ビジネス継続性、高可用性、ディザスターリカバリーとは

この記事では、高可用性とディザスターリカバリー設計によるリスク管理の観点から、ビジネス継続性とビジネス継続性の計画を定義し、説明します。この記事は、独自のビジネス継続性のニーズを満たす方法について明示的なガイダンスを提供するものではありませんが、Microsoft の信頼性ガイダンス全体で使用される概念を理解するのに役立ちます。

"ビジネス継続性" は、障害、停止、災害が発生しても企業が事業を継続できる状態を指します。ビジネス継続性には、予防的な計画、準備、回復性があるシステムとプロセスの実装が必要です。

ビジネス継続性の計画には、リスクを特定、理解、分類、管理することが必要です。リスクとその可能性を理解することに基づいて、ビジネスニーズに合った高可用性 (HA) とディザスターリカバリー (DR) 戦略を実現するための健全なビジネス継続性計画を設計できます。

"高可用性" とは、日々の問題に対する回復性を備え、可用性に関するビジネスニーズを満たすソリューションを設計することです。

"ディザスターリカバリー" とは、一般的でないリスクや、発生する可能性のある致命的な停止に対処する方法を計画することです。

ビジネス継続性

一般に、クラウドソリューションはビジネス運用に直接関連付けられています。クラウドソリューションが利用できなくなったり、重大な問題が発生したりするたびに、ビジネス運用に深刻な影響が出る可能性があります。影響が重大な場合はビジネス継続性が損なわれる可能性があります。

ビジネス継続性に対する重大な影響には次のようなものがあります。

事業収入の損失。
ユーザーに重要なサービスを提供できない。
顧客または他の当事者に対するコミットメント違反。

ビジネス上の期待と障害の結果を理解して、ワークロードを設計、実装、運用する関係者を含む重要な利害関係者に伝えることが重要です。そうすると、それらの利害関係者は、そのビジョンの達成に必要なコストを分担することで対応します。通常、予算やその他の制約に基づいて、そのビジョンの交渉と修正のプロセスがあります。

事業継続計画

ビジネス継続性への悪影響を制御または完全に回避するには、"ビジネス継続性計画" を事前に作成することが重要です。ビジネス継続性計画は、リスク評価と、さまざまなアプローチを通じてそれらのリスクを制御する方法の開発に基づいています。軽減すべき具体的なリスクとアプローチは、組織とワークロードごとに異なります。

ビジネス継続性計画では、クラウドプラットフォーム自体の回復性機能だけでなく、アプリケーションの機能も考慮します。堅牢なビジネス継続性計画には、要員、ビジネス関連の手動または自動化されたプロセス、その他のテクノロジなど、ビジネスにおけるサポートのあらゆる側面も組み込まれています。

ビジネス継続性計画には、次の一連の手順を含める必要があります。

重要度レベルの分類。ワークロードは、ビジネスにとっての重要度に基づいて、異なる重要度レベルに分類できます。各レベルには可用性に関する要件が異なるため、ビジネス継続性計画の要件が異なります。ワークロードのクリティカルレベルを決定するには、「 Well-Architected Framework - 重要度レベルを選択する」を参照してください。
リスクの識別。ワークロードの可用性または機能に対するリスクを特定します。考えられるリスクは、ネットワークの問題、ハードウェア障害、人的エラー、リージョンの停止などです。各リスクの影響を理解します。
リスク分類。各リスクを、HA のための計画に組み込むべき一般的なリスクと、DR 計画の一部とする一般的でないリスクのいずれかとして分類します。
リスクの軽減。リスクを最小限に抑えたり軽減したりするために、冗長性、レプリケーション、フェールオーバー、バックアップを使用するなどの HA または DR の軽減戦略を設計します。また、技術面以外の、およびプロセスベースの軽減策と制御を検討します。

ビジネス継続性計画はプロセスであり、1 回限りのイベントではありません。作成されたビジネス継続性計画は、関連性が高く効果的であり、現在のビジネスニーズをサポートしていることを確認するために、定期的に見直して更新する必要があります。

リスクの特定

ビジネス継続性計画の最初のフェーズは、ワークロードの可用性または機能に対するリスクを特定することです。各リスクを分析して、その可能性と重大度を理解する必要があります。重大度は、潜在的なダウンタイムやデータ損失、およびソリューション設計の残りの部分で悪影響を補えるかどうかを考慮したものである必要があります。

次の表は、リスクを発生の可能性の高い順に並べたものであり、すべてのリスクを網羅した一覧ではありません。

リスクの例	Description	規則性 (確率)
一時的なネットワークの問題	ネットワークスタックのコンポーネントの一時的な障害。短時間 (通常は数秒以下) で復旧できます。	レギュラー
仮想マシンの再起動	使用している仮想マシン、または依存サービスによって使用されている仮想マシンの再起動。再起動は、仮想マシンがクラッシュしたり、パッチを適用する必要が生じたりするために発生する可能性があります。	レギュラー
ハードウェアの障害	ハードウェアノード、ラック、クラスターなど、データセンター内のコンポーネントの障害。	ときどき
データセンターの停止	停電、ネットワーク接続の問題、冷暖房の問題など、データセンターの大部分または全体に影響を及ぼす停止。	まれ
リージョンの障害	大規模な自然災害など、大都市圏全体またはより広い地域に影響を与える停止。	非常にまれ

ビジネス継続性の計画は、クラウドプラットフォームとインフラストラクチャについてだけ考えればよいのではありません。人為的ミスのリスクを考慮することが重要です。さらに、従来はセキュリティ、パフォーマンス、または運用上のリスクと見なされていたであろう一部のリスクも、ソリューションの可用性に影響を与えるため、信頼性リスクと見なす必要があります。

いくつかの例を次に示します。

リスクの例	Description
データの損失または破損	データが誤って、またはランサムウェア攻撃などのセキュリティ侵害によって、削除、上書きされたり、破損したりする。
ソフトウェアのバグ	新しいコードまたは更新されたコードをデプロイしたことで、可用性または整合性に影響を与えるバグが発生し、ワークロードが正常に動作しなくなる。
デプロイ失敗	新しいコンポーネントまたはバージョンのデプロイが失敗し、ソリューションが一貫性のない状態になる。
サービス拒否攻撃	ソリューションの正当な使用を妨げるためにシステムが攻撃された。
不正な管理者	管理者特権を持つユーザーが、システムに対して意図的に有害なアクションを実行した。
アプリケーションへの予期しないトラフィックの流入	トラフィックの急増により、システムのリソースが圧迫されている。

"障害モード分析" (FMA) は、ワークロードまたはそのコンポーネントにどのように障害が発生する可能性があり、そのような状況でソリューションがどのように動作するかを特定するプロセスです。詳細については。「障害モード分析を実行するための推奨事項」を参照してください。

リスク分類

ビジネス継続性計画では、一般的なリスクと一般的でないリスクの両方に対処する必要があります。

"一般的なリスク" は計画に組み込まれており、想定されています。たとえば、クラウド環境では、ネットワークの短時間の停止、パッチによる機器の再起動、サービスがビジー状態の場合のタイムアウトなど、一時的な障害や障害が発生するのが一般的です。これらのイベントは定常的に発生するため、ワークロードにはこれらに対する回復性が必要です。

高可用性戦略では、この種類の各リスクを考慮して制御する必要があります。
"一般的でないリスク" は、自然災害や大規模なネットワーク攻撃など、予期しないイベントの結果であり、致命的な停止につながる可能性があります。

ディザスターリカバリープロセスは、このようなまれなリスクに対処します。

高可用性とディザスターリカバリーは相互に関連しているため、両方の戦略を一緒に計画することが重要です。

リスク分類はワークロードアーキテクチャとビジネス要件に依存し、一部のリスクは 1 つのワークロードの場合は HA、別のワークロードの場合は DR として分類できます。たとえば、Azureリージョンの完全な停止は、通常、そのリージョンのワークロードに対する DR リスクと見なされます。ただし、アクティブ/アクティブ構成で複数のAzureリージョンを使用するワークロードでは、完全なレプリケーション、冗長性、および自動リージョンフェールオーバーを使用する場合、リージョンの停止は HA リスクとして分類されます。

リスク軽減

リスク軽減は、ビジネス継続性に対するリスクを最小限に抑える、あるいは軽減するための HA または DR の戦略を策定することです。リスク軽減策には、テクノロジベースのものと人間中心のものがあります。

テクノロジベースのリスク軽減策

テクノロジベースのリスク軽減策では、ワークロードがどのように実装および構成されているかに基づくリスクコントロールが使用されます。次に例を示します。

冗長性
データのレプリケーション
フェールオーバー
Backups

テクノロジベースのリスクコントロールは、ビジネス継続性計画のコンテキスト内で考慮する必要があります。

例えば次が挙げられます。

少ないダウンタイムの要件 一部のビジネス継続性計画では、厳格な高可用性の要件により、どのような形でもダウンタイムのリスクを許容できません。特定のテクノロジベースの制御では、人が通知を受け取ってから応答する時間が必要になる場合があります。低速な手動プロセスを含むテクノロジベースのリスクコントロールは、リスク軽減戦略に含めることに適さない可能性があります。
部分的な障害に対する許容範囲。 一部のビジネス継続性計画では、"機能低下状態" で実行されるワークフローを許容できます。ソリューションが機能低下状態で動作する場合、一部のコンポーネントが無効または動作不能である可能性がありますが、基幹業務は引き続き実行できます。詳細については、「自己修復と自己保存に関する推奨事項」を参照してください。

人間中心のリスク軽減策

人間中心のリスク軽減策では、次のようなビジネスプロセスに基づくリスクコントロールが使用されます。

応答手順書を起動する。
手動操作に戻ります。
トレーニングとカルチャの変化。

Important

ワークロードを設計、実装、運用、進化させる個人は、適格であることが求められ、懸念がある場合は発言し、システムに対する責任感を持つことが奨励される必要があります。

人間中心のリスクコントロールは、多くの場合、テクノロジベースのコントロールよりもスピードが遅く、人為的なエラーが発生しやすいため、適切なビジネス継続性計画には、実行中のシステムの状態を変更するあらゆるものに対する正式な変更制御プロセスを含める必要があります。たとえば、次のプロセスを実装することを検討してください。

ワークロードの重要度に従って、ワークロードを厳密にテストします。変更関連の問題を防ぐには、ワークロードに加えられた変更を必ずテストしてください。
ワークロードの安全なデプロイプラクティスの一環として、戦略的な品質ゲートを導入します。詳細については、「安全なデプロイの実践に関する推奨事項」を参照してください。
アドホックな運用アクセスとデータ操作の手順を形式化します。これらのアクティビティは、どんなに軽微であっても、信頼性インシデントを引き起こす高いリスクを伴う可能性があります。手順には、別のエンジニアとのペアリング、チェックリストの使用、スクリプトの実行または変更の適用前のピアレビューの実施が含まれる場合があります。

高可用性

高可用性とは、一時的な障害や断続的な障害が発生した場合でも、特定のワークロードが必要なレベルのアップタイムを日常的に維持できる状態です。これらのイベントは定常的に発生するため、各ワークロードは、特定のアプリケーションの要件と顧客の期待事項に従って、高可用性を実現するように設計および構成されていることが重要です。各ワークロードの HA は、ビジネス継続性計画に影響します。

HA はワークロードごとに異なる可能性があるため、高可用性を決定する際に要件と顧客の期待事項を理解することが重要です。たとえば、組織がオフィス用品の注文に使用するアプリケーションで必要なアップタイムは、比較的低レベルになる可能性があります。一方、重要な金融アプリケーションでは、はるかに高いアップタイムが必要になるでしょう。ワークロード内であっても、"フロー" によって要件が異なる場合があります。たとえば、eコマースアプリケーションでは、顧客の閲覧と注文をサポートするフローが、注文フルフィルメントフローやバックオフィス処理フローよりも重要になるでしょう。フローの詳細については、「フローの識別と評価に関する推奨事項」を参照してください。

一般的に、アップタイムは "9 の数" に基づいて稼働率のパーセンテージで測定されています。アップタイムの割合は、特定の期間に許容されるダウンタイムの量に関係します。いくつかの例を次に示します。

99.9% のアップタイム要件 (スリーナイン) では、1 か月に約 43 分間のダウンタイムが許容されます。
99.95% のアップタイム要件 (スリーアンドハーフナイン) では、1 か月に約 21 分間のダウンタイムが許容されます。

アップタイム要件が高いほど、障害に対する許容度が低くなり、そのレベルの可用性に到達するために必要な作業が多くなります。アップタイムは、ノードのような 1 つのコンポーネントの稼働状態ではなく、ワークロード全体の全体的な可用性で測定されます。

Important

妥当なレベル以上に高い信頼性レベルに達するようにソリューションを過剰に設計しないでください。ビジネス要件を使用して意思決定を導きます。

高可用性の設計要素

HA 要件を達成するために、ワークロードに多数の設計要素が含まれることがあります。このセクションでは一般的な要素の一部を以下に示して説明します。

注

一部のワークロードは "ミッションクリティカル" です。つまり、ダウンタイムが人間の生命と安全に重大な影響を与えたり、大きな財政的損失を招いたりする可能性があります。ミッションクリティカルなワークロードを設計する場合、ソリューションを設計してビジネス継続性を管理するときに考慮する必要がある特定の事項があります。詳細については、「Azure Well-Architected Framework: ミッションクリティカルなワークロードを参照してください。

Azureで高可用性をサポートするサービスとレベル

多くのAzure サービスは高可用性を実現するように設計されており、高可用性ワークロードの構築に使用できます。いくつかの例を次に示します。

Azure Virtual Machine Scale Sets は、VM インスタンスを自動的に作成および管理し、それらの VM インスタンスを分散してインフラストラクチャの障害の影響を軽減することで、仮想マシン (VM) の高可用性を実現します。
Azure App Service は、異常なノードから正常なノードにワーカーを自動的に移動したり、多くの一般的な障害の種類から自己復旧する機能を提供するなど、さまざまな方法で高可用性を実現します。

それぞれのサービス信頼性ガイドを使用してサービスの機能を理解し、使用するレベルを決め、高可用性戦略に含める機能を決定します。

各サービスのサービスレベルアグリーメント (SLA) を確認して、予想される可用性レベルと満たす必要がある条件を理解します。特定のレベルの可用性を実現するには、特定のレベルのサービスを選択または回避することが必要になる場合があります。 Microsoft の一部のサービスは、SLA が提供されない (開発レベルや Basic レベルなど)、または実行中のシステムにリソースが再要求される可能性がある (スポットベースのオファリングなど) ことを前提に提供されています。また、一部のレベルでは、可用性ゾーンのサポートなどの信頼性機能が追加されています。

障害耐性

フォールトトレランスは、障害が発生した場合に、一定の定義済みキャパシティでシステムの動作を継続する機能です。たとえば、Web アプリケーションは、1 つの Web サーバーで障害が発生した場合でも動作を継続するように設計されている場合があります。フォールトトレランスは、冗長性、フェールオーバー、パーティション分割、穏やかな機能低下、その他の手法によって実現できます。

フォールトトレランスでは、アプリケーションが一時的な障害を処理することも必要です。独自のコードをビルドするときに、一時的な障害処理を自分で有効にすることが必要になる場合があります。一部のAzure サービスでは、状況によっては一時的な障害処理が組み込まれています。たとえば、既定では、Azure Logic Appsは失敗した要求を他のサービスに自動的に再試行します。詳細については、「一時的な障害を処理するための推奨事項」を参照してください。

冗長性

冗長性とは、インスタンスまたはデータを複製してワークロードの信頼性を高めるプラクティスです。

冗長性を実現するには、レプリカまたは冗長インスタンスを次の 1 つ以上の方法で分散します。

データセンター内 ("ローカル冗長")
リージョン内の可用性ゾーン間 ("ゾーン冗長")
リージョン間 (地理的冗長性)

一部のAzure サービスで冗長性オプションが提供される例をいくつか次に示します。

Azure App Service を使用すると、アプリケーションの複数のインスタンスを実行して、1 つのインスタンスで障害が発生した場合でもアプリケーションを確実に使用できます。ゾーン冗長を有効にした場合、これらのインスタンスは、使用するAzure リージョン内の複数の可用性ゾーンに分散されます。
Azure Storage は、少なくとも 3 回データを自動的にレプリケートすることで高可用性を実現します。ゾーン冗長ストレージ (ZRS) を有効にすることで、それらのレプリカを可用性ゾーン間で分散できます。また、多くのリージョンでは、geo 冗長ストレージ (GRS) を使用してリージョン間でストレージデータをレプリケートすることもできます。
Azure SQL Database には複数のレプリカがあり、1 つのレプリカで障害が発生した場合でもデータを確実に使用できます。

冗長性のしくみの詳細については、「冗長性、レプリケーション、バックアップ」を参照してください。ソリューションに冗長性を適用する方法については、冗長性の設計に関する推奨事項と、可用性ゾーンとリージョンを使用するための推奨事項を参照してください。

スケーラビリティと弾力性

スケーラビリティと弾力性は、リソースの追加と削除によって増加した負荷を処理し (スケーラビリティ)、要件の変化に合わせて迅速に行う (弾力性) システムの機能です。スケーラビリティと弾力性は、ピーク負荷時にシステムの可用性を維持するのに役立ちます。

多くのAzure サービスでは、スケーラビリティがサポートされています。いくつかの例を次に示します。

Azure Virtual Machine Scale Sets、Azure API Management、およびその他のいくつかのサービスでは、Azure Monitor自動スケーリングがサポートされています。自動スケーリングAzure Monitor使用すると、"CPU が常に 80%を超えたとき、別のインスタンスを追加する" などのポリシーを指定できます。
Azure Functions は、要求を処理するためにインスタンスを動的にプロビジョニングできます。
Azure Cosmos DB では、autoscale throughput がサポートされます。この場合、サービスは、指定したポリシーに基づいてデータベースに割り当てられたリソースを自動的に管理できます。

スケーラビリティは、部分的または完全な誤動作時に考慮すべき重要な要素です。レプリカまたはコンピューティングインスタンスが使用不可になった場合は、障害が発生したノードで以前処理されていた負荷を処理するために、残りのコンポーネントの負荷を増やすことが必要になる場合があります。システムが負荷の予想される変更を処理するのに十分な速さでスケーリングできない場合は、"オーバープロビジョニング" を検討してください。

スケーラブルで弾力性のあるシステムを設計する方法の詳細については、「信頼性の高いスケーリング戦略を設計するための推奨事項」を参照してください。

ダウンタイムなしのデプロイ手法

デプロイやその他のシステム変更により、ダウンタイムの重大なリスクが生じます。ダウンタイムのリスクは高可用性の要件の課題であるため、ダウンタイムなしのデプロイプラクティスを使用して、ダウンタイムを必要としない更新と構成の変更を行うことが重要です。

ダウンタイムなしのデプロイ手法には、次のようなものがあります。

リソースのサブセットを一度に更新する。
新しいデプロイに到達するトラフィックの量を制御する。
ユーザーまたはシステムへの影響を監視する。
以前の既知の適切なデプロイにロールバックするなどして、問題を迅速に修復する。

ダウンタイムなしのデプロイ手法の詳細については、「安全なデプロイプラクティス」を参照してください。

Azure自体は、独自のサービスにダウンタイムなしのデプロイアプローチを使用します。ご自身の独自アプリケーションをビルドする場合は、次のようなさまざまな方法でダウンタイムなしのデプロイを採用できます。

Azure Container Apps では、アプリケーションの複数のリビジョンが提供されます。これを使用して、ダウンタイムゼロのデプロイを実現できます。
Azure Kubernetes Service (AKS) では、ダウンタイムなしのさまざまなデプロイ手法がサポートされています。

ダウンタイムなしのデプロイは、多くの場合、アプリケーションのデプロイに関連しますが、構成変更の場合にも使用する必要があります。構成変更を安全に適用する方法を次に示します。

Azure Storage では、storage アカウントアクセスキーを複数のステージで変更できるため、キーローテーション操作中のダウンタイムを防ぐことができます。
Azure App Configuration には、feature flags、snapshots、および構成変更の適用方法を制御するのに役立つその他の機能が用意されています。

ダウンタイムなしのデプロイを実装しない場合は、"メンテナンスウィンドウ" を定義して、ユーザーが予期したタイミングでシステムを変更できます。

自動テスト

HA のスコープ内にあると考えられる停止や障害に耐えるソリューションの能力をテストすることが重要です。これらの障害の多くは、テスト環境でシミュレートできます。さまざまな種類の障害を自動的に許容または復旧するソリューションの機能をテストすることは、"カオスエンジニアリング" と呼ばれます。カオスエンジニアリングは、HA の厳格な標準を持つ成熟した組織にとって重要です。 Azure Chaos Studio は、一般的な障害の種類をシミュレートできるカオスエンジニアリングツールです。

詳細については、「信頼性テスト戦略を設計するための推奨事項」を参照してください。

監視とアラート

監視を使用すると、自動化された軽減策が実行された場合でも、システムの正常性を把握できます。監視は、ソリューションがどのように動作しているかを理解し、エラー率の増加やリソース消費量の増加などの障害の早期シグナルを監視するために重要です。アラートを使用すると、環境内の重要な変化を事前に受け取ることができます。

Azureには、次のようなさまざまな監視とアラート機能が用意されています。

Azure Monitor はAzureリソースとアプリケーションからログとメトリックを収集し、アラートを送信してダッシュボードにデータを表示できます。
Azure Monitor Application Insights は、アプリケーションの詳細な監視を提供します。
Azure Service Health と Azure Resource Health Azure プラットフォームとリソースの正常性を監視します。
Scheduled Events は、仮想マシンのメンテナンスがいつ予定されているかを知らせます。

詳細については、「信頼性の高い監視およびアラート戦略を設計するための推奨事項」を参照してください。

障害復旧

"災害" は、アプリケーションの設計上の高可用性の側面によって軽減できる影響よりも大きく、影響が長く続く、明確でまれな重大なイベントです。災害の例を次に示します。

自然災害 (ハリケーン、地震、洪水、火災など)。
誤って運用環境のデータを削除したり、ファイアウォールの設定ミスにより機密データが公開されたりするなど、重大な影響をもたらす人為的エラー。
サービス拒否やランサムウェア攻撃のように、データの破損、データ損失、サービスの停止につながる重大なセキュリティインシデント。

"ディザスターリカバリー" では、このような状況にどのように対応するかを計画します。

注

これらのイベントが発生する可能性を最小限に抑えるには、ソリューション全体で推奨されるプラクティスに従う必要があります。ただし、慎重に事前に計画した後でも、このような状況が発生した場合の対応方法を計画することをお勧めします。

ディザスターリカバリーの要件

災害の発生頻度と深刻度により、DR 計画では対応に対する期待が異なります。多くの組織は、災害シナリオでは、ある程度のダウンタイムやデータ損失は避けられないという事実を受け入れます。完全な DR 計画では、各フローに対して次の重要なビジネス要件を指定する必要があります。

回復ポイントの目標 (RPO) は、災害発生時に許容できるデータ損失の最大期間です。 RPO は、"30 分間のデータ" や "4 時間のデータ" など、時間単位で測定されます。
目標復旧時間 (RTO) は、災害発生時に許容されるダウンタイムの最大継続時間です。"ダウンタイム" は仕様によって定義されます。 RTO は、"8 時間のダウンタイム" のように、時間単位でも測定されます。

RTO と RPO の期間を時間単位で測定した、災害の例のタイムラインを示す図。

ワークロード内の各コンポーネントまたはフローには、個々の RPO 値と RTO 値が存在する場合があります。要件を決定する際に、ディザスターシナリオのリスクと潜在的な復旧戦略を調べます。 RPO と RTO を指定するプロセスにより、固有のビジネス上の懸念事項 (コスト、影響、データ損失など) の結果として、ワークロードの DR 要件が効果的に作成されます。

注

RTO と RPO ゼロ (障害発生時のダウンタイムやデータ損失なし) を目指したくなる一方で、実際には実装が困難でコストがかかります。技術的およびビジネスの利害関係者がこれらの要件について一緒に話し合い、現実的な要件を決定することが重要です。詳細については、「信頼性目標の定義に関する推奨事項」を参照してください。

ディザスターリカバリー計画

障害の原因に関係なく、明確に定義されたテスト可能な DR 計画を作成することが重要です。この計画は、それを積極的にサポートするためのインフラストラクチャとアプリケーション設計の一部として使用されます。さまざまな種類の状況に対して複数の DR 計画を作成できます。 DR 計画は、多くの場合、プロセス制御と手動介入に依存します。

DR は、Azureの自動機能ではありません。ただし、多くのサービスには、DR 戦略をサポートするために使用できる機能が用意されています。各Azure サービスの責任ガイドを確認して、サービスのしくみとその機能を理解し、それらの機能を DR プランにマップする必要があります。

強力な DR 計画により、戦略が決定的なアクションに変わります。災害に対応し、ダウンタイムを最小限に抑え、ビジネス継続性を確保するための明確なロードマップを提供します。

これを可能にするには、明確な Runbook、明確に定義された通信計画、構造化されたエスカレーションパスを含むように、すべての DR プランを文書化する必要があります。これらの DR プラン要素の詳細については、「 Well-Architected フレームワーク - DR プランを文書化する」を参照してください。

次のセクションでは、ディザスターリカバリー計画の一般的なアプローチの一覧を示し、Azureがそれらを実現するのにどのように役立つかについて説明します。

フェールオーバーとフェールバック

一部のディザスターリカバリー計画では、別の場所にセカンダリデプロイをプロビジョニングする必要があります。障害によってソリューションのプライマリデプロイに影響があった場合、トラフィックは他のサイトに "フェールオーバー" されます。フェールオーバーには慎重な計画と実装が必要です。 Azureでは、次のようなフェールオーバーを支援するさまざまなサービスが提供されます。

Azure Site Recovery では、Azureのオンプレミス環境と仮想マシンでホストされるソリューションに対する自動フェールオーバーが提供されます。
Azure Front Door と Azure Traffic Manager では、さまざまなリージョンなど、ソリューションのさまざまなデプロイ間の受信トラフィックの自動フェールオーバーがサポートされます。

通常、プライマリインスタンスが失敗したことを検出してセカンダリインスタンスに切り替えるには、フェールオーバープロセスに時間がかかります。ワークロードの RTO がフェールオーバー時間と整合性があることを確認します。

また、"フェールバック" を検討することも重要です。これは、復旧後にプライマリリージョンに操作を復元するプロセスです。フェールバックは、計画と実装が複雑になる場合があります。たとえば、プライマリリージョンのデータは、フェールオーバーが始まった "後" に書き込まれた可能性があります。そのデータの処理方法について慎重にビジネス上の意思決定を行う必要があります。

詳細については、フェールオーバーとフェールバックに関するセクションを参照してください。

Backups

バックアップには、データのコピーを取得し、定義された期間、それを安全に保存することが含まれます。バックアップを使用すると、別のレプリカへの自動フェールオーバーが不可能な場合や、データの破損が発生した場合に、災害から復旧できます。

ディザスターリカバリー計画の一部としてバックアップを使用する場合は、次の点を考慮することが重要です。

保存場所。 ディザスターリカバリー計画の一部としてバックアップを使用する場合は、メインデータに個別に保存する必要があります。通常、バックアップは別のAzure リージョンに格納されます。
"データ損失"。一般にバックアップは頻繁には作成されないため、バックアップの復元には通常、データの損失が伴います。このため、バックアップ復旧は最後の手段として使用する必要があり、ディザスターリカバリー計画では、バックアップから復元する "前" に実行しなければならない一連の手順と復旧の試行を指定する必要があります。ワークロード RPO がバックアップ間隔と整合していることを確認することが重要です。
復旧時間多くの場合、バックアップの復元には時間がかかるため、バックアップと復元プロセスをテストして整合性を確認し、復元プロセスにかかる時間を把握することが重要です。ワークロードの RTO がバックアップの復元にかかる時間を考慮していることを確認します。

多くのAzure データおよびストレージサービスでは、次のようなバックアップがサポートされています。

Azure Backup は、仮想マシンディスク、ストレージアカウント、AKS、およびその他のさまざまなソースの自動バックアップを提供します。
Azure SQL Database や Azure Cosmos DB など、多くのAzure データベースサービスには、データベースの自動バックアップ機能があります。
Azure Key Vault には、シークレット、証明書、キーをバックアップする機能が用意されています。

バックアップと復元の復旧戦略の詳細については、「 Well-Architected Framework - バックアップと復元の復旧戦略」を参照してください。

自動化されたデプロイ

障害が発生した場合に必要なリソースを迅速にデプロイして構成するには、Bicep ファイル、ARM テンプレート、Terraform 構成ファイルなどのコードとしてのインフラストラクチャ (IaC) 資産を使用します。 IaC を使用すると、リソースを手動でデプロイおよび構成する場合と比較して、復旧時間が短縮され、エラーが発生する可能性が減ります。

テストとドリル

DR 計画と、より広範な信頼性戦略を定期的に検証してテストすることが重要です。ドリルに人に関わるプロセスをすべて含め、技術的なプロセスだけに焦点を当てないでください。

ディザスターシミュレーションで復旧プロセスをテストしていない場合は、実際の災害で使用するときに大きな問題に直面する可能性が高くなります。また、DR 計画と必要なプロセスをテストすることで、RTO の実現可能性を検証できます。