ユニクス哲学とパイプ
今日は、DDIAの第10章、バッチプロセッシングの回を読んで、London Tech Talkの後の収録になります。
今日は、Shuheiさんをゲストにお呼びしています。
Shuheiさん、よろしくお願いします。
こんばんは、Shuheiです。よろしくお願いします。
こんにちは、おはようございます。
いろんな人もいると思うんですけど、よろしくお願いします。
こちらのタイムゾーンでは、おはようございますですけど、こちらのタイムゾーンですね。
本当に、改めてこの3つのタイムゾーンで収録を、ていうか、連続回をするのも結構すごいなっていう、ギリギリなところで思いますね。
Shuheiさんとは、この前も話をしましたけど、何かアップデートはありましたか?
出張で、そうですね、まずカナダに行っていました。
で、結構、その同じ大陸にはあるんですけど、結局、その西海岸から東海岸に移動するっていうことになるので、結構時間かかって、やっぱり7時間、8時間ぐらい。
そうか、レオバン含めたら、結局9時間ぐらいかかったのかな?とかで、意外と大変だなと思いました。
ただ、まあ、こう…。
そうですね、一応時差で考えると3時間時差なので、
まあ、何て言うんですかね、その前日に入って、なんか体を調整するとかまでは必要ないかなと思うんですけど。
まあなんか、半日でサクッと移動できるとか、そういう世界線ではまだなかったですね。
1週間くらい行って帰ったんですか?それとも3期間で1日2日とかですか?
そうですね、実際その東海岸で仕事したのは、まあ2日間かな。
うん。
であって合計4日ぐらいっていう感じですね
すごいいいですね楽しそう
これちょっと言っていいのか分からないですけど
今度またケンさんとついに会えるんですよシンガポールで
聞きましたそれ羨ましいです
全員来るんですかシンガポールに
大きくチーム全体としては世界中にメンバーが散らばってるんですけど
そこをざっくり2つに区切って
今回は僕がたまたま両方行けるんですけど
今回シンガポールに行くのは
APACとイミヤにいるチームのエンジニアが実際に集まるみたいな
そっかなるほど
しやひさんもとAPACですもんね
そうですねもともとAPACで僕はUSに移動したんですけど
今回そういう用心を持ってAPACの人から来たらいいじゃんって言っていただいて
APACのマネージャーから言っていただいて
行っていいんだったらぜひみたいな感じで
めっちゃ最高っすねそれ
そうですね
シンガポール初めてですか
シンガポールは初めてじゃないです2回目ですね
えいつだ2013年とかだね
もう10年ぶりですよ
10年ぶり
マイクロソフトにいらっしゃった時
そうです最初の新卒の時のトレーニングで
最初2年間か3年ぐらいは
全世界で同期になった人のトレーニングとかがあったんですよね当時は
すげーグローバル規模が違う
そうですね
世界の同期と2年ぐらい
2年間の中で
2、3回会うみたいな
世界の同期かっこいいですね
実際に会うときは基本的にはソーシャライジングメイン
それともトレーニングって一緒になんかやることがあるんですか
一応なんかそのディスカッションをやったりとか
その入社して数年の人たちがどうやってマイクロソフトを変えていくかみたいな
そういうトレーニングもやる
一応日中はやるんですけど
日中以外はほぼほぼ
そうですねソーシャライジングの時間でした
何人ぐらいいるんですかね
2,300人ぐらい
忘れちゃいました
でもそうですね
全員の顔覚えてないぐらいですよね
多分ね
そうですね
今回じゃあシンガポールでお二人会われて
収録もするかもって聞いたんですけど
あそうですか
それは聞いてなかった
収録したいねとは話したけど
できる時間ないんじゃないかな
そうですよね
お互いアメリカと日本
違うロンドンから行ってるから
期間はどのくらいでしたっけ
今回も2日ですね
仕事としては
前乗りするかどうか次第ですね
その辺も選べるんですね一応
一応1日
フライトの時間が一定より長かったら
前乗りしてもOKみたいなルールがあります
へー
やっぱお子さんとか
いると大変
ですよねそういうのもなかなか
いやいいポイントですね
僕はそういうので
家庭での承認が
おりなかったので
前乗りすることは諦めました
あーもうそれは仕方ないです
そうですけど
ケンさんもそうですか
僕も前乗りはさせていただくんですけど
その日に帰りますね
みんな
みんなは1日多分火曜日の夜に
みんなで飲んで
水曜日に帰るかって感じなんですけど
僕は火曜終わったら
多分そのまま直行でエアポート行きます
えっそんな日に帰れるんですか
なんですかすげー
深夜日にね
大変だ深夜日にね
深夜日にあるんですね
さすがロンゴ
ありました
いやー
まぁそこは仕方ないですね
ちょっと残念ですけど
フライトって何時間なんですか
えっと13.5でしたね直行の時から
あーなるほど
意外とあるなと思って
ありますね
日本に帰るのも15.6時間だから
それとそんなに変わらないなということで
フライト快適
地上は近そうですけど
そうそうそう
フライト快適グッズを買いましたね
フットレストとか
いいアイマスクとか
フットレスト
なんかそういうのあります?
しゅうへいさん
フライトの過ごし方とか
ティップスみたいな
あー僕は
いやそんなにそうですね
まぁないですけど
子供を連れて行く時は
そうですねフットレストっていうのか
わかんないですけど
なんかその足を置く場所を
完全に何て言うんですかね
もう椅子と同じ高さにできるぐらいの
フットレストがあって
そこに子供を寝かせると
広いスペースみたいになるので
子供はだいぶ足を伸ばして
なんかぐっすり寝れたりとかしてたので
子供にとって良かったなっていうのはありましたね
へー
それはいいですね
見てみます
子供がいる時は僕もそれ一緒に使えるんですけど
なんかあれ使えない時があるんですよね
あの子供会社によって
へーそうなんですか
あとなんか僕は大人一人で行く時に
それを使うのどうなんだっていうことで
僕は今回吊るす
吊るすタイプのフットレストを買いましたね
あっそんなのがあるんですか
うん
ちょっと外にしようと思って
イメージがわからないですけど
どんな感じなんだろう
面白いですね
そう
ちょっと楽しみですね
シンガポールでお会いできるのが
いやー楽しんできてください
いろいろその内容も話ができそうで
聞かせていただきたいです
ぜひぜひ
じゃあ早速ですが本題に入っていきますか
バッチプロセッシングとプリデュース
今日はバッチプロセッシングのショーをやっていて
主にマップレデュースの紹介が
メインだと思うんですけど
その前段で
ユニックス哲学の
ユニックス哲学の
ユニックス哲学の
話とかがちょっと出てきたりしていて
そこは結構面白かったって言ってる方多かったんですけど
しゅえさんも一応コメント書いてくださって
なんかちょっと
気になった点とか
ここ良かったなっていうのはありますか
そうですね
そうですね
勉強家のところでもちょっと少し
述べた内容と重複するかもしれないですけど
自分の場合結構キャリアの中で
Windowsというか
マイクロソフトの中で
マイクロソフト関連のテクノロジーを
多く使ってきてきたので
そのユニックスについて
ちゃんと学ぶみたいな機会が
正直少なかったんですよね
その中でもパイプとかも
雰囲気で使ってるっていうのが
正直なところだったので
ちゃんとそういうところで
今回のこのショーを読んで
パイプっていうのにもちゃんと哲学があって
その共通のインターフェイスをつなげることで
そういうことを目的にして
パイプが作られているっていうのも
書いてあったので
なるほどっていうふうに
結構感動しましたね
そっかパイプとか
ソースもOS違うから
あんまり気にしなくてよかったのか
パワーシェルとかでパイプもあるんですけど
なんでしょうね
なんか
思想が違うって感じ
思想がそうです
ちゃんとなんかこう
なんでしょうね
ちゃんと型とかを
僕そんなにちゃんと
パイプについて考えたことなかったので
今回ユニクソの本を読んで
実際もしかしたらパワーシェルでも
同じような哲学があるのかもしれないですけど
ユニクソの哲学を読んで
パイプってこういう人で作られてるんだ
みたいなところがよかったですね
本当に
こんだけシンプルで
フォーマットを合わせているからこそ
出力と入力をつなげられるみたいな話が
あったのは
そうですね
めちゃくちゃ
すごいなって思いましたね
このユニクソがあって
これが
これはシングルサーバーの上で
実行する上であればすごい強力で
すごい速いし
メモリ上で動くから
めちゃくちゃいいっていう話だったんですけど
それは実際にはスケールしないので
それをスケールさせるにはどうするかっていうところで
プリデュースが出てきましたという感じですかね
その紹介方としては
プリデュースの内部仕様
プリデュース自体はもうそんなに
流行ってないような感じではあるけど
外野としては大事なので
プリデュースの結構内部仕様というか
どうやって動いているかっていう話をしてましたね
みなさん結構
プリデュースは使ったことないって
言ってる方多かったですけど
けんさんは学生時代にちょっと触ってたんでしたっけ
そうなんですよね
だから原画では使ってたんですよ
学生時代
学生時代はすごい
社会学の学部だったんで
基本的にみんな他の先生は
社会福祉のポリシーの何たるわみたいなのとか
哲学の先生とか
いろんな人がいたんですけど
一人だけ研究室にこもって
当時MacBookを8台ぐらいつなげて
よくわからんことやってる先生がいるみたいな
ちょっと外れ者扱いされてる先生が
いたんですよね
その人は何をしてるかっていうと
TwitterのAPI叩いて
ソーシャルグラフを落としてきて
それでどんなことがバズってるかとか
あとは関係性とかを分析するっていう
Hadoopとマップリデュースの始まり
一応社会学っぽいことをやってる先生がいて
その先生面白そうだなっていうことで
4年生の時から言ったんですけど
その先生が結局何をしてたかっていうと
ローカルで
ApacheのHadoopのクラスターを組んで
Twitterから落としてきた大量のデータを
分析するっていうことをやってたんですよ
それが僕にとっての
ソフトエンジニアとしてのキャリアの始まりというか
最初に何かよくわかんないけど
楽しそうなことやっているなということで
そこでそのHadoopというものを知って
でもエンジニアなりたてというか
何ですかね
周りに教えてくれる人もいなかったり
何をやってるかよくわかんなくて
とりあえずオライリーでHadoopって調べて
当時ゾウの表紙の
確か赤というか紫の帯だったと思うんですけど
オライリーのHadoopの方があってそれを買って
家に届いたら思ったより暑くて
読み始めたんですけど何が書いてるかさっぱりわかんなくて
速攻で文鎮になりましたねその本がね
本当にいい思いですね
結局Hadoopが何かわかったのは
その後3、4年後ぐらいだったかも
当時はもう身を見真似で
先生の真似してるだけだったので
クラスターを組むドアみたいなところも
よくわかってなかったので
Hadoopからそのキャリアが始まるって
すごいイレギュラーな感じはするんですけど
でも面白いですねいいですね
でも当時は何も本当にわかってなかったので
本当に
それでキャリアが始まってちょっと言っていいのかぐらいですけど
でもそれでなんかわかんないけど面白そうだなっていうのが結構あって
それがわかるようになりたいなっていうモチベーションは
かなり強烈に植え付けられましたね
なるほど本当にファンキーな始め方ですけど
その先生がめちゃくちゃファンキーなんですよ
だって研究室のなんかね端っこの方にあるんですよね
へー
大丈夫かなこの先生って思うんだけど
なんか話してみるとすっごい真摯な方で
日本人じゃないんですよ
あそうなんだ
そうそうそう日本語上手なんですけど
はい
ゼミ生も検査の一人でしたっけ
えっとね僕の学年が一人で
でその下に3人入ってきたんですけど
おーそうなんだ
でなんで入ってきたかっていうと
その先生のゼミに入ると
楽にあの点数なんだっけ
卒業の
卒業もらえるよっていう
噂が広まっちゃってしまって
結局そのプログラミングができないけど
あの学生団体とかなんかそういう
クラブ
はい忙しい人ですね他のことで
そういうことをやりたくて楽に取りたいっていう人が集まったら
なんか別にエンジニアのトークができる人たちかっていう
全然そんなことなくて
あーなるほど
いやでもそのゼミのこと知らなかったですね僕は
知らないよね
そうなんだ
プログラミングやりたいなーと思って
で一人だけいてやってる先生が社会科学で
うん今なら絶対入りますけどそこに
ねー
うん
はい
っていうことで
逆に言うとそれ以降はマップリデュース先生やったことないですね
現場で
あーそうなんだ
いやマップリデュースにしてもその
Apache Sparkにしてもなんか
そのそういう大きいデータセットを持っている会社の中で
かつそのデータ分析系の人たちが
そういうのをそのインテリアにならないと
なかなかそういうのに触れられないですよね
うーん
と思いますねー
基本的には一般的なプログラミング言語とかで
データ処理したりとかって感じなんですかねやっぱり
とかもしくは
うん
まあそうですねもちろん多分
そのキャリア志向とかにもよるとは思うんですけど
自分の経験からいくとやっぱりその
なんていうんですかフィーチャーデベロップメントなり
SREなりっていうところでいくと
まあその
少なくとも自分の経験からは
あんまりHadoopを必要とする
シナリオに出会ったことがないっていうのが
正直なところですね
HadoopとApache Sparkの関係
そういうのがバッチリはまるシナリオを持っている会社に行って
そこで自分がそういう技術を持っているっていうのは
本当にレアだと思うし
そういうことができるエンジニアはすごいいいなと思いますね
相当の規模がないとっていうところはあるけど
そういうところにはかなりはまるっていう感じですかね
経験してる人が
大きい会社で検索エンジン作ってる会社とか
あとはEC作ってる会社とかじゃないですかね
そうですね
それで言うと僕らもECは作ってるけど
一応モノリスだし
多分僕らのやり方って
これ多分間違ってるかもしれないですけど
カフカに
入れて
でカフカから大量のコンシューマープロセスを
作って
イベントを読み込んで
そこで計算させるみたいな形だと思うんですよね
マップリデュースではないと思うんですよ
発想が
だから多分その辞書であるストリーム寄りなのかなと思って
そうですね
ハドゥープができたのって結構古いですよね
多分2010年
できたのは多分もっと前から
かもしれないけど多分
世の中的には2010
僕は2014年だったから
前だと思うんですけど
その後多分アパチカフカとか
ストリーミング系も結構枯れた技術になってきて
マップとリデュースで書くというよりも
カフカとかそういったもので書くみたいな方が
多分やりやすくなってきたんじゃないかなと思うんですよね
世の中トレンド的に
そうですね
うん
じゃあバッチの方はどうですか?
じゃあバッチの方はどうですか?
バッチの方からストリーミングの方に徐々に動いているという感じですかね
わかんないけど
可能性が
ただなんかプログラミング言語的な話で言うと
マップとリデュースに分けてみたいな
その考え方自体はよくありますよね
ファンクショナルプログラミングでね
そうです
確かにこの本の中でも
このピュアファンクション的な話が出てきて
プリデュースの良さとしては
何かのようなものが出てきて
何回再実行しても
同じ結果が出てくるっていうような
作りになって
インプットとアウトプットに
インプットを変更したりしないみたいな話であったりとか
障害性が高いっていうのがあったので
そういうところはすごい勉強だったって言ってる方も多かったですね
引力会をしたけど
Hadoopを実際触った人が誰もいないということで
うん そうですね
ちなみにすいません
Hadoopとマップリデュースの違いっていうのは
まあ
マップリデュースを使ってるんだと思うんですけど
さらにそのHadoopには
データベースがあるというか
書き込む用のデスクがついてる
なんか便利ツールみたいな感じでいいですか
そうですね
マップリデュースが要するに
プログラミングの手法ですね
分散データベースによって
各ステップをマップとリデュースに分けて
実行するっていう概念があったときに
Apache Hadoopっていうのは
それを実装しているソフトウェアですね
うん
でHadoopはそのマップリデュースで
実行するためのソフトウェアとしてできているので
まあ別物という理解で合ってると思いますね
はい なるほどそっか
じゃあ実際に使うとすれば
Hadoopを使うっていうことになるって感じですかね
マップリデュースを使いたいと思ったら
そのメインの手段をHadoopというか
メインストリームをHadoopみたいな感じですかね
2023年何がメインストリームかちょっと分かんないですけど
分かんないですね
まあ確かに今はそうですね
当時のっていうことですね
なんか一瞬触れられてたけど
これもしゅうへいさんかな
Databricksみたいな
マネージドApache Hadoopとかが
多分僕も経験も3年前とかなんですけど
Databricksのトレーニングを受けたことがあって
まあざっくりとDatabricksって
そのマネージドApache Hadoopとかがあったんですけど
まあマネージドApache Hadoopとかがあったんですけど
まあマネージドApache Hadoopとかがあったんですけど
まあマネージドApache Hadoopとかがあったんですけど
Databricksみたいなものだと理解してますと
バッチ処理とストリーミング処理の比較
でそのApache Sparkって何で出てきたかっていうと
まあこの方にもちょっと触れられてたと思うんですけど
そのHadoopというかMapReduceには
いくつか問題があって
その一例としては
まあその中間ファイルをそのHDFS
Mapファイルシステムとかで保存しなくちゃいけないとか
でもそれってパフォーマンスあんまり良くないよね
とかっていう話があったりとか
まあそういうのを解決するために
まあそのSparkが出てきて
でそれをまあその同じような話で
まあSparkの中のマネージド版っていうので
まあDatabricksが提供されてるっていう理解ですね
多分ここの章の結構ポイントって
実際にApache Hadoopを使うか
使ったことがあるかどうかとか
MapReduceのシステムを使ったどうかっていうのも
あると思うんですけど
そのバッジ処理を書くときの考え方として
あのそのユニックス哲学に表現されるような
一つ一つのプロセスはなるべく小さく
アイソレーテッドでピュアなファンクションを書くとか
あとその中間ファイル
中間バッジの中間の生成物を使うとか
まあそういった概念っていうのは
別にHadoopとかMapReduceを使わなくても
すごい生きてくる考え方だと思うんですよね
例えばなんかそのMySQLに
リードクエリを発行して何か計算して
でそれがすごい時間がかかるから
一つのバッジを回すだけじゃ終わらないから
一旦なんか別のS3か何かにバケットに
こう中間ファイルを書き出しておいて
みたいな話に生きてきたりだとか
あとそのバッジ処理って
バッジって失敗するので
1時間とか24時間とか回してると
だからそのバッジを
なるべくこうべき等性のあるものにする
何回実行しても再利用ができる
副作用が発生しないようなものにしておく
実行するたびに例えば
読み込み元のデータソースに
何か書き込みをしたりとか
先の中間生成物に
こうなんか実行するたびに
どんどんどんどん何かが
インクリメンタルされていったりだとか
何かその副作用が発生してしまうと
それはこうバッジのべき等性を壊してしまうので
そこはそのピュアに作りましょうとか
そういったその考え方自体は
すごい生きてくる章なのかなと
読んでいて思いましたね
いやーなるほど
確かにこれを知らないと
すごい巨大なバッジで
かつい何回か
実行すると壊れちゃうみたいなものを
書いてしまう可能性がありますよね
確かに
まあだからユニックス哲学の話が出てきて
ここは結構皆さん
確かに
あの思うポイントだって感じたのは
たぶん日常のね
開発に活かしやすい観点だったのかな
と思いましたね
確かに
そうですね
なんかちょっとこの章の話に
若干関連してるのは
内容でちょっと質問があるんですけど
ちょっとお二人聞いてみたいんですけど
いいですか
はいぜひぜひ
僕例えばそのオンラインで
その普通にその処理を受け付けてる
データベースがあって
まず最初そのスタートアップとかだと
最初多分その普通にデータベースがあると
シナリオを想像したいんですけど
それで今度じゃあ分析基盤を作ろうと思いましたと
そこはその今回のHadoopの
バッジ処理でも何でもいいですし
Hadoopなり
例えば今後やるイベント処理でも
何でもいいんですけど
ストリーミング何でもいいんですけど
例えばそのもともとある
そのOLTPのデータベースと
分析基盤のデータベースのスキーマとかって
ある程度なんかその
なんていうんですかね
シンクさせとかなくちゃいけないと思うんですよね
例えば勝手にそのオンライン側の方で
スキーマを追加削除されたら
分析基盤側も何らかのその仕組みを使って
その通知しなくちゃいけないと思うんですけど
そういう時って
なんかどういう風にこう
何て言うんですかね
それぞれのそのスキーマ情報って
そのうまくシンクしてましたかっていう
いやーなんかその問題は
僕はそんなに難しいことしないですけど
当たったことがあって
DMSっていうのでデータを移行した時に
まあ分析基盤に対してはないですけどね
移行した時にまあ確かにそういうスキーマ情報
そもそも連携されないんで
なんか連携をしてる最中に
実際にテーブルのカラームが追加されたりすると
まあそれが自動では反映されなくて
結構困るってことがあったんで
僕も気になってますっていうことしか言えないですけど
DMSってAWSの
そうそうAWSのやつですね
はいそうです
AWSデータマネジメントサービスとかなって
そうですねなんかはい
そういうのがあるんですね
結構その
ポスグレからマイスクエルに移したりとか
みたいなこともできるし
普通になんか
僕の場合はオンプレのEC2から
RDSのマネジメントサービスの方に
はい移すみたいなことを
してたんですけど
まあそういう悩みはありました
多分完全に自動同期させたら
結構困ると思うんですよ分析側は
例えば
あのマイスクエル
とか何でもいいですけど
OLTP側でカラムを使わなくなったから
カラムドロップしましたみたいな
だけどその分析プラットフォーム
OLAP側ではなんかダッシュボードか何かがあって
そこでその削除されたカラムを使ってて
それがある日
完全に自動で同期されていたと仮定した場合に
その分析のカラムナウンデータベースの方から
そのカラムがガラッと削除される
みたいになっちゃうと
どういったコンシューマーが
どういった分析を使ってるかわかんないので
ある日突然分析バッジがこけたり
ダッシュボードが壊れたりってなっちゃうと思うので
仮に自動で同期するとしても
アペンドオンリーというかにならざるを得ない
気がしているし
で例えばそのやっていたのは
例えばここはもうスキーマを別で明示的に分けて
その分析データベースが
その分析データベースが
分析データベースが
その分析データベース側にスキーマをアップデートしたい時には
それを別でスキーマで管理して
例えばプルリクを上げて
それプルリクをマージしたら
それを反映させるバッジが裏側で動いて
なので例えば
OLTP側のデータベース
MySQLとかのスキーマ管理とは別で
一緒にプルリクを出さなきゃいけなかったりとか
そういったワークフローをあえて踏ませることで
開発効率は下がるんですけど
そのスキーマの違い
データベースの違いを考えたら
変えざるを得ない状況を
ワークフローで強制的に生み出す
というのが一つやったことがありますね
それはじゃあ実務上で
一応ワークしてたってことですよね
そうですね
ワークはしてたのかな
知ってはいたんですけど
やっぱりそういった時に
まず課題になるのって
僕もその
一バックエンドエンジニアから入っているので
それで
分析プラットフォームを運用する
いわゆるデータ基盤とか
データウェアハウスチームからすると
結構その
いわゆる当時の僕みたいなバック
一バックエンドエンジニアって
そのOLTPとOLAPの違いって
よく分かんないんですよね
なので
マイシークエルにアクセスする感じな
ラフな感じで
OLAPにクエリを投げると
怒られるっていうことがよく発生する
うん
なんかこう
全然違うので
データベースの特性として
どういったクエリが強いかとか
どういったアクセスをしなきゃいけないみたいな
そういうベストプラクティスっていうのは
コードベースで担保できるものはするけど
できないから
ベストプラクティス集みたいなドキュメントに変えて
それを読んでやらなきゃいけないんだけど
当時僕はなんでそれをしなきゃいけないのかが
データベースの仕組みが分かんなかったから
全然分かんなくて
それでこう
これ違うよって指摘されながら
徐々に徐々にこう
分かっていったみたいなところがあるんですけど
ちょっと脱線してしまいましたけど
スキーマ管理に関しては
朝日さんが言ったDMSが完全に自動してないっていうのは
多分そういった背景があるんじゃないかなと想像しますね
確かに勝手に更新されたら困るっていうか
できないところもありそうですね
うん
そのワークフローに組み込むっていうのは
すごい大事な気がします
気づいたら追加されてるみたいなのが防げると思うんで
そうですね
多分気づいたら追加されてるのはいいですけど
気づいたらドロップされてるのがまだ
すごいヤバそうな感じがします
確かリネームとか
リネームも
リネームも多分
じゃあ試行実験でするとしたら
どういったスタイルが
事故が少ないかというと
例えば
OLTP側ではリネームされました
でもOLAP側では
元のカラムを
消さずに新しいの作るんじゃないかなと思うんですけどね
はいはいはい
そうですよね
多分
どういった運用にするか
会社次第ですけど
カラムを移行する
みたいなところもあるかもしれないですね
新しい名前のところ
もちろん
リネームもドロップもできるので
そういった時もありましたけど
そういう時はなるべくなくす
そういうことはなるべくなくすように
まあ確かに
うん
なるほど
今日はディスカッションのトピックも
いくつかあって
バッチ処理あるあるのフォルトパターン
まあ一つ目が
バッジ処理あるあるの
ウォールとパターン図をどう防ぐか
みたいな話
けんさんのテーマだったんですけど
これもなんか
4つくらいテーマがあって
一つやりましたね
インターン生が
スロークエリを連発する
バッジ処理を
ライトアロードに発行した時に
プラットフォーム絶対に
かかってしまったけど
これをどう対応するかみたいな
話でしたけど
補足すると
まあ
バッジ処理あるあるフォルトパターンみたいなのを
話すと面白いかなと思って
これMapReduceはそんな関係ないんですけどね
一つあったパターンが
例えばそのMySQLのクラスターを組んだ時に
ライターのデータベースがありますと
ライターをレプリケーションしてる
複数のリーダーノードがあります
でソフトウェアエンジニアは
ライターノードに対しても
リーダーノードに関しても
アクセスできるんですよね
どっちでも
でとある人が
重めのバッジ処理を書きました
その重めのバッジ処理ってのは
リードオンリーなんですよね
MySQLに対しては
MySQLからいろんなデータを読んで
別のとこに書き出すみたいなバッジを書いたので
そのバッジ処理ってのは
MySQLクラスターに関しては
リードオンリーにアクセスするだけで
バッチ処理のシステムレベルの修正
よかったんですけど
なぜか
まあ多分
タイマリーということで
ライターノードに発行しとけばいいだろう
ということで
とりあえずライターに
大量に読み込みに行ってしまったので
ライターが負荷がかかってしまって
他の普通の書き込みの
通常のクエリに対して
負荷がかかってしまった
みたいなのがあったんですよね
それを指摘する
防ぐために一つあるのは
プルリクエストが出された時に
それを知っている
シニアエンジニアとかが
プルリクエストが出された時に
それを知っているシニアエンジニアとかが
プルリクエストが出された時に
そこで指摘してあげて
これはライターに行く必要ないよねということで
リーダーに直してねということは
アーキテクチャの検討
一つもちろんあると思うんですけど
それってもうちょっと
システムレベルでというか
そういった誰かの
知識に依存せずに
修正するとしたら
どういったアーキテクチャがあるかな
というのを一つディスカッショントピックにしたら
面白いかなと思って
あげました
ありがとうございます
ありがとうございます
フックを
フックを
フックはその回答として
コードがアップロードされた時に
そのSQLというか
クエリを解析すれば
いいのかなって思ったんですけど
それが
僕の今の会社でも
そういう解析ツールを作っているんですが
それがまだ
できているか分からないというのがありまして
しゅうへいさんの話も
できますかね
実際に多分
できるかどうか分からないですけど
はい
例えばアプリケーションの中で
測れるクエリっていうのを全部
例えばそのあらかじめ
どんなクエリが測れるかっていうのは
分かっていれば
その新しくプルリクで追加された
そのクエリ
差分が出せるじゃないですか
そのこれまで発行されたクエリ一覧はこれです
で新しく発行
まあ今回プルリクで追加されたクエリが
これですっていうので
その今回このプルリクエストによって
えーと
えーと
新しく発行されるクエリが分かりますと
それが分かれば
あとはステージングというか
適当にMockでしたDBに対して
Explainつけて投げてみて
これはヤバそうだ
これは大丈夫だみたいなところを
Explainの結果から判断して
ヤバそうだったら
例えばプルディックに対して
コメントをつけるとか
そういうのはできるのかな
ちょっとやってみないと分からないんですけど
とはなんとなく思いますけど
サードパーティーツールとかでないのかな
これ作ったら普通に売れそうなんですけど
確かに売れそうですね
Explainして
多分ORマッパーを全部解析するとか
別に普段もできますよね
多分それプラス
それっぽいデータベースまで
作ってくれるところまで
セットであれば最高だなって気がしますけどね
ケンタさんは前の会社だと
SQLを書くようにしてたって話をされてましたけど
そうですよね
生で書いてそれを解析できるようにするみたいな
それがORマッパーでもできたら
生クエリは一番確実ですよね
多分取りこぼしがないというか
クエリも難しいですよね
例えばクエリが分かるだけじゃなくて
おそらくクエリもパラメータを持ってると思うんで
それらしいパラメータっていうのも
多分想像して
多分そのテストで投げなくちゃいけないと思うんで
結構多分やってみると
色々なんかありそうな気がするんですけど
それらしいパラメータを設定して
それらしいデータセットを持ったデータベースに
事前に投げるみたいなことが
なんかできればいいなっていう気がしますよね
確かに
テストのテストケースみたいなのも必要なんですね
そうなってくる
データの
生SQLを書いてってどうなんですかね
開発者的に
僕はSQL書くの嫌いじゃないからいいけど
うちとかレールズの会社なので
そんなこと提案したら反乱が起きるんじゃないかな
と思うんですけど
アクティブレコードなるものを
確かに
そうですね
アクティブレコードを書いちゃいけません
そうそうそうそう
レールズはきつそうだな
思想が反対じゃないですか
アクティブレコードで頑張ってこうぜっていうところなのに
それ全部やめて
生SQLプロジェクトに書いてくださいとか言われたら
運用しやすいねとか言われたら
反乱起きそうですけどね
クーデターが起きそう
やばいですね
でも
ちょっとミスとかも起きやすそうな感じはしないかな
しますね
うまくやらないと
書き方によると思うんですけど
やっぱり変数をどう入れるかみたいなとこ
生がどのくらい生なのかわかんないですけど
だからそれをじゃあ共通するかするために
生のSQLを書くんじゃなくて
なんかテンプレートみたいなの用意して
なんか埋め込めるようにして
それがJSONETでも何でもいいんだけどとかってすると
結局最終的なSQLが必要になってくると
SQL生成物が見えなくなっちゃってプルリクエ
なんか事故りそうですけどね
あとはあれじゃないですかね
その最初の取り戻って
こういうのが何ができるかっていうところでいくと
多分クエリ
ちょっとこれもやってみないとっていうところだと思うんですけど
新しく作られたクエリがあるんだとすると
多分データベース側でも
そのなんかそのライターが
新しいクエリハッシュが生成されたっていうのも
多分わかると思うんですよね
直近生成されたクエリハッシュとかも多分出せるはずなんで
そういう情報をもとに
SREなりクエリを書いた多さとかに通知を出すとか
誰かしらステークホルダーに通知を出すとかはいいかもしれないですね
ところがまだ現実的かもしれないですね
バッジの移行作業中の問題と対策
事前に検知できた方が本当はいいんですけど
確認フロー挟んじゃうっていうのも
一つありかもしれないですよね
そのライターに書き込むときは
なんかこうワンクッション必要で
いやでもどうなのかな
なんかプル陸上で
誰かのアプローブが必要で
まあちょっとそうなっちゃいますよね
そうちょっとダサい方向になっちゃいますよ
DBAの人とかがいる会社だったら
まあDBAの誰かの承認を得るみたいな
あとまあ気になったトピックとしては
なんか国産DBの話とかもあるんですけど
あとまあ気になったトピックとしては
あとまあ気になったトピックとしては
なんか国産DBの話をじゅんぺいさんがしてくださってて
つるぎってやつですね
これもなんかバッチリ強いって言いました
僕は全然あの中身を分かってないんですけど
こういうのも注目していきたいなと思いましたけど
これね気になってるんですよ
ちょっと前ツイッターで流れてきて
なんか論文とかも出てたかな確か
次世代RDBMSつるぎ
3つのところに
これ見たらシェルだけで書かれてるみたいな感じの
本当なんですかね
すごいです
えーすごいですね
なんかlanguageシェル100%って書いてますけど
どうなんだ
それとも検知できない言語で書いているのか
ちょっと分かんないですけど
本当だ
languageシェル100%
いやーそれはないんじゃないかね
そうですよね
これGitのサブモジュールになってますよね
あーはいはい
あーそっかそっか
だからか
それはそうっすよね
いやそれはさすがにないと思いますよ
噛みすぎる
うん多分Gitのサブモジュールに行くと
多分C++とか分かれてるので
ルートにシェルしかないっていう話だと思います
はいはいはい確かに理解しました
チラカミとかねタカトリとか多分そのコンポーネントごとに分かれてる
Gitデポジトリ分かれてて
全部山の名前なのかなこれ
なるほどな
C++かもね
C++が多いのかな
確かに
確かに
そうです
いやー国産DB熱いですよね
1回フィーチャーしてみたいですね
そうですね
なんかホームページを見る限り剣の特徴3つあって
1つが超高速バッジ処理が可能
2つ目がバッジオンライン併用が可能
3つ目がJava APIが利用可能ということなんで
なんとなくユーザーが想像できますけど
1つ目の超高速バッジ処理が可能っていうところはなぜなのかっていうのを多分公開論文とかを見ながら1回この今回のね
第10章の
あのー
臨読会のフォローアップみたいな感じでやってみても面白そうですよね
確かに
確かに
でこれ多分バッジオンラインの併用可能で夜間バッジが不要になりますっていうことをフィーチャーの1つと言ってるんで
なんとなくこう現場のエンジニアの苦労が想像できますけど
夜間バッジで苦しんでる人多分いっぱいいると思うんでね
とか帰還システムの裏側で
確かに
落ちちゃったらなんとかしないといけないから監視しなきゃいけないってことですよね
そうそうそう翌朝までに直さないとインフラ壊れますみたいな
あー厳しいな
そういった裏側を支えてくれてる人っていっぱいいると思うとね
刺さるんじゃないかな
確かに
そういう人たちの悩みはこれで解決できると思うと胸熱ですね
そうですね
これ結構早いんですよね
むしろちょっとねキャッチアップしてフィーチしようこれは
はいぜひやりましょう
他に気になったトピック何かありましたか
お二人で思い出のバッジ
あー思い出のバッジはいそうですね
ちょっと私が話しすぎたんで
あの話めっちゃ良かったですね
面白かった
良かったですね
新しいクエリへの対応
あの話を簡単にもう一回してもらいたい
どこかっていうのはちょっと伏せるんですけど
とあるそのテーブルを
まずとあるデータベースがありますと
その中のテーブルの直近3ヶ月以内のデータを残して
残りをアーカイブのデータベースに移行しなくちゃいけないみたいな
仕事が来ました
で自分はそういうその3ヶ月より古いデータを別のアーカイブデータベースに移行するっていうのが
そういうバッジを書くっていうのが自分の仕事だったんですけど
それを書きましたと
それで動くだろうと思っていたんですけど念のためにちゃんとアーカイブされているデータと
元のデータっていうのがちゃんと2つ
そのメインのデータベースとアーカイブのデータベースの中に両方あるかっていうのを確認するバッジも書いてたんですよね
結局もしその片方になかったらちゃんとアラートを鳴らすみたいなのも書いていたんですけど
やっぱり案の定そのアラートがちょっと飛んだっていう
結局そのメインのデータベースから移行させるときに
詳細はちょっと伏せるんですけど
ある高齢漏れのパターンがあって
結局普通に3ヶ月より古いものを移行するみたいなクエリの書き方だとちょっと甘い部分があったので
歯抜けな状態になっていました
ここでの学びはちゃんと自分を信用せずにそういうパターンもあるかもしれないから
ディフェンシブに
ちゃんとこういうパターンが起きたときには気づけるようにしましょうっていう仕組みを書いておいて
とりあえず救われたっていう
いやー素晴らしいですね
あとはその原因のところでちょっと気になったのが
確かその引力会の中では新しいクエリ
バッチ処理の結論
新しいインサートが原因になったっていう話で
解決策としては
結局バッチの処理においては最新のリアルタイムで入ってくるデータは取らない方がいいっていう結論があったみたいな話があると思うんですけど
それで理解あってましたっけ
そうですね
例えば例でいくとそのテーブルはそのアイデンティティインサートが有効になってたんですよね
例えばそのインサートが入ってくるときにインクリメンタルにそのIDが決まるみたいな
が決まるみたいな でそのぼっちでその取るときにその常に
最新のところまで取ろうとすると例えば その読み込みをその僕が書いたマッチは
まあ100番まで言いますよだけど複数の 書き込みがいる場合は101番から105番まで
インサートしようとしている奴らのやつも いれば他の書き込みの人が106から110
までインサートしようとしている人がい ますとで100それでもし106から110
までの方が早かったりするとまあその 読み込みバッジからするとまあえっと客まで
とってその後101から105は抜けて106 から110の情報が見えたりするんで
110まで見るとあまあそのままでたんです からそのオフセットというか自分はどこ
まで見たっていうのをそのバッジは管理し ているので
まずはもう100
106番まで見ましたっていうふうに理解し ちゃうんですよね
で101から105が見えないっていう状態に なるので
まあそういう問題っていうのが8起きて しまったみたいな数ですね
そのバッジが見に行くデータの タイムウィンドウみたいなところ
データのタイムウィンドウ
お尻と戦闘を決めるときに戦闘を再常に 最新の読み込むってしちゃうんじゃなくて
ある程度例えば
1分前までとか5分前までとか新しく入って きたデータも見続けちゃうそれが複数の
データから書けたソースから書き込まれると 不整合になるよねっていう話ですよね
はいまさにそうです
あるあるですよねでまぁ多分おっしゃって ましたけどその検知するバッジを書くと
いうのがほんとポイントですよね多分 プログラミング的な思考でとアサーション
を書くみたいな発想なのかなと思ってて これがもう
絶対ここでは負の値が入ってこないでしょ っていうふうにアサーションを書いておいて
負の値が返ってきたらプログラムが落ちる みたいな感じで
でもそれって分散のとかねバッジ環境では 表現できないので全然別のバリデーション
用のバッジを書くっていうのは確かに一つ ありだなぁと思いながら聞いていました
はいそうだと思います そのあくまで自分の想定ではそんなこと
は起きないと思っていても結構やっぱり 大事なものだったら
まあアサーションのバッジを書いてそれが 起きた時にすぐ気づけるような仕組みをとる
っていうのは一つ大事な方法だと思い ますね
いやーそれを5年前の僕 聞いておきたかったですね
広告事業部にいた時はバッジをたくさん 書いたんですけど
よく システムを落としてるんですよね
そういうのがあっていたので僕が
そうですか
スラックを
今じゃ考えられない
僕なのではい
バッジで何回も怒られましたね
そうなんですか
my secretさんごめんなさいみたいな感じで
それはなんかデータがなんですかね クエリが間違ってたけどそれでも
データが来ないみたいな話ですか
いろんな踏み抜きをしたのでね
一つ一つ語ってまたプラス1時間になって しまうので
おお
踏み抜きましただいぶ
聞いてみたいですね
意外と盛り上がったトピックだった
盛り上がりましたね
面白かったですか
思い出のバッジはみたいな
思い出のバッジは面白かった
思い出のほにゃららはとか盛り上がる ポイント高いのかな
みんないろいろ経験してるからそうですね
思い出があるんじゃないですか
主観的な聞き方の方が盛り上がるかもしれないね
確かに
あるあるの書くパターンについてどう防ぎますかみたいなのって
こう知ってるかどうかじゃない
まあその場で考えてもいいんだけど
あなたが今まで一番胸アツだったバッジ処理は何ですかみたいなのが
トピックとして面白いのかもしれないですね
うん確かに議論の仕方もちょっとそういうふうにしてみたいですね次から
まあこういうのもね学びながらね
面白い
輪読界一つ運営するにしてもどこまで場を盛り上げられるかってなかなか
意識しないと身につかないスキルだと思うので
今日はこんな感じにしますかね一応もう第10章もできてあと2章なので
次の本の候補とかも考えてますけど
まあそうですね引き続きあと2章残りやっていきましょうっていう感じですかね
そうかもう終わりですか
もう終わりですか
そうですよはいきましたね
すごいなんか達成感がありますね
まだ終わってないけど
まだ終わってないけどはい
ようやく終わりが見えてきましたね
僕こういうとこで結構やめんの得意なんでちょっと最後まで頑張りたいですね
いや確かにでも
最後の見えちゃっていうところで
確かに
しゅうへいさんが参加するまであの輪読界始まんないので
しゅうへいさん来ないときはもうピングし続けますよみんな
PagerDuty僕鳴らせるんでしゅうへいさんの
あーそっかそっか確かに
旗切り起こせるんですね
そうそうそう
あれあれあれは起きますね確かに
そんなうるさいんですかPagerDuty
なんかいやうるさいっていうかなんか心臓に悪い音になりますね
あーそうなんだこわ
何が起きたみたいな感じになりますねPagerDutyのそのデフォルトの
なんか変えれるっぽいんですけど
メッセージも渡せるんでねDDIAブッククラブ始まりますっていうタイトルで
来てください
来てください
来てください
それはそれは緊急ですね
うん緊急アージェンシー感慨ですねあのエスカレーションさせられないので
そうですマネージャーに行けるしかない
そうですね
いやー前回のショーが重かったんでねなんかそれを超えたらなんかあとはなんか楽しいかな次ショーもストリームですし
そうですねだいぶ楽しくなってきましたはいじゃあ引き続き次回もよろしくお願いします
今日はありがとうございました
ありがとうございました
ありがとうございました
ありがとうございました
ありがとうございました
