00:09
はい、ケンさん、今日もよろしくお願いします。
はい、よろしくお願いします。
はい、今日はですね、DDIA本の第5章のレプリケーションのところをやっていこうと思うんですけども、
今回なんとあの、臨読会を公開臨読会という形でやりまして、
なんと全部で6人の参加者がいて、実際に臨読会を行いまして、
30分間、いろいろ議論というか、感想を言い合って話して、あと今、この収録をしています。
ということで今回、そのうちの1人のテッペイ・イワオカさんを招待しているので、今回はテッペイさんに出てもらっています。
テッペイさん、よろしくお願いします。
よろしくお願いします。
はい、ということでですね、
よろしくお願いします。
1番に声をかけてくれたので、今回ちょっと呼んで、一緒に話をしていけたらなというふうには思っています。
ということで今回は、
えーと、
レプリケーションの章でして、
サマリーとしては
レプリケーションの、あれですね、
どうしてレプリケーションを取り入れるのかっていう話があって、
リプリケーションの形式がいくつか紹介されている。
リーダーが、シングルリーダー、マルチリーダー、リーダーですみたいな、いろんな種類があるんですけども
そういった種類のレプリケーションがどういうふうに構成されてるかみたいな話があったりとか
あとはそれぞれ課題があるんで
それをどう解消していくかみたいな話がありました
ケンさん実際にこの本再度読んでみてどうでしたか
そうですね
いやなんか本当にボリューミーなので
なんか新しい本を読んでるような感じでしたね
多分2018年に初めて読んだ時も
多分30%も分かってなかったと思うんですよ
当時多分がっつり使ったデータベースで
ダイナモを使ってポスグレちょっとそれまで使ったことあってくらいだったんで
マルチリーダーとかリーダーレスとか
なんだこれはみたいな感じだったし
当時ってアプリケーションデベロッパーだったので
裏側の仕組みについて全く知らなかったですよね
そもそも新しい概念ばっかりだったので
でいう時に読んで
今回はその後例えばアパッチカフカとか
ダイナモとかマイシークエルの
スケールとか結構やってから読んでるので
業務で出会った知識っていうのは結構多かったので
それをこういい感じに棚下ろししながら読むことができて
そうやって読んでみると
本当にいい本だなっていうのが分かりますね
教科書的というか
本当に何回も必要に応じて
立ち返る本だなっていうのは
今回読んでその思いを強くしたっていう感じ
ですかね僕は
03:00
毎回違うところで学びがあるっていう感じですかね
この本の中で
そうですね
てっぺさんはどうでしたか
今回読んでみて
そうですね
やっぱり結構ボリューミーで
内容的にもかなり難しい内容が扱われていたので
かなり読むのが苦戦しましたっていう感じなんですけど
元々の自分の経験で言うと
あんまりこういう
レプリケーションとかを意識した実装とかって
あまりしたことがなくて
本当に新しく学ぶことばかりでした
なんですけど
レプリケーションする際の手法みたいなのは
こういうものがあって
そうする時にはこういう課題があって
こういう風に解決すればいいみたいなのが
ある程度示されていたので
そのマップみたいなのを自分の中で
こう置きながらやっていけるっていうのは
すごく強い武器を頂けたかなっていう感じがしてますね
でまだやっぱり多分30%どころか
まだ10%20%ぐらいしか分かってないと思うんですけど
でもそういうマップが頭の中にあるので
次そういうレプリケーションを意識した実装とかをしないと
今一応アプリケーションエンジニアとしてやってるんで
アプリケーション側でも影響がある部分は
本の内容的にありそうだなっていうところで
見えてきて
そういう関係しそうな時にはまた立ち返って
その該当箇所を読んで進めていくっていうだけでも
かなり力強いサポートしてもらえそうだなっていう風に思ってます
本当に読んですごく良かったです
なんか臨読会もね
これ収録前にやったって浅井さんも言ってくれたけど
臨読会なんかすごい良かったですよね
でも今てっぺいさんが自分15%20%さんが
しか分かってないって言ったけど
臨読会してみんなでこれ難しいよねみたいな言いながら
この難しいポイントを話しながら読めるじゃないですか
あれがめちゃくちゃいいなと思ったのは
僕これ2018年読んだ時にこれ読んで
俺データベース分かったわって思ったんですよ
もちろん全然分かってないんだけどね
分かった気になって
そこで欠けてる視点ってのは無知の知というか
自分が知らないところを知らないっていうのを知らない
なんかちょっと哲学問答みたいになっちゃいましたけど
臨読会しながら
当時僕も臨読会してたんだけど
臨読会しながらすると
みんな難しいって言ってるから
ここ難しくていいんだとか
ここはやっぱり現場でまだ解決されてないんだとか
また逆に本が書かれた当時から結構進展してるところがあって
誰かがなんか最近はこういうのがあるよって紹介してくれたりとか
そういうのをキャッチアップしながら読めるから
臨読会と合わせて読めてるっていうのは
すごいいいなと思いながら今日参加してましたね
確かに
06:00
今日の会はすごい素直というか
分からないとか分からないっていうスタンスで
かつなんか皆さんの知識が違うんで
経験を話せるとこを話してもらって
すごい勉強になる会でもあったし
すごい良かったですね
なんかセーフなスペースやね
分かんないのを分かんないと言えるみたいな
なんかこうやっぱり人と話して
お互いの理解をもとに
より理解を深めていこうっていう
目的が一個できるんで
ただ読んでるだけだったら
ああそうなんだみたいなんで終わっちゃうんですけど
なんかこういうふうに理解しましたっていうのを
伝えようと思うだけでも
すごくこう
あのなんて言うんでしょうね
要点を絞って
興味を持って読めるので
そういう意味でインプットの質もすごく変わったので
やっぱり
臨読会ってすごい強力だなと思いましたね
なんかてっぺいさんは今回の臨読会では
常にディスカッショントピックがあったんですけれども
それに必ず一番目に答えてくれてて
なんかすごい
準備ちゃんとしてくれたなっていう感じはして
なんかすごいそのその分だけ学びも
きっと多いんだろうなっていう感じが聞き出しました
ってことで
じゃあそうですね
なんか臨読会で話したディスカッショントピックの振り返りとかをしてみますかね
はい行きましょうか
じゃあディスカッション
今回だいたい20分
くらいで二つトピックしたんですけれども
まず一つ目が
レプリケーションラグの問題ですね
レプリケーションをする際によって
必ずリーダーからレプリカに対して
レプリケーションするときに必ずラグが発生すると
最低でも光の速さの
距離に対する光の速さの時間のラグが発生するので
そのラグが発生することによって
例えば
えっと
あるアプリケーションに書き込みをしたとしても
その書き込みを読もうとしたら
それが反映されてないみたいなことが起きると思うんですけども
そういうラグの影響をできるだけ小さくするにはどうすればいいか
っていうトピックで今日話をしましたね
はいっていうことで
一つ目がてっぺいさんが言ってくれたやつなんで
ちょっと簡単にもう一回話をしてもらってもいいですかね
自分の理解では
レプリケーションされた構成では
リーダーがいて
それが基本的に書き込みを行って
そこに付属というか
下につくようなものたちとしてフォロワーズっていうのがいて
で書き込みがされたタイミングで
リーダーからフォロワーに
その書き込みの内容を送って
その動機を取る
09:01
みたいな形なのかなと理解してて
今言ったリーディングやオンラインズっていうのは
自分が何かを書き込みましたっていうタイミングで
リーダーはそれを書き込んで
それをフォロワーに動機するために
その書き込まれた内容を送って
リーダーはそれを
フォロワーはその内容をまた自分たちの内容の中に書き込む
っていうことをするんですけど
書き込んでからその自分の書き込みをすぐ
その後に読んだ時に
まだそのフォロワー側にその更新が反映されてなくて
古い状態が返ってきてしまうみたいなのが
状況をこのリーディングやオンラインズっていう風に
言っているのかなと理解してます
ちょっとあの僕も頭がこんがらがってきたので
ちょっと具体例で考えてみたいんですけど
例えばあのツイッターっていうサービスがあっても
あったじゃないですか
今はもう名前が変わっちゃいましたけど
なんて読めるんですかね
X?
Xというさ
本当通じるのかなこれ
Xっていうサービスがあってみたいな
もうXみたいな感じですよね
メタ括弧QFacebookみたいな感じで
じゃあX括弧QTwitterというサービスがあるじゃないですか
例えばあれで
Read your own rightはどういうことかっていうのは
例えば想像してみると
ツイートしますよね
自分が
今日はDDIAの臨読会参加しました
イエーイみたいな感じでツイートしたときに
自分のタイムラインに行くと
自分のタイムラインが
例えばこれフォロワーから
フォロワーのレプリケーションされたデータベースから
自分のタイムラインを取ってるみたいな構成だったときに
もしそこでラグがあると
自分がツイートした最新のツイートが現れてないみたいな
感じになっちゃうと思うんですよ
あれみたいな
これバグじゃねえみたいな感じで
で何回かリロードしてると
なんか
最新のツイートが出てくるみたいな感じで
これは完全にレプリカに
レプリケーションしてるときに
ちょっと時間がかかってて
レプリケーションが終わったら見えてきた
みたいなパターンですね
しかもこれちょっと最悪なパターンとかだと
前段にキャッシュがあって
キャッシュミスとかが
それがキャッシュミスとして記憶されてして
そこをキャッシュミスのときに
常にヒットしに行くみたいな感じの構成になってないと
キャッシュが何もないみたいな
結果が返ってきちゃったり
さすがにツイッターレベルでそういったものはないと思うんだけど
そういったこともあったりしますと
だけど自分のタイムラインは常に
自分のそのユーザーIDを
例えばハッシュIDとかにして
そこのそのライトのデータベースに
常に読み込みに行くみたいな感じにすると
そういったレプリケーションラグの影響を受けずに
自分がしたツイートは
タイムラインに行ったときにすぐ見える
12:00
という形になると思うんですよね
このリードユーアオンライトのポイントは
それというか
なんていうんですか
リミテーションというのは
全てリードユーアオンライトにすればいいかというと
それができないときもあるんですよね
例えば
自分のタイムラインを見に行くときは
自分のデータが入っているライトのデータベースにすることが
なぜできるかというと
例えば自分のタイムラインってそんなに見に行かないじゃないですか
すごい自分のタイムラインをめちゃくちゃ連打しても
せいぜいリクエストパーセカンドでも
3回4回ぐらいだと思うんですよね
それは別にそのライトのデータベースに
そんなに負荷を与えてないと思うんですけど
例えばリードユーアオンライトを間違って実装してしまうと
自分の書き込みを見に行くときに
常にリードを
リードユーアオンライトを間違って実装してしまうと
最新の情報を欲しいからライトデータベースを見に行ってしまうと
そこで実装してしまったがゆえに
追加のリードのリクエストがライトに行きすぎて
さちってしまうと
飽和してしまうと思うんですよね
要するにライトのデータベースを
必要以上に読みに行ってしまっているので
例えば他の書き込みのワークロードとかに
パフォーマンスの影響を与えてしまうと
だからこのリードユーアオンライトで
読みに行くべきリードのリクエストが
リードの数っていうのは
アプリケーションの要件上最小限にしたい
ここが結構肝かなと思ってますね
確かに悪用しすぎるとというか
変な使い方をしてしまうと
ライターに一番重要なところに負担がかかってしまうので
それは避けたいよねというところですかね
そうですそうです
このツイッターの例はすごいわかりやすいですね
ありがとうございます
ツイッターじゃないですよXS
あそうかXS
わかりにくいなそれは
あとは
その意見があったのは
長いトランザクションとか大きい書き込みを
減らすみたいな話がありまして
その書き込みのサイズが大きければ大きいほど
ラグも大きくなるっていうので
そういうのは多分アプリケーション側の
ロジックで工夫できる点なのかなという意見が
ありましたね
あとはそのラグを認識する
ラグは必ず生まれるので
それは認識して
置くようにしようみたいな話
しようというかそうしたらいいんじゃないって話はありまして
ちゃんとそのラグをモニタリングして
どのくらいのラグがあるかっていうのを
把握できるようにするといいですねっていう話はありましたね
外トランザクションとかどうですか
15:00
ベーサー的に
どうぞどうぞ
ごめんなさい
言いたかったところは
ラグがあったら
そのことをユーザー側にも数値を上げることができるような話はありましたね
そうですよね
はい
はい
はい
,
するっていうことで回避するっていうのも話になってましたね
計測して
計測するだけでなくて
それをちゃんと通知してあげるみたいな
そうですね
通知しないと意味ないですよね
ユーザー側で
遅れてますよって分かれば
ツイート2回も3回もしなくても済むみたいな
話ですねさっきの例で言うと
そうですね
ごめんなさい検査下げちゃいました
どうぞ
アラートねこれ
レプリケーションラグをアラートするみたいな
どの流で
どれぐらいのスレスホールドでアラートすると結構難しいなと思ってて
例えばじゃあデータベースからレプリケーションラグが取れますみたいなときに
どうやってアラートします
パーセンタイル99で
もしくは1秒超えたら
そのスレスホールドはアプリケーション要件によって違うと思うんですけど
そうですね
多分平均で
レプリケーションラグ取っても意味ないんだろう
多分ホストレベルとかで取るんだろうねきっと
でここのリージョンからとか
ここのホストのレプリケーションラグが
めっちゃこう遅くなってる
これなんでかって言って
アラートが来てそれを見に行ったら
そのライターの
ノードが走ってるリージョンと
フォロワーがいるリージョンの間で
ネットワークの寸断があってみたいなのが
分かってとか
確かにそれ
確かにその地域間の差があるとすると
ユーザーさんに最中出しても地域が違ったら
実際に対象じゃない可能性もあるしっていうので
これ難しいですね
多分ですけど
アラート設定するときに
これちょっと僕間違ったこと言ってるかもしれないんだけど
データベースレイヤーで取れる
レプリケーションラグでまるっとアラートするより
何のデータが
支援してるかみたいな
ビジネス要件込みでアプリケーションレイヤーで
モニターした方がいい気もする
例えば
レプリケーションが遅れてますみたいになるより
なんだろうね
例えば自分の
最新のツイートを
例えばリードU1オンライトで
実装せずにフォロワーから読むみたいな人
時に
フォローレプリケーションが遅れてますみたいな
分かった方が
なんだろう
レプリケーションが遅れてもいいとこって
結構いっぱいあるじゃないですか
例えば3秒4秒でも
問題ないとこって結構あると思うんですけど
その問題になるようなところだけに
アラート設定するっていう方が
そのフォルスポジティブなアラートとかを
減らせるんじゃないかな
18:00
とかっていうのは
ちょっとアラート難しいですけどね
なんか単純にだから
レプリケーションラグが取れたから
じゃあアラートを仕掛けるっていう風には
多分現場ではなってなくて
これ一つ難しいトピックかなと思うんですけどね
例えば金融機関とか銀行とか
最近オンライン送信できますけど
そういう情報とかですかね
送信したと思ったけどできてない
もう一回調べてみたいな感じになっちゃうと困るんで
そこが遅れてるなら
遅れてるっていう風に分かった方が
嬉しいかなっていうところは
一つ例としてありそうですけど
あとこのもう一個前に戻ると
長いトランザクションの書き込みを減らす
みたいなところも
これ結構難しいなと思ってて
たまによくあるのがですね
なんかソースコード見に行って
なんかこうレールとか
気軽にトランザクションをね
オープンして書けちゃうから
とりあえず関係してるでしょってことで
こう長めのトランザクションブロック書いて
そこでガンガンが更新するみたいな
見るんですけど
よくよくちゃんとソースコード見てみると
こんなにトランザクション貼らなくて
よくないみたいな時あるんですよね
例えばなんか10行ぐらいトランザクション貼ってるけど
それって2つの小さいトランザクションに
分けられるよねみたいな
それってこうSREの観点だと
なかなか分かんないから
常にアプリケーションディベロッパーに
確認しに行ったり
そのドメイン知識を身につけなきゃいけなくなったりして
かといってそれって結構自動で
検知する仕組みを作るのは
なかなか難しいところなのかなと思ってて
結構ドメイン知識が必要だからね
例えば金融のアプリケーションを
来た時に
このユーザーデータベースと
トランザクション
ペイメントデータベースと
ここでトランザクション貼ってるけど
これとこれ
ここ一つのトランザクションじゃなくて
よくないみたいなのって
結構ドメイン知識必要なとこだと思うんですよ
レビューとかで指摘できないで
ピュッとマスターに入っちゃったりすると
難しいから
ここはなんかね
ここは一つ
まだまだ発展しがいがある領域かなと思って
聞いてましたね
この辺を解析して
なんですかね
このトランザクション長くないみたいなのを
一度出してくれる
リストにしてくれるツールとかあったら
売れそうですね
基本的に
トランザクション
ちょっとこれ間違ってるかもしれないですけど
トランザクションって長い方が
書き込みなら書き込み自体は
早いですよねデータベース側で
だからなんか
処理を早く終わらせたいから
ある程度長い
トランザクション
トランザクションするみたいなことも
あったりするのかなと思う
偶然でいくと
処理のスピードを優先するのか
その整合性ですかね
21:02
を優先するのかみたいなところも
アプリケーションのデベロッパーとして
難しいポイントなのかなって思います
トランザクション貼ると早くなるのは
それってあれ
でもそれを投げてるクライアントの観点からじゃない
そうですね
自分がトランザクション貼ってるから
そいつのクエリが全部優先されるから
クライアント的には確かに
早くなるんだけど
同じタイミングで同じく
同じライターのデータベースに書き込みをしたい
他のクライアントが50人いるとした時に
彼らは
例えば同じロー
同じところでトランザクション貼ろうとすると
待たされるわけなので
データベースを全体で見た時に
ライトが早くなるかどうかっていうのは
難しい問題で
もちろんそのトランザクションも
貼る流度がいくつかありますよね
例えばテーブル全体でロックするのかとか
あと行だけロックするのかとか
いろいろ細かい流度があるけど
細かい流度でロックすればするほどに
他の人とコンフリクトしないから
そういう意味で言うと
どの流度でトランザクション貼るみたいなのも
一つポイントになってきたりするのかなと思います
結構やっぱり整合性のところを完全に理解して
本当に整合性を担保しなきゃいけないとこだけ
貼るみたいなのが
そういうプラクティスが
アプリケーション開発チームの中で
あまねく行き渡っていれば
問題問題にならないとこだと
思います
難しいかな
新しい人が入ってきたりとかね
考えるというか設計するのも
それだけでかなり時間もかかりますし
確かにてっぺいさんの観点で言うと
分けるためのコストみたいなのがかかるっていうところで
開発スピードにもちょっと影響があるみたいなところも
ありそうですね
実際に
データベースが遅延してしまうっていう問題は
生まれつつも
スピード優先っていう感じでいったら
そうしてなってしまうっていう
チームとかがあるっていうのを
想像できます
あと結構責任の分断も問題だと思ってて
例えばちっちゃいスタートアップで
フルスタックで働いてる人とかあったら
クエリを書く人とデータベースを管理する人が一緒だから
そこら辺データベースも意識しながら
クエリ書こうぜみたいな
割と普通にやられてると思うんですけど
例えば大きい会社とかなったときに
データベースを管理してるプラットフォームエンジニアリングと
アプリケーションを開発する人が違うみたいになったときに
例えばトランザクション書きますと
24:01
これなんかレプリケーションに影響あるかもしれないとか
他のクエリ影響しかあるかもしれないっていうのを
いきなりポンと入った
例えばジュニアメンバーとか
あとはデータベースDDI名本的なところを
知識としてない人が
意識しながらトランザクションを書いてくれるかっていうと
多分書かないと思うんですよね
アプリケーション的に整合性が淡々とあるので
そこできればいいやみたいなところだけだと思って
そこに問題が起きたら
データベース管理者から怒られるか
シニアエンジニアにレビューで叩かれるかして
ちょっとずつ学んでいくみたいな
僕もそんな感じだったけど
逆に言うとてっぺんさんとかは
今はバックエンドだったっけ
とかだけどDDI名本読んだから
その観点を持ちながら今後は書けると思いますけど
そういう意味でも
自分だけの
観点で
仕事をしてしまわないためにも
こういう網羅的に書かれた本を読んで
その上で今自分が何をすべきかって
決めていくっていうのはすごい
改めて大事だなと思いましたね
前の技術キャッチアップ会のちょっと
絡みになっちゃうけど
これもDDI本を読むことで
データベース周りのメンタルモデルを
一つ身につけるっていう感じですよね
データベース界隈みたいなのが
一つ大きい
キーみたいな感じで表現できるとしたら
多分アプリケーションを書いてるみたいな
一つのブランチしか見てないんですけど
DDI本を読むと他にも
レプリケーションラグのこととか
モニタリングのこととか
なんかいろいろ考えなきゃいけないんだ
みたいなのがふわっと見えてきて
それで仕事すると徐々に他のブランチも見えてくるみたいな
まさにそうですよね
なんかそもそもレプリケーションっていう言葉自体は
AWSの試験勉強とかをしてきたときに
ちょっとだけ聞いたことはあるなっていうぐらいの
理解だったんですね
それを業務で実際に使ったことがなかったので
あんまり日々意識してやってたものでは
全然なくても本当頭の片隅に
どっか行ってしまってたって感じだったんですけど
こうやって本当機能マップみたいなのが
作れたことで
次なんか出てきたときにこれだっていうのを
ちゃんと認識して
ちょっとそこで分からないことだったら
本に立ち返ってっていうのが絶対できるようになるので
それって全然違うなっていうのを思いますね
そうですよね
その木の大きさを知れるだけでも全然
大きな進歩ですよね
木がいかに小さかったのかってことすら
認識してなかったので
この回を通して
メンタルモデルの具体例まで分かったのが
最高ですね
お得ですね
お得です
最後に一個言うと
木を分かって
27:00
木のデータベースのメンタルモデルが分かった
って気になってると
実はその木っていうのは
大きい森の一つの木にすぎなくてってことも
次に分かってきて
それはまた人生の旅ですね
次行きましょう
次ですね
二つ目の議題がGoogle Docsとかの
話がこの本に出てきたんですけども
そういったGoogle Docsで
共同編集ができますよね
その共同編集したときに
同じ行というか
同じ箇所を同時に編集した場合に
どうやってコンフリクトが解消するか
それぞれ違う文字を書き入れている中で
それをどうやって直していくのかというか
どう解消するのかというところを
二つ目のトピックにしました
はい
で
I think
まず出てきたのが
コンフリクトの検知と解消ってこと
ケンさんがCRDTの話をしていただいたと思うんですけども
これちょっと話していただいてもいいですか
はい
まず最初にコンフリクトが
例えばGoogle Docsみたいな
共同編集アプリを作る
想像してほしいんですけど
コンフリクトの解消
を考える前にコンフリクトを検知するっていうタイミングがあるので
コンフリクトを検知する
ディテクションするところと
解消する
リソリューションするところは別の
実装するときには別のステップですよ
前提がありますと
あった上で
コンフリクトを解消するっていうのは
自動でできるときもあるんですけど
大抵の場合アプリケーションによってはユーザーに聞くことが
多いですと
何でかっていうと
どっちがコンフリクトしたときにどっちが勝ちますかっていうのを
単純に例えばタイムスタンプで
ラストライトラン
ウィンみたいなことをしてもいいときもあるけど
そうじゃないときもあるので
それが例えばGitとか使ってると
Gitで2つの別々の
例えばブランチをマージしようとしたときに
コンフリクトが発生しました
Gitはどうするかというと
ここでコンフリクト起こりましたよみたいなのを
教えてくれますよね
そこでユーザーがこっちが
こっちの方が
Winですみたいなことを
教えなきゃいけないんですけど
ここが解消のフェーズ
けどGitはコンフリクトがありましたっていう
検知のところはいい感じにしてくれるので
そこを別々のステップが
ありますよっていうのが
前提としてあります
この本にもちょっと触れられてるみたいですけど
多分検知みたいなところで言うと
Google Docsとか
あとは
AppleのiCloudの同期とか
あとはEvernoteとか
そこら辺でこのCRDTと
OTっていうデータ構造が
すごい研究されてきてるんですよね
これ多分20世紀後半くらいから
30:01
OTとか始まっていて
Google Docsとかでも
入ってきてる概念なんですけど
そのOTっていうのは確か
オペレーショナルトランスフォームだったかな
でCRDTっていうのは
えーっと
またその
後発のデータ構造でこの本を
書かれてたマーティン先生が
多分この本を書いた後に割と
がっつり研究してる分野だったりするんですけど
まぁそこら辺のその
最近の共同編集アプリケーションを
使うときにはここら辺のその
データ構造を実装した
オートマージっていう
JavaScriptのライブラリとか
y.js
あとはもしかするとラストの実装である
y.rsみたいなのも最近
エキスペリメンタルで出てるんですけど
同じオーサーですね
が割とこう耳にする
ことも増えてきたかなっていうことで
うん
ここはちょっとあの今日はあんまり
深掘りはしないし
僕も完全には分かってない分野ではあるんですけど
その
まぁ一つ大きなトピックとして
最近のトレンドって言っていいのかな
CRDTコンフリクトフリー
えーとリプリケーションデータ
かなっていうのがあったりしますっていうのは
ちょっと今日軽く触れましたね
ありがとうございます
しっかりそのGitの例とかは
エンジニアであれば
すごい分かりやすく
今日参加者の一人の方が
Gitの説明をしてくださって
そのGitで
実際にコンフリケーションが起きたら
マージできるものはオートマージするし
できないものは
人に確認して
しなきゃいけないので
そこで確認してもらってマージするみたいな
ところで対応するみたいな
あってそれは分かりやすかったですし
今言ったようなCRDTとかで
検知して
対応するみたいな
話も今後
研究が進んでいったら
面白いなっていうふうには思いました
だから本当に
Google Docsとか一つの
分散データベースですよね
各
ユーザーのオフラインに
ラップトップとか
iPhoneとかそこに
書き込めるデータベース
みたいなのがあって
それだからどんどんどんどん書き込みが入ってきて
どれが
価値なのかみたいなのを計算しないと
なきゃいけないので
確か多分DDIでも
ここら辺の話はあったと
思うんですけど
特にGoogle Docsとかすごいのがある
オフラインでも動くじゃないですか
オフラインモードみたいなのあったよね
確かね ありますね
あれがすごいよね
あれをした上でコンフリクトもリソリューションして
あのパフォーマンスでやってるっていうのは
なかなか普通の
そこら辺のスタートアップとかができる話でもない
これ解消とか
確認ありましたっけGoogle Docsの場合って
コンフリクト
見たことないですよね
自動でやってるんですかね
33:00
これは多分
僕もちょっと分かんないんだけど
Google Docsが使ってると
言われてるのは
CRTTではなくOT
オペレーショナルトランスフォームと呼ばれるもので
これの仕組みがちょっと関係して
そうなんですよね
これちょっとまた別に深掘りからやりましょう
はい
なんかその
コンフリクト解消の一つの例として
まあその
マージするとか
マージするっていうのもあって
まあだから
両方とも書いたものを全部出しておく
みたいなのも
対応としてはあるのかもしれませんね
はい
今日はこんなところですかね
せっかくだし
やろうと思ったけどやれなかった
ディスカッショントピックも軽く売れますね
行きますか
はい
最後のトピックというかできなかったトピックが
この
この章の中でリーダーレス
データベースレプリケーションっていうのが
出てきまして
まあ3種類の
レプリケーション形式の中の一番最後
まあリーダーがそもそも存在しない
データベース
レプリケーション形式っていうのがありまして
で
これはどういうときに使うべきかという
質問をしようと思ってました
で
これの詳細をちょっと説明すると
リーダー自体がいないのに
どうやって
正しいデータを決めるかっていうので
クライアントが
複数のノードに対して
書き込み読み込みをして
もともと決まっている
コーラムっていうやつで
どれのデータを
正しいか決めるというか
例えば
書き込みをして
10個のノードがあって
4つ3つのノードがあって
成功すればOKですみたいな
ルールを決めてあって
4つ成功すれば
書き込み成功
みたいなルールがあるので
それに従って
データ書き込み読み込みされる
みたいなデータベースという
認識です
ってことでこれあんまり
実用性というか
自分の周りでは全然使ったことが
なかったので
実際にどういうときに使えるのか
この本の中では一応DynamoDBが
そういうふうに
実装になっているという話は
ありましたけれども
じゃあどういうときに使うべきかという
議論をしたいですね
ちょっと今回も
一応調べてきたので
自分の理解を言ってみていいですか
お願いします
さすが
ありがとうございます
まず前提として多分
単一のリーダーと
他リーダー
なんていうんですか他リーダーの方より
36:00
一貫性については
追求しづらい
っていう
デメリットは
あるのかなっていう
上で
でもそれを
補うような
メリットももちろん
あって
それが結構いくつかあるのかな
っていうふうに理解しています
なのでそういう一貫性を
あまり求めない
かつ今から言うような
メリットを享受したいときに
こういうリーダーレスを
使うのかなっていうふうに理解しています
一つ目が
高い可用性が必要な場合
が
リーダーレス向いてるのかなっていうふうに
思ってて
元々そのリーダー
単一リーダーとかだったら
そのリーダーが死んじゃうと
その間
システムがダウンしちゃうみたいな
可能性があるんですけど
リーダーレスで
だったらその一つが
一つに依存するってことがないので
リーダー
どこか
使えるものからデータを取って
こればいいみたいなところで
書き込めばいいみたいなところで
可用性はすごく実現
しやすいのかなっていうふうな
ところが
1点目ですかね
2点目が
ちょっとこれ似てるっちゃ似てるかもしれないですけど
書き込みのスケーラビリティが
必要な場合
っていうところで
さっきの
一つのリーダーがいて
とかっていうリーダー構成の場合は
リーダーしか書き込みを
受け付けられないのに対して
リーダーレスの場合は
全員が書き込みを受け付ける
っていう理解なので
書き込みが一つなのか
いくらでも
増やせられるのかっていうところで
大量の書き込みを処理する必要があるときには
すごいスケーラビリティが
実現できる
のかなっていうのが
二つ目ですね
三つ目が
地理的に分散が必要な場合
リーダーが
いる場合は
これもあれですかね
そのデータセンター内で
リーダーが
一貫性を維持しておかないといけないけど
えーと
その場合は
どこからでも
一貫性を維持することができるから
分散してても
あまり遅延を大きくせずに
実現できるみたいなところ
なのかなと思ってます
ちょっと説明があれでしたけど
こういうメリットが
あるのかなと思ってて
一貫性をどれだけ強く求めるのかと
可用性とかスケーラビリティとか
地理的な分散がどこまで必要なのか
っていうところをバランス取りながら
選択していくものなのかなと
39:00
理解しました
完璧だと思います
答えが素晴らしすぎて
今日から僕はちょっと
ロンドンテックトークのホストをリタイアしようかなと
てっぺーさんに
ダメですそれは
僕もやりますそしたら
てっぺートーク
そうですよね
リーダーがまずいるってことは
どういうことかっていうと
ライトがリーダーに行かなきゃいけないんですよね常に
シングルリーダーで考えたときに
すごいパフォーマンスがボトルネックになります
特にライトのワークロードが
遅いときですよね
例えばUSリージョンにライトがいて
APACとEUゾーンで
フォロワーがいてそれをレプリケーションしてます
みたいなシングルな
フォロワー構成をとっているときに
例えばAPACのユーザーが
書き込みをしたいとき
ってのはその書き込みの
ルーティング常にUSリージョンに
飛ばされるんですよね
なぜかというとライトが
USリージョンにいるから
これはAPACのユーザータイムゾーン
ユーザーからすると
めちゃくちゃ遅いんですよね
それが問題になると
リーダーレスの場合は
基本的にライトのワークロードが
めちゃくちゃスケールするので
これは一つ大きな
ポイントかなと思います
例えば僕らが広告配信で
DynamoDBを使ってたときも
広告配信って結構書き込みの
スループットが
必要なんですよね
読み込みの
広告配信サーバーって
どういうものかっていうと
広告を入稿したり
リアルタイムの分析データを使って
どの広告を今配信させたいか
っていうのを計算して
いい感じのJSONスキーマにして
配信させるんですけど
リードは簡単にスケールするんですよね
キャッシュをいっぱい
使えばいいので
そういうのがあったときに
シングルリーダーに依存してしまうと
なかなかボトルネックになるので
そこでDynamoDBをいい感じに使って
みたいな発想だったりしたので
本当にてっぺいさんが言った通り
スケーラビリティでかつ
書き込みのワークロードみたいなのが
一つポイントだと思います
アプリケーションを作るという観点で言うと
アプリケーション実装者の観点で言うと
データセンター云々
みたいなのは
基本あんまり気にしてないので
データベースを管理する側とか
データベースを作る側の
観点になると思うんですけど
一つこれは本当に
大きなポイントだと思います
かといってリーダーレスが
シングルリーダーより
優れているかというと
もちろんそんなことはなくて
キャップセオリーで言うように
捨てている部分はあるので
それで
例えばDynamoが要件的に使えない
というアプリケーションも
世の中にはたくさんあるので
42:00
トレードオフだと思うんですけど
という理解ですね
そのデータを
失ったりする可能性が
あるとか
結果整合性ということで
そんなに常に
新しいデータが得られるかわからないという状態ではあるので
それに問題なければ
使えるというか
かなり可用性が高くて
そこをどうしても優先したい場合
は使えるデータベース
という感じですかね
そうですね
これを発生すると
多分このイベントュアルコンシスタンシー
結果整合性は
Dynamoを作っている人が
多分Dynamoのペーパーを
論文を出したときに
もともとあったのかな
これは社内ではDynamoと言われていて
このAWSのサービスとして
出しているときはDynamoDBなので
ここら辺のデータベース界隈の
数ときに細かく分けたいときは
もともとの社内のやつはDynamo
外に出ているパブリックなサービスは
DynamoDBと言い分けたりするんですけど
DynamoDBのすごいところは
もともとは多分
イベントュアルコンシスタントは
データベースで出てきたんですけど
これいつだったか
多分今ストロングコンシスタンシーも
サポートしてたはずなんですよ
AWS3年くらい去ってないからあれですけど
つまりコンフィギュラブルなんですよね
どっちも実装しているなと思うんですけど
うん
なんかデータベースとしては
一つのものに特化するっていう方向性から
多分ユーザーからのニーズが多かったのか
途中でストロングコンシスタンシーも
あるんですけど
サービスとしてはDynamoDBめちゃくちゃ
すごいなっていう
ただの感想なんですけど
確かに結構
機能としては尖ってますけど
かなり幅広く使われているイメージは
あるので
そういう意味では
そういうところで新たな機能が
実装されたんですかね
整合性を強くするみたいな
DynamoDB使ったことありますか
僕は
ほとんどないですね
ホームでちょっと出てくるくらいです
ほとんどない
ちょろっと
読み込んだりしたくらいの
本当に使ってないに等しいような感じです
多分アプリケーション開発者の
観点だとDynamoDBを使うときの
一番難しいのは
スキーマ管理ですかね
スキーマ設計か
あれ結構独特なので
かなりユニークなので
そこの最初の
何ですか
RDBMSの
ノリでやってしまうと
後で変更できなかったりとか
コンパティビリティが
壊してしまったりとか
しちゃうので
AWSもかなりドキュメントとか
チュートリアも出しているので
読み込みましたけど
今更乗り越えれば
逆に使えそうな感じですかね
そうですね
最初言ってた
45:01
整合性みたいなのが
なくなりつつある
という理解であってますか
それともリーダーレスとは
違う方法を採用し始めている
ということなんですかね
ちょっと内部実装
分からないですよね
でもめっちゃ最強じゃん
と思っちゃいましたね
いろいろ長所もありつつ
整合性的にも別に問題が
強い整合性が
保証されるっていう
話だったと思うので
そうそう
ただしやっぱりこう
ストロングコンシスタンシーを
コンシスタンシーモデルを選ぶんですよ
どっちを使うかみたいな
ただしやっぱり
ストロングコンシスタンシーを選ぶと
パフォーマンスがちょっと
下がると思うんですよね
内部実装的に
リーダーレスかつ
イベンチャルコンシスタンシーで
良かった時と
同じ書き込みのワークロードは
期待できないと思うんですよね
なるほどなるほど結局
イベンチャルコンシスタンシーって
結果整合性なんで
後から見たら整合性取れるよ
っていうことで書き込みのワークロードを
優先するがゆえに読み込みを
イベンチャルコンシスタンシーということで
トレードオフを
やってるだけなので
DynamoDBのストロングコンシスタンシーが
だからといって
同じパフォーマンスを取れない気はする
なるほど
ちょっと
古いですけど
これもDynamoDBを結構使ってるけど
この要件だけは
結果整合性が欲しいから
ここもDynamoDBで
やりたいみたいな
横展開するために
その機能をそこだけオンにする
みたいなイメージなんですけど
そのために使うというよりは
うん
確かにそうかもしれないね
DynamoDBを元々使ってて
めちゃくちゃ詳しい
チームとしても詳しいし
DynamoDBのメトリックスとかも
アラート込みの
運用の知見も溜まってるチームが
一部をストロングコンシスタンシーな要件で
実装しなきゃいけなくなった時に
DynamoDBで立てると
そういったチームはスキーマ管理とかも
DynamoDBのスキーマ管理とかも
慣れてるので
そっちで立てちゃった方が新しく
別のシングルフォロワーとかで
構成のデータベースを入れるより
インフラ構成がシンプルになるよね
みたいなそういう感じかもしれないですね
確かに
でも逆にこういうのを知っておくと
将来DynamoDBを使う機会や
選定する時があった時に
また生きてきますよね
生きてきますね
楽しいねここら辺
楽しいですね
祈りが多いです
結果整合性っていう言葉は
僕全然わかってなかったんですけど
今回の聞いて
そもそもこの言葉は
曖昧みたいな話があって
まあ
それこそ結果っていつなの?
48:01
みたいな
結果的に整合性が取れるけど
それはいつなのかっていうのは
定義はないみたいな話があったので
それもちょっと面白いなと思って
もしかしたら1秒後かもしれないし
1年後かもしれないみたいな
なんかそういうのも
実際言葉の意味がちょっとわかったっていうか
よかったです
ちなみに結果整合性は
奥様には説明してきたんですか?
説明してないな今回
なんだっけ前回は確か
結果をうまく説明できて
みたいな
しましたね
そんな回やってないですね今回
いいアナロジーで
プログラマーじゃない方にも
うまく説明できたら
わかってるという証拠ということで
結果整合性を
説明してきます後で
けんさん何かやりました?
アナロジーの
結果整合性は一言で言うと
終わり良ければ全て良しですよね
なるほど
ちょっとアナロジーじゃないですけどね
うん
ことわざで表せる
そう
まあ途中何があれってことですね
結果良ければ全て良しと
そう
だいぶさまってますけど
確かに
それでいいと思いますね
それ使ってダメ出しくなったら
僕の説明
ダメだということなので
出直しして聞きますね
はい
まあなんか
こうやって振り返ると
アプリケーション開発者の観点でも
レプリケーション知ってくって
めちゃくちゃ大事だなっていうのが
本当にわかりますよね
レプリケーション一つとっても
3つ別々の方法があってとか
あとそれぞれの違う実質の時に
コンシスタンシーとか
絶対考えなきゃいけないと思うんですよ
アプリケーション書いてるとね
自分がどういうデータを扱っていて
それってその整合性って
なきゃいけないんだっけみたいなのは
必ず考えなきゃいけないところだと思うので
これは
やっぱりそのチャプター5からね
ちょっと重めになってきて
その後パーティショニングとか
コンシスタンシーとか入ってきますけど
最初にレプリケーションを持ってきてるっていうのは
やっぱり構成としてもすごい
納得感があるというか
なかなか
いい章でしたね
何回読んでも勉強になる
という
軽くまとめてみましたが
ありがとうございます
てっぺさん最後に何か
一言ありますか
宣伝でもいいですけど
冒頭にもちょっと触れましたけど
やっぱり
臨読会をするって
ほんと実り多いなと思ってて
自分一人だったら
そもそも読むことすら
なかなか続かない
性格なんですけど
もちろんその
最後まで読み切れたっていうのもありましたし
51:01
他の方と
意見をぶつけることで
これ難しいって自分も
感じたけど他の方も
難しいと感じてるんだっていう
安心して
焦らず読んでいけるっていう
そういう良さもありましたし
誰かに説明しようっていう風に
想定して読むことで
よりインプットが
深いものになっていくっていうところも
ありましたし
そうですね
知識が身につけられて
単純にこう
なんか
知識が身につけられるもそうなんですけど
自分の中の頭のマップが
どんどんできていって
知らなかったことを
知らせてもらえたっていうのも
今後こう
何かそういうことを使わないといけない
タイミングが出てきた時にも
ちゃんと立ち返れるものになっているので
あの
ほんと実り多いので
宣伝じゃないんですけど
ぜひ皆さんも一緒に
一緒にやれたらいいなと思いますね
すごいおすすめですっていうところですね
これはもう
ファシリをしてくれてる浅井さんに感謝ですね
感謝ですね
スケジュール管理からファシリから
今後楽しみです
ぜひ続けていきましょう
はい
じゃあ今日はこんなところで
二人ともありがとうございました
ありがとうございました
ありがとうございました
