翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

序章

ワークロードは、意図した機能を正しく一貫して実行する必要があります。これを実現するには、回復性のために設計する必要があります。回復力とは、ワークロードがインフラストラクチャ、サービス、またはアプリケーションの中断から回復し、需要に合わせてコンピューティングリソースを動的に取得し、設定ミスや一時的なネットワーク問題などの中断を軽減する能力です。

ディザスタリカバリ (DR) は回復力戦略の重要な部分であり、災害発生時のワークロードの対応 (災害はビジネスに重大な悪影響を与えるイベント) に懸念があります。このレスポンスは、目標復旧時点 (RPO) と呼ばれるデータの損失を回避し、目標復旧時間 (RTO) と呼ばれるワークロードが使用できないダウンタイムを削減するためのワークロードの戦略を指定する組織のビジネス目標に基づいている必要があります。したがって、特定の 1 回限りの災害イベントの復旧目標 (RPO と RTO) を満たすには、クラウド内のワークロードの設計にレジリエンスを実装する必要があります。このアプローチは、事業継続計画 (BCP) の一環として事業継続性を維持するのに役立ちます。

このホワイトペーパーでは、ビジネスの AWS ディザスタリカバリ目標を達成するアーキテクチャを計画、設計、実装する方法に焦点を当てています。ここで共有される情報は、最高技術責任者 (CTOs)、アーキテクト、デベロッパー、運用チームメンバー、リスクの評価と軽減を担当するテクノロジー担当者を対象としています。

ディザスタリカバリと可用性

ディザスタリカバリは、耐障害性戦略のもう 1 つの重要な要素である可用性と比較できます。ディザスタリカバリは 1 回限りのイベントの目標を測定しますが、可用性目標は一定期間の平均値を測定します。

図 1 - 耐障害性の目的

可用性は、平均障害間隔 (MTBF) と平均復旧時間 (MTTR) を使用して計算されます。

このアプローチは「nines」と呼ばれ、99.9% の可用性ターゲットは「three nines」と呼ばれます。

ワークロードでは、時間ベースのアプローチを使用する代わりに、成功したリクエストと失敗したリクエストをカウントする方が簡単な場合があります。この場合、次の計算を使用できます。

ディザスタリカバリはディザスタイベントに重点を置いていますが、可用性はコンポーネントの障害、ネットワークの問題、ソフトウェアのバグ、負荷の急増など、より小規模なスケールのより一般的な中断に重点を置いています。ディザスタリカバリの目的はビジネス継続性ですが、可用性の問題は、ワークロードが意図したビジネス機能を実行するために利用できる時間を最大化することです。どちらも耐障害性戦略の一部である必要があります。

Well-Architected の実現状況の確認

AWS Well-Architected フレームワークは、クラウドでシステムを構築するときに行う決定のメリットとデメリットを理解するのに役立ちます。このフレームワークの 6 つの柱を使用することで、信頼性、セキュリティ、効率、コスト効果および持続可能なシステムを設計し、運用するためのアーキテクチャのベストプラクティスを学習できます。AWS マネジメントコンソールで無料で利用できる AWS Well-Architected Tool を使用すると、柱ごとに一連の質問に答えることで、これらのベストプラクティスに照らしてワークロードを確認できます。 https://console.aws.amazon.com/wellarchitected

このホワイトペーパーで説明されている概念は、「信頼性の柱」ホワイトペーパーに含まれるベストプラクティス、特にhttps://docs.aws.amazon.com/wellarchitected/latest/framework/a-failure-management.html「ディザスタリカバリ (DR) をどのように計画するか」という質問に詳しく説明されています。このホワイトペーパーのプラクティスを実装したら、AWS Well-Architected Tool を使用してワークロードを確認 (または再確認) してください。