要点: 明確なControl Plane境界により、全Requestを中央管理Serviceへ依存させずにSaaSを拡張できます。
課題
Tenant作成やPlanは低頻度ですが、顧客Requestは低Latencyと高Availabilityが必要です。結合すると管理障害が製品障害になります。
単純な対策だけでは不十分な理由
毎Requestの中央Entitlement参照はLatency、Cost、全体障害点を作ります。Local Snapshotが依存を外します。
Version State、Audit、ReconciliationがIntentと実Resourceを接続します。
処理フロー
Control Plane
TenantとPolicy→Provisioner
DesiredからActual→Data Plane
顧客Traffic→Audit
証跡とReconciliation
TenantとPolicy→Provisioner
DesiredからActual→Data Plane
顧客Traffic→Audit
証跡とReconciliation
アーキテクチャ上の判断
Desired-state Reconciliation
Controllerが実状態との差分を修復します。
Isolation Tierを選ぶ
Pooled、Partitioned、DedicatedをPolicyとして扱います。
EnforcementをLocal化
署名・Version付きPolicyをData Planeで検証します。
さらに深く考える
Isolationは多次元
DBは共有でもKeyやComputeは専用にできます。各DimensionとMigrationを定義します。
LifecycleをWorkflow化
Suspend、Restore、Export、DeleteにEvidenceとApprovalが必要です。
実装手順
- Tenant設定をVersion付きDesired Stateにします。
- Lifecycle State Machineで非同期Provisioningします。
- 署名Snapshotを配布し、最後の有効Versionで安全に継続します。
技術例: Tenant Policy Snapshot
snapshot = { tenantId, version, region, plan, limits, keyRef }
signature = controlPlane.sign(snapshot)
dataPlane.verify(signature)
dataPlane.activateIf(version > current.version)明示的な新署名Rollback Versionなしに古いSnapshotへ戻しません。
想定すべき障害パターン
- 部分Provisioning後にRetryされます。
- 古いEntitlementがSuspend後も機能を許可します。
- 一Tenantが共有Poolを枯渇させます。
監視すべきシグナル
| シグナル | 確認する理由 |
|---|---|
| State別Provisioning Age | 停止Transitionを検出します。 |
| Policy Version Lag | 古いIntentを使うData Planeを示します。 |
| Tenant・Tier別Resource | Isolation判断の根拠です。 |
設計の検証方法
- Control Plane停止中もActive Tenantが継続するか確認します。
- 各Step後にRetryし重複Resourceがないか確認します。
- 一TenantをQuota超過させ他Tenantを確認します。
安全なRollout計画
Read-only Policyを先に抽出して旧経路と比較します。Resource種別ごとにReconciliationへ移行し、Stale Policyと緊急Revocation訓練後に同期依存を外します。
本番前チェックリスト
- Tenant Contextは信頼Identityから取得します。
- Provisioningの全StepをIdempotentにします。
- Compute、Storage、QueueにTenant Budgetを持ちます。
まとめ
Control Plane分離はTenant操作を監査可能にし、顧客Trafficを独立させます。