# レプリケーションラグと読み取り整合性 ## 定義 レプリケーションラグ(replication lag)とは、[[単一リーダーレプリケーション]]の非同期フォロワーにおいて、リーダーでの書き込みがフォロワーへ反映されるまでの遅延である。通常は1秒未満だが、システムが高負荷であったりネットワーク問題が起きたりすると数秒〜数分に増大しうる。この遅延が実害を生む3種の異常(read-after-write違反・monotonic reads違反・consistent prefix reads違反)への対策として、強い整合性(linearizability等)より弱いが結果整合性より強い、独立した保証群が定義される。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Problems with Replication Lag") ## read-after-write consistency(read-your-writes consistency) ユーザーが自分で投稿したデータを、投稿直後に閲覧しても必ず見えることを保証する。他ユーザーの更新については何も約束しない。実装手段は複数ある。(1) ユーザーが変更しうるデータはリーダー(または同期フォロワー)から読み、それ以外はフォロワーから読む。(2) 最終更新時刻を追跡し、更新後一定時間(例: 1分間)はリーダーから読む、あるいはレプリケーションラグを監視して一定以上遅れたフォロワーへのクエリを止める。(3) クライアントが最終書き込みのタイムスタンプ(論理タイムスタンプまたは実クロック)を記憶し、そのタイムスタンプ以降まで追いついたレプリカのみへルーティングする。マルチデバイス(デスクトップとモバイル等)をまたぐcross-device read-after-write consistencyは、各デバイスが他デバイスの更新を知らないためメタデータの一元化が必要になり、リージョン分散構成では全デバイスのリクエストを同一リージョンへルーティングする必要が生じる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Reading your own writes") ## monotonic reads あるユーザーが連続して複数回読み取りを行う場合、時間が巻き戻ったように見えないことを保証する。同一ユーザーが遅延の異なる複数フォロワーへランダムにルーティングされると、新しいコメントが「見えた後に見えなくなる」といった混乱を招く。最も安価な実装は、ユーザーIDのハッシュなどで各ユーザーを常に同じレプリカへ固定してルーティングすることである(そのレプリカが落ちれば再ルーティングが必要)。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Monotonic reads") ## consistent prefix reads 因果的に関連する一連の書き込みが、読み取り側にも同じ順序で見えることを保証する。DDIAはMr. PoonsとMrs. Cakeの対話をシャード化されたレプリカ経由で観測すると、応答が質問より先に届いてしまう例で説明する。シャーディング(パーティショニング)されたデータベースで特に起きやすく、シャードが独立に動作すると書き込みのグローバルな順序が存在しなくなるためである。対策の一つは因果的に関連する書き込みを必ず同一シャードへ書くことだが、常に効率的にできるとは限らない。因果依存関係を明示的に追跡するアルゴリズムも存在する(happens-before関係、[[リーダーレスレプリケーション]]を参照)。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Consistent prefix reads") ## 解決策の選択 これら3つの保証をアプリケーションコードで個別に実装するのは複雑で誤りやすい。最も単純なプログラミングモデルは、線形化可能性とACIDトランザクションをサポートする強整合データベースを選び、レプリケーションの複雑さを意識しない設計にすることである。2010年代前半のNoSQLムーブメントはこれらの機能がスケーラビリティを制限すると主張したが、その後NewSQL(強整合性・トランザクション機能とスケーラビリティを両立する分散DB群)が登場した。とはいえネットワーク分断への耐性やオーバーヘッドの低さから、依然として弱い整合性保証を持つレプリケーション方式を選ぶ合理性は残る。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Solutions for Replication Lag") ## 横断的知見 - **詳説 データベース11章はDDIAが脚注に留めたTerry 1994の原型「セッションモデル」を本文で直接展開しており、DDIAの3保証との対応関係を具体的に確認できる**: 詳説 データベース11章は因果一貫性の応用として、自身の書き込みの読み取り(read-own-writes)・モノトニックな読み取り・**モノトニックな書き込み**・読み取りに続く書き込み(writes-follow-reads)という4つのセッションモデルを提示し、モノトニックな読み取り・モノトニックな書き込み・自身の書き込みの読み取りを結合するとPRAM一貫性(FIFO一貫性)になるという合成関係まで示す。DDIAのread-after-write consistencyはこの「自身の書き込みの読み取り」と、DDIAのmonotonic readsはそのまま「モノトニックな読み取り」と一致する。一方、詳説 データベースの「モノトニックな書き込み」(同一クライアントの書き込みが発行順に他プロセスへ伝播する)はDDIAの3保証には独立した項目として現れない(単一リーダーレプリケーションのリーダーが暗黙に保証すると想定されている可能性がある)。また詳説 データベースの「writes-follow-reads」(ある読み取りが見た値に依存する書き込みを、その読み取りの後に順序付ける、クライアント単位の保証)と、DDIAの「consistent prefix reads」(因果的に関連する書き込み列が読み取り側にも同じ順序で見える、システム全体・読み取り単位の保証)は名前も焦点も異なり、後者は特定のクライアントの行動に限定されない点でより広い保証である。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 11 レプリケーションと一貫性]] §11.6, [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Problems with Replication Lag") ## 未解決の問い - read-after-write / monotonic reads / consistent prefix readsの3保証を組み合わせて提供するシステムは、それぞれを独立に提供するシステムと比べてどの程度の実装・運用コストの差があるか。 - ~~Douglas Terryの「session guarantees」(1994年、DDIA脚注[^23])は本ページが扱う3保証の理論的源流とされるが、原論文でのセッション保証の定義とDDIAの用語法は完全に一致するか~~ → 詳説 データベース11章がTerry 1994(TERRY94)を直接引用してセッションモデルを4つ提示していることを確認した(横断的知見参照)。ただし詳説 データベースの「モノトニックな書き込み」がDDIAの3保証に対応項目を持たない点、「writes-follow-reads」と「consistent prefix reads」が完全に同一の保証を指すかは、Terryの原論文(1994年)への遡及がなければ確定できない。 - consistent prefix readsの「因果的に関連する書き込みを同一シャードへ書く」対策は、シャーディング設計([[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 7 Sharding]])とどう両立するか。 - 詳説 データベースの「モノトニックな書き込み」はDDIAの3保証のどれにも明示的に対応しないが、単一リーダーレプリケーションでは常に暗黙に満たされる保証なのか、それとも別途実装が必要な独立した保証なのか。 ## 関連 - [[単一リーダーレプリケーション]] — レプリケーションラグが発生する構造的背景 - [[結果整合性]] — レプリケーションラグが引き起こす整合性モデルの上位概念 ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]](3保証の定義・実装手段・consistent prefix readsとシャーディングの関係・NewSQLへの言及) - [[@2021__OReillyJapan__詳説 データベース - Chapter 11 レプリケーションと一貫性]] §11.6 セッションモデル(read-own-writes・モノトニックな読み取り・モノトニックな書き込み・writes-follow-readsの4保証とPRAM一貫性への合成)