Compute Optimizer と Trusted Advisor によるパフォーマンス改善
リソース使用率に基づくサイズ適正化提案とTrusted Advisorのパフォーマンス系チェック項目の活用を解説します。
既存システムのパフォーマンス改善は、勘や経験則ではなく、実際の使用率データに基づいて 継続的に行うべきです。本記事では2つの代表的な分析ツールを解説します。
SAA レベル:基礎概念
Compute Optimizerの基本(コスト最適化記事の復習)
- CPU・メモリ使用率等のCloudWatchメトリクスを機械学習で分析し、EC2・EBS・Lambda・Auto Scalingグループの適正なサイズを推奨する
- オーバープロビジョニング(コスト観点)だけでなく、**アンダープロビジョニング(パフォーマンス観点)**の検出にも使われる
SAA 試験のポイント
Compute Optimizerは、1-5のコスト最適化の文脈だけでなく、パフォーマンス問題(CPU使用率が恒常的に高く、レイテンシが悪化している)の解決策としても使われる、両面の価値を持つツールであるという理解がSAAで問われます。
Trusted Advisorの基本カテゴリ
| カテゴリ | 内容 |
|---|---|
| コスト最適化 | アイドルリソース、購入オプションの見直し |
| パフォーマンス | サービスクォータへの近接、過負荷リソースの検出 |
| セキュリティ | 公開されたS3バケット、緩すぎるセキュリティグループ等 |
| 耐障害性 | マルチAZ未設定、バックアップ未設定等 |
| サービスクォータ | 各種上限への近接状況 |
SAP レベル:高度な設計シナリオ
パフォーマンスチェック項目の活用
SAP 試験のポイント
Trusted Advisorのパフォーマンスカテゴリでは、EBSボリュームのIOPS使用率が高すぎる、Auto Scalingグループが最大キャパシティに近づいている、といった将来のボトルネックの予兆を検出します。SAPレベルでは、これらの指摘を放置せず、サービスクォータの引き上げ申請を事前に行う(本番障害が起きてから緊急申請するのではなく)という予防的な運用が問われます。
Compute Optimizerによる継続的なパフォーマンスチューニング
SAP 試験のポイント
「一度サイジングして終わり」ではなく、SAPレベルではアプリケーションの成長やトラフィックパターンの変化に応じて、Compute Optimizerの推奨事項を定期的(例: 月次)にレビューする継続的なチューニングサイクルを運用に組み込むことが求められます。特に、新機能リリース後にアクセスパターンが変化した際は、旧来のサイジングが最適でなくなっている可能性が高い点に注意が必要です。
設計上の落とし穴
「Trusted Advisorのチェック結果をダッシュボードで確認するだけ」という受動的な運用は、SAPレベルでは不十分です。Trusted AdvisorのAPIやEventBridge連携を使い、重要度の高い指摘事項を自動的にチケット管理システムに起票する、または自動修復Lambdaをトリガーする、能動的な運用への統合が問われます。
Enterpriseサポートプランでの追加機能
- Business/Enterpriseサポートプランでは、Trusted Advisorの全チェック項目にアクセスでき、Organizations全体でのチェック結果の集約・API経由でのプログラム的な取得も可能になる
- 大規模組織では、これを自社のダッシュボードやアラート基盤に統合し、独自の運用フローに組み込むことが一般的
まとめ
- SAA: Compute Optimizerがコストとパフォーマンス両面の適正化提案を行うこと、Trusted Advisorの主要カテゴリを理解する。
- SAP: パフォーマンスチェック項目を用いた予防的なクォータ管理、継続的なチューニングサイクルの運用設計ができる。
次は キャッシュ層追加・DB読み取りレプリカ活用を見ていきましょう。