1. London Tech Talk
  2. 【Bookclub 第四弾】 "Databas..
2025-10-04 39:21

【Bookclub 第四弾】 "Database Internals" #12 振り返り

spotify apple_podcasts
ken
ken
Host

London Tech Talk 名物 Bookclub 第四弾 "Database Internals" 第十二章の振り返り収録です。"Anti-Entropy and Dissemination" の内容について振り返りました。
まずは大規模な分散システムにおけるメタデータ配信の課題について紹介しました。会社の組織変更情報を全社員に伝達する状況をアナロジーとして、ブロードキャスト方式の通信コスト問題や、階層構造による情報伝達の効率性と課題について説明しました。
続いて、Anti-entropyアルゴリズムの3つの主要コンポーネントを詳しく解説しました。Read Repair(修復アルゴリズム)では図書館の司書さんによる蔵書情報照会の例を用いて、データを読む時の「ついでに修復」という仕組みを説明しました。Digest Reads(検知アルゴリズム)では、全データではなくハッシュ化されたダイジェストのみを送って効率的に差分を検知する方法を紹介しました。Hinted Handoffs(予防機能)については、学校の宿題預かりシステムをアナロジーとして使用し、故障したノードの代わりに他のノードが一時的にデータを預かる仕組みについて説明しました。重要なのは「権限の引き継ぎ」ではなく「一時的な荷物預かり所」であるという点も強調しました。
また、効率的なデータ構造として Merkle Tree と Bitmap Version Vector について触れました。Merkle Tree はブロックチェーンでも使われる階層的なハッシュ構造による差分検知技術として、Bitmap Version Vector はビット演算(XOR)を使った更新追跡の仕組みとして紹介しました。
さらに、Gossip Protocol について説明しました。疫病や噂話が集団の中で拡散される様子をアナロジーとして、情報がネットワーク全体に「感染」のように広がる仕組みと、そのスケーラビリティの利点や重複メッセージのオーバーヘッドという課題について触れました。Plumtree(Hybrid Gossip)と HyPerView(Hybrid Partial View)についても簡単に触れました。
その他 Bookclub で盛り上がった観点や、次回の Chapter 13 の予定について触れました。
ご意見・ご感想など、お便りはこちらの⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠Google Form⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ で募集しています。

サマリー

今回のエピソードでは、分散システムにおけるアンチエントロピーとメタデータ配信の重要性が深掘りされています。特に、エントロピーの概念を用いて、システム全体の秩序を保つためのアルゴリズムやデータ構造が紹介されています。「Database Internals」のエピソードでは、データの整合性を保つためのアルゴリズム、特にRead RepairやHinted Handoffが詳細に説明されています。この中で、ダイジェストリードの効率化やMercury Treeというデータ構造の利点が取り上げられ、データベースの運用における重要な考え方が示されています。このエピソードでは、データベースの内部構造に関する「Database Internals」が説明され、特にメルクルツリーとゴシッププロトコルの効率的なデータ管理手法に焦点が当てられています。チェックサムによる変更検出や、分散システムにおけるデータ伝播の仕組みが明らかにされています。また、今回のエピソードでは、データベースの効率的な情報配信と障害時の対処に関する方法論、特にスパニングツリーやハイパービューなどの概念が紹介されています。大規模分散システムにおけるメタデータの伝搬や、それに伴う課題についても触れられています。

アンチエントロピーの基礎
リスナーの皆さん、こんにちは。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 これが修復のアルゴリズムでしたと。
これはデータを他のノードから読むタイミングで
ノードの持っている情報データメタデータの間に
処遇がないかを確認して
必要があれば実際に修正しましょうという仕組みですね。
考え方というかやっていることとは知ってはシンプルですね。
処遇があったら直しましょうと。
ただそれを言っているだけっちゃだけなんですけれども
データ整合性のアルゴリズム
例えばコーディネーターみたいなのが複数のレプリカに問い合わせて
返答結果を比較しますと
自分の近くにいる人の10人から同じクエスチョンを投げて
10の結果が返ってきたと。
1人目は1,2,3って返してきたけど
2人目は1,2,5って返してきたと。
そしたらこれは1人目と2人目のノードの間で
別のデータを持っていると不正語を発見するわけですね。
そしたら Read Repair としては最新のタイムスタンプとか
コンフリクト解決ルール、コンフリクトリソリューションの
クラスターによって決めた
どうやってコンフリクトがあったときに解決するか
どっちをオーバーライドするのか
マージするのか色々あるんですけれども
それに沿って正しい値で統一して
じゃあ結果としては1,2,3が正しいので
みんな1,2,3に直してねというリプライを送ると。
要するにやっていることとしては
データを集めて、処遇があったら
事前に決められたアルゴリズムで正しい値を決めて
みんなに直すように言うという
ついでに修復みたいな感じですかね。
発想としてはシンプルです。
このときにデータを
データ間に処遇がないかを確認しますよね。
効率化の手法
これをどうするかというのが次の問題になってきます。
例えばメタデータなので
例えばメンバーリストだったら
IPのストリングのリストだったりするんですけど
それをクラスターの中にいるノードが増えてきたりとか
そもそも差分検知するためのデータが大きくなってくると
毎回全てのデータを送受信して比較するというのは
ネットワークコストが加算できますし
コンピュテーショナルコストも加算できますよね。
そこでこの差分を検知するというアルゴリズムを
ちょっと効率化できないかなというふうに
考え始めたと。
そこで登場するのがダイジェストリードです。
これの考え方は
知識として入れればすごいシンプルで
全てのデータを送りあって
バイナリーを全て正しいかどうかを
比較するのではなくて
比較したいデータを発出しちゃって
チェックサムとかをゲットしちゃうということですね。
シャアとか。
発出化されたダイジェストだけを送りあって
変更を検知するということですね。
これはディスクのチェックサムとかネットワークとかでも
よく使われるアルゴリズムですけれども
何かこう
例えばインターネットからソフトウェアをダウンロードするときに
ダウンロードするバイナリと一緒に
それのチェックサムをダウンロードして
それを自分の手元でもチェックサムを計算して
チェックサム同士を比較することで
自分が今からインストールしようとしている
バイナリが改ざんされてないかどうかを
チェックしたりとかそういうときに使われますけれども
発想としてはシンプルですよね。
全てのデータを送りあって比較するのではなくて
チェックサムだけを送り合うと。
これはほとんどの場合
データは一緒なので大抵のケースでは
チェックサムを送って違いがないことを
確認するだけでいいという前提に立っています。
ダイジェストリードと行儀良しく言ってますけど
要するにチェックサムしましょうという
ただそれだけっちゃそれだけなんですけれども
それを踏まえた上で
この3つ目にヒンキッドハンドオフというのが出てきます。
データ構造の紹介
これはちょっと面白いので
詳しく説明しようかなと思います。
これはプリベンション
予防のメカニズムでしたと。
実際の運用をイメージしてもらうと
ノードがダウンすることってよくあるんですね。
クラスターの中でのノードAがダウンしていたり
ディスクの障害とかネットワークの障害で
一時的にダウンしていると。
このヒンキッドハンドオフは
ノードがダウンしていたときに
エントロピックの状態にならないように
なるべく予防するためのアルゴリズムです。
このヒンキッドハンドオフって書いてますが
これはヒント
ブックマークとか
カタカナのヒントを
渡し合うということなんです。
これがどういうことかというと
これは
メタデータをレプリカノードに書き込もうとしたときに
ノードが故障していたときに
他の別の動いているノードに
ヒントをとりあえず渡しといて
もともと故障しているノードが
戻ってきたときに
そのヒントを戻して
何をしたらいいかが
わかるという
要するに
ノードが故障していたら
そのノードには何もデータを
情報を伝えられないですよね。
その近くにいる別の友達とか
近所のノードに
故障しているノードに
本来伝えたかった情報を
渡しといて
その故障していたノードが
戻ってきたら教えておいてね
みたいな
渡す感じですね。
これは
ブッククラブの読書ノードにも
書いたアナロジーなんですけれども
学校の宿題で例えると
わかりやすいかなと思います。
ここで
風邪で休んでいる生徒と
そのお友達の
太郎くんみたいなのがいるとして
太郎くんが
お友達で
風邪で休んでいる
花子ちゃんという
ケースだと思うんですけど
花子ちゃんが風邪で休んでしまった
そんな時に
宿題を先生は
出したわけですね。
みんなこの宿題を来週までやってくるように
ということで、その宿題のプリントを
渡されたんですけども
誰かがその宿題のプリントを
花子ちゃんに渡さなきゃいけないということで
太郎くんがその役を勝手に
出ましたと。
ここで言うヒントは
先生が渡した
宿題プリントみたいな感じですね。
で、太郎くんは
花子ちゃんの
宿題プリントをもらって
宿題プリントを
預けて
それを渡しに
行くわけですね。
花子ちゃんは風邪が治ったらつまり
濃度の故障から
修復したら
自分の宿題をやって
先生に渡すっていうこと
なんですけども
ここで重要なのはですね
宿題のプリントを
渡すだけであって
宿題自体はあくまで花子ちゃんが
やるってことなんですね。
太郎くんが気を利かせて
花子ちゃんの宿題プリントをやってしまったら
花子ちゃんの
花子ちゃんにとっては
良くないことなんですけども
どういうことかって言うと
ヒントはなぜ
ヒントって言ってるかって言うとあくまでヒントなんですね。
例えば元々の濃度の
が例えばライターとか
何かしら
役割がクラスターの中で役割があったときに
他の
ここで言うと太郎くんみたいな
濃度にその役割を
異常するわけではないんですね。
元々の
その濃度がバックアップ
されたときに
何をしたらいいか。例えばこの
こういうデータを回したらいいのか
とかこういう差分検証したら
いいのかみたいなやることを
やることリストみたいなのを渡しておくだけ
なんですね。やる
実際にそれをやる権限を異常する
わけではないと。なので
宿題リストは上げるけど
宿題を実際にやるのは
本来の故障した濃度が戻ってきてから
ということなんですね。
これはそのデータの所有権とは
常に本来の持ち主である
花子ちゃん、花子濃度のものなんですね。
他の子の
宿題をやりたい学生なんていないので
ということで
これはどういうことかと言うと
故障した濃度がいましたと
この故障した濃度に
クラスター全体の
健全性を保つためには
やらなきゃいけないことが
あったと。でも一時的に
故障してしまったと。なので
そのやらなきゃいけないことみたいなヒントを
他の濃度に一旦預けておいて
クラスター全体としては
動きを続けると。
元々の故障された濃度が戻ったときに
そのHinted Handoff
つまりそのヒントに書かれたものを
ちゃんと実行することによって
クラスター全体の健全性が元に
戻る。元に戻ることによって
そのアンチエントロピックな
状態になりづらくなるという
ロジックになっています。
ここ三つ目Hinted Handoffは
個人的には理解がちょっと
難しかったんですけれども、こんなことかなと
アナロジーを使って
理解しようと試みましたと。
これらのアルゴリズムを
サポートするために二つの
重要なデータ構造が紹介されて
いました。
まず一つ目がMercury Tree
ですね。これはその効率的な
差分検知を支えるデータ構造として
有名です。個人的にも
好きなデータ構造の一つでして
ブロックチェーンとか
Gitとかでも使われているんですけれども
これは
ツリー構造でして
ツリー構造を
イメージすると
マルートノードがあって
リフノードがあって
一番下のルーフ
データノードがある
みたいな感じなんですけど
各機構造のノードに
入れるデータというのは
下のチルドレンノードたちの
ハッシュなんですね。
これどういうことかというと
Mercury Treeの実際に
保存されているデータというのは
さっき言ったハッシュなんです。
チェックサム。
この二つの
機構造を
比較したいみたいな時に
リーフノードが
実際のデータのハッシュで
間の
インターミディエットノードか
ちょっと用語ぐちゃぐちゃになってしまいましたけど
中間ノードと
根っこのルートノードが
あった時に
二つのデータが
そこがないか
っていう風に
計算する時に
機構造の上から
ハッシュを計算してる感じなんですね。
なぜこれが
メルクルツリーの構造と効率
有効的かというと
ポッドキャストで音声で伝えるのが
ちょっと難しいんですけど
リーフノードにあったデータが
更新されてたら
そのリーフノードの上にある
中間ノードのチェックサムは
異なるんですよね。
この
中間ノードのチェックサムが異なる
ということは
さらにその中間ノードの
親ノードのチェックサムは異なってくるんですよね。
なぜかというと
親ノードは下の子ノードの
チェックサムを
元に計算されたものなので。
そこの親ノードの
チェックサムが
違うということはさらにその親ノードのチェックサムが
違うと。こういう風に
最期的にチェックサムが変わっていって
しまうわけですね。なので
リーフノードのデータが
変更されたときは
そのリーフノードを含んでいる
親ノードのチェックサムが
全て変わってしまうと。
これがどういうことかというと
2つのノードがあったときに
一部のデータでも変更されてしまうと
ルートノードのチェックサムが
違うんですね。
なので
ルートノードのチェックサムを
比較するだけで
変更があったかどうかが
一瞬で分かると。
一瞬で分かるし
どこのデータノードで
変更があったかというのを
気構造をたどっていくことで
特定できるわけですね。
というのもその気構造になっているので
例えば一部のデータノードだけ
例えば気構造の左側の
一番左のデータノードだけが
変更されていたら
気構造の
右側の右半分のチェックサム
というのは同じなんですね。
だからチェックサムが同じなので
下のデータノードまで見に行かなくていいと。
ただ、左側の
気構造のチェックサムというのは
違っているので
ルートノードからどんどん左側に降りていく
ですね。そのチェックサムが違う
データノードを
中間ノードに降りていくことで
最終的にどこのデータが更新されたか
という変更箇所も
特定できると。つまりそのメルクルツリー
というのは
2つの別々の
データを検知するときに
計算コストも
チェックサムというかハッシュを
計算することによって効率化していますし
かつ
気構造で表現することによって
どこのデータが更新されたかを
効率的に特定できる
というかなり
個人的にはすごいイケてる
データ構造かなと思っています。
ゴシッププロトコルの仕組み
これは
Gitとかで例えばディレクトリの構造を
気構造でも
表現しますけれども
どこのディレクトリに変更があったか
みたいなときとかに
親ディレクトリのチェックサムだけ
比べればそこに
変更があったかどうかが分かるわけですよね。
これは非常に
意味がなっているかなと思います。
もう一つ
ビットマップバージョンベクターという
仕組みも紹介されていまして
これも
2つ目のなかなかスマートな
データ構造だと思っていますが
これはですね
更新があるかどうかを
バイナリ0か1で
表現します。
更新があるかどうかと言いましたけど
データはたくさんありますよね。例えば
メタデータが100個あったときに
それぞれのデータに
更新があったかどうかを
0か1で表現しますと。
データが100個あったら
100の
長さのバイナリになりますね。
0か1と。更新が
あったら1。更新がなかったら0。
みたいなバイナリで表現するんですけども
ここで優れているのは
この2つの
ノードの中で更新があったかどうかを
ノードAとノードBで
比較するときに2つの
長さが100の
バイナリの列がきますよね。
これを
XOR演算で
比較しちゃうというところが
効率的なアプローチですと。
XORというのは
バイナリの演算で
データが異なっているときにのみ
位置を返すってやつですね。
例えば
0と0だったら0が返ってきて
1と1だったら
0が返ってくる。つまり
同じ状態だったら
0が返ってくるんですけど
0と1もしくは1と0だったら
1が返ってくるってことなんですね。
どういうことかというと
このデータ更新されたかどうか
みたいなバイナリ列が2つあったときに
XORで
結果を出すと
ノードAとノードBの
更新イベントの処理の
そごごあるところだけが
バイナリの位置として表現されるんですね。
だから
どこの更新イベントに
差分があるのかっていうのを
小コストで計算できる
優れ者のデータ構造となっているんですね。
これは
更新イベントの数が多ければ多いほど
効率的になります。
例えば更新イベントが500個あったときに
そこで10個ぐらい
更新イベントに差分があったときに
ノードAとノードBの
更新イベントリストを全部そうなめして
1個1個比較するのではなくて
XORでパッと取っちゃって
どこの箇所で
変更があったかっていうのがわかるという
ビットエンザンの
威力と言いますか
ビットエンザンを賢く使った
ベクターの
データ構造となっています。
さてこれらを踏まえた上で
アンチエントロビーの
さらなるアルゴリズムとして
ゴシッププロトコルについて
移っていこうかなと思います。
ゴシッププロトコルは
冒頭でもちらっと言ったんですけど
個人的には非常に興味深い
アルゴリズムだと思っていまして
あたかも
疫病とか
噂話というのが
人間の集団の中で
拡散されていくようにデータを
伝播させていく仕組みなんですね。
コンピューターのグループがまるで
人間と同じように情報を伝播させていく
というその擬人化された様子が
個人的には想像して
ドキドキしてくるんですけれども
分散システムでは
各ノードが定期的にランダムに選んだ
他のノードに対して自分が持っている情報を
送信しますと
風邪で言うなら
くしゃみをしてウイルスをつす
みたいな感じで噂話だったら
噂話をするみたいな感じですね。
受け取ったノードも同じように
別にランダムに選んだ
ノードに
情報を伝播していきますと
情報がネットワーク
全体に感染のように広がっていく
んですね。ゴシッププロトコルの
大きな利点は何かというと
ブロードキャストとか
アンチエントロピーと比べて
一番の利点はスケーラビリティなんですね。
というのもその単一の
ブロードキャストだったら単一のノードが
全てのノードにブロードキャストし
なくてはいけないので
単一のノードの
シングルポイントフェア
単一障害点になってしまいますし
ネットワークコストも加算で
しまいますと。
前述のアンチエントロピーアルゴリズムとも
異なって特定のノードが
単一障害点になることがないので
全ての分散された
ノード一つ一つが小さな
レスポンシビリティを持って頑張っている
というかデータを拡散している。
なのでノードが故障しても
他のノードが情報の伝播を継続
するために対障害性が最も
高いと理論的には言われていますと。
ただし
もちろんこのゴシッププロトコルにも
欠点があって
仕組み上
さっきのHR
情報が会社で伝播されていく
噂話で伝播していく
アナロジーでも紹介しましたが
同じメッセージが複数のルートを
通って重複して伝送されて
しまうこともあるんですね。
なのでこの重複メッセージのオーバーヘッドというのは
一つ重要なメトリックス
ですし重複が
多ければ多いほどネットワーク帯域を
無駄に消費する場合があります。
ですし
全ての情報に
ノードに情報が確実に
届くかどうかというのは
確率的な問題になって
決まりますし
全てのノードに情報が届くまでの
時間というのも
ブロードキャスト方式に比べては長くなる傾向になります。
なのでここはビジネス要件と
合わせてどのアルゴリズムを
選ぶかという話であって
かつブロードキャストの方が
イメージしやすい
イメージしやすいということは実装も
基本的にはシンプルなんですね。
ゴシッププロトコルを実装するよりは
ブロードキャスト一つのノードが
事前に決められた100のノードに
同じ情報をピングで送る
という方が実装は簡単ですよね。
なのでここはなかなか
トレードオフかなと思っています。
今述べた
ハイブリッドアプローチの導入
ゴシッププロトコルの課題を
解決するために
ハイブリッドアプローチがいくつか
考えられました。
これも簡単に本章で紹介されていまして
例えば
プラムツリー
Plumbing Reliable Multicast Tree
というのが
ハイブリッドゴシップとして紹介されていました。
このプラムツリー
というのはベースとしては
ゴシッププロトコルとしての動きを保ちつつ
スパニングツリー
というツリー構造を
ある程度の構造化されたメタデータ
みたいな感じで与えることで
重複メッセージのオーバーヘッドを
軽減させようとした妥協案といいますか
改善案ですね。
ここでちょっと寄り道しますが
スパニングツリーというのは
ネットワーク上の全ノードを
循環、ループがないように
機構造で表現した
データ構造です。
イメージとしては
森の中にある
複数のキャンピングサイト
情報配信の最適化
とか複数の小屋みたいなのを
最小限の道
エッジだけで行き来できるように
した地図みたいなものですね。
キャンプサイトとか広い公園とかに行くと
ちょっと観測された地図が
あったりするんですけども
一つの小屋から一つの小屋、
一つのキャンピングサイトから別のキャンピングサイトに
行こうと思えばいろんなルートがある
ですけども最小限の
行きやすい、人間が通りやすい道だけを
表現した地図というのがいわゆる
スパニングツリーみたいな感じになります。
これによって同じ情報が
複数経路で何度も
届くことをスパニングツリーを
メタデータとして持つことで
防ぐことができるんですね。
ただし
このスパニングツリーの
機構造の一部がノードの故障とか
ネットワーク障害によって壊れてしまうと
例えば今の例でいうと
とあるキャンピングサイトから
とあるキャンピングサイトに行くまでに
川を通らなきゃいけなかったんだけど
昨晩の雨によって
川がちょっと氾濫しちゃって
橋を通れなくなっちゃった
みたいな時っていうのは
もともとのスパニングツリーのマップ
に沿って行ったら
川を渡れないので
そこからそこの経路は
実質機能してないですよね。
こういった時に
プラムツリーでは
普通ベースとしてはスパニングツリーという
地図みたいなものを使って
効率的に配信しつつ
障害発生時にはゴシップ
プロトコルを使って対障害性を確保する
というハイブリッドなアプローチを
とっていますと。この場合だったら
キャンピングサイトの他の
キャンプしている家族同士で
昨日氾濫があってここの道通れなくなったらしいから
こっちの道を通った方がいいよ
みたいな感じで
情報を与え合う感じですかね。
ここら辺
話しながら思いついた感じで
全部アナロジーで喋っているので
間違っているところとか
端折っているところとかも
あるかもしれないんですけど
そんな感じかなと思います。
これによって正常時は
効率的でありながら
障害時には
対障害性を発揮するという
いいとこ取りを目指した仕組みになっています。
あとはもう一つ
ハイパービュー
ハイブリッドパーシャルビューという
も紹介されていまして
これはちょっと
自分もまだ勉強中なので
軽く触れるだけにしたいんですけども
これは
これも
ハイブリッドなアプローチの
一つですと
これは大規模なクラスターにおいて
全てのノードが
全ての状態を常に記録しておくというのは
現実的にはないんですね。
ここで言っている情報というのは
クラスターの状態ですと
クラスターというのは
ノードが今まで100とかで言っていましたけど
5000台とかあったときに
5000台のIPリストを全てのノードが持っておく
というのは現実的ではないと
しかも5000台のIPリスト
みたいなのを送り合うのも
現実的ではないですし
それを仮にメモリに持っておくとしたら
ノードのメモリ使用量が
膨大になっていきますし
ネットワークも発泊していくし
差分検知もどんどん
効率的なデータコードを
持っているとはいえ難しくなってきますよね
ここで
ハイプリッドパーシャルビュー
ハイパービューの考え方としては
各ノードがパーシャルビュー
部分的なビューですね
つまりそのクラスター全体の状態の
限定的な情報のみを
保持する感じですと
これを使うことによって
各ノードが
色を分けるわけなんですけども
アクティブビューとパッシブビューと言われて
頻繁に通信する
近しいノードと
知ってはいるが普段は通信しないノード
みたいな二層構造に分けておいて
基本的には普段アクティブビューに
頻繁にやり取りするんですけども
時々パッシブビューにも
連絡をしてスナップショットを
更新しつつ
メモリ使用量を抑えながらも
ある程度そこそこネットワーク全体の
健全性が動くように
維持するというこれもいいとこ取りを
目指した理論になっている
と思います
これについてはこれ以上の言及は
避けようかなと思いますが
今後もキャッチアップしていきたい
ところではあるかなと思います
今回は
次のステップへの準備
ブッククラブの
振り返りとしては
ノースアメリカとAPAC会の
会でしたので
僕は直接
参加はできなかったのですが
いつものように
内容ばかりで盛り上がったかなと思います
ということで
チャプター12ですけれども
いかがだったでしょうか
これを踏まえた上で
あとは残り2つ
チャプター残り2つになってきました
次はチャプター13
ディストリビューティー
トランザクションにいよいよ
入っていきますトランザクションですね
キーワードとしては
2層コミット
2フェーズコミット2PCとか
3フェーズコミット
3PC
あとはSAGAという
テクニックというか
フレームワークも出てきたりとか
分散トランザクションの話が出てきますね
トランザクションというのは
分散システムにおける
かなり野心的というか
挑戦的な問題の一つでもあるので
複数ノードにまたがる
トランザクションをどう処理したらいいか
それは現場で
どういうフレームワークとかテクニックがあるのか
について学んでいきます
今回学んだアンチエントロピーの仕組みが
どのように分散トランザクションの文脈で
活用されるのかというのをイメージしながら
読むのも面白いかなと思います
はい
ということで
もうそろそろデータベースインターナルズ
終わりに近づいてきたんですけれども
今まで一緒に
収録だけを聞いてキャッチアップしているという方も
一緒に本を読んでいるという方も
ブッククラブに参加している方も
あと一歩ですね
一緒に頑張りましょう
では振り返りは以上にしようと思います
今回は
チャプター12
アンティエントロピー&ディセミネーションについて
振り返りました
大規模分散システムにおける
メタデータ配信の話でしたね
ということで
では次はチャプター13の振り返り収録で
お会いしましょう
それでは皆さんHave a nice day
39:21

コメント

スクロール