整合性モデルの階層（線形化可能性〜結果整合性）

整合性モデルとは何か

整合性モデル（consistency model） は、レプリケーションされたデータに対する 読み書き操作が、どの順序で見えてよいか／見えてはならないか を定めた契約です。単一ノードなら操作は1本の時系列に並びますが、データを複数ノードに複製した瞬間、「ある書き込みを、別のクライアントがいつ・どの順で観測できるか」が自明でなくなります。整合性モデルは、その 観測されうる履歴（history）の集合 を規定します。

重要なのは、これが 正しさの定義そのもの だという点です。実装が速いか遅いかではなく、「この実行は仕様に違反したか」を判定する基準になります。モデルが強いほど許される履歴は少なく、プログラマにとって直感的になりますが、その制約を守るための 同期・合意のコスト が可用性とレイテンシに跳ね返ります。

強さの階層

代表的なモデルを 強い順 に並べると次のようになります。上位は下位を含意します（線形化可能なら逐次的でもある）。

線形化可能性（Linearizability）

最強の単一オブジェクト整合性です。すべての操作が、それぞれの呼び出しと応答の間にある「ある一点」で、瞬時に起きたかのように 見えなければなりません。帰結として、ある書き込みが応答を返したら、それ以降に開始する読み取りは、その値か、より新しい値しか返せません。古い値（ステイル read）は違反です。

つまり線形化可能性は 実時間（wall-clock）順序を尊重する全順序 を要求します。これは「最新性（recency）の保証」とも呼ばれ、外から見たシステムはあたかも1台のノードのように振る舞います。compare-and-swap のような合意が必要な操作の土台であり、リーダー選出やロックの正しさはここに依存します。

逐次一貫性（Sequential Consistency）

Lamport の定義による古典的モデル。すべての操作がある単一の全順序に並べられ、かつ 各プロセス内の操作はその発行順を保つ、という2条件を満たせばよい。線形化可能性との決定的な違いは、実時間順を要求しない ことです。

# 2つの全順序。逐次一貫だが線形化可能でない例
クライアントA: write(x=1) 完了
クライアントB: （Aの完了後に開始）read(x) -> 0   # 逐次一貫としては合法
# 全プロセスが一貫して「read が write より前」という1つの順序に同意できれば、
# 実時間ではAが先でも、整合性違反にはならない。

全員が 同じ1つの順序 に同意する点は強い保証ですが、その順序が現実の時刻とずれてよいため、最新性は保証されません。

因果一貫性（Causal Consistency）

因果関係（causality）で結ばれた操作の順序だけ を全プロセスで一致させ、因果のない（並行な）操作の順序は観測者ごとに異なってよい、というモデルです。因果は「ある操作が別の操作を見たうえで起きた」関係で、happens-before で定義されます。

帰結として、原因より先に結果を観測することは禁じられます。「Aが投稿 → Bがそれに返信」という連鎖は、どのノードでも投稿→返信の順にしか見えません。一方、無関係な2つの投稿の前後は、ノードによって入れ替わってよい。因果一貫性は 分断耐性と両立できる最強クラスのモデル（後述）として理論的に重要です。

結果整合性（Eventual Consistency）

最も弱い実用モデル。新たな更新が止まれば、いつかは全レプリカが同じ値に収束する ことだけを保証します。いつ収束するか・途中で何が見えるか には制約がなく、古い値も、書いた直後に消えたように見える挙動も、一時的には許されます。

「最終的に揃う」だけでは衝突した並行更新の決着が付かないため、実装には収束のための規則が要ります。LWW（last-write-wins、最終書き込み優先）、バージョンベクトル、あるいは数学的に必ず収束する CRDT（Conflict-free Replicated Data Type） などです。「読んだ自分の書き込みは見える」「同じ値を読み続ける」といった セッション保証 を足して、弱さの体感を和らげることもよくあります。

なぜ強い整合性は高くつくのか

階層の本質は トレードオフ です。線形化可能性を満たすには、読み書きのたびに「自分が最新を見ている」ことを確かめる必要があり、それは過半数のレプリカとの 同期的なやり取り（quorum や合意） を要求します。これがレイテンシを押し上げ、ネットワーク分断時には応答できなくなる原因になります。

ここで効くのが CAP 定理 です。ネットワーク分断（P）が起きたとき、システムは 整合性（C＝線形化可能性） と 可用性（A＝全ノードが応答を返す） の両方は満たせず、どちらかを諦めるしかありません。さらに PACELC はこれを平常時に拡張します。「分断時（P）は A と C のどちらか、そうでない時（E、Else）も レイテンシ（L）と整合性（C） のどちらか」を選ぶ、という構図です。

理論的な要となるのが CAP 定理の精密化 です。「分断耐性のもとで到達可能な最も強い整合性は 因果一貫性」が知られており、線形化可能性は分断時に可用性と両立できませんが、因果一貫性は両立できます。だから AP 寄りのシステムが「弱すぎる結果整合性」と「強すぎる線形化可能性」の間を狙うとき、因果一貫性が現実的な上限になります。

どう使い分けるか

正解は1つではなく、境界ごとに必要十分なモデルを当てる ことです。リーダー選出・分散ロック・ユニーク制約のように「ずれたら壊れる」核には線形化可能性を、ソーシャルのタイムラインやコメント連鎖には因果一貫性を、閲覧数カウンタやカートのような「多少ずれても回復できる」ものには結果整合性を、という具合に強さを段階的に下げます。

この設計判断は分散システム全般の土台になります。マイクロサービスでは各サービスが自分のデータを持つため、サービス間更新を1つの強整合トランザクションにできず、結果整合性や Saga が前提になります。SLO による信頼性設計では、強整合を選ぶほど可用性予算（エラーバジェット）を圧迫する関係を見積もる必要があり、カオスエンジニアリングでは分断注入によって「自分が選んだはずの整合性が本当にその通りか」を検証します。

まとめ

• 整合性モデルは 観測されうる履歴の集合 を定める契約であり、実装の速さではなく 正しさの定義 そのもの。
• 強い順に 線形化可能性 ＞ 逐次一貫性 ＞ 因果一貫性 ＞ 結果整合性。下位ほど並べ替えと古い値が許される。
• 違いの核は 実時間順を守るか（線形化可能性）／単一全順序に同意するか（逐次）／因果だけ守るか（因果）／いつか収束だけか（結果）。
• CAP・PACELC により、分断時も平常時も「強整合か、可用性・低遅延か」を選ばされる。分断と両立する最強は 因果一貫性。
• 万能の1モデルはない。境界ごとに必要十分な強さ を当てるのが、正しさとコストの両立点。