Azure Cosmos DB の整合性レベル

高可用性、低待機時間、またはその両方のためにレプリケーションに依存する分散データベースでは、 PACELC 定理で定義されている読み取り整合性、可用性、待機時間、スループットのバランスを取る必要があります。 強力な整合性モデルの線形化可能性は、データ プログラミングの標準です。 ただし、データは大規模な距離にわたってレプリケートおよびコミットする必要があるため、書き込みの待機時間が長くなります。 また、すべてのリージョンでデータをレプリケートおよびコミットできないため、強力な整合性により、障害発生時の可用性も低下します。 最終的な整合性により可用性が向上し、パフォーマンスが向上しますが、すべてのリージョンでデータが一貫性を持たない可能性があるため、アプリケーションをプログラミングすることはより困難です。

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

• 厳密
• 有界整合性制約
• Session
• 一貫性のあるプレフィックス
• 最終的

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

各レベルは、可用性とパフォーマンスのバランスを取ります。 次の図は、一貫性レベルをスペクトルとして示しています。

整合性レベルと Azure Cosmos DB API

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

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

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

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

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

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

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

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

"強固" 整合性

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

次の図は、音楽ノートとの厳密な一貫性を示しています。 データが "米国西部 2" リージョンに書き込まれると、他のリージョンからデータを読み取るとき、最新の値が取得されます。

動的クォーラム

通常の状況では、強力な整合性を持つアカウントでは、すべてのリージョンがレコードのレプリケーションを確認すると、書き込みがコミットされたと見なされます。 アカウントに 3 つ以上のリージョンがある場合、システムは、一部のリージョンが遅いか応答していない場合に、クォーラムに必要なリージョンの数を減らすことができます。 これは、いくつかのリージョンに問題がある場合でも、強力な一貫性を維持するのに役立ちます。 その時点で、強力な整合性を維持するため、応答しないリージョンはリージョンのクォーラム セットから取り除かれます。 これらは、他のリージョンと一貫性を持ち、期待どおりに動作する場合にのみ追加されます。 クォーラム セットから取り出すことができる可能性のあるリージョンの数は、リージョンの合計数によって異なります。 たとえば、3 つまたは 4 つのリージョン アカウントでは、マジョリティはそれぞれ 2 つまたは 3 つのリージョンであるため、どちらの場合も削除できるリージョンは 1 つだけです。 5 つのリージョン アカウントの場合、大部分は 3 つであるため、最大 2 つの応答しないリージョンを削除できます。 この機能は "動的クォーラム" と呼ばれ、3 つ以上のリージョンを持つアカウントの書き込みの可用性とレプリケーションの待機時間の両方を向上させることができます。

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

複数のリージョンを持つ単一リージョン書き込みアカウントの場合、データはそのプライマリ リージョンからすべてのセカンダリ (読み取り専用) リージョンにレプリケートされます。 複数のリージョンを持つマルチリージョン書き込みアカウントの場合、データは最初に書き込まれたリージョンから他のすべての書き込み可能なリージョンにレプリケートされます。 どちらのシナリオでも、一般的ではありませんが、リージョン間でレプリケーションの遅延が発生することがあります。

有界整合性制約の整合性では、任意の 2 つのリージョン間のデータのラグは、常に指定された量より小さくなります。 この量は、項目の "K" 個のバージョン (更新)、 または "T" 回の時間間隔のいずれか最初に達した方になります。 つまり、有界整合性制約を選んだ場合、任意のリージョンにおけるデータの最大 "整合性制約" は 2 つの方法で構成できます。

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

有界整合性制約は、主に 2 つ以上のリージョンを持つ単一リージョンの書き込みアカウントに役立ちます。 リージョン内のデータの遅延 (物理パーティションごとに決定されます) が構成済みの整合性制約値を超えた場合、整合性制約が構成済みの上限以内に戻るまで、そのパーティションへの書き込みは調整されます。

単一リージョン アカウントの場合、有界整合性制約は、セッションおよび最終的な整合性と同じ書き込み整合性の保証を提供します。 有界整合性制約を使用すると、データは単一リージョン内のローカル マジョリティ (4 つのレプリカ セット内の 3 つのレプリカ) にレプリケートされます。

有界整合性制約を使う読み取りの場合、そのリージョンで使用できる 2 つのレプリカから読み取ることで、そのリージョンで使用できる最新のデータが返されます。 1 リージョン内の書き込みは常にローカル マジョリティ (4 つのレプリカのうち 3 つ) にレプリケートされるので、2 つのレプリカを参照することで、そのリージョンで使用できる最新のデータが返されます。

有界整合性制約は、グローバルに分散したアプリケーションで、複数のリージョンを持つ単一リージョン書き込みアカウントを使っている場合に最適です。 複数のリージョンを持つマルチリージョン書き込みアカウントの場合、アプリケーション サーバーが、アプリケーション サーバーがホストされているのと同じリージョンに読み取りと書き込みを送信する必要があります。 複数書き込みアカウントの有界整合性制約は、アンチパターンです。 このレベルでは、リージョン間のレプリケーション ラグへの依存が必要になりますが、データが書き込まれたのと同じリージョンからデータが読み取られる場合は問題になりません。

次のグラフィックでは、音符の有界整合性制約整合性を図解しています。 データが "米国西部 2" リージョンに書き込まれた後、"米国東部 2" リージョンと "オーストラリア東部" リージョンでは、構成された最大遅延時間または最大操作に基づき、書き込まれた値を読み取ります。

"セッション" 整合性

セッション整合性での単一のクライアント セッション内の読み取りでは、自己書き込みの読み取り、読み取り後の書き込みの優先が保証されます。 この保証では、1 つの "ライター" セッションを想定するか、複数のライターのセッション トークンを共有します。

強力な一貫性よりも弱いすべての整合性レベルと同様に、書き込みはローカル リージョン内の少なくとも 3 つのレプリカ (4 つのレプリカ セット内) にレプリケートされ、他のすべてのリージョンに非同期レプリケーションが行われます。

書き込み操作のたびに、クライアントではサーバーから更新されたセッション トークンを受け取ります。 クライアントはトークンをキャッシュし、指定したリージョンでの読み取り操作のためにそれらをサーバーに送信します。 読み取り操作が発行されるレプリカに、指定されたトークン (またはより新しいトークン) のデータが含まれている場合は、要求されたデータが返されます。 レプリカにそのセッションのデータが含まれていない場合、クライアントではリージョン内の別のレプリカに対してその要求を再試行します。 必要に応じて、クライアントでは、指定されたセッション トークンのデータが取得されるまで、追加の使用可能なリージョンに対して読み取りを再試行します。

Azure Cosmos DB のセッション トークンはパーティション バインドです。つまり、1 つのパーティションにのみ関連付けられます。 書き込みを読み取れるようにするには、関連する項目に対して最後に生成されたセッション トークンを使用します。

クライアントで物理パーティションへの書き込みが開始されなかった場合、クライアントではキャッシュにセッション トークンが含められず、その物理パーティションへの読み取りは最終的な整合性で読み取りとして動作します。 同様に、クライアントが再作成されると、セッション トークンのキャッシュも再作成されます。 この場合も、読み取り操作は、後続の書き込み操作でクライアントのセッション トークンのキャッシュが再作成されるまで、最終的な一貫性と同じ動作になります。

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

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

強力な一貫性よりも弱いすべての整合性レベルと同様に、書き込みはローカル リージョン内の少なくとも 3 つのレプリカ (4 つのレプリカ セット内) にレプリケートされ、他のすべてのリージョンに非同期レプリケーションが行われます。

一貫性のあるプレフィックスでは、単一ドキュメントの書き込みとして行われる更新の場合、最終的な整合性が表示されます。

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

トランザクション T1 と T2 内で、ドキュメント Doc1 に対して 2 つの書き込み操作がトランザクションで実行され (すべて行われるか、何も行われない操作)、その後、ドキュメント Doc2 に対して実行されるとします。 クライアントが任意のレプリカで読み取りを行う場合、ユーザーには "Doc1 v1 と Doc2 v1" または "Doc1 v2 and Doc2 v2" のいずれかが表示されます。レプリカが遅れている場合はどちらのドキュメントも表示されませんが、同じ読み取りまたはクエリ操作に対して "Doc1 v1 と Doc2 v2" または "Doc1 v2 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 ネットワークでは、Azure リージョン間の RTT の待機時間サービス レベル アグリーメント (SLA) は提供されませんが、 Azure ネットワークラウンドトリップ待機時間の統計情報が発行されます。 Azure Cosmos DB アカウントの場合、レプリケーションの待機時間は Azure portal に表示されます。 Azure portal を使用するには、[メトリック] セクションに移動し、[ 整合性 ] オプションを選択します。 Azure portal を使用すると、ご自分の Azure Cosmos DB アカウントに関連付けられているさまざまなリージョン間のレプリケーションの待機時間を監視できます。

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

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

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

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

グローバル分散データベース環境では、整合性レベルは、リージョン全体の停止中のデータの持続性に直接影響します。 ビジネス継続性計画を策定するときは、中断を伴うイベントからの復旧中にアプリケーションが損失を許容できる最新のデータ更新の最大期間を理解します。 失われる可能性のある更新の期間は、 目標復旧ポイント (RPO) と呼ばれます。

次の表は、リージョン全体の停止中の整合性モデルとデータの持続性の関係を示しています。

K = アイテムの K バージョン (更新) の数。

T = 前回の更新以降の時間間隔 T 。

単一リージョン アカウントの場合、 K と T の最小値は 10 回の書き込み操作または 5 秒です。 複数リージョン アカウントの場合、 K と T の最小値は 100,000 書き込み操作または 300 秒です。 この値は、有界整合性制約を使用する場合のデータの目標復旧ポイント (RPO) の最小値を定義します。

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

複数の書き込みリージョンを持つ Azure Cosmos DB アカウントでは、分散システムで目標復旧ポイント (RPO) を 0 に、目標復旧時間 (RTO) をゼロにできないため、強力な整合性を使用できません。 さらに、複数の書き込みリージョンとの強力な整合性では、書き込みをレプリケートしてアカウント内のすべてのリージョンにコミットする必要があるため、書き込みの待機時間は向上しません。 このセットアップにより、単一書き込みリージョン アカウントと同じ書き込み待機時間が発生します。

関連項目

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

• Azure Cosmos DB によって提供される 5 つの整合性レベルの高レベル TLA⁺ 仕様
• Doug Terry による野球 (ビデオ) を通じて説明されたレプリケートされたデータの整合性
• Doug Terry による野球 (ホワイトペーパー) を通じて説明されたレプリケートされたデータの整合性
• 整合性の低いレプリケート データのためのセッション保証
• 最新の分散データベース システム設計における整合性のトレードオフ: CAP はストーリーの一部にすぎません
• 実用的な部分クォーラムの確率論的有界整合性制約 (PBS)
• 最終的に一貫性 - 再検討

関連するコンテンツ

• 既定の一貫性レベルを構成する
• 既定の整合性レベルをオーバーライドする
• Azure Cosmos DB の SLA の詳細を確認します。