【レポート】AWSでスケールする際のコスト最適化 #reinvent #ENT302

現地時間2017年11月27日(月)〜2017年12月01日(金)の計5日間に渡り、ラスベガスの複数のホテルにまたがる"キャンパス"で行われている『AWS re:Invent 2017』。

• AWS re:Invnet 2017｜AWS

本エントリではブレイクアウトセッション『ENT302-Optimizing Costs as You Scale on AWS(AWSでスケールする際のコスト最適化)』の内容をレポートします。

セッション概要

セッション登壇者と概要は以下の通りです。

セッション内容目次

• はじめに
• コストの最適化の為の5本の柱
• 1つめの柱：インスタンスサイズの変更
• 2つめの柱：弾力性の向上
• 3つめの柱：適切な価格設定モデルの選択
• 4つめの柱：適切なストレージとサービスの活用
• 5つめの柱：最適化のためのガバナンス：対策と目標
• コスト説明責任(アカウンタビリティ)の文化
• サクセスストーリー(エクスペディア社の事例)

セッションレポート

はじめに

• このセッションでは、AWS導入する際の、コストの最適化について説明する

何にコストを払っているのか？

• 今までは、「持っているものに払う」
• これからは「欲しいものに払う」

GEオイルガスの例

• "TCOを52%下げることができた" CTOの弁

コストの最適化

コスト最適化の為の5本の柱

1. インスタンスサイズの変更
2. 弾力性の向上
3. 適切な価格設定モデルの選択
4. 適切なストレージとサービスの活用
5. 最適化のためのガバナンス：対策と目標

１つめの柱：インスタンスサイズの変更

• サイズ変更
  • パフォーマンス要件を満たしながら最も安価なインスタンスを選択する
  • CPU、RAM、ストレージ、ネットワークの利用状況を見て、潜在的な問題を特定する
  • Amazon CloudWatchメトリックの活用とカスタムRAMメトリックの設定を活用する

サイズ変更の例

• c3.xlargeを使っていたが、CPUリソースがそんなに必要ないとわかったのでm4.largeへ変更してコストを33%off

２つめの柱:弾力性の向上

• 非本番インスタンスをオフにする
  • 常に実稼働する必要がないdev/test環境を探し、電源をオフにする
  • AWS Lambda + Amazon Cloudwatch = 自動スケジューリング(参考)
• Auto Scale本番環境
  • Auto Scalingを使用して、突発的な負荷が発生した際に自動拡大/縮小する

弾力性の向上例

• ピークだけサーバを追加することで、コストを1/3減らせる
  • 2サーバx24時間稼働を、1サーバx16時間+2サーバx8時間に変更

(ピンぼけすみません)

３つめの柱：適切な価格設定モデルの選択

• オンデマンドインスタンス
• リザーブドインスタンス(RI)
• スポットインスタンス

価格設定の例

• オンデマンドインスタンス
  • 利用分に応じた課金
  • 前払い料金なし
  • 予測不能な短期間、突発的な対応に適する
• リザーブドインスタンス(RI)
  • キャパシティの予約状況に応じて前払いし、時間毎の課金を下げる(最大72%引き)
  • 1年もしくは3年間の契約
  • RIマーケットプレイスで残り期間のRI権利を購入できる
  • いつも動作する環境に適する
  • 60%以上のコスト削減が可能
• スポットインスタンス
  • 予備のキャパシティが欲しい時に契約し、使用する
  • 入札価格がスポット価格を上回っている間、インスタンスが実行される
  • 時間やインスタンス数が柔軟に取れる場合に適する
  • 90%以上のコスト削減が可能！

リザーブドインスタンス(RI)

• RIは2種類
  • 1年(20%〜40%コスト削減)
  • 3年(最大75%コスト削減)
• RI対象のサービスはEC2だけではない
  • Amazon EC2
  • Amazon RDS
  • Amazon Redshift
  • Amazon Aurora
  • Amazon ElastiCache
  • Amazon DynamoDB
  • Amazon CloudFront
• 常時稼働しているリソースはRIでカバー
• RIの利用率を高める(事がコストダウンに繋がる)
• コンバーティブルインスタンスを使えば色々な変更が可能
  • インスタンスファミリー
  • オペレーティングシステム
  • テナンシー
  • 支払いオプション

スポットインスタンス

• 耐障害性のある、ステートレスなアプリケーションに適する
• オートスケーリンググループに含めておく
• バッチ処理
• EMR　等
• 最大80%安くなる

バランスを取る

• RI、オンデマンド、スポット、それぞれの価格体型の違いを理解し、使い分けること

4つめの柱：適切なストレージとサービスの活用

• 例えば、データの保存
  • 普通はS3を使うが、Glacierを使用すれば、入出力に時間は掛かるものの、より安くデータの保存ができる
• AWS Lambdaでアイドルタイムを取り除く
  • コードの管理の為のインフラの管理が不要
  • 自動スケールし、自動プロビジョニングする
  • 100ms単位の課金、アイドル状態には無課金

Lambdaを使用した例

• EC2 smallインスタンスを使用していた環境をLambdaに切り替えたことで、平均利用率ベースで利用料を1/4以下にダウン

5つめの柱：最適化のためのガバナンス：対策と目標

ガバナンスと制御の為のツール

• リソースプロビジョニングを制限する
  • AWS Service Catalog
  • IAM
  • Roles
  • Permissions

コストの可視化

• コスト割り当ての為のタグ付けが必須
• タグ付けの例
  • コストセンター名
  • アプリケーション名やワークロード名
  • ユーザー名
  • 失効日
  • 自動的なタグ付けを利用(参考：GorillaStack)

アカウントのデプロイを管理する

• AWS organizations
  • アカウントをポリシーベースの論理グループ化
  • 制御APIを提供して操作を自動化
  • グループは5階層までネスト可能
  • 現在利用可能(GA)

AWS Trusted Advisor

• AWS Trusted Advisorはベストプラクティスを提供する
  • コストの最適化
  • セキュリティ
  • 耐障害性
  • パフォーマンスの向上
• 色分けしてわかり易く表示してくれる

メトリックとターゲット

• 成功の指標を決め、進捗(目標達成度合い)を追う
  • 日あたりのインスタンス停止割合
  • 全体における適切なサイズになっているインスタンス比率
  • 常時起動リソースにおけるRI利用率
  • RIインスタンスの稼働率

コスト説明責任(アカウンタビリティ)の文化

• (運用の)原則を建てたとしても、運用中にエージェントから取得される実際の値とはギャップがある
• その場合に、CCoE(Customer Center of Expertise)はどう考えるべきか？
  • どのくらい負荷が「定常状態」なのか
  • 現在、柔軟性の要求に対してどのように対応しているか
  • AWSの構成が最適かどうか再検討したか
  • システムに余力があるか
  • どのようにして(システム最適化の)プロセスに関わることができるか

Cloud Center of Excellence

Cloudを活用した業務継続性の実現や運用コストの削減、および技術革新を推進するためには、以下の要素が必要

• インセンティブの調整（アメとムチ）
• 自動化
• レポート機能
• コントロールとガバナンス
• 統計指標/KPI

どこから始めるか

1. クラウドコンピテンシーセンターを組織する
2. 正しいツールを導入する
3. 行動を強化する
4. 加速するためにパートナーを活用する

サクセスストーリー（Expedia社の事例）

ここからは、事例紹介ということでExpedia社のAbiade氏が説明しました。

Expediaは世界最大級のオンライン旅行会社です。

会計におけるミッション

「財務インテリジェンスとオペレーションの卓越性によりExpedia Expediaの旅行革命を強化する」

「クラウド関連のリソースを効果的かつ効率的に使用しながら、ブランド全体で適切に予測され、財務的にインテリジェントな意思決定を正しく予測、報告、実行できるようにする」

これが私達の物語…

2016年、クラウドに掛かるコストの予想が、驚く程大きく超えてしまっていた。

そこで、コスト超過の原因を調べ始めた。

• 早急に手を打たなければならない
• 変更には限られた時間しかない
• イノベーションを再度行う余裕はない

財務チームと技術チーム、そしてAWSとパートナーシップを組んで、対応にあたった。

• 最適化を開始：
  • 小さなテンポラリチームは、すべてのアプリを確認し、無駄を最小限に抑えた
  • しかしそれは長続きせず、長期的には持続できなかった
  • 長期的な解決策は、コスト意識をDevOpsカルチャーの一部にすることだと分かった

そこで、「コストの最適化」から「コストの透明性追求」にピボットした。

コストの透明性追求で実施したこと

• 自動化
  • タグ付けが可能なリソースには全てタグを追加
  • タグが付いていないリソースは直ぐに削除されるよう自動設定
• バートナーツールの導入
  • CloudHealth
• 自作
  • Cloud Portforio Analyzer(CPA)の開発
• AWSオプションの利用
  • Trusted Adviser等
• 成功の指標を決め、進捗を追う
  • RIインスタンスの稼働率
  • (全体に占める)RI利用率
  • タグを付けていないリソースが発生させている料金
  • 月ごとの利用料金の予測値と実績値の比較
  • 日毎の利用料金
  • 利用していないRIとそのタイプ

透明性を追求した結果…「コスト意識が自社のDevOpsカルチャーの一部となる」

コスト最適化の為に取り組んだこと

• RIの導入が戦略的な鍵
  • 常時起動しているリソースに対して1年RIを適用する
  • 小さく、しかし頻繁にRI課金を行う(5/6ヶ月〜毎月〜毎週)
  • RIをEC2インスタンス、RDS、Redshift、ElastiCacheに適用する

全体に占めるRIの比率と、RIの利用率を毎月監視

その結果…

• インスタンスの時間あたりのコスト：22%ダウン
• インスタンスの利用効率：250%アップ
• 従来の5倍のコスト節約

コスト最適化のプラクティス

1. タグ付けの自動化
2. 可視化、モニタリング
3. 測定、測定、測定…
4. RI価格の活用
5. 分散型の予測と計算プロセス
6. チームに最適化のベストプラクティスを共有するよう推奨

12ヶ月以上運用した後…結果として

• コスト意識が自社のDevOpsカルチャーの一部となった
• タグ付け可能なリソースの内、90％以上のタグ付けを維持する
• RIの比率が40%から70%に、利用率は90%以上に
• 5倍節約
• クラウドに掛かる費用の予測精度が高くなった

今後の取り組み

• パートナーシップは継続
• DIYで作成したコスト可視化ツールを作り上げる
• 「コストの最適化の為の5本の柱」を全て活用
• より多くのチームを予測プロセスに組み込む
• エンドtoエンドのクラウド移行話を伝える

まとめ：AWS利用料金の最適化から学んだこと

• パートナーシップは成功の鍵
• 料金タイプの選択肢から最適なバランスを見つけること
• ワークロードを標準化して節約する必要はなかった
• 内部の技術ブログ上の議論、最適化パターンやトレードオフの共有が勝利へ導く
• クラウドのコスト最適化は、移行前後に行われる規律である

感想

AWSを使ってコスト削減する為の具体的な方法が、もれなく網羅されたセッションでした。日本でもコスト削減目的でクラウド導入を検討される方が多いですが、必見の内容だと思います。

それでは、また。