#471 DBのレプリケーションから組織の動かし方が学べるって知ってる？

ひまじんプログラマーからお知らせです。6月24日水曜日19時から、東京都汐留にあるスリーシェイクさんのオフィスで、「AI時代、エンジニアの価値はどう変わったのか。ひまプロが語るエンジニアの生存戦略」というイベントに出演します。

イベントでは、のりとかいちが登壇するパネルディスカッションに加え、LT会、懇親会を実施します。AI時代のエンジニアの働き方について情報収集したい人や、一緒にわいわいしたい人はコンパスでカタカナの「リプラス」と検索してご参加ください。

この番組は、「エンジニアの成長は楽しい学びから」をモットーに、昨日より少し成長できる学びをわいわいお届けするエンタメ系テックラジオです。

はい。

今日も頑張っていきましょう。

えーと、ま、最近仕事をしていてというか、まあ仕事をしていてずっと思ってるのがですね。

はい。今日の晩ご飯何かなって。

はーい、くじもです。はーい。

はーい、くじもです。

これは。これは。えー。

ちょっと、斬新すぎたな。

えー。

いや、のり突っ込みみたいなね。はーいじゃないですけどね。

これはすごい。

はい。

いや、結構あの、のりさんがよく言う、かいちさんのあの、なん、なんか、なんとかかんとかだよ、いや違うかみたいな、あの、のりさんのお気に入りのやつあるじゃないですか。

あのー、なんだっけ、あのー、ユニテツのやつね。

あ、はい。結構それに次ぐやつな気がしますね。

よかったー、名作できましたね、じゃあ。

はい。はい。

えーと、なんの話だっけ。あー、仕事をしてて大事なことですよ。

はい。はい。

えーと、組織内の情報共有と合意形成めっちゃ大事だと思うんすよね。

なんかかっこいい。

情報共有と合意形成？

そう。なんか会社とかで動くにあたってもですね、やっぱり自分1人の力じゃ動かせるものが限られてますと。

うん。

えー、なので、ま、人間ってね、支え合って、えー、物事を前に進めていくんでね。

うん。うん。

まあ情報共有とか合意形成とか、まあめっちゃ大事なんですけど。

うんうんうん。

まあエンジニアってこの辺苦手な人多いんじゃないかなと思って。

うーん。

えー。

苦手かも。

情報共有と合意形成のやり方をですね。

うん。

えー、データベースのレプリケーションから学ぼうという話です。

可能か。おー、可能かそれ。

いや、データベースのね、レプリケーションってね、情報共有と合意形成なんすよ、結局。

あ、まさか？分散データベースか、これ。

まさか？分散データベースか、これ。

まあ分散データベースなんすけど、まあその中のまあ一部、レプリケーションの話をちょっと今日はしようかなと思います。

ほー。

うん。

で、えー、まあ例によって例のごとく、データ思考アプリケーションデザインっていう分厚い本の、えー、第5章だったかな。

おー。

が、レプリケーションの話になってるんですけど。

うんうん。

まあそこからちょっと、レプリケーションってこういう種類があるよとか、まあこういうメリデメあるよとか。

うん。

まあだから、まあ我々は情報共有と合意形成こうやってやっていこうかみたいな。

うんうんうん。

ところをちょっとわいわいしながらお話していければなと思います。

まさかのハードスキルだった。

ハードスキルです。やっぱね、エンジニアに伝えるんだったらね、こういうハードから、ハードから攻めたほうが伝わりやすいかなと思って。

あるよね。

はい。で、ちょっと前提を揃えたいんですけど。

はい。

じゅ、順平にデータベースのレプリケーションってどんなのって言ったら、なんかどんなイメージあります？

うわ、これ。

何をやるやつ？

でもデータの、まあ複製というか。

うん。

いう系統で。

うーん。

まあど、どういう視点になるんだろう。しょ、障害対策とか。

うんうんうんうん。

そういう話なんですかね？それだけでもないですか？

そうそうそうそうそう。

はい。

ま、それだけではないけど、まあ合ってる合ってる。

うんうん。

そのレプリケーションって順平がさっき言ってくれたように、えー、データを複製しておく仕組みになるんですけど。

うん。

で、これなんでじゃあデータを複製しとくかっていうところには、まあいくつか理由があるんですけど。

うん。

え、1つがさっき順平が言ってた、えー、データがなくならない。

うん。

なんか障害とかで、ま、データベースの、ま、ノードが、ま、3つぐらいあったとして、その3つに同じのを複製してたら、ま、1個死んでも2個生きてるから大丈夫。

うん。

っていうのが1つと。で、あとは、えー、CDNとかもそうなんですけど、なんか日本においてアメリカにおいてみたいな、なんか例えばモンストとかそうなってんのかな。わかんないですけど。

うん。

なんかそういう。モンハンとかはなってるかな、さすがに。マリオカートとか。

うん。

なんかそういう、えー、遠い地理的に、地理的に遠いユーザーでも、なんかある程度早く同じようなデータにアクセスできるように。

うん。

地理的に分散させることによって、えー、早いとかありますし。で、あとはもう単純にリクエスト数が多い場合に、そのリクエストの負荷を分散できるみたいな。

うん。

っていうところで、まあ3つ、なんか落ちても消えないとか、えー、パフォーマンス早くするため。

うん。

負荷分散。みたいなのが、まあレプリケーションの主な目的かなというところになりますと。

うん。

うん。ま、なので、なんか比較的規模が大きいサービスを作ろうと思うと、このレプリケーションをして、あ、ん？このレプリケーションしたデータベースを、まあアーキテクチャに組み込むっていうのは、まあ割と現実的な選択肢というか、や、取る、やりがちなこと。

うん。

になりますと。

うんうん。

で、このレプリケーションって、まあいいこといっぱいありそうですと、今の話聞くと。

うん。

まあなんかサーバー代がかかるなあぐらいかもしんないんですけど。

うん。

これまあ運用はちょっと一癖あってですね。

ほう。

まあやっぱりなんか、どっかで変更が走ったらそれをほかの人に伝えなきゃいけないわけじゃないですか。

うん、確かに。

うん。そのなんか伝え続けるっていうところが、まあ途中で失敗しても大丈夫なようになってるのどうだっけとか。

うん。

そもそもなんかデータの書き込みって、えー、その3つノードがあるとしたらその3つ全部にやっていいんだっけとか。

うん。

このへんって、うーんと、自由ではなくて決して。

うん。

なんかある程度型がありますと。なので今日は、なんかレプリケーションって、まあなんとなくコピーを送るものだよねみたいな解像度が、こういうふうな形のレプリケーションあるよねみたいな解像度になって、えー、終わるのを目指して、ここからちょっと組織の話をしていきます。

おお、急に。

すげえ。

おお。

えー、で、おっきくですね、このレプリケーションというか、まあ情報共有の仕組みですね。大きく3種類あります。

はい。

で、1つの、まあ会社を思い浮かべてください。会社の中にある、ある部？

部。

部を思い浮かべてください。

はい。

で、よくある組織の部って、部長が1番上にいて。

うん。

そっからなんかトーナメント表みたいな感じで。

うんうん。

まあツリーか。木構造で課長がぶら下がってて何人か。

うんうん。

で、その下に担当社員がバーっているみたいな。

うん。

うん。で、これがまあよくある会社の部、部の組織構造になってると思います。

はい。

で、この部は、えー、部長がなんか会社の方針を取り入れて、で、その部長がその方針を自分の部下ですね。ちょっと今回ちょっと説明の便宜上、課長も担当もちょっと1列にしてほしいんです。1列というかもう同じくらいにしてほしいんですけど。

うんうん。

まあ要するに部長にいっぱい人が紐づいているような組織があったとして。

部長直下だ。

部長直下。

はい。

えー、ちなみに弊社は部長直下の会社です。

うーん。

うーん。で、まあなんで部長に方針が行って部長がほかの人に伝播する。これが、えー、型1、レプリケーションの型1、シングルリーダーの。リーダーっていうのはあの、読み、読み、読むほうじゃなくて、わしがリーダーじゃあのリーダーね。

あ、そっち？ちょっとデータベースすぎて脳みそが今読むほうになってました。

あ、R、Rになりがちですけど、まあLです。シングルリーダー。

導くものね。

はい、導こう。これがまあシングルリーダーです。

はい。

これはよくある形で、まあ文語、僕が今やってる文語とか、あとはえーとRDSとか、まあ普通にリレーショナルデータベースも多分そうだと思うんですけど、書き込めるのは1ノードだけ。リーダーノードだけで。

うん。

分かりづらいな。えー、マスターって言おうかな。

そのほうが分かりやすいかも。

うん。

今なんて言うんだっけ？マスターとセカンダリ、違うな。プライマリとセカンダリだ。プライマリノード。

うんうんうん。

はい。

書き込むやつプライマリと呼んで、部下をセカンダリって言うんですけど。プライマリに書き込みをして、プライマリはその書き込まれた内容をセカンダリに共有して、で、読み込むときはセカンダリから読み込むみたいなのが、えー、レプリケーションの型その1。

うん。

うん、になります。

1番。

まあなんで。

1番簡単にレプリケーションしやすい方式のイメージっすね。

そうですね。そう。よくある。

うん。うーん。

まあだから会社はですね、担当社員に直接この部の方針これねって言っちゃだめなんすよ。もう部長を通さないといけない。

うんうんうん。

で、その部の外の人は今この、例えばじゃあひま、ひまプロブという部にしましょう。

はい。

いや、ひま部。ひま部という部にしましょう。

窓際族感すごいけど。

うん。ひま部という、えー、部にするんですけど、ひま部の方針を聞くときは部長じゃなくて担当社員に聞いてもいいです。今このひま部の方針ってどうなってんのって聞くのは他とでもいい。

うんうん。

だから同じで普通の会社。

うん。

うんうんうんうん。ですね。で、まあ人であってもデータベースの世界であっても、えーと情報の同期にずれがあることがあります。

うん。

うん。えー、なんて言えば、どういう言い方かっていうと、部長に言ってるけど担当、えー例えばじゃあ順平には伝わってるけど、かいちには伝わってないから、かいちに担当の方針聞くと古い方針が返ってくるみたいな。

うん。

そういうことはあります。この方式。

うんうん。メンバー間でもってこと？

メンバー間でもずれることがあります、はい。で、これちょっと文語とかの話なんですけど、文語とかだと、そのプライマリに書き込みをしたあとに、えー、何個のセカンダリに同期したあとにOK返すかっていうのが設定で選べるんですよ。

うん。

うん。で、この何個のセカンダリに同期したあとに返すかっていう設定の数字によってパフォーマンス全然変わるんすね。まあ当たり前ですけど。

うんうんうん。

これはセカンダリに伝えたあとに返してねってやったら、あのセカンダリに裏側で通信してそれを成功したあとじゃないと返さないんでパフォーマンス落ちるし。

うん。

セカンダリに言わなくていいよだったらめっちゃ早いみたいな。

うんうんうん。

うん。ただその代わりセカンダリに言わないような処理だと、書き込み直後にどっかが落ちた場合にそのデータ消えちゃうリスクあるからね、よろしくっていう。まあそんなリスクをはらんだ、まあ構成にはなりますね。

なるほど。

うん。

あ、じゅう、なんか速さがどれだけ重要かによって変えるみたいなイメージなんすかね？

そうですね。変わるかとかは重要だけど、別になんかプロフィール情報はそんな重要じゃないよねみたいな。

うん、そうそうそう。

はい。で、あとはなんかもう1個ちょっと話しておきたいなっていうのがフェイルオーバーの話ですね。

うん。

まあこれも非常に分かりやすくてですね、まあ部長が病気で倒れちゃいましたと。

おお。

うん。うわ、部長いなくなった。ってなると、えー。

休み？休みですか？

休みじゃない。休みじゃない。

だめ？

すぐさま、すぐさま部下の間で話し合いが行われて。

おお。

1人が部長になります。

ああ、傷病手当てもののやつだ。代理。はいはい。はいはい。

部長代理というかもう部長になります。

あ、なるんだ。

はい。すごい。で、部長になったあとに倒れた部長が帰ってきたらその部長は担当になります。

絶対倒れられねえ。

絶対倒れたくねえ。はい。

あ、まあちょっと正確なこと言うと、まあDBにもいるのかな。すいません。文語とかだと部長返り咲くかもしんない。

うーん。

ああ。

プライオリティっていう、あのー、社員ごとに、えー、パワーが設定されてて。

うんうんうん。

そのパワーが強えやつがプライマリになるんで。

ああ。うーん。

強えやつが入ってきたら入れ替わるわ。

なるほど。

まあちょっとDBのエンジンにもよると思います。

うん。

だから文語は少なくともそうですね。で、ただ、えーっと、これなんか順調にね、部長への引き継ぎができればいいんですけど、えー、2人が同時に俺が部長だっていうことも起きうります。

なんやて。

はい。これちょっと気をつけなきゃいけなくて、まあ設定でどうにでもなるんじゃなるんですけど、さっき言ったあのノードのパワーをちょっといい感じに調整しておくとか。

うん。

とかなのかな、やれることは。あ、まああとは、クラスタの、そうっすね、クラスタの配置とかにもよるのかもしんないですけど。まあなんで、要するにその部長が2人になったら結構現場は混乱するんで、データも。

うん。

えー、どっからレプリケーションすればいいのかみたいなところがまあずれてくるので、このスプリットブレインっていう状態ならしいんですけど。

うん。

部長が2人になるのは。

うん。

まあそれはちょっと注意した上で設計する必要がありますと。で、まあここまでが部長1人の話ですね。

はい。

はい。で、今のそのシングルリーダーの構成はめちゃくちゃ一般的で大体これだと思ってます。

うんうん。

うん。僕は正直これしか知らなかったっす。なのでこっから知らない世界に入ってきます。

ほう。ほう。

えー、次がですね、マルチリーダーと呼ばれる、えー、1つの部だけど部長が2人いる。

うん。

なんか高、高、高部長？

え？

はい。COってことですね。

なんか高CEOみたいななんかあるじゃないですか。なんかその共同。

高ファウンダー。

はい。

高ファウンダー的な？

高ファウンダー的な、そうそうそう。高部長。

高部長。

こう？

でも2人までなんすか？いっぱい置ける？

あ、いやー、複数ある。

うんうん。

複数ある。

うんうんうん。

で、これなんかどうやらなんかGoogleドキュメントみたいなNotionみたいななんかそのクラウド上でなんか共同編集が行われるようなタイプ。

うん。

うん。

本当にスピーディーにデータを同期して、えー、やるみたいなときに使われるアプローチみたいで。

うん。

やっぱこの高部長スタイルだと書き込みのパフォーマンスがすごい上がるみたいです。

まあそこがボトルネックにならなくなるから。

はい。そうです、そうです。書き込みがね、やっぱ増やせるから。

うん。

うんうん。で、まあなので、なんて言うんでしょうね、その、ひ、ひま部に対して、えー、日本、日本本社とアメリカ本社が別々にすごい量の矛盾したこと言ってきても。

うん。

ひま部はちゃんと受け付けて、えー、中身をとにかく書き換えますと。

うんうん。

うん。まあなん、なのでパフォーマンス出るんすけど、一方で想像するとおり、えー、競合が生まれますと。

うん。

競合というか衝突っていうのかな、データの。

うん。

で、この、まあ衝突をどう解決するかみたいなのがまあポイントになってきます。

うん。

うん。で、大概自動で解決されるんですけど、ただ自動で解決するのにもアルゴリズムというか方針っていくつかあって。

うんうんうん。

その自動解決方針もちょっといくつか紹介するんですけど。

はい。

え、1つ目が、えー、後がち。

うん。

えー、なんかLWW、ラストライトウィンズっていうやり方なんですけど。

うん。

データが同時に書き込まれても、まあ最終的に、えー、タイムスタンプ見て新しいほうだけ有効にして古いほう消す。

うーん、分かりやすい。

方式。で、これなんかなん、一見良さそうですけど。

はい。

ただGoogleドキュメントとか思い浮かべると、こうはなってないですよね。

え、多分。

そうなのかな。同じ場所に文字をポーンって書いたら、片方消えないでどっちも残るっすよね。

そうなんだ。

確かに残りそう。

多分Googleドキュメントそうなってるはず。

へえ。なので、なんかすべてのアプリで後がちにすればいいというわけではなくて。

うんうん。

やっぱりそのアプリケーションの特性によって、まあどう例を採用するか。これ、そのLWW、後がちを使うと、片方の人はリクエストを送って成功したって思ってんのにそのデータ登録されてないってことが発生するんで。

うんうんうん。

うん。それがまあ要件として許されるか。

はいはい。

というところがポイントになります。

なんかFTPでファイルをアップロードしてデプロイしてた時代あるあるみたいな。

あ、そうそうそうそうそうそうそう。そういうことだと思います。

うん。

で、パターン2が、えー、バージョンベクトルというものになります。

バージョンベクトル。

これは。データがあって、で、そのデータのそれぞれにバージョンを持ってきます。

うん。

レコードのそれぞれにっていうのかな。で、バージョンを持っておいて、で、なんか同時に更新されたときに、そのそれぞれの更新はお互いの更新を見たあとに変えたのか、見る前に変えたのかっていうのを、なんかそれぞれのデータのバージョンを持っておくことによって気づけるようにしておきます。伝わりますかね、なんか。

うん。

Gitみたいな感じ？

ああ、まあそう。ハッシュ取ってるわけじゃないんですけど、考え方はそうですよね。

うん。

本当になんかすべて取っとく、取っ、すべてを比較するから。

うん。

どっかがずれてるっていうのがなんか気づけるっていうんですかね。まあそれぞれのデータに対してバージョン持ってるから。で、それで衝突検知をして、衝突していた場合に、まあどっちも残すのかどっちも拒否するのか。

うんうん。

みたいなものはアプリケーションによって考え方変えていきましょうね。まあもしくはなんか別の衝突解決仕組みを入れるか。

めちゃくちゃGitだな。

そう。

まさにコンフリクトしたときのやつじゃないですか。

あ、そう。ああ、確かにそうですね。コンフリクトはね、通知するというか。

うん。

お知らせするんですもんね。

そのバージョンじゃなきゃだめなんすね。なんかタイムスタンプでもなんか、み、見るっていうことに関しては一緒かなと思ったんですけど、バージョンのほうがいいんですか？

バージョンって多分なんか本当にGitの変更管理みたいなこと言ってんじゃないの？

具体どうなんだろうな。なんかそんなに、各レプリカ以外の更新回数、だから更新回数だけ見てるっぽいので。

うーん。

タイムスタンプどうなんだろうな。タイムスタンプから分かんのかな、それ。分かるか。まあでも文字列が多いから更新回数だけ見てたほうが省エネですよね、多分ね。

うん。

うんうん。で、最後がCRDTと呼ばれる。これはマージの規則を持たせるという衝突解決方法です。で、何言ってるかっていうと、例えば、えっと、Xのいいね。

はい。

って2人同時に0のポストに対していいねをしたら2になるじゃないですか。

うん。

で、これはいいねが、えー、競合する変更があったらどっちも適用させるっていうマージ規則を最初から埋め込んでいるからこういう解決の仕方をしますと。

うん。

うんうん。えー、逆に、ちょっと分かりづらいんですけど、Hugging Faceとかで、あとまあAWSとかでもいいんですけど、Claudeのモデル使いたいですってなったときに、だから有効化してから使えるようになるんですよ。

うん。

で、その有効化になってるか無効化になってるかって、処理、べき等じゃないですか。何回押しても有効だし。有効、有効化にするっていう処理をしたら何回押しても有効だし。

うん。

無効化するっていう処理したら何回押しても無効じゃないですか。

うんうん。

で、そういうものについては同時に押されても、まあただ、えー、べき等だからまあ片方だけ残すっていうマージ規則にする。

うんうんうん。

みたいな感じで、その自動でそのマージ規則を作っとくっていうのが、まあ3つ目の、えー、衝突回避方法らしいです。

べき等で言うとあれかもね、投票とかのが分かりやすいかもね。

あ、なんですか？

と、べき等だと投票とかのが分かりやすいかもね。1人1票までしか投票できない投票システムというか。

はいはい。

とかは同時に押しても1票しか入れないよねっていう。

ああ、そうですね。それだとどうなるんでしょうね。なんか投票先が複数あって別々に同時に行ったときとかはどうすんでしょうね。まあ先がちになるのかな。

あ、これって同時だったときの解決方法ではないのか。

あ、いや、そうです。同時だったときの解決方法です、はい。そうですね。そういうときもどういうふうなルールにするのかみたいなところを。

うん。

データ型ごとに作り込んでいく。

うん。

ってのが最後になります。なのでちょっとまとめると、後がちにするかどっちも、えー、残す。うそうそ、ごめんなさい。えっと、後がちにするか、えー、衝突検知させてからどう、どうにかするってアクションにするか、衝突検知も何もする前にデータ型ごとにマージルール決めとくか。あたりのところが、えー、この衝突解決とか衝突検知あたりでちょっと紹介されてました。

これは高部長への指示がってことですよね？

そうですね、はい。高部長への指示が衝突したときにどう解決するかみたいなところですね。

うん。

えー、でここまでがあの高部長の話、マルチリーダーの話なんですけど。

はい。

えー、これあの権限持つ人が増えると、なんか方針変更とかが早くなる一方でちょっとあちこちで食い違う、うーんどうしようってなった末の次の組織の形なんですけど。

うん。

えー、次の組織は部長なしです。

ほう。民主主義。

これリーダーレスと呼ばれるものなんですけど。リーダーレスってどうやったら成立すると思いますか？

やっぱ1人1人が高い意識を持って。

うん。

あのー、人任せにせずに積極的にイニシアチブを握っていくことじゃないですか。

正解。正解。

だろ？完全に正解。

すげえ。

えー、いやごめんなさい。完全に正解言いすぎたかもしんないな。完全に正解言いすぎてんすけど。

臨時リーダー。

テンポラリーリーダー？

毎回臨時でリーダーが立ち上がる。

うーん。それはリーダーレスとは言えない？

そうですね。リーダーレスとは言えないですね。えー、リーダーレスはどうやるかでというとですね。えー、めっちゃ極端なこと言うと、じゃあ、のりさんとじゅんぺいと僕、こう3つのノードがありますと。

うん。

うん。で、書き込みをする人は3人に書き込みをして、読み込むときも3人から読み込みます。

ほう。

っていうのがリーダーレスという形になります。

仕事が。

すごい拡散型ってこと？

増えるなあ。

仕事が増える。

うん。

そう、仕事が増えるんすよ、これ。で、まあどうするのがパフォーマンス的にいいのは、えーっと、一長一短なんすよね。書き込みだったら多分、小部長の、高部長のがいいし。

うんうんうん。

読み込み重視すんだったら部長スタイルのがいい。

うん。

うん。で、えー、リーダーレスはリーダーレスで、言うても書き込み先がいっぱいあるし。

うん。

そうですね。書き込みと読み込みが、えー、全、全員に対してというか、まあ全員じゃないこともあるんですけど。なんか関数にやればいいんだっけな。

うんうん。

そう。例えば、すいません、あの最初は3人書いて3人読むって言ったんですけど、これ全員やる必要はなくて。書き込みと読み込みが、えー、3人の場合は2人にすれば十分で。

うん。

書き込むときはじゃあじゅんぺいと僕に書き込みましたと。のりさんだけちょっと遅れてますと。

うん。

で、読み込むときに、じゃあかいちとのりさんを読み込みに行きましたと。

うん。

ってなると、あれのりさんのデータちょっと古いぞってなるわけじゃないですか。

マジごめん。

えー、で、そのときに、えー、のりさんが古いのが分かるんで。

うん。

のりさんのやつを更新しつつ読み込むみたいな動きをするみたいです、このリーダーレスの。

うーん。

え、どうやって気づくんだろう。俺が気づくの、これ？それとも教えてくれる人がいるの？

えーっと、呼んでる側で気づく。

呼んでる側で気づくんだ。

はい。

なんかデータベースの外に大いなる意志を感じるけど。

そうですね。間にいるのかな。プロキシみたいなのがいるのかもしんないですけど。

ちなみにキルとしてリーダーレスアーキテクチャで作られてる製品とかある？

カサンドラとか。

カサンドラ。

そうみたいですよ。

うーん、マジでピントこん。

いや、そうなんすよね。

聞いたことあるな。なん、なんでしょう。

買ったことないな。あの、コンタクトのCMみたいなアイコンのやつだよ。

そう。

え、でもあれ、なん、なんかのNoSQLだよね？グラフ？

あ、そうです、そうです。NoSQLですよね。ちょっと僕もあんまり詳しくないから分かんないですけど。で、これなんかパフォーマンス落ちそうな気はするんですけど、なんかどうやら、あのー、今3つだから分かりづらいですけど、全員に聞いて早いやつから2つレスポンスが返ってきた時点で返すみたいな考え方みたいなんで。なんかスピードはそんなに悪くなんないみたいです。なんか1個聞きに行ってめっちゃそいつが遅いみたいなことはあんまり発生しないから、なんかパフォーマンスは安定するらしい。

ん？

えーっと、書き込みを過半数にやって読み込みも過半数から取ってくる？

はい。

ん？2個から取ってくんのか、読み込みは。

最低。

最低。

最低過半数。基本的に全部から全部に送って、早いものが、早いもの順に返ってきた、2人返ってきたら返すみたいな動きするみたいですね。

あ、ってことはこれ設定値工夫する必要あんのかな。なんか例えばだけど今3人じゃん。で、2人に書き込むじゃん。で、読み込み2人にやったらさ、絶対書き込まれてないやつ読み込んだときに違いが分かるじゃん。

はい。

そういうロジック？

あ、そうです、そうです。はい。そういうロジック。

ああ、なるほど。

読み込みと書き込みが必ず、あのー、全ノードよりも多い数。

うんうんうんうん。

になるように。

あれってことは例えば5台いたときに、えー、3台書き込むとするじゃないですか。

はい。

でも読み込みを2台にするとミスる可能性あるじゃないですか。

あ、そうです。

だからそこは設定値絶対3じゃないとだめだよみたいなことになってるってことか。

そうです。おっしゃるとおりです。

うわお。

はあ。

多分だから、まあさっきも言ったように多分RDBMSじゃないNoSQLと何か、まあカサンドラはそうらしいですけど。

うんうんうん。

っていうのでこのリーダーレスという形が取られてるみたいですね。

へえ。

なんかどういうユースケースで早くなるかがなんかあんまピントこんな。

まあKafkaがかかってノードが、いや、あるノードがたまたまちょっと遅いみたいなのは少なくなるんじゃないですか。

ああ。

みんなに聞きに行って早いやつが返ってくるんで。

うんうんうんうん。

うーん。

まあ可用性は高そうですよね。

まあ確かに。

うん。

うん。ただ、そのデータベース間の一貫性はだいぶないですね。都度レプリケーションしてるわけじゃないんで。

うんうんうん。

まあなのでなんか組織構造で言うとほんとに、えー、担当社員が、うんと、会社の方針が担当社員全部に落ちてきて、で、みんながとう、イニシアチブを持って理解して。で、そいつを理解してないやつをその社員が見つけたら教えに行ってあげるみたいな。なんかそういうほんとに個々人が自立した組織。

うんうんうん。

みたいになってるのがまあリーダーレスというレプリケーションがあるみたいです。

おお。

はい。まあみたいな感じで、ちょっと今日はちょっとレプリケーション周りこういう型があるよというので、部長1人パターン、えー、高部長パターン、部長がいないパターン。

うん。

まあみたいなのをちょっと紹介させていただいたんですけど。で、私もプロジェクトで使ってるのは部長1人パターンの、えー、データベースでやってるんですけど。もし、えー、部長2人パターンとか、まあ書き込みのパフォーマンス求められるんだったらやんのかもしんないですね、確かに。

うーん。

部長2人パターンはなんか今後システム作る上で考えうるなあとは思いました。