AWS Compute Optimizerを活用した継続的な適正化とコスト削減
AWS Compute Optimizer（ACO）を活用して、AWSのコスト効率とパフォーマンス最適化を習得しましょう。この包括的なガイドでは、ACOが機械学習をどのように利用して、EC2インスタンス、EBSボリューム、Lambda関数の適正化に関する実用的でデータ駆動型の推奨事項を生成するかを説明します。これらの変更を実装するための具体的な手順とCLIの例を学び、継続的な最適化を確保してクラウド支出を削減し、アプリケーションの信頼性を維持します。
AWS Compute Optimizerを活用した継続的な適正化とコスト削減
AWSの適正化は、最初の不適切な変更が本番ワークロードをダウンさせるまでは、財務上の演習のように聞こえます。有用なバージョンはもっと慎重です。明らかに大きすぎるリソース、明らかに小さすぎるリソース、または扱いにくい世代のインフラストラクチャで実行されているリソースを見つけ、トラフィックパターン、状態、ロールバック、およびアプリケーションの動作を尊重する方法で変更を加えます。
AWS Compute Optimizerは、リソース構成と使用率メトリクスを分析し、EC2インスタンス、Auto Scalingグループ、EBSボリューム、Fargate上のECSサービス、Lambda関数などのサービスに対する推奨事項を生成することで、その作業を支援します。推奨事項は有用ですが、自動的な真実ではなく、意思決定のサポートとして扱う必要があります。Compute Optimizerはメトリクスを確認できます。リリースカレンダー、顧客のコミットメント、ライセンスの特殊性、または月末にのみ実行される奇妙なバッチジョブを常に確認できるわけではありません。
AWS Compute Optimizerについて
AWS Compute Optimizerは、サポートされているリソースの過去の使用率メトリクスを分析することで推奨事項を提供します。デフォルトのルックバック期間は通常最近の履歴に基づいており、拡張インフラストラクチャメトリクスにより、一部のリソースタイプで分析ウィンドウを延長できます。正確な可用性と保持期間は、リソースタイプ、リージョン、アカウント設定、およびAWSの機能変更によって異なる場合があるため、1つの数値に基づいて厳格なプロセスを構築する前に、現在のサービスページを確認してください。
ACOは、CPU使用率、メモリ使用量（適切なCloudWatchエージェントがインストールされている場合）、ネットワークスループット、ディスクI/Oなど、いくつかの要素を評価し、コスト効率とパフォーマンスの両方を優先する推奨事項を生成します。
ACOが提供する主要なメトリクス
- 最適化結果: リソースの分類（例：過剰プロビジョニング、過小プロビジョニング、最適化済み）。
- 推定月間節約額: 推奨事項が実装された場合の予想されるコスト削減額。
- パフォーマンスリスク: 推奨事項の実装がワークロードのパフォーマンスに悪影響を与える可能性を示す低、中、高の評価。
- 推奨オプション: 特定の代替リソース構成（例：インスタンスタイプ、メモリ設定、EBSボリューム仕様）。
注: Compute Optimizerの推奨事項自体は、多くの一般的な使用法では別途サービス料金なしで利用できますが、オプションの拡張メトリクスと分析対象のリソースによっては、依然として請求に影響を与える可能性があります。オプション機能を広く有効にする前に、アカウントの料金を確認してください。
Amazon EC2インスタンスの適正化
EC2インスタンスは、多くの場合、クラウドコンピューティングコストの最大の要因です。ACOは、スタンドアロンインスタンスとAuto Scalingグループ（ASG）内のインスタンスの両方に対して、カスタマイズされた推奨事項を提供します。
過剰プロビジョニングおよび過小プロビジョニングされたインスタンスの特定
ACOは、その分析に基づいてEC2インスタンスを分類します。
- 過剰プロビジョニング: Compute Optimizerが確認できるメトリクスについて、一貫して使用率が低いインスタンス。より小さい、または異なるインスタンスタイプへの移行を提案する場合があります。
- 過小プロビジョニング: 使用率が高い、またはリソースに負荷がかかっているインスタンス。より大きなインスタンス、異なるファミリー、またはより優れたCPU、メモリ、ネットワーク、ストレージ特性を持つ構成を提案する場合があります。
EC2適正化推奨事項の実装
変更の実装には、特に本番ワークロードの場合、慎重な計画が必要です。インスタンスタイプを変更するプロセスでは、通常、インスタンスの停止、変更、再起動が必要です。
例：CLIを使用した過剰プロビジョニングインスタンスの変更
Compute Optimizerがインスタンスをm5.largeからt3.largeに変更することを推奨する場合、EBS-backedインスタンスの機械的な手順は次のとおりです。
- インスタンスを停止する:
aws ec2 stop-instances --instance-ids i-1234567890abcdef0 - インスタンスタイプを変更する:
aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --instance-type "{'Value': 't3.large'}" - インスタンスを起動する:
aws ec2 start-instances --instance-ids i-1234567890abcdef0
ベストプラクティス: これらの変更は常にトラフィックが少ない期間に実行し、実装後24〜48時間はインスタンスメトリクス（CPU、レイテンシ、アプリケーションログ）を注意深く監視して、新しいサイズがパフォーマンスの低下なしにピーク負荷を処理できることを確認します。
タイプを変更する前に、インスタンスがAuto Scalingグループの一部であるか、インスタンスストアボリュームを使用しているか、プレースメントグループの要件があるか、ENAまたはNVMeの命名規則を使用しているか、ライセンスモデルに固定されているかを確認してください。本番サービスでは、新しいサイズを起動テンプレートに組み込み、インスタンスを段階的に交換し、ロードバランサーに接続をドレインさせる方が安全な場合がよくあります。
Amazon EBSボリュームの最適化
Compute Optimizerは、その推奨事項をEC2インスタンスに接続されたElastic Block Store（EBS）ボリュームに拡張します。ここでの最適化は、最新のボリュームタイプを提案し、IOPS/スループット設定を調整することで、1ドルあたりのパフォーマンスを最大化することに焦点を当てています。
移行の推奨事項
一般的な最適化の1つは、特にgp2から、ワークロードに適した**gp3**への古い汎用ボリュームの移行です。
| ボリュームタイプ | 利点 |
|---|---|
gp2 |
パフォーマンスはボリュームサイズとバーストクレジットに応じてスケーリングされます。 |
gp3 |
パフォーマンスは、サービス制限内でサイズとは別に構成できます。 |
Compute Optimizerは、観測された使用パターンに基づいて、特定のIOPSとスループットの値を推奨する場合があります。これらの推奨事項は出発点として扱ってください。最近の書き込みボリュームが少ないデータベースボリュームでも、メンテナンスウィンドウ、コンパクション、インデックスビルド、バックアップ、フェイルオーバーキャッチアップのために余裕が必要な場合があります。
実行可能な手順：ボリュームの変更
EBSボリュームの変更は、通常、ボリュームの使用中に実行できます（EC2インスタンスタイプの変更とは異なります）が、パフォーマンスへの影響を考慮する必要があります。
# 例：ボリュームをgp3に移行し、特定のIOPS/スループットを設定する
aws ec2 modify-volume \
--volume-id vol-fedcba9876543210 \
--volume-type gp3 \
--iops 3000 \
--throughput 125
コマンド実行後、変更状態を監視します。
aws ec2 describe-volumes-modifications \
--volume-ids vol-fedcba9876543210
重要なデータベースの場合は、最初にレプリカまたはステージングコピーで変更をテストしてください。ボリュームタイプの変更はオンラインで行われる可能性がありますが、新しいIOPSまたはスループット設定が低すぎる場合、ワークロードはI/O動作の変化を感じる可能性があります。
AWS Lambda関数の適正化
サーバーレスワークロードの場合、Compute OptimizerはAWS Lambda関数に関する重要な洞察を提供します。Lambdaでは、メモリ設定によって関数に割り当てられるvCPUの量が決まります。Lambdaの適正化は、主にパフォーマンス目標を満たす最小のメモリ構成を見つけることです。
メモリ/CPUのトレードオフ
Compute Optimizerは、Lambdaの使用率と期間のパターンを分析して、メモリ設定を推奨します。関数に1024 MBが割り当てられているが、512 MBでも許容できるパフォーマンスを発揮する場合があります。別の関数は、メモリを増やすと追加のCPUによって期間が十分に短縮され、より大きなメモリ割り当てを相殺できるため、コストが安くなる場合があります。
2番目のケースは人々を驚かせます。Lambdaのコストは割り当てられたメモリと期間に関連しているため、最も安価な設定は常に最小のメモリ値であるとは限りません。推奨事項を広く適用する前に、代表的なイベントをテストしてください。
Lambda関数の最適化の実装
Lambdaの最適化は簡単で、通常は関数の構成を簡単に更新するだけです。
例：Lambdaメモリ構成の更新
ACOが関数を2048MBから1024MBに移行することを推奨する場合：
aws lambda update-function-configuration \
--function-name MyOptimizedFunction \
--memory-size 1024
継続的な最適化をワークフローに統合する
適正化は1回限りの監査ではなく、継続的な規律であるべきです。Compute Optimizerは、そのAPIとAWS Organizationsとの統合を通じてこれを容易にします。
1. 集中管理
AWS Organizationsを使用している場合は、Compute Optimizerの委任管理者アカウントを指定します。これにより、ACOはすべてのアカウントにわたって統合された推奨事項を提供し、企業全体の潜在的な節約額を全体像で把握できます。
2. 自動化と通知
Compute Optimizer APIを使用し、AWS CloudWatch EventsまたはLambdaと統合して、自動化されたワークフローを作成します。
- スケジュールされたレポート: 最新の優先度の高い推奨事項（例：推定節約額が最も高いもの）をプルする、毎日または毎週のトリガーを設定します。
- アラート: ACOが特定の結果（例：パフォーマンスリスクが高い過小プロビジョニングインスタンス）を持つリソースを特定したときに、SNSを介してアラートをトリガーします。
- 半自動実装: 低リスクで高節約の推奨事項（EBS gp3移行など）については、Lambda関数を使用して変更リクエストを自動的に生成したり、必要なガバナンスしきい値を通過した後、変更を直接適用したりします。
# boto3を使用して推奨事項を取得する概念的なPythonスニペット
import boto3
aco_client = boto3.client('compute-optimizer')
response = aco_client.get_ec2_instance_recommendations(
filters=[
{'name': 'finding', 'values': ['Overprovisioned']}
]
)
# 推奨オプションを処理し、それに基づいて行動する...
実装は推奨事項の収集とは別にしておいてください。毎週のレポートで候補を安全にリストアップできます。ワークロードのコンテキストなしにインスタンスを停止したり、Lambdaメモリを変更したりするボットは、インシデントを引き起こす可能性があります。適切な中間点は、推奨事項、現在のメトリクス、提案された変更、推定節約額、およびロールバック計画を含むチケットまたはプルリクエストを開くことです。
推奨事項を確認する方法
各推奨事項について、いくつかの実用的な質問を自問してください。
- リソースはまだ使用中ですか、それともサイズ変更よりも削除の方が良い答えですか？
- ルックバック期間には、通常のピークトラフィック、バッチウィンドウ、および最近のリリースが含まれていますか？
- EC2でメモリデータは利用可能ですか、それとも推奨事項は主にCPUとネットワークに基づいていますか？
- インスタンスはステートフルですか、ライセンスされていますか、ハードウェアに固定されていますか、それとも手動で構成されていますか？
- 変更はAuto Scalingグループ、ブルー/グリーンデプロイメント、またはレプリカの背後でロールアウトできますか？
- 変更が成功したか失敗したかを証明するメトリクスは何ですか？
たとえば、夜間レポートを実行するEC2インスタンスは、営業時間中はアイドル状態に見え、真夜中過ぎの40分間は非常にビジー状態になる場合があります。広範な平均に基づく推奨事項はダウンサイジングを提案する可能性がありますが、本当の質問は、レポートがビジネスの期限までにまだ完了するかどうかです。バッチウィンドウを壊すコスト削減は節約にはなりません。
リスクを軽減するロールアウトパターン
最も安全な実装パスは、リソースによって異なります。
ロードバランサーの背後にあるステートレスなEC2サービスの場合は、手動でライブインスタンスを停止するのではなく、Auto Scalingグループまたはデプロイメントパイプラインを介してインスタンスを交換することをお勧めします。起動テンプレートを更新し、新しいタイプのインスタンスを1つ追加し、ヘルスチェックとアプリケーションメトリクスを監視し、残りを段階的にロールアウトします。これにより、自然なロールバックが可能になります。古い起動テンプレートバージョンに戻し、新しいインスタンスを交換します。
ステートフルなEC2ホストの場合は、より遅いパスを取ります。バックアップを確認し、接続されているボリュームを理解し、メンテナンスウィンドウを確認し、アプリケーションが停止/起動サイクルに耐えられることを確認します。一部の古いインスタンスファミリーと新しいファミリーでは、ディスクまたはネットワークデバイスの公開方法が異なるため、デバイス名を想定する起動スクリプトは、タイプ変更後に壊れる可能性があります。
EBSの場合は、ボリュームタイプまたはプロビジョニングされたパフォーマンスを変更した後、コストとパフォーマンスメトリクスの両方を監視します。月間推定値が低いだけでは十分ではありません。キュー長、レイテンシ、スループット、およびアプリケーションレベルの症状を確認してください。ボリュームがデータベースをバックアップしている場合、アプリケーションのレイテンシは、ボリュームグラフ単独よりも多くの情報を提供する可能性があります。
Lambdaの場合は、関数が重要な場合、新しいバージョンまたはエイリアスベースのロールアウトを公開します。トラフィックのごく一部を新しいメモリ設定に送信し、期間、エラー、コールドスタート、ダウンストリームへのプレッシャーを比較し、さらにトラフィックをシフトします。メモリが増えると高速になる関数は、呼び出すデータベースやAPIにより多くのプレッシャーをかける可能性があるため、パス全体を監視してください。
推奨事項を明確に報告する
有用な適正化レポートは、コンテキストのないインスタンスIDでいっぱいのスプレッドシートであってはなりません。現在の構成、推奨構成、観測された使用率ウィンドウ、推定月間節約額、パフォーマンスリスク、所有者、提案されたロールアウト方法、およびロールバック計画を含めてください。推奨事項が受け入れられた、延期された、または拒否された理由を説明する短いメモを追加します。
拒否された推奨事項も依然として有用です。データベースサーバーは、平均トラフィックではなくフェイルオーバー用にサイズ設定されているため、過剰プロビジョニングに見える場合があります。ライセンスサーバーは、固定のインスタンスファミリーを必要とする場合があります。使用率の低いホストは、計画された移行を待っている場合があります。これらの理由をキャプチャすることで、同じ推奨事項が毎月再び議論されるのを防ぎます。
Compute Optimizerを使用するためのベストプラクティス
| 領域 | ベストプラクティス |
|---|---|
| 監視期間 | 推奨事項を信頼する前に、リソースが少なくとも14日間、通常の負荷で実行されていることを確認します。 |
| パフォーマンステスト | ダウンサイジングの推奨事項を実装した後は、必ずロードテストを実行して、アプリケーションが必要なSLO（サービスレベル目標）を維持していることを確認します。 |
| 特殊なワークロード | ステートフルアプリケーション、データベース、または特定のインスタンスタイプや最小リソースを必要とする可能性のあるサードパーティのライセンスサーバーには注意してください。ACOがより小さいサイズを推奨している場合でも同様です。 |
| メモリメトリクス | EC2の場合は、CloudWatchエージェントをインストールして、詳細なメモリ使用量データを収集します。これがないと、ACOの適正化推奨事項は主にCPUとネットワークに依存し、不完全になる可能性があります。 |
| 継続的なレビュー | ACOダッシュボードを生きたドキュメントとして扱います。ワークロードは常に変化するため、リソースサイジングの定期的な再評価が必要です。 |
最終確認
AWS Compute Optimizerは、レビューの習慣の一部になるときに最も価値があります。それを使用して、無駄を見つけ、過小プロビジョニングされたリソースを特定し、古い前提に挑戦してください。次に、AWSが推測できないコンテキスト（リリースタイミング、ピークイベント、顧客の約束、障害ドメイン、ロールバックパス）を持ち込みます。最善の適正化プログラムは、最も多くの推奨事項を受け入れるプログラムではありません。それは、本番環境をより脆弱にすることなく、コストを節約するプログラムです。