要点: バックアップは、実際に復元し、データを確認し、時間を測るまで復旧能力とは呼べません。
この記事の用語: RPO：許容するデータ損失量。RTO：許容する復旧時間。Failover：予備環境へ切り替えること。
現場の課題
レプリカは誤削除も複製します。バックアップも暗号鍵、キュー、ファイルが欠ければ使えません。復旧はデータだけでなく、業務を再開する一連の手順として試験する必要があります。
単純な対策だけでは不十分な理由
レプリカは誤削除も複製し、未復元のバックアップは仮定にすぎません。データ、キー、キュー、ファイル、サービス起動順を含めてRPOとRTOを実測します。
処理フロー
Protect
バックアップ・Replication→Detect
障害対応宣言→Recover
依存順復元→Verify
データ・業務確認
バックアップ・Replication→Detect
障害対応宣言→Recover
依存順復元→Verify
データ・業務確認
アーキテクチャ上の判断
Impact別データ Tier
必要RPOから保護方式を選びます。
依存順復旧
アイデンティティ、シークレット、DB、ブローカー、Storage、AppをGraphとして復旧します。
Business 不変条件確認
Balance、テナント分離、イベント連続性を確認します。
さらに深く考える
非同期システムもRPO対象
ブローカー、Search、オブジェクト MetadataのAuthorityとRebuildを定義します。
組織能力も復旧
Role、Communication、AuthorityもRTOに含まれます。
実装手順
- プラットフォーム全体で一つではなく、業務機能ごとにRPOとRTOを定義します。
- 復旧に必要なデータストア、暗号鍵、キュー、ファイル、設定を一覧化します。
- 隔離環境への復元を自動化し、定期訓練で実時間を測ります。
コード例: 復旧 Verification ゲート
restore(backupId, isolatedEnvironment)
assert pointInTime >= incidentTime - RPO
assert invariant('tenant_isolation')
assert invariant('ledger_balanced')
assert syntheticJourney('sign-in-to-publish')
approve traffic cutoverIntegrityとセキュリティ確認まで復元環境を隔離します。
想定しておく障害
- Format・キー変更で復元に失敗します。
- クライアントが旧Region接続を保持します。
- Failbackが災害Modeの書き込みを上書きします。
監視すべきこと
| 指標 | 何が分かるか |
|---|---|
| 最終Verified 復旧 Point | 実データ保護を測ります。 |
| 復元 Stage Duration | RTO達成可能性です。 |
| レプリカ遅延・書き込み Fence | データ LossとSplit Brain リスクです。 |
設計の検証方法
- 元環境なしで無作為バックアップを復元します。
- Synthetic 書き込み中にRegionを失います。
- Failback後に全書き込みを照合します。
本番導入の進め方
重要なデータストア一つの復元を自動化し、業務フローが完了するまで依存サービスを増やします。定期訓練で指揮担当を交代し、手作業を自動化へ変えます。
本番前チェックリスト
- バックアップはImmutable、Encrypted、別失敗 Boundaryです。
- 復元 認証情報とキーも災害を生き残ります。
- FailoverはSingle Writer FenceとFailbackを持ちます。
まとめ
復旧能力は、計測した時間と照合済みデータで証明します。レプリカの存在だけでは証明できません。