Cells ADR 024: ディザスタリカバリにバックアップとリストアを使用する
コンテキスト
この ADR は、Cells のディザスタリカバリモデルとしてバックアップとリストア戦略の使用を定めます。
現在、私たちは定期的に Cell データをバックアップし、それらのバックアップを AWS Vault に保存しています。この Issue で議論したように、これらのバックアップは Cells ベースのアーキテクチャにおけるディザスタリカバリ（DR）の主要なメカニズムとなることが意図されています。
決定事項
Cells のプライマリディザスタリカバリメカニズムとしてバックアップとリストアを使用します。
各 Cell は、ステートフルなコンポーネント（例：データベース、オブジェクトストレージ、設定状態）の整合性あるバックアップを生成する責任を持ちます。災害シナリオでは、同じまたは別の AWS リージョンに新しい Cell をプロビジョニングし、最新の有効なバックアップから復元できます。
このアプローチは以下を意味します：
- バックアップはファーストクラスのリカバリアーティファクトとして扱われます。
- リストアワークフローは自動化され、再現可能で、定期的に実施される必要があります。
- リカバリは失敗した Cell をその場で修復しようとするのではなく、新しい Cell を作成することによって行われます。
AWS に保存されたバックアップデータは、ディザスタリカバリ操作の唯一の情報源と見なされます。
結果と影響
ポジティブ
- Cells の分離モデルとの強い整合性：障害とリカバリの範囲が個々の Cell に限定される
- Geo による場合と比較して、グローバルな同期レプリケーションに比べ運用の複雑さ/コストが削減される。
- 新しいリージョンやアカウントへのリストアの柔軟性があり、AWS クォータの枯渇やリージョン停止の緩和に役立つ。
- ドリルを通じて検証可能な明確でテスト可能なリカバリ手順。
ネガティブ
- Geo とは異なり、RTO はテナントのプロビジョニングとリストア時間に制限され、Geo フェイルオーバーより長くなります。
- Geo とは異なり、RPO は最後の成功したバックアップの時刻に制限され、設定可能ですが Geo フェイルオーバーより長くなります。
- リストアワークフローは信頼性が高くなければなりません。リストアツールの障害は直接 RTO に影響します。
運用上の影響
- バックアップの鮮度と整合性は継続的に監視される必要があります
- リストア手順は文書化され自動化される必要があります。
- バックアップが実際の条件下で使用可能であることを確認するために、定期的なディザスタリカバリ訓練が必要です
