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 または Table 用の API では、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" リージョンに書き込まれると、他のリージョンからデータを読み取るとき、最新の値が取得されます。
動的クォーラム
通常の状況では、強力な整合性を持つアカウントの場合、すべてのリージョンでレコードがレプリケートされたことが確認されると、書き込みがコミットされたとものと見なされます。 一方、(書き込みリージョンを含めて) 3 つ以上のリージョンがあるアカウントでは、一部のリージョンが応答しないか、応答が遅い場合、システムはリージョンのクォーラムをグローバル マジョリティに "ダウンシフト" できます。 その時点で、強力な整合性を維持するため、応答しないリージョンはリージョンのクォーラム セットから取り除かれます。 それらは、他のリージョンと調和し、期待どおりに動作するようになった後でのみ、追加して戻されます。 クォーラム セットから取り除かれる可能性のあるリージョンの数は、リージョンの合計数によって異なります。 たとえば、3 または 4 リージョンのアカウントでは、マジョリティはそれぞれ 2 または 3 リージョンであるため、どちらの場合も取り除けるリージョンは 1 つだけです。 5 リージョンのアカウントの場合、マジョリティは 3 であるため、最大 2 つの応答しないリージョンを取り除けます。 この機能は "動的クォーラム" と呼ばれ、リージョンが 3 つ以上のアカウントで、書き込みの可用性とレプリケーションの待ち時間の両方を向上させることができます。
Note
動的クォーラムの一部としてクォーラム セットからリージョンが取り除かれると、それらのリージョンは、クォーラムに再び追加されるまで、読み取りを処理できなくなります。
"有界整合性制約" 整合性
複数のリージョンを持つ単一リージョン書き込みアカウントの場合、データはそのプライマリ リージョンからすべてのセカンダリ (読み取り専用) リージョンにレプリケートされます。 複数のリージョンを持つマルチリージョン書き込みアカウントの場合、データは最初に書き込まれたリージョンから他のすべての書き込み可能なリージョンにレプリケートされます。 どちらのシナリオも一般的ではありませんが、リージョン間のレプリケーションには遅延が発生することがあります。
有界整合性制約の整合性では、任意の 2 つのリージョン間のデータのラグは、常に指定された量より小さくなります。 この量は、項目の "K" 個のバージョン (更新)、 または "T" 回の時間間隔のいずれか最初に達した方になります。 つまり、有界整合性制約を選んだ場合、任意のリージョンにおけるデータの最大 "整合性制約" は 2 つの方法で構成できます。
- アイテムのバージョンの数 (K)
- 書き込みに対して読み取りが遅れる可能性がある期間 (T)
有界整合性制約は、主に複数のリージョンがある単一リージョン書き込みアカウントに役立ちます。 リージョン内のデータの遅延 (物理パーティションごとに決定されます) が構成済みの整合性制約値を超えた場合、整合性制約が構成済みの上限以内に戻るまで、そのパーティションへの書き込みは調整されます。
単一リージョン アカウントの場合、有界整合性制約は、セッションおよび最終的な整合性と同じ書き込み整合性の保証を提供します。 有界整合性制約を使用すると、データは単一リージョン内のローカル マジョリティ (4 つのレプリカ セット内の 3 つのレプリカ) にレプリケートされます。
重要
有界整合性制約の整合性を使う場合、整合性制約チェックはリージョン全体に対してのみ行われ、1 つのリージョン内では行われません。 1 つのリージョン内では、整合性レベルに関係なく、データは常にローカル マジョリティ (4 つのレプリカ セット内の 3 つのレプリカ) にレプリケートされます。
有界整合性制約を使う読み取りの場合、そのリージョンで使用できる 2 つのレプリカから読み取ることで、そのリージョンで使用できる最新のデータが返されます。 1 リージョン内の書き込みは常にローカル マジョリティ (4 つのレプリカのうち 3 つ) にレプリケートされるので、2 つのレプリカを参照することで、そのリージョンで使用できる最新のデータが返されます。
重要
有界整合性制約の整合性を使う場合、プライマリでないリージョンに対して発行された読み取りからは、必ずしもグローバルに最新バージョンのデータが返されるとは限りません。ただし、そのリージョン内の最新バージョンのデータが確実に返されます。これは、グローバルに最大整合性制約の制限内に収まります。
有界整合性制約は、グローバルに分散したアプリケーションで、複数のリージョンを持つ単一リージョン書き込みアカウントを使っている場合に最適です。 複数のリージョンを持つマルチリージョン書き込みアカウントの場合、アプリケーション サーバーが、アプリケーション サーバーがホストされているのと同じリージョンに読み取りと書き込みを送信する必要があります。 複数書き込みアカウントの有界整合性制約は、アンチパターンです。 このレベルでは、リージョン間のレプリケーション ラグへの依存が必要になりますが、データが書き込まれたのと同じリージョンからデータが読み取られる場合は問題になりません。
次のグラフィックでは、音符の有界整合性制約整合性を図解しています。 データが "米国西部 2" リージョンに書き込まれた後、"米国東部 2" リージョンと "オーストラリア東部" リージョンでは、構成された最大遅延時間または最大操作に基づき、書き込まれた値を読み取ります。
"セッション" 整合性
セッション整合性での単一のクライアント セッション内の読み取りでは、自己書き込みの読み取り、読み取り後の書き込みの優先が保証されます。 この保証は、単一の "ライター" セッションを使用するか、複数のライターのセッション トークンを共有することを前提としています。
強力な一貫性よりも弱いすべての整合性レベルと同様に、書き込みはローカル リージョン内の少なくとも 3 つのレプリカ (4 つのレプリカ セット内) にレプリケートされ、他のすべてのリージョンに非同期レプリケーションが行われます。
書き込み操作のたびに、クライアントではサーバーから更新されたセッション トークンを受け取ります。 クライアントはトークンをキャッシュし、指定したリージョンでの読み取り操作のためにそれらをサーバーに送信します。 読み取り操作が発行されるレプリカに、指定されたトークン (またはより新しいトークン) のデータが含まれている場合は、要求されたデータが返されます。 レプリカにそのセッションのデータが含まれていない場合、クライアントではリージョン内の別のレプリカに対してその要求を再試行します。 必要に応じて、クライアントでは、指定されたセッション トークンのデータが取得されるまで、追加の使用可能なリージョンに対して読み取りを再試行します。
重要
セッション整合性では、クライアントによるセッション トークンの使用により、古いセッションに対応するデータが読み取られることはありません。 ただし、クライアントで古いセッション トークンを使用していて、データベースに対してより新しい更新が行われた場合は、古いセッション トークンが使用されていても、より新しいバージョンのデータが返されます。 セッション トークンは、最小バージョンのバリアとして使用されており、特定の (履歴の可能性がある) データのバージョンがデータベースから取得されるわけではありません。
Azure Cosmos DB のセッション トークンはパーティションにバインドされており、1 つのパーティションに排他的に関連付けられています。 書き込みを確実に読み取るには、関連する項目に対して最後に生成されたセッショントークンを使用します。
クライアントで物理パーティションへの書き込みが開始されなかった場合、クライアントではキャッシュにセッション トークンが含められず、その物理パーティションへの読み取りは最終的な整合性で読み取りとして動作します。 同様に、クライアントが再作成されると、セッション トークンのキャッシュも再作成されます。 この場合も、読み取り操作は、後続の書き込み操作でクライアントのセッション トークンのキャッシュが再作成されるまで、最終的な一貫性と同じ動作になります。
重要
セッション トークンが 1 つのクライアント インスタンスから別のクライアント インスタンスに渡される場合は、トークンの内容を変更しないでください。
セッション整合性は、1 つのリージョンのアプリケーションと世界中に分散されたアプリケーションの両方で最も広く使用されている整合性レベルです。 これにより、最終的な整合性に匹敵する書き込みの待機時間、可用性、読み取りスループットが提供されます。 セッション整合性により、ユーザーのコンテキストで動作するように作成されたアプリケーションのニーズに適合する整合性の保証も提供されます。 次のグラフィックでは、音符のセッション整合性を図解しています。 「米国西部 2 ライター」と「米国東部 2 リーダー」は同じセッション (セッション A) を使用しているため、どちらも同時に同じデータを読み取ります。 一方、"オーストラリア東部" リージョンでは "セッション B" が使用されているため、後でデータを受け取るとき、書き込みと同じ順序になります。
"一貫性のあるプレフィックス" 整合性
強力な一貫性よりも弱いすべての整合性レベルと同様に、書き込みはローカル リージョン内の少なくとも 3 つのレプリカ (4 つのレプリカ セット内) にレプリケートされ、他のすべてのリージョンに非同期レプリケーションが行われます。
一貫性のあるプレフィックスでは、単一ドキュメントの書き込みとして行われる更新の場合、最終的な整合性が表示されます。
トランザクション内でバッチとして行われた更新は、それがコミットされたトランザクションと一貫性を保って返されます。 複数のドキュメントに対するトランザクション内の書き込み操作は、常に一緒に表示されます。
トランザクション T1 と T2 内で、ドキュメント Doc1 に対して 2 つの書き込み操作がトランザクションで実行され (すべて行われるか、何も行われない操作)、その後、ドキュメント Doc2 に対して実行されるとします。 クライアントがいずれかのレプリカ内で読み取りを行った場合、ユーザーには "Doc1 v1 と Doc2 v1" または "Doc1 v2 と Doc2 v2" のどちらかが表示されるか、レプリカが遅れている場合はどちらのドキュメントも表示されませんが、同じ読み取りまたはクエリ操作で "Doc1 v1 と Doc2 v2" または "Doc1 v2 と Doc2 v1" が表示されることはありません。
次のグラフィックでは、音符の整合性のあるプレフィックスの整合性を図解しています。 すべてのリージョンでの読み取りで、書き込みトランザクション バッチの順序が乱れた書き込みに遭遇することはありません。
最終的な一貫性
強力な一貫性よりも弱いすべての整合性レベルと同様に、書き込みはローカル リージョン内の少なくとも 3 つのレプリカ (4 つのレプリカ セット内) にレプリケートされ、他のすべてのリージョンに非同期レプリケーションが行われます。
最終的な整合性では、クライアントは、指定したリージョン内の 4 つのレプリカのいずれかに対して読み取り要求を発行します。 このレプリカは遅れている可能性があり、古いデータが返されるか、データが返されないことがあります。
クライアントが過去に読み取った値よりも古い値を読み取る可能性があるため、最終的な整合性は最も弱い形態の整合性です。 最終的整合性は、順序保証がアプリケーションで要求されないときに最適です。 たとえば、リツイート、いいね、スレッド化されていないコメントなどです。 次のグラフィックでは、音符の最終的整合性を図解しています。
整合性の実際の保証
実際には、より強力な整合性の保証を得られることがしばしばあります。 読み取り操作の整合性の保証は、要求するデータベースの状態の鮮度と順序に対応します。 読み取り一貫性は書き込み/更新操作の順序と伝達に関連付けられています。
データベースへの書き込み操作がない場合、最終的、セッション、または一貫性のあるプレフィックスの整合性レベルでの読み取り操作は、強固な整合性レベルの読み取り操作と同じ結果になる可能性が高いと言えます。
ご自分のアカウントが厳密な整合性以外の整合性レベルで構成されている場合、クライアントがワークロードに対して厳密で一貫した読み取りを得られる可能性を確認できます。 この確率は、確率的有界整合性制約 (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 portal を使用すると、ご自分の Azure Cosmos DB アカウントに関連付けられているさまざまなリージョン間のレプリケーションの待機時間を監視できます。
重要
書き込み待機時間が長くなることから、5000 マイル (8000 キロメートル) を超えるリージョンでのアカウントの厳密な整合性は、既定でブロックされています。 この機能を有効にするには、サポートにお問い合わせください。
整合性レベルとスループット
厳密と有界整合性制約では、一貫性の保証を提供するために、4 つのレプリカ セット (マイノリティ クォーラム) のうち 2 つのレプリカに対して読み取りが行われます。 セッション、一貫性のあるプレフィックス、および最終的では、単一のレプリカの読み取りが行われます。 結果として、同数の要求ユニットに対する厳密と有界整合性制約の読み取りスループットは、他の一貫性レベルの半分になります。
書き込み操作の種類 (挿入、置換、アップサート、削除) が指定された場合、要求ユニットに対するスループットはすべての整合性レベルで同じです。 厳密な整合性のために、すべてのリージョン (グローバル マジョリティ) で変更をコミットする必要があります。一方、他のすべての整合性レベルでは、ローカル マジョリティ (4 つのレプリカ セットのうち、3 つのレプリカ) が使用されます。
| 整合性レベル | クォーラムの読み取り | クォーラムの書き込み |
|---|---|---|
| 厳密 | ローカル マイノリティ | グローバル マジョリティ |
| 有界整合性制約 | ローカル マイノリティ | ローカル マジョリティ |
| セッション | 単一のレプリカ (セッション トークンを使用) | ローカル マジョリティ |
| 一貫性のあるプレフィックス | 単一のレプリカ | ローカル マジョリティ |
| 最終的 | 単一のレプリカ | ローカル マジョリティ |
Note
ローカル マイノリティの読み取りに対する RU コストは、強度の低い一貫性レベルの場合の 2 倍です。これは、2 つのレプリカから読み取りが行われ、強固および有界整合性制約の整合性が保証されるためです。
整合性レベルとデータ持続性
グローバルに分散されるデータベース環境内では、リージョン全体にわたる停止が発生した場合の整合性レベルとデータ持続性の間には、直接的な関係があります。 ビジネス継続性計画を策定する場合、破壊的なイベント発生後の復旧中にアプリケーションが損失を許容できる新しいデータ更新の最大期間についても理解する必要があります。 損失を許容できる更新の期間は、目標復旧時点 (RPO) と呼ばれます。
この表は、リージョン全体の停止が発生した場合の整合性モデルとデータ持続性の間の関係を定義しています。
| リージョン | レプリケーション モード | 整合性レベル | RPO |
|---|---|---|---|
| 1 | 単一または複数の書き込みリージョン | 任意の整合性レベル | < 240 分 |
| >1 | 単一の書き込みリージョン | セッション、一貫性のあるプレフィックス、最終的 | < 15 分 |
| >1 | 単一の書き込みリージョン | 有界整合性制約 | K と T |
| >1 | 単一の書き込みリージョン | Strong | 0 |
| >1 | 複数の書き込みリージョン | セッション、一貫性のあるプレフィックス、最終的 | < 15 分 |
| >1 | 複数の書き込みリージョン | 有界整合性制約 | K と T |
K = 項目の "K" バージョン (更新) の数。
T = 前回の更新以降の期間 "T" 。
単一リージョン アカウントの場合、K と T の最小値は 10 回の書き込み操作または 5 秒です。 複数リージョン アカウントの場合、K と T の最小値は 100,000 回の書き込み操作または 300 秒です。 この値により、有界整合性制約を使用する場合のデータの最小 RPO が定義されます。
強力な整合性と複数の書き込みリージョン
分散システムでゼロの RPO とゼロの RTO を実現することはできないため、複数の書き込みリージョン用に構成された Azure Cosmos DB アカウントには、厳密な整合性を構成することはできません。 さらに、すべてのリージョンへの書き込みは、アカウント内のすべての構成済みリージョンにレプリケートおよびコミットされる必要があるため、強固な整合性と複数の書き込みリージョンを併用しても、書き込み待機時間の恩恵は受けられません。 このシナリオでは、単一の書き込みリージョン アカウントと同じ書き込み待機時間になります。
関連項目
整合性の概念について詳しくは、以下の記事をご覧ください。
- 「High-level TLA+ specifications for the five consistency levels offered by Azure Cosmos DB (Azure Cosmos DB によって提供される 5 つの整合性レベルのための高レベル TLA+ 仕様)」
- レプリケート データの整合性を野球にたとえると (Doug Terry によるビデオ)
- レプリケート データの整合性を野球にたとえると (Doug Terry によるホワイトペーパー)
- 整合性の低いレプリケート データのためのセッション保証
- 先進的な分散データベース システム設計における整合性のトレードオフ:CAP 以外の考慮事項について
- 「Probabilistic Bounded Staleness (PBS) for Practical Partial Quorums (現実的なパーシャル クォーラムのための Probabilistic Bounded Staleness (PBS))」
- 「Eventually Consistent - Revisited (最終的な整合性 - 改訂版)」