リスナーの皆さん、こんにちは。London Tech Talkへようこそ。
イギリスのロンドンからお届けしています。Ken Wagatamaです。
本日は、London Tech Talkのブッククラブ、【Database Internals】の振り返りを収録していきます。
今回は、チャプター12、【アンチエントロピー&ディスエミネーション】
分散システムにおけるアンチエントロピーとメタデータ配信について、振り返っていこうと思います。
さて、このタイトルにあるエントロピーという言葉なんですけれども、普段あまり耳にしない方も多いかもしれませんね。
このエントロピーという言葉は、もともと物理とか、あと情報理論とかでも使われる用語でして、
日本語に訳すならば、乱雑さ、カオスという意味ですね、とか、あとは無秩序さの度合いというのを表している言葉です。
例えば、きれいに並んだ本棚が誰かにぐちゃぐちゃにされた状態とか、
おもちゃのケースをひっくり返しておもちゃを床に広げたような状態、これがいわゆるエントロピーが高い状態と言えると思います。
逆にバラバラだった本を元通りに整理したり、おもちゃ箱におもちゃを片付けることがアンチエントロピー、
つまりエントロピーを減らす秩序を取り戻す動きということが言えます。
このアンチエントロピーという言葉がデータベース、分散システムの世界においてどういうことかというと、
分散システムのノードごとに持っているクラスターのメタデータ情報というものがバラバラになってしまうと、
いわゆるエントロピーが高いという状態になりますね。
今回のアンチエントロピーという、今回の章で扱うこのアンチエントロピーというのは、
そんなカオスな無秩序な乱雑なバラバラな情報を揃えてシステム全体のエントロピーを保つ、
つまりシステム全体の秩序を保つための仕組みということを指しています。
難しそうに聞こえるかもしれませんが、身近な例とかアナロジーで言うと要するに、
データベースの分散システムのノードごとに持っている情報を揃えるためにはどういったアルゴリズムやデータ構造が必要かということを紹介しているのがこの章になっています。
なので今回の章の目玉というか、読む目的としては、
大規模な分散システムにおいてシステム全体の健全性とかヘルシネスを保つために必要不可欠なメタデータ、
例えばノードのメンバーシップリストの情報とかクラスター全体がヘルスかどうかみたいな状態とかを効率的にクラスターにいるノード全体に伝播させる仕組みというのを理解することです。
まず軽く前回の振り返り収録のおさらいからいこうと思います。
チャプター12の前、チャプター11ではレプリケーション、複製とコンシスタンシー、整合性について学びましたね。
データを複数のノードに複製していく際の動き方と複製をすることによって生まれる整合性を考えなきゃいけないという話がありました。
そこでのキーワードとしてはキャップ定理だったりとか様々なコンシスタンシーモデル、整合性レベルについて深く掘り下げてきました。
これまでは主に複製するデータの整合性に焦点を当てていましたが、
今回のチャプター12ではクラスター全体の健全性を保つために必要不可欠なメタデータの配信というシステム全体の土台を支える重要な問題に取り組んでいきます。
ここで大きくカテゴリーで分けると3つのアルゴリズムが分離されています。
ブロードキャストとアンチエントロピーとゴシップ。
この3つを本書の振り返りに深掘りする前に簡単にブロードキャストとアンチエントロピーとゴシップの違いは何かというのをまたここでアナロジーで導入してみようと思います。
今回は会社の組織変更とか新入社員が入社したみたいな情報とかそういったその人事情報を社内の全社員に伝達するためにはどのようなアルゴリズムが必要かというアナロジーで紹介していこうと思います。
まず一番シンプルなアプローチとしてはHRを担当している人事部から全社員に一斉にメールを送ることですね。
これがいわゆるブロードキャスト方式に相当します。
社員が10人いたら10人メールを送ればいいし社員が1000人いたら1000通のメールを送ればいいわけですよね。
これはスラックだったらスラックのノーティフィケーションでもいいかもしれません。
でももしこれが例えば10万人の大企業だったりしたら一斉に10万人にメールを送るとメールサーバーがパンクしてしまうかもしれませんし10万人全員しっかり確認しているかどうかというのはわからないですよね。
10万人にメールを送ったかもしれないけど一部の人には届いてないかもしれないし一部の人は内容を理解していないかもしれない。
届けたい情報が100%届けられないかもしれない。
これが分散システムでいう通信コストの問題であったりちゃんときちんと受け取ったかみたいな悪のレジの問題だったりしますね。
じゃあここでその人事情報を伝えるためにどのような補完手段が取れるかというと
ここでちょっと賢い会社ならヒエラルキーを持ち込みますね。
部長、課長、係長、一般社員みたいな感じで回送コートを使って情報を伝達しています。
これは効率的ですけれども途中で伝言ゲームみたいな形なので誰かが伝達を忘れたりとか内容を間違って伝えると
組織の一部だけが古い情報とか誤った情報のままになってしまいますね。
もしくは席に座っている隣の人に教えてもらって自分も隣の人に教えるみたいな口コミ方式もありますけれども
これも似たような感じで情報がバラバラになってしまう可能性がありますよね。
今回のチャプター12で学ぶアンチエントロピーというのはまさにこの情報がバラバラになってしまった状態、
エントロピーが高い状態を元に戻すアンチエントロピーのための仕組みなんですね。
この3つ目のゴシップ、ゴシッププロトコルというのも紹介されていますが
これはこのアナロジーでいうとどういうイメージになるのかですけれども
ゴシップというのは噂話という意味なんですね。
なのでこれは逆にアナロジーの中で一番わかりやすいと思います。
ゴシッププロトコルはまさに噂話が広まっていくように情報が伝わっていく感じですね。
例えば会社の給頭室とか休憩室みたいなところとかランチタイムに同僚の間で
新しい部署ができるらしいよとか、あそこのチームに新しい人が入ってくるらしいよみたいな噂話が自然と広がっていく様子ですね。
誰かが新しい情報を得ると近くの同僚に伝えて、その同僚もまた別の同僚に伝えていくという形で
本当に噂話が広まっていくようにクラスターの中でメタデータを広げていくというのがゴシッププロトコルになっています。
なので最初は一部の人しか知らなかったメタデータもしくは情報が時間とともに会社全体にぶわーっと広がっていくというのが
まさにゴシッププロトコルのイメージになると思います。
このゴシップ方法の面白いところはですね、特定の誰かが全員に伝える責任を持つわけではないんですね。
もちろん噂話好きな人みたいなよくみんなとコミュニケーションするホットノードみたいなのはいるんですけれども
その責任ではないわけですね。
このコーディネーターとかリーダーとかブロードキャスターがいるわけではなくて
みんなが情報を広め合うという責任を分散して担保するということになります。
みんなが少しずつ情報を広め合うことで最終的に全員が最新情報を知ることができるかもしれないという点です。
かもしれないというのはこれは噂話を想像してもらうとわかるかもしれないんですけれども
同じ人から同じ情報を何回も聞くことがあるかもしれませんね。
例えばランチに行った時に同僚から新しいチームができるらしいよ、利用具があるらしいよと聞いて
席に戻ったらまた別の同僚からいやいやこういう話聞いたんだけどさって
いやそれさっきランチで別の同僚から聞いたよみたいな重複された情報が入ってくる可能性があります。
これはゴシッププロトコルでも当てはまりますね。
デプリケーティッドメッセージが同じ状態で何回も重複されていくということで
その重複率というのもゴシッププロトコルを運用する際には重要なメトロクスになってきます。
というのも重複が多ければ多いほどそれはその非効率な情報分散をしているということになりますよね。
それが逆にその伝え漏れを防ぐ仕組みにもなっているんですけれども
分散システムではこういった噂話ネットワークのようなゴシッププロトコルというのがあります。
この一つそれぞれのアルゴリズムについて詳しく紹介しているのが第12章になっていきます。
ということで詳しく内容を振り返っていきましょう。
本章ではまずアンチエントロピーについて紹介されていました。
分散システムにおけるアンチエントロピーアルゴリズムの3つの主要なクリティカルな概念、
手法について紹介されていましたね。
雑にまとめるとまず3つのアルゴリズムがあります。
1つ目がRead Repair 修復アルゴリズム。
2つ目がDigest Reads これは検知のためのアルゴリズムですね。
3つ目がHinted Handoff これは予防プレベンションのためのメカニズムです。
どういうことかというとエントロピーな状態つまりカオスな状態があったときに
Read Repair というのをカオスな状態をエントロピーな状態をアンチエントロピックな状態に戻す
Resolution する修復のアルゴリズムで
Digest Read というのはそのアンチエントロピーかどうか
つまりそのみんなが持っているノードが持っている情報が違っているかどうか
すなわちカオスな状態かどうかを検知するアルゴリズムディテクションですね。
Hinted Handoff というのはそもそもエントロピーな状態にならないように
予防するプレベントするためのメカニズムかなと僕は理解しています。
これらを支える効率的なデータストラクチャーとして
Merkle Tree
日本語だとマルクルツリーと言われたりするのかな?
Git とかビットコインとかでも出てくるんですけど
Merkle Tree と Bitmap Version Vector っていう2つのデータ構造も合わせて紹介されていました。
この3つのアルゴリズムと2つのデータ構造についても簡単に触れようと思います。
まず Read Repair これが修復のアルゴリズムでしたと。
これはデータを他のノードから読むタイミングで
ノードの持っている情報データメタデータの間に
処遇がないかを確認して
必要があれば実際に修正しましょうという仕組みですね。
考え方というかやっていることとは知ってはシンプルですね。
処遇があったら直しましょうと。
ただそれを言っているだけっちゃだけなんですけれども