Azure Cosmos DBの信頼性

NoSQLのAzure Cosmos DBは、柔軟なスキーマを持つドキュメント データ モデルをサポートする、グローバルに分散されたマルチモデル データベース サービスです。 Azure Cosmos DBでは、パフォーマンスと可用性のバランスを取るための複数の整合性レベル、可用性ゾーンの障害から保護するゾーン冗長デプロイ、サービスマネージドフェールオーバーまたはカスタマー マネージド フェールオーバーを使用したマルチリージョン レプリケーション、データ保護のための継続的および定期的なバックアップ オプションなど、包括的な信頼性機能が提供されます。

Azureを使用する場合、信頼性は共有責任です。 Microsoftには、回復性と回復性をサポートするためのさまざまな機能が用意されています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。

この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止、サービスメンテナンスなど、さまざまな潜在的な障害や問題に対するAzure Cosmos DB回復性を確保する方法について説明します。 また、バックアップを使用して他の種類の問題から復旧する方法についても説明し、Azure Cosmos DB サービス レベル アグリーメント (SLA) に関する重要な情報を強調します。

運用環境のデプロイに関する推奨事項

Azure Well-Architected Framework は、信頼性、セキュリティ、コスト、運用、パフォーマンスに関する推奨事項を提供します。 これらの領域が互いに及ぼす影響を理解し、信頼性の高いAzure Cosmos DB ソリューションに貢献するには、Azure Cosmos DB のアーキテクチャのベスト プラクティスを参照してください。

信頼性アーキテクチャの概要

このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。

論理アーキテクチャ

デプロイするプライマリ リソースは、Azure Cosmos DB account です。 各アカウントには、複数のコンテナーを持つ複数のデータベースを含めることができます。 コンテナーは、分散とスケーラビリティの論理ユニットとして機能します。 Azure Cosmos DBの操作に使用する API に応じて、コレクション、テーブル、グラフなどのコンテナーを作成できます。 リソース モデルの詳細については、Azure Cosmos DB のデータベース、コンテナー、およびアイテム を参照してください。 各コンテナーでは パーティション分割が使用され、高スケールと高パフォーマンスがサポートされます。

データのクエリと操作に使用できるシステム リソースの量を表す スループットを構成します。 スループットを 手動でプロビジョニングしたり、 自動スケールを使用 してワークロードの要件に基づいて容量を動的に調整したり、実際の使用量に対して課金される サーバーレス アカウントの種類 を使用したりできます。

1 つのアカウント複数のAzureリージョンを使用できるため、リージョンの停止に対する回復性が向上します。 読み取り用に複数のリージョンを構成できます。 Business Critical レベルを使用する場合は、複数のリージョンを使用して書き込みを行うことができます。 Azure Cosmos DBは、データを自動的に geo レプリケートします。 geo レプリケーションの動作は、データ の整合性、可用性、待機時間、スループットのトレードオフを行う方法を示す整合性レベルなど、使用する構成の影響を受けます。 異なる整合性レベルは、さまざまな懸念事項に合わせて最適化し、さまざまな保証をサポートし、異なる種類のリージョン間レプリケーションを提供します。

物理アーキテクチャ

Azure Cosmos DBは、冗長性のためにデータの複数のreplicasを格納します。 サービスは、各リージョンのレプリカ間でクォーラムを維持することで、レプリカの停止を自動的に軽減します。 この方法では、高可用性が保証され、アプリケーションの変更や構成を必要とせずに、個々のノード障害時のデータ損失から保護されます。

内部的には、Azure Cosmos DBは、physical partition、partition sets、replica sets などのさまざまなコンストラクトを使用してデータを管理します。 Azure Cosmos DBのしくみの詳細については、「global data distribution with Azure Cosmos DB - under the hoodを参照してください。

一時的な障害に対する回復性

一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。

クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。

Azure Cosmos DB SDK を使用することをお勧めします。 SDK は、自動再試行による一時的な障害処理や、サービスによって送信されるレート制限応答の受け入れなど、さまざまな回復性に関する考慮事項のサポートを自動的に実装します。 詳細については、「AZURE COSMOS DB SDK を使用した回復性のあるアプリケーションの設計を参照してください。

マルチリージョン アカウントを使用する場合、SDK では 、しきい値ベースの可用性戦略 ( ヘッジとも呼ばれます) もサポートされています。この戦略では、並列読み取り要求が複数のリージョンに送信され、最速の応答が受け入れられます。 この方法では、リージョンで通常よりも一時的に待機時間が長い場合に、アプリケーションのパフォーマンスを向上させることができます。

可用性ゾーンの障害に対する回復性

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

Azure Cosmos DB では、 ゾーンの冗長性がサポートされています。 ゾーンの冗長性を有効にすると、Azure はデータのレプリカを複数の可用性ゾーンに分散し、データセンターの問題や停止に対する回復性を提供します。 Microsoftは、使用する可用性ゾーンを選択します。

Azure Cosmos DB アカウントでは、グローバル分散、スケール、フェールオーバーに複数のリージョン (場所) が使用される場合があります。 ゾーン冗長は、アカウント内のリージョンごとに個別に構成します。

Azure Cosmos DBでゾーン冗長性を使用しても、パフォーマンスや待機時間に目に見える影響はありません。 選択した整合性モードを調整する必要はありません。また、アプリケーション コードを変更する必要はありません。

特に単一リージョン アカウントの場合は、サポートされているリージョンでゾーン冗長を使用することをお勧めします。 可用性ゾーンは物理的に分離され、個別の電源、ネットワーク、冷却を提供するため、Azure Cosmos DB の可用性 SLA は、可用性ゾーンを使用しないアカウントよりもゾーン冗長アカウントの方が高くなります。

ゾーン冗長を有効にしない場合、アカウントはそのリージョンでは 非ゾーン です。 非ゾーン アカウントでは、1 つの可用性ゾーンにレプリカが配置され、その特定のゾーンで問題が発生した場合にダウンタイムが発生する可能性があります。

Requirements

• Region のサポート: 可用性ゾーンをサポートするAzure リージョンでゾーンの冗長性を有効にすることができます。 リージョンが可用性ゾーンをサポートしているかどうかを確認するには、 サポートされているリージョンの一覧を参照してください。

  ゾーン冗長は、アカウント全体の設定ではありません。 Azure Cosmos DB アカウントは複数のリージョンにまたがることができ、各リージョンは可用性ゾーンを使用するように個別に構成できます。 可用性ゾーンをサポートしていないリージョンでは、同じアカウント内の他のリージョンでゾーンの冗長性を有効にすることはできません。

• サーバーレス アカウント: ゾーン冗長サーバーレス アカウントは、作成時にのみ構成できます。 可用性ゾーンがない既存のサーバーレス アカウントを可用性ゾーン構成に変換することはできません。 ミッション クリティカルなワークロードの場合は、プロビジョニングされたスループットを使用することをお勧めします。

考慮事項

• 複数の同時ゾーン停止: ゾーン冗長性を持つ単一リージョン アカウントは、障害が単一の可用性ゾーンに影響を与えた場合に、読み取り/書き込み可用性を維持できます。 ただし、障害が複数の可用性ゾーンまたはリージョン全体に影響を与える場合、単一リージョン アカウントは、サービスが復元されるまで読み取りと書き込みのアクセスを失います。 同時に障害が発生した複数のゾーンに対する回復性が必要な場合は、マルチリージョン アカウントのデプロイを検討してください。

• 複数リージョンアカウント: マルチリージョン アカウントがある場合は、必要に応じて、可用性ゾーンをサポートする任意またはすべてのアカウント リージョンでゾーンの冗長性を有効にすることができます。 アカウントが 1 つのリージョンを使用するように構成されている場合、または複数の読み取りリージョンで単一の書き込みリージョンを使用するように構成されている場合は、ゾーン冗長を有効にすることを強くお勧めします。

Cost

ゾーン冗長が有効になっているリージョンは、Premium で課金されます。 ただし、複数リージョンの書き込みを使用して構成されたアカウントと、自動スケール スループット モードを使用するように構成されたコレクションについては、可用性ゾーンの Premium 価格は免除されます。 詳細については、「Azure Cosmos DB pricing」を参照してください。

可用性ゾーンのサポートを設定する

ほとんどのアカウントでは、Azure Cosmos DB アカウントに新しいリージョンを追加する場合にのみ、ゾーン冗長性を有効にします。 既存のアカウントで可用性ゾーンのサポートを有効にするには、リージョンを追加し、ゾーンの冗長性を有効にします。 元のリージョンでゾーンの冗長性を構成できるように、プロセスに従って一時的なリージョンを追加できます。 詳細な手順については、Azure Cosmos DB アカウントでのゾーン冗長性の確保に関する記事を参照してください。

サーバーレス アカウントの場合は、アカウントの作成時にゾーン冗長を有効にする必要があります。

すべてのゾーンが正常な場合の動作

このセクションでは、ゾーンの冗長性のためにAzure Cosmos DB アカウントを構成し、すべてのゾーンが動作する場合に想定される内容について説明します。

• Cross-zone operation: Azure Cosmos DB は、すべてのレプリカが要求を処理できるように、可用性ゾーン間のレプリカに要求を自動的にルーティングします。

• ゾーン間データ レプリケーション: クライアントがデータに変更を加えると、クォーラムを実現するために、その変更が異なるゾーン内の複数のレプリカに適用されます。 この方法は同期 レプリケーションと呼ばれます。 同期レプリケーションにより、データの整合性が高くなります。これにより、ゾーン障害時のデータ損失の可能性が軽減されます。 可用性ゾーンは比較的近くに配置されているため、待機時間やスループットへの影響は最小限です。

ゾーン障害時の動作

このセクションでは、ゾーンの冗長性のためにAzure Cosmos DB アカウントを構成し、いずれかのゾーンで障害が発生した場合に想定される内容について説明します。

• 検出と応答: Azure Cosmos DB プラットフォームは、可用性ゾーンの障害を検出する役割を担います。 ゾーンのフェールオーバーを開始するために何もする必要はありません。

• 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Resource Health を 使用して個々のリソースの正常性を監視したり、 Resource Health アラート を設定して問題を通知したりすることはできます。 また、Azure Service Health を使用して、ゾーンエラーを含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することもできます。

• Active requests: 可用性ゾーンが使用できなくなった場合、Azure Cosmos DBは影響を受けるゾーン内のレプリカに接続されているすべての進行中の要求を終了し、アプリケーションはこれらの要求を再試行する必要があります。 一時的な障害処理ガイダンスに従って、アプリケーションが準備されていることを確認します。

• 予想されるデータ損失: ゾーン障害による予期されるデータ損失はありません。

• 予想されるダウンタイム: ゾーンの停止中に、トラフィックが再配布されるときに通常数秒続く短い中断が接続で発生する可能性があります。 一時的な障害処理のガイダンスに従って、アプリケーションが準備されていることを確認します。

• Redistribution: Azure Cosmos DB は、受信要求を他の可用性ゾーン内の正常なレプリカに自動的にリダイレクトします。 可用性ゾーンが停止すると、プラットフォームはプロビジョニングされたスループットを他のレプリカに自動的に再割り当てします。

ゾーンの回復

可用性ゾーンが復旧すると、Azure Cosmos DBは可用性ゾーン内のレプリカを自動的に復元し、通常どおりレプリカ間のトラフィックを再ルーティングします。

ゾーンエラーのテスト

Azure Cosmos DBの可用性ゾーンのフェールオーバーと復旧は、Microsoftによって完全に管理されます。 可用性ゾーンの障害プロセスを開始または検証する必要はありません。

リージョン全体の障害に対する回復性

Azure Cosmos DB アカウントを 1 つのリージョンにデプロイすると、通常、すべてのAzure Cosmos DB ノードに影響するリージョン全体の停止によってデータが失われることはありませんが、アプリケーションがデータにアクセスできなくなります。 Azure Cosmos DBは、影響を受けるリージョンでサービスが復旧した後にデータ アクセスを復元します。 データ損失は、リージョンで回復不能な災害が発生した場合にのみ発生します。

まれなリージョンの停止に備えて、次のいずれかの方法を使用して、さまざまなレベルの持続性と可用性をサポートするようにAzure Cosmos DBを構成できます。

• 1 つの書き込みリージョンを持つ複数の読み取りリージョン。 必要に応じて、サービス管理フェールオーバーまたはパーティションごとの自動フェールオーバー (PPAF) を有効にすることができます。
• 複数の書き込みリージョン。

次の表は、アカウントの構成と停止の種類に基づいて使用可能な回復オプションをまとめたものです。 この記事の後のセクションでは、これらのオプションと関連する動作について詳しく説明します。

SDK と回復性

Azure Cosmos DB SDK は、アプリケーションの回復性戦略の重要な部分です。 複数リージョン アカウントがある場合、SDK の構成は、接続する優先リージョンや除外するリージョンなど、リージョン間での要求のルーティング方法に影響します。 SDK はリージョンとパーティションの可用性を監視し、パーティション レベルのサーキット ブレーカーなど、正常なリージョンとパーティションを使用するように動的に再構成できます。

SDK が高可用性をサポートする方法の詳細については、使用する SDK の高可用性に関するドキュメントを参照してください。

• Azure Cosmos DB .NET SDK v3
• Azure Cosmos DB Java SDK v4
• Azure Cosmos DB の Python SDK

リージョンの停止中にデータが失われる可能性がある

Azure Cosmos DB アカウントを複数のリージョンにデプロイする場合、データの持続性は、アカウントで構成する整合性レベルによって異なります。 次の表では、すべての整合性レベルについて、少なくとも 2 つのリージョンにデプロイされているAzure Cosmos DB アカウントの目標復旧ポイント (RPO) について詳しく説明します。 RPO は、リージョンの停止中の潜在的なデータ損失を表します。

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

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

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

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

1 つの書き込みリージョンを持つ複数の読み取りリージョン

リージョンの停止中にソリューションで継続的なアップタイムが必要な場合は、プライマリ リージョンによって処理される書き込みを使用して、複数のリージョン間でデータをレプリケートするようにAzure Cosmos DBを構成できます。 必要に応じて、特定の読み取りリージョンに接続するようにアプリケーションを構成できます。これは、パフォーマンスの向上に役立ちます。 リージョンで障害が発生した場合、アカウントは正常なリージョンから引き続き動作できます。

Azure Cosmos DB アカウントを示す図解

リージョン間のフェールオーバー

Azure Cosmos DB SDK は、読み取りリージョンの優先順位付けされた一覧で構成できます。 SDK は、アプリケーションを一覧の最初の利用可能なリージョンに接続します。 読み取りリージョンの停止中、SDK はバックエンド応答コードを使用してリージョンの停止を検出し、それを使用不可としてマークし、今後の操作を優先リストの次の使用可能なリージョンにルーティングします。 優先リージョンの一覧が正しく設定され、ビジネス要件と待機時間の要件に合っていることを確認します。 詳細なガイダンスについては、「 Azure Cosmos DB SDK の可用性のトラブルシューティング」を参照してください。

フェールオーバーとは、アカウントのいずれかのリージョンを完全または部分的に使用できないようにするプロセスです。 フェールオーバーの影響は、リージョンが書き込みリージョンか読み取りリージョンかによって異なります。

• 書き込みリージョンが使用できなくなった場合、別のリージョンが書き込みリージョンになります。
• 読み取りリージョンが使用できなくなった場合、そのリージョンは読み取り要求を処理できず、代わりに他のリージョンが読み取り操作に使用されます。

Azure Cosmos DBでは、次の複数の種類のフェールオーバーが提供されます。

• パーティションごとの自動フェイルオーバー (PPAF): Azure Cosmos DB では、データを内部的に複数の物理パーティションに分散させます。 パーティションをサポートするインフラストラクチャで問題が発生した場合、他のパーティションは影響を受けない可能性があります。 PPAF を使用すると、単一書き込みリージョン アカウントは、プライマリ リージョンで正常なパーティションを維持しながら、個々のパーティションをセカンダリ リージョンに自動的にフェールオーバーできます。 PPAF は、ダウンタイムを最小限に抑え、リージョンの部分的な障害時の復旧を高速化するのに役立ちます。 詳細については、「Azure Cosmos DB に Per-Partition 自動フェールオーバー (PPAF) をオンボードして導入する方法に関するページを参照してください。

  Note

  パーティションごとの自動フェールオーバーはパブリック プレビュー段階です。 この機能は、サービス レベル アグリーメントなしに提供されます。 詳細については、「 Microsoft Azure プレビューの追加使用条件」を参照してください。

• 強制フェールオーバー: アカウントのいずれかのリージョンをオフラインにすることができます。 これは、 カスタマー マネージド フェールオーバーまたは オフライン リージョン 操作とも呼ばれます。 これは、停止中に可用性をすばやく復元するための推奨されるアプローチです。 障害を検出し、フェールオーバーをトリガーする責任があります。 また、ディザスター リカバリー訓練中など、強制フェールオーバーを使用して、テスト用のリージョンダウン シナリオをシミュレートすることもできます。

  書き込みリージョンをオフラインにすると、次に優先度が高い読み取りリージョンが新しい書き込みリージョンになります。 読み取りリージョンをオフラインにした場合、アプリケーションはアカウント内の他の読み取りリージョンに接続できます。

  書き込み用リージョンの強制フェールオーバーでは、レプリケートされていない書き込みによってデータが失われる可能性があります。

  強制フェールオーバー後、Microsoftはリージョンをオンラインに戻す必要があります。 正常なリージョンの場合、このプロセスは自動化されますが、最大で数日かかる場合があります。 リージョンが 1 日または 2 日以内にオンラインに戻らない場合は、サポート ケースを開いてサポートを依頼してください。

• 書き込みリージョンの変更: リージョンが正常な場合は、アカウントの書き込みリージョンを変更できます。 この変更は、実際にはアカウントの書き込みリージョンの計画されたフェールオーバーです。

  新しい書き込みリージョンが昇格される前にデータ レプリケーションが追いつくので、書き込みリージョンを変更してもデータが失われません。 一時的な中断が発生する可能性がありますが、再試行ロジックやその他の一時的な障害処理手法を使用するクライアントでは、通常、大きな影響はありません。

  この操作では、リージョンが正常である必要 があるため、リージョンの停止中に使用することはできません。

• Service-managed failover: アカウントでサービス管理フェールオーバーを使用する場合、Microsoftはリージョン間でフェールオーバーするタイミングを決定します。 サービス管理フェールオーバーを有効にするには、リージョンごとに優先順位を指定します。 ただし、停止を宣言し、サービスで管理されたフェールオーバーをトリガーするプロセスには、1 時間以上かかる場合があります。 復旧を高速化するには、サービスで管理されたフェールオーバーがトリガーされるのを待つのではなく、強制フェールオーバーを実行します。

  Microsoftがアカウントの書き込みリージョンに対してサービス管理されたフェールオーバーをトリガーすると、複製されていない書き込みが失われる可能性があります。

  サービスで管理されたフェールオーバーの後、Microsoftはリージョンをオンラインに戻す必要があります。 Microsoft自動的にリージョンがオンラインになりますが、このプロセスには数日かかることがあります。

Requirements

Region support: Azure Cosmos DB アカウントの読み取りリージョンとして任意のAzure リージョンを構成できます。

Cost

Azure Cosmos DB アカウントに読み取りリージョンを追加すると、リージョンごとに既存のコストが増加します。 詳細については、「Azure Cosmos DB pricing」を参照してください。

複数の読み取りリージョンを構成する

• 読み取りリージョンをアカウントに追加します。 アカウントを作成するとき、またはアカウントの作成後にいつでも、アカウントに複数のリージョンを構成できます。 詳細については、「 データベース アカウントからリージョンを追加または削除する」を参照してください。

• フェールオーバーを有効にする: 一部の種類のフェールオーバーは、事前に構成する必要があります。

  • Per-partition automatic failover: 詳細については、「 Azure Cosmos DB に Per-Partition 自動フェールオーバー (PPAF) をオンボードして採用する方法」を参照してください。

  • サービスマネージド フェールオーバー: まず、 サービス管理フェールオーバーを有効にします。 次に、 アカウント内のリージョンごとにフェールオーバーの優先順位を設定します。

容量の計画と管理

アプリケーションがリージョン間で要求を分散し、1 つのリージョンがオフラインになった場合、残りのリージョンでは要求量が多くなります。 自動スケール スループットを使用して、需要に基づいて容量を動的に調整します。 プロビジョニング済みスループットを使用する場合は、サービスの低下なしにリージョンの損失を処理するための十分な容量を計画し、過剰プロビジョニングを検討してください。 詳細については、「 過剰プロビジョニングによる容量の管理」を参照してください。

すべてのリージョンが正常な場合の動作

このセクションでは、複数の読み取りリージョンでAzure Cosmos DB アカウントを構成し、すべてのリージョンが動作している場合に想定される内容について説明します。

• リージョン間操作: アプリケーションは、読み取り操作を受け取るリージョンを構成します。 リージョンの優先順位付けされた一覧を使用してアプリケーションを構成したり、一部のリージョンを除外したりできます。 リージョンの選択のしくみの詳細については、「Diagnose」を参照し、複数のリージョン環境でのAzure Cosmos DB SDK の可用性のトラブルシューティングを行います。

  すべての書き込み操作は、アカウントの書き込みリージョンに送信されます。

• リージョン間データ レプリケーション: すべての書き込み操作は、アカウントのプライマリ リージョンで行われます。 書き込みは、アカウントの構成済みの整合性レベルに基づいて、他の読み取りリージョンにレプリケートされます。 レプリケーションの最大ラグについては、「 リージョンの停止中にデータが失われる可能性がある」を参照してください。

読み取りリージョン障害時の挙動

このセクションでは、複数の読み取りリージョンでAzure Cosmos DB アカウントを構成し、アカウントのいずれかの読み取りリージョンで障害が発生した場合に想定される内容について説明します。

• 検出と応答: 停止を検出して対応する責任は、アカウントが使用するフェールオーバーの種類によって異なります。

  • PPAF: PPAF は通常、読み取りリージョンの停止には適用されません。 ただし、一貫性が強く、リージョンが 2 つのアカウントの場合、読み取りリージョンが失われると、アカウントが 1 つのリージョンに減り、動的クォーラムを維持できません。 このシナリオでは、PPAF は、影響を受けるパーティションを正常なリージョンに移行することで、可用性を維持するためにアクティブ化できます。

  • 強制フェールオーバー: 強制フェールオーバーを実行する必要があります。 詳細な手順については、「Azure Cosmos DB アカウントのPerform 強制フェールオーバーを参照してください。

    フェールオーバーを実行しない場合、アカウントの動作は、その整合性レベルによって異なります。

    • 強力な整合性: 厳密な整合性には、 動的クォーラムを維持するために 2 つ以上のリージョンが必要です。 使用可能なリージョンが 2 つ未満で、フェールオーバーを実行しない場合、アカウントはサービスの復元まで書き込み可用性を失います。

    • 有界整合性制約の整合性: 有界整合性制約の整合性は、リージョン間の特定の制約のしきい値を維持することに依存します。 リージョンの停止の長さがしきい値を超えた場合、システムは書き込み間の整合性を維持できません。 フェールオーバーを実行しない場合、アカウントはサービスの復元まで書き込み可用性を失います。

  • Service-managed failover: サービスマネージド フェールオーバーが有効になっている場合、Microsoftは最終的に停止を検出し、アカウントのフェールオーバーを開始します。 ただし、このプロセスには、1 時間以上かかる場合があります。 復旧を高速化するには、サービスで管理されたフェールオーバーがトリガーされるのを待つのではなく、強制フェールオーバーを実行します。

• Notification: Microsoftは、リージョンがダウンしたときに自動的にユーザーに通知しません。 しかし：

  • Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Health アラートを設定して問題を通知することができます。

  • Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定できます。

• アクティブな要求: アクティブな要求はすべて終了する可能性があり、フェールオーバーの完了後にクライアントによって再試行する必要があります。 クライアントが短時間後に再試行することによって 一時的な障害 を適切に処理する場合、通常は重大な影響を回避します。

• 予想されるデータ損失: 読み取りリージョンで障害が発生しても、データが失われることはありません。 Azure Cosmos DBは、読み取りの整合性の保証を引き続き受け入れる。

• 予想されるダウンタイム: アカウントで発生するダウンタイムの量は、アカウントが使用するフェールオーバーの種類によって異なります。

  • PPAF: PPAF が有効になっている場合、システムは自動的に障害を検出して復旧します(通常は 3 分以内)。手動による介入は必要ありません。

  • 強制フェールオーバー: ダウンタイムは次に依存します。

    • 停止を検出してフェールオーバーを開始するのにかかる時間。

    • フェールオーバーにかかる時間 (通常は数秒)。

      Warnung

      障害シナリオ中に影響を受けるリージョンに対して構成 (コントロール プレーン) 操作を実行しないでください。アカウントの不整合と復旧の遅延が発生するためです。 回避すべきコントロール プレーン操作の一部例を次に示します:

      • 書き込みリージョンの変更またはフェールオーバーの優先順位の変更
      • アカウントを複数書き込み構成に更新する
      • 整合性レベルまたはその他のアカウント設定の更新
      • プライベート エンドポイントの構成またはネットワーク設定の更新
      • アカウントのスループットまたはスケーリング操作の更新
      • アカウントの構成またはリージョンの設定を変更するその他の操作

  • Service-managed failover: Microsoft はサービス管理フェールオーバーの開始を担当し、アカウント エクスペリエンスのダウンタイムは、停止の宣言とフェールオーバーの開始にMicrosoftかかる時間に基づいています。 状況によっては、1 時間以上かかる場合があります。 アカウントで書き込みが中断され、書き込みの可用性をすばやく復元する必要がある場合は、強制フェールオーバーを実行します。

• 再 分配： 強制フェールオーバーまたはサービス管理フェールオーバーの場合、影響を受けるリージョンは切断され、オフラインとしてマークされます。

  読み取りリージョンの停止を処理するアプリケーション コードは、変更する必要はありません。 Azure Cosmos DB SDK は、優先リージョンの一覧で次に使用可能なリージョンに読み取り操作をリダイレクトします。 優先リージョンの一覧のどのリージョンも使用できない場合、読み取り操作は、サービスで構成されているアカウントの現在の書き込みリージョンに自動的にフォールバックします。

  Note

  Azure Cosmos DB アカウントでプライベート エンドポイントを使用する場合は、オフライン リージョンの操作後にプライベート DNS が正しくルーティングされていることを確認します。 詳細なガイダンスについては、 プライベート エンドポイントのフェールオーバーに関する考慮事項を参照してください。

書き込みリージョンの障害時の動作

このセクションでは、複数の読み取りリージョンでAzure Cosmos DB アカウントを構成し、アカウントの書き込みリージョンで障害が発生した場合の対処方法について説明します。

• 検出と応答: 停止を検出して対応する責任は、アカウントが使用するフェールオーバーの種類によって異なります。

  • PPAF: Microsoft は停止を自動的に検出し、必要に応じて一部のパーティションのフェールオーバーを開始します。 アプリケーションでアクションを実行する必要はありません。

  • 強制フェールオーバー: 強制フェールオーバーを実行する必要があります。 詳細な手順については、「Azure Cosmos DB アカウントのPerform 強制フェールオーバーを参照してください。

    フェールオーバーを実行しない場合、アカウントはサービスの復元まで書き込み可用性を失います。

    アカウントの書き込みリージョンが停止した場合は、 変更書き込みリージョン の操作を実行しないでください。 ソースまたは宛先リージョンの停止が発生した場合、リージョンの変更を書き込むには成功しません。 その理由は、リージョン変更手順に、リージョン間の接続を必要とする整合性チェックが含まれていることです。

  • Service-managed failover: Microsoft は自動的に停止を検出し、アカウントのフェールオーバーを開始します。 アプリケーションでアクションを実行する必要はありません。

• Notification: Microsoftは、リージョンがダウンしたときに自動的にユーザーに通知しません。 しかし：

  • Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Health アラートを設定して問題を通知することができます。

  • Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定できます。

• アクティブな要求: アクティブな要求はすべて終了する可能性があり、フェールオーバーの完了後にクライアントによって再試行する必要があります。 クライアントが短時間後に再試行することによって 一時的な障害 を適切に処理する場合、通常は重大な影響を回避します。

• 予想されるデータ損失: 強力な一貫性を持つアカウントを構成した場合、データ損失は発生しません。 それ以外の場合は、フェールオーバーの完了後に、レプリケーションされていない書き込みが失われる可能性があります。 リージョンの停止中に予想される最大データ損失の詳細については、「リージョンの 停止中の潜在的なデータ損失」を参照してください。

• 予想されるダウンタイム: アカウントで発生するダウンタイムの量は、アカウントが使用するフェールオーバーの種類によって異なります。

  • PPAF: PPAF が有効になっている場合は、短い中断が予想されます。通常は約 3 分です。

  • 強制フェールオーバー: ダウンタイムは次に依存します。

    • 停止を検出してフェールオーバーを開始するのにかかる時間。
    • フェールオーバーにかかる時間 (通常は数秒)。

  Warnung

  障害シナリオ中に影響を受けるリージョンに対してコントロール プレーン操作を実行しないでください。これは、アカウントの不整合と復旧の遅延が発生するためです。 回避すべきコントロール プレーン操作の一部例を次に示します:

  • 書き込みリージョンの変更またはフェールオーバーの優先順位の変更
  • アカウントを複数書き込み構成に更新する
  • 整合性レベルまたはその他のアカウント設定の更新
  • プライベート エンドポイントの構成またはネットワーク設定の更新
  • アカウントのスループットまたはスケーリング操作の更新
  • アカウントの構成またはリージョンの設定を変更するその他の操作
  • Service-managed failover: Microsoft はサービス管理フェールオーバーの開始を担当し、アカウント エクスペリエンスのダウンタイムは、停止の宣言とフェールオーバーの開始にMicrosoftかかる時間に基づいています。 状況によっては、1 時間以上かかる場合があります。 書き込み可用性をすばやく復元するには、強制フェールオーバーを実行します。

• 再 分配： 書き込みトラフィックの再配布は、アカウントで使用するフェールオーバーの種類によって異なります。

  • PPAF: Azure Cosmos DBは、異常なパーティションを正常なリージョンに自動的にフェールオーバーします。

  • 強制フェールオーバー: 強制フェールオーバーを実行すると、アカウントの書き込みリージョンが指定したリージョンに変更されます。

  Note

  Azure Cosmos DB アカウントでプライベート エンドポイントを使用する場合は、オフライン リージョンの操作後にプライベート DNS が正しくルーティングされていることを確認します。 詳細なガイダンスについては、 プライベート エンドポイントのフェールオーバーに関する考慮事項を参照してください。

  • Service-managed failover: Azure Cosmos DB は、アカウントのセカンダリリージョンの中から自動的に新しいプライマリ書き込みリージョンを昇格させます。 指定するリージョンの優先順位に従って別のリージョンにフェールオーバーが行われます。

リージョンの復旧

Microsoftリージョンをオンラインに戻す必要があります。 障害が発生した後にリージョンが復旧すると、Microsoftは自動的にリージョンをオンラインにします。 ただし、このプロセスには数日かかる場合があります。

リージョンがオンラインになった後に実行するアクションは、停止が読み取りリージョンか書き込みリージョンかによって異なります。

• 読み取りリージョンの停止後: 影響を受けるリージョンがオンラインに戻ると、現在の書き込みリージョンと同期され、完全に追いついた後に読み取り要求を処理するために再び使用できます。 それ以降の読み取りは、アプリケーション コードを変更しなくても、回復したリージョンにリダイレクトされます。 フェールオーバー中も、以前に障害が発生したリージョンの再参加中も、読み取り整合性の保証は引き続き Azure Cosmos DB によって遵守されます。

• 書き込みリージョンの停止後: 影響を受けるリージョンがオンラインに戻ると、そのリージョンは Azure ポータルに "オンライン" と表示され、読み取りリージョンとして使用できるようになります。 この時点で、 書き込みリージョンを復旧されたリージョンに戻しても安全です。

  Important

  復旧されたリージョンは、復旧後 に書き込みリージョンとして自動的に昇格されません 。 あなたの責任として、安全であれば、復旧されたリージョンを再び書き込みリージョンに変更してください。

  書き込みリージョンを変更する前、間、または後に、 データや可用性の損失はありません 。 アプリケーションの高可用性が維持されます。

  リージョンがオフラインになるまでに書き込みがレプリケートされなかった場合は、 競合フィードから未更新の書き込みを読み取ることができます。 アプリケーションは、競合フィードを読み取り、アプリケーション固有のロジックに基づいて競合を解決し、必要に応じて更新されたデータをコンテナーに書き戻すことができます。

リージョン障害のテスト

Azure Cosmos DB アカウントの可用性が高い場合でも、アプリケーションでリージョンのフェールオーバーが正しく処理されない可能性があります。 アプリケーションのテストまたはディザスター リカバリー (DR) 訓練の一部としてアプリケーションのエンド ツー エンドの高可用性をテストするには、アカウントのサービスマネージド フェールオーバーを一時的に無効にします。 PowerShell、Azure CLI、またはAzure ポータルを使用して強制フェールオーバーを呼び出し、アプリケーションを監視します。 テストが完了したら、リージョンが自動的にオンラインに戻ったらプライマリ リージョンにフェールオーバーしてから、アカウントのサービス管理フェールオーバーを復元できます。 リージョンが 1 日または 2 日以内にオンラインに戻らない場合は、サポート ケースを開いてサポートを依頼してください。

アカウントで PPAF を使用している場合は、パーティションのフェールオーバーをシミュレートできます。 詳細については、 PPAF セットアップのテスト (障害のシミュレート) を参照してください。

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

複数のリージョンで書き込みを受け入れるように Azure Cosmos DB を構成できます。 この構成では、リージョンの停止に対する非常に高い回復性を提供できます。 また、地理的に分散されたアプリケーションの書き込み待機時間を短縮する場合にも役立ちます。

Azure Cosmos DB アカウントを示す図です。リージョン A とリージョン B はどちらも書き込みおよび読み取りリージョンです。リージョン A のアプリケーションは、そのリージョンの Azure Cosmos DB アカウントに対して読み取りおよび書き込みを実行します。リージョン B のアプリケーションも同様に、そのリージョンの Azure Cosmos DB アカウントに対して読み取りおよび書き込みを実行します。内部的には、Azure Cosmos DB がリージョン間で変更を非同期的にレプリケートします。

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

アプリケーションの設計と、複数の書き込みリージョンでの動作を考慮することが重要です。 複数リージョンの書き込みのベスト プラクティスを確認します。

Requirements

Region support: Azure Cosmos DB アカウントの読み取りまたは書き込みリージョンとして任意のAzure リージョンを構成できます。

Cost

Azure Cosmos DB アカウントに書き込みリージョンを追加すると、リージョンごとに既存のコストが増加します。 詳細については、「Azure Cosmos DB pricing」を参照してください。

複数の書き込みリージョンを構成する

アカウントの作成時、またはアカウントの作成後いつでも、アカウントに対して複数の書き込みリージョンを構成できます。 詳細については、「 複数の書き込みリージョンを構成する」を参照してください。

複数の書き込みリージョンを効果的に使用するには、アプリも適切に構成する必要があります。 Azure Cosmos DB を使用するアプリケーションでのマルチリージョン書き込みの構成に関する説明を参照してください。

容量の計画と管理

アプリケーションがリージョン間で要求を分散し、1 つのリージョンがオフラインになった場合、残りのリージョンでは要求量が多くなります。 自動スケール スループットを使用して、需要に基づいて容量を動的に調整します。 プロビジョニング済みスループットを使用する場合は、サービスの低下なしにリージョンの損失を処理するための十分な容量を計画し、過剰プロビジョニングを検討してください。 詳細については、「 過剰プロビジョニングによる容量の管理」を参照してください。

すべてのリージョンが正常な場合の動作

このセクションでは、複数の書き込みリージョンでAzure Cosmos DB アカウントを構成し、すべてのリージョンが動作している場合に想定される内容について説明します。

• リージョン間操作: アカウントが複数の書き込みリージョンで構成されている場合、アプリケーションは読み取りと書き込みの操作に使用するリージョンを構成します。 リージョンの優先順位付けされた一覧を使用してアプリケーションを構成したり、一部のリージョンを除外したりできます。 リージョンの選択のしくみの詳細については、「Diagnose」を参照し、複数のリージョン環境でのAzure Cosmos DB SDK の可用性のトラブルシューティングを行います。 アプリケーションを構成する方法については、Azure Cosmos DB を使用するアプリケーションでの マルチリージョン書き込みの構成に関するページを参照してください。

• リージョン間データ レプリケーション: データはリージョン間で非同期的にレプリケートされます。 レプリケーションのラグは、アカウントの整合性レベルによって異なります。 複数リージョンの書き込みに強力な整合性を使用することはできません。 詳細については、「 リージョンの停止中にデータが失われる可能性がある」を参照してください。

  アカウントが複数の書き込みリージョン用に構成されている場合、異なるリージョン内のアプリケーションが相互に競合する変更を行う可能性があります。 Azure Cosmos DBは競合解決機能を提供します。 詳細については、「複数の 書き込みリージョンを使用する場合の競合の種類と解決ポリシー」を参照してください。 独自の競合解決ポリシーを構成する方法については、Azure Cosmos DB の Manage 競合解決ポリシーに関するページを参照してください。

  Note

  同じドキュメント ID を頻繁に更新したり、TTL の有効期限が切れたり削除された後に同じドキュメント ID を頻繁に再作成したりすると、システムで生成される競合の数が増えたため、レプリケーションのパフォーマンスに悪影響が及びます。

リージョン障害時の動作

このセクションでは、複数の書き込みリージョンでAzure Cosmos DB アカウントを構成し、アカウントのいずれかの読み取りまたは書き込みリージョンで障害が発生した場合に想定される内容について説明します。

• 検出と応答: アプリケーションは、リージョンの損失を検出します。 Azure Cosmos DB SDK は、読み取り操作と書き込み操作を正常なリージョンにルーティングする自動リージョン選択機能を提供します。

• Notification: Microsoftは、リージョンがダウンしたときに自動的にユーザーに通知しません。 しかし：

  • Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Health アラートを設定して問題を通知することができます。

  • Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定できます。

• アクティブな要求: アクティブな要求はすべて終了する可能性があり、フェールオーバーの完了後にクライアントによって再試行する必要があります。 クライアントが短時間後に再試行することによって 一時的な障害 を適切に処理する場合、通常は重大な影響を回避します。

• 予想されるデータ損失: 最近更新されたデータは、他のリージョンでは使用できなくなる可能性があります。 リージョンの停止中に予想される最大データ損失の詳細については、「リージョンの 停止中の潜在的なデータ損失」を参照してください。 影響を受けるリージョンで起こる可能性は低いですが、永続的なデータ損失が発生した場合、複製されていないデータが失われる可能性があります。

• 予想されるダウンタイム: SDK が ApplicationRegions または PreferredRegionsで正しく構成されている場合、複数書き込み構成で予期されるダウンタイムはありません。

  ヒント

  最適な結果を得るには、グローバル分散アプリケーションは、Azure Front DoorやAzure Traffic Managerなどのグローバル負荷分散サービスによって前面に配置する必要があります。 これらのサービスは、リージョンの低下を検出し、正常なリージョン内のアプリケーション インスタンスにトラフィックを自動的にルーティングできます。

• Redistribution: Azure Cosmos DB SDK は、リージョンが異常であることを自動的に検出し、優先リージョンの一覧で次に使用可能なリージョンに読み取りと書き込み操作をリダイレクトします。 アプリケーション コードに変更は必要ありません。

  ヒント

  アプリケーションが Azure Front Door または Traffic Manager によって前面に配置されている場合、それらのサービスはリージョンの低下を検出し、トラフィックを正常なリージョンにルーティングします。

リージョンの復旧

影響を受けるリージョンがオンラインに戻ると、リージョンは Azure ポータルに "オンライン" と表示され、再び使用可能になります。

リージョンが失敗したときにレプリケートされなかった書き込みデータは、 競合フィードを通じて使用できるようになります。 アプリケーションは競合フィードを読み取り、そのアプリケーション固有のロジックに基づいて競合を解決した後、更新されたデータを必要に応じて Azure Cosmos DB コンテナーに書き戻すことができます。

リージョン障害のテスト

複数リージョンの書き込みフェールオーバー シナリオをテストするには、 強制フェールオーバーを使用して書き込みリージョンをオフラインにすることができます。 このプロセスは、リージョンの停止をシミュレートし、アプリケーションがどのように応答するかを確認できます。

バックアップと復元

ほとんどのソリューションでは、バックアップのみに依存しないでください。 代わりに、このガイドで説明されている他の機能を使用して、回復性の要件をサポートします。 ただし、バックアップでは、他の方法では行わないリスクから保護されます。 詳細については、「冗長性、レプリケーション、バックアップとは」を参照してください。

データの損失は、誤って削除されたり、データの破損を引き起こすアプリケーションのその他の問題が原因で発生する可能性があります。 単一リージョン アカウントを使用すると、Azure Cosmos DB リージョンで回復不能な障害が発生したため、データ損失が発生する可能性もあります。 データ損失から保護するために、Azure Cosmos DBには一連のバックアップと復元の機能が用意されています。 回復性の要件とコスト要件に基づいて、バックアップとリテンション期間を構成できます。 詳細については、「Azure Cosmos DB でのオンライン バックアップとオンデマンドのデータ復元」をご覧ください。

サービス メンテナンスに対する回復性

Azure Cosmos DBは、個々のコンピューティング ノードのすべての詳細を透過的に管理し、修正プログラムの適用やその他の種類の計画メンテナンスを自動的に実行します。 可用性と待機時間のAzure Cosmos DB SLA は、システムが実行するすべての自動メンテナンス操作によって適用されます。

サービス水準合意書

Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。

Azure Cosmos DBでは、可用性、待機時間、スループット、整合性など、さまざまな構成とサービス特性に対する SLA が提供されます。

可用性 SLA は、次のいずれかの製品機能を使用するかどうかによって異なります。

• プロビジョニングスループット
• 可用性ゾーン対応の単一リージョンアカウント（ゾーン冗長性）
• 複数の読み取りリージョンを使用するアカウント
• 複数の書き込みリージョンを使用するアカウント (Business Critical レベル)

関連するコンテンツ

• Azureの信頼性
• Azure Cosmos DBの概要
• Azure Cosmos DB の整合性レベル
• Azure Cosmos DB を使用したグローバルデータの分散
• 多地域環境でのAzure Cosmos DB SDK の可用性の診断とトラブルシューティングを行います