はじめに

AWS Compute Optimizer では、特定のリソースに対して使用の最適化分析が行なえます。
ただ、情報が多く何を見ればいいのかわからない人のために、多くの方が使われている EC2 を対象として最適化する場合に見るポイントについて解説します。

AWS Compute Optimizer とは

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

最近のアップデートで AWS Fargate が追加されました。
AWS Compute Optimizer now supports Amazon ECS services running on AWS Fargate

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

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

それに合わせて、各リソースごとに様々な要件があります。
サポートされるリソースと要件 – AWS Compute Optimizer

サポートされているリソースごとに要件を軽く見ていきます。

EC2 インスタンスの要件

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

サポートしているインスタンスタイプについては以下ドキュメントからご覧ください。
Amazon EC2 インスタンスの要件

Auto Scaling グループの要件

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

• 1 つのインスタンスタイプのみなこと（混合インスタンスタイプはありません)
• 希望する容量、最小容量、最大容量はすべて同じなこと (たとえば、固定数のインスタンスを持つ Auto Scaling グループ)
• スケーリングポリシーがアタッチされていないこと
• オーバーライドは設定されていないこと

Auto Scaling グループの要件

EBS ボリューム要件

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

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

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

Amazon EBS のボリューム要件

Lambda 関数の要件

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

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

Lambda 関数の要件

Fargate の 要件

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

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

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

Compute Optimizer で行う最適化

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 インスタンスタイプが推奨される場合、移行作業は低です。
といったように、一定の水準で移行作業の労力について評価してくれます。

これにより、移行にかかるコストについてもおおよそ見積もる事が可能です。
Graviton のインスタンスタイプに切り替える際には、Porting Advisor for Graviton といった分析ツールがあるのでぜひお試しください。
Porting Advisor for Graviton を発表

プラットフォームの違い

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

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

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

EC2 インスタンスの詳細

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

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

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

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

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

参考資料

AWS Compute Optimizer | AWS News Blog