Azure Cosmos DB の整合性レベル

適用対象: SQL API Cassandra API Gremlin API Table API MongoDB 用 Azure Cosmos DB API

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

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

  • 厳密
  • 有界整合性制約
  • セッション
  • 整合性のあるプレフィックス
  • 最終的

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

範囲としての整合性

読み取りと書き込みが行われるリージョン、Azure Cosmos アカウントに関連付けられているリージョン数、またはアカウントの構成に使用されている書き込みリージョンが 1 つか複数かには関係なく、Azure Cosmos アカウントの整合性レベルはリージョンに依存せず、すべての操作で保証されています。

整合性レベルと Azure Cosmos DB API

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

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

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

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

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

重要

既定の整合性レベルを変更した後、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" リージョンと "オーストラリア東部" リージョンでは、構成された最大遅延時間または最大操作に基づき、書き込まれた値を読み取ります。

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

"セッション" 整合性

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

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

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

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

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

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

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

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

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

整合性のあるプレフィックスでは、返される更新には、それ以外のすべての更新の一部のプレフィックスがギャップなしで含まれます。 整合性のあるプレフィックスの整合性レベルでは、読み取りの際、書き込みを順序どおりに参照することが保証されます。

書き込みが A, B, C の順で実行された場合、クライアントでは AA,B、または A,B,C が確認されますが、A,C または B,A,C などの順不同の順列が確認されることはありません。 整合性のあるプレフィックスでは、書き込み待機時間、可用性、読み取りスループットは最終的整合性と同等ですが、順序が重要となるシナリオのニーズに合わせて順序も保証されます。

一貫性のあるプレフィックスの整合性の保証は次のとおりです。

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

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

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

最終的な一貫性

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

最終的な整合性の図

整合性の実際の保証

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

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

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

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

整合性レベルと待機時間

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

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

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

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

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

重要

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

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

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

  • 書き込み操作の種類 (挿入、置換、アップサート、削除) が指定された場合、要求ユニットに対するスループットはすべての整合性レベルで同じです。

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

注意

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

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

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

次の表は、リージョン全体の停止が発生した場合の整合性モデルとデータ持続性の間の関係を定義しています。 分散型システムでは、強固な整合性を備えていても、CAP 定理のために、RPO と RTO が 0 の分散型データベースを持つことは不可能である点に注意することが重要です。

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

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

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

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

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

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

その他の情報

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

次のステップ

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