システムデザイン面接：マルチリージョンフェイルオーバーコーディネーターの設計

質問とそれが適用される場面

リージョンの健全性を評価し、ルールが満たされたときにトラフィックを切り替え、復旧後にトラフィックを安全に戻すコーディネーターを設計します。コントロールプレーンとデータプレーン、シグナル、データ状態、承認、監査、訓練について説明してください。

AWS ARCはルーティングコントロールを信頼性の高いデータプレーンスイッチとして説明し、ディザスタ発生時にもフェイルオーバーメカニズムが動作しなければならないことを強調しています。Kubernetesはレプリカ、トポロジ分散、ディスラプションバジェットに焦点を当てています。Amazonのソフトウェア面接のトピックでは、知識を適用してシステム問題を解決することが重視されます。

これはマルチリージョンAPIゲートウェイの設計とは異なります。焦点は、偽陽性、スプリットブレイン、データの追いつき（キャッチアップ）、フェイルバックを含む、判断と復旧のワークフローにあります。

面接官が見ているポイント

複数シグナルによる健全性、耐障害性のあるルーティング制御、明確なRTO/RPOとレプリケーション、同時並行の決定を防ぐフェンシング、監査可能性、訓練、そして測定可能なフェイルバック計画が求められます。

回答前に確認すべき質問

• RTO、RPO、可用性、手動介入の目標はどのようなものですか？
• 障害はリージョンの到達性、依存関係、レイテンシ、デプロイ、データ破損のどれによるものですか？
• スタンバイはホット、ウォーム、コールドのどれですか？
• どのデータがレプリケーションされ、どの書き込みが拒否される可能性がありますか？
• DNS、ゲートウェイ、Anycast、またはクライアントはどのように新しいルーティングを受信しますか？
• 自動化が失敗した場合、誰が引き継ぐことができますか？
• 二重書き込みはどのように防止されますか？
• フェイルバックのゲートとなる健全性とキャッチアップの条件は何ですか？
• スコープは特定の単一クラウドですか、それとも抽象的な設計ですか？

30秒の回答フレームワーク

「まずRTO、RPO、スタンバイの準備状態を定義します。各リージョンは独自のデータプレーンを実行し、コーディネーターは検証済みのルーティング状態のみを公開します。健全性は、ビジネスプローブ、依存関係、キャパシティ、レプリケーションラグをクォーラムのようなシグナルおよびダンペニング（変動抑制）と組み合わせて判定します。切り替え前に、書き込みをフェンシングまたは縮退させ、スタンバイのデータ閾値を検証し、高可用なルーティング制御を使用します。すべての状態変更は監査可能で可逆的です。フェイルバックは健全性とデータのキャッチアップを待ってから、少量のトラフィックから開始します」

詳細な回答（ステップバイステップ）

ステップ1：障害モデルと目標を定義する

ゾーン障害、リージョン分断、依存関係の障害、不正なデプロイ、データ破損を区別します。RTO/RPOをスタンバイのコスト、レプリケーション、自動化に対応付けます。

ステップ2：コントロールプレーンとデータプレーンを分離する

データプレーンはリクエストを処理し、ルーティングを実行します。コントロールプレーンは推奨事項、承認、記録を計算します。フェイルオーバーの実行が、利用不可となったコントロールプレーンに依存してはなりません。

ステップ3：健全性判定を構築する

ビジネスの成功率、依存関係、レイテンシ、レプリケーションラグ、キャパシティ、オペレーターのシグナルを組み合わせます。1回のプローブ失敗で候補（candidate）状態となり、閾値が持続することでワークフローが進みます。

ステップ4：安全な切り替えを実行する

準備完了（ready）、候補（candidate）、承認済み（approved）、切り替え中（switching）、安定（stable）、フェイルバック（failback）などの状態を使用します。リースまたはフェンシングバージョンによって同時並行の操作を防ぎます。書き込みフェンシング、最大切り替え時間、停止アクションを定義します。

ステップ5：一貫性とスプリットブレインに対処する

単一ライター、グローバルシーケンシング、または競合解決を選択します。分断中は、両方のリージョンでマージできない書き込みを受け入れるのではなく、安全でない書き込みを拒否します。カットオーバーポイントとデータのギャップを記録します。

ステップ6：ルートを伝播しキャパシティを保護する

TTL、キャッシュ、クライアントのリトライを含め、DNS、ゲートウェイ、またはエッジでの伝播を説明します。スタンバイのキャパシティをウォームアップし、スロットリングと縮退モードを定義します。

ステップ7：オブザーバビリティ、監査、ハンドオーバー

健全性の証拠、ルールバージョン、オペレーター、状態遷移、ルート結果を記録します。切り替え時間、エラー、ラグ、キャパシティ、二重書き込みの兆候についてアラートを発報します。手動アクションは承認され、冪等である必要があります。

ステップ8：訓練と安全なフェイルバック

障害を注入し、段階的なトラフィックをテストします。フェイルバックの前に、プライマリの健全性、データの追いつき、依存関係の安定性、キャパシティを検証します。最初は少量のパーセンテージを移行し、迅速なリバート手段を確保しておきます。

高品質な回答例

「単一ライター構成の2つのリージョンで、5分のRTOと30秒のRPOを持つ設計にします。両方のリージョンが完全なデータプレーンを持ち、スタンバイはウォームキャッシュとキャパシティを維持します。

健全性は、ビジネスの成功率、依存関係、レプリケーションラグ、キャパシティを組み合わせて判定します。3回連続で不良ウィンドウが発生するとcandidateになります。リースと単調増加するフェンシングバージョンにより、1つのコーディネーターのみが状態を進めることができます。切り替え前に書き込みがフェンシングされ、スタンバイのラグがチェックされ、高可用なルーティング制御によってトラフィックが移動されます。エラーとレイテンシが監視され、即時リバートの閾値が設定されます。

監査では、証拠、ルール、承認、ルーティング結果が保存されます。毎月の訓練で、DNSキャッシュ、クライアントのリトライ、スタンバイキャパシティをテストします。フェイルバックはデータの追いつきを待ち、まず5パーセントを移行し、二重書き込みやレイテンシが発生した場合は停止します」

よくあるミス

• 決定の責任者（オーナー）を決めずに2つのリージョンを提示すること。
• 単一のpingやインフラメトリクスをビジネスの健全性として使用すること。
• フェンシング、ダンペニング、承認、リバート手段なしで自動化すること。
• TTL、キャッシュ、クライアントのリトライを無視すること。
• 競合処理なしに二重書き込みを許可すること。
• スタンバイのウォームアップとキャパシティを忘れること。
• フェイルオーバーについて説明しても、フェイルバックや訓練について触れないこと。
• レプリケーションやコストとのマッピングなしにRTO/RPOを述べること。

フォローアップ質問と回答方法

フォローアップ1：偽陽性にはどのように対処しますか？

複数のシグナル、持続的なウィンドウ、ダンペニングを使用します。信頼性の低い障害の場合は、切り替える前に監視または縮退を行います。

フォローアップ2：コントロールプレーンがダウンした場合はどうしますか？

実行スイッチと必要な読み取りを高可用なデータプレーン上に維持し、安全な状態を事前に配布して、監査された手動操作を制限します。

フォローアップ3：両方のリージョンがプライマリになった場合はどうしますか？

リース、フェンシングトークン、または外部アービターを使用します。単一ライターの所有権が不確実な場合は、書き込みを拒否します。

フォローアップ4：スタンバイのキャパシティが不足している場合はどうしますか？

キャパシティを予約し、縮退やスロットリングを使用し、全負荷を処理できない場合はクリティカルなトラフィックのみを受け入れます。

フォローアップ5：すべてを自動化しないのはなぜですか？

可逆的で信頼性の高い障害を自動化します。破損、スプリットブレイン、信頼性の低いイベントについては、人間の確認を必須とします。

フォローアップ6：訓練が機能していることをどのように証明しますか？

検知から復旧までの時間、RPO、エラー、キャパシティ、手動ステップ、リバート結果を追跡し、見つかったギャップを責任者が割り当てられた改善タスクに変換します。