プロンプトとユースケース
あるグローバルサービスはすでにテナントを複数のセルに割り当てていますが、1つの不正なリリース、共有依存関係の障害、またはキャパシティイベントが依然として広範囲の障害を引き起こしています。現在のアーキテクチャを監査し、セル間で影響が伝播する経路を特定し、各セルが真の隔離境界であることを証明する再現可能な障害注入およびリカバリ検証を設計してください。
面接官が見ているポイント
- セルを、独立して実行、スケーリング、ロールバックできる完全なレプリカとして定義しているか。
- 爆発半径（影響範囲）、ルーティングマップ、新規ユーザーの一貫した割り当てについて論理的に考えられるか。
- 共有コントロールプレーン、セル間データ、キャパシティの偏り、ホットテナントの移行に対処できるか。
- プログレッシブロールアウト、メトリクスゲート、リカバリ訓練を具体的な運用に落とし込めるか。
回答前に明確にすべき質問
- 隔離キーはユーザー、テナント、リージョン、またはビジネスパーティションのどれであり、リージョン間アクセスは許可されているか？
- どのデータがグローバルに一貫している必要があり、どのデータがセル内で結果整合性でよいか？
- 目的はデプロイの影響を限定することか、リージョン全体の障害に耐えることか、あるいはその両方か？
- 負荷は予測可能か、ホットテナントを移動できるか、移行中の冪等性はどのように維持されるか？
30秒の回答フレームワーク
まず、各セルのコンピュート、キャッシュ、キュー、データ、コントロールプレーンの依存関係をマッピングし、すべての共有経路を特定します。次に、ルーティング、キャパシティ、リリース、セル間処理に関する隔離の不変条件（インバリアント）を定義します。1セルの過負荷、不正なリリース、データ依存関係の障害、コントロールプレーンの喪失を注入し、正常なセルのエラー率とレイテンシがゲート内に収まることを検証します。影響を伝播させる依存関係はすべて、パーティショニング、クォータ制限、またはローカルスナップショットによるフォールバックを設ける必要があります。復旧時間、影響テナント率、訓練のエビデンスによって、隔離が本物であるかを判断します。
ステップごとの詳細解説
1. セルの境界
セルとは、独立してデプロイ、スケーリング、リカバリが可能なシステム単位であり、通常はサービスインスタンス、キャッシュ、キュー、専用データシャードを含みます。共有DNS、アイデンティティ、構成サービスは、定義された劣化動作を備え、最小権限かつ疎結合に保つ必要があります。
2. ルーティングとマッピング
ルーティング層は、ユーザーまたはテナントキーによってマップを検索し、リクエストをターゲットセルに転送します。マップにはバージョン、チェックサム、有効期限ポリシーが必要です。移行中は、1つのエンティティが同時に2つのセルに書き込まないよう、新しいマップを先に書き込んで古いリクエストをドレイン（排出）します。
3. データの隔離
各セルはローカルの書き込み境界を保持し、セル間クエリには非同期レプリケーションされた読み取りプロジェクションを優先します。グローバルな一意性は、すべての書き込みを1つの共有ポイントに集中させるのではなく、専用のコーディネーターに委ねるか、パーティションローカルの一意性＋結果的な照合とします。
4. キャパシティとホットスポット
最大の爆発半径を制限するため、セルごとにリクエスト、キュー、データベース接続、ストレージのクォータを設定します。テナントの分布とリソースのウォーターマークを監視します。ホットテナントはアイドル状態のセルに移動できますが、移行には二重読み取り、単一書き込み、再生可能なイベントが必要です。
5. 共有コントロールプレーンのリスク
コントロールプレーンはマップ、バージョン、オーケストレーションを管理し、すべてのビジネスデータを運ぶべきではありません。コントロールプレーンの障害時、ルーターはTTL付きのローカルスナップショットから処理を提供できます。有効期限が切れた後は、安全な読み取りのみを許可するか、再試行可能なエラーを返します。
6. ロールアウトとロールバック
新しいバージョンを1つのセルで実行し、エラー率、テールレイテンシ、リソース飽和度、ビジネスメトリクスについてベースラインセルと比較します。ゲートを通過した後にバッチ単位で拡大します。リグレッションが発生した場合は拡大を停止し、正常なセルを劣化させることなくそのセルをロールバックします。
7. セル間オペレーション
セル間のレポート、バッチジョブ、アカウント移行は、冪等性キー、リース、進行状況チェックポイントを備えたオーケストレーターを通じて実行します。障害発生時は未完了のシャードのみを再試行し、部分的な完了状態を呼び出し元に明示的に公開します。
8. ディザスタリカバリと訓練
目標復旧時点（RPO）と目標復旧時間（RTO）を定義し、各セルのデータと構成をバックアップします。理論上の冗長性に頼るのではなく、単一セルの隔離、コントロールプレーンの喪失、リージョン障害、マッピング破損の訓練を実施して、トラフィックの移譲、データ復元、ロールバックスクリプトを検証します。
質の高い模範解答
「単にサービスが複数のセルにデプロイされているからといって、隔離されているとは仮定しません。データベース、キュー、キャッシュ、アイデンティティ、構成、ルーティング、リリースパイプラインを通じてテナントのリクエストを追跡し、共有障害ドメインを特定します。そして、3つの不変条件を定義します。1つのセルのリソース枯渇が別のセルのリソースを消費しないこと、不正なビルドは1つのロールアウトバッチにしか侵入できないこと、短いコントロールプレーン障害の間もデータプレーンがローカルのルーティングスナップショットから継続できることです。
ステージング環境や厳格に隔離された本番訓練において、1セルの過負荷、データベースの喪失、不正な構成、ルーティングディレクトリの喪失を注入します。正常なセルは、エラー率、P99レイテンシ、飽和度のゲート内に維持されなければなりません。障害を拡散させる共有依存関係には、パーティショニング、セルごとのクォータ、またはバージョン管理されたローカルスナップショットのフォールバックを適用します。リカバリチェックでは、トラフィックの隔離、データの整合性、マッピングのロールバックをカバーします。アーキテクチャ図に頼るのではなく、チームが隔離を繰り返し証明できるよう、影響テナント率、復旧時間、セル間の健全性をリリースのエビデンスとします。」
よくある間違い
- データベース、キュー、接続プールを共有し続けたまま、ステートレスなコンピュートのみを複製すること。
- 正常なセルのエラー率やテールレイテンシを確認せずに、障害が発生したセルが復旧するかどうかだけを確認すること。
- 安定したテナントマッピングの代わりにランダムルーティングを使用し、セル間書き込みを引き起こすこと。
- インフラの喪失はテストするものの、不正なリリース、ホットテナント、コントロールプレーンの障害を除外してしまうこと。
フォローアップ質問と回答
共有コントロールプレーンが隔離を壊しているかどうかをどのように判断しますか？
訓練中にコントロールプレーンを切断し、ルーターがTTL付きのバージョン管理されたローカルマッピングからリクエストを処理できるかを検証します。スナップショットの期限が切れた後は、システムに明示的な安全劣化状態が必要です。
隔離の受け入れゲートは何を測定すべきですか？
正常なセルのエラー率、P99レイテンシ、飽和度、影響テナント率の制限を設定し、復旧時間を記録します。障害セルの復旧だけでは隔離を証明できません。
セルを増やせば常に隔離性が向上しますか？
いいえ。セルを小さくすると理論上の爆発半径は小さくなりますが、キャパシティの断片化、ロールアウトバッチの増加、セル間の運用コストが増大します。目標とする影響テナント率、セルキャパシティ、持続可能な運用コストからセル数を導き出す必要があります。
セル間レポーティングによって共有障害が再現されることはありますか？
はい。レポーティングは、独立したクォータと縮退動作を備えた非同期プロジェクションを読み取る必要があります。オンラインリクエストが同期的にすべてのセルにファンアウトしてはいけません。