AWS Compute Optimizerを使用したコスト最適化アプローチ

これは何？

昨今、クラウドでシステムを構築することが主流になりましたが、クラウド利用料を最適化するには様々な情報をみなくてはいけません。
今回はEC2を対象として、最適化をする場合に見るポイントについて、解説します。

AWS Compute Optimizer とは

AWS Compute Optimizer は、 AWS リソースの設定と使用率のメトリクスを分析するサービスです。リソースが最適かどうかをレポートし、コストを削減し、ワークロードのパフォーマンスを向上させるための最適化に関する推奨事項を生成します。Compute Optimizer には、最近の使用率メトリクスの履歴データと、推奨事項の予測使用率を示すグラフもあります。このグラフを使用して、最適な価格性能のトレードオフを提供する推奨事項を評価できます。使用パターンの分析と視覚化は、実行中のリソースを移動またはサイズ変更するタイミングを決定し、パフォーマンスとキャパシティーの要件を満たすのに役立ちます。
AWS Compute Optimizerとは

AWS Compute Optimizer とは、直近 14 日間のリソースの使用状況を機械学習で分析し、適切なリソース量を提示してくれるサービスです。

例えば、過剰なインスタンスタイプを選択していてリソースが余っている場合は、インスタンスサイズを下げることによりコスト最適化が望めます。
逆に、プロビジョニング不足なものについては、パフォーマンスを向上のためインスタンスサイズを上げる場合の参考に役立ちます。

なお無料範囲では、14 日間のデータに基づき分析をしてくれます。
さらに、分析期間を伸ばしたい場合は、有料機能を使って 3 か月に延長することも可能です。

ワークロードによっては、繁忙期でアクセスが集中する場合などは短期間のデータだけを見て分析するのでは不十分です。
そのため、もう少し期間を広げて分析するほうがより最適化な分析が行なえます。

サポートされるリソースと要件

推奨事項を出してくれるリソースは以下のとおりです。

Amazon EC2 インスタンス
Amazon EC2 Auto Scaling グループ
Amazon EBS ボリューム
AWS Lambda 関数
AWS Fargate

ここで一点注意が必要です。
EC2 使っているからといっても推奨事項を表示してくれる訳では無いです。

前提として、Compute Optimizer はメトリクスから分析しているので、CloudWatch リソースからのメトリックデータが 30 時間連続してあることが必要となっています。

それに合わせて、各リソースごとに様々な要件があります。

サポートされるリソースと要件 - AWS Compute Optimizer

EC2 インスタンスの要件

EC２の場合は、サポートされているインスタンスタイプが決まっています。

サポートしてるEC2インスタンスタイプは以下のリンク参照です。

EC2インスタンスの要件

Auto Scailing グループの要件

Auto Scailingの倍は、EC2要件と合わせて以下をすべて満たす必要があります。

• 単一のインスタンスタイプのみを実行します。（混合インスタンスタイプは不可）
• 必要容量、最小容量、最大容量の値はすべて同じです（たとえば、インスタンス数が固定されている 自動スケーリンググループ）。
• スケーリングポリシーはアタッチされていません。
• オーバーライドは設定されていません。

Auto Scailingグループの要件

EBS ボリューム要件

EBS ボリュームの場合は、ボリュームの種類とインスタンスへのアタッチが必要となってます。

• 汎用SSD
  • gp2
  • gp3
• プロビジョンド　IOPS SSD
  • io1
  • io2

またボリュームは、少なくとも30時間連続してインスタンスにアタッチする必要があります。

Amazon EBSボリューム要件

Lambda関数の要件

Lambda関数の場合は、メモリ量と呼び出し回数が必要となってます。

• 構成されたメモリが 1,792 MB 以下
• 関数は、過去 14 日間で少なくとも 50 回呼び出されること

これらの要件を満たさない関数には、「使用不可」という結果が返されます。「未確定」の理由コードは、 1,792 MB を超えるメモリを設定した関数に適用されます。過去 14 日間に呼び出された回数が 50 回未満の関数には、データ不十分が適用されます。

Lambda関数の要件

Fargateの要件

Fargateの場合は、スケーリングポリシーで制限があります。

• サービスには、過去14日間dふぇ少なくとも24時間のCloudWatchおよびAmazon ECS使用率メトリクスが必要になります。
• ステップスケーリングポリシーが割り当てられてないこと。
• CPUとメモリには、ターゲットスケーリングポリシーが割り当てられてないこと。
• サービスの実行ステータスはSteadyStateまたはMoreworkであること。

FargateでのAmazon ECSサービスの要件

Compute Optimizerの使用

Managed CosoleからCompute Optimizerに飛ぶとダッシュボード画面で「節約の機会」や「パフォーマンスの向上の機会」が確認できます。

EC2 インスタンスレコメンデーション項目

EC2 を例にレコメンデーション項目について見ていきます。

各リソースごとのレコメンデーションの画面に飛ぶと詳細を一覧で見ることができます。
以下例は EC2 のレコメンデーション内容です。

EC2 インスタンスの推奨事項を表示 – AWS Compute Optimizer

EC2 では以下 29 の項目で確認できます。
たくさんありますが、どこを見るのかのポイントについて詳細を後述します。

インスタンス ID
インスタンス名
結果
検出結果の理由
推定月間節約額 (オンデマンド)
節約の機会 (%)
現在のパフォーマンスリスク
推定月間節約額 (RI と Savings Plans)
効果的な拡張インフラストラクチャメトリクス
現在のインスタンスタイプ
現在のオンデマンド料金
推奨インスタンスタイプ
推奨されるオンデマンド料金
価格差
価格差 (%)
移行にかかる労力
推論されるワークロードタイプ
プラットフォームの違い
リザーブドインスタンス時間
オンデマンド時間
Savings Plan 時間
現在の RI カバレッジ (%)
現在の RI 使用率 (%)
推奨される RI カバレッジ (%)
推奨される RI の使用率 (%)
アカウント ID
リージョン
Auto Scaling グループ名
アタッチされた EBS ボリューム

これらの項目すべてを見ていくのは大変なので 7 つのポイントに絞って以降で解説をします。

EC2 のレコメンデーションポイント

EC2 のレコメンデーションのポイントは以下の順番で各列を見ていくのが良いです。

1 結果
2 検出結果の理由
3 現在のパフォーマンスリスク
4 現在・推奨のインスタンスタイプとオンデマンド料金
5 節約の機会 (%)
6 移行にかかる労力
7 プラットフォームの違い

結果

EC2 インスタンスの推奨事項ページの調査結果列には、分析期間中の各インスタンスのパフォーマンスの概要が表示されます。

この結果が以下２つの分類の場合は最適化要素が存在しているインスタンスを表しています。
詳細については次項の「検出結果の理由」で確認が可能です。

• プロビジョニング不足
• オーバープロビジョニング
  「最適化」になっているものについては、特筆してパフォーマンス問題はないです。
  しかし、「推奨インスタンスタイプ」は表示されている場合があるので、最新のインスタンスタイプにすることでコスト最適化が図れるかもしれません。

検出結果の理由

EC2 インスタンスの推奨事項と EC2 インスタンスの詳細ページの [理由の検索] 列には、インスタンスのどの仕様がプロビジョニング不足またはオーバープロビジョニングされているかが示されます。

どこに対してパフォーマンス影響があるのかを表しています。
対象となるのは以下のとおりです。

• CPU
• メモリ
• EBS スループット
• EBS IOPS
• ネットワーク帯域幅
• ネットワーク PPS
• ディスク IOPS
• ディスク スループット

複数の箇所でパフォーマンス影響がある場合は複数表示されます。

現在のパフォーマンスリスク

推奨される各インスタンス タイプがワークロードのリソース ニーズを満たさない可能性を定義します。

検出した結果のパフォーマンスリスクを以下 5 段階評価で表しています。

• 非常に低い
• 低い
• 中程度
• 高い
• 非常に高い

「高い」や「非常に高い」に属しているものからサイジングを検討すると良いでしょう。

現在・推奨のインスタンスタイプとオンデマンド料金

現在・推奨のインスタンスタイプとオンデマンド料金について確認できます。

これらを比較してどれぐらい単価が安くなるのかがわかります。

節約の機会

現在のインスタンスのオンデマンド料金と推奨されるインスタンス タイプの料金との差のパーセンテージが表示されます。

現在のインスタンスタイプから推奨に替えたときに得られるコストメリットを表しています。

移行にかかる労力

現在のインスタンス タイプから推奨されるインスタンス タイプに移行するために必要となる可能性のある労力のレベルが一覧表示されます。

たとえば、ワークロードタイプを推測できないが、AWS Graviton インスタンスタイプが推奨される場合、移行作業は中です。
Amazon EMR が推定ワークロードタイプであり、AWS Graviton インスタンスタイプが推奨される場合、移行作業は低です。
といったように、一定の水準で移行作業の労力について評価してくれます。

これにより、移行にかかるコストについてもおおよそ見積もる事が可能です。

プラットフォームの違い

現在のインスタンスと推奨されるインスタンス タイプの違いが説明されています。現在のインスタンスから推奨されるインスタンス タイプにワークロードを移行する前に、構成の違いを考慮する必要があります。

• アーキテクチャ
• ハイパーバイザー
• インスタンスストアの可用性
• ネットワークインターフェース
• ストレージ インターフェイス
• 仮想化タイプ

インスタンスタイプによって異なる特徴について表しています。
これにより、推奨されるインスタンスタイプが現在のワークロードの要件に合致するのか事前に確認することができます。

EC2インスタンスの詳細

レコメンデーションの画面で各インスタンスを選択するとインスタンスごとの詳細に画面に遷移できます。

ここでは、インスタンスタイプを変えた場合のシミュレーションができます。
また、推奨オプションとの比較も可能です。

詳細ページには、特定のインスタンスに対する最大 3 つの最適化の推奨事項が一覧表示されます。

メトリクスベースでも見ていくことができます。

この詳細を見ながら、どのインスタンスタイプに変えることが適切なのかより詳細に分析していくことができます。