SOAモニタリング、ロギング、分析、修復、およびパフォーマンスの最適化
ある企業のWebアプリケーションは、EC2インスタンス上で稼働しており、定期的にパフォーマンスの低下が報告されています。調査の結果、CPUやメモリの使用率は正常範囲内であるにもかかわらず、ネットワークI/OとディスクI/Oが断続的にスパイクしていることがわかりました。運用チームは、どのプロセスやリソースがこれらのスパイクを引き起こしているかを特定したいと考えています。最も効果的な調査方法はどれですか？
ACloudWatch エージェントに procstat プラグインを設定し、プロセスレベルのメトリクス（CPU・メモリ・I/O）を収集してCloudWatch Metrics で上位プロセスを特定する
✓ 正解
CloudWatch エージェントをインスタンスにインストールし、procstat プラグインを設定してプロセスレベルのメトリクス（CPU・メモリ・ディスクI/O・ネットワーク）を収集し、CloudWatch Metrics でクエリして上位プロセスを特定する
CloudWatch エージェントの procstat プラグインは、OS上の個別プロセスのCPU・メモリ・I/Oメトリクスを収集できます。これにより、どのプロセスがI/Oスパイクを引き起こしているかをプロセス単位で特定できます。
BAWS X-Ray をアプリケーションに組み込み、トレースデータを収集してサービスマップから遅延の発生箇所を特定する
X-RayはアプリケーションレベルのAPM（アプリケーションパフォーマンス管理）追跡に特化しており、プロセス単位の分析には不向きです。
CVPC Flow Logs を有効化してネットワークトラフィックをキャプチャし、Athena でクエリして通信量の多い送信元を特定する
VPC Flow Logsはネットワークフロー記録であり、I/Oの詳細なプロセスレベル分析には対応できません。
DCloudWatch の標準メトリクス（NetworkIn/NetworkOut・DiskReadOps/DiskWriteOps）をより短いグラニュラリティ（1分間隔）で収集し、CloudWatch アラームでスパイクを検知する
CloudWatch標準メトリクスはインスタンス全体集計であり、どのプロセスがI/Oスパイクを引き起こしているかの特定には不向きです。
解説
選択肢AはCloudWatch エージェントの procstat プラグインを使用する方法です。OS上の個別プロセスのCPU・メモリ・I/Oメトリクスをプロセス単位で収集できるため、どのプロセスがI/Oスパイクを引き起こしているかをCloudWatch Metricsで特定できます。
選択肢BはX-RayはアプリケーションレベルのAPM（アプリケーションパフォーマンス管理）追跡に特化しており、OSプロセス単位のI/O分析には不向きです。
選択肢CはVPC Flow Logsはネットワークフローの記録であり、ディスクI/Oや個別プロセスの詳細分析には対応できません。
選択肢DはCloudWatch標準メトリクスはインスタンス全体の集計値であり、どのプロセスがI/Oスパイクを引き起こしているかの特定には不向きです。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →