ISBN 9784873118703

データ指向アプリケーションデザイン : 信頼性、拡張性、保守性の高い分散システム設計の原理

データ指向アプリケーションデザイン : 信頼性、拡張性、保守性の高い分散システム設計の原理
刊行
2019-07

概要

オライリーの 「イノシシ本」 として現代古典の地位にある『Designing Data-Intensive Applications』(Martin Kleppmann 著)の邦訳。SQL も NoSQL も含めたデータシステム全体 を、信頼性 / 拡張性 / 保守性の 3 つの観点で体系化する。バックエンドエンジニア・SRE・データエンジニアのいずれの職種にとっても「棚にあるべき 1 冊」として参照され続けている。

想定読者

  • 数年バックエンドを書いてきて、「自分のサービスの信頼性をどう設計するか」 を 1 段抽象レベルで考えたいエンジニア
  • マイクロサービス / 分散システムの本(『マイクロサービスアーキテクチャ』など)を読んで、その下のレイヤを理解したい人
  • データエンジニア / SRE 志望、あるいは現職で データパイプラインの基礎理論 を体系で押さえたい人
  • DB / メッセージキュー / 検索エンジンを「ブラックボックス」ではなく「特性が分かる道具」として扱いたい人

こんな人には向いていない

  • プログラミング言語の文法・フレームワーク入門を求めている人(本書は言語非依存、設計理論が中心)
  • 1 冊で実装手順をなぞって動くものを作りたい人(本書はパターン・トレードオフを示す本で、実装手順書ではない)
  • DB やネットワークの基礎が全く無い人(『マスタリング TCP/IP』『達人に学ぶ DB 設計徹底指南書』などを先に通すのが現実的)

この本で身につくこと

  • 信頼性 / 拡張性 / 保守性 という 3 軸で、自分のシステムを評価する語彙ができる
  • B-Tree / LSM-Tree など主要なストレージエンジンの選択トレードオフを語れるようになる
  • レプリケーション / パーティショニング / トランザクション分離レベル の設計判断ができる
  • CAP 定理 / 結果整合性 / 線形化 が実装にどう影響するかを、具体的な障害シナリオで理解する
  • バッチ処理 vs ストリーム処理 の違いと、Kafka / Spark / Flink がどこに位置づけられるかを掴む
  • 二相コミット / コンセンサスアルゴリズム(Paxos / Raft) の概念と、実務での使われ方を知る

章立て(全 4 部 / 12 章)

第 I 部 データシステムの基礎(第 1〜4 章)

第 1 章 信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーション / 第 2 章 データモデルとクエリ言語(リレーショナル / ドキュメント / グラフ)/ 第 3 章 ストレージと取得(B-Tree / LSM-Tree / カラム指向)/ 第 4 章 エンコーディングと進化(JSON / Protocol Buffers / Avro)。

第 II 部 分散データ(第 5〜9 章)

第 5 章 レプリケーション / 第 6 章 パーティショニング / 第 7 章 トランザクション(ACID / 分離レベル / Serializable Snapshot Isolation)/ 第 8 章 分散システムの問題(時計 / ネットワーク / 知識限界)/ 第 9 章 一貫性と合意(線形化 / CAP / 全順序ブロードキャスト / 二相コミット / Raft)。

第 III 部 導出データ(第 10〜12 章)

第 10 章 バッチ処理(MapReduce / データフロー)/ 第 11 章 ストリーム処理(Kafka / イベントソーシング / CEP)/ 第 12 章 データシステムの将来。

ハイライト(外部評価)

バックエンドエンジニアにとって最強の本のひとつ。10 年は古びない設計の原理が体系で書かれている。」 — 国内エンジニア界隈で繰り返し参照されている評価軸(qiita 上の言及記事で確認可能)

「全エンジニアが読むべき本。マイクロサービス本を読む前に、この本を 1 度通したい。」 — オライリー公式の書評・読者レビュー(oreilly.co.jp)

ファンによる Github リポジトリ で、各章の概念を実装やコメントで補完する読書ガイドが作られている(エンジニア界隈で複数の派生プロジェクトあり)。」 — オライリー本としては珍しい現象、本書の影響力の傍証

読了後にできること

Before(読む前): DB が落ちたら困る、レプリカを増やせばいい、と漠然と理解。トランザクション分離レベルを「Read Committed か Serializable か」のどちらかで選ぶ理由が言えない。

After(読み終えた後): 「この障害シナリオなら線形化が必要、結果整合性で OK のケースはここまで」を、自分のサービスごとに区別できる。新しい DB 製品の発表を見たときに、それが LSM-Tree か B-Tree か、レプリケーション戦略は何か、という観点で評価できる。

読み方のコツ

本書は 600 ページ超 / 4,400 円台 の大著で、最初から最後まで通読しようとすると挫折しやすい。章単位で「今の自分の問題」と関係するところだけ引く 使い方が現実的:

  • DB 選定の議論をしているとき → 第 2 章(データモデル)+ 第 3 章(ストレージ)
  • レプリケーション失敗を経験したとき → 第 5 章(レプリケーション)+ 第 8 章(分散システムの問題)
  • トランザクションでデータ不整合が出たとき → 第 7 章(トランザクション)
  • Kafka を本番投入する前 → 第 11 章(ストリーム処理)

前提知識

  • 何らかのプログラミング言語で 2〜3 年バックエンドを書いた経験(Java / Go / Python / Ruby など問わず)
  • SQL の基本(SELECT / JOIN / トランザクションを意識して書ける程度)
  • Linux / OS の基本(プロセス / メモリ / ファイルシステムが何をしているか分かる程度)

これらが揃っていなくても読み進められるが、章途中で詰まる可能性が高い。

次に読む本

『マイクロサービスアーキテクチャ 第 2 版』(Sam Newman、オライリー)

DDIA で「データシステム」の語彙が揃った後、その上で動くアプリケーション層をどう分割するかを学ぶ。両書を並べると 「データ + アプリ」の両軸 で分散システムを語れるようになる。

『SRE サイトリライアビリティエンジニアリング』(Google、オライリー)

DDIA は「設計の原理」、SRE 本は「それを運用するチームの作法」。SLI / SLO / エラーバジェットの語彙が DDIA の信頼性章とぴったり繋がる。

『プログラマのための SQL 第 4 版』(ジョー・セルコ)

第 7 章のトランザクション理論を、SQL の文法レベルで深く理解したい場合の補助。

この本がどの学習段階で役立つかは、 関連する ロードマップ から確認できます。

質問に答えるだけで、
あなたに合う専門書が見つかる

IT・デザイン・士業・医療・経理・教育・研究 ほか、あらゆる分野の専門書と 「読む順序」(学習ロードマップ)を収録。何を選べばいいか分からなくても、 いくつかの質問に答えるだけでたどり着けます。