00:07
今日は、DDIAの第9章、一貫性と合意という章を読んだ後の収録をします。
よろしくお願いします。今日は、Kenta Kudoさんにお越しいただきました。
Kentaさんは、前回の臨時読解から参加していただいていて、今日はゲストにお呼びしています。
Kentaさん、よろしくお願いします。
よろしくお願いします。
Kentaさん、前回参加されてから、収録されてから何か変化とかありましたか?
変化、そうですね。前回、日本に住み始めて2、3ヶ月みたいな感じで、そこからまた半年ぐらい経って、
なんか色々変化はあるんだけど、ついていけないっていうか。
変化がありすぎて。
そう。
簡単には話せないくらいの、成果があるじゃないですか。
とりあえず、生きてるみたいでよかったよ。
生きてるかどうか、わかんないけど、生きてはいいよ、生きてるよ。
よかった。
変化、そうだね。
その仕事としては、フリーランスっていうのを一応やっていって、
そこでもクライアント変わったり、みたいな変化があるのと、
またあとは、プライベートだと、結婚をしまして。
おー、おめでとうございます。
ありがとうございます。
それは大きいね。確かに変化、色々あるね。
そう、なんか色々。
彼女さん、今の奥さん、海外で会われたみたいな話を伺った気がするんですけど、
はい、会ってます。
ロンドンで会って、去年の暮れに日本に住みたいってことで、
一緒に日本に来たって感じなんですけど。
はい。それは大きな変化ですね。
大きいね。おめでとう。
ありがとうございます。
フリーランスの話も気になります。
フリーランスされるのは、日本来てからが初めてですか?
うーん、まあ、副業みたいなことは、ちょっとこう、
はい。まあ、副業みたいなことは、ちょっとこう、
やったりはしたんですけど、
まあ、完全にフリーランスでみたいなのは初めてですね。
ただまあ、エージェントを経由して案件をもらうので、
正直そんな、働き方がすごい変わるかっていうと、そういうのはないですね。
03:03
これまでの副業のような感じで、仕事ができているというか。
まあ、フルタイムとそんなに大きな変わりに感じない。
そんなに変わらない。
うん、感じない。
なので、やることは一緒ですか?
タイムゾーンは、というか、働いている会社は日本の会社?
うん、日本の会社。日本のエージェントで日本の会社って感じ。
そこはさ、しばらくさ、イギリスで2社、4、5年ぐらい働いてたわけじゃない?
うん。
ワークプレイスの環境としてのギャップとかは感じなかった?職場環境として。
まあ、ずっとリモートでやってて。
うん。
まあ、ギャップらしいギャップっていうのはあんまり感じないかな。
ただ、もちろんカルチャー的な部分は全然違うから。
うん。
うん。なんだろうな。
まあ、すごく日本的なカルチャーと、でも、それでもテック系の会社ってかなりリベラルじゃないけど。
風通し。
風通しがいいし、とか。
そう。結構、まあ、今のクライアントもスタートアップだから、すごいフラットで、だから、すごい、まあ、中間って言ったらあれなんだけど、その、いわゆる日本の企業っていうのと海外のスタートアップっていうところの間ぐらいにあるのかなっていうようなイメージかな。
だから、すごくギャップを感じるっていうのはない。
うん、確かに。
うん。
企業としては、世界で共通しているところが、まあ、やっぱり。
やっぱ似たような、まあ、カルチャーというか、形態というか、になるのかなっていうのは、やっぱ同じようなスピード感を持ってやろうと思ったら似てくるのかな。
まあ、たぶん日本の会社の方が、はい、参考にみたいな部分が大きいとは思うんだけど。
ケンタ君は今は、その、どういった技術とか、ジョブロールとか、どういった技術を持っているんでしょうか。
ジョブロールとかで働いてる。前は、例えば、まあ、バックエンドエンジニアだったり、まあ、割とフロントを合わせて、トゥルーフルスタックみたいな感じで、何でもするみたいな時期もあったと思うけど。
例えば、そういった、その、エージェントを通してさ、仕事をもらうときって、ある程度、制約をつけたりするの?例えば、Goを使ってる会社でとか、といっても何でもやりますみたいな感じなのか。
まあ、方向性みたいなのを決めるかな、こういう。まあ、言語で決めることもあるし、黒字で決めることもあるし。
プロジェクトで決める、まあ、探すっていう方法もあると思うんだけど。まあ、ある程度の方向性を持った上で、いろいろ紹介してもらってっていう感じになるかな。
で、今、自分としては、まあ、フルスタック、まあ、フロントもバックもできるよ、バックの方が得意だよみたいな感じで探してって感じかな。
06:07
じゃあ、今、読んでるようなデータベースの知識とかが、まあ、今後、技術選定とかでいきそうだなっていうところもありますけど。
うん。
うん。
まあ、もちろん技術選定でもいきますし、っていうのも、まあ、データベースってなったときに、まあ、SQL系はそれなりに分かってるつもり、まあ、もちろんアプリケーションエンジニアとしてはしてるんだけど、分かってるつもりだけど、そこからそのノーシークエルと比べたときに、どういう点を見てどう選べばいいのかみたいなのはあまり経験がないんで。
まあ、そこはすごい参考になるなっていうのと。
うん。
あとは、もっとコンピューターサイエンスに近い領域の方の理解を伸ばさないと、ここから先、レベルアップしていくためにはそういう部分が必要かなみたいな、ちょっと思ってて。
そうですね、あの、途中から参加していただくのが結構初だったので、声かけていただいて、すごい嬉しいなと思ったんですけど、っていうことで、そろそろ本の内容に入っていきますかね。
はい。
うん。
はい。
今日は、さっきも言ったように、コンセンサスと一貫性と合意の章だったんですけれども、皆さん、参加者もおっしゃってたように、すごい難しいというところで、毎回難しいって言ってるんですけど、今回特に難しかったかなという気がします。
難しかったね。
そうですね。
やっぱり、その本の最初で、これまでその結果整合性。
はい。
これの話があって、結果整合性が担保できるみたいな、まとめ方みたいなのがあったんですけど、それだけでは足りないというか、結果整合性だと、例えば順番が保証されなかったりとか、いつ整合性がどういうか分からなかったりみたいな、そういった問題が起きてくるので、それを実際に担保するにはどうしたらいいかっていうのが話が、今回の話で、お話ししたいと思います。
今回の章なのかなと思っていて、その中で、リニューアリザビリティ、先継性とか、あとは順序、順序をどう担保するかみたいな話とか、あとはコンセンサスアレゴリズムの話が主にされていたと思います。
分厚いしね。
そうですね。
一番挫折するとこだと思うんですよ。
だから、今回ブッククラブどうかなと思ったら、ちゃんとなんか。
ちょうど出張中で出れない方以外みんな来てて、事前のノートも僕見たとき、なんか半分ぐらいしか書かれてなかったから、あ、これはちょっと危ないかなと思って、当日望んでみたらしっかりみんな埋まってたっていうね。
09:02
そう、ちゃんと直前に皆さんちゃんと書いてくださって。
ここ乗り越えたら、あとはね、ちょっと楽しくバッチの話とかストリームの話するだけなんで。
そうですよね。
これ読んでないですけど、気楽な感じがしますね。
この章読み終わったと思ったら、まだなんか2PCの、あの、トゥーフェイズコミュニティの話が始まってとか、ディストロイビューティットトランザクションもこう、これでもかって感じで挟んできて、なかなか読んでて終わらないなって思いながら読んでた人も多いんじゃないかなと思う章ですね。
うん、まさにその通りですね。
結構やっぱり懐かしいと思う一方で、まあ概念としてはすごく重要というか、うん。
難しいというよりは、なんだろうな、まあやっぱ新しさっていうところがすごい大きいかなと思って、うん、やっぱその一貫性モデルみたいなのって、その、まあ実際アプリケーションを書くときにはほとんど意識しないところで、その、勉強するってなっても絶対に、あと、まあ頭足っていうのもあれだけど、なかなか手を出しづらいところがあると思うんで、やっぱその概念の新しさみたいなところがとってきにくさかなあと思います。
で、あとは、その、マーティン先生の書き方、論理の順序が、僕個人的には結構、なんか、独特だなと思って、だから多分素直に説明しようと思ったら、一貫性モデルにはこれこれこれのこれがあって、こういう特徴があって、比較して、で、あとはこれを実装するためにはこういう実装があるよみたいな説明かなと思うんですけど、
9章の説明的には、なんかいきなり線形可能性ドーンってきて、ちょっとこれは難しいから、ついにちょっと弱いこれがあって、みたいな、読みづらい、読みづらい、まあ、その説明の順序が特徴あるなっていうのを印象としてありました。
相当特徴あるよね。なんか、ブログとかと真逆の方向性、ブログとかで最初にこういうコンシスタンスモデルがありますみたいな感じで。
1個ずつクリアに紹介していく知識を入れるためにはいいんだけど、これはなんか割とこうナラティブというか、この本も結構特徴的なのが各章の最初に地図の差し絵が入っていると思うんですよ。気づきました?
はいはい、入ってます。
なんか地図、なんかRPGのドラクエの地図みたいなのがあって、なんか各章ごとのキーワードがなんか書いてるんですよね。
なんかここの山はなんかこういうコンシスタンスモデルで、ここには海があってみたいな。
ここの川で分断されててみたいな。なんか多分、マーティ先生が書いてるのか知らないですけど。
なんかその、そういったその、未踏の地みたいなのをこう1個1個歩きながらこう散策していくみたいな、なんか説明の仕方をするんですよね。
12:09
こうリニアライザビリティみたいなの出会って、ちょっとそいつが強すぎて倒せなかったから隣の道に行ってみたいな、なんかもっといい奴がいてみたいな。
うん。
Howみたいな感じで説明していく。
うん。
確かに。
そういうのが好きな方なのかもしれない。
あるゲームとかの経験を元にやってるんですかね。
ね。
友舎さんもなんか言ってましたけど、このリニアライザビリティの説明がまずあって、これ読んでいく中でこういうのがあるんだって思いながら読んで、でも最終的にダメなんか言って、がっかりしたみたいな話をされてて。
うん。
確かに説明の順序。
すごく面白いですね。
まあ、癖がある分、多分読み物としての面白さもあると思うんだけど、その多分一から説明されると本当に挫折するようなところだと思うんで。
知識だけにすると、これ600ページぐらいあったかな、確か。多分3分の2ぐらいになると思うんですよね。
うん。
あー。
だけど、まあそれはそれで、ずーっと知識だけが並べられてると単調というのもあって。
まあ、そういう本と読み方が多分違うと思うんですよ。
違うよね。DDIAはそういうふうにナレティブだと、章の始めから最後までまあ読むかって気になるけど、キーワードだと、問いと答え、キーワードと答えだけ書いてるような本は、自分がそのときに読みたい、章だけピックアップして読めばいいので、なんかこう。
はい。
却下辞典みたいな感じで使う読み方になるけど。
うん。
まあ、本によって特色が違うから読み方も変わるよねっていう話になるのかな。
データベースの却下辞典、地点で。
まあ、ここからさらに広げていく。
参考文献とかをさらに深読みしていくことができるような入門書って感じですかね、やっぱり。
まず、その参考文献みたいのを見に行きやすい本かなと思いましたね。
まあ、もちろん参考してる部分っていうのは章の中にいくつも100個ぐらいあるんですけど。
あ、これって実際どうなってるんだろうみたいな疑問がする、すごく分けやすいような書き方だなとは思いましたね。
あとは。
今回は、例えとかがやっぱりわかりやすかったですよね。
あの1つは、サッカー、ワールドカップの試合の例ですかね。
データベースの、あ、というか、リニアライザビリティが実現できていないと、まあ、当然、順序とかが決まってないので、読み込みの時に違うノードにアクセスしてしまった時に、
自分は変わってしまう
だからサッカーの結果とかを
この人は早く知ってて
この人は遅く知るみたいなことが
起きるっていう話があったりとか
15:02
あとは結婚式の例とかですね
結婚してください
はいっていう風に
いうのが普通に
で終わるところは
この実際の分散システムだと
新婦さんの例が出てきていて
新婦さんが
実際に結婚を認めるんですけれども
新婦さんを経由して
参加者とかに対しても
結婚をしてください
イエスって言って
それを新婦さんが
今から夫婦になりましたみたいなところを
全員が聞いていても
夫の人がその時に
何かそっと押してしまった
言ってなかったら
繰り返すときに
ちょっとすみません
うまく説明できないですけど
何かそういう例えがいっぱいあって
分かりやすかったなと思いました
この先生したの?けんたくん
結婚式してないからね
コーディネーターまだいないからね
新婦がコーディネーターで
はい
あの
自分たちがコホートってことだよね
この二層コミットのアナロジーとしては
そうですね
多分
自分たちと参加者
参加者もそうですから
その結婚式の
だから新婦というコーディネーターが
参加者であるコホートたちに
この人たち結婚するんだけどいいよねって言って
その時にコホートの一人が
コホートフェイラーが起こっちゃうと
例えば誰かがそっと押したりとか
何か第三者が入ってきて
トランザクションを横取りして
いやこの
これは自分と結婚する人だみたいな
横取ってっちゃったりすると
二層コミットが解決されないよね
っていうアナロジーですよね
はいそうです
あとは何か言葉の
何か曖昧されてなくて
似た言葉が出てくるっていうところですかね
一つはその前に出てきた
トゥーフェイズコミットと
まあ以前に出てきたトランザクションの
ところに出てきたトゥーフェイズロックの違い
まあ似たような言葉だけで
全く違うものだよっていう話であるとか
リニアライザビリティとシリアライザビリティ
それぞれこれの違いとか
この辺も一応説明があったので
混同しやすいけど似た名前っていうのも
やっぱやめてほしいなと思いますけど
まあそういうところも説明があって
まあちゃんと読めば
理解がしっきりするのかなって思いましたけど
これこういうところ
まあケンタ君の意見とかも聞いてみたいんだけど
こういうところが
結構やっぱり非ネイティブとして
コンピュータサイエンスに入っちゃうところの
欠点というかオーバーヘッドになるかなと思って
多分英語ネイティブで
いきなりリニアライザビリティって言われたら
18:00
リニアって線でしょ
で線形可能性
まあつまりどういうことかというと
こう直線のようにこう
表現できるみたいなところだと思うんだけど
いきなり日本語に線形か可動性みたいなのを
言われると一旦脳がストップしてしまうと思うんですよね
例えば英語からシンプルに
入るともっとなんだろう
シンプルにイメージできるんじゃないかなと思う
それはあるかもしれない
たとえ日本語で読んでるとしても
やっぱ線形可可能性って英語でなんて言うんだろう
みたいなのを確認したくはなるかなと思います
コーザリティとかコーザルチェーンとかも
因果関係
要するにAが来たらBが来るよねっていう
因果関係があるよねっていうところ
コーザルコンセスタンシーとか多い
じゃあ訳せって言われると難しいよね
訳せるけど
すごい学術的になっちゃう
なんか日本語に直接的な訳がないような感じがしますね
依存とかとも近いのかちょっと思ったんですけど
因果関係とも言えるしみたいな
日本語の難しいところは依存と言っちゃうと
英語にはディペンデンシーって言葉があるしねってなっちゃうよね
翻訳は本当大変なので
難しいですね
翻訳者にはね頭が上がれないですね
なんかそのアナロジーの話がせっかく出たので
ちょっと触れておくと
参加者の友久さんがリンクを貼ってくれた
Azure Cosmos DB 脳性合成レベルで紹介されてる
音符のアナロジーかな
これはちょっと新しすぎて面白かったな
いやこれ分かりやすかったですね
簡単に説明すると
Azure Cosmos DB の公式ドキュメントがありまして
そこにその5つトランザクション
コンシスタンシーモデル紹介されてるんですね
一番簡単なものから
一番強固な整合性から
イベンチュアルコンシスタンシー
弱い整合性まで
それらの5つのコンシスタンシーモデルについて
音符のGIFを使って紹介するんですよ
リンクは小ノートに貼ろうと思うんですけど
例えば一番ストロンゲストなコンシスタンシーだったら
音符のメロディが全てのノード
同じ順番で同じ音階で音楽を奏でますと
だけど例えばこれがイベンチュアルコンシスタンシーになっていくと
リーダーのノードでは徐々に
ドレミファって音階が上がっていくところが
全然別の順番で
ドミファソーみたいな感じで
来てしまうので
結果としてのメロディは全然違ったものになってしまうよね
21:01
っていうものをGIFで表現しているアナロジーがあって
これちょっと面白かった
新しい扉でしたね
これ見たら結果整合性じゃダメだって
結構あるなっていうのが本当に分かりやすい気がして
これすごいいいですね
他にアサヒさん的に
気になっているトピック
ありますか?
ケンタさんがおっしゃってたブロックチェーンの話
ちょっとその臨読会でも喋れましたけど
気になりました
コンセンサスアルゴリズムとかってブロックチェーンで
すごい重要なところ
トピックだと思うんで
僕は全然語れないんですけど
ここは今語った方がよくわかんないですけど
面白かったですね
せっかくこの本を読んだからこれを踏まえた上で
例えばプルーフオブワークとかね
ちゃんと元の論文を読んで
DDIを読んだ知識を持ってブロックチェーンを語ってみるっていうか
一回やりたいですよね
やりたいですね
やっぱすごい地続きというか
すごく隣にあるんだなっていうのを感じますね
専門家の方を一人お呼びして
ありだね
やってみたいですね
うん
だからそれでこのDDIAを読んだときに
この本は5年10年は生きる本だなと思ってましたけど
さらに10年続くかっていうと
続くと思うけど
でも例は明らかに古くなってきてるよね
例えばそれこそブロックチェーンの話とか
あとここでまだモンゴDBとかマイシークルとか
全然使われてますけど
最新のクラウドが出してる
例えばオーロラとかスパナーの例とか
もっと出てもいいと思うし
はい
なんかどこかで
どっかでツイッターかどっかで
マーティン先生もセカンドオーディション書いてるって言ってた気がするけど
ちょっとうろ覚えですけど
確かに
じゅんぺいさんとかもオーロラの例とかも上げてくださってましたけど
この辺の説明はまだこの本にはないような感じがする
その穴をこのポッドキャストというコンテンツで
ちょっとずつ埋めていけたらいいですね
そのブロックチェーンの話とかね
含めて
フィギュアさんなんか他に気になったトピックとかありますか
この本
この本じゃなくてもいいです
この書じゃなくてもいいですけど
ここまでどうして
一行チャプテリーですかね
改めて
実際よく分かってなかったんで
チャプテリーさんと pretending と良かったなというところで
estimated と 社長さんがしてあったみたいね
そういうね チャプテリーさんに触れられて良かったなというところですね
説明はわかりやすいっていうのは何人かの方も増えてましたね
24:05
そもそもキャップ定理自体が
曖昧な概念っていう話でしたね
キャップ定理自体はこれがあれば大丈夫というか
なんていうか証明しきれてるものではなくて
今回の本の中ではパーティションされてる上で
どっちを取るかみたいな話であるっていう説明があったと思うんですけど
じゃあリスナーの方向けに簡単にサマリーをやってみてもらっていいですか
僕ですか
キャップ定理っていうのが
Cがコンシプテンシー一貫性
Aが
アビリビリティ
これは可用性ですね
Pがパーティショントレランスで
パーティションは便利できるかどうかみたいな話だと思うんですけど
それぞれの2つしか取れないよっていうものなんですけども
実際には必ずパーティショントレランス
パーティションしてるっていうの前提がある上で
それでコンシステンシーを取るか
もしくはアビリビリティ可用性を取るかっていう話であるっていうのが今回の説明でして
だからキャップセオリーのCAを取るかCPを取るかで
APCを取るっていうような選択肢はそもそもないから
ちょっとその定義としてはどうなのっていう話がちょっとあったっていうのが
今回の章で説明がありましたが
っていう感じですかね
合ってますかね
合ってます
だからマーティン先生はキャップセオリムだけで語れないよねっていう
それはそうなんですけどすごい批判的な立場で語ってて
じゃあキャップセオリム限界があるよねってことで
じゃあ他にどういった概念が必要なのかってことで
コーザリティとかリニアライザビリティとかもちゃんとあってっていう話につながっていく
その多分導入というか批判的に乗り越えるためのキーワードとして放り込んでる気がします
そうですね
そういう基本的な用語の整理ができたのは良かったです
そしてここで出てるリニアライザビリティとかも
実際例えばライトもリードも遅いので実用耐え売らないようですよねっていうことで
じゃあどういったものがあるんですかってことで
シークエンシャルなコンシスタンシーとか
あとコーザルコンシスタンシーと呼ばれる別のモデルがあります
ありますよねっていう風につながってて
例えば一つ例を出すと
僕が昔働いてたネオ4Jっていう会社では
27:02
最終的にそのコーザルコンシスタンシーっていうものに落ち着いたんですよ
他の言い方で言うのはリードアフターライトみたいなところなんですけど
リードユアライトコンシスタンシー
結局ネオ4Jとかはグラフを操作するようなデータにおいて
パフォーマンスを出さなきゃいけないデータベースだったので
基本的には読みにも書きにもある程度早いですよって歌ってたんで
とはいえそれでもやっぱコーザリティを担保したいよねっていうことで
僕らが何をしたかというと
ブックマークと呼ばれる仕組みで実装したんですよね
コーザルクラスタリングっていうもの
ブックマークっていうのは
トランザクションごとに目印みたいなのをつけて
その目印を一種グローバルの入会でいいみたいな
形としてインスタンスに渡していく
インスタンスが来たときに
そのトランザクションについているブックマークと
自分が知っているそのブックマークをマッピングして
自分が処理するかどうかっていうのを
受け渡すみたいな感じで実装してて
このコーザルクラスタリングがあるとどういうことができるかっていうと
例えば自分が書き込んだデータは
基本的にすぐに返ってくるっていう
データセキュリティを散歩した状態で返ってくるみたいなのがあって
このコーザルクラスタリングをじゃあなぜでO4Jが実装したかっていうと
コンピューターが実装してたからなんですけど
そんな感じで多分データベースの界隈っていうのも
あそこが実装してるからうちはここかなみたいな感じで
徐々に浸透していくの力学を旗から見てて感じましたね
なるほど
けんさんのブログ1年くらい前に書いたやつだと思うんですけど
すごいわかりやすくて
デプリケーションとかの復習にもなってすごい良かったですね
ブックマークのっていう仕組みも
トランザクションIDと似てると思うんですけど
具体的にイメージできて良かったですね
一応ノートに貼っておきます
ありましたお願いします
実際にどのシステムがどういう意味で
どの一貫性モデルを選んでそれをどう実装してるのかっていうのは
結構調べたら面白いですね
確かに
比較表みたいなの作ってみたいですね
コンセンサスアルゴリズムにも触れたし
今回はケンタクもいるしっていうこと
これ以前の収録でも話してると思うんだけど
アパッチカフカの話を何回かこのロードテックトークでもしてて
アパッチカフカの有名な話としては
もともとはズーキーパーっていう
コーディネーターサービス
別のプロセスを使って
ズーキーパー自体が3台とか5台プロセスを動かして
30:02
彼らでコンシスタンスを守るための別のコーディネーターサービスを使って
アパッチカフカはそれに依存してるサービスだったんですよね
それを最近のインプルーブメント改善によって
アパッチカフカ自身にラフトコンセンサスを利用した
コーディネーションを実装することで
ズーキーパーをなくそうっていう動きが進んでて
もう実装はされててプロダクションレディではなかったかな
ちょっとそこの最新は追ってないんですけど
そういった話があったりする
だから要するにアパッチカフカを運用する側としては
今までカフカというJavaのプロセスとズーキーパーを
どっちもデプロイしなきゃいけなかったのが
アパッチカフカだけで良くなったっていう話があったりしますね
いやーなんかその話懐かしいというか
カフカでしましたけど
ここに繋がってくると思ったら感慨深いです
ここと繋がってくるというね
実際ラフトはやっぱデファクトというか
大体なんですかね
ズーキーパーは何でしょうね
ダブか何かを使っていて
うん
そこからラフトに
有効グラフ
乗り換えたってことですよね
多分ズーキーパーが完全に
世の中から消えることは全然ないと思うんですよね
例えばうちの会社でもインターナルな
フォークしていろいろ加えてるズーキーパーみたいなのがいて
そこは全社的に使ってる高可用性な
小さなメタデータを扱うための
インターナルズーキーパーみたいなのが機能してて
いろんなマイクロサービスがあるんですけど
そのマイクロサービス間で例えば
ちょっとしたデータを共有したいときに
使ってたりするので
コーディネーションというのはマイクロサービス間の
アーキテクチャでもよく出てくる話だから
アパチカフカが乗り換えたからといって
ズーキーパーが一気にしぼむかというと
そんなことではないと思うんですが
カフカとしてはほぼ確実に必要だから
自分で実装してみたほうが
メリットがあるかなっていうところだったんですかね
そうだと思いますね
それこそけんたくんが前に
イギリスで働いてた会社とかは
ズーキーパーの代わりに
Kubernetesでも使ってるコーディネーターサービスの
etcdを使って運用とかしなかったっけ
ズーキーパーの代わりに
ズーキーパーの顔をしたetcdを使うっていう
その辺どういう意図で選定したのかとかも気になりますね
この章で書かれてる知識がある人が選定したんでしょうね
33:02
確かに
コンシスタンシーモデルどうするとか
これをした時に
レイテンシーどれくらい影響があるよねとか
あとはパーティションが起こった時の運用をどうするみたいな
そういった選定する時の
技術要素とか要件ってあると思うんですよね
レイテンシーとかコンシスタンシーモデルとか
そういったものを思いつくために
ここら辺の知識はもう前提となってきちゃう
分かんないとついていけないから
っていう意味ではやっぱり
ちゃんと皆さんと読めてよかったですねこの本
ブッククラブで最後ちょっと時間がなかったから
ディスカッショントピックとしては提案できなかったんだけど
言っておけばよかったなと思ったのが
結構アプリケーションディベロッパーの方多いじゃないですか
参加してくれてる人で
じゃあこれを読んで明日からの業務どう変わりますかっていうところで
もうちょっと議論してもよかったなと思った
あー確かに
ごめん事前に書けなかったんだけど
消化不良だからこそ
消化不良のものの
食べ物のうちでも自分が消化できるものを
ちゃんと消化したいなということで
じゃあこれを読んで明日からの
あなたのキャリアどう変わりますかっていうのは
もうちょっと多分おのおのが考えても
いいところだったかなと思いましたね
うん
確かに
例えば具体的には社内のデザインドックを見に行ったら
コンシスタンシーに言及してないものがあったら
そこを突っ込む役になるとか
あとは社内ブログでコンシスタンシーについて
自分たちが例えばPOSGREを使っているんだったら
POSGREのコンシスタンシーモデルみたいなのを
いろいろ調べて
社内ブログ書いてみるとか
浅井さんの新しい会社はデータベース何使ってるんですかね
多分これから社内の
いやーそうですちゃんと分かってない
多分POSGREのRDSかAuroraかちょっと分かんないですけど
確かにAuroraとかを使ってるのであれば
内部資料を理解して
なんかしら障害が起きると思うんですけど
その時にどう対応するかっていうのを準備しておくとか
そういうのは確かにいいかなって思いましたね
SREだったらどういったフェイラーパターン
失敗パターンが起こるのかって想起したところに
それが起こった時にコンシスタンシーがどう影響するか
っていうのを多分シナリオとして一つ描けるはずなので
例えば社内の負荷テストとかゲームデーみたいなのをする時の
シナリオ提案に使えたりするよね
あーいいですねそういうのやってみたいです
けんたくんは最近どういうデータベースに扱うことが多いんですか
フリーランスの仕事してる中で
データベースはAWSが多くて
ダイナモフェインで使ってるかな
36:00
まさに
そういうのいきそうですねこの話が
やっぱ日本のテック業界ってAWSすごい人気って
この前聞いたんだけど
多いよね
多いんじゃないかな
こっちでAWSで働いてる中の人とこの前働いたら
もう日本は大きい一つの市場として捉えられてて
割合的にはGoogleとかを使ってるのは結構先進的な会社
割合的にはGoogleとかを使ってるのは結構先進的な会社
でそれ以外は基本AWSみたいなイメージが
結構伝統的な企業というかは
WindowsとかMicrosoftとの繋がりが強いんで
Azure使ったりみたいなのは
肝心な気がしますけど
Azureも結構いいよねなかなか
使ったことないんですけど
使ってみたい
ダイナモどう?使いやすい?
もちろん癖はある
癖強いなデータモデル
慣れが必要だなっていうのはすごく感じる
あれはイベンチュアルコンシスタンシーだよね基本的には
確か
クエリレベルでストロングコンシスタンシーかどうかは選べる時もある
そういう感じなのでだからこれを読んで
じゃあ明日からの業務にどう生かすかってのを
はい
ちなみにケンさんは何かありましたか?
第2回目読んでみて
自分で話せると思いましたけど
SREなのでさっき言ったゲームデーのゲームデーっていうのは
実際に障害が起こった時とかのようなシナリオを
実際に自分たちで体験するステージング環境とかにデプロイして
いろいろぶっ壊してみて
ここが抜けてたねみたいなのを
炙り出すプラクティスなんですけど
そういった時にコンシスタンシーとかを意識したシナリオを提案できるなっていうのを
まさに浅井さんに話ししながら自分でもそれやろうと思って
素晴らしいですね
あとは社内のラーニングセッションみたいなところで
自分が好きなトピックを紹介するシチュエーションって何回かあるんですよね
この前とかはメモキャッシュの
MICルーターってやつを紹介したりするんですよ
僕はデータベースが好きなので
勝手にデータベースを選んで話すことが多いんだけど
そういった時の項目とかディスカッショントピックとして
ここら辺の性能ももうちょっと細かく入れられるかなと思いましたね
実際の設計とかで提案できたら楽しいですね
39:02
今日はこんなところですかね
何か言い足りないこととかありますか?
お二人、けんたさん、けんさん
最後に宣伝とかされても大丈夫ですけど
サービスを最近友達と作ってるので
トリプリンク
旅行、旅系のサービスを作ってるので
興味のある方は覗いてみてほしいです
ちょっとじゃあショーの後にリンクを
それは今のフリーランスのやつとはまた別ですよね
はい、完全に個人から
あそこら辺の深掘り会やりたいんですよ
けんた工藤inジャパン半年
いいですね、やりたいです
気になるな
フリーランスの極意みたいなのもちょっと気になります
確かに
検討してみたいなと思ってるんで
ぜひよろしくお願いします、引き続き
はい、ぜひまた
では今日はけんたさんと第9章の振り返りをしました
引き続き第10章以降もやっていきます
じゃあ今日はありがとうございました
ありがとうございました
ありがとうございました
