プロンプトとユースケース
これはマルチリージョンの可用性に関する設計問題です。有益な回答では、トラフィック決定、ヘルスシグナルの伝播、障害時のキャパシティおよびデータの境界、そしてフェイルオーバーとフェイルバックがどのようにリハーサルされるかを説明します。
面接官が評価するポイント
- DNS、エッジプロキシ、アプリケーションルーティングに明確な責任分担とタイムスケールがあるか。
- ヘルス判定が単一のエンドポイントではなく、複数のオブザーバーからの階層化されたシグナルを使用しているか。
- フェイルオーバーのキャパシティ、接続数、レート制限が計算されているか。
- ステートフルなデータに対して、明示的な書き込み所有権、レプリケーション遅延、リージョン制約が設定されているか。
- スプリットブレイン、フラッピング、フェイルバック時の連鎖障害が制御されているか。
- RTO、RPO、SLO、および訓練の実績エビデンスが定義されているか。
回答前の確認事項
- どのリージョン、トラフィックピーク、単一リージョン障害モデルが適用されるか？
- RTO、RPO、データレジデンシー、コンプライアンスの制約は何か？
- リクエストは主にステートレスな読み取りか、それとも書き込みや長時間接続が含まれるか？
- ステアリングはDNS、Anycast、エッジプロキシ、サービスメッシュのいずれで行われるか？
- ヘルスチェックはどのユーザージャーニーと依存関係をカバーする必要があるか？
- クライアントのDNS TTL、接続移行、フェイルバックウィンドウは何を要求しているか？
30秒回答フレームワーク
「まずリージョン障害、ピーク負荷、RTO/RPOを定義します。DNSまたはエッジエントリポイントはレイテンシーに基づく候補を選択できますが、トラフィックを受信できるのは階層化されたヘルスチェックに合格し、予備キャパシティがあるリージョンのみです。過負荷時には、バックアップリージョンが維持されるよう、優先順位に基づいてレート制限と機能縮退を行います。書き込みは、明示的なレプリケーション遅延とリトライセマンティクスを備えたデータ所有権境界に従います。ダンピング（減衰）コントローラーが徐々に重みをシフトし、フェイルバック前にはリハーサル、ウォームアップ、メトリクスの検証を実施します。」
ステップバイステップの詳細解説
ステップ1：障害と目標を定義する。 リージョン、依存関係、ネットワーク、コントロールプレーンの障害範囲を明示し、RTO、RPO、ピーク、縮退レベルを定量化します。
ステップ2：決定レイヤーを分離する。 DNSまたはグローバルエントリポイントがおおまかなリージョン選択を処理し、エッジまたはサービスレイヤーがライブの重み、接続、ローカル制限を処理します。1つのコントロールプレーンにすべての障害対応を担わせてはなりません。
ステップ3：ヘルスシグナルを構築する。 複数拠点からのプローブ、重要なユーザージャーニー、依存関係の状態、エラー率、キャパシティを組み合わせます。連続ウィンドウ、復旧ウィンドウ、クォーラムのような決定により、フラッピングを低減します。
ステップ4：キャパシティを保護する。 フェイルオーバー用のヘッドルームを確保し、リージョンごとの並行性、キュー、レート制限を設定します。障害発生時は、クリティカルなトラフィックが連鎖障害を引き起こす前に、優先度の低い処理を破棄（shed）します。
ステップ5：データの境界を定義する。 レプリカ遅延、書き込み所有権、競合処理、冪等性キー、クロスリージョンリトライを説明します。ルーティングによって利用不可な書き込みの整合性を取ることはできません。
ステップ6：フェイルオーバーを実行する。 コントローラーは理由、バージョン、承認を記録し、障害が発生したリージョンの重みを下げ、拡大する前に少量のコホートをシフトします。長時間接続にはバックオフとセッション復旧が必要です。
ステップ7：フェイルバックをリハーサルする。 復旧したリージョンをウォームアップし、安定したメトリクスとデータ検証を確認した上でフェイルバックします。リージョン、依存関係、コントロールプレーンの障害を定期的に注入し、測定されたRTO/RPOのエビデンスを保持します。
質の高い模範解答
「各リージョンをエントリレイヤー、ステートレスサービス、データユニットに分割します。グローバルエントリポイントがレイテンシー候補を選択しますが、リージョンがトラフィックを受信するのは、複数拠点からのジャーニーチェック、エラー閾値、キャパシティヘッドルームをクリアした場合のみです。コントローラーは最小滞在時間とクールダウンを適用し、まず5%をバックアップに送信します。バックアップの並行性が上限に達した場合、低優先度のレポートを一時停止しつつログインと書き込みを保護します。テナントの所有権が書き込み場所を決定し、クロスリージョンリトライは冪等性キーを付与してレプリケーション遅延を考慮します。訓練によって、フェイルオーバーとフェイルバックの両方でRTO、RPO、再接続の成功率、データ検証を確認します。」
よくある間違い
- DNSと2つのリージョンのみを描く → キャパシティとデータが欠落している → コントローラーのガードレールと書き込み所有権を追加する。
- 1回のプローブ失敗でリージョンを切り離す → トラフィックがフラッピングする → ウィンドウ、クールダウン、複数のシグナルを使用する。
- バックアップがすべてのトラフィックを受け入れられると思い込む → フェイルオーバーで過負荷になる → ヘッドルームと段階的な縮退を計算する。
- TTLを完了時間として扱う → クライアントが古い応答をキャッシュし続ける → リゾルバ、接続、エッジの遅延を含める。
- 競合ルールなしでアクティブ/アクティブと述べる → 書き込みが未定義になる → 所有権、レプリケーション、冪等性を明記する。
フォローアップの質問と回答
フォローアップ1：DNS TTLが長い場合はどうしますか？
エッジを使用して重みの変更をより迅速に行い、TTL、再帰キャッシュ、接続ライフタイムをRTOバジェットに含めます。即時移行を前提にしてはなりません。
フォローアップ2：ヘルスチェック自体が失敗した場合はどうしますか？
独立した制御パスと複数拠点からのプローブを使用し、鮮度を追跡し、チェックが期限切れになった場合は最後の安全な状態を維持するか、保護された手動モードに移行します。
フォローアップ3：バックアップのキャパシティが不十分な場合はどうしますか？
キャパシティを確保してウォームアップしておき、優先度に応じてレート制限、縮退、またはキューイングを行います。負荷テストによって単一リージョンの上限を証明します。
フォローアップ4：フラッピングをどのように防ぎますか？
障害用と復旧用で異なる閾値、最小滞在時間、クールダウン、承認を使用し、重みの変更ごとに理由を記録します。
フォローアップ5：リージョン間の書き込み競合をどのように処理しますか？
テナントまたはキーごとに所有権を割り当て、バージョンまたは冪等性条件を使用します。マルチライターが必要な場合は、競合ルールとマージ不可能なデータを定義します。
フォローアップ6：正常に動作することをどのように証明しますか？
リージョン、依存関係、ネットワーク、コントロールプレーンの障害訓練を実施し、RTO、RPO、エラー、復旧キャパシティ、再接続、データチェックを測定します。
フォローアップ7：マルチリージョンを避けるべきなのはどのような場合ですか？
データレジデンシー、レプリケーションセマンティクス、運用能力、またはコストが目標を満たせない場合は、まずディザスタリカバリを備えた検証済みの単一リージョン設計を採用してください。マルチリージョンは自動的な選択肢ではありません。