Azure Cosmos DB を使用して高可用性を実現する

  • [アーティクル]

適用対象: NoSQL MongoDB Cassandra Gremlin Table

高可用性を備えたソリューションを構築するには、すべてのコンポーネントの信頼性特性を評価する必要があります。 Azure Cosmos DB は、すべてのソリューションの可用性のニーズに応じて高可用性を実現するために、複数の機能と構成オプションを提供するように設計されています。

RTO (目標復旧時間) という用語で Azure Cosmos DB に影響を与える停止の開始から完全な可用性への復旧までの時間を示し、RPO (回復ポイントの目標) という用語で正しく復元された最後の書き込みから Azure Cosmos DB に影響を与える停止の開始時刻までの時間を示します。

注意

予想される最大 RPO と RTO は、Azure Cosmos DB で発生している停止の種類によって異なります。 たとえば、1 つのノードの停止とリージョン全体の停止では、予想される RTO と RPO は異なります。

この記事では、Azure Cosmos DB の可用性に影響を与えるイベントとソリューションに必要な可用性特性を実現するための Azure Cosmos DB の構成オプションについて詳しく説明します。

レプリカのメンテナンス

Azure Cosmos DB は、個々のコンピューティング ノードのすべての詳細を透過的に管理する、マネージドのマルチテナント サービスです。 ユーザーは、修正プログラムの適用や計画メンテナンスについて心配する必要はありません。 Azure Cosmos DB では、システムによって実行されるすべての自動メンテナンス操作を通じて、可用性と P99 待機時間に関する SLA が保証されます。

可用性の SLA の保証については、「SLA セクション」をご覧ください。

レプリカの停止

レプリカの停止は、Azure リージョンにデプロイされた Azure Cosmos DB クラスター内の個々のノードの停止を表します。 Azure Cosmos DB は、4 つのレプリカ クォーラム内のアカウントについて、各 Azure リージョンでデータのレプリカを 3 つ以上保証することにより、レプリカの停止を自動的に軽減します。 これにより、個々のノードの停止に対して RTO = 0 および RPO = 0 になります。アプリケーションの変更や構成は必要ありません。

多くの Azure リージョンでは、可用性ゾーンが物理的に分離され、個別の電源、ネットワーク、および冷却が提供されるため、可用性ゾーン間で Azure Cosmos DB クラスターを分散でき、その結果、SLA が改善します。 「可用性ゾーン」をご覧ください。 Azure Cosmos DB アカウントが可用性ゾーンを使ってデプロイされていると、ゾーンが停止しても Azure Cosmos DB で RTO = 0 および RPO = 0 が提供されます。

ユーザーが単一の Azure リージョンにデプロイすると、ユーザーが特に何も入力しなくても、Azure Cosmos DB はノードの停止に対して回復性を持つようになります。 可用性ゾーン間で冗長性を有効にすると、料金は高くなりますが、ゾーンの停止に対する Azure Cosmos DB の回復性が実現されます。 SLA と価格の両方が「SLA セクション」で報告されます。

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

既定では、Azure Cosmos DB アカウントは複数の可用性ゾーンを使用しません。 複数の可用性ゾーン間のデプロイは、次の方法で有効にできます。

Azure Cosmos DB アカウントが N 個の Azure リージョンに分散している場合は、すべてのデータの N x 4 個のコピーが存在します。 データ分散に関する詳細については、内部でのグローバル データ分散に関するページを参照してください。 2 つ以上のリージョンで Azure Cosmos DB アカウントを用意すると、アプリケーションの可用性が向上し、関連するリージョン全体で低待機時間を実現できます。

Azure Cosmos DB が各リージョンのデータをレプリケートする方法の詳細については、「Azure Cosmos DB でのグローバル分散 - 内部のしくみ」をご覧ください。

リージョンの停止

リージョンの停止とは、すべての可用性ゾーンにわたって、Azure リージョンのすべての Azure Cosmos DB ノードに影響を与える停止を表します。 まれに発生するリージョンの障害時には、Azure Cosmos DB を構成して、持続性と可用性のさまざまな結果をサポートできます。

Durability

Azure Cosmos DB アカウントが単一リージョンにデプロイされていると、通常、データ損失は発生しません。また、影響を受けたリージョンで Azure Cosmos DB サービスが回復された後、データ アクセスが復元されます。 データ損失は、Azure Cosmos DB リージョンで回復不可能な障害が発生した場合にのみ、発生する可能性があります。

リージョンで致命的なディザスターが発生した結果として起こる可能性がある完全なデータ損失から保護するために、Azure Cosmos DB には 2 つの異なるバックアップ モードがあります。

  • 継続的バックアップ 各リージョンで 100 秒ごとにバックアップが作成され、2 番目の粒度で任意の時点にデータを復元できます。 各リージョンでは、バックアップは、そのリージョンでコミットされたデータに依存します。
  • 定期的なバックアップ アカウント内のすべてのコンテナーからすべてのパーティションの完全バックアップが作成されます。パーティション間の同期は実行されません。 最小バックアップ間隔は 1 時間です

Azure Cosmos DB アカウントが複数のリージョンにデプロイされていると、データの持続性は、アカウントで構成されている整合性レベルによって異なります。 次の表では、すべての整合性レベルについて、2 つ以上のリージョンにデプロイされている Azure Cosmos DB アカウントの RPO を詳細に示します。

整合性レベル リージョンが停止した場合の RPO
セッション、一貫性のあるプレフィックス、最終的 < 15 分
有界整合性制約 K&T
Strong 0

K = 項目の "K" バージョン (更新) 数。

T = 前回の更新以降の期間 "T" 。

複数リージョン アカウントの場合、K と T の最小値は 100,000 回の書き込み操作または 300 秒です。 これにより、有界整合性制約を使用する場合のデータの最小 RPO が定義されます。

整合性レベルの違いの詳細については、「整合性レベル」をご覧ください。

可用性

リージョンの停止中でもソリューションに継続的な可用性が必要な場合は、複数のリージョン間でデータをレプリケートし、必要に応じて使用可能なリージョンに透過的にフェールオーバーするように Azure Cosmos DB を構成できます。

単一リージョンのアカウントは、リージョンの障害の後で可用性を失う場合があります。 常に高可用性を確保するには、Azure Cosmos DB アカウントを 1 つの書き込みリージョンと少なくとも 2 つ (読み取り) リージョンで設定し、サービスマネージド フェールオーバーを有効にします。

サービスマネージド フェールオーバーでは、Azure Cosmos DB がマルチリージョン アカウントの書き込みリージョンをフェールオーバーし、持続性セクション示すデータ損失のコストで可用性を維持できます。 リージョン間フェールオーバーは、Azure Cosmos DB クライアントで検出され、処理されます。 アプリケーションの変更は不要です。 複数の読み取りリージョンとサービスマネージド フェールオーバーを有効にする手順については、「Azure Cosmos DB アカウントの管理方法」をご覧ください。

重要

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

複数の書き込みリージョン

Azure Cosmos DB は、複数のリージョンで書き込みを受け付けるように構成できます。 これは、地理的に分散したアプリケーションの書き込み待機時間を短縮するために役立ちます。 Azure Cosmos DB アカウントが複数の書き込みリージョン用に構成されていると、強力な整合性はサポートされず、書き込みの競合が発生する可能性があります。 複数の書き込みリージョン構成で競合を解決する方法の詳細については、「複数の書き込みリージョンを使用する場合の競合の種類と解決ポリシー」をご覧ください。

Azure Cosmos DB の内部アーキテクチャのため、複数の書き込みリージョンを使用しても、リージョン停止中の書き込みの可用性は保証されません。 リージョンの停止中に高可用性を実現するための最適な構成は、サービスマネージド フェールオーバーで構成された単一書き込みリージョンです。

競合解決リージョン

Azure Cosmos DB アカウントで複数リージョン書き込みが構成されている場合、書き込み競合が発生した場合、リージョンの 1 つがアービターとして機能します。 このような競合が発生すると、整合性のある解決のためにこのリージョンにルーティングされます。

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

単一リージョン アカウントのクライアントでは、サービスが復元されるまで、読み取りおよび書き込み可用性が失われる可能性があります。

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

構成 Outage 可用性への影響 持続性への影響 対処
単一の書き込みリージョン リージョンの停止を読み取る すべてのクライアントは、読み取りを他のリージョンに自動的にリダイレクトします。 すべての構成で読み取りまたは書き込みの可用性の損失はありません。ただし、強力な整合性を持つ 2 つのリージョンは例外で、サービスが復元されるまで書き込みの可用性で損失が発生します。また、サービスマネージド フェールオーバーが有効になっている場合、そのリージョンは失敗としてマークされ、フェールオーバーが発生します。 データの損失はありません。 停止状態中は、読み取りトラフィックをサポートするのに十分な RU が残りのリージョンにプロビジョニングされていることを確認します。

停止状態が終了したら、必要に応じて、プロビジョニングされている RU を再調整します。
単一の書き込みリージョン 書き込みリージョンの停止 クライアントは、読み取りを他のリージョンにリダイレクトします。

サービスマネージド フェールオーバーが有効になっていない場合、クライアントでは、停止が終了し、書き込みの可用性が自動的に復元されるまで、書き込みの可用性損失が発生します。

サービスマネージド フェールオーバーが有効になっている場合、クライアントでは、設定に従って選択された新しい書き込みリージョンへのフェールオーバーがサービスによって管理されるまで書き込みの可用性損失が発生します。

 厳密な整合性レベルが選択されていない場合は、一部のデータが残りのアクティブ リージョンにレプリケートされていない可能性があります。 これは、こちらのセクションで説明されているように、選択されている整合性レベルによって決まります。 影響を受けるリージョンで永続的なデータ損失が発生した場合は、レプリケートされていないデータが失われる可能性があります。 停止状態中は、読み取りトラフィックをサポートするのに十分な RU が残りのリージョンにプロビジョニングされていることを確認します。

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

停止状態が終了したら、必要に応じて、プロビジョニングされている RU を再調整します。 NoSQL 用 API を使用しているアカウントでは、障害が発生したリージョン内のレプリケートされていないデータを競合フィードから復旧することもできます。
複数の書き込みリージョン リージョンの停止 サービスマネージド フェールオーバーを使用した単一書き込みリージョンと同様に、一時的な書き込み可用性が失われる可能性があります。 競合解決リージョンのフェールオーバーは、停止時に多数の競合書き込みが発生すると、書き込みの可用性の損失の原因になる場合もあります。 障害が発生したリージョンで最近更新されたデータは、選択した整合性レベルによっては、残りのアクティブ リージョンでは使用できない場合があります。 影響を受けるリージョンで永続的なデータ損失が発生した場合は、レプリケートされていないデータが失われる可能性があります。 停止状態中は、追加トラフィックをサポートするのに十分な RU が残りのリージョンにプロビジョニングされていることを確認します。

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

読み取りリージョンの停止に関する追加情報

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

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

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

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

  • Azure リージョンが永久に回復不可能になるという、まれで不運な状況でも、複数リージョンの Azure Cosmos DB アカウントが "厳密な" 整合性で構成されていれば、データ損失は発生しません。 書き込みリージョンが永続的に復旧できなくなった場合に備えて、複数リージョンの Azure Cosmos DB アカウントには、「持続性」セクションで指定した持続性特性があります。

読み取りリージョンの停止に関する追加情報

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

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

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

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

SLA

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

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

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

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

重要

内部 Azure Cosmos DB アーキテクチャを考えると、複数の書き込みリージョンを使用しても、リージョンの停止中に書き込み可用性が保証されるということはありません。 リージョンが停止した場合に高可用性を実現するための最適な構成は、サービスマネージド フェールオーバーで構成された単一書き込みリージョンです。

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

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

  • 書き込みと読み込みの高可用性を確保するために、複数の書き込みリージョンを持つ少なくとも 2 つ (強力な整合性を使用している場合には 3 つ) のリージョンにまたがるように Azure Cosmos DB アカウントを構成します。 リージョンが停止した場合に高可用性を実現するための最適な構成は、サービスマネージド フェールオーバーで構成された単一書き込みリージョンであることを覚えておいてください。 詳しくは、「チュートリアル: NoSQL 用 API を使用して Azure Cosmos DB グローバル分散をセットアップする」をご覧ください。

  • 単一書き込みリージョンで構成されている複数リージョンの Azure Cosmos DB アカウントでは、Azure CLI または Azure portal を使用してサービスマネージド フェールオーバーを有効にします。 サービスマネージド フェールオーバーを有効にすると、リージョンで災害が発生するたびに、ユーザーによる入力なしで Azure Cosmos DB はアカウントをフェールオーバーします。

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

重要

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

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

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

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

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

書き込みリージョン サービスマネージド フェールオーバー ウィザードの内容 対処
単一の書き込みリージョン 無効 厳密な整合性が使用されていないとき、読み取りリージョンに障害が発生した場合、すべてのクライアントが他のリージョンにリダイレクトされます。 読み取りまたは書き込みの可用性が失われることはありません。 データの損失はありません。 厳密な整合性が使用されているとき、残っている読み取りリージョンが 2 つより少ない場合、読み取りリージョンの障害が書き込みの可用性に影響を及ぼす可能性があります。

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

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

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

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

停止状態が終了したら、必要に応じて、プロビジョニングされている RU を再調整します。
単一の書き込みリージョン Enabled 厳密な整合性が使用されていないとき、読み取りリージョンに障害が発生した場合、すべてのクライアントが他のリージョンにリダイレクトされます。 読み取りまたは書き込みの可用性が失われることはありません。 データの損失はありません。 厳密な整合性が使用されているとき、残っている読み取りリージョンが 2 つより少ない場合、読み取りリージョンの障害が書き込みの可用性に影響を及ぼす可能性があります。

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

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

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

停止状態が終了したら、書き込みリージョンを元のリージョンに戻し、必要に応じて、プロビジョニングされている RU を再調整できます。 NoSQL 用 API を使用しているアカウントでは、障害が発生したリージョン内のレプリケートされていないデータを競合フィードから復旧することもできます。
複数の書き込みリージョン 該当なし 障害が発生したリージョンの最近の更新データは、残りのアクティブ リージョンで使用可能でない可能性があります。 最終的、整合性のあるプレフィックス、およびセッションの整合性レベルで保証されている整合性制約は、<15 分間未満です。 有界整合性制約では、構成に応じて、K 個の更新、または T 秒未満が保証されます。 影響を受けるリージョンで永続的なデータ損失が発生した場合は、レプリケートされていないデータが失われる可能性があります。 停止状態中は、追加トラフィックをサポートするのに十分な RU が残りのリージョンにプロビジョニングされていることを確認します。

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

次のステップ

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