Azure Cosmos DB for NoSQL の高可用性 (信頼性)

この記事では、Azure CosmosDB for NoSQL での高可用性 (信頼性) のサポートについて説明し、可用性ゾーンと、リージョン間のディザスター リカバリーとビジネス継続性について説明します。

Azure Cosmos DB for NoSQL の一般的な回復性に関する推奨事項については、「Azure Cosmos DB for NoSQL の回復性に関する推奨事項」を参照してください。

可用性ゾーンのサポート

Azure 可用性ゾーンとは、各 Azure リージョン内にある、3 つ以上に物理的に分離されたデータセンターのグループです。 各ゾーン内のデータセンターには、独立した電源、冷却手段、ネットワーク インフラストラクチャが備わっています。 ローカル ゾーンの障害が発生した場合、可用性ゾーンは、1 つのゾーンが影響を受けたときに、リージョンのサービス、容量、高可用性が残りの 2 つのゾーンによってサポートされるように設計されています。

障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象に至る可能性があります。 Azure サービスの冗長と論理的な分離により、障害に対するトレランスが実現されます。 Azure の可用性ゾーンの詳細については、リージョンと可用性ゾーンに関する記事を参照してください。

Azure の可用性ゾーン対応サービスは、適切なレベルの信頼性と柔軟性を提供するように設計されています。 それらは 2 つの方法で構成できます。 それらは、ゾーン間の自動レプリケーションによるゾーン冗長、またはインスタンスを特定のゾーンにピン留めするゾーンベースのいずれかになります。 これらのアプローチを組み合わせることもできます。 ゾーン ベースとゾーン冗長のアーキテクチャを比較した詳細については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。

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

Azure Cosmos DB のオファー:

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

ゾーン停止の回復性。 可用性ゾーンを使って Azure Cosmos DB アカウントをデプロイすると、ゾーンが停止しても Azure Cosmos DB で 0 の RTO および 0 の RPO が実現します。 RTO の詳細については、「回復目標」を参照してください。

可用性ゾーンが有効になっている場合、Azure Cosmos DB for NoSQL では、ゾーン冗長構成がサポートされます。

前提条件

• レプリカは、可用性ゾーンをサポートする Azure リージョンにデプロイする必要があります。 リージョンが可用性ゾーンをサポートしているかどうかを確認するには、サポートされているリージョンの一覧を参照してください。

• 可用性ゾーンが現在の構成に十分なメリットをもたらすかどうかを、「可用性 ゾーンの使用による影響」で判断します。

可用性 ゾーンの使用による影響

可用性ゾーンが Cosmos DB for NoSQL データベースの高可用性に与える影響は、アカウントの整合性レベルと、可用性ゾーンが有効になっているリージョンによって異なります。 多くの場合、可用性ゾーンは、アカウントが複数リージョンの場合 (厳密な整合性で構成されている場合を除き)、メリットをもたらすことはないか、最小値のメリットのみをもたらします。

現在のアカウント構成で可用性ゾーンを使用した場合の影響を見積もるために、次の表を参照してください。

SLA の機能強化

可用性ゾーンは物理的に分離され、個別の電源、ネットワーク、冷却を提供するため、可用性 SLA (サービス レベル アグリーメント) は、単一リージョン (99.99%) のアカウントよりも高い (99.995%) です。 可用性ゾーンが有効になっているリージョンは 25% の Premium で課金されますが、可用性ゾーンのないリージョンでは Premium は発生しません。 さらに、複数リージョンの書き込みを使用して構成されたアカウントや、自動スケール モードで構成されたコレクションの場合、可用性ゾーンの Premium 価格は免除されます。

Cosmos DB アカウントに追加のリージョンを追加すると、通常、既存の請求額が 100% (乗算ではなく加算) 増加しますが、リージョン間のコストには若干の変動が存在します。 詳しくは、価格に関するページをご覧ください。

AZ の有効化、追加リージョンの追加、またはマルチリージョン書き込みの有効化は、各段階で特定の Cosmos DB アカウントの回復性と可用性を高める階層化アプローチと考えることができます。つまり、可用性は AZ のない単一リージョン構成の場合は 99.99%、AZ のある単一リージョン構成の場合は 99.995%、複数リージョン書き込みオプションが有効になっている複数リージョン構成の場合は 99.999% になります。 各構成の SLA の概要については、次の表を参照してください。

1 サーバーレス アカウントの RU には、1.25 の係数が乗算されます。

2 1.25 レートは、可用性ゾーンを有効にするリージョンにのみ適用されます。

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

可用性ゾーンは、Azure Cosmos DB NoSQL アカウントに新しいリージョンを追加する場合にのみ構成できます。

可用性ゾーンのサポートを有効にするには、次を使用できます。

• Azure Portal

• Azure CLI

• Azure リソース マネージャーのテンプレート

可用性ゾーン サポートに移行する

Cosmos DB アカウントを可用性ゾーンのサポートに移行する方法については、「Azure Cosmos DB for NoSQL を可用性ゾーンのサポートに移行する」を参照してください。

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

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

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

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

Durability

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

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

• 継続的バックアップでは、100 秒ごとに各リージョンがバックアップされます。 これにより、1 秒の細分性で任意の時点にデータを復元できます。 各リージョンでは、バックアップは、そのリージョンでコミットされたデータに依存します。 リージョンで可用性ゾーンが有効になっている場合、バックアップはゾーン冗長ストレージ アカウントに格納されます。
• 定期的なバックアップでは、アカウント内のすべてのコンテナーからすべてのパーティションの完全バックアップが作成されます。パーティション間の同期は実行されません。 最小バックアップ間隔は 1 時間です

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

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

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

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

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

サービスマネージド フェールオーバー

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

単一リージョン アカウントでは、リージョンの停止後にアクセシビリティが失われる可能性があります。 常にビジネス継続性を確保するには、Azure Cosmos DB アカウントを 1 つの書き込みリージョンと少なくとも 2 つ (読み取り) リージョンで設定し、サービスマネージド フェールオーバーを有効にします。

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

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

複数のリージョンで書き込みを受け付けるように Azure Cosmos DB を構成できます。 この構成は、地理的に分散したアプリケーションの書き込み待機時間を短縮するために役立ちます。

Azure Cosmos DB アカウントを複数の書き込みリージョン用に構成すると、厳密な整合性はサポートされず、書き込みの競合が発生する場合があります。 これらの競合を解決する方法の詳細については、「複数の書き込みリージョンを使用する場合の競合の種類と解決ポリシー」を参照してください。

競合解決リージョン

Azure Cosmos DB アカウントで複数リージョン書き込みが構成されていると、書き込み競合が発生した場合、リージョンの 1 つがアービターとして機能します。

複数リージョンの書き込むのベスト プラクティス

複数のリージョンに書き込む場合に考慮すべきベスト プラクティスをいくつか紹介します。

ローカル トラフィックをローカルに維持する

複数リージョンの書き込みを使用する場合、アプリケーションはローカル リージョンから発信される読み取りおよび書き込みトラフィックを、厳密にローカル Cosmos DB リージョンに発行する必要があります。 最適なパフォーマンスを得るには、リージョン間の呼び出しを避けてください。

アプリケーションでは、次のアンチパターンを回避して競合を最小限に抑えることが重要です。

• すべてのリージョンに同じ書き込み操作を送信して、応答時間が速くなる確率を高める

• 要求ごとに読み取りまたは書き込み操作のターゲット リージョンをランダムに決定する

• ラウンド ロビン ポリシーを使用して、要求ごとに読み取りまたは書き込み操作のターゲット リージョンを決定します。

レプリケーションのラグへの依存関係を回避する

複数リージョンの書き込みアカウントでは、厳密な整合性を構成できません。 書き込まれるリージョンは、Azure Cosmos DB がデータをグローバルに非同期的にレプリケートしながら、データをローカルにレプリケートした直後に応答します。

めったに起こりませんが、データを geo レプリケートするときに、1 つまたは複数のパーティションでレプリケーションのラグが発生する場合があります。 レプリケーションのラグは、ネットワーク トラフィックのまれな中断や、通常よりも高い競合解決率が原因で発生することがあります。

たとえば、アプリケーションがリージョン A に書き込み、リージョン B から読み取るアーキテクチャでは、2 つのリージョン間のレプリケーションのラグに依存します。 ただし、アプリケーションが同じリージョンに対して読み取りと書き込みを行う場合は、レプリケーションのラグが発生してもパフォーマンスは一定のままになります。

書き込み操作のセッション整合性の使用を評価する

セッション整合性では、セッション トークンは読み取りと書き込みの両方の操作に使用します。

読み取り操作の場合、Azure Cosmos DB によって、指定された (またはより新しい) セッション トークンに対応するデータの受信を保証するサーバーに、キャッシュされたセッション トークンが送信されます。

書き込み操作の場合、指定されたセッション トークンとのラグがサーバーで解消された場合にのみ、Azure Cosmos DB によって、データの保持を保証するデータベースにセッション トークンが送信されます。 単一リージョンの書き込みアカウントでは、書き込みリージョンとセッション トークンの間のラグが解消されていることが常に保証されます。 ただし、複数リージョンの書き込みアカウントでは、書き込み対象のリージョンが別のリージョンに発行された書き込みとのラグを解消できない場合があります。 クライアントがリージョン B からのセッション トークンを使用してリージョン A に書き込む場合、リージョン A は、リージョン B で行われた変更が適用されるまでデータを保持できません。

セッション トークンは読み取り操作にのみ使用し、クライアント インスタンス間でセッション トークンを渡すときの書き込み操作には使用しないことをお勧めします。

同じドキュメントに対する急速な更新を軽減する

解決、または競合がないことを確認するためのサーバーの更新は、同じドキュメントが繰り返し更新されたときにアプリケーションによってトリガーされる書き込みと競合する可能性があります。 同じドキュメントに連続して更新を繰り返す場合、競合解決時の待機時間が長くなります。

同じドキュメントに対する繰り返しの更新でバーストが時々発生することは避けられませんが、安定した状態のトラフィックで長期間にわたって同じドキュメントに対する急速な更新が見られる場合は、代わりに新しいドキュメントが作成されるアーキテクチャを検討してください。

読み取りと書き込みの停止

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

複数リージョンのアカウントでは、次の構成と停止の種類に応じて異なる動作が発生します。

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

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

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

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

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

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

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

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

• 手動フェールオーバーはトリガーしないようにする必要があり、ソースまたは宛先のリージョンが停止していると成功しません。 その理由は、フェールオーバー手順に、リージョン間の接続を必要とする整合性チェックが含まれているためです。

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

• 以前に影響を受けた書き込みリージョンの復旧後、Azure portal に "オンライン" として表示され、読み取りリージョンとして利用できるようになります。 この時点で、[PowerShell、Azure CLI、または Azure portal] を使用して、復旧されたリージョンに書き込みリージョンとして切り替えることができます (../cosmos-db/how-to-manage-database-account.yml#perform-manual-failover-on-an-azure-cosmos-db-account)。 書き込みリージョンの切り替えの前後や最中に、"データや可用性が損なわれることはありません"。 アプリケーションの高可用性が維持されます。

停止の検出、通知、管理

単一リージョン アカウントの場合、クライアントでは、Azure Cosmos DB リージョンの停止中に読み取りと書き込みの可用性が失われます。 次の表で説明するように、複数リージョン アカウントではさまざまな動作が発生します。

高可用性のテスト

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

関連するコンテンツ

• Azure Cosmos DB の整合性レベル

• Azure Cosmos DB の要求ユニット

• Azure Cosmos DB でのグローバル データ分散 - 内部のしくみ

• Azure Cosmos DB の整合性レベル

• Azure Cosmos DB を使用するアプリケーションで複数リージョン書き込みを構成する

• 複数リージョン環境での Azure Cosmos DB SDK の可用性の診断とトラブルシューティング

• Azure での信頼性