要点: すべての顧客リクエストを中央の管理サービスへ通すべきではありません。
この記事の用語: 管理系：テナントやポリシーを管理する系。実行系：顧客リクエストを処理する系。
現場の課題
プラン、上限、配置リージョンは頻繁に変わりませんが、利用者のリクエストには低遅延と高可用性が必要です。両者を密結合すると、管理系の障害が製品全体の停止になります。
単純な対策だけでは不十分な理由
プランや上限はゆっくり変わり、利用者 リクエストは速さと可用性を求めます。管理系がバージョン付きポリシーを配布し、実行系が最後の有効スナップショットで処理すれば障害領域を分けられます。
処理フロー
管理系
テナントとポリシー→Provisioner
DesiredからActual→実行系
顧客トラフィック→Audit
証跡と状態照合
テナントとポリシー→Provisioner
DesiredからActual→実行系
顧客トラフィック→Audit
証跡と状態照合
アーキテクチャ上の判断
Desired-state 状態照合
Controllerが実状態との差分を修復します。
Isolation Tierを選ぶ
Pooled、Partitioned、Dedicatedをポリシーとして扱います。
EnforcementをLocal化
署名・バージョン付きポリシーを実行系で検証します。
さらに深く考える
Isolationは多次元
DBは共有でもキーやComputeは専用にできます。各Dimensionとマイグレーションを定義します。
ライフサイクルをワークフロー化
Suspend、復元、データ出力、Deleteに検証結果とApprovalが必要です。
実装手順
- テナント設定をバージョン付きの期待状態として管理します。
- 資源作成は、途中から再開できる状態機械で非同期実行します。
- 署名付きポリシースナップショットを配布し、管理系停止中も最後の有効バージョンで処理します。
コード例: テナント ポリシースナップショット
snapshot = { tenantId, version, region, plan, limits, keyRef }
signature = controlPlane.sign(snapshot)
dataPlane.verify(signature)
dataPlane.activateIf(version > current.version)明示的な新署名ロールバック バージョンなしに古いスナップショットへ戻しません。
想定しておく障害
- 部分資源作成後に再試行されます。
- 古い利用権限がSuspend後も機能を許可します。
- 一つのテナントが共有プールを枯渇させます。
監視すべきこと
| 指標 | 何が分かるか |
|---|---|
| State別資源作成 Age | 停止Transitionを検出します。 |
| ポリシー バージョン Lag | 古いIntentを使う実行系を示します。 |
| テナント・Tier別Resource | Isolation判断の根拠です。 |
設計の検証方法
- 管理系停止中も利用中テナントが継続するか確認します。
- 各ステップ後に再試行し重複Resourceがないか確認します。
- 一つのテナントをQuota超過させ他テナントを確認します。
本番導入の進め方
ポリシーの読み取りを先に切り出し、旧経路と判断を比較します。資源作成を資源種別ごとの状態照合へ移し、古いポリシーと緊急権限取り消しの訓練後に同期呼び出しを外します。
本番前チェックリスト
- テナントコンテキストは信頼アイデンティティから取得します。
- 資源作成の全ステップを冪等にします。
- Compute、Storage、キューにテナント Budgetを持ちます。
まとめ
管理系と実行系の分離は、テナントのライフサイクルを監査可能にし、顧客トラフィックを管理障害から守ります。