Azure Cosmos DB で高可用性を実現する方法

適用対象: SQL API Cassandra API Gremlin API Table API MongoDB 用 Azure Cosmos DB API

Azure Cosmos DB は、主に 2 つの方法で高可用性を実現します。 まず、Azure Cosmos DB は、Cosmos アカウント内で構成されたリージョン間でデータをレプリケートします。 第 2 に、Azure Cosmos DB は、リージョン内にデータの 4 つのレプリカを保持します。

Azure Cosmos DB はグローバルに分散されたデータベース サービスであり、Azure を利用できるすべてのリージョンで利用できる基本サービスです。 任意の数の Azure リージョンをお客様の Azure Cosmos アカウントに関連付けることができ、お客様のデータは、自動的かつ透過的にレプリケートされます。 Azure Cosmos アカウントへのリージョンの追加と削除は、いつでも実行できます。 Cosmos DB は、お客様が利用できる 5 つの異なる Azure クラウド環境のすべてで利用できます。

  • Azure パブリック クラウドは、グローバルに利用できます。

  • Azure China 21Vianet は、Microsoft と中国最大のインターネット プロバイダーの 1 つである 21Vianet との間の独自のパートナーシップを通して利用できます。

  • Azure Germany では、データ保護受託者モデルに沿ってサービスが提供され、お客様のデータは、ドイツ国内でデータ保護受託者の役目を務める T-Systems International GmbH (Deutsche Telekom の子会社) の管理下で、ドイツ国外に移転されないことが保証されます。

  • Azure Government は、米国内の 4 つのリージョンで米国政府機関とそのパートナーが利用できます。

  • 米国国防総省 (DoD) 向け Azure Government は、米国内の 2 つのリージョンで米国国防総省が利用できます。

リージョン内では、Azure Cosmos DB は次の図に示すように、データの 4 つのコピーを物理パーティション内のレプリカとして保持します。

物理的パーティション分割

  • Azure Cosmos コンテナー内のデータは、水平方向にパーティション分割されます

  • パーティションセットは、複数のレプリカセットのコレクションです。 各リージョン内のすべてのパーティションは、すべての書き込みがレプリケートされ、レプリカの大多数によって永続的にコミットされたレプリカ セットによって保護されます。 レプリカは、最大で 10 ~ 20 個の障害ドメインに分散されます。

  • すべてのリージョンで、各パーティションがレプリケートされます。 各リージョンには Azure Cosmos コンテナーのすべてのデータ パーティションが含まれており、複数リージョンの書き込みが有効になっている場合は読み取りと書き込みの両方が可能です。

Azure Cosmos アカウントが N 個の Azure リージョンに分散している場合は、すべてのデータの少なくとも N x 4 個のコピーが存在します。 2 つ以上のリージョンで Azure Cosmos アカウントを用意すると、アプリケーションの可用性が向上し、関連するリージョン全体で低待機時間を実現できます。

可用性に関する SLA

Azure Cosmos DB は、スループット、99 パーセンタイルの待ち時間、一貫性、および高可用性を含む包括的な SLA を提供します。 次の表では、単一リージョンおよび複数リージョンのアカウントに対して Azure Cosmos DB によって提供される高可用性の保証について説明します。 書き込みの可用性をさらに高めるには、複数の書き込みリージョンが存在するように Azure Cosmos アカウントを構成してください。

操作の種類 単一リージョン 複数リージョン (単一リージョンの書き込み) 複数リージョン (複数リージョンの書き込み)
書き込み 99.99 99.99 99.999
読み取り 99.99 99.999 99.999

注意

実際には、有界整合性制約、セッション、一貫性のあるプレフィックス、および最終的整合性モデルに関する実際の書き込み可用性は、公開された SLA より大幅に高くなります。 すべての整合性レベルについての実際の読み取り可用性は、公開された SLA よりもずっと高くなります。

リージョン障害が発生した場合の Azure Cosmos DB の高可用性

まれに、一部のリージョンで障害が発生した場合でも、Azure Cosmos DB によってデータベースの高可用性が常に維持されます。 Azure Cosmos アカウントの構成に応じた、障害発生中の Azure Cosmos DB の動作の詳細を次に説明します。

  • Azure Cosmos DB では、クライアントに対して書き込み操作が承認される前に、書き込み操作を受け入れるリージョン内のレプリカのクォーラムによってデータが永続的にコミットされます。 詳細については、「整合性レベルとスループット」を参照してください。

  • 複数書き込みリージョンで構成された複数リージョン アカウントは、書き込みと読み取りの両方について高可用性を実現します。 リージョン間フェールオーバーは、Azure Cosmos DB クライアントで検出され、処理されます。 これらは瞬間的であるため、アプリケーションからの変更は必要ありません。

  • 単一リージョンのアカウントは、リージョンの障害の後で可用性を失う場合があります。 常に高可用性を確保するために、Azure Cosmos アカウントで 少なくとも 2 つのリージョン (可能であれば、少なくとも 2 つの書き込みリージョン) を設定することを常にお勧めします。

重要

SQL API を使用している場合は、向上した可用性を活用するには、指定されたすべての読み取りリージョンを使用するように Cosmos DB SDK を構成する必要があります。 詳しくは、こちらの記事を参照してください。

単一書き込みリージョンで構成された複数リージョン アカウント (書き込みリージョン障害):

  • Azure Cosmos アカウントで [自動フェールオーバーの有効化] が構成されている場合、書き込みリージョンの停止時に、Azure Cosmos アカウントによってセカンダリ リージョンが自動的に新しいプライマリ書き込みリージョンに昇格します。 有効な場合、指定したリージョンの優先順位に従って別のリージョンにフェールオーバーが発生します。

  • 手動フェールオーバーはトリガーしないでください。同期元または同期先 リージョンの停止があると成功しません。 これは、リージョン間の接続を必要とするフェールオーバー プロシージャによって必要とされる整合性チェックのためです。

  • 以前に影響を受けたリージョンがオンラインに戻ると、障害発生時にレプリケートされなかった書き込みデータは競合フィードによって使用可能になります。 アプリケーションは競合フィードを読み取り、そのアプリケーション固有のロジックに基づいて競合を解決した後、更新されたデータを必要に応じて Azure Cosmos コンテナーに書き戻すことができます。

  • 以前影響を受けた書き込みリージョンが復旧すると、自動的に読み取りリージョンとして利用可能になります。 復旧したリージョンに書き込みリージョンとして切り替えることができます。 リージョンは PowerShell、Azure CLI または Azure portal を使用して切り替えることができます。 書き込みリージョンを切り替えている間、またはその後に、データや可用性の損失が発生することはありません。アプリケーションは高可用性を維持します。

重要

運用環境のワークロードに使用される Azure Cosmos アカウントを構成して、自動フェールオーバーを有効にする ことを強くお勧めします。 これにより、Cosmos DB は、利用可能なリージョンに自動的にアカウント データベースをフェールオーバーできます。 この構成がない場合、リージョンに接続されていないため手動フェールオーバーは成功せず、書き込みリージョンの停止中は、アカウントで書き込みを利用できなくなる可能性があります。

単一書き込みリージョンで構成された複数リージョン アカウント (読み取りリージョン障害)

  • 読み取りリージョンの停止中、整合性レベルを使用しているか、3 つ以上の読み取りリージョンとの厳密な整合性を持つ Azure Cosmos アカウントでは、読み取りと書き込みの高可用性が維持されます。

  • 3 つのリージョン (書き込み 1 つ、読み取り 2 つ) で厳密な整合性を使用する Azure Cosmos アカウントでは、読み取りリージョンの停止中は書き込みの可用性が維持されます。 2 つのリージョンがあり、自動フェールオーバーが有効になっているアカウントでは、リージョンが "失敗" とマークされ、自動フェールオーバーが発生するまで、書き込みの受け入れが停止されます。

  • 影響を受けるリージョンは自動的に切断され、オフラインとマークされます。 Azure Cosmos DB SDK は、読み取り呼び出しを、優先リージョンの一覧にある次の使用可能なリージョンにリダイレクトします。

  • 優先リージョンの一覧にあるいずれのリージョンも使用可能でない場合、呼び出しは自動的に現在の書き込みリージョンに戻ります。

  • 読み取りリージョン障害を処理するアプリケーション コードは、変更する必要はありません。 影響を受けた読み取りリージョンはオンラインに戻ると、現在の書き込みリージョンと自動的に同期され、読み取り要求に再び対応できるようになります。

  • それ以降の読み取りは、アプリケーション コードを変更しなくても、回復したリージョンにリダイレクトされます。 フェールオーバー中も、以前に障害が発生したリージョンの再参加中も、読み取り整合性の保証は引き続き Azure Cosmos DB によって遵守されます。

  • Azure リージョンが永久に回復不可能になるという、まれで不運な状況でも、複数リージョンの Azure Cosmos アカウントが [厳密] の整合性で構成されていれば、データ損失は発生しません。 永久に回復不可能となった書き込みリージョンで、有界整合性制約で構成された複数リージョンの Azure Cosmos アカウントの場合、考えられるデータ損失ウィンドウは、整合性制約ウィンドウ (K または T) に制限されます (K = 100,000 回の更新、または T = 5 分で、先に発生した方となります)。 セッション、一貫性のあるプレフィックス、および最終的な整合性レベルの場合、考えられるデータ損失ウィンドウは最大 15 分に制限されます。 Azure Cosmos DB の RTO と RPO ターゲットの詳細については、「整合性レベルとデータ持続性」を参照してください。

可用性ゾーンのサポート

リージョン間の回復性に加えて、Azure Cosmos DB では、Azure Cosmos アカウントに関連付けるリージョンを選択するときに、サポートされているリージョン内での ゾーン冗長 もサポートされます。

可用性ゾーン (AZ) のサポートにより、Azure Cosmos DB では、特定のリージョン内でレプリカが複数のゾーンに配置され、ゾーンの障害に対する高可用性と回復性の提供が保証されます。 可用性ゾーンによって、待ち時間の変更なしに 99.995% の可用性 SLA が提供されます。 単一のゾーンの障害の発生時に、ゾーンの冗長性により、RPO = 0 で完全なデータの持続性を提供し、RTO = 0 で可用性を提供します。 ゾーン冗長は、リージョンのレプリケーションの補助的な機能です。 リージョンの回復性を実現するために、ゾーンの冗長性だけに依存することはできません。

ゾーン冗長は、Azure Cosmos アカウントに新しいリージョンを追加するときにのみ構成できます。 既存のリージョンの場合、ゾーン冗長を有効にするには、リージョンを削除してから、ゾーン冗長が有効な状態でゾーンを追加し直します。 単一のリージョン アカウントの場合、一時的にフェールオーバーするリージョンを 1 つ追加してから、目的のリージョンを削除してゾーン冗長が有効な状態で追加する必要があります。

Azure Cosmos アカウントに複数リージョンの書き込みを構成すると、追加のコストを必要とせずに、ゾーン冗長性を実現できます。 それ以外の場合、ゾーン冗長のサポートの料金に関する後述の表を参照してください。 可用性ゾーンが利用可能なリージョンの一覧については、可用性ゾーンに関するページを参照してください。

次の表に、さまざまなアカウント構成の高可用性機能をまとめています。

KPI AZ がない単一リージョン AZ がある単一リージョン 複数リージョン、AZ がある単一リージョンの書き込み 複数リージョン、AZ がある複数リージョンの書き込み
書き込み可用性 SLA 99.99% 99.995% 99.995% 99.999%
読み取り可用性 SLA 99.99% 99.995% 99.995% 99.999%
ゾーンの障害 – データ損失 データ損失 データ損失なし データ損失なし データ損失なし
ゾーンの障害 - 可用性 可用性の損失 可用性の損失なし 可用性の損失なし 可用性の損失なし
リージョンの障害 - データ損失 データ損失 データ損失 整合性レベルによって決まります。 詳細については、整合性、可用性、パフォーマンスのトレードオフに関するページを参照してください。 整合性レベルによって決まります。 詳細については、整合性、可用性、パフォーマンスのトレードオフに関するページを参照してください。
リージョンの障害 - 可用性 可用性の損失 可用性の損失 読み取りリージョンの障害に関して可用性の損失なし、書き込みリージョンの障害に関しては一時的 可用性の損失なし
価格 (*1 _) なし プロビジョニングされた RU/秒 x 1.25 レート プロビジョニングされた RU/秒 x 1.25 レート (_*2**) 複数リージョン書き込みレート

1 サーバーレス アカウントの要求ユニット (RU) には、1.25 の係数が乗算されます。

2 1.25 のレートは、AZ が有効になっているリージョンにのみ適用されます。

可用性ゾーンは、次の方法で有効にできます。

高可用性アプリケーションの構築

  • これらのイベント中に、想定される Azure Cosmos SDK の動作と、それに影響を与える構成を確認します。

  • 書き込みと読み込みの高可用性を確保するために、複数の書き込みリージョンを持つ少なくとも 2 つのリージョンにまたがるように Azure Cosmos アカウントを構成します。 この構成は、SLA によって裏付けられた読み取りと書き込みの両方に対して、最も高い可用性、最も短い待ち時間、および最高のスケーラビリティを提供します。 詳しくは、複数の書き込みリージョンで Azure Cosmos アカウントを構成する方法に関するページを参照してください。

  • 単一書き込みリージョンで構成されている複数リージョンの Azure Cosmos アカウントでは、Azure CLI または Azure portal を使用して自動フェールオーバーを有効にします。 自動フェールオーバーを有効にすると、リージョンで災害が発生するたびに Cosmos DB はアカウントを自動的にフェールオーバーします。

  • Azure Cosmos アカウントの可用性が高くても、アプリケーションが高可用性を維持するよう正しく設計できていないこともあります。 アプリケーション テストまたはディザスター リカバリー (DR) ドリルの一環として、アプリケーションのエンドツーエンドの高可用性をテストするには、アカウントの自動フェールオーバーを一時的に無効にし、PowerShell、Azure CLI または Azure portal を使用して手動フェールオーバーを呼び出し、アプリケーションのフェールオーバーを監視します。 完了したら、プライマリ リージョンにフェールバックし、アカウントの自動フェールオーバーを復元できます。

重要

データの一貫性を維持するためにリージョンに接続する必要があり、成功しない場合は、同期元リージョンまたは同期先リージョンでの Cosmos DB の停止中に手動フェールオーバーを呼び出さないでください。

  • グローバルに分散されるデータベース環境内では、リージョン全体にわたる停止が発生した場合の整合性レベルとデータ持続性の間には、直接的な関係があります。 ビジネス継続性計画を開発するときは、破壊的なイベントが発生してから、アプリケーションが完全に復旧するまでの最大許容時間について理解する必要があります。 アプリケーションを完全に復旧するために必要な時間は、目標復旧時間 (RTO) と呼ばれます。 さらに、破壊的なイベントの発生後、復旧中にアプリケーションが損失を許容できる新しいデータ更新の最大期間についても理解する必要があります。 損失を許容できる更新の期間は、目標復旧時点 (RPO) と呼ばれます。 Azure Cosmos DB の RPO および RTO を表示するには、「整合性レベルとデータ持続性」を参照してください。

Cosmos DB のリージョン停止中に予期されること

単一リージョンのアカウントでは、クライアントの読み取りと書き込みの可用性が失われます。

複数リージョンのアカウントでは、次の表に従って異なる動作が発生します。

書き込みリージョン 自動フェールオーバー ウィザードの内容 対処
単一の書き込みリージョン 無効 読み取りリージョンで停止状態が発生した場合、すべてのクライアントは他のリージョンにリダイレクトされます。 読み取りまたは書き込みの可用性が失われることはありません。 データの損失はありません。

書き込みリージョンで停止状態が発生した場合、クライアントで書き込みの可用性が失われる可能性があります。 厳密な整合性レベルが選択されていない場合は、一部のデータが残りのアクティブ リージョンにレプリケートされていない可能性があります。 これは、こちらのセクションで説明されているように、選択されている整合性レベルによって決まります。 影響を受けるリージョンで永続的なデータ損失が発生した場合は、レプリケートされていないデータが失われる可能性があります。

停止状態が終わると、Cosmos DB は書き込みの可用性を自動的に復元します。

停止状態中は、読み取りトラフィックをサポートするのに十分な RU が残りのリージョンにプロビジョニングされていることを確認します。

成功しないからといって、停止状態発生時に手動フェールオーバーを トリガーしないで ください。

停止状態が終了したら、必要に応じて、プロビジョニングされている RU を再調整します。

単一の書き込みリージョン Enabled 読み取りリージョンで停止状態が発生した場合、すべてのクライアントは他のリージョンにリダイレクトされます。 読み取りまたは書き込みの可用性が失われることはありません。 データの損失はありません。

書き込みリージョンで停止状態が発生した場合、クライアントは、ユーザーの好みに応じて新しいリージョンを新しい書き込みリージョンとしてCosmos DB により自動的に選択するまで、書き込みの可用性が失われます。 厳密な整合性レベルが選択されていない場合は、一部のデータが残りのアクティブ リージョンにレプリケートされていない可能性があります。 これは、こちらのセクションで説明されているように、選択されている整合性レベルによって決まります。 影響を受けるリージョンで永続的なデータ損失が発生した場合は、レプリケートされていないデータが失われる可能性があります。

停止状態中は、読み取りトラフィックをサポートするのに十分な RU が残りのリージョンにプロビジョニングされていることを確認します。

成功しないからといって、停止状態発生時に手動フェールオーバーを トリガーしないで ください。

停止状態が終了したら、書き込みリージョンを元のリージョンに戻し、必要に応じて、プロビジョニングされている RU を再調整できます。 SQL API を使用しているアカウントでは、障害が発生したリージョン内のレプリケートされていないデータを競合フィードから復旧することもできます。

複数の書き込みリージョン 該当なし 読み取りまたは書き込みの可用性が失われることはありません。

障害が発生したリージョンの最近の更新データは、残りのアクティブ リージョンで使用可能でない可能性があります。 最終的、一貫性のあるプレフィックス、およびセッションの整合性レベルで保証されている整合性制約は、15 分間未満です。 有界整合性制約では、構成に応じて、K 個の更新、または T 秒未満が保証されます。 影響を受けるリージョンで永続的なデータ損失が発生した場合は、レプリケートされていないデータが失われる可能性があります。

停止状態中は、追加トラフィックをサポートするのに十分な RU が残りのリージョンにプロビジョニングされていることを確認します。

停止状態が終了したら、必要に応じて、プロビジョニングされている RU を再調整できます。 可能な場合、SQL API アカウントでは構成済みの競合解決方法、他の API が使用されているアカウントでは "最後の書き込みが有効" を使用して、障害が発生したリージョン内にあるレプリケートされていないデータが自動的に復旧されます。

次のステップ

次に、次の記事を読むことができます。