翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 序章
ワークロードは、意図した機能を正しく一貫して実行する必要があります。これを実現するには、*回復性*を考慮して設計する必要があります。回復力とは、ワークロードがインフラストラクチャ、サービス、またはアプリケーションの中断から回復し、需要に合わせてコンピューティングリソースを動的に取得し、設定ミスや一時的なネットワーク問題などの中断を軽減する能力です。
ディザスタリカバリ (DR) は耐障害性戦略の重要な部分であり、災害発生時のワークロードの対応 ([災害](what-is-a-disaster.md)はビジネスに重大な悪影響を与えるイベント) について懸念しています。このレスポンスは、[目標復旧時点 (RPO)](business-continuity-plan-bcp.md#recovery-objectives-rto-and-rpo) と呼ばれるデータの損失を回避し、目標[復旧時間 (RTO)](business-continuity-plan-bcp.md#recovery-objectives-rto-and-rpo) と呼ばれるワークロードが使用できないダウンタイムを削減するためのワークロードの戦略を指定する組織のビジネス目標に基づいている必要があります。したがって、特定の 1 回限りの災害イベントの復旧目標 ([RPO と RTO](business-continuity-plan-bcp.md#recovery-objectives-rto-and-rpo)) を満たすには、クラウド内のワークロードの設計に回復力を実装する必要があります。このアプローチは、事業継続[計画 (BCP) の一環として事業継続](business-continuity-plan-bcp.md)性を維持するのに役立ちます。
このホワイトペーパーでは、ビジネスのディザスタリカバリ目標 AWS を満たすアーキテクチャを計画、設計、実装する方法に焦点を当てています。ここで共有される情報は、最高技術責任者 (CTOs)、アーキテクト、デベロッパー、運用チームメンバー、リスクの評価と軽減を担当するテクノロジー担当者を対象としています。
## ディザスタリカバリと可用性
ディザスタリカバリは、耐障害性戦略のもう 1 つの重要な要素である*可用性*と比較できます。ディザスタリカバリは 1 回限りのイベントの目標を測定しますが、可用性目標は一定期間の平均値を測定します。
![\[ディザスタリカバリ (RTO、RPO) と可用性 (MTBF、MTTR) の回復目標を示す画像。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/images/resiliency-objectives.png)
*図 1 - 耐障害性の目的 *
可用性は、平均障害間隔 (MTBF) と平均復旧時間 (MTTR) を使用して計算されます。
![\[可用性は使用可能時間を合計時間で割ったものと等しく、MTBF を MTBF と MTTR で割ったものと等しくなります。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/images/availability-calculation-time-based.png)
このアプローチは「nines」と呼ばれ、99.9% の可用性ターゲットは「three nines」と呼ばれます。
ワークロードでは、時間ベースのアプローチを使用する代わりに、成功したリクエストと失敗したリクエストをカウントする方が簡単な場合があります。この場合、次の計算を使用できます。
![\[可用性は、成功したレスポンスを有効なリクエストで割った値です。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/images/availability-calculation-successful-failed-requests.png)
ディザスタリカバリはディザスタイベントに重点を置いていますが、可用性はコンポーネントの障害、ネットワークの問題、ソフトウェアのバグ、負荷の急増など、より小規模な規模のより一般的な中断に重点を置いています。ディザスタリカバリの目的はビジネス継続性ですが、可用性の問題は、ワークロードが意図したビジネス機能を実行するために利用できる時間を最大化することです。どちらも耐障害性戦略の一部である必要があります。
## Well-Architected の実現状況の確認
[AWS Well-Architected フレームワーク](https://aws.amazon.com/architecture/well-architected/)は、クラウドでシステムを構築するときに行う決定のメリットとデメリットを理解するのに役立ちます。このフレームワークの 6 つの柱を使用することで、信頼性、セキュリティ、効率、コスト効果および持続可能なシステムを設計し、運用するためのアーキテクチャのベストプラクティスを学習できます。[AWS マネジメントコンソールで無料で利用できる AWS Well-Architected ツール](https://aws.amazon.com/well-architected-tool/)を使用すると、柱ごとに一連の質問に答えることで、これらのベストプラクティスに照らしてワークロードを確認できます。 [https://console.aws.amazon.com/wellarchitected](https://console.aws.amazon.com/wellarchitected)
このホワイトペーパーで説明されている概念は、[「信頼性の柱」ホワイトペーパー](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)に含まれるベストプラクティス、特に[https://docs.aws.amazon.com/wellarchitected/latest/framework/a-failure-management.html](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-failure-management.html)「ディザスタリカバリ (DR) をどのように計画するか」という質問に詳しく説明されています。このホワイトペーパーのプラクティスを実装したら、AWS Well-Architected ツールを使用してワークロードを確認 (または再確認) してください。