00:08
はい、よろしくお願いします。
今日は、DDIA第8章の臨時課会後の収録をしていきます。
今日はですね、自分が時間を、スケジュールを間違えたせいで、Kenさんが参加できなくて、ホストは僕一人で、ゲストに、てっぺいさんと、しゅうへいさんをお呼びしています。よろしくお願いします。
よろしくお願いします。
よろしくお願いします。
てっぺいさんとしゅうへいさんは、これまで出たことが、ポッドキャストに出たことがあるんですけれども、一応まだ知らない方もいると思うので、簡単に自己紹介をお願いしようかな。
じゃあ、しゅうへいさんお願いします。
はい、こんにちは。枝しゅうへいと申します。前回も出たことがあるので、今回2回目です。
自分は今、ショッピファイに勤めていて、
で、ちょっと前、初旅をしたときは、ショッピファイのジャパンにいたんですけど、このたび、しれっとアメリカに移動しまして、今シアトルに住んでいます。よろしくお願いします。
よろしくお願いします。
たぶん、前回は日本にいたときだったと思うんで、その後のこと、全然僕は知らないんですけれども、どうやったか、引っ越してから、引っ越されてからというか、家とか簡単に使ったんですか?
はい。
家は…。
はい。
そうですね。最初、引っ越し、アメリカに来た直後は、その会社がサポートしてくれているので、そのテンポラリーの、一時的に住む家を用意してくれていました。
はい。
なので、その間に、本当に自分たちが住む家を探さなくてはいけなかったんですけど、そこは結構、いろいろ見て回って、2ヶ月ぐらいかけて、高校みたいな。
結局、アパートになったんですけど、見つけましたね。
やっぱり、そのくらいかかるんですね。僕も実は、今週末にスイスに渡航するんですけど、
なるほど。
そうなんですよ。出してもらっているテンポラリーアパートみたいな費用が、2週間分なので、その間に見つけられなかったら、自分で出すんですけど、ちょっと…。
おお、2週間。
やっぱり、1ヶ月くらいかかる人もいるって言ってたんで、はい。そのくらい、みんな気に入っています。
はい。
そのくらい、見なきゃダメかなと思ってますね。
なるほど。いや、たぶん、すごい勢いで、いろいろ内見してみてもらわないと、たぶん、なかなか1週間に決まらない気はするので、頑張ってください。
気が引いてしまいました。
もう、地域どのあたりとかは決めてるんですか?
もう1回。
洋介さん。
地域は、一応だいたい目星ですけど、会社から電車とかトラムとかですぐに行けるようなところに。
03:00
はい。
住みたいなと思ってて、まあ、30分以内みたいな感じで考えてて、一応、スーパーとかの場所もちょっとずつ見ているけど、まあ、全然まだわかんないですね。
ああ。
結構、事前に目星つけとかないと、2週間じゃ全然足りないってなりそうですよね。このあたりの、このあたりみたいな。
いや、本当に、なんかでも、住宅事情の変化が早すぎて、全然今から目星つけるとかできないらしくて。
へえ。
だから、ついてから見ないと。
まあ、本当に、取れないみたいな感じらしいんで、まあ、まだ何もわかんないですね。
うん。
その、価格がちゃんとわかんなかったりとか、開いてる、開いてないが、結構、部屋が激しかったりとか。
部屋が出されても、そうですね、あの、すぐに売れちゃうみたいな感じらしいんで、結構、そもそも出るのが少ないみたいな感じで、価格もよくわかんないです。
まあ、一応、目星はつけられるんですけど。
はい。
っていう感じかな。
結構、大変な2週間になりそうですね。
頑張ります。
働きつつ、部屋を探しつつって感じになるんですかね。
うん。最初の1週間は、まあ、何もないから、まだ。まあ、そのときは、仕事、部屋探しに集中して、まあ、2週間目から仕事が始まるんで、まあ、働きつつ、部屋を探すみたいな感じになりそうです。
1週間目、勝負ですね。
はい。
現地って、車社会なんですか?
いや、結構、交通機関は便利なので、あの、車買わなくても行けそうなんですよね。
ああ、そうですか。
はい。あの、まあ、街にトラムとかバスが結構走ってて、電車もあってみたいな感じなんで、まあ、今のところ買う予定はないですね。
なるほど。
ヨーロッパはそういうところが、都市は特に多いんじゃないかなと思うんですけど、まあ、ジュネーブ、僕はジュネーブ、ジュネーブもそんな感じです。
なるほど。
こっちはもう完全に車社会なんで、そうですね、まあ、車もようやく最近ゲットしたんですけど、まあ、それまで、なんか、もう、ずっと、なんていうか、自分の住んでるエリアに、なんか、から出れないみたいな。
まあ、出てもそんなに行けるとこ知れてるみたいなのが、ずっと続いてたんで、まあ、そういう、まあ、多分、アメリカは本当に一部の都市、まあ、ニューヨークとかサンフランシスコとか、そういうところ以外はもう、なんか、車ないとつらいみたいな感じなので。
まあ、シアトルで結構。
いいなって聞いててもらいました。
都会のイメージでしたけど、あれ、結構、車に行かないとダメなんですね。厳しいところ。
ああ、そうですね。まあ、僕、ちょっと、まあ、シアトルの近く、厳密にはシアトルの近くなので、レドモンドっていうエリアで、まあ、シアトルは確かに、まあ、ダウンタウンで、その、本当にまあ、車なくても、まあ、ある程度、こう、いろいろ、なんか、買い物が便利だったりとか、まあ、その、見て回る場所も充実してたりとかするんですけど。
はい。
まあ、その、自分の外住んでるところは、まあ、郊外の。
はい。
エリアなので、もう、本当に、車がないと、どこも行けないみたいな感じです。
06:03
いやー。
じゃあ、家決めてから、車買った感じですか?
そうですね。家買っ、そうですね。あの、そんな感じですね。
だから、まあ、実際、ほぼ同時ぐらい。たまたま、その、これ、なんか、その、いろいろ、こう、Facebookマーケットプレイスとか見てたら、これから日本に帰るっていう人が、車を売りたいみたいなところに、たまたま出会って、まあ、ほぼ、家を買うのと、車をゲットするのと。
はい。
まあ、たまたま同時になったっていうのはありましたけど。
はい。
まあ、その、マーケットプレイスで、あの、やり取りして、帰ったんですか?
まあ、そうですね。
へー。
結構、その、直接だから、安く、安めにって感じですか?
そうですね。あの、結構、なんでしょうね、しかも、向こうは焦ってたんで、こっちが言うような。
へー。
いいですね。
なんとしても、そう、現地で早く売って帰りたいみたいな。
あー。
まあ、割と、なんか、値下げしてくれてっていうので、ありがたい感じです。
めっちゃラッキーですね。
そうですね。まあ、本当、たまたまだと思いますけど。
うん。
結構、他にもFacebookマーケットプレイス、なんか、他にも欲しそうな人が、なんか、いい値付けてたりとかしてたんで、まあ、家族も。
タイミングが。
タイミングが。
そうですね。
素晴らしい決断力。
はい。
右ハンドル、左ハンドルは、もう慣れましたか?
あー。ようやく慣れてきましたけどさ、本当にそれは、もう、最近までなんですけど。
何でしょう、なんか、脳、常に脳トレをやってるみたいな。
間違った。
そうですよね。
ちょっと集中しなかったら、すぐに反対車線に入りそうになるのが、本当に怖いですね。
いや、怖いですね。
怖いですね。
気をつけないと。
うん。
ぼーっとしても運転できますけど、逆だと厳しそうですね。
いや、こうですね。
本当に集中してないと。
まあ、そこ、まあ、ようやくはちょっとずつ、こう、まあ、なんていうんですかね、そう、意識しなくても出てるようになってきましたけど。
うん。
1、2ヶ月なので、結構、何でしょうね、ぼーっとしてたらすぐに、お、こっちじゃないみたいな時がちょっとあるので。
危ない。
なんか、左折、日本で言う左折とかって、まあ、ちょっと、あの、歩行者いなかったら、バッて、なんか、あんまり気にせずに曲がるんですけど、右折とかだと、こう、反対車線から車来てるのをちゃんと見ないといけないじゃないですか。
はいはい。
で、多分それが逆になるから、左折の時にちゃんと対向車来てない、顔見ないといけない。
でも、なんか、同じ感覚で、まあ、左折やから、ちょっと気ぃ抜いていっちゃいそうやなっていう、対向車来て手ぶつかりそうになるみたいな、めっちゃ怒りそうな気ぃ手で想像しましたね、自分だったら。
おお、ですね。なので、どっちをより注意しなくてはいけないかとかも、まあ、ちょっと、なんていうんですかね、まあ、慣れるまでに時間がかかるし。
うん、そうですね。
あと、あとは、その、まあ、ご存じか分かんないですけど、アメリカって、赤信号でも右折だったら行っていいんですよ。
ああ、そうなんですね。あ、右折だったら。日本で言うと左折ってことですよね。
はい。
09:00
うんうんうん。
日本でも、なんか、そういう、その、新、この話続けてていいのか分からないですけど。
そうですね。
発展がすごく。
話しましょう。
はい。
まあ、そういうの、そういうのがあったりとかして、まあ、いろいろ、ちょっと違うのもあったりとかして。
ちょっと、マイナーのローカルルールがあるんですね。ローカルルールというか、国特有の。
うーん。
すいません。はい、長くなりました。
はい、ありがとうございました。
ありがとうございます。
えーと、てっぺいさんは、そうですよね。まあ、一応、第5章とかでも出てもらってましたけど、最近あれですね、転職と、なんだっけ、大学院進学されてめちゃくちゃ忙しいですよね。どうですか?
そうですね。えーと、そうですね。大学院が始まったのも、転職したのも8月で、えーと、どちらもちょうど1か月経ったみたいな状況ですね。
うんうん。
まあ、そうですね。まあ、で、会社の転職が、えーと、外資系企業に、日本の外資系の企業に転職したので、えーと、まあ、周りほとんども日本人がいなくて、全部英語で仕事をするみたいな環境になったので、そういう意味で、結構今、英語に苦しんでいるっていうような感じですね。
うん。
うん。
14:23
I think 11年くらいが過ぎたっていう感じですね。
11年くらい経つと、もう、まあ、最初ちょっとまだまだ、その、悔しい経験もされてるっていうお話でしたけど、ある程度やっぱりもうスムーズに仕事はできるようになりましたか?英語っていうね。
まあ、そうですね。まあ、一、一、その、昔の自分と比較すると圧倒的にスムーズにやったと思うんですね。
うんうん。
ああ、そうなんですね。
はい。
まあ、まあ、ちょっと、なんか分からない、まあ、分かる方がまあ多いし、まあ、その、ディスカッションとかも、まあ、その、ある程度入ったりはできるんですけど、ただやっぱりその、何でしょうね、すごい、あと自分のプレゼンテーションとかはまあ別に、まあ自分が話すことなんで、もう決めてたりもするんで、まあ言いやすい表現で言ったりとかもするので、別に全然問題なくなりますね。
15:12
うん。
すごい細かいこととかを
伝えるときとかに
結構
短い表現で
スマートなスタイルっていうのは
やっぱりまだ苦労することが多くて
そこはやっぱりまだまだ
勉強が必要だなっていう
気になることはあります
そういう英語でのコミュニケーションの話も
この辺ですごい上手な人は
やっぱりケンさんすごい上手だと思うので
そうなんですかね
すごいなぁケンさんと思う
一緒にミーティング入ったりとかするときは
時々会ったりするので
すごいなって思うことが多いので
やっぱりぜひその秘訣を
ここで話していただく回を
やってもらいたいです
めちゃくちゃ聞きたいです
今度は3人でインタビューしましょうケンさんに
そうです
ということでそろそろ
本題に入っていきますかね
お二人の話ももっと聞きたいので
またぜひ今度
ポッドキャストに出ていただきたいと思います
よろしくお願いします
お二人の話聞けなかったらぜひ前のポッドキャストに
行ってみてください
よろしくお願いします
ということでですね
前振りが長かったんですけども
第8章は
分散システムの問題という章でして
最初にコールミーメイビーの歌をもじったやつが出て
結構みんなでディスコードで笑ったんですけど
ちょっとこれ僕歌う自信ないんで
歌わないですけど
そういうネットワークとか
もしくはクロックとかで起きるに関連して
起きる問題とか
あとはそうですね
ビザンティンシャークモードとかできたりして
これまで
ビザンティンシステムのレプリケーションとか
パジションとか
トランザクションの章をやってきて
それでもなお
起こる問題みたいな
部分を
結構悲観的に見ていくような章
っていう感じになってますね
はい
ということで
今回は
4人でやったので
いつもより
少なかったんですけども
自分からは
そうですね
この章の中で
ネットワークの問題
結構気になって
やっぱり比較対象として
電話とかのネットワークの話が出てきて
電話はすごい
回線が安定しているのは
18:02
なぜかっていうと
電話自体がそもそも
回線の広い帯域幅を使わないで
固定した帯域幅しか使わないから
確立した回線を使って
そのデータを送れるっていうのが
あるんですけど
一方で
普段我々が使っている
Webサービスにおいては
いろんなサーバーがあって
いろんなサーバーのリクエスト
リスポンスが
ネットワーク上に溢れていて
かつそれのサイズも
まちまちでっていうので
Qを使って
使わなきゃいけなかったりっていうのが
あるので
それによって
ネットワークが遅延したりとか
途中でパケットロストしたりとか
相手のサーバーで問題が起きたりとか
いろんな問題が起きて
ネットワーク上
かついけない問題が
起こりうるので
送れてますが
それが分かったら面白かったなというふうに
思いました
あとは
そうですね
これまでの
5章第5章6章7章で読んできた
問題とかをどう解決するか
みたいな話がありましたけども
それが結構ネットワークの問題が起きると
それでこれまでトランザクションで
一生懸命担保招待したことが
うまくいかないっていうことになるので
それがすごい儚いなというふうに思いました
例えばトランザクション
データベースに更新かけようとして
トランザクションで
データベース側は
そのトランザクションコミットを完了しました
っていうふうになったとしても
データベースからの出力部分のネットワークが
何らかの問題で落ちていた時に
それがクライアント側には返せなくて
クライアント側は失敗したと思ってしまう
みたいなことも起こりうるので
そういう
そうですね
なんかさらにトランザクションとかだけでは
防げない問題がたくさんあるんだなと
思いましたね
っていうのがよく分かりました
一旦そうですね
自分からはこんな感じなんですけど
てっぺいさんなんかテイクアウェイとか
本の読みどうでしたか
そうですね
なんか
この章ちょっと
なんかつかみどころがちょっとなくなかったですか
なんか
なんか
ふわっと知ってたなっていう感じですね
自分の中では
なんか
なんかこう
問題がすごい
分散システムを使った時に
こういうことが困るんだよっていうのは
分かった分かったんですけど
ちょっと分散システムを使ってない
使った経験があまりないからなのか
そうなんだって感じで
ちょっと終わっちゃったなっていうのが
正直なところでした
ちょっと難しい
難しいというよりも
21:01
何がポイントなんだろうっていうのは
ちょっと把握しづらい感じでしたね
そうですね
あの
けんとうさんも言ってましたけど
クロックとかの問題
実際に見ることが少なくて
あんまりピンとこないっていう話はされてたので
そうですね
まあ
結構
低レイヤーな問題の話になってくるから
うんうんうん
その参考文献とかも
何かデータセンターで
どうやってその問題を防ぐかみたいな話で
あんまり普通のソフトウェアエンジニアとか
変わらないようなところも多いのかなって。
はい、うん。
あとこの辺でクラウドが出てくると
全部隠蔽されちゃってるから実感がわきにくい
クラウド使ってても
分散システムを使ったアプリケーションを書く場合には
ここで書かれてたような
対障害性を意識したことは書かなきゃいけなくなるんですよね
やってたらある程度イメージできる部分もあるのかもしれないですけど
まだ分散システムを使った経験もないので
なおさらピンときづらかったなっていう感じでしたね
クラウドとかの話で言うと面白かったのは
スーパー
スーパーコンピューターとの対比って出てきて
スーパーコンピューターは
ある特定の場所に
一つの場所に置いてあって
すごい高価なマシンを使って
そこで
ストレージも共有されていて
ネットワークをまたぐ必要がない
失敗したときはチェックポイントに戻って
どっかやり直せるみたいな話があって
そういう風にシステムを組めれば
かなり信頼性の高い
高いものを組めるけど
実際そういう例えば
富岳みたいなスーパーコンピューターって
すごい高い効果なんで
まあ普通のソフトウェアというか
システムとかを構築する場合は
クラウドコンピューティングを使う必要が
クラウドコンピューティング
安いノードを分散させて
システムを構築する必要があるっていう話があって
まあこれもなんか当たり前ちゃ当たり前ですけど
なんかそういう風に言うと
こういう風に対比されると面白いなと思いました
あとあれですかね
そのやっぱりスーパーコンピューターを使うと
まあその高いけど
まあ処理が早くなったりとか
そういうことはありつつも
やっぱりこう対障害性ですかね
あのなんか一つのコンピューターが落ちても
処理を継続し続けられるみたいなところは
あの満たせないので
24:02
そういうところではやっぱり分散システム使っていかないと
いけないっていうのがあるのかなとも理解しました
確かに
多分まあ一例とかで出てたのがあれですよ
リーダーセレクションでしたっけ
例えばそのいくつか何台かマシンがある中で
まあそのうちの1台がプライマリーとかリーダーであるみたいなことがある必要がある人がいるとは思いますが
まあそのうちの1台がプライマリーとかリーダーであるみたいなことがある必要がある人がいるとは思いますが
まあそのうちの1台がプライマリーとかリーダーであるみたいなことがある必要がある人がいるとは思いますが
まあそのうちの1台がプライマリーとかリーダーであるみたいなことがある必要がある人がいるとは思いますが
っていうシステムがあるときに
例えばデータベースとかは多分そういうものが多いと思うんですけど
論理上というかコンソール上では1台に見えてるんだけど
裏側には2台とか複数台のセカンダリーがいて
プライマリーがダウンしました
その裏のセカンダリーはどちらかが
プライマリー昇格しなくちゃいけませんとか
そういう時とかに多分その分散
それもある意味その分散システムですよね
多分こういうところをどうやって合意形成とっていく
そういうところで起きる問題が多分この章に書かれてたのかなと思ってて
おそらく次の章ではじゃあこれがどうやってプライマリーになるのかっていうのを
多分いろんなアルゴリズムを紹介してくれるのかなって期待してます
そうですね
多分ちょっとこの章と次の章がセットでなんか1つ
やっぱりそうですよね
話になるっていうので
ちょっとまだその前半部分だけ
だから何かこうフワッとしてる部分もあるのかなっていうのは
次がちょっと楽しみですね
重そうですけど
そうですね多分合意形成のアルゴリズムが多分出てくるんですよね
きっと次は
そうだと思います
なんかこれまでもデプリケーションとかでも
ちょっと多少マルチリーダーとかの話があったんで
えっと
多少話はありましたけど
まあ次の章で本格的にそのアルゴリズムの内容が出てくると思うんで
はい
ちょっと怖いですけど楽しみですね
あとはそのコメントの中で
あの目に見えるものが真実とは限らない
何が本当に何が嘘かっていうのを
コンフィデンスマンの世界を見るぞみたいなコメントがあって
これ面白かった
なんかそのこれは文脈としてはさっきの合意形成とか
えっと
えっとビザンチン将軍問題とかがあったんですけれども
あの途中でネットワークのデータが改ざんされてしまった時に
どう対応するかというか
それをどう防ぐかみたいな話もあると思うんですけど
まあ実際にそれが起きないことはないと思うので
そういうところもこの章には書いてありましたけれども
それもありますし
あれですよね
なんか嘘
そのビザンチン問題ほど明確にこう改ざんとかされなかったとしても
えっとまあなんかこうこういう風に思うときにね
27:00
まあこういう風に思うときにね
そういう風に思うときにね
まあこういう風に思うときにね
まあこういう風に思うときにね
何秒間の間にレスポンスがなかったら
そのノードが落ちたと判断して
別のノードをリーダーみたいな
見なすっていう仕組みがあったときに
何かしらのスレッドの一時停止で
その敷地を超えてしまって
っていう状態が発生したときに
もともとリーダーだったノードは
他のノードから見ると
もう死んでしまったと見なされてしまう
だけど自分自身はまだ死んでないと主張し続けるけど
信じてもらえないみたいな感じで
自分が正しいこと言ってても
それを嘘かのように捉えられてしまうみたいなところも
話としてありましたね
ちょっとうまく説明できたかもしれないですけど
いやでも書いてあってまさにその通りだと思います
そうですね
なので何が正しい情報なのかっていうのが
すごく分かりづらくなるんだろうなっていうのを
よく感じましたね
分散システムになると
たまたまそのGCがベージュコレクターしてて
そうですね
アップデートしてるだけなのかとか
なんかアップデートしてるだけなのかとか
いろんな事情があると思う
それをどうやって判定するかみたいなところ
いろいろやりようはありそうですけど
細かいですよね
そうですね
自分がなんかちょっとすごいなと思ったのは
やっぱりスパナですね
ちょっと勉強会のところでも触れさせてもらいましたけど
まずその
時刻が結局まず分散システムの問題になるのは
時刻の問題があると書いてあったと思うんですけど
それをなんていうんですかね
うまくやろうとすると
時刻がずれているところで
どうやってうまくトランザクションの順序であったり
何かイベントの発生をどうやって整理するか
みたいなところに話が行くのかなと思いきや
Googleはお金を使って
全ノードですごい精度のいい時計を用意するっていう
あとはそれを使ったAPI
TrueTime APIでしたっけ
そういうのを使って
なるべく誤差を下げるっていう
インフラで解決してしまうから
ちょっと不合感あふれる解決方法で
すごいなと思いましたけど
スパナ高いってよく言いますよね
高い理由はここに一つはこのようなかもしれませんね
この時間
はいはい
無理やり合わせていくっていうスタイルで
30:01
はいはい
逆に言うとGoogleであっても
安価にスマートに解決する方法っていうのは
あんまり見つけづらい
買ったからこそそういう商法を取ってるのかなとかって
考えるとやっぱりすごい難しい問題だなと思いますね
そうですね
なんか参考文献として面白かったのが
なんかネットワークが
落ちる原因
ネットワークが遅延することが
やっぱり一つずつクロックが遅れたりする原因になると思うんですけど
落ちる原因の一つに
そのサメがネットワークを
回転経路を食べて
なんか落としてしまったみたいな
切ってしまったみたいなのがあったりして
まあそういうなんか本当に予測できない問題が
起きるんだっていうのを思うとやっぱり
その現実世界で
まあリージョンも分散されてる中で
分散システムを組むっていうのは
確かにまあ予想がつかないことが多いので
まあそういうパワープレイに出るのも
なんか確かになっていうのはある
まあでもそこ
逆にでもまあそこにはお金をかけているとは
もうことは多分間違いないと思うんですけど
逆にでもそこが時刻がどの分散してるノードであっても
正確にある程度の精度で正確に取れるってことが
保証されてると
その上での実装はなんかすごい簡単になりそうだな
っていう気もしたので
なるほど
まあトータルのコストで見ると
どこインフラ部分にはコストが高いと思うんですけど
アプリの実装の難易度みたいなのを
下げられることを考えると
トータルのコストがどうなるのかっていうのは
まあなんかちょっとまあ実際に実はDWなのかなとか
この辺でちょっとコストまでは公開されてないと思うんですけど
まあでもちょっとなんかいつか中の人と喋ってみたいな
確かに気になりましたね
まあ普通のGoogleみたいな超正確なものを持っての
クロックを持ってないノードで処理をしようと思った場合
ある程度やっぱ範囲を取るんですよね
なんかこのここからここの範囲に入ってる
クロックおよびそのノードは正しいと判断して
でそれをその範囲を外れるものは
そのノードがなんかおかしいことになってるっていうので省くみたいな
感じですかね
で多分その
その時刻を使う処理をするときには
常にその範囲がどうで
そのノードは正しい範囲に入ってるのかみたいなところを
確認しながらプログラミングをしていかないといけないっていうところで
多分そこが超正確なGoogleみたいなものだったら
あまりそこまでこう工夫しなくても大丈夫だったりとか
33:00
そういうふうにするのかなっていうことですかね
そうだと思います
時刻確かそうですね
Tuletime APIって言われてたやつだと思うんですけど
ノードで正確な時間が取れるんだったら
その分散してても多分順序の整合性が取れると思うので
多分その辺でそういうなんていうんですかね
その後で情報をどこかで集約したりとか
トランザクションでどこまでのデータを見せるかとかっていうのが
多分自分の引ける時間だけで解決できるっていうことになると思うので
だいぶ実証の難易度が下がるのかなっていう気がしますね
なるほど
単一ノードっぽくプログラミングができるっていうことですかね
そうですね
なるほど
わかんないですねそうなると
もしかしたらトータルで考えると
リーズナブルなのかもしれないし
もしかしたらそういう意思決定なのかもしれないですよね
面白いですね
そうですね
テストとかもバカにならなさそうですよね
その誤差を意識したテストをちゃんと書こうと思うと
めっちゃ大変そうじゃないですか
確かにそうです
ミリ秒の世界で
やるんだったらだから
E2Eとかでやるんだったら
意図的にノードを多分2、3個用意して
1個落とすとかそういうことをやるのかな
多分そこまではやるか
そうですねこれぐらいのサービスを提供するんだったら
それぐらいはやります
なんかこのさっきの歌の例でできた
ジェプセンっていうツールがあって
それが確かそういう分散システムの
データベースのテストかな
確かできるはずで
そういうツールもあって
カサンドラだっけな
カサンドラかなんかで
結構いろいろバグがあるのを
そのテストツールを使って
検証したみたいな話はあったんで
なんか意外と自分でそこらへん
テストを書かなくてもできるところは
あるのかなっていうのを
ちょっと文献で読みましたね
何か気になったところとかありますかね
分散システムならではっていう
っていうところでいくと
やっぱりプロセスの処理が
ネットワークの遅延とかはよく
分散システムにおいてよく問題になるなっていうのは
なんとなく知ってたんですけど
プロセスの遅くなることもやっぱり辛いし
そのプロセスが遅くなる要因に
ガベージコレクションと
ライブマイグレーションとかっていうのが
あるよねって言われて
確かによく考えてみるとクラウドでよくあるのは
調査をしていて
何かシステムの時が止まったように見えるみたいな
36:03
ログが時々出るんですけど
それを後々調べてみると
ライブマイグレーションが起きてました
とかっていうのはやっぱりあって
なのでこの辺はやっぱり
実務でも痛い思いをしているところが
ここでも出てきていて
なんかやっぱり分散システム
分散システムは特にそうですね
考慮しながら作らなくてはいけないなっていう
気にはなりましたね
確かになんかその
ガベージコレクションだけじゃなくて
コンテナとかでも結構そういうのがあるって
話があった気がしててVMか
一つのホストに複数のVMというか
コンテナとかそういうのがある場合にも
どれか一つがCPUとかを
分かんないです
独占してしまって他のが止まったりとか
あるっていうのは結構身近にそういう問題は
ありそうですよね
Kubernetesとか使っているときにどうなるのか
みたいなちょっと気になりますね
そうですよね
表現としてはコンテナが
コンテナが別のVMに
割り当てられるって簡単に言いますけど
実際はそうですね
あるノードでコンテナなりプロセスを止めて
別のノードで
知らせるっていう話になると思うので
その間止まったように見える
ログからすると
時も取り方にももちろんよると思うんですけど
それでもGCとかの問題については
GCを予測して
GCが起きるノードを予測して
事前にルーティングするみたいな
GCを全体的に管理するような分散システムで
そういうツールを
研究とかもされているっていう話があったので
今後そういう問題が
そういったサービスによって
改善されていくのかなっていうのは
期待したいですね
GCもそうですね
問題になりがちですよね
結構ガビッジコレクションが
そうですね
GCがどうしても避けたいってなると
そうですね
そのガビッジコレクション
多分Javaとか
特にJavaだと思うんですけど
ガビッジコレクションに対していくつか
パラメーター渡したりとかもできるんで
それで何かしらチューニングするとかは
多分ある話だと思いますし
この辺をは
何でしょうね
逆にGoは相対的には少なくて
多分その
多分Goって
僕も最近触り始めたので
ちょっと知識として
ちょっとRFの部分あるんですけど
その
Javaとかだとマーキングして
39:03
スイーピングっていう
実際にメモリのオブジェクトを除いて
最後その
フラグメントしてるメモリを
全部その
なんていうんですかね
ディフラグメンテーションっていうんですかね
空き領域をちゃんと増やすみたいな処理で
コンパクションっていうところまで入って
3ステップでやって
ようやく空き領域が確保できるっていうメリットはあるんですけど
その代わりに
やっぱりコンパクションする時とか
そのものによっては
スイーピングする時とかに
結構そのストップザワールド
多分書かれたと思うんですけど
他のスレッドが止まって処理が止まるみたいな時間が
結構長くなると思うんですけど
Goとかって多分最後コンパクションが
ないのかな
僕の調べでは多分ないように見えて
もしかしたらごめんなさい
これバージョンによっても違ったりとか
するかもしれないんで何とも言えないんですけど
マーキングしてスイープするっていうところまでなので
結構メリットとしては
ストップザワールドする
他のスレッドが止まって
プロセスの処理が止まる時間が
かなり短くなってるのかなっていう感じはしました
結構Goだとそういう悩みが少ないから
なんか広く使われてると思うんですけど
そういうのも理由としてあるんですかね
なんかGoが使われる
かもなって思いました
もちろん最後のコンパクションがないと
ディフラグメンテーション
要はメモリの断片化が解決ができないので
そこをどうするかっていうデメリットはある
メリデメの話でそういうデメリットあると思うんですけど
多分でもその代わり止まる時間が少ないので
パフォーマンス的には良さそうだなと
いう気はしましたね
その辺ちょっと深掘りしてみたいですね
全然違うトピックになっちゃいますけど
そうですね
ちょっと分散システムから脱線して
いえいえめちゃくちゃ面白いありがとうございます
何か言い残したことありますか
もしなければ
パクソスラフトとかが出てくる気がするんですけど
いやーそうですね
頑張りましょう
名前だけは何度も見てたんで
ようやく深掘りできるっていうので
楽しみです
頑張りましょう
頑張りましょう
今日はありがとうございました
では引き続き次回以降もよろしくお願いします
また個別にインタビューもさせてください
よろしくお願いします
今日はこの辺で終わりにします
ありがとうございました
ありがとうございました
