Compute Optimizer のEBSボリューム最適化提案をそのまま受け入れていいか検討してみた
2025.01.31こんにちは！AWS事業本部のおつまみです。
みなさん、普段 Compute Optimizer を利用していますか？私は利用しています。
コスト削減を進める上で、必須のサービスですよね。
今回あるアカウントにて、いくつかのEBSボリュームに対して、IOPSとスループットを下げた方がコスト削減できるよとレコメンドが出ていました。
レコメンド通り、早速変更しよう！と思ったのですが、本当にこのまま下げても大丈夫でしょうか？
他に気にする指標がないか気になり、調査した内容を共有します。
3行まとめ
- Compute Optimizerのレコメンドだけでなく、2024/10に新規追加された
VolumeIOPSExceededCheckとVolumeThroughputExceededCheckメトリクスも確認する必要がある - EBSのパフォーマンス最適化は、ワークロードの要件確認から段階的な変更、継続的なモニタリングまで慎重に進める必要がある
- コスト削減効果と性能要件のバランスを考慮し、優先順位をつけて対応を進めることが重要である
調査内容
EBSのパフォーマンス不足時の検知に役立つメトリクスについて
2024/10にEBSのパフォーマンス不足時の検知に役立つメトリクスが登場していました。
EBS ボリュームの設定された IOPS またはスループットのパフォーマンスを超えるアクセスがあった場合に検知するメトリクスです。以下の2種類があります。
- VolumeIOPSExceededCheck
- アプリケーションがボリュームのプロビジョニングされた IOPS パフォーマンスを超える IOPS が記録されるとメトリクスの値が変化します。
- VolumeThroughputExceededCheck
- アプリケーションがボリュームのプロビジョニングされたスループットパフォーマンスを超えるスループットが記録されるとメトリクスの値が変化します。
これらのメトリクスは、1分間隔 で自動的に収集されます。また値の範囲は、0（超過なし）または 1（超過あり）の2種類です。
Compute Optimizerのレコメンドについて
そしてCompute Optimizer は 5分ごと のメトリクスの最大使用率を使用し、レコメンデーションを作成しています。確認しているメトリクスは以下です。
- 読み取りオペレーション (毎秒)
- 書き込みオペレーション
- 読み込み帯域幅 (KiB/秒)
- 書き込み帯域幅 (KiB/秒)
- バースト残量 (%)
参考：Amazon EBS ボリュームに関するレコメンデーションの表示 - AWS Compute Optimizer
Compute Optimizer のコンソール上にて、これらのメトリクスが確認できます。
つまり、2024/10に追加されたVolumeIOPSExceededCheckとVolumeThroughputExceededCheckは考慮されていません。
また、Compute Optimizerでは 5分ごと のメトリクスの最大使用率を使用、EBS の新規メトリクスでは 1分間隔 で自動的に収集されるというころから、Compute Optimizerの方が粒度が荒いこともわかりました。
そこで困ったこと
今回 Compute Optimizer で検知したリソースのほぼ全てでVolumeIOPSExceededCheck、VolumeThroughputExceededCheckが検知している状況でした。
こちらがあるEBSボリュームに対するグラフです。常時1（超過あり）に張り付いているわけではないですが、一時的なピークで発生しているようでした。
- VolumeIOPSExceededCheck
- VolumeThroughputExceededCheck
よって、このままCompute Optimizer どおりの推奨事項で変更するのはパフォーマンス的にリスクがありそうでした。
どう考えればいいのか？
このような状況を踏まえ、今後の進め方を検討しました。
1. ワークロードの要件を確認
まずはEBSがアタッチされているEC2において、どのようなワークロードが動いているのか用途や要件を以下の点で明確にします。
- ワークロードが短時間の遅延を許容できるか。
- 応答性能が重要なデータベースやリアルタイム処理が含まれているか。
- ワークロードのSLA（サービスレベル合意）やSLO（サービスレベル目標）に影響を与える可能性があるか。
ここで、遅延の許容が難しかったり、SLAやSLOに影響が出そうな場合は費用対効果の面から対応を見送ることも視野に入れましょう。
2. Compute Optimizerの提案を参考に目星をつける
対応1でリソース変更が可能そうとなった場合は、Compute Optimizerのレコメンドを基に、コスト削減の余地が大きいボリュームを特定します。今回であれば、IOPSを9000→3000に削減、スループットを300→285に変更することで、月額$36.720の削減が見込まれるケースが1番削減効果が高いです。
そして、レコメンドがワークロードの要件を満たすかを性能要件などを確認します。
なお、いきなり9000→3000に大きく変更するのではなく、9000→6000→4000など多段階変更のアプローチも有用です。
3. CloudWatchメトリクスで詳細を調査
CloudWatchのVolumeIOPSExceededCheckおよびVolumeThroughputExceededCheckメトリクスを詳細に分析し、以下を確認します。
- メトリクスがトリガーされる頻度とタイミング（例: 一時的なピークか、継続的な問題か）。
- ピーク時のIOPSやスループットが、Compute Optimizerの提案する設定で対応可能か。
継続的に1（超過あり）が検知されている場合は、対応を見送ることも視野に入れましょう。
4. テスト環境での検証
本番環境適用前に、開発環境などで検証できるのであれば、そこでCompute Optimizerの提案を試し、以下を確認します。
- パフォーマンスに問題がないか。
- ワークロードの要件を満たしているか。
5. 変更後のモニタリング
実際に設定を変更した後、CloudWatchを使用して影響を継続的にモニタリングします。
変更後もVolumeIOPSExceededCheckやVolumeThroughputExceededCheckが頻繁にトリガーされ、パフォーマンスに影響が出ている場合は設定を再調整します。
一定期間、1（超過あり）が検知している場合にアラームを設定するのもいいですね。
Amazon CloudWatch でのアラームの使用 - Amazon CloudWatch
6. 優先順位の確認
対応5で特に問題がない場合は、次にコスト削減の効果が大きいボリュームを優先的に最適化します。
一方で、コスト削減効果が小さい（費用対効果が見込めない）場合や、パフォーマンスへの影響が懸念される場合は、変更の優先度を下げることも検討しましょう。
最後に
今回は、Compute Optimizer のEBSボリューム最適化提案をそのまま受け入れていいか検討した内容を共有しました。
Compute Optimizer は大変便利なサービスですが、推奨値通り削減できるか難しいので、慎重に対応を進めていく必要がありますね。
この件は現在進行形で進んでいるため、実際にコスト削減に取り組んだら別ブログで報告したいと思います！
最後までお読みいただきありがとうございました！
以上、おつまみ（＠AWS11077）でした！
