第5章：整合性ってなんだ──“なんとなく使ってた言葉”に向き合う回
第5章：整合性ってなんだ──“なんとなく使ってた言葉”に向き合う回
『データ指向アプリケーションデザイン（DDIA）』第5章を読んだメモです
「整合性？なんとなく分かってるつもりだったけど…」という感覚に刺さる章
あいまいな言葉に潜むトレードオフと、“割り切り”の設計観点を自分なりに整理しました
「結果整合性」は便利な言葉だけど、曖昧すぎる
まず最初にぶち当たるのがこのワード
結果整合なのでOK、って言うけど「いつ整合するか」ってちゃんと考えてる？
100年後に整合したらOKなのか？という極端な思考実験が本質を突いてくる
「結果整合性」は設計側がサボるための言い訳ではなく、
時間軸と業務要件に即した仕様を明文化するためのキーワードだという認識が必要
図5: 整合性モデルの階層（Strong → Eventual）
読み取り用レプリカ、入れたら勝ちかと思いきや
検索が重いからレプリカを追加したい──これはありがち
でも実際やろうとすると、
- 検索結果を使って更新系の処理が走る
- レプリカにラグがあると、古いデータを基に更新が実行される
- 破綻！
読み取り専用にするだけで済む話じゃなくて、使われ方そのものの見直しが必要になる
「検索にしか使わない」という制約を守れる構造設計がないと破綻しやすい
準同期型レプリケーション、どこで使う？
準同期ってふんわりした言葉だけど、これはたぶん：
- 厳密な同期（全ノード書き込み完了を待つ）だと遅すぎる
- でも完全に非同期だと整合性崩壊
これは「完全同期は遅すぎる」「非同期は信用ならない」という中間案
たとえば金融系など「データの重要度が高いが可用性も必要」な領域では、
準同期型は妥協案として実用ラインに乗りうるかな
チェーンレプリケーション＝書き込みは1箇所、読み取りは別
これは構造を見れば納得しやすい：
- 書き込みはプライマリに集中
- セカンダリは読み取り専用
- 書き込み後にのみ読み取り可 → 整合性保証
ただし、リーダーが1つという構造がスケールの壁になるので、
次のフェーズではまた別の整合性戦略が必要になってくる
WALは正義だけど、環境依存が強い
Write-Ahead Log（WAL）を使えば書き込み操作を漏らさず記録できるけど、これはあくまでバイト列
つまり：
- 高速で信頼性がある
- でもスキーマレスで読みづらい
- 運用のクセが出やすい
ツールが整ってるならOKだけど、運用まで含めた設計ができないとしんどい
論理ログレプリケーション、悪いとこ書いてなくても怪しい
本にはメリットばかり書いてあるが、正直：
- WALと比べてパフォーマンスどうなの？パフォーマンス劣化の可能性は？
- 巨大テーブル＆PKなしテーブルでは地獄じゃない？
って疑問は拭えない。
実際、データ移行ツールで「主キーないから無理」って怒られたことあるし、パフォーマンスには相当左右される構成
**「使ってみないとわからない系」**の代表格
遅延 vs 障害耐性のジレンマ
レプリカを遠隔拠点に置くことで障害には強くなるけど、ネットワーク遅延は避けられない
光速が遅いから仕方ない（？）という雑すぎる真理に突き当たる
- レプリカを遠隔に置くと耐障害性は上がる
- でもネットワーク遅延は不可避
- かといって片方だけだと災害リスクが怖い
→ **整合性と可用性、両方を同時に取るのはできない（CAP定理）**という現実を突きつけられる
モノトニック、プレフィックス…知らん用語が増えてきた
ここから「モノトニック読み取り」「プレフィックス読み取り」といった
実装レベルの整合性制約が出てくる
でも本質はこう：
設計上の“期待値”をどう実装・保証するかという話
言葉に振り回されず、「これは誰に、いつ、どこまで保証すべきことか？」を考える
マルチリーダーの誘惑、でも整合性はお察し
「リーダーが1台しかないのが嫌」というのは誰しも思うけど、
マルチリーダー構成はその分同期が地獄になる
- リーダー分散でスケーラブルにしたい
- でも同期はめちゃくちゃ大変
- 最終的には「後勝ちルール」や「手動マージ」頼り
ローカルでも編集できるアプリ（カレンダーやメモアプリ）は、衝突を許容する代わりに整合性を後で頑張る方針
この辺、Notion や Miro とかがやってる「後勝ち実装」の世界
それを許容できるユースケースじゃないと成立しない
リーダーレス＆クオーラム読み取りの世界
「クオーラム」と聞いて思考停止しそうになるけど、要は：
- 書き込み：n台中w台でOK
- 読み取り：r台でOK
- w + r > n なら、最低1台は重なる
というロジック
数字をどう設定するかで、整合性と可用性のバランスが取れる
ただし、これをアプリ側がちゃんと理解して使えるかは別問題
並列書き込みの地獄と、ゆるい解決策
複数ノードで同時書き込みが起きたら、タイムスタンプが新しい方を採用する
という力技が Cassandra で採用されていて、笑いつつも納得する
- 完璧な同期は無理
- じゃあ「いちばん最近のやつが勝ち」ルールにしよう
っていう潔さ
でも、競合が多いユースケースでは破綻しがち
✍️ まとめ：整合性は“時間”と“割り切り”でできている
この章でいちばん感じたのは、整合性とは：
- “いつまでに”揃えばいいのか（時間）
- “どこまで”許せるのか（割り切り）
という、リアルな選択の集合体だということ
そして、整合性の正体は「整合しているように見せる」技術の集合でもある
裏でズレても、ユーザーが気づかなければ整合してる
つまり整合性って、ユーザー体験と設計者の執念の境界線なのかもしれない
💡 設計Tips
- 結果整合性は仕様である：「何秒後に整合すればOKか」を言語化せよ
- 読み取りレプリカは使い方が命：更新と混ぜない／用途を限定する設計に
- 整合性の“許容範囲”は定義しておく：ユーザー視点で違和感のない幅を明確化
- クオーラム設計は数値設計より、アプリとの整合が難所：構成と運用をセットで設計すべし
- 「同期できる」は幻想：整合性を保証するより、“壊れない見せ方”を設計することの方が重要
Discussion