次の方法で共有

Azure DocumentDB の信頼性

この記事では、 可用性ゾーン を使用したリージョンの回復性と、リージョン 間のディザスター リカバリーと Azure DocumentDB のビジネス継続性について詳しく説明します。

Azure における信頼性のアーキテクチャ概要については、「Azure の信頼性」を参照してください。

可用性ゾーンのサポート

可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

可用性ゾーンのサポートを得るには、高可用性 (HA) を有効にする必要があります。

HA は、クラスター内のすべてのシャードのスタンバイ レプリカを維持して、データベースのダウンタイムを回避します。 シャードがダウンした場合、Azure DocumentDB は受信接続を失敗したシャードからスタンバイ レプリカに切り替えます。

可用性ゾーンをサポートするリージョンで HA が有効になっている場合、HA レプリカ シャードはプライマリ シャードとは異なる可用性ゾーンにプロビジョニングされます。 HA レプリカは、プライマリ シャードが失敗しない限り、クライアントから要求を受信しません。

HA が無効になっている場合、各シャードには独自のローカル冗長ストレージ (LRS) があり、3 つの同期レプリカが Azure Storage サービスによって維持されます。 1 つのレプリカ エラーが発生した場合、Azure Storage サービスでエラーが検出され、関連するデータが透過的に再作成されます。 LRS ストレージの持続性については、「冗長オプションの概要」を参照してください。 ただし、リージョンで障害が発生した場合は、広範なダウンタイムとデータ損失の可能性があるリスクが発生します。

可用性ゾーンが有効になっているリソースを作成する

可用性ゾーンを有効にするには、クラスターの作成時に、または Azure portal 内の既存のクラスターの [スケール] セクションで、指定できます。高可用性 (HA) を有効にする必要があります。

リージョン間のディザスター リカバリーおよび事業継続

ディザスター リカバリー (DR) とは、自然災害やデプロイの失敗など、ダウンタイムやデータ損失につながる影響の大きいイベントから組織が復旧するために使用するプラクティスを指します。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を開始する前に、 ディザスター リカバリー戦略の設計に関する推奨事項を参照してください。

DR の場合、Microsoft は 共有責任モデルを使用します。 このモデルでは、Microsoft はベースライン インフラストラクチャとプラットフォーム サービスを確実に利用できるようにします。 ただし、多くの Azure サービスでは、データが自動的にレプリケートされたり、障害が発生したリージョンから別の有効なリージョンにクロスレプリケートされたりすることはありません。 それらのサービスに対して、ワークロードに適したディザスター リカバリー計画を設定する責任はユーザーにあります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されています。 サービス固有の機能を使用して高速復旧をサポートし、DR プランの開発に役立ちます。

Azure DocumentDB には、組み込みの自動フェールオーバーやディザスター リカバリーは用意されていません。 高可用性の計画は、ソリューションがスケーリングするにつれて重要な手順となります。

単一リージョンの地域でのディザスター リカバリー

アップタイムを最大化するには、ビジネス継続性を維持し、Azure DocumentDB を使用したディザスター リカバリーの準備を事前に計画してください。

Azure サービスはアップタイムを最大化するように設計されていますが、計画外のサービス停止が発生する可能性があります。 ディザスター リカバリー計画により、リージョン規模のサービス停止に対処するための戦略を用意することができます。

Azure DocumentDB は、データのバックアップを定期的に自動的に取得します。 自動バックアップは、データベース操作のパフォーマンスや可用性に影響を与えずに取得されます。 すべてのバックアップはバックグラウンドで自動的に実行され、ストレージ サービス内のソース データとは別に格納されます。 これらの自動バックアップは、リソースを誤って削除または変更し、後で元のバージョンが必要となるシナリオで役立ちます。

自動バックアップは、クラスターが現在アクティブであるか、最近削除されたかに基づいて、さまざまな間隔で保持されます。

保持期間
アクティブなクラスター 35 日
削除されたクラスター 7 日

高可用性向けの設計

運用環境のワークロードを実行する重要な Azure DocumentDB クラスターでは、高可用性 (HA) を有効にする必要があります。 HA 対応クラスターでは、各シャードは、プライマリと、別の可用性ゾーン内にプロビジョニングされたホット スタンバイ シャードとして機能します。 プライマリおよびセカンダリ シャード間のレプリケーションは、既定では同期です。 データベースに対する変更は、そのデータベースからの応答が受信される前に、プライマリおよびセカンダリ (ホット スタンバイ) シャードの両方で保持されます。

サービスは、クラスターの各プライマリおよびセカンダリ シャードへの正常性チェックとハートビートを管理します。 ゾーンまたはリージョンの停止によってプライマリ シャードが使用できなくなった場合、セカンダリ シャードが自動的に新しいプライマリに昇格され、次のセカンダリ シャードがその新しいプライマリ用に構築されます。 さらに、セカンダリ シャードが使用できなくなった場合、サービスではプライマリからのデータの完全なコピーを含む、新しいセカンダリ シャードが自動的に作成されます。

サービスでプライマリからセカンダリ シャードへのフェールオーバーがトリガーされた場合、接続はその新しいプライマリ シャードに内部的にシームレスにルーティングされます。

プライマリとセカンダリ シャード間の同期レプリケーションでは、フェールオーバーが発生してもデータ損失が発生しないことが保証されます。

次のステップ

  • Last updated on