ひさしぶりに「データ指向アプリケーションデザイン」を読んだ

これは KOBA789 日記 Advent Calendar 2021 - Adventar 14日目の記事です。

日記を書くには早すぎる時間なんだけれど、久しぶりに「データ指向アプリケーションデザイン」を読んだら気持ちが高まりすぎてしまったので、書く。

データ指向アプリケーションデザインと私

「データ指向アプリケーションデザイン」（以下、本書）は "Designing Data-Intensive Applications" の和訳であり、2019年に発行された書籍です。

原著の方は2017年には発行されていたらしいのだけれど、恥ずかしながら当時は知りませんでした。和訳が出たということで話題になっていたのを見て知り、買って読みました。

初めて読んだときの衝撃といったらすごいものでした。学術的なバックグラウンドがほぼ皆無な私が趣味・業務内の試行錯誤のみから思索してぼんやりと仮説を立てていたものについて、その答えが根拠とともに載っていたのです。

私の感覚は間違っていなかったんだという安堵感と同時に、なぜ文献にあたらずにひとりだけで問題に向き合っていたのかと後悔し、また列挙されている参考文献の多さを見て、私と興味を共有する人々が世界中にはこれほどいるのかと嬉しくなったのを覚えています。

その感動をより多くの人と分かち合いたくて、すぐにその場で追加でもう1冊追加で買い（布教用というやつです）、とりあえず当時の職場の CTO の机の上に置いたりもしました。

ペーパーバック版は大きくて持ち歩きづらいので、友人とのふとした会話の中で参照するには不便です。そのため電子版も買ってスマートフォンに入れてあります。電子版は全文検索が効くので、紙の本をシークするときの索引としても便利ですね。

ひさしぶりに読んだ

そんな本書ですが、今朝2年ぶりくらいに読み直しました。きっかけは若干仕事で必要だったからなんですが、勢いで頭から第Ⅱ部（400ページくらい）まで読みました。思い入れのある1冊の割にはレビュー(?)をしたことがなかったことに気づきました。せっかくなので書きます。

12ページ目くらいで早速 Twitter のタイムラインの話が出てくるあたりで泣きそうになりました（一度読んでるはずなんですけどね）。データシステムに興味があれば、誰しも一度はスケーラブルなタイムライン機能の設計を考えるものです。読者のハートをガッチリ掴んできます。

日常的にデータシステムと向き合っていれば、システムの信頼性を高めるにはどうすべきか、スケーラブルにするにはどうすべきか、という勘が多少なりとも育まれます。しかし、実際に信頼性の低いコードやスケーラブルでない設計を目の当たりにしたときにその問題をわかりやすく説明できるでしょうか。あるいは妥当な修正案を出せるでしょうか。必ずしもそうとは限りません。

本書ではそうした勘を言語化するための強力な武器になります。課題を分解し、概念を定義し、例を交えて読者に整理されたメンタルモデルを与えます。いずれも現場に向き合ったことがあればスッと心に染みる課題ばかりです。課題が分解され整理される様を追いながら解説にうなずき続けることになるでしょう。読者の悩みを読者より雄弁に語ります。

REST と RPC の話が個人的に好きなので一部を引用します。

RESTの魅力の一部は、それ自身がネットワークプロトコルであるという事実を隠そうとしていないことにあります データ指向アプリケーションデザイン P.145

私が今よりもさらに未熟だったころ、RPC に夢を見すぎて実際に本書で指摘されているような RPC の問題に直面したことがあります。本書では、リモートサービスの呼び出しをローカルの関数呼び出しのように見せかけるアイデアには「根本的な問題がある」とすら書かれています。私もそう思います。具体的にどういう問題があるのかは P.144 を参照してください。

関連して、8章の内容も好きです。特に8.2の、非同期パケットネットワークって不便だよね、というあたり。皆さんご存じの通り、IP ネットワークは非同期パケットネットワークの一種です。なのでいろいろ困ったことが起きます（具体的な困りは P.302 あたりを読んでください）。

でも TCP を習う時って信頼性のあるプロトコルだって説明されませんか？　UDP と比較して TCP には順序保証とか到達確認とかがあるってだけなんですが、10年くらい前に勉強したときは、TCP はめっちゃ信頼性がある印象を受けました。信頼性あるなら普通に RPC 乗っければいいって発想になりますよね？　私だけ？　まぁ結論としてはそれは幻想なんですが。

第3章、ストレージの話が grep や tail を用いた素朴なストレージエンジンの実装から始まっているのも感動的です。私の書いた記事ではいきなり B-Tree から始めてしまいましたが、誌面の余裕さえあればシンプルなテーブルヒープから始めた方がわかりやすいし、インデックスのありがたみや意味が実感できるよな、と思ったりします。

ストレージエンジンに（当然）魔法なんかなくて、実にエンジニアリングらしいチマチマしたトレードオフの選択でそれっぽい性能特性が得られてるだけなんですよね。その出発点として、まずは（直感的にダメそうでも）素朴な実装から始めてみるというのは理解に大いに役立ちます。ちなみに直感的にダメそうでも特定ケースでは問題なかったりしますし、現実がそのうまくいく特定ケースにハマることはよくあります。自戒を込めて。

この調子で書いていくといくらでも語れそうなのでこのへんにしておきます。あ、Avro のライターのスキーマ・リーダーのスキーマとかも地味ですがおもしろいですよね。まずい、話が終わらなくなる。

終わりに

明日も書く。