クラウド規模の分析のためのビジネス継続性とディザスター リカバリー

クラウド サービスのアーキテクチャを設計するときは、可用性の要件と、サービスで中断が発生したときの対応について考慮します。 問題は特定のインスタンスに限定またはリージョン全域にわたる可能性があります。 両方について計画しておくことが重要です。 回復時刻の目標と回復ポイントの目標によっては、高可用性とディザスター リカバリーのために積極的な戦略を選択することをお勧めします。

高可用性とディザスター リカバリーを組み合わせることもできます。 2 つの領域は、特にデータに関する戦略が若干異なります。 詳細については、「Microsoft Azure Well-Architected Framework」と、その信頼性についての原則に関するページを参照してください。

障害を防ごうとするのではなく、障害は発生する可能性があること、そして実際に発生することを事前に受け入れます。 ライフサイクルにおいて、障害が発生した単一コンポーネントの影響を最小限に抑えます。 許容できるコスト、回復ポイントの目標、回復時刻の目標によって、実装するソリューションの種類が決まります。

バックアップ戦略

リージョン間での分散コンピューティングを実装するには、多くの代替方法を利用できます。 戦略は、ビジネス要件とアプリケーション環境に合わせて調整する必要があります。 大まかに言えば、方法は以下のカテゴリに分類できます。

• バックアップと復元: 障害が発生する前の最後のバックアップ コピーからデータベース アプリケーションを復元します。 この方法は、一般的にデータの破損または偶発的な削除の後に使用されます。

• 災害発生時の再デプロイ: 災害時にアプリケーションを一から再デプロイします。 この方法は、復旧時間を保証する必要がない重要性の低いアプリケーションに適しています。

• ウォーム スペア (アクティブ/パッシブ): 代替リージョンにセカンダリ ホステッド サービスを作成します。 最小容量を保証するようにロールをデプロイします。 このロールは運用環境のトラフィックを受信しません。 この方法は、リージョン間にトラフィックを分散するように設計されていないアプリケーションに有用です。

• ホット スペア (アクティブ/アクティブ) : 複数のリージョンで運用負荷を受信するようにアプリケーションを設計します。 各リージョンのクラウド サービスを、ディザスター リカバリーのために必要な容量よりも大きい容量で構成する場合があります。 そうではなく、災害およびフェールオーバー時にクラウド サービスを必要に応じてスケールアウトすることができます。

  この方法は、アプリケーション設計に投資を必要としますが、利点があります。 復旧時間が短く、保証されています。 すべての復旧場所で連続してテストを実行でき、容量を有効に使用できます。 データベース アプリケーションの場合、この方法には、1 つの接続ポイントと同期する 2 つのデータベース用のロード バランサーが含まれます。

Azure サービスのディザスター リカバリーと高可用性

以下のセクションでは、さまざまな Azure サービスについて説明します。

Azure Cosmos DB

Azure Cosmos DB の高可用性の概要については、「Azure Cosmos DB で高可用性を実現する方法」を参照してください。

Azure Data Factory

データ統合とデータ製品には、Azure Data Factory にリンクされた Azure DevOps リポジトリが存在する可能性があります。 ダウンタイムを最小限に抑えて、パイプラインを別の Data Factory にデプロイすることができます。 GitHub および Azure DevOps リポジトリとは別に、コード バージョン管理ソフトウェアを使用するには、Azure Data Factory SDK を使用して、パイプラインやその他の Azure Data Factory オブジェクトを作成します。

Azure Data Lake

Azure Data Lake Storage Gen2 においては、局所的なハードウェア障害に備えて、既に 3 倍のレプリケーションがサポートされています。 ゾーン冗長ストレージ (ZRS) や geo ゾーン冗長ストレージ (GZRS) などのその他のレプリケーション オプションを使用すると、高可用性が向上します。 geo 冗長ストレージ (GRS) と読み取りアクセス geo 冗長ストレージ (RA-GRS) を使用すると、ディザスター リカバリーを向上させることができます。 高可用性を実現するために、サービスの中断が発生した場合は、ワークロードからできるだけ早く最新のデータにアクセスする必要があります。 ワークロードは、レプリケートされたインスタンスにローカルで、または新しいリージョンに切り替えることができます。

RA-GRS または GRS として構成されたストレージ アカウントは、ディザスター リカバリー計画の一部にすることができますが、回復ポイントの目標 (RPO) と目標復旧時間 (RTO) を分析し、2 つの異なる Azure リージョンにデータをコピーするデュアル ロード シナリオなどの他のオプションを確認する必要があります。

各データ ランディング ゾーンには、データ製品の回復ポイントの目標が必要です。 各データ ランディング ゾーンに、そのユース ケース用に定義されたレプリケーション戦略が必要です。

詳細については、「ディザスター リカバリーとストレージ アカウントのフェールオーバー」を参照してください。

Azure Databricks

Azure Databricks クラスターのディザスター リカバリーア ーキテクチャの概要については、「Azure Databricks クラスターに対するリージョンのディザスター リカバリー」を参照してください。

Azure Machine Learning

Azure Machine Learning の高可用性の概要については、「事業継続とディザスター リカバリーのためのフェールオーバー」を参照してください。

Azure Key Vault

Azure Key Vault には、可用性を維持し、データの損失を防ぐうえで役立つ機能が用意されています。 業務上の正当かつ重要な理由がある場合にのみ、シークレットをバックアップするようにしてください。 キー コンテナーにシークレットをバックアップすると、シークレットの有効期限が切れたりシークレットのローテーションを行ったりした際に、ログ、アクセス許可、およびバックアップの一式を複数維持しなければならないなど、運用上の負担が発生する可能性があります。 詳細については、「Azure Key Vault のバックアップ」を参照してください。

Key Vault を使用すると、障害状況下で可用性を維持できます。 ユーザーが介入することなく、要求がペア リージョンにフェールオーバーされます。 詳細については、「Azure Key Vault の可用性と冗長性」を参照してください。 別の方法として、シークレットとその他の Key Vault アーティファクトを適切なアクセス許可を持つセカンダリ コンテナーに格納することを検討することができます。 このパターンは、コンテナーをアプリケーションと同じリージョンに配置する必要があるアプリケーションに適している場合があります。

Azure SQL Database

Azure SQL Database を使用した事業継続性の概要については、Azure SQL Database による事業継続性の概要に関するページを参照してください。

Azure Synapse Analytics

Azure Synapse Analytics を使用した事業継続性の概要については、Azure Synapse Analytics の高可用性に関するページを参照してください。

次の手順

• データ ガバナンスの概要