SOAモニタリング、ロギング、分析、修復、およびパフォーマンスの最適化
ある企業は共有テナンシーのEC2インスタンス上でビジネスクリティカルなアプリケーションを運用しています。ハードウェア障害によるシステムステータスチェック失敗(StatusCheckFailed_System)が月に数回発生しており、都度オペレーターが手動でインスタンスを停止・起動する対応をとっています。インスタンスのプライベートIPアドレス・Elastic IP・EBSボリュームを維持したまま、最も少ない手順で自動回復する仕組みはどれか?
AEC2 Auto ScalingグループにEC2ヘルスチェックを設定し、システムステータスチェック失敗時に異常インスタンスを終了して起動テンプレートから新しいインスタンスを自動起動するよう構成する
Auto Scalingによる代替インスタンス起動では新しいインスタンスIDが付与されるため、Elastic IPの再関連付けやプライベートIPの変更が発生します。インスタンス属性を維持しながら回復する要件を満たしません。
BSystems Manager Automation ドキュメント「AWSSupport-RestartEC2Instance」をEventBridgeルールでStatusCheckFailed_Systemイベントに紐付け、ハードウェア障害時に自動再起動するワークフローを設定する
Systems Manager AutomationによるEC2再起動は、ハードウェア障害でホストが応答不能な状態ではコマンドが到達しないことがあります。ハードウェア移行を伴うEC2回復アクションほど適切ではありません。
CCloudWatchアラームでStatusCheckFailed_Systemメトリクスを監視し、アラームアクションに「このインスタンスを回復する(Recover)」を設定する
✓ 正解
EC2回復アクションはCloudWatchアラームのネイティブ機能で、StatusCheckFailed_System発生時にAWSが別ホストへインスタンスを自動移行します。プライベートIP・Elastic IP・EBSアタッチメントがすべて保持され、設定手順が最小です。
DCloudWatch エージェントをインスタンスにインストールしてステータスメトリクスを収集し、Lambda関数がアラームをトリガーとしてEC2 Stop/Start APIを呼び出す自動化を構築する
CloudWatchエージェント+Lambda+Stop/Start APIの組み合わせは実現可能ですが、エージェント設定・Lambda実装・IAMロール設定など複数の手順が必要で、EC2回復アクションより運用負荷が大幅に高くなります。
解説
CloudWatchアラームのEC2回復アクション(Recover Action)は、StatusCheckFailed_Systemが発生した際にAWSが自動的に別の正常なハードウェアへインスタンスを移行させる機能です。回復後もインスタンスID・プライベートIPアドレス・Elastic IP・EBSボリュームアタッチメント・セキュリティグループなどがすべて保持されます。共有テナンシーのインスタンスで利用可能で、コンソールまたはCloudFormationから数ステップの設定のみで完結します。追加コードやサービスは不要です。
選択肢AのAuto Scalingは新しいインスタンスIDで代替インスタンスを起動するため、Elastic IPの再関連付けが必要になりプライベートIPも変わります。インスタンス属性を維持する要件を満たしません。
選択肢BのSystems Manager Automationによる再起動は、ハードウェア障害でホストが応答不能な状態では再起動コマンドが到達しないケースがあり、ハードウェア移行を伴うRecoverアクションより適切ではありません。
選択肢DのLambdaによるStop/Start APIは機能しますが、CloudWatchエージェント設定・Lambda実装・IAMロール設定など複数の手順が必要で、最も少ない手順という要件を満たしません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →