SOAモニタリング、ロギング、分析、修復、およびパフォーマンスの最適化
ある企業は、EC2インスタンス上でメモリを大量に消費するバッチ処理アプリケーションを運用しています。まれにメモリ不足でアプリのプロセスがハングし、手動でサービスを再起動するまで処理が停止します。運用チームはCloudWatchエージェントでメモリ使用率のカスタムメトリクスを収集済みです。人手を介さずに、メモリ使用率が閾値を超えた場合へアプリケーションプロセスを自動で再起動させたいと考えています。最も自動化された方法はどれですか。
Aメモリ使用率のCloudWatchアラームをトリガーにEC2の自動復旧（Auto Recovery）アクションを設定し、同一インスタンスを再起動してプロセスを復帰させる
EC2の自動復旧はシステムステータスチェック失敗（基盤ハードウェアの問題）を契機にインスタンスを再起動する機能で、OSは動作したままメモリ枯渇でアプリプロセスがハングするケースには反応せず、プロセス再起動もできません。
Bメモリ使用率のCloudWatchアラームをAuto Scalingグループのスケールインポリシーに関連付け、対象インスタンスを終了して新規インスタンスに置き換える
スケールインは対象インスタンスを終了して新規に置き換える動作のため、実行中のバッチ処理の状態が失われ、単にプロセスを再起動したいという要件に対して過剰かつ不適切です。復旧というより破棄・再作成になります。
Cメモリ使用率のCloudWatchアラーム状態変化をEventBridgeで受け、Systems Manager AutomationランブックからRun Commandで該当サービスを再起動する
✓ 正解
アラームの状態変化をEventBridgeで受けてSSM Automationランブックを起動し、Run Commandでインスタンス内の該当プロセスのみを再起動できます。インスタンスを置き換えずにサービスを復旧でき、手順をランブックで管理でき人手を介さない自己修復が完結します。
DCloudWatchエージェントの設定でメモリ使用率が閾値を超えたら自動でプロセスを再起動するローカルアクションを有効化し、SSM State Managerで構成を維持する
CloudWatchエージェントはメトリクスやログの収集を担うエージェントで、メトリクス閾値超過を契機にプロセスを再起動するローカルアクション機能は備えていません。State Managerで維持しても実行する再起動処理自体が存在しません。
解説
CloudWatchアラームの状態変化イベントをEventBridgeルールで捕捉し、ターゲットにSystems Manager Automationランブックを指定すれば、ランブックからRun Command（AWS-RunShellScriptなど）を実行して対象インスタンス上のアプリケーションプロセスだけを再起動できます。
インスタンスを終了・再作成せずにサービスを復旧でき、人手を介さない自己修復（セルフヒーリング）が完結します。ランブックで再起動手順や確認処理を一元管理できる点も運用上有利です。
選択肢のEC2 Auto Recoveryは、システムステータスチェック失敗（基盤ハードウェア障害）に対する復旧機能で、メモリ枯渇によるアプリのハングには反応しません。
選択肢のAuto Scalingスケールインは、インスタンスを終了して置き換える動作で、実行中バッチの状態を失い過剰です。
選択肢のCloudWatchエージェントには、閾値超過でプロセスを再起動するローカルアクション機能自体が存在しません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →