# REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する
障害は、さまざまな方法でビジネスに影響を与える可能性があります。まず、障害が発生するとサービスの中断 (ダウンタイム) が発生する可能性があります。2 つ目は、障害によりデータが失われたり、一貫性がなくなったり、古くなったりする可能性があります。障害への対応方法と障害からの復旧方法をガイドするために、ワークロードごとに目標復旧時間 (RTO) と目標復旧時点 (RPO) を定義します。*目標復旧時間 (RTO)* は、サービスの中断から復旧までの最大許容遅延時間です。*目標復旧時点 (RPO)* は、最後に実行されたデータ復旧時点からの最大許容時間です。
**期待される成果:** すべてのワークロードには、技術的な考慮事項とビジネスへの影響に基づいて指定された RTO と RPO があります。
**一般的なアンチパターン:**
+ 復旧目標が指定されていない。
+ 任意の復旧目標を選択する。
+ 過度に寛大で、ビジネス目標を満たさない復旧目標を選択する。
+ ダウンタイムとデータ損失の影響を評価していない。
+ 復旧時間ゼロやデータ損失ゼロなど、ワークロード設定では達成できないおそれのある非現実的な復旧目標を選択する。
+ 実際のビジネス目標よりも厳格な復旧目標を選択する。これにより、ワークロードが必要とするよりもコストが高く、複雑な DR 実装を強いられている。
+ 依存するワークロードの復旧目標と互換性のない復旧目標を選択する。
+ 規制とコンプライアンスの要件を考慮していない。
**このベストプラクティスを活用するメリット:** ワークロードに RTO と RPO を設定すると、ビジネスニーズに基づいて明確で測定可能な復旧目標を確立できます。これらの目標を設定すると、それに合わせてカスタマイズされたディザスタリカバリ (DR) 計画を作成できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ディザスタリカバリ計画の指針となるマトリックスまたはワークシートを作成します。マトリックスで、ビジネスへの影響 (重大、高、中、低など) と、それぞれにターゲットとする関連する RTO と RPO に基づいて、異なるワークロードカテゴリまたは階層を作成します。次のマトリックスは、従うことができる例を示しています (RTO と RPO の値は異なる場合があります)。
![\[ディザスタリカバリマトリックスを示すチャート\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/disaster-recovery-matrix.png)
各ワークロードについて、ダウンタイムとデータ損失がビジネスに与える影響を調査して理解します。影響は通常、ダウンタイムとデータ損失と共に大きくなりますが、影響の形状はワークロードタイプによって異なります。例えば、最大 1 時間のダウンタイムによる影響は小さいかもしれませんが、その後、影響が急速に拡大する可能性があります。影響には、財務上の影響 (収益の損失など)、評判上の影響 (顧客の信頼の喪失を含む)、運用上の影響 (給与の損失や生産性の低下など)、規制上のリスクなど、さまざまな形態があります。完了したら、ワークロードを適切な階層に割り当てます。
障害の影響を分析するときは、次の質問を考慮してください。
1. ビジネスに許容できない影響が生じる前にワークロードが利用できなくなる最大時間はどれくらいですか。
1. ワークロードの中断により、ビジネスにどのような影響が及ぶでしょうか。財務、評判、運用、規制など、あらゆる種類の影響を考慮してください。
1. ビジネスに許容できない影響が生じる前に、失われたり回復不能になったりする可能性のあるデータの最大量はどれくらいですか?
1. 失われたデータは、他のソース (*派生*データとも呼ばれます) から再作成できますか? その場合、ワークロードデータの再作成に使用されるすべてのソースデータの RPO も考慮してください。
1. このワークロードが依存するワークロード (ダウンストリーム) の復旧目標と可用性の期待値は何ですか? ワークロードの目標は、ダウンストリームの依存関係の復旧能力を考慮して達成可能である必要があります。このワークロードの復旧能力を向上させる可能性のあるダウンストリーム依存関係の回避策または軽減策を検討してください。
1. このワークロードに依存するワークロード (アップストリーム) の復旧目標と可用性の期待値は何ですか? アップストリームのワークロード目標によっては、このワークロードに、最初に想定されるよりも厳密な復旧能力が必要になる場合があります。
1. インシデントのタイプに基づいて、さまざまな復旧目標がありますか? 例えば、インシデントがアベイラビリティーゾーンまたはリージョン全体に影響するかどうかに応じて、RTO と RPO が異なる場合があります。
1. 復旧目標は、特定のイベント中または 1 年のうちに変化しますか? 例えば、ホリデーショッピングシーズン、スポーツイベント、特別セール、新製品の発売などに合わせて、異なる RTO と RPO を設定できます。
1. 復旧目標は、どのような事業部門や組織のディザスタリカバリ戦略と整合していますか?
1. 考慮すべき法的または契約上の影響はありますか? 例えば、特定の RTO または RPO でサービスを提供する契約上の義務はありますか? それらを満たさなかった場合、どのような罰則が科される可能性がありますか?
1. 規制またはコンプライアンス要件を満たすために、データ整合性を維持する必要はありますか?
次のワークシートは、各ワークロードの評価に役立ちます。このワークシートは、特定のニーズに応じて修正できます (質問を追加するなど)。
![\[ワークシート\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/worksheet.png)
### 実装手順
1. 各ワークロードを担当するビジネスステークホルダーと技術チームを特定し、連携します。
1. ワークロードが組織に与える影響について、重要度のカテゴリまたは階層を作成します。カテゴリの例としては、重要、高、中、低などがあります。カテゴリごとに、ビジネス目標と要件を反映する RTO と RPO を選択します。
1. 前のステップで作成したインパクトカテゴリの 1 つを各ワークロードに割り当てます。ワークロードがカテゴリにどのようにマッピングされるかを決定するには、ビジネスにとってのワークロードの重要性と中断やデータ損失の影響を考慮し、上記の質問を参考にしてください。これにより、ワークロードごとに RTO と RPO が作成されます。
1. 前のステップで決定した各ワークロードの RTO と RPO を検討します。ワークロードのビジネスチームと技術チームを関与させて、目標を調整する必要があるかどうかを判断します。例えば、ビジネスステークホルダーは、より厳格なターゲットが必要であると判断する可能性があります。あるいは、技術チームは、利用可能なリソースと技術的な制約で目標を達成できるようにターゲットを変更する必要があると判断することもできます。
## リソース
**関連するベストプラクティス:**
+ [REL09-BP04 データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html)
+ [REL12-BP01 プレイブックを使用して障害を調査する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 ディザスタリカバリの実装をテストし、実装を検証する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**関連ドキュメント:**
+ [AWS アーキテクチャブログ: ディザスタリカバリシリーズ](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS でのワークロードの災害対策: クラウド内での復旧 (AWS ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [AWS Resilience Hub による障害耐性ポリシーの管理](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [APN Partner: partners that can help with disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: ディザスタリカバリに活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**関連動画:**
+ [AWS re:Invent 2018: マルチリージョンアクティブ/アクティブアプリケーション用アーキテクチャパターン](https://youtu.be/2e29I3dA8o4)
+ [Disaster Recovery of Workloads on AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)