ストリーミングの基本
Kenさん、今日もよろしくお願いします。
はい、よろしくお願いします。
今日はですね、DDIAの第11章、ストリーミングプロセッシングの引読会後の収録になります。
今日はゲストとしてトモシタさんをお呼びしています。トモシタさん、よろしくお願いします。
はい、よろしくお願いします。
トモシタさんをお呼びしたのはですね、トモシタさんがこのストリーミングにおいて、すごい専門家というか、かなり詳しい方なので、今回お呼びさせていただいてましてですね、
いろいろ話していただこうかなというふうに思っています。トモシタさんは今アメリカに住まれていると思いますけど、こちらの気候とかはどうですかね?今11月ですけど。
そうですね、ロサンゼルスはやっぱり一番気候のいいところとして知られていて、結構真冬でも朝はちょっと涼しくて10度を切ることはありますけども、日中はもう一年中20度から25度を超える。
しかも、
夏があんまり暑くないっていう、非常に海辺の近くでいいところですね。
めっちゃいいですね。
今日も朝が15度ぐらいで、昼はもう25度を超えてくると思いますね。
いや、いいな。
最高だな。
こっち、今ジネーブだと10度を超えないので、本当にうらやましいです。晴れる日も少ないですし。
ダメダメ、ヨーロッパと比べちゃダメですよ。
ヨーロッパと比べちゃダメですって、もう。
そうですよね。
ここでロンドンワーとか、もう僕行っちゃ負けだと思ってるんで。
そっかそっか、そうだ。ダメです。寝かけ足ダメですね。いいとこです。ジュニアウェブもいいとこです。
ヨーロッパも行ってみたいなと思いますね。
ぜひ夏に来てください。
やっぱり夏が過ごしやすいですよね。
夏最高ですね。
ちなみに週末とかはどういうことされてるんですか?
そうですね。うち、子供がいるので。
なんか、子供がやりたいことをやるっていうのが多いんですけれども。
今週うちの子供が、学校で月に一人、スチューデントオブザマンスっていうのが発表されるんですけれども。
それはなんか、月に、その月頑張っていたクラスの子供が表彰されるみたいなので。
うちの子が、久しぶりに今月表彰されたので。
おー、すごい。
めでたい。おめでとうございます。
ありがとうございます。
いいですね。
なので、なんか、あの、コンバースの靴を買いに行くかもしれません。
あ、ご褒美ですか。
はい、ご褒美で。
いいですね。
コンバースが好きなんですか、お子さん。
コンバース好きみたいでね、なんかもう本当に、あの、僕らの時から変わっていない、あの、ハイカットの靴を、同じの2個3個持っていますね。
え、それ色も同じなんですか?
なんか、今回色は変えるかもしれないとか。
あ、なんかおかしい。
おしゃれ。
いいですね。
高校生、高校1年生ですね。
あ、高校1年生。
うん。
友下さんの奥さんって、日本の方じゃないですかね。
あ、そうですね。
あの、写真見たんですけど、はい。
はいはい、あの、メキシコ人なんですね。
あ、そうなんですね、はい。
えー、そちらで出会われたんですか、アメリカに行かれてから。
そうですね、アメリカに旅行に行った時に会って、あの、ま、あの、文通みたいなのをしてみたいな、そんな感じで。
えー、あ、文通、すごい。
半分メキシコ人みたいな感じです、僕は。
はい。
文化も。
あ、そうなんですね。
じゃあ、スペイン語とかも。
手書きの、手紙の方から。
いやいや、もう、さすがに。
メール。
あの、メールです。ただ、eメールとかでしたね。当時は、あの、あんまり、あの、やっぱり、国際メッセージとか高かったので、eメールとかでした。
あ、いいな。
へー、そう、めちゃくちゃロマンチック。
トモシタさんの経験と研究
いいですね。
うん。
何か、あの、こっから、ストリーミングに繋がる話があるかなと思ったんですけども。
w
どうつなげるの。
w
ふははは、ちょっとなかったですね。はい。ちょっとじゃあ、じゃ、えーと、今回のショーの。
はい。
まとめ、まとめというのを入って行こうと思うんですけれども。
お願いします。
はい。一応、前回バッジのショーがありまして、まぁ、バッジでは、まぁ、Batchmatesとしては、まぁ、バッジの、一定、一定期間にたまったデータを、まぁ、送って、入力したりとか。
うん。
はい。
そうですね、まあ、ね。
まぁ、きちんと。
はい。
入力としてそれを処理して出力するみたいな処理なので
入力に影響を与えることがないっていうのがバッジのメリットでして
何度も繰り返して実行できるみたいなところがあって
障害にも強いみたいなところがバッジのメリットとしてあったと思うんですけども
一方でバッジを使うとリアルタイムで流したいデータとかに対応できないので
それに対応するために今回やっているストリーミングっていうのが
使われているというところかなというふうに思います
ストリーミングだと皆さんがよく知っているようなメッセージブローカーとか
メッセージキューみたいなのがあって
定期的にデータを受け取ってそれを流していくみたいなのとか
あとはログを使ったストリーミングとかもあって
この辺は友達さんがすごい詳しいところなのかなというふうに
思っているのでぜひ話していただこうかなというふうに思っています
ちょっとじゃあまずケンさん
これ今回2回目読んだと思うんですけども
読んでみてなんかどうでしたか
相変わらず大好きな章ですね
1回読んだ時にはちょうど多分
ストリーム処理かじってて現場で実装してたみたいな頃で
よくわからんけどなんか面白いみたいな感じで読んでたんですよね
はい
その後に2個3個作ってから振り返ってみると
なんか自分の当時を思い出しながら
わからないなりにも頑張ってたのを思い出して
なんかいい章だなと思いました
そうですよね
この章の最後の方に思い出の
思い出のストリーミング処理みたいな
ディスカッショントピックを作ったんですけど
ケンさんの出てくる量がすごいなっていう
過去のブログとか
読み切れないくらいブログが張ってあって
すごいやられつつなんだっていうのが
はい分かりましたけど
多分なんかよくある流れですけど
まず最初にRDBMS
僕の場合マイシークエルとかをやった後で
なんかそれだけではない
自分の強みを出すみたいなところで
ストリーム処理を頑張ったところがあるので
そういう意味でも面白かったな
そんなところですね僕は
これ友久さんがストリーム詳しいからっていうところで
呼ばれていると思うんですけど
そこら辺をちょっとね
グレック・ヤングの動画
最初の方に詳しく聞いてみたい
確かに背景を聞きたいですね
そうですね
大体この1年半ぐらいですかね
私たちも以前はといって
今の会社では
メインではRDBを使っているんですけれども
ちょっと長めの話でいくと
まず会社でDDDっていうのが
流行ったんですね
ドメインドリブンデザインっていう
コードを書くときにちゃんとレイヤーを分けて
しっかりドメインのビジネスロジックを
分離して書きましょうっていう
それが4,5年前から流行っていて
いろいろそれを導入することによって
かなりバグが少ないシステムを作るとか
そういう意識が会社の中で上がっていってきて
会社の中で
その振り返りをしたときに出てきたのが
やっぱりトランザクションによって
結構問題が起きやすいとか
もうちょっといい方法がないのかとか
そういうディスカッションをいろいろした中で
出てきたのが
ドキュメントDBを使えばいいんじゃないかみたいな
分散システムに対応しているらしいから
ちょっとそれを使ったらいいんじゃないかみたいなところで
結構いろいろ
ドキュメントDBをうまく使う方法について探した中で
イベントソーシングがあるっていうのが見つかって
私もその前はそんなにストリーミング自体も詳しくなくて
マジュールファンクションとかで
いわゆる非同期のストリーミングは使っていたんですけれども
それでシステムを作るっていうところまでは行ってなくて
遅延処理みたいな感じで
そういうメッセージングを使っていただけだったんですけれども
いろいろ調べて
このグレック・ヤングっていう人が結構すごい面白い人で
YouTubeで結構1時間ぐらいの講演で
イベントソーシングに説明しているビデオが結構たくさんあるんですけど
その分かりやすさっていうんでしょうかね
すごい非常に物事をシンプルに
説明できる人だなと思うんですけど
イベントソーシングっていうのを使えば
多くの問題が解決されるんだっていうのが
説明されているところを見て
作り始めたっていう感じです
最初 社内システムのために作り始めたんですけれども
日本でまだあんまり流行っていないので
これ オープンソースにするなり
会社として再利用できるものにすれば
結構いいんじゃないかっていう話になって
作り始めて
今1年ちょっと経っているという
そういう状況です
ありがとうございます
まずはDDDから入って
そこからドキュメントDB使ったらいいんじゃないかっていう風になって
さらにグレック・ヤングさんの動画を見て
イベントソーシングに進んでいたという感じですかね
そんな感じです
このYouTube見たんですけど
結構多くも分かりやすいなと思って
英語なんですけど
話もすごい面白い
話し方も面白いですし
内容もすごい分かりやすかったので
半分くらい見たんですけど
動画すごい良かったし
これぜひ使いたいなっていう風に思ったので
めちゃくちゃ勉強になりました
そうなんですよね
特にイベントソーシングって
簡単に言うと
ここで
ストリーミングの章にも書いてますけれども
起きたことを事実として
イベントとして書き込んで
そのイベント一つだけを見ても
現在のステートっていうのは分からないので
そのストリーミング処理なり
このバッジ処理を使って
現在のステートに関しては
キャッシュとして持って
そのキャッシュから
システムに表示するようにしましょう
という風に思っています
でも一番大事なのは
そのイベントなので
そのイベントに関しては
もう一回書き込んだものは
絶対削除しないという形で
管理していきましょうという
そういうものなんですね
いろいろ質問が出てきて
例えば古いデータ間違ってたら
どうするのかとか
そういう疑問が出てくるので
そういうのが結構
シンプルに分かりやすく答えられているのが
YouTubeのグレイクさんの話です
そういう感じがします
このグレックヤングさん自体は
マイクロソフトの人ですか
いや違いますね
グレックヤングは多分
アプリケーションデベロッパーの人で
この
イベントソーシングというのが
2007年8年ぐらいに
彼がやり始めたのは
DDDコミュニティ
このDDDというのは
エヴァンスさん
イベントソーシングの背景
という方が
書いた本で
その
エリック・エヴァンス
エリック・エヴァンスの本で
それをやっているコミュニティの人が
CQRSというのが先に出てきたんですけど
コマンドとクエリを分離したらいいよね
そのためには
イベントソーシングというのを
使ったらいいよねというのが
コミュニティとして出てきたのが
2007、8年で
それがいろいろ温められて
それをやり始めた
グレックヤングが
イベントソーシングを
イベントソーシングの
イベントソーシングの詳細
創始者じゃないですけれども
についてよく話しているという
そういう感じかなと思いますね
なるほど
DDDの本ありますよね
結構熱いやつ
浅井さん読みました?
いや読んでないです
ちょっと懺悔したいんですけど
DDDの本数年前に読んだんですけど
さっぱりよく分からなかったんですよね
そうなんですか?
けんさんでも
結構原本と言われている
エリック・エヴァンスさんの本っていうのは
開発手法については
あんまり述べていなくて
お客さんと調整するプロセスっていうんでしょうかね
仕様をはっきり決めていくには
どうすればよいかみたいな
何を問題として
どこからどこまでを
境界としてシステムを定義していって
それぞれの境界を分離させる
ということが書かれている
その部分が結構多くて
それをシステム作るところまで読むまでに
結構時間かかるみたいな
結構壮大な本になってますね
かなり抽象的な部分に時間が割かれているという感じですかね
なんかあれですかね
オニオンアーキテクチャーとかそういうやつでしたっけ
DDDに関係の
そうですね
DDDのコミュニティで
結構オニオンアーキテクチャーが
用いられているという
そんな感じです
それもあんまり分かりやすくないから
こうした方がいいんじゃないみたいな
図をたまにツイッターで見るときあるんですけど
いろいろそういうのを工夫すれば
分かりやすいんですかね
そうだと思います
社内でどういう風に作るかみたいなのがあるんですけど
どうしてもいろいろ分離するために
レイヤーを分けるので
その途中で渡すための
DTOみたいな
データトランスファーオブジェクトみたいなのが
何回も詰め替えて詰め替えて渡すみたいな
そういうことが起きるので
結構行業しいなと感じるのがあるんですけれども
でも分離することによって
フォーカスできる部分というのを設定できるので
やっぱりバグが出にくいシステムを
作りやすいというのはあると思いますね
ちなみに
今イベントソーシングを
多分開発の途中から
実装していると思うんですけれども
今どのくらい置き換えが進んできているとか
そういうのは分かりますか
開発の途中から
現システムにくっつけて作ったというよりも
最初から別の
イベントソーシング用のフレームワークとして
別プロジェクトで作っていって
現プロジェクトには部分的に入れられるように作っていて
今イベントソーシングを作っているというのが
今中小システムであれば
対応できるぐらいのフレームワークとして
今完成しているところで
今年中にオープンソースとして
リリースしようという
今最終段階になっています
今日のストリーミングシステムの話に戻ると
結構やっぱり
メッセージング的なシステムというんでしょうかね
配信型のシステムというか
のシステムというので
データの整合性を組み立てようと思うと
結構やっぱり時間的な
順序の逆転みたいなのが起きてしまうので
結構大変なんですね
一つの処理がネットワークが落ちて
再接続して取り込もうとする間に
その後にできたイベントの処理が
終わってしまうっていうのが
一番なんかここにも書かれていた
ありがちな問題で
そうすると
例えばお金があって
それを誰かが使うみたいなところで
本当は先にイベントを出した人が先に使って
それが売り切れるみたいな
処理にしないといけないのに
後から入ってきた人が
本当は売り切れていたはずなのに
まだ残っていて
それを買うことができたとか
そういうことがやっぱり起こりうるみたいな
そんな感じの問題があるので
このストリーミングの方式として
ログ型の
実際に扱うときは順序で扱えるという
そういうストリーミング処理っていうのが
カフカのようなものが
マッチする場面が多い
特にこのストリーミングの方式は
特にイベントソーシング的な
動質データを作るときには
順番っていうのが大切なので
イベントソーシングの応用
順番を管理するには
こういうログ型のものを使うのが
いいんじゃないかなっていうのが
この章に書かれていることかなと思いますね
そうですよね
かなりログ型のところを
押しているようなところはある気がしていて
最初に
ログ型のものを使うときに
メッセージQとかの説明がありましたけど
かなりの部分で
ログ型の一部であるCDC
チェンジデータキャプチャーとか
今イベントストリーミングみたいなところが
結構重点的に説明されていたので
確かにそうなんだろうなっていうのは
それでもなお時間の問題があるって感じなんですよね
そうですね
やっぱりそれがさらに分散のサーバーになってくると
なんていうのか
無理みたいな形になってくるので
順番が変わっても
なんとかするシステムはどう作ったらいいか
みたいな話が
もうちょっと後の12章に書かれていたので
そちらの方も
一生懸命読んでいかないといけないな
というところになっています
そうですよね
12章もまた
読むの大変ですね
これは
でも一番面白い章なのかなと
そうですね
聞きました
ちょっと戻ると
CDCっていうのが結構
特にRDBを使っている人にも
役に立っているものかなと思うんですけども
実際そのRDBっていうのは
ステートを管理するシステムで
現在のレコードのデータっていうのを
いつも保存して
それを取得するっていう感じなんですけれども
それを
ディストリビュート
分散していくためには
結局
イベントソーシング的なことっていうんでしょうかね
このデータが
レコードがこういうふうに変わりました
このレコードが削除されましたっていうのを
ログとして持って
そのログを
再生することによって
現在のデータが出せるんですけれども
ちょうどイベントソーシングがやっていることと
ほとんど似ているような仕組みで
ログを
一から再生していくことによって
現在の状態が分かるみたいなのが
データベースの内部では
実際はそれが行われているっていうの
私も昔は知らなかったんですけど
そうなのかっていう感じで
納得しましたね
MySQLだと
Binlogで
Postgreだと
なんだっけな
忘れちゃいました
いろいろデータベースによって
それぞれ異なるCDCの実装が
あるんですよね
その中でも
CDCがそれぞれデータベースで違うっていうのが
使いづらいみたいな話が確かあって
金太さんも言ってたんですけど
その公開APIみたいな
それが公開APIになって
どの実装も
どのデータベースも
同じようなAPIで叩けたらいいんじゃない
みたいな話があったと思うんですけど
そういうのは使えそうですかね
ちょっと僕は使ったことないんですけども
でもやっぱり
なんていうか
安定性を突き詰めると
ログベースっていうのは
この
著者のクレップマンさんの
結論なのかな
そういうふうに感じてますね
ここでちょっと
聞いてみたいというか
ジャンプインしたいところがあるんですけど
Neo4jで実装してた頃も
内部で似たような
システムを使ってたんですよね
データの状態を基本的にずっと
ライターヘッドログみたいなのを入れといて
そのデータベースインスタンスが
スタートアップしたときに
それを最初から舐めていって
現在の状態をステートとして
割り出してからそれをメモリに入れて
はいどうぞ
OKですよクエで受け付けますみたいな感じで
どんどんどんどんログが増えていくので
それが増えていくと
何が問題になるかっていうと
データベースのインスタンスが
立ち上がる時間がどんどん伸びていくんですよ
そのログが少ないときは
30秒ぐらい経ってたのが
ログが伸びていくと3分4分5分となっていって
それで何が問題が起こるかっていうと
例えばフェールオーバーするときとかに
リージョン障害が起こって
別のリージョンに新しくデータベース
立てたいみたいなときに
そのログが長いと
ログを舐めていくコンピュテーション処理が長くなって
フェールオーバーに数分かかりますみたいな
感じになって
それってリライビリティに対しても
良くないってことがあったので
多分POSGREの
ログとかもそうですけども
バキューム処理的な感じ
最新のステートをここまでは処理して
最新の状態これってことで
ステートは計算してメモリに持てるんだけど
ログの方も整合性を壊さない形で
ある程度シュッとスリムにしちゃう
NEO4Jの場合はチェックポイントっていう形をしていて
ここのチェックポイントまでは
このユニークキーのやつは
最新の状態ですよってことで
その前の
キュッとバキュームしてスリムにしたり
みたいなことがあって
なんていうんでしょうね
状態は
全てイミュータブルなログが
入っていて舐めていくとはいえ
アプリケーションレベルでも
バキューム的な処理とかを
実装したくなるときとか
することってありますか
イベントソーシングに関しては
それは
基本的にはしないというのが
基本になりますね
というかというと
イベントソーシングでデータを取っている
理由として
例えばショッピングカートでの話が
よくされるんですけれども
ショッピングカートに
この商品追加しました
やっぱりいらないと思って
その商品を削除しました
で別の商品を追加して購入する
追加して削除した商品に関しては
ステートとしては
今回変わらなかったので
残らないんですけれども
結局後々分析のために
役に立つんですね
こういうで
イベントソーシングのデータ取り扱い
1回商品追加して削除したから
やっぱりもう1回買いたいですか
みたいな
Amazonとかそういうふうにやっていると思いますけれども
そういうことのために
アナライゼーションのために
基本的に使えるという
そういう
事実として
イベントソーシングの場合は
意味あるデータを残すように
というふうに言われていて
その意味あるデータであれば
使わなくて
その場ですぐ使わなくても
将来使うことを見越して残しておく
でスピード
立ち上がりが遅くなるという問題に関しては
スナップショットを取って
チェックポイントっていうのと
同じようなイメージですけれども
途中途中で
そのスナップショットを取っておいて
普通に見るときは
もうそのないものとして
扱うことができるみたいな
そういう感じで
扱うようになっています
なるほど
だからこう
カンサログ的な扱いであったり
過去のユーザーの状態を分析したり
みたいなことで残しておくと
確かにそうですね
データベースを作るという観点と
アプリケーションとして
ビジネス要件として扱うという意味で
確かにそこの違いがありますね
そうなんですよね
だから
CDCのコンパクションの場合は
なくなってもいい
なんか
オンになったりオフになったりしたっていう
なくなってもいい情報なので
クリーニング処理をして
早くするっていうのが
有効になってくるという感じかなと思いますね
なるほど
いや面白いですね
ここら辺の違いを探っていくのも
これでですね
データが大きくなりすぎたら
そんなことできるわけないじゃないか
みたいな話になってくるわけなんですよ
私たちのライブラリーも今
中小企業向けっていうことで作っていて
すごく大きくなったら時に
ハンドルする自信がまだないので
あれなんですけど
理論的には
どうすればいいかっていうのを
今いろいろこの本を読んだりして
勉強しているところで
でも実際にはですね
マテリアライズドビューというので
インメモリで全部取っておくわけじゃないんだけれども
バッチ処理みたいな感じで
マテリアライズドビューの活用
データを一から
再構成しつつ
RDBにそのとき必要なデータを
構成しておくことによって
毎回イベントを見るんじゃなくて
特定の簡単なクエリのときには
マテリアライズドビューのRDBを見るという
そういう形でできるんですね
これが何でできるかというと
過去の削除しないと
約束しているから
ここまで終わったっていうのを
記録さえしておけば
その後の新しいイベントだけ見て
調整すればいいということになります
なので
バッチ処理を
例えば1時間に1遍
30分に1遍
10分に1遍みたいに減らしていくことによって
時間的なずれというのを
できるだけ少なくしていく
という感じになりますね
だからマテリアライズドビューも
一種中間データみたいな形で
アプリケーション側で
自由にいろんな中間データの作り方できるので
それを駆使して
努力作業やっていくという感じですよね
そうですね
なのでマイクロサービス化がしやすいんですね
まとめて
例えば1テラ2テラのデータになっていたとしても
1テラ2テラのデータを各拠点にコピーしておけば
新たに必要なのは
1000回コピーした
あとのその後1日のデータを
ガツンと
それが100メガとか1ギガとか
なるかもしれないですけれども
毎回全部をコピーする必要がない
というので
同期作業がしやすくなっていて
今データの
値段が安くなっているので
実際その使う量の
データというぐらいは
まかなえるようなインフラが
整ってきているんじゃないか
というのが
グレッグヤングさんが言っていたことで
それを言っていたのが
10年前ぐらいなので
さらに今から安くなっていることを考えると
なんとかなるんじゃないかと思って
カフカの利用例
使い始めたという感じですね
なるほど
ハードウェアの進化も
あえまって安くなってきてと
ちなみにチラッと
コピーしてみたいな話もありましたけど
多分コピーするみたいなことを考えて
別リージョンからも読めるようにする
みたいな考えると
今度整合性のこととかも
考えなきゃいけなくなってきたりするんでしょうね
多分コピーしたものはちょっと遅いから
そっちから読むと最新の状態にならなくて
そうですね
なので私たちは
Cosmos DB
自分でデータベースを作るっていうのは
ちょっとハードルが高いなと思って
Cosmos DBの
持っている機能をまず使い始めよう
ということで
Cosmos DBはやっぱり分散にも対応しているし
データのコピーも
勝手にやってくれると
ところがあるので
まずはそれでできるところまで
やってみようと思ってますね
ちょっと今回のところを聞きたいんですけど
アプリケーションが
イベント送信業に吐き出す
ログっていうのは
まずCosmos DBに全部出ていくってことですね
そうなります
でそのCosmos DBが
さらにマテリアライズドビューを
作るようなバッジを書いているって感じですかね
そうですね
Cosmos DBを一定期間中に
このイベントの
その後のイベントを全部くれって言って
それが取ってきて
それをもとにマテリアライズドビューも
調整していったりする
という感じになります
それはRDBだからまた別のデータベースに
作るんでしたっけ
データが少ないときは
それをインメモリに持つことができるんですね
なので
5ギガとか
10ギガとかのサーバーを
AWSなり
Azureで借りていったときに
そこに入りきれる量の
メモリのデータであれば
マテリアライズドビューを
インメモリに持って
何かクエリがあったときに
インメモリから返すことができるので
システム的にも結構早く
扱うことができるみたいな
そういう利点はあります
イベントソーシングが
何でも解決できるような
2にちょっと
僕はこれ読んで思われてしまったんですけど
一方でやっぱりバッジを書いたりとか
っていう悩みも
いろいろあると思うので
要件に合っていれば
すごいめちゃくちゃ使えるという感じですかね
そうですね
苦手なこともありまして
苦手なことで言うと
やたらにオンオフオンオフするような
データを
がある場合に
例えば
ゲームをイベントソーシングでやりましょう
って言われて
ボタンを押したっていうのを
記録するのはいいんだけれど
そこまでのデータっていうのは
実際にはいらないっていうことはあると思うんですね
それをずっと残しておく必要っていうのは
全然ないみたいな
それこそどういうふうにボタンを押したか
押されたかというのを
解析してAIを作るとかだったら
まだしも普通の状況では
そのオンオフのボタンのデータがいらないのに
イベントソーシングの形で
普通に
データよりも
巨大なデータができていくみたいな場合は
そのまま同じように
ずっと取っておく形にする必要っていうのは
なかったりするので
やっぱり要件次第っていうことにはなるんですけれども
ユーザーの意思がかかる
ユーザーがこれを依頼するのに
ゆっくり考えないといけないみたいな
そういうものに関しては
データとして価値があり続ける
という可能性が多いので
結構多くのビジネス案件っていうんでしょうかね
エンタープライズ案件とかに関しては
かなりデータ容量的にも問題なく
使えるっていうことが多いんじゃないかなと思ってますね
ありがとうございます
イベントソーシングの話から外れて
臨読会今回ケンさんがいなかったんですけれども
ケンさんに質問がいくつかあったので
それを取り上げてみてください
まず一つ目が
ケンさんがアパッチカフカを大規模とする
ストリーミングパイプラインの導入機能が増えている
っていう話をコメントに書いてくださっていて
その中で例えば銀行とかフィンテック
HRスタートアップとか
そういうのを挙げてくださったんですけども
その中でてっぺいさんから
HRスタートアップで使われているのが意外でしたと
どういうところで使われているかって
ご存知ですかという話があったんですけども
これは話せますかね
2年半くらい前に
転職活動したときにいろいろ見て
ロンドンのスタートアップを見たんですね
これはテックブログに出てたので
パブリック情報ですけど
一つ当時結構大きいスタートアップシリーズ
BからCになろうとしてたのかな
なんかビーマリーっていう会社があってですね
ビーマリーっていうのはタレントソースプールを
作ってるHRテックなんですよね
だから例えば
僕が転職活動してますみたいな状態が
タレントプールとして情報に載ってて
この人が転職必要を見取るのが出たら
企業にプッシュしてみたいな
リンクトインの度胸号ではないですけど
各社が例えば過去に受けたけど
ちょっと落とした人
1年後にもう一回再プッシュしてみようかなとか
そういった自分の会社を受けてくれそうな
タレントの人が
タレントプールって言ったりするんですね
結構大きい会社
Googleとかインディートとか受けると
彼ら独自のタレントプール
内製ツールとか使ったりするんですけど
それのソフトウェアザサービスみたいな会社があって
そこでカフカをがっつり使ってる
カフカとあとグラフデータベースを使ってる
っていう話があって
そこの話を聞いたときに
すごい面白かったなと思っていて
それがHRスタートアップの例で
あとはロンドンだとやっぱり
フィンテック系が多いので
フィンテックスタートアップもそうだし
皆さんが名前を聞いたことあるような
大手銀行系も多くて
どっちでもカフカを使ってる例が多いですね
結構エンタープライズというか
エンジニア以外の人も聞く
よくある日本でいう
三菱UFJ的な感じの銀行でも
カフカ使ってますみたいなところがあったりして
なかなか幅が広いなと思って
カフカ使ったものとしては
だいぶちょっとこう
ボーナスポイントを持って
転職活動してるみたいな感じでしたけど
カフカの特徴と設定
そういうのがありましたね
すごいですね
やっぱりそれだけ安定性とか
対障害性みたいなのが
かなりあるっていうことですよね
カフカ
多分ね運用する知見っていうのも
だいぶ枯れてきたと思うんですよ
カフカ自体ももちろん継続的に
アップデートされてるんですけれども
使うエンジニアの裾のボリュームが
結構広がってきたので
やっぱりアパッチスパーク
アパッチフリンクとか
他のストリーム使ってますってより
やっぱりアパッチカフカっていうのは
よく効くじゃないですか
だからよく効くってことは
選定される機会もそれだけ多いということで
ログのセマンティクスとかも
結構コンフィギュアラブルだし
割とそのいろいろコンフィギュアラブル
設定可能な幅が広いので
そういうところでも
選定しやすいっていうのは
あるのかもしれないですね
カフカについて聞いてもいいですか
僕はあんまりカフカ自体は
すごく詳しくなくて
カフカはやっぱり
イベントは基本的に
ずっと取っておくものなんですか
それとも途中で
一定期間以前のものは
クリアするとか
最終的な
データ保持のために
も使うのか
それはやっぱり別のサービス
ドキュメントデビとかに流すのが
一般的なのかとか
その辺知りたいなと思ってるんですけど
それが面白くてどっちも選べて
カフカはリテンションピリオド
ログをどれぐらいの期間持つかっていうことで
例えばアプリケーションログを作るときってのは
もうその1年も必要ないので
例えば30日で切るようにして
そうすると30日以降の
タイムスタンプのログは
どんどん勝手に消してくれる
一方でアプリケーションログ的に
セキュリティ関連の監査ログ的なのを
保存したいときは
ちょっとディスクの容量とか
気にする必要があるので
アプリケーションの設定としては
カフカの設定としては
どっちのつまみも触れられるので
そういったコンフィギュアラブルな幅っていうのも
カフカを選定する理由が
多い理由なのかなと思ったりしますね
イベントソーシングのソースのデータベースとしても
使えるんですか
そうですね
使っているっていう話は結構聞いたことがあって
私はドキュメントDBを先に使って
そっちをメインにしているので
カフカを
何か
何か
流す経路として
これから何か考えていきたいなと思っていて
古いものは
コスモスDBとかに
永続化みたいなのもできるかな
って考えていたところで
あともう一個
時間のことが
ここにも書いていたと思うんですけれども
カフカの場合の
時間の整合性というか
並べ替えの
単位っていうのはやっぱり
パーティションというか
パーティション
パーティション的な
このパーティション内では
時間並べ替えを
担保できますみたいな
そういうのってあったりするんですか
そこもね
関数みたいなので結構
コンフィギュラブだった気がするんですよね
ちょっとそこ曖昧ですね
ありがとうございます
結構順番って重要で
順番変わっているとね
パーティションの中は
さすがに
北順だった気がしますね
パーティション
カフカでいうパーティションは
物理的な単位
そうですよね
そこがまず一番大事
っていうところかなと思いますね
パーティション単位では
ライターヘッドログと一緒に
どんどんアップエンドしていくだけなので
そこは一定だった気がしますね
多分パーティションを超えた
順番の
担保っていうのは
無理だと思うんですよね
そこをデフォルトだと
順不動です
ちょっとヘッタなこと言わないですけど
確かカフカもラップしてて
カフカストリームを使用した結合や変換
いい感じにする設定もあってもないような
でも
頑張ればできなくはないですよね
バギーですけど
データベースやってくれたらいいので
パーティションごとには
タイムスタンプは順不動だけど
実装の詳細ではあるので
使う側からしたら
どっちも対応してくれたらいいな
あるので
確かに
ありがとうございます
この章の最初のところの文章が
すごい良い文章で
うまく動作する複雑なシステムは
例外なく
うまく動作するシンプルなシステムから
進化してきたものだっていう
文章でこの章が始まっていたんですけれども
やっぱり
まずそのパーティション内の
順序
それをずれるとしても
それをどうやって
修正していくかみたいな
感じで
順位的には多分そういう感じだと思うので
結構やっぱこのシステムって
それぞれデータベースの
単体としても
いろいろ考えないといけないし
分散についても考えていかないといけないし
アプリケーションについても
考えていかないといけないんですけれども
どういう順番で
整合性を
担保していくかっていう
まずシンプルなところから
スタートして
少しずつ複雑にしていく
というのが
っていう感じかなと思って
自分たちの
作っているシステムはまだ全然
完全ではないんですけれども
この範囲だったらできるよ
みたいな
まずシンプルなところから
成長させていきたいなと思っていますね
この一部かっこいいですよね
シンプルと複雑の
狭間でっていうのは
ソフトウェアエンジニアの永遠の課題だと思いますね
いかにシンプルにできるか
というところが大事なんですかね
すみません
もう一個質問があるんですけれども
しゅうへいさんからでして
このストリームの結合っていうところが
前回のバッジについて
結合をどうするかっていう話がありまして
このストリーム
ストリーム結合の部分のジョインは
そのカフカみたいな
プラットフォーム上で実現できるのか
もしくはコンシューマー側でやっているのか
みたいな具体的なイメージが
わからなかったって話なんですけど
これケンさん分かりますか
これあれだよ
KSQL DBっていうのでできるはず
僕プロダクションレベルで使ったことない
あくまで趣味プロで触ったレベルなんですけど
カフカを作ってる会社
コンフルエントっていう会社があって
アパチカフカのコンビニターたちがいるような会社で
そこでが作ってるAPIとして
カフカのスキルを作っている会社があるんですけど
ストリームに対してSQLっぽいものが
発行できますよっていうやつがあるんですよ
SQLって大抵どこのソフトウェアエンジニアも知ってるんで
各社データベースはやっぱり
SQLに仕様を寄せるんですよね
Neo4jのCypherっていうクエリ言語とかも
ちょっとSQLっぽく書かせようとしてたりする
SQLっぽくさせるとやっぱり
参入障壁が下がるので
ストリームのデータベースに対して
SQLっぽく書けるよっていうのがあり
そこで
ストリームのデータベースに対して
そこでストリームっていう概念を作るんですよ
クリエイトテーブルみたいな感じで
クリエイトストリームS1みたいな感じで作って
基本カフカのストリームを流れてくるものに対して
SQLっぽいのが書けますって感じなんだけど
そこでジョインができるんですよ
なのでそこのカフカを流れているものに対して
ジョインができて
カフカストリームに対する命令発行の
ラッパーのAPIに過ぎないので
カフカにはカフカコネクトって言って
カフカにデータを入れる側と
カフカからデータを吸い出す側との
つながりをいい感じにしてくれる
ツール群みたいなのがあって
例えばカフカからイラスティックサーチに流したいとか
ポスグレーのデータをカフカに入れたいってなった時に
それ思う人いっぱいいるじゃないですか
それが一人一人が
ゼロからプロデューサーとかコンシューマーのコード返したら
なんか
カフカに入れる側とカフカからデータを吸い出す側との
人類の知恵の無駄じゃないですか
だからカフカコネクタっていうのがあって
それをデプロイしてコンフィグいじるだけで
誰かが書いてくれたようなのはいい感じに
ポスグレーとカフカのコネクタがオープンソースにあれば
そこはいい感じにしてくれるとか
カフカとイラスティックサーチのコネクタがあれば
いい感じにしてくれるっていうのがあるので
例えばポスグレーから吸い取ったやつと
別のS3から吸い取ったやつを
カフカのスリム投げて
KCクリックDBのジョインを使って
ジョインして
イラスティックサーチに吐き出すっていうのは
それでできるはず
プロダクションレベルでしたことないんだけど
理論上そうですね
だからプラットフォームできますかという答えに関しては
そう思います
ちなみにこのストリームに対して結合するっていうのが
ストリームって流れてくるもので
一定期間
溜めておいて
それを結合するっていう感じなんですか
例えばここからここの範囲で
流れてきたものに対して
結合するっていう感じですか
結合するっていう感じですか
カフカを利用したシンプルな要素の組み合わせ
そういうことになるんですかね
ストリームで結合するっていうの
そこで結合するキーを選ぶでしょ
だから結合する同じレコードが
両方から流れてきたらってだと思うけれども
ここから先は
想像なので
分からないですね
調べてみます
間違ってたら次回で補足しますが
でもCDCとかと
つなげられて
そういうのに
変更に
基づいて
このテーブルが変更されたら
このマテリアルビューを
セレクトして
アップデートするとか
やっぱりかなり
マイクロサービスが
使いやすくなるっていうんでしょうかね
いろんな要件に対する
データを作るための
ハブ的なものとして
使えるっていうのが
非常によくできているな
それこそやっぱりシンプルなものを
組み合わせて
複雑なことを実現するのに
核化っていうのがすごい役立っているな
っていうふうに感じますね
自分も
ちょっとまた話変わりますけど
会社で
この本を書を読んでから
イベントソーシングの可能性
イベントソーシングっぽいところを
体験したことがあって
デプロイの
回数を測るための
処理が
測るタスクが
習字であって
それをデプロイする
ジョブがあって
デプロイの回数みたいなPRとかの数を
数えれば分かるんですけど
そうじゃなくて
デプロイするジョブから
ログをクラウドウォッチとかに吐き出して
それを集計
1週間に1回集計するみたいな
ことをやっているのを見て
これイベントソーシングに
すごい近いなと思って
アプリケーション
全体でやらなくても
小さく始められるのかなみたいな
ふうに思ったので
これはすごい面白いなと
思ったんですけど
イベントソーシングなんですから
もっとやってみたいなというふうに
結構自分は思いまして
いいなと思ったんですけど
友下さんの
会社にもし入ったら
そういう経験がいっぱいできる
という感じなんですかね
まだね
イベントソーシングを扱っている
のが
少なくてうちの会社の中でも
主流にはなっていないんですけれども
面白い体験はできるんじゃないかと
かなと思います
イベントソーシングやりたくなったらね
主流になってきたら
入るしかないじゃん
そうですね
めちゃくちゃ僕興味があるんですよね
アメリカですかスイスの次は
アメリカ
行きたいですね
でもイベントソーシング
やっぱり日本で
かなり積極的に
扱ってくださっている
イベントソーシングの
インフルエンサー的な
方が数人いるんですけれども
日本ではやっぱまだ
あんまり知られていない
というところなので
日本人が作っていた
イベントソーシングフレームワークで
Cシャープは日本でも結構
ビジネス側では
よく使われていて
Cシャープで私たち書いているんですけれども
Cシャープで
イベントソーシングを
関数型的に
書けるみたいなのを
オープンソース化したら
例えば趣味プロジェクトとか
でも使っていただけるんじゃないかな
と思うので
早めにリリースしたいと思います
はい
楽しみにしています
今回ね
DDIAの
ブッククラブに
参加させていただいて
うちの会社でも
ブッククラブを
開始させていただいて
その時に
アサヒさんの作ってくださった
フォーマットが非常に良かったので
ほとんど同じフォーマットで
本だけ変えて
会社内で
スタートさせてもらったんですけれども
結構やっぱり
うちの会社自体は
本を読む人は結構
限定的にいるものの
やっぱり忙しいのでね
なかなか読めない
という人が多かったですけれども
賞を限定して
こういう
まとめを書く時間と
この話す時間は
仕事時間でやるようにしたので
結構多くの人が
参加してくれて
本を読むことができて
良かったと言ってくださっているので
ちょっと今回
ロンドンテックトークのおかげで
そういう良い
取り組みが広まっていますというのを
感謝したいと思います
ありがとうございます
すごい
アサヒさんめっちゃ嬉しいやつじゃん
めちゃくちゃ嬉しいですよ
だってやってたことが
他の会社にもちょっと影響を与えられたっていうのは
すごい嬉しいですし
このフォーマット自体は
けんさんが作ってくださったところはあるんですけど
それはすごいシンプルで分かりやすい
いや多分そうです
めちゃくちゃシンプルで分かりやすいなと思うんですけど
これはすごい嬉しいですね
ありがとうございます
ディスコードのね
僕らのディスコードのチャンネルにも
友下さん共有してくれましたけど
会社の方が書かれたノートコムの記事もありましたよね
なんかそこで
インタビュー形式で社員に
いろんな本を聞いてるみたいなのがあって
あれも面白く読ませてもらいましたね
面白かったですね
本当に多くの方が参加してるんだなっていうのが分かって
なんかすごいですね
巻き込み力も
友下さんの巻き込み力もあるのかなっていう感じはしたんですけど
でもやっぱり
このロンドンテックトークの
ブッククラブは
結構みんなそれぞれ
すごい
すごい時間かけてやっていますけれども
社内の方がもうちょっと参加しやすくして
結構聞いてるだけの人も
多いし
それでもいいし
だからこういう風に
結構シンプルな
コメントの書き方とか
変数名の付け方とか
そういうことが書かれている本を選んで
そういうことについて
社内で語り合っているのを聞いて
ちょっと刺激を受けるみたいなね
そういうことについて
ロンドンテックトークのブッククラブ
新しいメンバーとかも
入りやすい形に
アレンジしてやっているっていう感じですね
めちゃくちゃいいですね
PRとかにコメントするよりも
なんか
意見のすり合わせがしやすいというか
いうような
メリットもありそうだなと思いました
ロンドンテックトークの
臨読会もこの後一章で終わりですけど
引き続きまた
別の本で
臨読会を続けていこうと思っていますので
興味がある方はぜひ
ご連絡くださいっていうのを
宣伝しておきたいですね
楽しみだね
次の本も決まったしね
詳しく本の紹介会があるのかな
あると思います
やります
私も
一リスナーの立場から
参加させていただいたんですけれども
全然怖くなかったので
聞いている方で
関心がある方も
ぜひ
どこから連絡するかを
っていうのが一番いいんでしょうかね
ディスコードなのか
ツイッターか
そうです
一応ケンさんが最近
アンケートフォーム作られたんで
そこから声掛けていただいてもいいですし
どこがいいんだろうね
トバヒラさんって何でくれましたっけ
連絡
僕はXで
ケンさんにリプライをして
最初興味あるって
言ったと思うんですけれども
人によっては
パブリックリプライで
書きにくいっていう人も
いるのかなと思って
今週出たエピソードで
Googleフォームっていうのは
非常にいいなと思いましたね
いきなりDMとか
ハードル高い方もいらっしゃるだろうからね
うん
ぜひ
Googleドックスなのか
Googleカレンダーなのか
それできたら
それをパブリックに放出しちゃうとかも
ありなのかな
確かにいいですね
それはやってみますか
確かに
運用の話は
やりましょう
はい了解です
ありがとうございます
今日はこんなところですが
すごい面白い話が聞かれてよかったです
ありがとうございました
ご参加いただきありがとうございました
ありがとうございました
お疲れ様でした