00:09
Yosuke Asai
はい、London Tech TalkのYosuke Asaiです。
Kenさん、今日もよろしくお願いします。
ken
はい、Asaiさん、よろしくお願いします。
Yosuke Asai
はい、ということで久しぶりにホストをやるんですけども、
今日は、Software Mistakes and Trade-offsの第8章の輪読会の収録をやっていきたいと思います。
ということで、この収録の輪読会をしたのが、
たぶん収録している今の1ヶ月くらい前なんで、結構前になっちゃったんですけど、
思い出しながら、その後の学びを活かして何かできたことがあったかとか、
そういうことも踏まえて話ができたらな、みたいなのは思っています。
よろしくお願いします。
Kenさんは、読んだと思うんですけど、今回は参加はしていないんですね。
ken
そうそう、参加できなかったんですよね。
だから、この収録を通して思い出す感じでいこうかなと思っています。
Yosuke Asai
ゲストの紹介を忘れていました、今日てっぺいさんが来ています。
てっぺいさん、よろしくお願いします。
Teppei Iwaoka
よろしくお願いします。
Yosuke Asai
一応自己紹介しておきますか、初めての方のために。
Teppei Iwaoka
はい、そうですね、初めての方は初めまして。
大阪でソフトウェアエンジニアをやっているてっぺいです。
リンドク会は前回のDDIAのときから参加させていただいてまして、
自分の関心からちょっと外れたところの技術の理解を深められたりとか、
参加者の中で交流することで技術を学ぶ影響をいただいたりとかっていうところがあって、
すごく楽しんでリンドク会に参加させていただいています。
よろしくお願いします。
Yosuke Asai
よろしくお願いします。
最近は結構忙しいですか、てっぺいさんは。
大学院もあって仕事もあってどんな感じですか。
Teppei Iwaoka
そうですね、仕事はだいぶ慣れてきて、
徐々に重要度の高いタスクとかを任せてもらえるようになってきて、
すごく楽しくなってきたなっていう感覚ですね。
ken
いいね。
Teppei Iwaoka
あと大学院の方がちょうど今学期が終わるタイミングなので、
ちょっと少し楽になってきたっていうような感じですね。
Yosuke Asai
もう2期目が終わるってことだよね。
Teppei Iwaoka
そうですね、なので3つ授業を取り終えることになるっていう感じになります。
Yosuke Asai
ちなみに何の授業を取ったんですか、今期は。
Teppei Iwaoka
今期はネットワークの授業と、
あとソフトウェアデベロップメントプロセスっていう、
ソフトウェアエンジニアが普通に普段やってるようなことを改めて復習するような内容と、
Yosuke Asai
そんな2つの授業を取ってましたね。
ken
例えばなんですか、ギットの使い方とかCICDとかそういうやつ。
Teppei Iwaoka
本当にCICDまで行かなくて、
本当に基礎的なところをやったような感覚で、
結構簡単だったなっていう印象なんですけど、
本当に一番最初の課題はギットにコミットしてプッシュしてみたいなところから始まって、
最後らへんになってくるとテストドリブンなデベロップメントとか、
アジャイルの開発手法とかそういうところまで学んでいくような感じだったんです。
結構普通にソフトウェアエンジニアとして働いていたら馴染みのあるような内容でしたね。
ken
なるほどね。美経験者とかも想定してるから、
そういうのを一つ挟んどいた方が業務にスムーズに入れるみたいなのも、
きっと想定してるんでしょうね。
そうですね。
てっぺえさん的には簡単かもね。
Teppei Iwaoka
そうですね。個人的には簡単だったし、
評判も結構評価がまとめられてるサイトみたいなのがあって、
そこを見たらわかるんですね。
なんかディフィカルティっていう数字が5段階でいくつかみたいになってて、
それが確か2.2とかそれくらい結構簡単なやつだったんで、
簡単だろうなっていうのは想定してたんですけど、
やった目的としては、この授業はチーム開発が入ってて、
それをちょっと経験してみたいなっていうところがあって参加してみました。
英語とかでちょっとやっていけるか自信がないなっていうところもあったんですけど、
内容的にはたぶんついていけるだろうから、
このちょっと簡単な授業で一発挟んでみようかなみたいなところで1個取ってみました。
Yosuke Asai
ちなみにチームメンバーはスコファイに広がってるんですか?
どんなところに行くんですか?
Teppei Iwaoka
そうですね。
一応タイムゾーンを考慮してチームを組んでくれるみたいで、
なんですけど、香港にいる人が1人、
あとアメリカにいる人が2人っていうような感じでしたね。
どういう考慮をして地理的な組み合わせになってるのかわからないんですけど、
でも全員香港の方と中国人2人とっていう感じで、
アジア系の方が多かったですね。
それも意図してるのかしてないのかちょっとわかんないんですけど、
でも結構新鮮な感じでした。
会社の外で英語で何かプロジェクトを進めてるっていうことを初めてやったので、
ちょっとすごく不安だったんですけど、
なんとなくこの経験を通してやっていけそうだなっていう自信が若干身についたなと思ってます。
ken
その他の3人とは仲良くなりました?
Teppei Iwaoka
なんか仲良く、多少ですね。
1人はすごい日本のカレーに興味があるみたいで、
ken
美味しいカレーの作り方教えてくれないみたいなメッセージのやり取りするぐらいの仲良くなる程度にはなりましたね。
それは仲良いね。
Teppei Iwaoka
ぼちぼちって感じですね。
Yosuke Asai
ロンドンテックトークの開発をしたから初めてじゃないかなと思ったんですけど、
でも確かに外国人とやるっていうのはやってなかったので、
それはまた新しい経験です。
けんさんは風邪ひかれてるって言ってましたけど大丈夫ですか?
ken
週末オンコールだったんですよ。
週末は24時間体制なんですよね。
昔別の収録で言ったかもしれないけど、
ウィークデーは平日は自分のワーキングアワー、起きてる時間、日中だけだから、
深夜カバーしなきゃいけないというのがないんですけど、
土日はみんなで持ち回りで24時間回してて、
2ヶ月に1回ぐらいと頻度は少ないんだけど、
その日は夜中の2時から次の日の2時までカバーするみたいな感じですね。
だから運が悪いと深夜3時とかに来るんですよ、ページが。
ピピピピって言って起きて、うわー来たーって言って、
それでちょっと寝不足になっちゃって、
ダブルパンチという感じで、
収録を1回リスクしてもらったんだよね。
Yosuke Asai
アラートが来なくても寝れないですよね。
ken
アラートが来るかもとものが寝てるとちょっと眠りが遅くなる。
その通りですよ、本当に。構えて寝るから。
Yosuke Asai
お疲れ様でした。
1ヶ月の方はとりあえずないと。
土日の運行以外はこれから。
ありがとうございます。
ということで本題に入っていきたいと思うんですけども、
データローカリティの活用
Yosuke Asai
今回のトピックは、
Leveraging Data Locality and Memory of Your Machinesということで、
データのローカリティーとかメモリーをいかに活かすかみたいな
トピックだったと思っています。
簡単にようやくというか、
自分のまとめをすると、
最初はデータ分析よりの話で、
これまでの話と経緯が結構違ったんですけど、
データがあるノードでコンピューティングする、
集約するときにJavaアプリケーションのノードから
データを取ってきて集約するよりも、
実際にデータのあるノードで集約した方が早いよねとか、
そういったデータをローカルでいかに処理することで、
効率よくデータを処理できるかみたいな話から始まって、
後半はどうやってデータをジョインしていくかみたいな、
効率よくジョインしていくかという話で、
基本的にはシステムでデータが分散しているので、
分散しているノード間でいかにデータをやり取りするかみたいな話とか、
後は一番最後はApache Sparkの例が結構出てきて、
多分この作者の方がApache Sparkがかなり得意で、
Apache Sparkの利用
Yosuke Asai
Apache Sparkに寄せた解決策みたいなところを結構話したと思うんですけども、
Apache Sparkを使っていかにメモリ上でその処理すれば、
どれだけディスクから読み書きするよりも早くできるかみたいな話が結構あったかなと思っています。
ken
ちょっと何か足りないことがあれば補足してください。
だいぶ経路変わりましたよね、この章からね。
Yosuke Asai
そうですね。
ken
今まではアプリケーションレイヤーの素敵なモデリングとか、
素晴らしいアブソラクションみたいな感じだったけど、
いきなりDDIAのおつまみみたいな章がポンと出てきて、
僕は楽しかったけど、
でもここの3人みんなDDIA読んでるから、
それから比べると何か物足りない感じもあったんじゃないかなと思うというか、
だいぶすっ飛ばしたなみたいな。
本当に触りだけというかキーワードがね、
データローカリティーとか、
Moving Computation to Dataとか、
パーティショニング、シャーディング、ブロードキャッシングジョインみたいな、
もう聞いたことあるねみたいな、
振り返りという感じで僕は良かったかなと思います。
Teppei Iwaoka
多分これをいきなりDDIAを挟まずに読んでたら多分、
あんまり何言ってるのかさっぱりわからないみたいな状況だったかなと思うんですけど、
DDIA読んでたから結構すんなり入ってきて、
なんかちょっと自分できるようになってきたかなみたいな自信がついた章でもありましたね。
ken
いいね。
確かにこれDDIAみたいなの興味がなかったり、
いきなり読んだりすると、
なんでこの人スパークのポジショントークしてるのかなみたいな、
データのジョイニング
ken
いきなりちょっと困っちゃうやつだね。
Yosuke Asai
読み飛ばしたくなるような感じはあるでしょうでしたけど、
なんか一般的じゃない内容だったんで、
なんていうか、だってはありましたけれども、
なんてこのデータの分析的なところも、
今のアプリケーション開発とかなり結びつくことが多いので、
やっぱり知っておいた方がいいなっていうか、
こういうところに詳しくなっておきたいなみたいなことは個人的にはすごい思いました。
なんかこの本を読んで、
僕はすごい勉強になったみたいなのありますか、てっぺいさん。
Teppei Iwaoka
そうですね。
なんかこう、
普段の業務であんまりこういうデータ分析系の業務はしないので、
すぐに活かせそうだなっていうところはパッと思いつかないんですけど、
何かそういう業務が今後出てきたときに、
パッとチャレンジ飛び込めるような下準備を作れたなっていう感じはしてて、
データはデータのある場所で計算した方が効率的だよっていうのが
特にここのメインのポイントかなと思うんですけど、
それとかもなんか、
うっかりデータを持ってきてから処理してしまうみたいなちょっとおバカなことをしてしまいかねない
ことかところかなと思うんですけど、
これを知ることでそういう基本的に大事にしておかないといけないことっていうのを
抑えられたかなって思ってます。
ken
なんだろう、こうバックエンド、
この章に限って言うと完全に対象としてジョブロールが違うなと思ってて、
今までの章だったら割とバックエンドディベロッパーとか
フロントエンドディベロッパーとかソフトウェアディベロッパーだったけど、
ここはこの章だけは例えばデータエンジニアとかデータプラットフォームエンジニアみたいな、
あとはスタートアップのSREというかプラットフォームエンジニアリング的な
なんかいう感じになっていて、
例えばこのディベロッパーの方がこの章を読んだときに
なんかどこまでこう、
なんだろうね、勉強になったと感じるかも。
本当にその人の興味関心次第でいいんじゃないかなと僕は思っていて、
別になんかここの書いてるスパークの話とか全然分かんなくても
キャリアを進めていける人っていっぱいいると思うんで、ディベロッパーで。
なんかすごいこうジェネラリスト的な本の書き方をする人だなと思ってて、
なんか自分が好きなこととか得意なことを衝立てで書いているから、
全部の内容を完全に理解しなくても、
僕らが今ブッククラブでやってるように興味ないところはスキップしたりとか、
読者の理解を促進するためには程よく内容を取り入れることが重要
ken
そういう読み方が全然できるような本かなというのは思いましたね。
Yosuke Asai
確かに。
スパークもよく調べてみると結構大規模向けっていう認識なんですけど、
やっぱりこの大規模向けなスパークを使える環境にある人も結構少ないのかなと思ったので、
やっぱりそういうふうに読みとかしてというか、
程よく取り込むみたいな感じののがいいのかなと思いました。
ちょっと今回ケンさんがディスカッションのところでいろいろいい質問をしてくさっていて、
一つが普段の業務でデータローカリティーを意識して実装したことはありますかっていう質問で、
これはあんまり回答なかったんですけど、
本社さんがちょっと話してまして、
そこではマテリアライズドビューを作って、
データローカリティの実装経験について
Yosuke Asai
作られている石板でやろうとしているという話をされていて、
もう一個の質問で、
Apache HadoopとかApache Sparkとか今回出てきたようなツールを使って
データパイプラインの構築をしたことがありますかとか、
そういうフレームワークを使ったことがありますかという質問があって、
こっちは結構回答があったので、
ken
このてっぺいさんのコメントを詳しく深掘りしてみたいです。
Teppei Iwaoka
そうですね。
Apache SparkとかHadoopとかは使っていないんで、
直接的な回答にはならないんですけど、
ちょっとそれに似たようなデータパイプラインという意味では、
若干経験があるなというところで回答させていただいたんですけど、
前職でレコメンデーションの会社で働いていたときに、
ユーザーからのリクエストを受けて、
特に3つ種類があって、
閲覧の行動とクリックと購入というパーチェスという3つのイベントを
常にログとして吐き出しておいて、
それをS3に対比しておくみたいなことを
常にリアルタイムで流していて、
そのデータを日時でバッチ処理をして、
ちょっとどういう分割だったかわからないんですけど、
ラムダというものを、
AWSのラムダを使って中間データをS3に作っていって、
何個かのラムダを組み合わせて、
最終的な集計結果を作成して、
それを最終的な請求のデータに利用するみたいなことをやってました。
自分はそこの実装とかはしたわけではなかったんですけど、
そのデータを見るってことはたまにしていて、
大きな修正とかを入れたときに、
過去24時間分のログからリクエストを再生成して、
そのデータログをさっき言ったバッチ処理にかけて、
請求データを作成したときに、
実際に出ていた値と再生成した値が一致しているか確認することは何度かやってて、
その際に中間データを見てどこの時点でおかしかったのかな、
みたいなところを分析するみたいなことをやってて、
その時にアテナでクエリを投げて、中間データを見に行って、
みたいなことをやってましたっていうところぐらいが、
データパイプラインの構築について
Teppei Iwaoka
自分が唯一ある経験としてになりますね。
ken
これ面白そうですね。
日時のバッチって言ってるのが、いわゆるAWS Lambda Functionで実行しているところの話。
Teppei Iwaoka
そうですね。
たぶんラムダの中から次のラムダをチェーンしていくような形で、
いくつか中間データを作って最終的な結果にするみたいなことをやってたと思います。
ken
そこで作った中間データってざっくりどういう分け方してたか覚えてます。
たぶんこれがいわゆるシャーディング、パーティショニング的な考え方だと思うんですよね。
たとえばその日時のデータをガッと引っ張ってくるじゃん。
あわりとかで、あわり別に集計して中間データとしたのかとか、
もしくはユーザーのIDか何かから、
たとえばモジュールで常用で適当にパーティショニングしたのかとか、
あとユーザーIDの連番、1から1000、1000から2000とかでしたのかとかって、
たぶんそれなのかそういうことをせずに、
日時データが多分S3にヒットファイルとしてあり、
それをまるっとラムダで取っちゃって、まるっと加工して投げるみたいな。
ここ聞きたかったのは、この観点で今回のショーにもあったキーワード、
パーティショニングとかシャーディング的なことって何かしてたか、
もし覚えてたら聞いてみたいなっていう。
Teppei Iwaoka
そうですね。
これがパーティショニングなのかと言われるとちょっと違う気もしてるんですけど、
具体的にどういう分け方かってすごく明確に覚えてるわけではないんですけど、
どういうふうに請求のデータにつなげていくかっていうところで、
例えば閲覧のデータがレコメンド経由でクリックされたとか、
レコメンド経由で購入されたみたいなことを判定するために、
セッションが何時間続いていて、その中にクリックが起きているかとか、
購入のイベントが起きているかみたいなことを確認した上で、
最終的な請求データにつなげていくんですけど、
例えば全体のログの中から次の段階としてはセッションがつながっているクリックのイベントとか、
そういう感じで分けていっているっていうような感じでしたね。
ken
具体的なところが。
書き用によっては全然インフラコストの上振れしそうだし、
例えばS3の課金モデルってちょっと覚えてないですけど、
あれは単純にストレージ量だけだったかな、書き込み読み込みのネットワーク転送量とかによっても変わってきたか忘れてないですけど、
ラムダも結構メモリ食いそうですし、割と技術力が試されそうな運用設計になりそうですね。
ここらへんのツーリングは浅井くん使ったことあります?S3、ラムダって。
Yosuke Asai
今のときは使ってますけど、
確かにリーカー出してくると、でもエグレスってなんか料金が確かあって、
ラムダのネットワークはコストはなくないはずで、
ただメモリの使用量と実行時間に応じて課金されるという感じだと思うので、
実行時間が伸びたりメモリ使いすぎたりするとやっぱり金がかかっちゃうという感じだと思います。
ken
こういうのってデータのバリデーションとかも難しくないですか?
そういうシチュエーションがあったかわからないけど。
バグ押し込んだときにね。
Yosuke Asai
セーキュレーターに反映されるってことを、
例えばイベントをクリックすると10倍カウントしちゃったら
請求も10倍になっちゃうみたいな、
そういうのってどうやって対応するのかっていうのが気になります。
Teppei Iwaoka
たぶん賢いバリデーションっていうのはあんまり入ってなかったと思ってて、
最終的に出た結果をお客さんに確認してもらって、
それをお客さんが承認して初めて実際請求書を出すみたいな感じになってて、
そこは割と人間の目で頑張っていたのかなと思っています。
Yosuke Asai
DDIAのバッチプロセッシングとかのショーを思い出したんですけど、
バッチだったらやり直しができるみたいなのがあって、
もしバグを押し込んだりしてデータが間違ったりとか、
途中失敗してももう一回やり直せますみたいなのがあって、
そういう機構とかあるのかなみたいなのが、
ここまで詳しくわかんないかもしれないですけど。
ken
元データを削除しなければ、中間データっていうものなんで、
Linuxっていう添付ファイルみたいな感じなんで、
いくらでも上書きすればいいと思うんですよね。
元データさえちゃんと保存していれば。
ただ問題は現実問題、あんまりそれをやりまくっていると、
バッチを何回も回さなきゃいけないし、
運用も大変だし、ユーザーからの信頼も、
また間違ってますけどみたいな感じになっちゃうし、
回すたびにインフラコストもかかるんで、
あんまりスマートじゃないよねっていうのがあるので。
Teppei Iwaoka
実際に間違っていた処理が、
細かい計算でとかっていうよりも、
この月に請求を出すかどうかみたいなフラグを入れて、
初めて請求データが作られるみたいなことがあったりするんですけど、
それを運用側が付け忘れていたから請求データが作られてなくて、
その顧客のために再度回し直してみたいなことはやってましたね。
なのでちょくちょく回し直しがあったのと、
あとさっきの話だと、クリックのデータ、ログ自体がちゃんと出てて、
その元データがあって回し直しは全然できるんですけど、
ログ自体が10倍出ちゃっていたら、
それはちょっともうどうしようもない状況なのかなと思いますね。
ken
そうだね、確かに。
だから中間データの書き込みと読み込みをするそれぞれのラムダで、
ちゃんと単体テスト的なのを書いてコードで担保しつつ、
なるべく別のバリデーション用のラムダを書いたりとかして、
ユーザーに出すまでに自分たちで検証する術を書くとかになるんですかね。
Yosuke Asai
この内容ってやっぱりメモリを使おうっていう、
この後半の観点からちょっと逆を言ってるとは言わないですけど、
メモリを使ってメモリ上で処理していくというよりは、
毎回S3に読み込んで書き出してみたいなのをやってると思うんで、
そういう点で改善できそうだなみたいなところって、
Teppei Iwaoka
てっぺいさんなんかありますか、この章を。
そうですね、ちょっと料金がどうなるのかっていうのが一つと、
あとスピードがどうなるのかっていう二つが結構大事なのかなと思ってて、
メモリを使うようなスパークみたいなのを使ったときに、
S3に毎回置いて読み書きしているときよりも安くなるのかっていうのはちょっとわからないので、
もしそこが安くなるなら一つそこは改善できるのかなっていうところと、
あとメモリを使ったスパークみたいな処理を使うメリットとして、
ディスクのときよりも素早くなるっていうところがあるのかなと思うんですけど、
今回のケースで言うと1日1回とか回す程度の処理で、
それが全然1日で収まりきらないとかっていう感じでもなく、
何回も別に回し直してもそんなに困ることもないみたいな状況だったので、
速度っていう意味ではそこまで改善する必要もなかったのかなっていうふうに感じてますね。
Yosuke Asai
ありがとうございます。
ken
ビジネス要件がそこまで厳しくないのであれば、
エンジニアリングリソースをかけて作り込まなくてもいいよねっていうのは本当にその通りだと思いますね。
ちなみにこういうのっててっぺいさん好きな感じですか?
それとも面倒くさいですか?
どういう開発業務が好きなのかなと思って。
Teppei Iwaoka
そうですね、でも好きですね。
ただ経験はあんまりなくて、前の会社でこの話とかは、
わりと技術の深いところが求められるところだったなっていうのが唯一あるぐらいの経験なんですけど、
世界であんまりこういう経験はしてきてないので、どちらかというと今の業務とかでもそういう経験があんまりなくて、
より深いところに携わっていきたいなみたいな思いは常にありますね。
ken
いいっすよね。だから多分本当にコメント書いてくれてるけど、
てっぺいさんがこれをやった頃はこういうの初めてだし楽しいなと思ってやってたけど、
多分それから経験も積んでDDI名を読み、大学院でも似たようなことを勉強したら、
もうその時作ったシステムが日時バッチで物足りないみたいになってきた感じだと思うので、
これが例えばリアルタイムで求められるようなシステムを作るとか、
そういったところにチャレンジしていきたいなってなっていくのは自然ですよね。
Teppei Iwaoka
そうですね。ちょっと話それてしまうんですけど、
大学院の授業の方ではそういう分散処理とか、
ハイパフォーマンスコンピューティングとかそういう授業とかも、
あとクラウドコンピューティングとかそういうちょっと難しそうな授業もこれからあって、
そういうのも積極的にチャレンジしていこうかなと思ってますね。
ken
いいっすね。
分散システムここら辺の学習の一番の課題って、
個人開発めちゃくちゃしづらいと思うんですよ。
そんなコストもかけられないし、
あとやっぱり学校もテッペさんが言ってるね、
大学がどこまで支援してくれるかだけど、
例えば大学院とかコーセラーのクラスによっては、
フリーで使える枠とか提供してくれるけど、
かといってどこまで自分でかけるかってのが違うから、
データパイプラインの構築
ken
やっぱり業務でやった方が経験になったりとかなっちゃうんですよね。
なるべくコンピュータサイエンスの理論的な話で、
メンタルモデルは考えるけど、
実際のコーディングみたいなのは、
なかなか個人開発ではしづらいところですよね。
Teppei Iwaoka
まさにそうですね。
すごく頭でっかちになっていってしまってる感がありますね。
DDIAもそうですし、この本もそうで、
これを身につけて一回理解したつもりになっても、
それを吐き出す場がちょっと今のところ持ててないので、
何とか見つけられたらいいなと常々感じてますね。
ken
そうだよね。すごい同意です。
Yosuke Asai
それに関連して言うと、
最近僕もデータ関連の仕事が増えてきて、
まさにベイさんが言ってたような、
請求関連のデータを今の使用率とかから出そうみたいなプロジェクトがあるんですけど、
やっぱりこれを一から実装するといって、
いろいろ議論をしていて、
僕はやっぱりDDIAとかを読んだので、
そういう内容を生かしてというか、
そういった背景を踏まえて提案とかしてるんですけど、
自分が持っている知識とか前提と、
実際にチームメンバーが持っている知識と前提が結構違って、
これを一から説明すると結構難しかったりとか、
例えばバッチのところでやった通信プリンシパルみたいなやつがあったと思うんですけど、
そういうデータを、生のデータを持っておいた方が、
加工されたデータを持っておくよりもいいみたいなのがあって、
画像の生のデータを持っておく理由はこういうのであって、
説明するのも結構時間がかかるというか、
そういう前提が違う時間がかかって難しいなというのがあったんで、
本で得た知識を実際に生かそうと思って、
それがチームで開発しようと思うと結構、
人との認識合わせがやっぱり難しいな、
自分の知識をこれが正しいと思うよというのを伝える上で、
そのコンテキストをうまく伝えながら納得してもらうというのは、
やっぱりすごい難しいなというのをすごい感じてますね。
Teppei Iwaoka
会社でも輪読会したらいいんじゃないですか。
Yosuke Asai
確かに輪読会するか、チームでも。
Teppei Iwaoka
コンテキストめっちゃ合うと思う。
Yosuke Asai
これはめちゃくちゃいいアイデア。
ken
それめちゃくちゃいい経験じゃない。
だって本読んだだけだったら意味ないからさ、
それを生きた経験にコンバートしなきゃいけなくて、
その本で読んだ知識を誰か分かってない人に説明する。
説明できて初めて自分も分かったと言えると思うんで、
説明する相手が中学生じゃないだけ、
多分まだバッシャーだと思いますよ。
Yosuke Asai
確かに。
ken
あるじゃないですか、猿でも分かるギットとかさ、
中学生にも分かる資本主義みたいな感じで、
それよりは普通のCSの基礎がある大人に説明する方が
全然イージーだと思うんで。
Yosuke Asai
あと普通にその本の内容が正しくて、
データ基盤チームの役割
Yosuke Asai
自分も理解していても、
それが適応する場所が間違ってる可能性があって、
こういうのはいいと思いますって言って、
確かに自分が間違ってるなって思うこともあるんで、
説明してみて違うなって思うこともあって、
ストレートオフがあるんで、
そういうのもまたいいですね、
実際に議論の間違いがあってみたいな。
ken
いいよね、それ。
Yosuke Asai
本さんはちなみに何かありますか?
めちゃくちゃ経験あると思うんですけど、
データファイプラインの構築とかを読んで、
ここが良かったなとか、こんなに良かったなとか、
もしくはこういう結果思い出したとかありますか?
ken
そうですね。
ただ僕もApache HadoopとかSparkを業務でがっつり使った経験はないので、
Apache Spark知ってるよっていう風ではあんまり話せないので、
なんかApache SparkのデータセットのAPIとか、
あとはなんだっけかな。
なんかそこら辺の細かい話は普通に勉強になったし、
そのApache Spark出てるRDD、Resilient Distributed Data Setみたいな、
なんか存在も知らなかったし、
なんか細かい話は結構勉強になりましたね。
ただ正直この原則のSREになってからは、
割とデータパイプラインを自分の手を動かして作るっていうのは、
ご無沙汰してるので、2年弱ぐらい。
まあなんかこう思い返しながら読んだかな。
Yosuke Asai
なんかまたやっぱいいなと思いました。
RDDとかこういう仕事。
ken
いやあ、いい質問だね。
やりたいけど、今の原則の今のSREロールでもまだやりたいこともあるからって感じ。
やりたいことはいっぱいあるよ。
やりたいことはいっぱいあるよね。
こういうのね、なんか技術コーナーとかそういう副業とかできるといいんだけど。
Teppei Iwaoka
けんさんの今の会社ではどういうロールの方がそういう構築みたいなのされているんですか。
ken
会社が大きいから専門のチームがいるんですよね。
データ基盤チーム的なところがいて、
そこらへんが例えばデータ基盤を新しく刷新します、
マイグレーションしますとかこういったチューニングしますとかっていうのを作っている。
僕が例えば前職前々職にいたときはSREというロールだったんですが、
500人ぐらいの会社だったのでSREの中でデータプラットフォームエンジニアリング的なところとかも
中途半端に持ってたのでやる機会があったという感じ。
ただここでも本当にSREの中のレジリエンシーマネジメントとかインシデントハンドリングだけなので
データパイプラインをコードを書いて書くってことはもう一切ない。
Teppei Iwaoka
会社の規模とかによって結構誰っていうかどの所属の人がやるかっていうのは変わってくるんですね。
ken
そうそうそうそう。
議論と役割の違い
ken
いいところは、いいですよ。
Teppei Iwaoka
いや、自分もいつかそういうことにもチャレンジしてみたいなって思うんですけど、
じゃあどういう職種の人がやってるんだろうっていうのがちょっと気になっての質問でした。
ken
Octopus Energyさんとかと、じゃあこれをやってるのはどこになるわけ?SRE、データパイプラインってある?
Teppei Iwaoka
いや、プラットフォームエンジニアっていう職種の方がいらっしゃるんですけど、
でもその方がデータパイプラインを構築しているかというと分かんないですね。
確かに社内を見てみるともう少しこう見えてくることがあるかもしれないですね。
ken
そっかそっか。Octopusもどっちかというと、
普段何気なく。
Teppei Iwaoka
そうですね。何気なくデータパイプラインとかって使ってしまうことが多くて、
じゃあ中身誰が作ったんだろうみたいなこと、構築したんだろうみたいなことって気にかけてなかったんですけど、
気にかけるとこういう人の努力があるんだなっていうのがちゃんと見えたりするなっていうちょっと気づきでしたね。
ken
そうだよね。
Yosuke Asai
他に何かここが気になったみたいな話はありますか?
今回そもそも参加した3人だった気がするんで、連続会は。
ちょっとみなさん予定がなかなかつけられないので。
けんたさんと3人でやったんですけど。
けんたさんは、そうですね、ちょっとトレードオフが分かりづらくなっているっていうコメントがあってね。
確かに今回は分かりづらかった。どれを取りたいか。
分かる。
それはちょっと面白かったです。
そんなもんですかね、今日は。
ken
そうですね。
Yosuke Asai
今回は第8章の連続会の内容をてっぺんさん、けんさんと話しました。
ありがとうございました。
ken
はい、ありがとうございました。
Teppei Iwaoka
ありがとうございました。