Compute Optimizer のルックバック期間・使用率プリセットについてまとめてみた
こんにちは！クラウド事業本部のおつまみです。
みなさん、Compute Optimizer 使っていますか？
コスト最適化に欠かせない便利なサービスですよね。
Compute Optimizerは、機械学習を使用してEC2インスタンス、EBSボリューム、Lambda関数などのリソースを分析し、最適なリソース推奨事項を提供してくれるサービスです。
しかし、「ルックバック期間と指標の設定をどうすればいいの?」という質問をよく受けます。
本ブログでは、Compute Optimizerのルックバック期間と使用率プリセット(指標)の設定について、わかりやすく解説します。
ルックバック期間と使用率プリセットとは？
Compute Optimizerでは、リソースの最適化推奨を生成する際に、以下の2つの重要な設定があります。
| 項目 | 概要 |
|---|---|
| ルックバック期間 | 過去何日分のメトリクスデータを分析に使用するかを決定します。14日間（デフォルト）または32、93日間から選択できます。 |
| 使用率プリセット | CPU使用率とメモリ使用率のしきい値とヘッドルームを決定します。最大節約額、バランス、デフォルト、最大パフォーマンスの4つから選択できます。 |
これらの設定により、Compute Optimizerが生成する推奨事項の精度とコスト削減の傾向が変わります。
ルックバック期間の選び方
こちらが3つの設定値の違いです。
| 項目 | 14日間（デフォルト） | 32日間 | 93日間 |
|---|---|---|---|
| 分析傾向 | 短期的な傾向 | バランス型 | 長期的な傾向 |
| 推奨精度 | 最近の状況に即応 | 中程度 | 最も高精度 |
| メリット | ✓ 迅速な分析 ✓ 新規リソース向け ✓ 環境変更を素早く反映 |
✓ 短期と長期のバランス ✓ 月次周期を考慮 ✓ 適度な応答性 ✓ ノイズを軽減 |
✓ 最も正確な分析 ✓ 周期的ピーク対応 ✓ 季節性を考慮 ✓ 長期的パターン把握 |
| デメリット | ✗ 短期変動に影響されやすい ✗ 月次ピークを見逃す ✗ 一時的なスパイクの影響 |
✗ 四半期周期は不十分 ✗ 季節変動は考慮できない ✗ 長期パターンは不完全 |
✗ 過去の不要データも含む ✗ 環境変更の反映が遅い ✗ 最新の最適化効果が見えにくい |
| 適用シナリオ | • 開発・テスト環境 • 新規プロジェクト • 常時稼働Webサーバー • 季節性が低いワークロード |
• 月次バッチ処理システム • 月末・月初負荷集中 • 経理・請求処理システム • 迷った時はこれ |
• 本番環境の長期最適化 • 四半期バッチ処理 • 季節性のあるECサイト • 長期稼働システム |
| 推奨環境 | 開発環境、新規環境 | 本番環境（月次周期） | 本番環境（長期運用） |
| 変更への対応 | 非常に速い | 速い | 遅い |
どのルックバック期間を選ぶべきか？
上記の表をもとに、具体的な選び方をまとめまてみました。参考にしてみてください。
14日間を選ぶべきとき
- 開発環境やテスト環境でコストを削減したいとき
- 新しくリリースしたサービスで、まだ運用データが少ないとき
- アプリケーションに大きな変更を加えた直後で、最新の状況を素早く反映させたいとき
- 負荷がほぼ一定で、月次や季節による変動がないワークロードのとき
- とにかく迅速に推奨を得たいとき
32日間を選ぶべきとき
- 月次のバッチ処理や定期的な月末・月初処理があるシステムのとき
- 経理システム、請求処理システムなど、月の特定時期に負荷が集中するとき
- 本番環境だが、最近のアプリケーション改善の効果も反映させたいとき
- 迷ったらこれ: 14日間と93日間のどちらを選ぶか迷った場合、バランスの取れた32日間がおすすめ
93日間を選ぶべきとき
- 本番環境で長期的なコスト最適化を行いたいとき
- 四半期ごとの決算処理や、年次のピーク処理があるシステムのとき
- ECサイトなど、季節やキャンペーンによって負荷が大きく変動するビジネスのとき
- システムが既に長期間（数か月以上）安定稼働しており、十分なデータがあるとき
- 最も精度の高い推奨を得たいとき（環境変更が少ない場合）
使用率プリセットの選び方
使用率プリセットは、CPU使用率とメモリ使用率のしきい値とヘッドルームを決定します。この設定により、Compute Optimizerがどれくらい余裕のあるサイジングを推奨するかが変わります。
しきい値とヘッドルームとは？
- しきい値: これを超える使用率が観測された場合、インスタンスが過剰に利用されていると判断される基準値
- ヘッドルーム: 推奨インスタンスに持たせる余裕度。ヘッドルームが大きいほど、ピーク時に対応できる余裕が増える
ヘッドルームはあまり聞きなれない言葉のため、追加で解説します。
ヘッドルームとは、推奨されるインスタンスタイプに持たせる「バッファ（余裕）」のことです。これは、予期しない負荷の増加や突発的なトラフィックのスパイクに対応するための予備容量を意味します。
具体例で見てみましょう。
あるEC2インスタンスのCPU使用率が、ルックバック期間中の最大値で70%に達したとします。
-
ヘッドルーム0%の場合: 最大70% + 余裕0% = 70%の容量を持つインスタンスを推奨
- 突発的な負荷で70%を超えると即座にキャパシティ不足になる
- 最も大きな余裕を持ち、パフォーマンス劣化のリスクが最も低い
- コストは最も高い
-
ヘッドルーム20%の場合: 最大70% + 余裕20% = 90%の容量を持つインスタンスを推奨
- 突発的な負荷で90%まで上昇しても対応可能
- 適度な余裕を持ち、バランスが取れている
- コストは中程度
-
ヘッドルーム30%の場合: 最大70% + 余裕30% = 100%の容量を持つインスタンスを推奨
- 最大使用率ギリギリのインスタンスを推奨
- 突発的な負荷増加に対する余裕がほとんどない
- コストは最も低い
- パフォーマンスリスクが高い
つまり、ヘッドルームが小さいほど余裕を持った推奨となり、ヘッドルームが大きいほどコスト重視の推奨となります。
4つの使用率プリセット
以下の4つの使用率プリセットが用意されています。
| プリセット | CPUしきい値 | CPUヘッドルーム | メモリヘッドルーム | 特徴 |
|---|---|---|---|---|
| Maximum savings（最大節約額） | P90 | 0% | 10% | 最も高い節約、パフォーマンスリスク高 |
| Balanced（バランス） | P95 | 30% | 30% | ほとんどのワークロードに適している |
| Default（デフォルト） | P99.5 | 20% | 20% | パフォーマンスリスク低、節約の機会限定的 |
| Maximum performance（最大パフォーマンス） | P99.5 | 30% | 30% | 最もパフォーマンス重視、余裕が大きい |
特徴に合わせて、選択する必要があります。
実際の設定例
ここでいくつかのユースケースをご紹介します。
例1: 本番環境のWebアプリケーション
ルックバック期間: 93日間
使用率プリセット: Balanced（バランス）
理由: 長期的な傾向を把握しつつ、コストとパフォーマンスのバランスを取りたい
例2: ミッションクリティカルなAPIサーバー
ルックバック期間: 93日間
使用率プリセット: Maximum performance（最大パフォーマンス）
理由: 長期間の全てのピークに対応でき、パフォーマンス低下のリスクを最小化
例3: 月次バッチ処理システム
ルックバック期間: 32日間
使用率プリセット: Default（デフォルト）
理由: 月次の高負荷ピークを考慮しつつ、バッチ処理のため節約の機会は限定的でも安定性を優先
例4: 開発環境
ルックバック期間: 14日間
使用率プリセット: Maximum savings（最大節約額）
理由: 開発環境のため、コスト削減を最優先
例5: 新規サービスの初期段階
ルックバック期間: 14日間
使用率プリセット: Balanced（バランス）
理由: まだデータが少ないため短期間で分析し、ある程度の余裕を確保
例6: 経理システム・請求処理システム
ルックバック期間: 32日間
使用率プリセット: Balanced（バランス）
理由: 月末・月初の負荷集中を考慮しつつ、安定したパフォーマンスを確保
リソースごとには設定できないので、気をつけましょう。
最後に
今回はCompute Optimizerのルックバック期間と使用率プリセットの設定について解説しました。
設定変更を頻繁に行うことは少ないですが、Compute Optimizerを効果的に活用して、コストとパフォーマンスの最適なバランスを見つけましょう！
最後までお読みいただきありがとうございました!
以上、おつまみ（@AWS11077）でした！
