要点: BackupはRestore、検証、時間計測を行うまでRecovery能力ではありません。
課題
Replicaは誤削除も複製します。Key不足、Queue・Object Storage漏れ、Split Brainにより図面上のMulti-regionだけでは復旧できません。
単純な対策だけでは不十分な理由
AnalyticsとPaymentでは必要目標が違います。
Region Failover前に旧WriterをFenceしSplit Brainを防ぎます。
処理フロー
Protect
Backup・Replication→Detect
Incident宣言→Recover
依存順Restore→Verify
Data・業務確認
Backup・Replication→Detect
Incident宣言→Recover
依存順Restore→Verify
Data・業務確認
アーキテクチャ上の判断
Impact別Data Tier
必要RPOから保護方式を選びます。
依存順Recovery
Identity、Secret、DB、Broker、Storage、AppをGraphとして復旧します。
Business Invariant確認
Balance、Tenant分離、Event連続性を確認します。
さらに深く考える
非同期SystemもRPO対象
Broker、Search、Object MetadataのAuthorityとRebuildを定義します。
組織能力もRecovery
Role、Communication、AuthorityもRTOに含まれます。
実装手順
- Business Capability別にRPO・RTOを定義します。
- 全Stateful Dependency、Key、ConfigをMapします。
- 隔離環境へのRestoreを自動化し定期訓練します。
技術例: Recovery Verification Gate
restore(backupId, isolatedEnvironment)
assert pointInTime >= incidentTime - RPO
assert invariant('tenant_isolation')
assert invariant('ledger_balanced')
assert syntheticJourney('sign-in-to-publish')
approve traffic cutoverIntegrityとSecurity確認までRestore環境を隔離します。
想定すべき障害パターン
- Format・Key変更でRestoreに失敗します。
- Clientが旧Region接続を保持します。
- Failbackが災害ModeのWriteを上書きします。
監視すべきシグナル
| シグナル | 確認する理由 |
|---|---|
| 最終Verified Recovery Point | 実Data保護を測ります。 |
| Restore Stage Duration | RTO達成可能性です。 |
| Replication Lag・Write Fence | Data LossとSplit Brain Riskです。 |
設計の検証方法
- 元環境なしで無作為BackupをRestoreします。
- Synthetic Write中にRegionを失います。
- Failback後に全Writeを照合します。
安全なRollout計画
重要Store一つからRestoreを自動化し、Business Journey全体へ広げます。四半期訓練で実RPO・RTOを記録し、手作業の驚きをCodeまたはTest済みChecklistへ変えます。
本番前チェックリスト
- BackupはImmutable、Encrypted、別Failure Boundaryです。
- Restore CredentialとKeyも災害を生き残ります。
- FailoverはSingle Writer FenceとFailbackを持ちます。
まとめ
ResilienceはReplicaの存在でなく、時間計測したRecovery Evidenceで証明します。