問題とスコープ
3つのリージョンにまたがる2,000の論理サービスと100,000の動的インスタンスを対象とした、社内向けサービスディスカバリシステムを設計します。コンテナの再スケジューリング、オートスケーリング、ローリングデプロイにより、アドレスは継続的に変化します。大規模なデプロイでは、2分間に10,000個のエンドポイントが置き換わる可能性があります。呼び出し側は複数の言語を使用しているため、すべてのチームに高度なディスカバリSDKの保守を求めることはできません。
この問題では2つのデッドラインが区別されます。コントロールプレーンがインスタンスの意図的なサービス離脱遷移を検知した後、その検知から新規トラフィックの停止までのp99は最大3秒です。プロセスやノードが予告なく消失した場合、ハード障害検出のp99は最大15秒です。ディスカバリのコントロールプレーンが10分間停止している間も、既存の呼び出しは最後に認識されたエンドポイントを使用して継続する必要があります。ただしこれは、停止中に新しいインスタンスが可視化されたり、キャッシュされたインスタンスが生存し続けたりすることを意味するわけではありません。
サービス数、インスタンス数、リージョン数、デプロイ規模、およびSLOは面接における前提条件です。スコープには、登録、リース、ヘルス状態、エンドポイントのクエリと差分配信、キャッシュ、ドレイン（draining）、マルチリージョン動作、および検証が含まれます。リクエストの負荷分散はディスカバリが必要とする範囲でのみ扱い、ビジネスAPI、完全なサービスメッシュデータプレーン、パブリックDNSはスコープ外とします。コアタスクがコントロールプレーン、プロキシ、ヘルスシグナル、エンドツーエンドのトラフィック動作にまたがるため、これはsystem-designです。
面接官が評価するポイント
第1のシグナルは、登録、ディスカバリ、ヘルス判定、ルーティングの分離です。レジストリは「誰がどこで実行されていると主張しているか」を記録します。ヘルスロジックは「インスタンスが今トラフィックを受信すべきか」を判断します。ディスカバリは候補を呼び出し側に配信します。プロキシまたはクライアントが候補を1つ選択します。これら4つすべてを単一のデータベースとして描くと、伝播レイテンシや障害境界が見落とされてしまいます。
第2のシグナルは、コントロールプレーンとデータプレーンの分離です。すべてのビジネスリクエストがレジストリに同期クエリを実行すると、レジストリの遅延がサイト全体の停止につながります。優れた設計では、プロキシ内にバージョン管理されたスナップショットを保持し、バックグラウンドで変更を受信します。コントロールプレーンの障害時、データプレーンは最後に認識されたセットを使用し、短い接続タイムアウト、制限されたリトライ、パッシブなローカル退避によって古いエンドポイントを処理します。
第3のシグナルは、ディスカバリ情報が常に古くなり得ることを認識しているかです。DNSのTTL、プロキシキャッシュ、ウォッチの遅延、障害検出、ローリングシャットダウンによってタイムラグが生じます。優れた回答では、どのイベントが各クロックを開始するかを定義し、意図的な離脱とハード障害に個別のSLOを割り当て、プローブの間隔、閾値、伝播を予算化します。「強力な整合性によって停止したインスタンスへの呼び出しを防ぐ」という考えは、ネットワーク分断や読み取り直後のインスタンス障害を無視しています。
最後に、面接官はスケールと運用上の判断力を確認します。100,000のインスタンスが10秒ごとに直接リースを更新すると、ロールアウトの変更やウォッチのファンアウトが発生する前から、レジストリは毎秒10,000件の更新を受信します。単にConsul、etcd、Kubernetesの名前を挙げるだけでなく、書き込み増幅、再接続ストーム、フルスナップショット、リージョンごとの障害ドメイン、不正なヘルスチェックを抑え込む設計が求められます。
回答前に確認すべき明確化のための質問
- 登録情報の信頼できる情報源（Source of Truth）は何か？ オーケストレータがPodのライフサイクルを管理している場合、コントローラが登録を生成すべきです。ワークロードIDを持つローカルエージェントは、VMや外部プロセスを登録できます。認証されていない自己登録を許可すると、カタログが汚染されます。
- 3秒のクロックはいつ開始するか？ ここでは、コントロールプレーンがREADYからDRAININGまたはnot-readyへの遷移を受け入れた時点で開始します。アプリケーションが報告前にフリーズした場合、ハード障害検出の担当となります。
- 15秒の目標において、誤検知による削除はどの程度許容されるか？ 3回連続の失敗により一時的なパケットロスによるエラーは削減されますが、5秒の間隔にタイムアウトを加えると予算のほぼすべてを消費します。パッシブなエラー率、リージョンの予備容量、確認ウィンドウによって選択肢が変わります。
- 呼び出し側にはインスタンスのアドレスが必要か、それとも安定したサービスアドレスが必要か？ 安定したVIPに対しては、DNSとプラットフォームのロードバランシングの組み合わせが最もシンプルです。呼び出し側がバージョン、リージョン、シャードのメタデータを必要とする場合は、プロキシまたはクライアントサイドディスカバリの方が適しています。
- コントロールプレーンの障害時はフェイルオープンかフェイルクローズか？ 通常の内部サービスは、最後に認識されたスナップショットから継続できます。セキュリティの失効や厳格な分離は、古いディスカバリキャッシュに依存できません。独立した認証・認可レイヤーがそれらを拒否する必要があります。
- 自動的なクロスリージョンフェイルオーバーは許可されるか？ ステートレスな読み取りはポリシーによってフェイルオーバー可能です。データレジデンシー、単一ライター状態、または高いクロスリージョンコストがある場合は、ターゲットセットを明示的に制限する必要があります。
30秒の回答
「リージョナルなコントロールプレーンとローカルなデータプレーンを構築します。オーケストレータまたは認証されたエージェントが、STARTING、READY、DRAINING、UNHEALTHY、EXPIREDの状態を持つシャード化されたカタログにインスタンスを書き込みます。ルーティング可能なのはREADYのみです。正常なシャットダウンでは、接続がドレインされる前にDRAININGに入ります。リージョンリーダーが単調増加するリビジョンで変更を順序付けます。配信層が5,000のノードプロキシに差分をプッシュし、プロキシはリビジョンの欠落を検出した際にフルスナップショットを取得します。
ビジネスリクエストはローカルプロキシまたは安定したVIPを使用し、レジストリに同期クエリを実行することはありません。障害発生時、プロキシは最後のスナップショットを保持し、接続タイムアウト、制限されたリトライ、パッシブエラーを使用して不良エンドポイントを一時的に退避させます。ヘルス状態は、起動（startup）、準備完了（readiness）、生存（liveness）、およびパッシブシグナルを分離します。5秒のアクティブプローブと3回の失敗判定により、約15秒のクラッシュ検出を目指します。最後に、ロールアウト、ネットワーク分断、ウォッチの切断、再接続ストーム、不正プローブに対するフォールトインジェクションを実施し、削除レイテンシ、古いリクエスト、収束性を測定します。」
ステップごとの詳細解説
ステップ1: データモデルとステートマシンの定義
カタログのキーには、環境とプロトコルが衝突しないよう、少なくともネームスペース、サービス名、ポート名を含めます。エンドポイントには、安定したインスタンスID、アドレス、リージョン、ゾーン、バージョン、重み、機能ラベル、状態、リース有効期限、リビジョンが含まれます。事前定義されたラベルディメンションのみが許可され、任意の高カーディナリティデータはディスカバリプレーンには属しません。
ステートマシンは、単一のhealthyブール値よりも多くの意味を持ちます。STARTINGはトラフィックを受信しません。READYは新規トラフィックを受け入れます。DRAININGは既存の接続を完了させつつ新規リクエストを停止します。UNHEALTHYはアクティブまたはパッシブな障害判定を反映します。EXPIREDはリースが更新されなかったことを意味します。各遷移はその理由、発生元、単調増加リビジョンを記録し、順不同の更新を監査可能にします。
単一エンドポイントの更新は、インスタンスIDと起動ジェネレーションによって重複排除されます。古いプロセスからの遅延リースが、すでに置き換えられたアドレスを復活させることはできません。オーケストレータが権威を持つ場合、コントローラが意図されたライフサイクルと実際の準備完了状態を監視します。自己登録の場合、書き込み側はワークロードとして認証され、自身のサービスおよびインスタンスレコードのみを変更できます。
ステップ2: 各言語への複雑さの波及を避けるディスカバリパターンの選択
呼び出し側がサービス名のみを必要とし、プラットフォームがエンドポイントとヘルスをすでに処理している場合は、DNSと安定したVIPの組み合わせが機能します。DNS経由でインスタンスアドレスを直接返すのはシンプルですが、TTLによってクエリ負荷と情報の古さとの間にトレードオフが生じます。短いTTLを無視するクライアントはリスクを拡大させます。
クライアントサイドディスカバリはバージョン、ゾーン、負荷に応じた選択が可能ですが、すべての言語でウォッチ処理、キャッシュ、負荷分散、リトライ、安全なアップグレードを実装する必要があります。この問題には多様な言語を使用する呼び出し側が存在するため、ノードローカルまたは既存のプラットフォームプロキシを経由するサーバーサイドディスカバリを推奨します。アプリケーションは安定したローカルアドレスを呼び出し、プロキシがエンドポイントセットとバックエンドの選択を管理します。ローカルでのホップが1回増えることで、統一されたセマンティクスと迅速なアップグレードが得られます。
すべてのワークロードがすでにKubernetes上で動作している場合、通常はService、DNS、EndpointSliceが基本的なディスカバリをカバーします。別のレジストリを構築するとプラットフォームが重複します。個別のコントロールプレーンを導入するのは、VM間、クラスタ間、高度なルーティング、またはポリシーに関する真の要件がある場合のみとし、オーケストレータのエンドポイント情報を消費することを優先します。
ステップ3: 古い読み取りを許容しながら書き込みを順序付ける
リージョンごとに3または5つのカタログレプリカをデプロイし、登録と状態遷移にはコンセンサスリーダーを使用します。1つのグローバルリーダーが100,000インスタンスすべてを所有しないように、サービスキーまたはテナントごとにシャード化します。すべての書き込みをリージョン間で同期レプリケーションしないでください。リモートのネットワーク分断が健全なリージョンをブロックしてはなりません。グローバルレイヤーは、サービスポリシーと許可されたフェイルオーバー先を同期します。
書き込みの成功は、リージョナルカタログがリビジョンを受け入れたことを意味します。すべてのプロキシがそれを確認したことを意味するわけではありません。ディストリビュータは順序付けられた差分（デルタ）をプッシュします。プロキシは最後の完全なスナップショットとリビジョンを永続化します。連続したリビジョンを適用しますが、ギャップを検出した場合、検証に失敗した場合、またはデルタ保持期間が切れた後に再接続した場合は、そのサービスのフルスナップショットを取得します。古いデータと新しいデータが混ざらないよう、スナップショットの置き換えはアトミックに行われます。
読み取りパスは、可用性と引き換えに限られた古さ（staleness）を許容します。プロキシはスナップショットの経過時間、コントロールプレーンとの最終通信、ウォッチの遅延を記録します。通常の許容時間を超えた場合はアラートを発しますが、規定の10分間の停止中も最後のセットを使用し続けます。既知のエンドポイントがすべて失敗した場合、ポリシーを無視して勝手に任意のリージョンへ迂回するのではなく、明示的な「バックエンドなし」の結果を返します。
ステップ4: 意図的な離脱とハード障害検出の分離
正常なシャットダウンの場合、アプリケーションはまず準備完了状態（readiness）を取り下げます。カタログはDRAININGに入り、伝播後にプロキシはそのエンドポイントの選択を停止します。プロセスは最大接続ドレイン期間待機してから終了します。ディスカバリの伝播は瞬間的ではないため、古いプロキシや長期生存接続が依然としてそのアドレスを保持している可能性があり、アプリケーション側でも新しい処理の受け入れを停止します。
ハード障害は何のシグナルも送信しません。5秒ごとのアクティブプローブと3回連続の失敗による削除を行う場合、プローブ成功直後の障害では、プローブのタイムアウトと伝播の前に、サンプリングだけでほぼ15秒を消費する可能性があります。15秒のp99を満たすには、タイムアウト、スケジューラのジッター、配信を総合的に予算化するか、間隔を短縮する必要があります。プロキシは、接続拒否、タイムアウト、または高いローカルエラー率の後にエンドポイントを一時的に退避させることができますが、単一の呼び出し元のネットワーク問題によってグローバルに登録解除してはなりません。
起動（startup）、準備完了（readiness）、生存（liveness）も明確に区別されます。Startupは低速な初期化を保護します。Readinessの失敗はトラフィックを停止します。Livenessの失敗は再起動をトリガーします。共有データベースをすべてのインスタンスのlivenessテストに含めると、データベース停止時にサービス全体が再起動し、負荷が増幅する可能性があります。重要な依存関係はreadinessに影響を与える場合がありますが、プローブストームを回避するために、チェックには短いタイムアウト、ジッター、キャパシティ保護が必要です。
ステップ5: 書き込み、変更、およびファンアウト負荷の計算
100,000のインスタンスが10秒ごとに直接更新を行う場合、定常状態で毎秒10,000件の更新が発生します。インスタンスごとのハートビートよりもオーケストレータのウォッチを優先するか、ランダムなジッターを持つノードエージェントを介して更新を集約します。リースの有効期限は、通常の離脱パスではなく、破棄されたレコードに対するセーフティネットとして残します。
2分間で10,000個のエンドポイントを置き換える場合、毎秒平均約83件の追加と83件の削除、つまり約167件のメンバーシップ変更が発生します。各変更を5,000のノードプロキシすべてに個別に送信すると、毎秒最大約835,000件の配信が発生することになります。実際のサブスクリプションでは、各プロキシが必要とするサービスにフィルタリングし、短い時間枠で同一サービスの変更を結合（coalesce）し、階層型の配信を使用します。結合処理によって、3秒の離脱SLOが1分間のバッチ処理になってしまわないように注意が必要です。
フルスナップショットにも予算が必要です。エンドポイントあたりシリアライズサイズを256バイトと仮定すると、グローバルな100,000エンドポイントのスナップショットは約24.4 MiBになります。通常のプロキシは、グローバルカタログではなく、サブスクライブしているサービスのみを取得します。再接続にはジッター付きのエクスポネンシャルバックオフを使用し、ディストリビュータは短いデルタログを保持して、復旧後に5,000のプロキシが同時にフルスナップショットを要求しないようにします。
ステップ6: リージョン境界とセキュリティ境界の定義
インスタンスはデフォルトでローカルリージョンに登録され、呼び出しは同じリージョンおよびゾーン内のREADYエンドポイントを優先します。リージョナルカタログがクォーラムを失った場合、新規書き込みは拒否されますが、ローカルプロキシはキャッシュの読み取りを継続します。他のリージョンが、リモートプローブに基づいてそれらのエンドポイントを健全とマークしたり、ローカルの信頼できる情報を上書きしたりしてはなりません。
サービスポリシーでは、クロスリージョンルーティングの可否、読み取り専用または書き込み可能の動作、優先順位、キャパシティ制限、データ境界を宣言します。明示的なポリシーによってグローバルフェイルオーバーがトリガーされます。ステートレスな読み取りは迅速に切り替えられますが、単一ライターのデータベースに対するプロキシは、まずオーナーシップの移譲を確立する必要があります。ディスカバリは候補アドレスを返すだけであり、ビジネスの整合性プロトコルを代替することはできません。
登録、登録解除、ウォッチにはワークロードIDと最小権限が必要であり、カタログの変更は監査ログに記録されます。プロキシはコントロールプレーンを認証し、機密性の高いサービスはディスカバリとMutual TLSを組み合わせることができます。エンドポイントのラベルは信頼された認可クレームではないため、呼び出し側は接続時またはリクエスト時にサービスのアイデンティティと権限を検証します。
ステップ7: タイムラインとフォールトインジェクションによる検証
まず、ローリングアップデートをテストします。古いインスタンスが準備完了状態を取り下げます。カタログがリビジョンを受け入れ、プロキシがそれを適用し、最後の新規リクエストが到着し、プロセスが終了するまでの時間を記録します。新しいインスタンスは、起動と準備完了が完了した後にのみセットに入ります。アクティブ離脱の伝播p99が3秒未満であること、処理中のリクエストが完了すること、準備ができていないインスタンスへのトラフィックがゼロであることを確認します。
次に、登録解除を行わずにプロセスを強制終了し、5秒のプローブ、失敗閾値、および配信が連携して15秒のp99を満たすことを検証します。プロキシのネットワーク障害、ノード全体の障害、カタログフォロワーの遅延、リーダー交代、リージョナルクォーラムの喪失、デルタの欠落、破損したスナップショット、10分間のコントロールプレーン停止を注入します。復旧時はジッターを伴って再接続し、フルスナップショットのスタンピードが発生しないことを確認します。
本番メトリクスには、登録および更新レート、カタログ書き込みレイテンシ、サービスごとのREADY数、ヘルスのフラッピング、プローブレイテンシ、ウォッチ遅延、スナップショットの経過時間、リビジョンギャップ、フルスナップショットへのフォールバック、プロキシの再接続、削除されたエンドポイントへの新規リクエスト、古いエンドポイントへの接続失敗、バックエンドなしの結果が含まれます。コントロールプレーンのダッシュボードが緑色であることだけでなく、トラフィックのタイムラインによって伝播を証明します。
優れた回答例
「登録の事実、ヘルス判定、ディスカバリの配信、リクエストルーティングを分離します。リージョナルなコンセンサスグループが認証されたインスタンスの変更を受け入れます。各レコードは、サービスキー、インスタンスID、起動ジェネレーション、アドレス、リージョン、バージョン、状態、リース、リビジョンを持ちます。ルーティング可能なセットに入るのはREADYのみです。シャットダウン時はDRAININGに移行し、新規トラフィックを停止し、ドレインした後に終了します。ハード障害にはプローブとリースの期限切れを使用します。パッシブエラーはローカルで退避され、即座にグローバルな確定情報になることはありません。
呼び出し側が多言語にわたるため、すべてのプロセスにレジストリをウォッチさせることはしません。5,000のノードプロキシが必要なサービスのみをサブスクライブし、完全なスナップショットと単調増加リビジョンを永続化し、連続したデルタを適用し、ギャップが生じた場合は単一のサービスを再取得します。リクエストはローカルプロキシを使用し、コントロールプレーンに同期クエリを実行することはありません。10分間の停止中、プロキシは短い接続タイムアウト、制限されたリトライ、ローカル退避を用いながら、最後に認識されたエンドポイントを使用します。新しいインスタンスは不可視となり、古いアドレスは無効になっている可能性があるため、これらのコストを明示的なメトリクスとして監視します。
100,000のインスタンスが10秒ごとに更新を行うと毎秒10,000件の書き込みが発生するため、オーケストレータのウォッチまたはノードでの集約を優先します。2分間で10,000個のエンドポイントを置き換えると、毎秒約167件の追加・削除変更が発生します。サブスクリプションでフィルタリングし、短時間結合し、3秒の離脱予算を消費しないように階層的にファンアウトします。5秒ごとのプロービングと3回の失敗要求はそれだけで15秒に近づくため、タイムアウトと伝播も予算の一部として組み込みます。
トラフィックタイムラインを通じて検証を行います。受け入れられた離脱から3秒以内に新規リクエストがゼロになり、ハードクラッシュしたエンドポイントは15秒以内に候補セットから外れることを確認します。既存のトラフィックは、リーダー交代、リージョナルなネットワーク分断、10分間のコントロールプレーン停止中も継続します。最後に、5,000のプロキシがジッターを伴って再接続し、リビジョンギャップを埋め、カタログに過負荷をかけることなく収束します。」
よくある落とし穴
- リクエストごとにレジストリをクエリする → コントロールプレーンの遅延や障害がビジネスパスに入り込む → バージョン管理されたエンドポイントをローカルにキャッシュし、バックグラウンドで変更を受信する。
- 単一の
healthyブール値を使用する → 起動、トラフィック受け入れ、ドレイン、再起動のセマンティクスが混同される → 遷移元を伴う明示的なステートマシンを使用する。 - Readinessの失敗で再起動する → ダウンストリームの障害によってサービス群全体が再起動する可能性がある → Readinessはトラフィックを除去し、Livenessは回復不能なローカル障害のみを対象とする。
- 短いDNS TTLによって古いデータが排除されると思い込む → クライアントキャッシュ、伝播、検出により依然としてタイムラグが生じ、クエリ負荷が増加する → TTLのトレードオフを測定し、データプレーンの耐障害性を維持する。
- 認証されていない自己登録を許可する → 誤ったエンドポイントや不正なエンドポイントが内部トラフィックを受信する恐れがある → オーケストレータの確定情報または制限されたワークロードIDを使用する。
- すべてのプロキシにグローバルカタログをサブスクライブさせる → デプロイや再接続時にファンアウトやスナップショットのストームが発生する → サービスごとにフィルタリングし、階層的に配信し、デルタをバージョン管理し、再接続にジッターを設ける。
- すべてのハートビートをリージョン間で強力にレプリケーションする → リモートの遅延やネットワーク分断が健全なリージョンをブロックする → 書き込みをリージョン内で順序付け、ポリシーと許可されたフェイルオーバーメタデータのみを同期する。
- ディスカバリの成功をリクエストの成功と同一視する → ルックアップ直後にエンドポイントが失敗する可能性がある → 呼び出しプロトコルには接続タイムアウト、制限されたリトライ、サーキットブレーカー、冪等性が依然として必要である。
- すべての依存関係のヘルスをチェックする → 1つの共有障害によってすべてのインスタンスが一度に削除される → 短いタイムアウトとジッターを用いて、重要なトラフィック受け入れ条件のみをチェックする。
フォローアップの質問と回答
フォローアップ1: なぜ100,000のインスタンスすべてにクライアントサイドディスカバリを直接使用させないのか？
クライアントサイドディスカバリはホップを排除し、詳細なルーティングを可能にしますが、ウォッチ、キャッシュ、リビジョン修復、負荷分散、退避、アップグレードの処理がすべての言語とプロセスに重複してしまいます。多言語環境では、ノードプロキシを使用することで100,000のクライアント接続を約5,000のデータプレーンインスタンスに集約できます。単一の成熟したランタイムでレイテンシ予算が極めて厳しい場合は必須のSDKが正当化されることもありますが、それでもプロトコルの適合性テストと強制アップグレードが必要です。
フォローアップ2: コントロールプレーンの停止中に古いエンドポイントを使用しても安全な理由は？
最後のスナップショットを使用することで、追加、離脱、フェイルオーバーの変更を見逃すリスクと引き換えに、生存しているインスタンスが処理を継続できます。プロキシはスナップショットの経過時間を公開し、短いタイムアウトとパッシブエラーを使用して停止したアドレスへの呼び出しを減らし、リトライ回数を制限します。セキュリティの失効はディスカバリキャッシュの伝播を待ってはならず、独立した認証・認可レイヤーがフェイルクローズします。サービス固有の最大スナップショット経過時間を過ぎた場合、単一のグローバルルールを適用するのではなく、ポリシーに従って縮退運転または拒否を行います。
フォローアップ3: 5秒のプローブと3回の失敗判定で本当に15秒を満たせるのか？
必ずしも満たせるとは限りません。プローブ成功直後に障害が発生した場合、3回の失敗サンプリングだけでほぼ15秒を消費する可能性があり、さらにタイムアウト、スケジューリングのジッター、エンドポイントの伝播が加わります。p99を満たすには、間隔を短縮し、タイムアウトを間隔未満に抑え、接続拒否などのパッシブシグナルを利用してより迅速にローカル退避を行う必要があります。フォールトインジェクションでは、最後に成功したリクエストから最後にルーティングされた新規リクエストまでの分布を測定しなければならず、設定値を掛け算するだけでは証明になりません。
フォローアップ4: ローリングデプロイで即時削除ではなくDRAININGが必要な理由は？
削除は、新しいリストを受信した呼び出し元からのトラフィックのみを停止します。古いキャッシュ、Keep-Alive、時間のかかるRPC、キューに入った処理には対処できません。DRAININGは、プロセスが限られたドレイン期間維持されている間に、エンドポイントを新規リクエストの候補から除外します。アプリケーション側も新規処理の受け入れを停止し、呼び出しタイムアウトはプラットフォームの終了猶予期間内に収まるようにします。検証では、最後の新規リクエスト、処理中リクエストの完了、強制終了を追跡します。
フォローアップ5: あるリージョンがクォーラムを失った場合、別のリージョンが登録を受け入れるべきか？
そのリージョンのインスタンス情報を別のリージョンが自動的に引き継ぐべきではありません。クロスリージョンからの観測ではネットワーク分断をインスタンスの完全停止と誤認する可能性があり、2つのコントロールプレーンが矛盾した状態を受け入れるリスクがあります。クォーラムを失ったリージョンはカタログの書き込みを停止し、プロキシはキャッシュを読み取ります。グローバルレイヤーは、宣言されたサービスのフェイルオーバーポリシーに従ってのみ新規呼び出しをルーティングします。復旧時には、リビジョンと起動ジェネレーションによって状態が調整され、期限切れのリースが新しいインスタンスを上書きすることを防ぎます。