理解確認：障害から自動復旧するアーキテクチャの設計

顧客向け APIでデータベース接続障害が発生し、すべてのAPIリクエストがHTTP 500を返している。Amazon EC2 ステータスチェックは正常である。この障害を自動復旧のトリガーとして検出する設計として最も適切なのはどれか。

Application Load Balancerは、あるEC2ターゲットをHTTPヘルスチェック障害によって異常と判定し、トラフィックから除外している。しかし数時間経過してもAuto ScalingグループはそのEC2インスタンスを交換しない。Amazon EC2 ステータスチェックは正常である。最も適切な改善はどれか。

ウェブ階層は複数AZに配置され、ALBとAuto Scalingグループを利用している。1台のEC2でアプリケーション障害が発生したとき、ユーザーリクエストをそのインスタンスへ送らず、希望するキャパシティも自動回復する必要がある。最も適切なアーキテクチャはどれか。

東京リージョンと大阪リージョンにそれぞれApplication Load Balancerがあり、東京をプライマリ、大阪をセカンダリとする。プライマリALB配下の対象がすべて利用不能になった場合も、人手を介さずセカンダリへDNSフェイルオーバーしたい。最も適切な構成はどれか。

Amazon Route 53のヘルスチェック間隔を10秒に設定したため、アーキテクトは「エンドポイント障害から10秒後には、すべてのクライアントが必ずセカンダリへ接続する」と説明した。最も適切な評価はどれか。

EC2 Auto Scalingグループで新インスタンスを起動すると、アプリケーション起動に約3分かかる。しかしヘルスチェックが起動直後から失敗し、インスタンスが準備完了になる前に異常として交換され続けている。最も適切な改善はどれか。

企業は2つの可用性ゾーンでウェブアプリケーションを運用し、別リージョンにも復旧環境を持っている。アプリケーション障害が発生したEC2へ新規トラフィックを送らず、壊れたEC2を自動交換し、1つのAZを失っても正常キャパシティでサービスを継続し、プライマリリージョン全体が利用不能ならセカンダリリージョンへ自動切替する必要がある。適切な設計を4つ選択してください。

すべてのウェブインスタンスの /health が外部決済APIへ接続し、決済APIが一時的に失敗すると全インスタンスが同時に異常になる設計になっている。その結果、Auto Scalingが正常なインスタンスまで大量交換している。最も適切な改善はどれか。

現在のAWSの正常性ベースのルーティング / ロードバランシングの障害モードについて正しいものを3つ選択してください。

プライマリリージョンで短いネットワーク遅延が断続的に発生しており、ヘルスチェックが正常 / 異常を頻繁に往復してプライマリとセカンダリの切り替えを繰り返している。最も適切な改善はどれか。

自動復旧アーキテクチャにおける自己修復とフェイルオーバーの責任差として最も適切なのはどれか。

フェイルオーバールーティングを使用する公開APIで、プライマリエンドポイント障害時の切り替えを設計している。DNS TTLは60秒だが、障害検出をDNSクエリ到着時だけに依存させたくない。Route 53のエンドポイントヘルスチェックの動作として最も適切な説明はどれか。