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

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

コンピューティング ノードの回復性

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

Azure Cosmos DB では、4 つのレプリカ クォーラム内のアカウントについて、各 Azure リージョンでデータのレプリカを 3 つ以上保証することにより、レプリカの停止を自動的に軽減します。 この保証により、アプリケーションの変更や構成を必要とせずに、個々のノードの停止に対して 0 の RTO および 0 の RPO を実現します。 RTO と RPO の詳細については、「 ビジネス継続性、高可用性、ディザスター リカバリーとは」を参照してください。

可用性ゾーンのサポート

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

Azure Cosmos DB では、 ゾーンの冗長性がサポートされています。 ゾーンの冗長性を有効にすると、Azure はデータのレプリカを複数の可用性ゾーンに分散し、データセンターの問題や停止に対する回復性を提供します。 可用性ゾーンをサポートする Azure リージョンでゾーン冗長を有効にすることができます。 リージョンが可用性ゾーンをサポートしているかどうかを確認するには、サポートされているリージョンの一覧を参照してください。

特に単一リージョン アカウントの場合は、サポートされているリージョンでゾーン冗長を使用することをお勧めします。

ゾーン冗長性と単一リージョン アカウント

単一リージョンの Cosmos DB アカウントがある場合は、可用性ゾーンの問題に対して回復性を持つことが重要です。 ゾーン冗長を有効にすると、可用性ゾーンの障害による可用性損失の合計を防ぐことができます。

可用性ゾーンは物理的に分離され、個別の電源、ネットワーク、冷却を提供するため、Azure Cosmos DB の可用性 SLA は、可用性ゾーンを使用しないアカウントよりもゾーン冗長アカウントの方が高くなります。

ゾーン冗長性とマルチリージョン アカウント

マルチリージョン アカウントがある場合は、必要に応じて、可用性ゾーンをサポートする任意またはすべてのアカウント リージョンでゾーンの冗長性を有効にすることができます。 マルチリージョン アカウントでは、高可用性サービス レベル アグリーメント (SLA) を実現でき、ゾーンの冗長性を有効にすると、それらのリージョンで実現する全体的な可用性 SLA がさらに強化されます。

複数リージョン アカウントの場合、Cosmos DB for NoSQL データベースの可用性に対するゾーン冗長性の影響は、アカウントの整合性レベルと、ゾーン冗長が有効になっているリージョンによって異なります。 マルチリージョン アカウント構成で可用性ゾーンを使用した場合の影響を見積もるために、次の表を参照してください。

ゾーン冗長性を有効にするコスト

ゾーン冗長が有効になっているリージョンは、25% Premium で課金されます。 ただし、複数リージョンの書き込みを使用して構成されたアカウントや、自動スケール モードで構成されたコレクションの場合、可用性ゾーンの Premium 価格は免除されます。

Cosmos DB アカウントにリージョンを追加すると、通常、リージョンごとに既存の請求書が 100% 増加します。 ただし、リージョン間のコストの変動は小さいです。

詳しくは、価格に関するページをご覧ください。

SLA の機能強化

Azure Cosmos DB アカウントの回復性と可用性を高めるために、次を含む階層化アプローチを実装できます。

• ゾーン冗長の有効化。
• 1 つ以上のリージョンを追加する。
• 複数リージョンの書き込みを有効にする。

階層化アプローチは、各段階でアカウントを保護します。具体的には、ゾーン冗長性のない単一リージョン構成では4 9の可用性、ゾーン冗長性を備えた単一リージョン構成では4と1/2 9の可用性、マルチリージョン書き込みオプションを有効にした複数リージョン構成では5 9の可用性を実現します。

次の表に、各構成の SLA の概要を示します。

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

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

可用性ゾーンを構成する

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

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

可用性ゾーンのサポートを有効にするために、以下を使用できます。

• Azure Portal

• Azure CLI

• Azure Resource Manager テンプレート

可用性ゾーンのサポートを有効にする

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 を構成して、持続性と可用性のさまざまな結果をサポートできます。

耐久性

通常、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](/azure/cosmos-db/how-to-manage-database-account#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 での信頼性