📚 『データ指向アプリケーションデザイン』設計判断に効く 6 章だけ抜いた

📖 Martin Kleppmann 著 / オライリー・ジャパン / ¥4,840 — 600 ページの古典から「設計判断に直結する 6 章」だけを要約・図解

📕 『データ指向アプリケーションデザイン』は、分散システムとデータベース設計の「現代の古典」として読まれている。600 ページ、12 章、邦訳の評価も高い。ただ、初学者には厚すぎる。

🎯 本書の真価は 「設計判断のための語彙」を一段深くする ところにある。「データを同期する」が「single-leader か CRDT を選ぶ」になり、「ロックする」が「snapshot isolation で write skew を防ぐ」になる。言葉が変わると、見える地形が変わる。

🪜 ここでは、設計判断にすぐ効く 6 章を抜き出した。各章の終わりには 「自分のシステムだと」 ブロックとして、実際に運用しているサービス(個人ダッシュボード や VJ アプリなど)の問題に概念を紐付けてある。同じように手元の問題と本書の概念を結ぶと、本の効き目が桁違いになる。

一.🏛️ 信頼性・拡張性・保守性 — 三本の柱

🤔 俺は思うんやけど、ソフトウェアってのはあれや、動いてる時より、壊れる時の方が遥かに正直やで。Kleppmann は冒頭でいきなり、システム設計には三つの柱しかないと言い切る。信頼性(Reliability)、拡張性(Scalability)、保守性(Maintainability)。それ以外は枝葉や、と。

🛡️ 信頼性は「故障しても動く」こと、止まらないことやない。違うで。fault と failure を混同するな、と Kleppmann は言う。

fault(故障)は起きる、必ず起きる。問題は fault が failure(全停止)に化けるか化けへんか、そこだけや。🐒 Netflix が自社サービスをわざと殺す Chaos Monkey を作った理由がここにある。fault を毎日起こしておけば、failure に化ける経路が見える。健康な恐怖や。

💡 fault is unavoidable, but failure is preventable.
故障は避けられんが、全停止は防げる。

二.👑 レプリケーション — 独裁・内戦・無政府の三択

🔥 レプリケーションの章でこの本はガチで化ける。データを複製する戦略は single-leader、multi-leader、leaderless の三択。Kleppmann の説明が秀逸なのは、全部に欠陥があると最初に宣言するところや。「最善」はない。「あんたのワークロードに対する最悪が小さい方」を選ぶ、それだけや。

👑 Single Leader は分かりやすい、書き込み窓口が一つ、独裁政権や。シンプル、でもリーダーが死んだ瞬間、失われた書き込みをどう数えるかで地獄が始まる(failover の問題)。

⚔️ Multi Leader は複数の窓口、自由や、でも同じデータを別の窓口で違う値に書いた時、どっちを残す? これは内戦や、調停者がいない(これを conflict resolution、衝突解決と呼ぶ)。

🌐 Leaderless(Cassandra, Dynamo)は窓口を消した、全員が書ける、quorum(定足数)で多数決、これは無政府主義や。「最後の書き込みが勝つ」(Last Write Wins)の罠は、そもそも「最後」を時計でしか測れず、時計は嘘をつく(後述)。

三.🔒 トランザクション — ACID は嘘やないが、I は曖昧

🔤 ACID という有名な略語がある。これが何を保証してるか、ちゃんと言える?

🤔 ACID の中で、Atomicity と Durability はまだ意味が固い。Consistency は アプリ側の責任で DB の話やない、と Kleppmann はバッサリ言う。問題は I、Isolation や。これは複数バージョンの「分かったふり」が共存しとる泥沼や。

🪜 isolation level の梯子: Read Uncommitted → Read Committed → Repeatable Read → Snapshot Isolation → Serializable。下に行くほど安全、でも遅い。

😱 ほとんどの DB のデフォルトが Read Committed か Snapshot Isolation で、Serializable じゃない。これは何を意味するか。「並行で書いても辻褄が合う」と無自覚に信じてるアプリのほぼ全てに、再現性の低いバグが眠っとるということや。

名前だけ覚えても本番で気付けへん。再現させるのが難しい、ログにも出にくい、これが厄介や。

✨ 救いは Serializable Snapshot Isolation(SSI、直列化可能スナップショット隔離)。PostgreSQL がこれを 2011 年に実装した時、業界が静かに進化した。「Serializable は遅い」は古い知識や、SSI なら速い。これだけは覚えておけ。

四.👻 分散システムの嘘 — 時計・ネットワーク・プロセス

🧘 第八章は禅問答のような章や。「あんたが信じてた現実は、全部嘘や」と Kleppmann は淡々と剥がしていく。複数台のサーバーで動かす時、無自覚に信じてる前提がいくつもある。それを 3 つに整理した:

🌐 嘘 ①: ネットワークは信頼できない。パケットは消える、遅れる、複製される、順序が入れ替わる。「タイムアウトしたから死んだ」は推測でしかない、生きてる相手にもう一個のリーダーが立ってたら split-brain(分裂脳、同じ役割が 2 つ並行する状態)が起きる。

⏰ 嘘 ②: 時計はもっと嘘つきや。NTP(時刻同期プロトコル)で同期した時計でも、サーバー間で 数百 ms ズレる。仮想化環境ではプロセスが 数分間停止することがある(GC pause、live migration)。「うちの time-based ID は衝突しません」と言うエンジニアの 9 割は嘘つきや、と Kleppmann は半笑いで指摘する。Last Write Wins が壊れる根本原因がここにある。

⏸️ 嘘 ③: プロセスは止まる。GC(ガベージコレクション、不要メモリ回収)で 1 秒止まる、ページフォルト(メモリ呼び出しの待ち)で 10 秒止まる、その間 lease(リーダー権の有効期限)が expire してたら、自分が死んでることに気付かないリーダーになる。これが split-brain の本体や。

五.🔗 整合性と合意 — 「同じものが見える」をどう保証するか

💎 第九章で、Kleppmann は linearizability(線形化可能性) と causal consistency(因果整合性) という二つの宝石を取り出す。複数台で動かす時、「みんなが同じものを見てる」をどこまで保証するか — その強度の話や。

🔗 linearizability は 「全員が同じ一本の時間軸で同じものを見る」、強い。でもクソ高い。あらゆる読み書きが調整される必要があり、地理的に分散してたら絶望的に遅い。現代のほとんどの分散 DB は linearizable じゃない(Spanner は例外、TrueTime という GPS + 原子時計のチートで実現)。

⏳ causal consistency はもっと弱い、「原因の前に結果は見えない」だけを保証する(例: 投稿の前に返信が見える、みたいなことは起きない)。これで多くのアプリは充分回る。linearizability を諦めて causality だけにするだけで、レイテンシが激減する。これが分かってないと、過剰スペックな DB を選んで金をドブに捨てる。

🤝 合意アルゴリズム(Paxos、Raft)は linearizability を実現する唯一の方法として登場するが、Kleppmann は冷たく言う。「自分で実装するな、ZooKeeper か etcd を使え」。賢者の助言や。

六.🌊 バッチとストリーム — 二つは同じものの別の側面

📜 最終章で Kleppmann は Lambda アーキテクチャ(バッチ + ストリーム並列)を冷ややかに退ける。「二回書くな、二つ作るな」。

📚 代わりに Kappa アーキテクチャ(ストリーム一本で全部やる) を推す。歴史的に MapReduce(Hadoop)が支配したバッチの世界が、Kafka + Flink/Spark Streaming のストリーム世界に飲み込まれていく流れを、彼は 2017 年時点で予言していた。📅 2026 年の現在、その通りになっとる。

🌊 本質は 「データはイベントの流れであり、状態はその副産物に過ぎない」。これは関数型プログラミングの世界観や(state は fold の結果)。event sourcing(イベント履歴で状態を再構成)、CDC(Change Data Capture、DB の変更を流すパターン)、materialized view(計算結果を物理的に保存) は全部この世界観の派生物や。

🎯 まとめ — 何が残るか

🪨 俺がこの本から持ち帰った、たった一つの態度はこれや:

💡 「動いてる」を信用するな。「動かなかった時、何が起きるか」を設計しろ。

🧱 Reliability の章から始まり、replication / transaction / distributed systems の章で「動かない経路」を浴びるほど見せつけられ、consensus(合意)の章で「動かなさを前提に動く方法」を学び、最後にバッチとストリームの統合で「壊れた時のリカバリーが安いアーキテクチャ」を教えられる。

📚 600 ページを一気読みする必要はない。困った時に該当章を引く辞書として、3 年は使える。設計判断で迷ったら、まずこの本を開く — それだけで「自分が今、何の問題を解いているのか」が一段クリアになる。

🔑 補足: まとめで使った CRDT(Conflict-free Replicated Data Type、衝突しない複製データ型)は本書 Chapter 5 で扱われる、leaderless 環境での conflict resolution を成立させる仕掛けや。Google Docs の同時編集や Figma のリアルタイム共同編集の裏側にいる主役の一人。