感想: データ指向アプリケーションデザイン / Martin Kleppmann,(監修)斉藤 太郎,(訳)玉川 竜司

llll
·

600ページを超える分厚い本なので気になった箇所だけ読んできたが、年末年始に時間ができたので通しで読んだ。概要は以下の通り。

現代の分散システム設計においてデータの扱いは重要な課題です。システムはスケーラビリティ、一貫性、信頼性、効率性、メンテナンス性を維持する必要があり、そのためにリレーショナルデータベース、NoSQLデータストア、ストリーム、バッチプロセッサ、メッセージブローカーなどのツールが数多く存在します。

本書は、データを処理し、保存するさまざまなテクノロジーの特性を詳述することで、ツールの長所と短所を理解し、システムの課題と使用するアプリケーションに適した選択肢の発見を助けます。

本書では、データの量や複雑さ、変化が課題となるアプリケーションを「データ指向」と名づけ、データ指向アプリケーションの設計を支える基本的な概念を解説します。

そしてレプリケーション、パーティション、トランザクションなど分散データベースについて扱い、さらにバッチ処理、ストリーム処理など、データセットの取り出しや結合について解説します。データ処理のテクノロジーを総覧し、特性やトレードオフを詳述する本書はソフトウェアエンジニア、アーキテクト必携の一冊です。

本書は「信頼性があり、スケーラブルで、メンテナンス性が高いデータ指向アプリケーション」を作るための知識を提供する本。ここで「データ指向アプリケーション」とはデータの量や複雑さ、変化の速度が主な課題となるアプリケーションを意味する。

第一部「データシステムの基礎」ではデータ指向アプリケーションの設計を支える基本的な構成要素として、信頼性・スケーラビリティ・メンテナンス性の定義や SQL などのクエリ言語、ストレージの構造や JSON などデータのエンコーディングを取り上げる。

第二部「分散データ」では複数のマシンにデータを分散配置するにあたって適時性と整合性を維持するためのレプリケーションやトランザクション、パーティション / シャーディング、一貫性や合意の実現について取り上げる。

第三部「導出データ」では既に存在するデータセットからデータを取り出して活用するための仕組みとしてバッチやストリーム処理、そして最後にデータシステムが将来あるべき姿について述べている。

全体を通して、大規模なデータを処理するアプリケーションの裏側にどのような仕組みがあるのかを解説するような本だった。例えば第7章「トランザクション」ではデータベースにおいてトランザクションをどのように使うかではなく、それらがどのような制約や背景の下どのような方針で実装されているかを説明している。

ソフトウェアの世界にあらゆる状況に適応する完璧なアーキテクチャは存在せず、誰もが常に何かを優先し何か別のことを諦めている。例えばトランザクションが提供するデータの安全性保証(いわゆる ACID)を厳密に突き詰めると、データベースの可用性やパフォーマンスに一定の制約がかかってしまう。それらを可能な限り両立させるためには、トランザクションがどのように実装されているかを理解した上で、自分が向き合っているアプリケーションにとって何が必要かを判断し実装していく必要がある。

本書はデータ指向アプリケーション全体を一つのデータベースとみなして整合性や可用性、パフォーマンスを可能な限り高めるためのトレードオフを検討する教材として非常に優れた本だと感じた。

個人的に印象に残ったのが最後の12章 578 ~ 582 ページの「12.3.4 信頼しつつも検証を」の節だった。以下の文章は 578 ページより引用。

コンピュータが間違うのではないかと常に心配しなければならないのであれば、何らかの処理を完結させることは非常に難しくなります。従来、システムモデルはフォールトに対して二者択一のアプローチをとってきました。すなわち、何かが起こることはあり、他のことは決して起こらないといった仮定をしていたのです。現実には、むしろそういったことは確率的な問題です。すなわちあることは起こりそうであり、他のことは起こりそうにないといったことなのです。問題は、仮定に反することに現実に出くわすかもしれないほど、その発生頻度が高いかどうかということです。

ここでいう「システムモデル」は現実世界を単純化するために一定の仮定を置いて問題を抽象化することで理解しようとする考え方を指す。しかし、現実世界ではさまざまなことが起こり得る。例えばトランザクションによるデータ整合性担保を検討するにあたり、当然ながらプロセスのクラッシュやマシンの電源喪失については起こり得ると仮定すべきだが、 CPU の乗算命令が常に正しい答えを返すかどうかまで考慮すべきか?

本書ではソフトウェアのバグやハードウェアの障害が起きても可能な限りデータの整合性を保つために自己検証・自己監査を推奨している。例えば HDFS や Amazon S3 ではファイルの保存にあたりディスクを全面的に信用せず、バックグラウンドプロセスを用いて他のレプリカと比較検証しディスク間でファイルを移動させている。

また、本書の出版後に発表された Amazon QLDB ではデータを追記のみで変更でき、その追記レコードのハッシュチェーンを検証することで(AWS への信頼を前提として)データそのものに改竄耐性と検証可能性を付与している。

将来的にデータが大量に複雑になることはあってもその逆はないと考えられるので、本書で取り上げられているようなデータの整合性や適時性を保つような仕組みを理解しつつもそれを盲信しないことが重要だと感じた。

@llll
経理 → プログラマー