Azure Cosmos DB の整合性レベル

適用対象: NoSQL MongoDB Cassandra Gremlin Table

高可用性、低遅延、またはその両方のためにレプリケーションに依存する分散データベースでは、PACELC の定理で定義されているとおり、読み取りの整合性、可用性、待機時間、スループットの間で基本的なトレードオフが必要になります。 厳密な整合性モデルの線形化可能性は、データ プログラミングの標準基準です。 しかし、大きな距離にわたってデータをレプリケートしてコミットする必要があるため、長い書き込み待機時間により高いコストが追加されます。 また、すべてのリージョンでデータをレプリケートしてコミットすることはできないため、強固な整合性は (障害発生時の) 可用性の低下の影響を受ける場合もあります。 最終的な整合性では可用性とパフォーマンスは向上しますが、すべてのリージョンでデータが完全に一致しない可能性があるため、アプリケーションのプログラミングは困難になります。

現在市場で利用可能な市販の分散 NoSQL データベースのほとんどは、強固かつ最終的な一貫性のみを提供しています。 Azure Cosmos DB では、5 つの明確に定義されたレベルが提供されます。 最強から最弱の順に、次のレベルがあります。

既定の整合性レベルについて詳しくは、「既定の一貫性レベルの構成」または「既定の一貫性レベルを上書きする」をご覧ください。

各レベルには、可用性とパフォーマンスのトレードオフが存在します。 次の図では、さまざまな整合性レベルの範囲内での位置づけを示します。

範囲としての整合性

整合性レベルと Azure Cosmos DB API

Azure Cosmos DB は、一般的なデータベース用のワイヤ プロトコルに対応する API をネイティブにサポートしています。 たとえば、MongoDB、Apache Cassandra、Apache Gremlin、Azure Table Storage などです。 Gremlin 用 API または Table を使用する場合、Azure Cosmos DB アカウントに構成されている既定の整合性レベルが使用されます。 Apache Cassandra と Azure Cosmos DB 間の整合性レベル マッピングの詳細については、Cassandra 用 API の整合性マッピングに関する記事を参照してください。 MongoDB と Azure Cosmos DB 間の整合性レベル マッピングの詳細については、MongoDB 用 API の整合性マッピングに関する記事を参照してください。

読み取り整合性のスコープ

読み取り整合性は、論理パーティション内をスコープとする 1 つの読み取り操作に適用されます。 読み取り操作はリモート クライアントまたはストアド プロシージャが発行できます。

既定の整合性レベルを構成する

Azure Cosmos DB アカウントの既定の整合性レベルはいつでも構成できます。 自分のアカウントに構成されている既定の整合性レベルは、そのアカウントのすべての Azure Cosmos DB データベースおよびコンテナーに適用されます。 コンテナーまたはデータベースに対して発行されるすべての読み取りとクエリでは、指定された整合性レベルが既定で使用されます。 詳しくは、既定の整合性レベルを構成する方法についての記事をご覧ください。 また、特定の要求に対して既定の整合性レベルをオーバーライドすることもできます。詳細については、「既定の整合性レベルをオーバーライドする」を参照してください。

ヒント

既定の整合性レベルのオーバーライドは、SDK クライアント内の読み取りにのみ適用されます。 既定で厳密な整合性を使用するように構成されたアカウントでも、データの書き込みとレプリケートは、アカウントの各リージョンに対して同期的に実行されます。 SDK クライアント インスタンスまたは要求が、セッションの整合性または弱い整合性でこれをオーバーライドした場合、読み取りは単一のレプリカを使用して実行されます。 詳しくは、「整合性レベルとスループット」をご覧ください。

重要

既定の整合性レベルを変更した後、SDK インスタンスを再作成する必要があります。 これは、アプリケーションを再起動することによって行うことができます。 これにより、SDK で新しい既定の一貫性レベルが使用されるようになります。

整合性レベルに関連付けられた保証

Azure Cosmos DB では、読み取り要求の 100 パーセントが、選択した整合性レベルについて整合性の保証を満たすことが保証されます。 TLA+ 仕様言語を使用した Azure Cosmos DB での 5 つの整合性レベルの正確な定義は、azure-cosmos-tla GitHub リポジトリで提供されています。

5 つの整合性レベルのセマンティクスは、この後のセクションで説明します。

"強固" 整合性

強力な一貫性は、線形化可能性保証を与えます。 線形化可能性は、要求に同時にサービスを提供することを意味します。 読み取りでは、アイテムの最後にコミットされたバージョンが返ることが保証されています。 クライアントが、コミットされていない書き込みや部分的な書き込みを見ることは決してありません。 ユーザーが最新のコミット済みの書き込みを読み取ることが常に保証されます。

次のグラフィックでは、音符の厳密な一貫性を図解しています。 データが "米国西部 2" リージョンに書き込まれると、他のリージョンからデータを読み取るとき、最新の値が取得されます。

厳密な整合性レベルの図

"有界整合性制約" 整合性

有界整合性制約の整合性を確保するために、読み取りでは、整合性のあるプレフィックスの優先が保証されます。 読み取りは、最大でアイテムの "K" 個のバージョン (更新)、あるいは期間 "T" のどちらか早く達した方の分だけ書き込みよりも遅れる場合があります。 つまり、有界整合性制約を選択する場合、"整合性制約" は 2 つの方法で構成できます。

  • アイテムのバージョンの数 (K)
  • 書き込みに対して読み取りが遅れる可能性がある期間 (T)

単一リージョン アカウントの場合、KT の最小値は 10 回の書き込み操作または 5 秒です。 複数リージョン アカウントの場合、KT の最小値は 100,000 回の書き込み操作または 300 秒です。

有界整合性制約では、「整合性制約期間」外でトータルなグローバル順序が実現されます。書き込みを受け入れるリージョン内でクライアントが読み取り操作を実行するとき、有界整合性制約整合性で提供される保証は、厳密な整合性の場合と同じです。 整合性制約期間が時間または更新のいずれか近い方に近づくと、サービスは新しい書き込みを調整して、レプリケーションが追いつき、整合性の保証を優先できるようにします。

整合性制約期間内では、有界整合性制約は次の一貫性の保証を提供します。

  • 単一の書き込みリージョンを持つアカウントに対して、同じリージョン内のクライアントの整合性 = 厳密

  • 単一の書き込みリージョンを持つアカウントに対して、異なるリージョン内のクライアントの整合性 = 整合性のあるプレフィックス

  • 複数の書き込みリージョンを持つアカウントに対して、単一のリージョンに書き込みを行うクライアントの整合性 = 整合性のあるプレフィックス

  • 複数の書き込みリージョンを持つアカウントに対して、異なるリージョンに書き込みを行うクライアントの整合性 = 最終的

    世界中に分散されているアプリケーションで、書き込み時の待ち時間が短く、全体のグローバルな順序保証が求められるとき、有界整合性制約が頻繁に選ばれています。 有界整合性制約は、グループの共同作業と共有、株式相場表示器、発行とサブスクライブまたはキューなどを特徴とするアプリケーションに最適です。次のグラフィックでは、音符の有界整合性制約整合性を図解しています。 データが "米国西部 2" リージョンに書き込まれた後、"米国東部 2" リージョンと "オーストラリア東部" リージョンでは、構成された最大遅延時間または最大操作に基づき、書き込まれた値を読み取ります。

    有界整合性制約の整合性レベルの図

"セッション" 整合性

セッション整合性での単一のクライアント セッション内の読み取りでは、整合性のあるプレフィックス、単調読み取り、単調書き込み、自己書き込みの読み取り、読み取り後の書き込みの優先が保証されます。 これは、単一の「ライター」セッションを使用するか、複数のライターのセッション トークンを共有することを前提としています。

書き込みを実行しているセッションの外部のクライアントは、以下の保証を確認できます。

  • 単一の書き込みリージョンを持つアカウントに対して、同じリージョン内のクライアントの整合性 = 整合性のあるプレフィックス

  • 単一の書き込みリージョンを持つアカウントに対して、異なるリージョン内のクライアントの整合性 = 整合性のあるプレフィックス

  • 複数の書き込みリージョンを持つアカウントに対して、単一のリージョンに書き込みを行うクライアントの整合性 = 整合性のあるプレフィックス

  • 複数の書き込みリージョンを持つアカウントに対して、複数のリージョンに書き込みを行うクライアントの整合性 = 最終的

  • Azure Cosmos DB 統合キャッシュを使用するクライアントの整合性 = 最終的

    セッション整合性は、1 つのリージョンのアプリケーションと世界中に分散されたアプリケーションの両方で最も広く使用されている整合性レベルです。 書き込みの待機時間、可用性、読み取りスループットは最終的整合性レベルと同等ですが、ユーザーのコンテキスト内で動作するよう作成されたアプリケーションのニーズに適した整合性保証が提供されます。 次のグラフィックでは、音符のセッション整合性を図解しています。 「米国西部 2 ライター」と「米国東部 2 リーダー」は同じセッション (セッション A) を使用しているため、どちらも同時に同じデータを読み取ります。 一方、"オーストラリア東部" リージョンでは "セッション B" が使用されているため、後でデータを受け取るとき、書き込みと同じ順序になります。

    セッションの整合性レベルの図

"一貫性のあるプレフィックス" 整合性

一貫性のあるプレフィックスでは、単一ドキュメントの書き込みとして行われる更新の場合、最終的な整合性が表示されます。 トランザクション内でバッチとして行われた更新は、それがコミットされたトランザクションと一貫性を保って返されます。 複数のドキュメントに対するトランザクション内の書き込み操作は、常に一緒に表示されます。

トランザクション T1 と T2 内でドキュメント Doc1 と Doc2 に対して 2 つの書き込み操作を行ったとします。 クライアントがいずれかのレプリカ内で読み取りを行った場合、ユーザーには "Doc1 v1 と Doc2 v1" または "Doc1 v2 と Doc2 v2" のどちらかが表示されますが、同じ読み取りまたはクエリ操作に対して "Doc1 v1 と Doc2 v2" または "Doc1 v2 と Doc2 v1" は表示されません。

トランザクション コンテキスト内での一貫性のあるプレフィックスに関する一貫性の保証を次に示します (単一ドキュメントの書き込みの場合、最終的な整合性が表示されます)。

  • 単一の書き込みリージョンを持つアカウントに対して、同じリージョン内のクライアントの整合性 = 整合性のあるプレフィックス
  • 単一の書き込みリージョンを持つアカウントに対して、異なるリージョン内のクライアントの整合性 = 整合性のあるプレフィックス
  • 複数の書き込みリージョンを持つアカウントに対して、単一のリージョンに書き込みを行うクライアントの整合性 = 整合性のあるプレフィックス
  • 複数の書き込みリージョンを持つアカウントに対して、複数のリージョンに書き込みを行うクライアントの整合性 = 最終的

次のグラフィックでは、音符の整合性のあるプレフィックスの整合性を図解しています。 すべてのリージョンで、読み取りで順序が乱れた書き込みに遭遇することはありません。

整合性のあるプレフィックスの図

最終的な一貫性

最終的な整合性では、読み取りの順序の保証はありません。 さらに書き込みがない場合、レプリカが最終的に収束します。

クライアントが以前に読み取ったものより古い値を読み取ることがあるため、最終的整合性は最も弱い形態の整合性です。 最終的整合性は、順序保証がアプリケーションで要求されないときに最適です。 たとえば、リツイート、いいね、スレッド化されていないコメントなどです。 次のグラフィックでは、音符の最終的整合性を図解しています。

最終的な整合性の図

整合性の実際の保証

実際には、より強力な整合性の保証を得られることがしばしばあります。 読み取り操作の整合性の保証は、要求するデータベースの状態の鮮度と順序に対応します。 読み取り一貫性は書き込み/更新操作の順序と伝達に関連付けられています。

データベースへの書き込み操作がない場合、最終的セッション、または一貫性のあるプレフィックスの整合性レベルでの読み取り操作は、強固な整合性レベルの読み取り操作と同じ結果になる可能性が高いと言えます。

Azure Cosmos DB アカウントが、強固な整合性以外の任意の整合性レベルで構成されている場合、"確率論的有界整合性制約" (PBS) メトリックを調べることによって、ワークロードの厳密な整合性を持つ読み取りをクライアントが取得する確率を調べることができます。 このメトリックは、Azure portal で公開されます。詳しくは、「確率的有界整合性制約 (PBS) メトリックを監視する」をご覧ください。

確率論的有界整合性制約は、最終的な整合性が、どれほど最終的であるかを示します。 このメトリックでは、Azure Cosmos DB アカウントで現在構成されている整合性レベルより強力な整合性をどのくらいの頻度で得られるかについての分析情報が提供されます。 つまり、書き込みと読み取りのリージョンの組み合わせに対して厳密な整合性の読み取りを取得する確率 (ミリ秒で測定) を表示できます。

整合性レベルと待機時間

すべての整合性レベルの読み取り待機時間は 99 パーセンタイルで 10 ミリ秒未満となるように常に保証されています。 平均読み取り待機時間は、(50 パーセンタイルで) 通常 4 ミリ秒以下です。

すべての整合性レベルの書き込み待機時間は 99 パーセンタイルで 10 ミリ秒未満となるように常に保証されています。 平均書き込み待機時間は、(50 パーセンタイルで) 通常 5 ミリ秒以下です。 複数のリージョンにまたがり、厳密な整合性で構成されている Azure Cosmos DB アカウントは、この保証の例外です。

書き込み待機時間と厳密な整合性

複数のリージョンでの厳密な整合性によって構成された Azure Cosmos DB アカウントの場合、書き込み待機時間は、99 パーセンタイルで 2 つの最も遠いリージョン間のラウンドトリップ時間 (RTT) の 2 倍 + 10 ミリ秒に等しくなります。 アカウント内のすべてのリージョンにコミットされたことを確認した後にしか厳密な整合性による操作は完了されないため、リージョン間のネットワーク RTT が高くなると、Azure Cosmos DB 要求の待機時間が長くなります。

正確な RTT 待機時間は、光の速さで通信する距離と Azure ネットワーク トポロジによって決まります。 Azure ネットワークでは、2 つの Azure リージョン間の RTT に対する待機時間の SLA は提供されませんが、「Azure ネットワーク ラウンドトリップ待ち時間統計」が公開されています。 Azure Cosmos DB アカウントの場合、レプリケーションの待機時間は Azure portal に表示されます。 Azure portal を使用して ([メトリック] ブレードに移動する)、ご自身の Azure Cosmos DB アカウントに関連付けられているさまざまなリージョン間のレプリケーション待機時間を監視できます。

重要

書き込み待機時間が長くなることから、5000 マイル (8000 キロメートル) を超えるリージョンでのアカウントの厳密な整合性は、既定でブロックされています。 この機能を有効にするには、サポートにお問い合わせください。

整合性レベルとスループット

  • 厳密と有界整合性制約では、一貫性の保証を提供するために、4 つのレプリカ セット (マイノリティ クォーラム) のうち 2 つのレプリカに対して読み取りが行われます。 セッション、一貫性のあるプレフィックス、および最終的では、単一のレプリカの読み取りが行われます。 結果として、同数の要求ユニットに対する厳密と有界整合性制約の読み取りスループットは、他の一貫性レベルの半分になります。

  • 書き込み操作の種類 (挿入、置換、アップサート、削除) が指定された場合、要求ユニットに対するスループットはすべての整合性レベルで同じです。 厳密な整合性のために、すべてのリージョン (グローバル マジョリティ) で変更をコミットする必要があります。一方、他のすべての整合性レベルでは、ローカル マジョリティ (4 つのレプリカ セットのうち、3 つのレプリカ) が使用されます。

整合性レベル クォーラムの読み取り クォーラムの書き込み
厳密 ローカル マイノリティ グローバル マジョリティ
有界整合性制約 ローカル マイノリティ ローカル マジョリティ
セッション 単一のレプリカ (セッション トークンを使用) ローカル マジョリティ
一貫性のあるプレフィックス 単一のレプリカ ローカル マジョリティ
最終的 単一のレプリカ ローカル マジョリティ

注意

ローカル マイノリティの読み取りに対する RU/秒の読み取りコストは、強度の低い一貫性レベルの場合の 2 倍です。これは、2 つのレプリカから読み取りが行われ、強固および有界整合性制約の整合性が保証されるためです。

整合性レベルとデータ持続性

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

次の表は、リージョン全体の停止が発生した場合の整合性モデルとデータ持続性の間の関係を定義しています。

リージョン レプリケーション モード 整合性レベル RPO
1 単一または複数の書き込みリージョン 任意の整合性レベル < 240 分
>1 単一の書き込みリージョン セッション、一貫性のあるプレフィックス、最終的 < 15 分
>1 単一の書き込みリージョン 有界整合性制約 K&T
>1 単一の書き込みリージョン Strong 0
>1 複数の書き込みリージョン セッション、一貫性のあるプレフィックス、最終的 < 15 分
>1 複数の書き込みリージョン 有界整合性制約 K&T

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

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

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

強力な整合性と複数の書き込みリージョン

分散システムでゼロの RPO とゼロの RTO を実現することはできないため、複数の書き込みリージョン用に構成された Azure Cosmos DB アカウントには、厳密な整合性を構成することはできません。 さらに、すべてのリージョンへの書き込みは、アカウント内のすべての構成済みリージョンにレプリケートおよびコミットされる必要があるため、強固な整合性と複数の書き込みリージョンを併用しても、書き込み待機時間の恩恵は受けられません。 この結果、単一の書き込みリージョン アカウントと同じ書き込み待機時間が発生します。

その他の情報

整合性の概念について詳しくは、以下の記事をご覧ください。

次のステップ

Azure Cosmos DB の整合性レベルの概念の詳細については、以下の記事をご覧ください。