エピソードの紹介
London Tech Talkへようこそ。
リスナーのみなさん、こんにちは。London Tech Talkへようこそ。
イギリスのロンドンからお届けしています。Ken Wakatobaです。
本日は、London Tech Talkの【Bookclub 第四弾】
【Database Internals】の全体を通した振り返りを収録していきます。
長い道のりでしたが、ついに全14章を完走することができました。
今まで一章一章読んだ後で、振り返り収録というのを、基本的にはソロ収録。
時々、Bookclubの参加者の方をお呼びしてやってきたんですけれども、
せっかく一章読み終えましたので、今回は特別編として、
アレックス・ペトロプの【Database Internals】を通しで読んで、
学んだ内容を総括的に振り返っていこうと思っています。
ということで、ちょっとBookclub自体ですね。
思い返せば、始めようと思ったのはほぼ1年前なんですよね。
2024年の年末くらいでして、
分散システムとデータベースの内部実装について体系的に学びたいと、
そして一人で読むだけでは得られない知見とか知識を、
Bookclubの参加者と共有したいという思いから始まったこの取り組みでした。
数ヶ月をかけて、こうして完走に至ったことを、
個人的にも非常に嬉しいと思います。
Database Internalsの構成
2024年を振り返ると、年末に頭の中で構想がありまして、
前回第3弾は【タイリーファースト】という本を、
ケント・ベックの本を読んできたんですけれども、
次にどの本を読もうかなというのを、
まあ、つらつらと考えてまして、
じゃあ要するに【Database Internals】を読もうという風になって、
最初はゲストの方とか、
過去のBookclubの参加者が集っているディスコードがあるんですけれども、
そこで周知したのがきっかけでしたね。
この【Database Internals】第4弾の本書の選定にはかなり迷ったんですね。
もうだいぶ前のことなので、
細かい事実は間違って記憶しているかもしれないんですけれども、
今覚えていることで言うと、
一番結構軸として気をつけたのが、
自分が情熱を持ってファシリテーションできるという軸で、
最終的に判断した気がしますね。
やっぱり読みたい本とか、
学びたい技術というのはいくつかあったんですよね。
ファンクショナルプログラミングでもいいし、
もうちょっとアーキテクチャよりでもいいし、
やっぱりAIプログラミングのところでもいいかなと思ったんですけれども、
最後までファシリテーターとして3箇所を引っ張って
感想できるという意味で言うと、
やはりデザイニングデータインテンシャルアプリケーション、
DDAIの本の時のように、
やっぱりトピックとしては分散データベースとか、
パフォーマンスエンジニアリング、
レジデンシーとか、
あとはデータベース関連になるかなと思いましたね。
このデータベースインターナルズも、
キャリアの中では何度もつまみ食いしてきた本なんですけれども、
ブッククラブという形で読むのは、
個人的に初めてでしたので、
そのいい機会になるかなと思ったのも結構強い後押しでした。
ということで、簡単に本書の構成を振り返ってみようと思います。
パート1と2に分かれていまして、
パート1では単一のデータベースに同化した内容、
パート2だと分散環境で、
それぞれのデータベースを動かした時に気をつけなきゃいけない概念とか、
コンセプトについて紹介されていました。
パート1の部分では、
データベースの心臓部分とも言えるような、
B-Treeと呼ばれるデータ構造、
これはディスクにどのようなデータ構造で、
実際のデータを配置しているかというところなんですけれども、
それからファイル格納形式とか、
B-Treeの実装の詳細とか、
トランザクション処理、
あとはB-Treeと言っても、
B-Plus-Treeとか、
Blink-Treeとか、
いろんな改良版がありまして、
それぞれのB-Treeのデータ構造のアシュについて学んでいました。
そしてそのパート1の最後となるチャプター7では、
現代のモダンなデータベースでは使われることが多い、
LSM-Treeと呼ばれる別のデータ構造について触れられていましたね。
割とこれを読むことで、
データベースのインターフェースというのは、
例えばバックエンドエンジニアとかとして使っていると、
SQLというところになるんですけれども、
SQLが発行されてから、
ディスク上にあるバイナリを取ってきて返すまでの一連の流れというのが、
なんとなく見えたんじゃないかなという、
そのストレージレイヤーとか、
あとはそのクエリレイヤーの奥深い世界を探求することができるのが、
パート1になっていました。
それを踏まえた上で、パート2では、
それをディストリビューティブ環境で動かしたら、
どういったことを気をつけなくちゃいけないのかということで、
例えばフェーラーディテクション、故障検知ですね。
ノードの1つが死んだときにどのようにクラスター全体として、
ヘルスな状態を保つのかであったり、
リーダーエレクション、リーダー選出であったり、
1つのノードから別のノードにデータをコピーするレプリケーションとか、
あとはレプリケーションしたことによって生まれてくる整合性の問題ですとか、
あとはデータベースのメタ情報をノードの中に分散させていくような、
ディセミネーションとかアンチエントロピーの話とか、
あとは分散トランザクション、
そして最後にラフトとかパキソスとかで有名な合意形成という、
一連の現在の分散データベースシステムを抱える、
基盤となる技術についてパート2では学ぶことができました。
パートから得た学び
個人的にはこのパート1とパート2に分かれている構成というのは結構好きですね。
好きででして、
というのもまずはデータベースの内部にだけ興味があるという人は、
パート1だけ読むという読み方ができるからですね。
実際僕も最初はそういうふうに読みました。
例えばスタートアップとか小さいアプリケーション開発ですと、
分散システムの運用が求められないというケースもあると思います。
そんな場合でもデータベースのないアプリケーションというのは結構、
特に業務系開発していたりするとステートを持つことが多いので、
逆にそれはレアなんじゃないかなと思うんですよね。
だからほとんどの人が何かしらの形でデータベースに触れているという前提を置いたとすると、
そこで単体のインスタンスとしてのデータベースが内部でどう動いているのかというのは、
始めの一歩としてもとても良いきっかけづくりになるのが本書なんじゃないかなと思っています。
それを踏まえてのパート2なんですけれども、
分散システムという界隈は本当に長年研究が進んできて深い分野なので、
本書のパート2だけだとその評価の一部分しか見えませんけれども、
それでもキーワードを知るためにバランスよく浅く広く触れられている入門書としてすごいんじゃないかなと思いました。
ということで、これらを読んで個人的なテイクアウエーは何だったのかというところで、
これらの学びの中から個人的に特に印象深かった3つを紹介していこうかなと思います。
その第3位なんですけれども、
実践的な価値が高いなと感じたトピック、パート1から1つずつ選ぶとやっぱりLSM3ですね。
B3とかB3のBプラス3のASUみたいなのは結構コンピューターサイエンスのデータ構造の教科書とか授業とかで知ったこともあるかなと思うんですけれども、
このLSM3というのは現場のロックシティBとかいろいろ使われているところも多いので、
これについて深くメモテーブルの仕組みとかSSテーブルの仕組みを知っておくというのはすごい重要だなと思いました。
印象深かったものの第2位は、個人的にはパート2からはいっぱいあるんですけれども、
1つ選ぶならChapter10のリーダーエレクションですね。
分散システムにおけるリーダーを正しく選ぶというのは結構難しいものなので。
そして第1位はやっぱりパート2の締めでもあるChapter14、何と言っても合意形成アルゴリズムですね。
特にRAFTについて深く振り返りたいなと思っています。
個人的にもちょうどRAFTについていろんなところで学んだり勉強したりしている途中だったのでタイミングも良かったというのもあり、
やっぱり合意形成アルゴリズムというのは分散システムにおけるかなり重要なトピックの1つでもあるので、
この本章を読んだことをきっかけに改めて深掘りしたいトピックでもありました。
個人的なテイクアウェイをまず紹介して、その後でね、
ブッククラブの運営者としても1年弱かな、9ヶ月ぐらいを通して感じた運営の気づきとか学びについても軽く振り返りたいなと思っています。
ということでまずテイクアウェイからいこうと思います。
Chapter7で学んだLSMツリー第3位ですね。
ちょっとLSMツリーについても振り返っていこうと思います。
LSMツリーが解決する根本的な問題というのが、
現代のアプリケーションにおけるライトの主役的なワークロード、ライトヘビーなワークロードへの対応なんですよね。
例えば具体的なユースケースで言うとソーシャルネットワークサービスのタイムラインとか、
IoTデバイスからのセンサーデータとかアプリケーションログからの収集マン、何でもいいんですけど秒間何万何十万という書き込みが発生するようなシステムでは、
従来のB3のようなインプレスアップデートの方式だとライトアプリケーションという問題が起こってボトルネックになってしまうんですよね。
このB3というのはツリー構造を常に維持しなくちゃいけないので、アップデートとかデリートとかインサートみたいな書き込みが発生したときに、
LSM3のデザインとB3との比較
このツリーをバランスさせるという処理が必要なんですけれども、書き込みの処理が多ければ多いほど、そこがボトルネックになってしまうと。
B3のアッシュというのは、例えば書き込みをバッチングしてみたりだとか、ちょっとした工夫をデータ構造に加えることによってそこのアンプリケーションにならないようにしているというのがB3のアッシュだったんですけれども、
LSM3はそもそものデザインのところから解決しようとしているというのがすごいクリエイティブですね。
やっぱりデザインで綺麗だなというか美しいなというものがシンプルな発想ですね。
全ての書き込みをシーケンシャル、線形というんですかね。ただ書き込むだけにアペンドオールにするという発想なんですよね。
まずデータをメモリ上にメモテーブルというデータ構造があって、そこで一旦バッファーみたいな感じで受け止めて、
そのメモテーブルにある程度書き込みのイベントが溜まったら相当済みのSSテーブルという、これはディスク上のデータ構造なんですけど、
そこに一括で書き足ししていくということで、書き込み自体というのは常にディスクの末尾というんですか、最後にアペンドオンリー、追記していくだけなので、
P3でよく発生するようなランダムIoが排除されると。そのランダムIoが排除されることによって書き込みをするものの、
より早い高速な書き込みを実現できるという、そういうのがLSM3の発想の一番のキーワードなんですね。
もちろんこの設計にはトレードオフも付きものです。全てのデザインにはそうなんですけど、トレードオフもあって、
なのでB3よりLSM3がいいということではもちろんないんですよね。
デザインチョイスをするときにはそれぞれのアルゴリズムとかデータ構造のトレードオフを理解するというところがポイントで、
このLSM3にはどういうトレードオフがあるかということなんですが、読み込みですね。
ライトはアペンドオンリーしていくだけでいいとは言ったものの、読み込むときにはどういうオペレーションが裏側で発生するかというと、
複数のSSテーブルを横断して検索する必要があるんですよね。
例えばB3だったら連軸エリなんていうのは、各ノードのリーフノードが相当されているので、そこの並んだブロックをパッと取ってくればいいんですけども、
じゃあSSテーブルのときにはどうするのかというところで、うまくやらないと、今度は逆にリードアンプリフィケーションが起こってしまうと。
これを解決するためにLSM3では色々な工夫をしているというのが本書で紹介されていて、
例えば取りに行こうとするディスクにデータがあるかどうかを確率的アルゴリズム、ブルームフィルターと呼ばれるフィルタリングアルゴリズムを使ってやはり精度を高めることによって、
その不要なディスクのデータのフェッチをなくすというような考え方であったり、
あとそのSSテーブルもどんどんフラグメンテッドというか小さいSSテーブルがたくさん出てきてしまうので、
それをコンパクションすることによって、1回でフェッチするときのそのSSテーブルのディスクをまとめることによって、ディスク愛用の効率化を図ろうみたいに色んな工夫を施されています。
これは例えばロックスDBとかになると、このSSテーブルにレイヤード、レベルをつけて、レベル1、レベル2みたいな感じで、
その流度の違うSSテーブルを階層構造にするなんていうアイデアも出てきたりするんですけれども、
そのLSM3という別のデザインにすることによって工夫ポイントも異なってきますよねというところが結構ポイントでしたと。
僕はサイトリライビティエンジニアなので、SREの観点から見るとやっぱりLSM3ベースのシステムだとやっぱりB3ベースのシステムと見なきゃいけないメトリックスというのが変わってくるんですね。
そこを適切に理解するというのも結構ポイントだったなと思いました。
例えばLSM3ベースのシステムだとコンパクションというのも言いましたけど、そのSSテーブルを非同期もしくはストップで終わるみたいな感じでコンパクションしなきゃいけないんですけれども、
そのコンパクションが通常のワークロードに影響していないかどうかというコンパクションのワークロードからくる、
例えばどれくらいCPUを使ってますかとかどれくらいの頻度で発生してますかみたいな健全性監視は極めて重要ですし、
そのSSテーブルとかメモテーブルのカスサイズとか、アクトはQサイズみたいなそのメトリックスを適切に監視していくというところも重要かなと思いますね。
リーダー選出アルゴリズムの解説
それを理解するためにはLSM3の大まかなデザインを理解するというのがすごい大事になってきましたと。
というところでLSM3チャプター7丸々採って紹介しているというところもあって、結構個人的にはいいタイミングのショーだったんじゃないかなと思いました。
個人的なベスト3テイカーウェイの第2位ですけれども、これはチャプター10のリーダー選出アルゴリズム、リーダーエレクションでした。
このリーダー選出アルゴリズムというのは分散システムの多くの問題の基盤となる出発点となるようなすごい重要な概念なんですよね。
例えばそのデータクラスターにデータノードが3台いますとか5台いますとなったときに、どのノードをリーダーにするかというのを適切に選ぶ必要があるんですよね。
例えばスプリットブレインみたいな問題があって、それは例えば俺がリーダーだ、いやいや私がリーダーだみたいな感じで複数のノードが自分がリーダーだと誤認識してしまうと、
どこのノードからどこのノードにデータをレプリケーションするかみたいなところで統制が取れなくなってしまうので最悪の場合、
少なくとも例えばそのデータベースがクラスターとして健全に動けない状況になりますし、最悪の場合データが壊れてしまったりとかあとは整合性が保てなくなったりしてしまうので、
このリーダー選出アルゴリズムというのは分散システムでデータベースを動かすときに極めて重要な概念かなと思っていて、
このチャプター10の面白いところは、いろんなリーダー選出のアルゴリズムについて一つ一つ丁寧に紹介されていたところですね。
例えばまずはブリーアルゴリズム、ブリーというのはいじめっ子という意味ですけれども、ブリーアルゴリズムの説明から始まってましたね。
このブリーアルゴリズムの革新というのは、いじめっ子というところからもう想像できるようにランキングベースの選出ですね。
一番腕っぷしが強いやつからランキングをつけていくみたいな感じで、それぞれのノードにランクをつけていて、最も高いランクを持つ生存ノードがリーダーになるというシンプルな、基本的にはシンプルなルールでしたね。
あとはキャンディデイトオーディナリーオプティマイゼーションみたいな考え方もあって、これは基本的にはブリーアルゴリズムみたいにランキングベースでの選出なんですけれども、
その中でリーダー候補になるキャンディデイト、候補者ノードと、あとは普通のオーディナリーノードという役割を分離することでメッセージ数を削減します。
メッセージ数を削減しますというのは、例えばリーダーになり得るキャンディデイトが10台いると、その10台の中で掛け合わせ的にハートビートであったり誰がリーダーになるかみたいなメタデータのやり取りが発生してしまうんですけれども、
例えば10台のうち5台だけがキャンディデイトノードですというふうに事前に決めておくことによって、今言ったようなネットワーク上をやり取りするメタデータの数とかリモートプロセッジャーコールの数を減らすことによって最適化を図るみたいなネットワークの負荷を軽減するためのアイデアがあったりして、面白いなと思いましたね。
あとはインビテーションアルゴリズムみたいなのも紹介されていて、これも個人的には面白かったんですけれども、これはまず最初に1つのリーダーみたいな制約を緩和して、複数のグループそれぞれがリーダーを持つことを許可して、
徐々にノードごとのドメインというかエリアみたいなのをマージしながらリーダーを決めていくみたいなボトムアップ的なアプローチなんですけれども、これは結構ネットワーク分断が発生しやすい環境だとスプリットブレインを問題視するよりも各グループが独立して動作できることの方に価値があるケースもあったりするので、
そのケースバイケースで別のリーダーエレクションアルゴリズムもあるよっていうのを理解しておく、頭に入れておくっていうのはデザインチョイスをするにあたってすごい引き出しを増やしておくという意味で、いろんなリーダー選出のアルゴリズムを少なくとも頭に入れておくのはいいことかなと思いました。
合意ケースアルゴリズムの重要性
ということで第2位がリーダーエレクションでした。
個人的なベスト3テイカーウェイのナンバーワンがチャプター14の合意ケースでしたね。
チャプター14が一番最近読み終わったばっかりなので、リセンシーバイアスというか直近のものが重要だと思いがちな人間のバイアスがかかっているかもしれませんが、やっぱり本書の最後というところもあって醍醐味かなというところで、
第チャプター14のボリュームも結構あったので、そこで紹介されていたパキソスのいろんな亜種も紹介されていましたね。
マルチパキソスだけじゃなくてファーストパキソスとかイーパキソスとかイガリタリアンパキソスとかいろいろあったんですけども、それを踏まえた上でラフトももちろん紹介されていましたね。
個人的にはやっぱりラフト、合意ケースアルゴリズムの中でも今最もモダンな分散システムで広く採用されていると言ってもいいんじゃないかなというような重要な合意ケースのアルゴリズムでした。
このラフトについてきちんと理解しておくというのは分散システムを運用するSREとかそれを実装するデータベースエンジニアは間違いなく理解しておく必要がありますし、そうじゃない人でも知っておいて損はないんじゃないかな、結構面白いアルゴリズムなので。
このラフトは何かというと合意ケースのアルゴリズムなんですけども、パキソスの理論的な美しさみたいなのを保ちながら論文ではunderstandabilityという言葉で紹介されていたんですけども、
このアルゴリズム自体の理解しやすさ、そして実装しやすさというのを明示的な設計目標に据えて考えられた合意ケースアルゴリズムなんですね。
というのはパキソスが結構理解するのが難しいというところがあって、パキソスの論文自体も何本も書かれていて、そのたびにシンプリファイドパキソスみたいな感じでパキソスをわかりやすく説明しようとする取り組みも試みも何回もされてきたような、
理論的に美しいというのをわかっているものの、やっぱりアカデミー図の人たちでもなかなか完全に理解した状態になるには難しいようなものがあったので、やっぱりその理解されないと実装できないんですよね、もちろん。
理解できないものというのは実装できないじゃないですか。そこを問題だと捉えたRAFTの開発メンバーが、Understandability、理解しやすさと実装しやすさを設計目標に据えたというのがRAFTでしたと。
そのRAFTのポイントとしては、例えばリーダー選出、リーダーがいるという前提に立ったアルゴリズムであるところとか、あとはすべてのイベントをログレプリケーション、悪みたいな感じでリーダーからフォロワーにレプリケーションしていくであったりとか、
あとは安全性ですね、ギャラリティする3つの独立した要素を分解して複雑な分散合意形成を一つ一つのコンセプトに落とし込んで理解できるようにという形で、結構論文も18ページくらいかな、リファレンス含めて18ページなので実際の内容は十数ページくらいなんですけど、
割と読みやすいですね、割とというのはパキソスとかと比べてということなんですけども。
ちょっとRAFTも簡単に振り返ってみましょうと。
RAFTはリーダーを前提とするんですね。
なのでリーダー選出、さっき言ったチャプター10のリーダーエレクションを前提としています。
これはタイムアウトベースの選挙システムでして、フォロワーノードというのがいます。
フォロワーノードのうちの一人がリーダーになりますと。
フォロワーノードは常にリーダーからのハートビートを受け取って、リーダーがいる間はフォローしますという感じでやり取りをしているんですけども、
リーダーからのハートビートが途絶えた時に、フォロワーは自分は候補者、キャンディレートという子になって選挙を開始するんですね。
例えばリーダーが死んでしまった時とか、ネットワークパーティションによってハートビートが来なくなった時に一定数来なかったらリーダーがいなくなったとみなして、
自分が候補者になります、キャンディレートになりますといって、ボートリクエストRPCを他の人に送り始めると。
そこで過半数の票を獲得したノードが新しいリーダーになるというのがRAFTのすごいシンプルにさまった基本的なリーダー選出です。
一度リーダーになったらクライアントからいろいろな書き込み操作とかが来るんですけども、そのリーダーがまず受け取って、
それをAppend Onlyのログエントリーとしてどんどんどんどん書き込んでいって、それをフォロワーに複製していくんですね。
ここで2段階のプロセスがあって、まず一旦リーダーがフォロワーにこのログのエントリーをまず複製しますと、
リピリケートしますと。フォロワーは受け取りましたよというふうにアクノレッジするわけですね。
この時に過半数のノードからアクノレッジされた時点でコミットします。
例えば5台行った時に5台のうちの1人がリーダーで、その5台のノードに複製するわけですよね。
そのうちの3台以上からアクノレッジが来たら、少なくとも3台にはきちんとデータが届いたと。
マジョリティにデータをきちんと届けられたということは整合性を保てるというふうに認識して、
じゃあコミットしましょうということで次にコミットの命令をして、
そのコミット命令を受け取った人たちはそれをコミットとみなすということによって、
このプロセスをすることによってこのデータというのが必ず過半数のノードにきちんとドゥラブルな状態でコミットされていく状態なんですね。
これによってクラスター全体でデータの一貫した状態というのを保っていくというのがポイントになってきますと。
ラフトですごい大切にしている前提条件というかラフトが保証するという条件がいくつかあるんですけども、
その一つの制約というのが一度この今の説明したプロセスでコミットされたログエントリーというのは、
未来のボートタームのリーダーのログにも必ず含まれるという制約条件なんですね。
これはなぜ大切かというとというのもリーダーが交代することはあるわけですよね。
例えば今までノードAがリーダーだったけれどもノードAが死んだしまったのでノードBがリーダーになったと。
この時リーダーが交代したとしても一度それまでにコミットされたログエントリーは新しいリーダーの手元にコミットされたログとしてあるのでデータは一貫してあるはずなんですよね。
これはアルゴリズムでデザインされているのでここの一貫性が保証されています。
これによってリーダーが交代されてもデータの安全性というかデータの一貫性が損なわれることがないというところは結構ラフトは大きい目玉だったりします。
ブッククラブの運営の知見
このラフトはコクローチDBとかUBITEDBとか多くの現代的なモダンなデータベースが採用しているというのはこの実装のしやすさが大きな理由かなと思っています。
ということで個人的なテイクアウェイNo.321ということで紹介してきました。
データベースインターナルズを一緒にブッククラブに参加してくださった皆様やエピソード振り返り収録を通じて一緒に読んでくださったリスナーの皆さんの個人的なテイクアウェイは何だったでしょうか。
ぜひもし一緒にこれを読んでデータベースインターナルズを読んだよという方はGoogleフォームにお便りがありますので皆さんの個人的なテイクアウェイとか分からなかったところとかぜひ教えてください。
内容を振り返ったので次にブッククラブのオーガナイザーというかファシリテーターとして1年間9ヶ月運用してきたのでだいぶ思っちゃいましたね。
9ヶ月通して感じた運営の気づきとか学びについてもログみたいな感じできちんとこのタイミングで振り返っておこうかなと思います。
よかった点からでいくとやっぱり一つは継続するための仕組み作りでしたね。
今回も参加するタイミングで途中で子供が生まれるので途中から非同期になりますみたいな方が2人いたりとかそういうのがあったので参加者っていうのはやっぱり増えることはないので減ってしまうんですけれども。
とはいえやっぱり最後まで読んでくれた方もなかなか僕が思ってたよりは多かったかなと思いますね。
やっぱり本書がちょっと違うな自分が想定して知ったのとは違うなみたいな方はもう割と早い段階でドロップアウトするので途中まで読み進め始めた方は最後まで読めたっていうのはすごい良かったかなと思いますね。
個人の学習であれば一人で読んでたらモチベーションが下がった時に一時休することも可能なんですけども複数人で日時を調整して定期的な頻度で読むブッククラブというのはやっぱり参加者全員のペースを合わせるということでやっぱりファシリテーターである自分がペースランナーみたいな形で読んでいくところはすごい意識しましたね。
構造化のところで言うと割と毎回やることが違ってたらやっぱりオーバーヘッドもあるので章ごとのテイカーウェイを明確にするとか毎章の読書ノートのテンプレを統一するみたいな形で毎週やることは決めてあとはただ読むところにフォーカスできるようなブッククラブに参加するということ自体が
すごいハードルの高いものではなくて読むというところがあくまでのフォーカスなのでそこ以外の部分はなるべく構造化とか自動化とかテンプレ化することによってハードルを運用者としても参加者としても下げるみたいなところは結構ポイントとして掲げてました。
ファシリテーターとして参加してよかったのはやっぱり4回目になりますけれども議論をファシリテートする技術もまだまだ改善ポイントありつつも自分が9ヶ月前にやってた時よりは向上したかなと思いますね。
技術的な内容の議論では参加者がなるべく発言しやすい雰囲気を作るといったところだけじゃなくて使っている専門用語タームの定義を適切に確認したりとかあとは自分で読書ノートを書くときもしっかりリサーチして書かなきゃいけないのでそういった意味でどういった土台を作ると議論が盛り上がるかみたいなところを常に意識して参加しなきゃいけなかったので
まだまだ道半ばとはいえ9ヶ月前の自分と比べると改善もできたかなと思ってたりします。
あと時間管理ですね。
限られた時間の中で皆さんいろんな会社に所属している中で参加する以外のリワードがない状況で参加しているわけじゃないですか。
例えば会社の一部のブッククラブであったら例えばボスがリードしてるから出なきゃいけないみたいなピアプレッシャーがあったりとか参加することによってリワードがあるじゃなくて純粋に何かを学びたいっていうところだけで参加しているので
やっぱり皆さん忙しいと自分も忙しいとその中でスケジュールも調整して本も読んでで
あとは実際のブッククラブもやってそれが終わった後にソロ収録もしてでそれも編集もしてでそれもアップロードしてみたいな一連のその流れってのをちゃんとつく
で習慣化することによって時間管理もなんとなく合わせるように後半はなってきたかなと思ってきます。
やっぱりこうこれは毎回言ってますけどあとはコミュニティの力というか技術学習におけるコミュニティというかピアラーニングの力かなコミュニティというかピアラーニングかなはすごい実感しましたね。
参加者からのフィードバック
やっぱりモチベーションマネジメントみたいな観点でももちろんそうですよね。
一人ではやっぱり挫折しがちな技術書も一緒に読んでくれるピアラーナーがいることで最後まで読み切ることができたのはもちろんですしこれも何回も言ってますけどやっぱり自分が本書読んで理解したっていう
メンタルモデルが他の人に当ててみると欠けてる部分間違ってる部分あとは思い込みすぎてる部分みたいながあったりするのでそれを議論通して
刀を舵するみたいな感じじゃないけど固めていくというか練度を上げていくみたいなところもやっぱりディスカッションの醍醐味かなと思ってます。
ということで今回のブッククラブは良かったですね。
次どうしようかなというところでメインのエピソードでも紹介した通り私に無事第二誌が生まれたのでちょっと今回のペースで2026年
ブッククラブ別の本をファシリテーションしていくのはちょっと難しいかなと思っているので少なくとも前半はいろんな形を考えたいかなと思っててしばらくはね
今回のブッククラブで学んだ内容をさらに深掘りするボーナス編をいくつか収録したいなと考えてます。
具体的にはソロ収録みたいな感じで例えば論文とか実際の実装とかをいくつか見て本書で深掘りできなかったところって結構あるんですね。
それをこの単発エピソードボーナス編みたいな感じでちょくちょくと取っていけたらいいかなと思います。
今のところ考えているのは具体的にはラフトアルゴリズムの詳細な実装について実際のコードを読みながらとか論文を読みながら
論文ラフト論文一緒に読みましょう改めて読みましょうみたいなDTIAの時も読んだんですけどそんな感じのボーナス編してもいいかなとか思ったりとか
コクローチDB、ETCDとかイガバイトDBみたいな実際のプロダクトでどのようにラフトが実装されているのかっていうのを紹介しても面白いかなと思ってます。
やっぱりそのオリジナルのラフト論文が発表されてからも10年近く経つので
オリジナルのラフト論文にはない追加のメカニズムとか最適化みたいなのがやっぱり現場で進んでるんですよね。
例えばリーダーがリードワークロードを捌けるようなリーダーリースの仕組みだったりとか
あとそのラフトのハートビートをバッチングするみたいな仕組みがあってこれは本論文ではほぼあまり触れられてないところなので
そこをねそういったところの現場で使われているラフトってどうなのみたいなところを深掘りしても面白いかなと思ったりします。
あとはCRDTやりたいですね。
これはもうやるやる言ってもう2年ぐらい全然やれてないCRDT。
Conflict-Free Replicated Data TypesということでDDIAの著者でもあるマーティン先生も割と発表とか研究していた
コンフリクトフリーなデータタイプのところでデータベースインターナルでもチラッと触れられてたかな。
キーワードとして出てたはずでリアルタイムのコラボレーションアプリケーションを作るときとか
モバイルアプリケーションのオフライン対応などで活用されている事例を紹介できればいいかなと思います。
あとやっぱりSRE観点でのデータベースの深掘りというのもちょっといきたいかなと思ってますね。
例えばじゃあLSM3ベースのデータベースを運用するときにどういったメトリックス具体的に見てますかとか
あとはGoogleが出しているSREブックスのシリーズの中で今回の本書に絡んでいるようなチャプターがいくつかあるんですよね。
そういうのをつまみ食いでつまみ読みしてそこの紹介みたいなのをしても面白いかなと思ったり
あとはDevOpsプラットフォームエンジニア、データベースエンジニア、SRE共通のトピックかもしれないですけど
データベースを運用するというところに特化してもっと話したらいいかなと思います。
あとは一つの個別のデータベースプロダクトをピックアップして深掘りしても面白いかなと思います。
じゃあ今日はコクローチDBの深掘りしましょうとか、あとは今日はUgabyteDBの深掘りしましょうとか
あとはスパベースの深掘りしましょう。何でもいいですけどね。
そういったのも面白いかなと思ったりしますのでしばらくそのボーナス編というか
補助するDatabase Internalsの内容を補完するようなトピックを追加でやっていこうかなと思っています。
今後のエピソードについて
ということでまだまだ続きますということでぜひ次の収録を楽しみにしていてください。
ということでDatabase Internalsの振り返りは以上にしようかなと思います。
今回はBookClubの今までチャプターごとの振り返りをしてきましたが全体を通した振り返りをしました。
個人的に学びのあった3つのテイクアウェイ。
LSMツリー、D-Direction、RAFTというトピックについて紹介したり
あとは個人的なファシリテーターとして参加したBookClub運営の学びを共有させていただき
今後のエピソードの計画というかチラ見せについてもお話ししました。
約9ヶ月間にわたって続けてきたこのBookClubを通じて
分散システムとかDatabaseの内部実装について体系的に学ぶことができたんじゃないかなと思います。
何より一人では決して得られなかった
多様な視点とか深い洞察というのを
BookClubの素晴らしい参加者の皆さんと共有できたことが最大の収穫だったかなと思います。
今後もこの学びをベースとして
より面白いプラクティカルで価値のあるコンテンツを引き続き
リスナーの皆さんにお届けしていきたいと思いますので
ぜひ楽しみにしていてください。
こんな話聞いてみたいよとか、次この本読んでみたらどうですかとか
色々なアイディア、フィードバックぜひお待ちしていますので
書ノートにあるリンクからGoogleフォームでぜひご意見ください。
ということで、今日も聞いてくださってありがとうございました。
それでは皆さん、Have a nice day.
