無限ノック › SOA 練習問題一覧 › 問題SOA モニタリング、ロギング、分析、修復、およびパフォーマンスの最適化
ある企業は、ALBの背後にあるEC2 Auto Scaling グループでWebアプリケーションを運用しています。ときどきインスタンス内のNginxプロセスが停止し、ALBのターゲットが異常判定となって一部リクエストが失敗します。インスタンス自体は正常なため、担当者は「異常ホスト数」のアラーム発生時にNginxを自動で再起動して復旧させたいと考えています。最も自動化された方法はどれですか。
A UnHealthyHostCount のCloudWatchアラームをEventBridge のアラーム状態変更イベントに接続し、Nginx再起動用のRun Commandを実行するSystems Manager Automation ランブックをターゲットに設定する
✓ 正解
アラームの状態変更をEventBridgeで受けてSSM Automationランブックを起動し、Run CommandでNginxを再起動すれば、インスタンスを維持したままイベント駆動で自動復旧できる。人手不要で最も自動化された修復方式。
B UnHealthyHostCount のアラームがALARM状態になったらAuto Scaling の簡易スケーリングポリシーを起動し、グループ内のインスタンスを終了して新しいインスタンスに置き換える
インスタンスの置き換えは、プロセスが停止しただけの一時障害に対して過剰な対応となる。正常なインスタンスを終了し新規起動のプロビジョニング時間も要するため、局所復旧より復旧が遅く無駄が多い。
C Nginxプロセスを監視するcronジョブを各インスタンスに配置し、停止を検知したらローカルスクリプトでNginxを再起動するよう手動でセットアップする
各インスタンスへのcronとスクリプトの手動配置は、配布や更新の保守が煩雑で一元管理できない。SSMによる集中管理と比べて運用負荷が高く、自動化の観点で最善ではない。
D Route 53 のヘルスチェックでNginxのエンドポイントを監視し、異常時にフェイルオーバールーティングで別リージョンのスタックへ切り替える
Route 53のフェイルオーバーはリージョンやスタック単位の切り替えを行う仕組みで、単一プロセスの再起動という局所的な修復には粒度が大き過ぎる。過剰な構成であり要件に合わない。
解説 CloudWatchアラームの状態変更はEventBridgeのイベントとして捕捉でき、これをトリガーにSystems Manager Automation ランブックを起動できます。ランブック内からRun Commandを呼び出せば、対象インスタンス上でNginxの再起動コマンドを実行して自動復旧でき、人手を介さずインスタンスを維持したまま最小の操作で修復が完結します。
選択肢Bのインスタンス置き換えは、プロセス停止という一時障害に対して過剰で、正常なインスタンスを終了して起動時間もかかるため復旧が遅く非効率。
選択肢Cのcron＋手動セットアップは、各インスタンスへの配布・保守が必要で自動化・一元管理の観点で劣る。
選択肢Dの Route 53 フェイルオーバーは、単一プロセス障害の局所復旧ではなくリージョン単位の切り替えであり、要件に対して過大かつ復旧手段として不適切。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →