DOPインシデントとイベントへの対応
ある金融サービス企業が、us-east-1をプライマリ、ap-northeast-1をセカンダリとするマルチリージョンアクティブ/スタンバイ構成でアプリケーションを運用しています。障害発生時に以下の要件を満たしたいと考えています。
・フェイルオーバー実行前に、セカンダリリージョン（ap-northeast-1）のECSサービス・RDSリードレプリカ・ElastiCache等が実際にトラフィックを受け入れ可能な状態かを継続的に確認する
・フェイルオーバーはエンジニアの判断で手動制御できるようにする（自動フェイルオーバーによるスプリットブレインを防ぐ）
・フェイルオーバーのオン/オフを単一の操作で切り替えられる
この要件を最も適切に満たすサービス・機能はどれですか？
AAmazon Route 53 Application Recovery Controller（ARC）のReadiness Checkでセカンダリリージョンのリソースキャパシティを継続的に監視し、Routing Controlでフェイルオーバーを単一操作で手動制御し自動切り替えを行わない。
✓ 正解
ARCのReadiness Checkは各リソース（ECS・RDS・ElastiCache等）のキャパシティをリファレンスと継続比較し、セカンダリの受け入れ準備状態を確認します。Routing Controlは単一操作でDNSを切り替え、手動制御によりスプリットブレインを防げます。
BRoute 53フェイルオーバールーティングポリシーとヘルスチェックを組み合わせ、プライマリエンドポイントのヘルスチェックが失敗した際に自動的にセカンダリへトラフィックを切り替える。ヘルスチェックの閾値を厳密に設定することでスプリットブレインを防止する。
ヘルスチェック失敗時の自動フェイルオーバーを基本としており、「手動制御でスプリットブレインを防ぐ」要件やセカンダリリソースの継続的な準備確認の要件を満たせません。ARCのReadiness Checkに相当する事前確認機能もありません。
CAWS Global Acceleratorのエンドポイントグループのトラフィックダイヤル（Traffic Dial）設定をCloudWatchアラーム発火時にLambdaで変更し、プライマリリージョンのウェイトを0にすることでトラフィックをセカンダリへ切り替える。
トラフィックダイヤルの操作自体は動作しますが、セカンダリリソースが本番トラフィックを受け入れられるかを事前確認するReadiness Check相当の機能がなく、準備状態監視の要件を満たせません。
DAWS Systems Manager Automationドキュメントを作成して、Route 53レコード更新・RDSフェイルオーバー促進・ECSスケールアップの各ステップを自動化する。インシデント発生時にエンジニアがコンソールからAutomationを手動実行する。
複数ステップを自動化できますが、単一操作での切り替えの実現が難しく、セカンダリの継続的な準備状態を監視する機能もないため要件を完全には満たせません。
解説
Amazon Route 53 Application Recovery Controller（ARC）はマルチリージョンフェイルオーバーの制御に特化したサービスです。Readiness Checkは各リソース（ECS・RDS・ElastiCache等）のキャパシティ設定をリファレンスデプロイと継続的に比較し、セカンダリが本番トラフィックを受け入れられる状態かをリアルタイムで確認します。Routing Controlは単一操作でDNSルーティングを切り替え、複数AZにまたがる高可用性ClusterエンドポイントによりプライマリリージョンのAZ障害時でも確実に操作できます。
選択肢Bはヘルスチェック失敗時の自動フェイルオーバーを基本としており、「手動制御でスプリットブレインを防ぐ」要件や「セカンダリリソースの継続的な準備確認」要件を満たせません。
選択肢Cは技術的に動作しますが、セカンダリリソースが本番トラフィックを受け入れられる状態かを事前確認するReadiness Check相当の機能がなく、要件を完全には満たせません。
選択肢Dは複数ステップの手順を自動化できますが、「単一操作での切り替え」要件の実現が困難であり、セカンダリの継続的な準備状態監視機能がありません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →