SOA信頼性とビジネス継続性
ある金融機関はWebアプリケーションをus-east-1(プライマリ)とus-west-2(セカンダリ)のActive-Standby構成でRoute 53フェイルオーバールーティングにより運用しています。
以前の障害では、データベース層のみが停止してALBは正常な「部分的障害」をRoute 53のHTTPヘルスチェックが検出できず、手動のDNSレコード変更に20分かかりました。
次回の障害時に5分以内かつ確実にトラフィックをセカンダリリージョンへ切り替えられる仕組みを導入したいと考えています。最も適切な対策はどれですか?
ARoute 53ヘルスチェックの評価間隔を30秒から10秒に短縮し、連続失敗回数を3回から1回に変更して障害検知を高速化する
ヘルスチェックの感度を上げても、DBのみ停止してALBが正常なHTTP 200を返し続ける部分的障害はRoute 53が検出できません。ヘルスチェックのエンドポイントとDB健全性を連動させない限り根本的な解決になりません。
BCloudFrontのオリジンフェイルオーバーを設定し、プライマリALBが5xx応答を返した際にus-west-2のALBへ自動切り替えする
CloudFrontオリジンフェイルオーバーはHTTP 5xx応答をトリガーとしますが、DBが停止してもALBが独自のエラー画面(HTTP 200)を返す場合はフェイルオーバーが発動せず、本シナリオの部分的障害には対応できません。
CRoute 53 ARCのルーティングコントロールを設定し、障害時にコンソール・APIからスイッチ操作でトラフィックをセカンダリへ切り替える
✓ 正解
Route 53 ARCのルーティングコントロールはヘルスチェックの結果に依存せず、オペレーターの明示的なスイッチ操作でトラフィックを切り替えます。レディネスチェックでセカンダリの準備状態を事前確認できるため、確実かつ5分以内のフェイルオーバーが実現できます。
DAWS Global Acceleratorに両リージョンのエンドポイントグループを設定し、ヘルスチェックに基づきトラフィックをus-west-2へ自動移行する
Global Acceleratorはエンドポイントのヘルスチェックに基づく自動切り替えを行いますが、ALBが正常とみなされる部分的障害では自動フェイルオーバーが発動しません。明示的な操作によるフェイルオーバー制御にはRoute 53 ARCが適しています。
解説
Route 53 Application Recovery Controller(ARC)は、マルチリージョンアプリケーションの信頼性の高いフェイルオーバーを実現するサービスです。ルーティングコントロール機能を使うと、トラフィックの切り替えをヘルスチェックの自動検知に依存するのではなく、オペレーターが明示的にコントロールスイッチを操作(コンソール・API・CLI)して実行できます。また、レディネスチェック機能によりセカンダリリージョンがトラフィックを受け入れられる状態かを事前に継続的に検証できます。DBのみ停止しALBが正常応答を続ける部分的障害でも確実にフェイルオーバーを実行でき、操作は数分以内で完了します。
選択肢AのRoute 53ヘルスチェックの調整は、ALBが正常にHTTP 200を返し続ける部分的障害(DBのみ停止)を検出できないため、根本的な解決にはなりません。
選択肢BのCloudFrontオリジンフェイルオーバーはHTTP 5xxエラーコードをトリガーとするため、DBが停止してもALBが別の応答を返し続ける場合は機能しません。
選択肢DのGlobal Acceleratorも同様にヘルスチェックに基づく自動切り替えであり、ALBが正常とみなされる部分的障害では自動フェイルオーバーが発動しません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →