# 結果整合性 ## 定義 結果整合性（eventual consistency）は、分散データストアにおいて、すべての更新が最終的にすべてのレプリカに到達することを保証する整合性モデルである。強い整合性（strong consistency）とは異なり、ある時点での読み取りが最新の書き込みを反映していない可能性を許容する代わりに、高い可用性を実現する。[[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]] において、[[Dynamo]] の中核設計哲学として位置づけられた。ネットワーク障害の可能性がある環境では、強い整合性と高い可用性を同時に達成できないという原理（CAP 定理として知られる）に基づき、Dynamo は可用性を優先して整合性を緩和する選択をした。 更新の伝播は非同期に行われ、並行更新やネットワーク分断により同一オブジェクトの複数バージョンが共存する場合がある。Dynamo ではベクタクロック（vector clocks）によってバージョン間の因果関係を追跡し、因果的に先行するバージョンは自動的に破棄する（構文的調整）。因果関係のない並行分岐はクライアントに返却し、アプリケーション固有のロジック（意味的調整）で解決させる。ショッピングカートの例では、分岐バージョンの「マージ」により「カートへの追加」操作が決して失われないことを保証する。 ## 横断的知見 - **Session Consistency はクライアント間でトークンを共有しないと Eventual Consistency と同等になる**: Azure CosmosDB の Session Consistency はドキュメントで推奨される設定だが、「セッショントークンを共有するクライアント間でのみ同期」という制約がある。Work Dispatcher が書き込んだ直後に別クライアント（Worker）がトークンなしで読み取ると「キーが見つからない」エラーが発生した。この挙動がパフォーマンス最適化による「too fast」な処理で初めて顕在化し、28 日間のインシデントとなった。「ドキュメント推奨の設定を正しく理解しないと、Eventual Consistency と変わらない動作を招く」という実例（Source: [[@2023__SREcon23Americas__Turning an Incident Report into a Design Issue with TLA+]]）。 - **キャッシュ層における「ベストエフォート結果整合性」**: Facebook memcache は古いデータを読む確率を「調整可能なパラメータ」として明示的に位置付け、完全整合性よりも性能・可用性を最優先にする。Dynamo/Cassandra が永続ストアの整合性を論じるのに対し、memcache はキャッシュ層(非永続)の整合性のため、データ損失は許容しつつキャッシュ無効化の遅延のみを課題とする。リージョン内では mcsqueal(DB コミットログ駆動)で 1 秒以内に 4 ナインの無効化信頼性を達成。リージョン間ではレプリケーション遅延に起因する stale read を remote marker で緩和する。(Source: [[@2013__NSDI__Scaling Memcache at Facebook]]) - Dynamo と Cassandra はともに結果整合性を採用するが、衝突解決の機構が根本的に異なる。Dynamo はベクタクロックにより因果関係を追跡し、クライアント側での意味的調整を可能にする。一方 Cassandra はベクタクロックを排除し、タイムスタンプ（last-write-wins）で衝突を解決する。Dynamo の方式は「書き込み前に読み取りが必要」という制約を生み、高書き込みスループット環境では制約となった。Cassandra はこの制約を取り除くことで Inbox Search（1 日数十億書き込み）の要件を満たしたが、同時書き込み時の意味論がタイムスタンプ精度に依存するトレードオフを受け入れている（Source: [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]、[[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]）。 - 両システムはクォーラムベースの読み書きを採用するが、クォーラムの粒度が異なる。Dynamo は R + W > N を推奨して整合性を調整可能にしている。Cassandra も同様のクォーラム方式を採用するが、加えてデータセンタ対応レプリケーションポリシー（ラック対応、データセンタ対応）を提供し、地理分散環境での整合性と可用性のトレードオフをより細かく制御できる（Source: [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]、[[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]）。 - **結果整合性はNoSQL固有の概念ではなく、非同期レプリケーションされたリレーショナルデータベースのフォロワーにも等しく当てはまる**: DDIA([[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]])は、eventual consistencyという用語がDouglas Terryに由来しWerner Vogelsが広めNoSQLムーブメントの合言葉になった経緯を確認しつつ、「NoSQLデータベースだけが結果整合性を持つのではなく、非同期にレプリケーションされたリレーショナルデータベースのフォロワーも同じ特性を持つ」と明言する。これはDynamo/Cassandraのようなリーダーレスシステムを起点に本ページが蓄積してきた知見が、実は[[単一リーダーレプリケーション]]の非同期フォロワーにも適用範囲を持つことを示しており、結果整合性を「NoSQL特有の設計選択」ではなく「非同期レプリケーション一般が持つ性質」として再定義する必要がある。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Problems with Replication Lag") - **結果整合性と強整合性の間に、読み取り側の異常を個別に禁止する中間的な保証群(read-after-write / monotonic reads / consistent prefix reads)を置くことで「結果整合性を受け入れつつ特定の異常だけを排除する」設計余地が生まれる**: Dynamo/Cassandraの文脈では結果整合性は「ベクタクロックまたはLWWで解決する」という単一の対処法として語られてきたが、DDIAはこれを更に分解し、[[レプリケーションラグと読み取り整合性]]で詳述する3つの独立した保証(ユーザー自身の書き込みは必ず見える・時間が巻き戻らない・因果的順序が保たれる)を定義する。これらは強整合性(線形化可能性)より弱いがDynamo流の無条件の結果整合性より強く、アプリケーションごとに必要な保証だけを選択的に実装する設計指針を与える。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Problems with Replication Lag") - **自動衝突解決によって全レプリカが同一状態へ収束することを保証する性質は「強い結果整合性(strong eventual consistency)」と呼ばれ、Dynamo/Cassandraの(単なる)結果整合性より強い概念として区別される**: DynamoはベクタクロックとR+W>Nクォーラムで結果整合性を実現するが、収束アルゴリズム(CRDT等)を伴わない限り、siblingsの解決順序次第で最終状態が変わりうる。DDIA([[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Automatic conflict resolution")は、CRDT/OTのように「同じ書き込み集合を処理した全レプリカが到着順序に関わらず同一状態に収束する」性質を明示的に「強い結果整合性」と命名しており、[[マルチリーダーレプリケーション]]・[[リーダーレスレプリケーション]]双方に共通する上位の整合性目標として位置づけられる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Automatic conflict resolution") - **詳説 データベース11章のN/W/R表記は、本ページがDynamo/Cassandraの文脈で個別に蓄積してきたR+W>Nクォーラムを、レプリケーション方式に依存しない一般形として再提示する**: 本ページはこれまでDynamoの「R + W > N を推奨」・Cassandraの「同様のクォーラム方式」という個別記述としてR+W>Nを扱ってきたが、詳説 データベース11章はこれをレプリケーションファクタN・書き込み一貫性W・読み込み一貫性Rという明示的な3変数のフレームワークとして定式化し、W=1,R=N(書き込み偏重)やW=N,R=1のような非対称構成の一般原理までを示す。これは[[クォーラムベースレプリケーション]]ページが既に蓄積しているAuroraのV/Vw/Vr表記と同型であり、結果整合性システムの調整可能な一貫性が、Dynamo系リーダーレスレプリケーションに限らずクォーラムベース設計一般に共通する数理であることを裏付ける。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 11 レプリケーションと一貫性]] §11.8, [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]) - **結果整合性の「最終的に(eventually)」という時間制限の欠如は、CAP定理のベストエフォート可用性と同じ構造を持つ**: 詳説 データベース11章は結果整合性を「データ項目に対する追加の更新がない場合、最終的には最新の書き込み値がすべてのアクセスに返される」と定義し、この「最終的に」が処理の厳しい時間制限を指定しない点を強調する。これは[[CAP定理]]ページが扱う「正常時には保証を侵害しないが、ネットワーク分断発生時には保証を弱めたり違反したりすることが許容される」というベストエフォートAPシステムの定義と同じ設計思想であり、結果整合性はAPシステムが可用性を優先して選び取る一貫性側の緩和を、時間軸の言葉で言い換えたものと位置づけられる。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 11 レプリケーションと一貫性]] §11.7, §11.2) - **結果整合性は収束を「約束」するだけであり、その収束を実際に駆動する機構(アンチエントロピー)を別途持たなければ絵に描いた餅にとどまる**: 詳説 データベース11章 §11.7 が定義する結果整合性は「最終的には最新の書き込み値がすべてのアクセスに返される」という到達点の宣言にすぎず、その到達をいつ・どうやって達成するかには触れない。詳説 データベース12章([[@2021__OReillyJapan__詳説 データベース - Chapter 12 アンチエントロピーと情報散布]])はこの空白を埋める機構として[[アンチエントロピー]]を導入し、「アンチエントロピーは、結果整合性システムにおいて、収束にかかる時間の制限を短くするために使用される」と明言する。読み取り修復・ヒンテッドハンドオフ・Merkleツリー・ビットマップバージョンベクトル・ゴシップはいずれも、結果整合性という整合性モデルの「宣言」を実際の「収束」に変換する具体的な実装であり、11章の定義だけを読むと結果整合性はいつ収束するか分からない静的な性質に見えるが、12章と合わせて読むことで初めて、収束時間を左右する運用可能な設計変数(どのアンチエントロピー機構を選ぶか)が見えてくる(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 11 レプリケーションと一貫性]] §11.7, [[@2021__OReillyJapan__詳説 データベース - Chapter 12 アンチエントロピーと情報散布]] p.251)。 - **結果整合性は分散データベース固有の概念ではなく、キャッシュコヒーレンスの一戦略としても独立に定義される**: 本ページはこれまで Dynamo/Cassandra/memcache という「永続または半永続なデータストア」の文脈でのみ結果整合性を扱ってきたが、[[@2009__MITOCW__Principles of Computer System Design - Chapter 10 Consistency]] は結果整合性を分散データベースの用語としてではなく、「厳密一貫性(strict consistency)」と対をなす一般的なキャッシュ一貫性モデルの1つとして導入する。同書が挙げる例は DNS のキャッシュであり、TTL(time-to-live、秒〜月のオーダー)が切れるまで古いレコードが返りうるという「タイマー期限による結果整合性」という単純な機構だけで、ベクタクロックや LWW のような衝突解決アルゴリズムなしに結果整合性を実現している。DNS では通知対象のキャッシュが「インターネット中に無数にあり、全てへの変更通知が非現実的」であることが結果整合性を選ぶ理由として挙げられており、これは Dynamo が可用性優先のために意図的に選択した設計判断とは異なる、「規模が大きすぎて強い整合性の通知コストを払えない」という別種の動機である。(Source: [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]], [[@2009__MITOCW__Principles of Computer System Design - Chapter 10 Consistency]] §10.1, §10.2.2) ## 未解決の問い - CosmosDB の Session Consistency は「ドキュメント推奨だが扱いが難しい」とされる（[[@2023__SREcon23Americas__Turning an Incident Report into a Design Issue with TLA+]] p.12）。クライアント間でセッショントークンを明示的に引き渡すパターンは SDK レベルでどの程度サポートされているか。また、実際のクラウドアプリケーションでこのパターンを誤用しているケースの頻度はどの程度か。 - Dynamo の本番データでは 99.94% のリクエストが単一バージョンのみを返しており、実際の不整合発生は極めて稀である。しかし残り 0.06% のケースにおける意味的調整のコスト（開発者負担・データ品質への影響）は定量化されているか。 - ベクタクロックの切り捨て（閾値超過時に最古エントリを除去）が調整の正確性に与える影響は「本番で問題にならなかった」と報告されるが、ワークロード特性が変化した場合にも成立するか。理論的な安全性の保証はあるか。 - Dynamo は「常に書き込み可能」を優先したが、金融取引や在庫管理など厳密な整合性が必要な領域では、結果整合性と強い整合性のハイブリッドアプローチ（例: Spanner の外部整合性）がどのように使い分けられているか。 - [[James Hamilton]] の[[インターネットスケールサービス設計]]における「障害前提設計」原則と、Dynamo の結果整合性設計は、ステートフルサービスにおける可用性と整合性のトレードオフをどのように分担しているか。 - Cassandra がベクタクロックを排除しタイムスタンプ（last-write-wins）に切り替えた判断は、書き込みスループットと衝突解決の正確性のトレードオフである。NTP のクロック同期精度がミリ秒オーダーの環境で、同一キーへの近接書き込みがどの程度のデータ損失リスクを生むか、本番ワークロードでの定量評価はあるか。 - DDIAが定義するread-after-write / monotonic reads / consistent prefix readsの3保証は、DynamoやCassandraのようなDynamo-styleシステムでは実際にどこまで実装・提供されているか。両システムのドキュメントは本ページの既存出典からは明確でなく、[[レプリケーションラグと読み取り整合性]]との突き合わせが必要。 - 「強い結果整合性(strong eventual consistency)」はCRDTのような収束保証つきアルゴリズムを要求するが、DynamoのベクタクロックやCassandraのLWWは収束を「アプリケーション側の意味的調整」に委ねており、この意味で両者は「弱い」結果整合性にとどまる可能性がある。DDIAの区別に照らして、既存の Dynamo/Cassandra 実装がstrong eventual consistencyを満たさない具体的なシナリオは何か。 ## 関連 - ソース: [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]（Dynamo の設計哲学と本番検証）/ [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]（Dynamo 型結果整合性の継承とタイムスタンプベース衝突解決への変更）/ [[@2013__NSDI__Scaling Memcache at Facebook]]（キャッシュ層でのベストエフォート結果整合性・remote marker・mcsqueal）/ [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]]（NoSQLに限らない結果整合性の一般化・read-after-write等3保証・強い結果整合性）/ [[@2021__OReillyJapan__詳説 データベース - Chapter 11 レプリケーションと一貫性]]（結果整合性の形式的定義・N/W/Rによる調整可能な一貫性の一般形）/ [[@2021__OReillyJapan__詳説 データベース - Chapter 12 アンチエントロピーと情報散布]]（収束を実際に駆動するアンチエントロピー機構）/ [[@2009__MITOCW__Principles of Computer System Design - Chapter 10 Consistency]]（DNS の TTL によるキャッシュコヒーレンスとしての結果整合性） - 概念: [[一貫性ハッシュ法]]（Dynamo のパーティショニング基盤）/ [[インターネットスケールサービス設計]]（障害前提設計の上位原則）/ [[ゴシッププロトコル]] / [[LSMツリー]] / [[分散キャッシュ]] / [[単一リーダーレプリケーション]]（非同期フォロワーが結果整合性を持つ根拠）/ [[レプリケーションラグと読み取り整合性]]（3つの中間的な読み取り保証の詳細）/ [[マルチリーダーレプリケーション]]（強い結果整合性を要求するCRDT/OTの応用先）/ [[CAP定理]]（結果整合性が選び取るベストエフォート可用性の理論的根拠）/ [[CRDT]]（強力な結果整合性を実現する具体的データ構造）/ [[アンチエントロピー]]（結果整合性の収束を実際に駆動する運用機構） - エンティティ: [[Dynamo]] / [[Amazon]] / [[Werner Vogels]] / [[Apache Cassandra]] / [[Facebook]] - 関連 MOC: [[分散システム - MOC]]（存在する場合） ## 出典 - [[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store]]（結果整合性の定義、ベクタクロックによるバージョン管理、本番での分岐率データ） - [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]（ベクタクロック排除、タイムスタンプ方式、クォーラム読み書き、データセンタ対応レプリケーション） - [[@2013__NSDI__Scaling Memcache at Facebook]]（キャッシュ層のベストエフォート結果整合性・mcsqueal 無効化・remote marker・30 日間の削除パイプライン信頼性計測） - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]]（結果整合性の用語史・NoSQLに限らない一般化・read-after-write / monotonic reads / consistent prefix reads・強い結果整合性の定義） - [[@2021__OReillyJapan__詳説 データベース - Chapter 11 レプリケーションと一貫性]] §11.7 結果整合性, §11.8 調整可能な一貫性（N/W/Rによる一般形、CAPのベストエフォート可用性との対応） - [[@2021__OReillyJapan__詳説 データベース - Chapter 12 アンチエントロピーと情報散布]](p.251: アンチエントロピーが結果整合性の収束時間を短くする機構であることの明示) - [[@2009__MITOCW__Principles of Computer System Design - Chapter 10 Consistency]] §10.1, §10.2.2(結果整合性を分散データベース文脈でなくキャッシュ一貫性モデルとして定義、DNS TTL の例)