無限ノック › SAP 練習問題一覧 › 問題SAP 既存のソリューションの継続的改善
ある e コマース企業は、単一リージョン内で ALB、Amazon ECS on Fargate、Amazon Aurora（マルチ AZ）による 3 層アプリケーションを本番運用しています。マルチ AZ 構成は取っているものの、設計以来 AZ 障害やインスタンス障害時のフェイルオーバーを一度も実際に検証したことがなく、経営層は「本当に想定どおり復旧するのか」に不安を持っています。要件は、追加リージョンを常時稼働させるような大幅なコスト増を伴わずに、実際の障害挙動を安全かつ反復的に検証し、復旧手順（Runbook）の実効性を継続的に高めることです。最も適切なアプローチはどれですか。
A アプリケーションを 2 つ目のリージョンに複製してアクティブ/アクティブ構成にし、Route 53 のレイテンシールーティングで両リージョンへトラフィックを分散する。両系を常時稼働させることで障害時の切り替え自体を不要にし、検証作業を排除する
マルチリージョンのアクティブ/アクティブは可用性を大きく高めますが、2 リージョンを常時稼働させるためコストが大幅に増加し、「大幅なコスト増を避ける」という明示された制約に反します。
B AWS Fault Injection Service で AZ 停止やタスク終了を模擬する実験テンプレートを作成し、定期的なゲームデーで復旧手順を検証する。CloudWatch アラームを停止条件（ストップコンディション）に設定して安全に実施する
✓ 正解
AWS Fault Injection Service で AZ 停止やタスク終了を制御下で注入し、ゲームデーで復旧手順を反復検証できます。CloudWatch アラームをストップコンディションにすることで本番でも安全に実施でき、コスト増も抑えられます。
C 各コンポーネントに Aurora レプリカと追加 AZ を割り当ててリソースを増強し、CloudWatch Synthetics の外形監視を強化する。フェイルオーバーの挙動は実際の本番障害が発生した際に初めて確認して手順を見直す
Aurora レプリカや追加 AZ による増強と外形監視強化は有効ですが、フェイルオーバーの実挙動を実際の本番障害まで確認しない受動的な姿勢で、安全かつ反復的に検証する要件を満たしません。
D AWS Resilience Hub でアプリケーションの回復性を評価してポリシーとのギャップを可視化し、RTO/RPO のスコアと推奨改善策のレポートを継続的に取得して、改善バックログとして運用チームで管理する
AWS Resilience Hub は回復性ポリシーとのギャップや RTO/RPO スコアを可視化できますが、評価と推奨提示が中心で、障害を注入して実挙動と手順の実効性を検証する行為そのものは行いません。
解説 AWS Fault Injection Service（FIS）はカオスエンジニアリングのマネージドサービスで、AZ 停止・インスタンス/タスク終了・API スロットリングなどの障害を制御された形で注入し、実際のフェイルオーバー挙動と復旧手順を反復的に検証できます。ストップコンディションに CloudWatch アラームを設定することで、影響が閾値を超えた場合に実験を自動停止でき、本番でも安全にゲームデーを実施できます。追加リージョンの常時稼働のような大きなコスト増を伴わずに要件を満たします。
選択肢Aのマルチリージョン アクティブ/アクティブは可用性は最高水準ですが、両系常時稼働でコストが大幅に増え「大幅なコスト増を避ける」要件に反します。
選択肢Cはリソース増強と外形監視強化に留まり、フェイルオーバーの実挙動を実障害まで検証しない点で「安全かつ反復的な検証」要件を満たしません。
選択肢Dの Resilience Hub は回復性の評価とギャップ可視化には有効ですが、それ自体は障害注入による実挙動の検証を行わず、実効性の確認には FIS などのテストが別途必要です。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →