DOPインシデントとイベントへの対応
本番環境のEC2インスタンスが定期的にメモリ枯渇（memory exhaustion）で応答不能になる問題が発生しています。DevOpsチームは以下の自動インシデント対応フローを人手不要で実装したいと考えています。
・CloudWatchカスタムメトリクスでメモリ使用率95%超を3連続期間（period）検出したとき自動実行
・対象インスタンスでプロセス一覧を取得し、診断ログをCloudWatch Logsに記録する
・メモリを消費しているNginxサービスを再起動する
・再起動に失敗した場合のみ、インスタンスを強制再起動（reboot）する
各ステップの実行状況を管理コンソールで可視化でき、実行履歴を監査ログとして残せる実装方法はどれですか？
ACloudWatchアラーム→SNS→Lambda関数をトリガーし、Lambda内でSSM Run Commandを順次呼び出してプロセス取得・ログ記録・Nginx再起動・失敗時リブートを実装する
CloudWatchアラーム→SNS→Lambda関数をトリガーし、Lambda内でSSM Run Commandを順次呼び出してプロセス取得・ログ記録・Nginx再起動・失敗時リブートを実装するアプローチはコードでRun Commandを制御する実装が必要でステップの可視化に追加作業が必要です。
BEventBridgeルールでCloudWatchアラームのALARM状態変化を検知し、onFailure条件分岐付きのSSM AutomationドキュメントでNginx再起動失敗時のリブートまで一元管理する
✓ 正解
SSM Automationドキュメントは複数ステップを定義でき、各ステップにonFailure（失敗時の次アクション）と条件分岐を設定できます。ステップごとの実行状況がAWS管理コンソールで可視化され、実行履歴が自動的に監査ログとして保存される点がLambda（A）より優れています。
CSystems Manager State Managerのアソシエーションを1分間隔で設定し、メモリチェックと自動修復スクリプトをインスタンス上で継続的に実行する
Systems Manager State Managerのアソシエーションを1分間隔で設定し、メモリチェックと自動修復スクリプトをインスタンス上で継続的に実行するアプローチは構成状態の維持向けでアラーム連動のイベント駆動処理には不適切です。
DCloudWatchアラームをAuto Scalingのスケーリングポリシーにリンクし、ALARM発火時に新しいインスタンスを起動して問題のあるインスタンスを自動置換する
CloudWatchアラームをAuto Scalingのスケーリングポリシーにリンクし、ALARM発火時に新しいインスタンスを起動して問題のあるインスタンスを自動置換するアプローチはステートフルアプリには不向きです。
解説
選択肢Bの SSM Automation ドキュメントは複数ステップを定義でき、各ステップに onFailure プロパティで失敗時の次アクションを条件分岐として設定できます。ステップごとの実行状況が管理コンソールで可視化され、実行履歴が監査ログとして自動保存される点が他の選択肢より優れています。
選択肢Aは Lambda 内で Run Command を制御する設計のため、複数ステップの実行状況の可視化には追加実装が必要で、監査ログの自動保存も行われません。
選択肢Cの State Manager は構成状態の維持向けサービスであり、アラーム連動のイベント駆動型インシデント対応には設計上不適切です。
選択肢Dの Auto Scaling によるインスタンス置換はステートフルアプリには不向きで、診断ログ取得・Nginx 再起動・リブートの段階的な修復フローを実行できません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →