00:04
皆さん、こんにちは。London Tech TalkのKen Wagatsumaです。
イギリスのロンドンで、ソフトウェアエンジニアとして働いています。
このポッドキャストでは、Yosuke Asaiさんと一緒に、海外転職や最新の技術トレンドについて話していきます。
よろしくお願いします。
よろしくお願いします。
今日はですね、Kafka編ということで、Kenさんが一度Cookpad時代に、Kafkaのプロジェクトをリードされていたという話を伺っていたので、
今回、自分もKafkaのことをより詳しくなりたいなっていうことを思っていたので、お願いして、Kafkaの話をしていこうと思います。よろしくお願いします。
よろしくお願いします。いいですね。大好き。データベースの話は好きなんで。
こういう会話ができるのを待っていました。
よかったです。
自分の歌詞でも、Kafkaを導入していきたいなみたいな話があって、自分も勉強したいなと思っているので、ぜひ、いろいろ聞かせてください。
はい。
まずは、Kafkaについて、Kenさんが、Kafkaとはっていうところを聞いてみたいなと思うんですけど。
だから、聞いたほうがいいと思います。
そうですね。
Kafkaとは何ですかっていうのを簡単に説明されたいと思うんですけど。
はい。
なんか、前、コミュニティとかで、ちょっと、Apache Kafkaの勉強会しようかなと思ったけど。
はい。
なんか、あんまり興味ある人いなさそうだから、そもそもKafkaって、多分、ソフトエンジニアの中でも、アプリケーションとか書いてない人にとっては、何?って感じだと思うんだよね。
うん。
うん。
っていうことで。
そうですね。
そう。まず、Apache Kafkaっていうのが、データベースの一つですと。データベースにもいろんな種類があって。
よく聞くMySQLとか、OsgreみたいなRDBMSとか、あとはNoSQLっていわれるやつで、いろいろあるんだけど。
Kafkaは、その中でも、ストリーミングデータベースといわれるものの種類の一つですね。
なので、一言で言うとストリーミングデータベースって何かな。
ストリーミング。
うん。
ストリーミング。
横流ししていくために使うというか、一時的な置き場として使うみたいなイメージですか。
そう。よく言われる特徴の一つとしては、既存のMySQLみたいなRDBMSとストリーミングデータベースの一番の大きな違いっていうのは、データが無限に入ってくることを想定している。
だから、ストリームっていうのは、小川とか川の流れっていう意味なんだけど。
03:03
うん。
その流れのように、連続的にデータブロックがどんどんどんどん入ってくることを、それを処理するということを想定されたデータベース。
うん。
じゃあ、限界がある意味ないっていうか、当然あるけど、限界なくても大丈夫なように作られてるってことですか。
それを、そうだね、想定している、作りとかAPIになっていて、例えばRDBMSとかだと、例えばトランザクションを開いて、その中で必要な処理をいろいろアップデートしていく。
うん。
いろいろアップデートをゴニョゴニョしたり、デリートをゴニョゴニョしたり、トランザクションを閉じて、ガッと書き込みをするみたいな感じなんだけど、カフカとかストリーミング志向のデータベースっていうのは、例えば、何だろう、無限に発生するデータ、例えば現実世界で言うと、例えば株価のティック、株価の値が、基本、連続的に入ってくると思うんだけど、それをどんどんデータブロックとして入れて、やり取りをするとか、あとはIoTのデバイスから入っていく。
例えば温度とか湿度みたいなセンサーデータを、1年中入ってくると思うんだけど、それをデータベースに入れて、それを処理するとか、そういったユースケースに向いている。
一つ一つのデータは、基本的にイミュータブルな小さな、変更されない小さなブロックのデータが入ってきて、それを処理する、ストリーミングデータベースっていう形になるかな。
うん。
じゃあ、カフカの中で、なんか、そのデータを処理する。
うん。
うん。
と思った人が、何か編集するとかはしない。
っていうのが基本にある。
そうそう。
カフカとしてはそうだね。
うん。
なので、ユースケースとして、例えば僕がWeb企業で働いているけれども、まあ、よくある、結構いろんな所で使われてて、大きい所だと、CDNAのCloudflareとかでも使ってたり、
多分、Facebookとか、そういうネタか、とかね。
はい。
一部でも使ってたりするし ロンドン とかだとワイズ トランスファーワイズ
級 フィナンシャル フィンテック の会社とか フィンテック系とか
でも多いんだけど 例えば
センターのアーキテクチャー見 ったときにも カフカ使ってるみたいな
話ありましたよ
あった気がするね あったと思う あったと思う 僕の今の会社ももちろん使ってる
で 例えばiOSとかAndroidとかWebとか クライアントのログ基盤のまず
受け渡しとして使ったりとかが 多いかな いろんなクライアント
からまずApacheかフカのデータベース なので普通にサーバーが動いて
て そこにどんどんどんどんデータ を流して そのデータを入れる人
たちのことをログをプロデュース 生成するということ プロデューサー
って呼ぶんですね
はい
ストリーム 川に水をどんどん流す 人たちのことをプロデューサー
プロデューサーって言っていて そのプロデューサーが好き勝手に
06:04
どんどんどんどん自分が投げたい データを小川に流していくんですね
で それはプロデューサーっていう のはデータを流すだけ
その反対の概念としてあるのが コンシューマー 消費者ということで
それは小川の下流のほうで待ち構 えていて
川を流れてくるデータパケット を自分が欲しいやつでもとりあえず
全部取って取った上で処理して いくっていう感じのプロデューサー
とコンシューマー
で なんでカフカみたいなものが そもそも必要となるのか ストリーム
データベースが必要になるのか っていうポイントは データを生成
するプロデューサー側とデータ を消費するコンシューマー側の
間にバッファリングとかができる
この別のレイヤーを入れたいから なんですよね スケーラビリティ
の観点
例えば逆にイメージしてほしいん ですが いろんなiOSとかAndroidとか
IoTデバイスから大量のデータ送 られてきて それを処理して じゃあ
レポートを作るバックエンドサーバー があるとしましょう
そのバックエンドサーバーが全部 世界中にあるデバイス 数十万の
デバイスからデータを受け入れる っていうことを考えると そのバックエンド
のサーバーは入ってきてるんですよ っていうところがあるんですよ
データのビジネスロジックを入れて データをごにょごにょするっていう
ところだけじゃなくて 大量のデータ が入ってくるのを分散処理でスケーラブル
に対応しなきゃいけないっていう このスケーラビリティのことも
考えなきゃいけない
データを生成する側のワークロード とデータを受け取る側のワークロード
アンバランスっていうのをどこかで 吸収しなきゃいけないんだけど
それをカフカみたいな真ん中に 大きなパイプみたいなものを入れ
たりみたいなストリームを流す 川みたいなものを作ることによって
そこのワークロードの違いを吸収 することができる
だから例えばストリームの流れ でいくと そこにダムを作っていく
ようなイメージですね プロデューサー がどんどんどんどんログを入れて
いくと でも受け取るコンシューマー 側が追いつかないことってある
と思うんですよね そういうとき には例えばApache Kafkaっていう真ん中
の層があって 例えばプロデューサー 側に
今 下流の人たちがちょっと君たち がデータを送りすぎてて処理できない
からちょっと待ってよってことで 入ってきたデータパケットをドロップ
したりとか あとはリジェクトしたり とか あとはバックプレッシャー
っていって ちょっと待ってねみたいな ちょっと速度下げてねみたいな
シグナルを出したりとか そうい ったことをするんだけど それを
カフカのストリーム処理として 抽象化していくことで いろんな
ビジネスユースケースに対応できる という形になっている感じかな
上流側で凄い処理が多いときとかに 下流でも対応するために でも下流
09:01
側でさらにスケールアップする ような時間がかかったりするから
それをカフカでいったん止めて おくこともできるということですか
ね
そうそうそう もう一つのプラクティカル なメリットとしては 一つの大きな
本流みたいな川があって そこに 全てのデータが流れてくると思
うんですけど
例えば ビジネス要件って結構 いろいろで 同じIoTデバイスのセンサー
データが入ってくるんだけど 例えば それをレポートとして見るビジネス
側のチームと あとそれをメトリクス とってディベロッパーチームがあって
それぞれ同じデータなんだけど どうそのデータを 何だろうね メトリクス
として取ってディベロッパーチーム があって それぞれ同じデータなんだけど
で コンピューターの中で 形成してレポート作りたいかっていう
コンシューマー側の要件が違う ことってよくあると思うんですよ
ね
はい
そういうときに ストリームを 例えばファンアウトっていう形
で 同じデータパケットをそれぞれ 別の支流に分けて コピーして分け
て こっちのチームでは レポート の中 データパケットの中で必要な
ものだけを作って 彼ら独自のレポート を作り 別のチームでは データパケット
の中で必要なものだけを作って 彼ら独自のレポートを作り 別のチーム
では 別のチームでは 別のチーム が必要なデータパケットだけを
使ってレポーティングを作りみたいな 感じで 川の流れをどんどんどんどん
分けていくことによって 下流の 細かい違うビジネス要件のチーム
たちが同じデータを好き勝手使う ことができるっていう そこの抽象化
をすることが Kafkaみたいなストリーム 処理を使うとやりやすいという
形になってるんですよね
Kafkaの中でフィルタリングみたい なのができるっていう
フィルタリング
フィルタリングもいいですし 例えば Apache Kafkaのコンシューマーを作る
ときに 単純にファンアウトっていう のは扇 ファンですね 内輪みたいな
扇をアウトさせていくみたいな 感じで 同じデータを複数の支流
にコピーしていく感じなんですよ ね
このデータをここにコピーして いって このデータをここにっていう
のが設定できるっていう
そうそうそう とりあえず必要な データをまずバーンと流しといて
下流側で
必要なデータを必要に応じてもら ってきて そこでフィルタリング
したりとか なんでかなり抽象度 の高いレイヤーなので 結構ユースケース
でいうと業界はもうFintechとか に限らず いろんな業界で使われ
やすいし いろんなところでユースケース がよく効くかな
ちなみにファンアウトとかの 設定をするのに そのコンフィグ
ファイルみたいなのを開けば 必要なデータを必要に応じてもらってきて
いるのかっていうところはできるん ですか それともコードを書いたり
して設定していくんですか
12:02
ファンアウトに限って言うと まだ 前半なのでどこまで突っ込むか
例えば Apache Kafka で Kafka Connect っていうAPIがあって Kafka Connect っていうAPIは今言ったよね 今言った
でしょ
うん
AmazonのApkってことですか
AmazonのApkってことですよね
AmazonのApkってことですよね
データのパイプラインをいろいろつなぎ込みやすいような
抽象化されたAPIなんですけど
例えばそのカフカにとりあえずデータを入れて
その後に例えばイラスティックサーチに入れたいですとか
イラスティックサーチの別のデータベース
他のRTBSに入れたいですとか
あとは別のカフカからカフカに流したいですってことって
よくあるんですよ
例えば他のカフカからカフカに流したいっていうのは
とりあえずUSリージョンで受け取った全てのデータを
ヨーロッパのリージョンにコピーしたいですとか
あとはヨーロッパとAPACから入ってきたリージョンの
アグリゲートを集約して告知に流したいですとか
そういったときに今までだったら
そのコンシューマーのアプリケーションを書いて
カフカのAPIを直接叩いてデータを持ってきて
コードゴリゴリ書いて
JavaとかGoとかでそれを集約して流すみたいなのだったんですけど
そのアプリケーションを受け取ったら
カフカとつなげる先のデータベースで
ある程度パターン化していくんですよね
イラスティックサーチとつなげたい人とか
別のカフカとつなげたい人みたいな
そこのつなぎ込みをさらに抽象化する
バッチカフカのコネクトっていうのができて
それを使うと実装コードが減る場合が多いですね
例えばカフカに受け取ってきたものを
イラスティックサーチに出して検索に使いたいみたいなときに
今までだったら自分でコンシューマーを書いて
カフカのAPIを叩きゴニョゴニョして
ライトのAPIを叩くみたいなのを
自分でゼロから書かなきゃいけなかったのが
コネクトAPIがサポートしていれば
実装が少なく書けるケースが多いっていう感じですね
システムが発展してきて
やることが減ってきたという感じですかね
そうそう
さっき言ったデータをコピーするみたいなやつも
すごいよくある要件なので
ファンアウトとかね
カフカコミュニティ自体が
ミラーメーカーっていうソフト
バイナリーを出していて
それはもう名前の通り
一つのカフカの中のデータを
別のカフカにコピーするっていう
それをもうすごく上手にやってくれるっていう
バイナリーがあって
そのミラーメーカーも実は
バージョン2だと新しいバージョンだと
裏側ではカフカコネクトのAPIを使ったりするんだけど
そういうふうに
カフカコネクトとAPIを上手く使うと
可能な限りコンフィグファイルを書いて
15:01
そのプロセスをデプロイするだけで
Apache、カフカに返ってきたデータを
上手く継ぎ込めるっていう感じになってる
どんどん便利になっていってるんですね
面白いスポットだな
やっぱり使うデベロッパー側のユーザーエクスペリエンス
デベロッパーエクスペリエンスを考えて
結構いろいろ頑張ってる印象はありますね
いいですね
うん
ちょっといろいろ頑張っていきたい話もあるんですが
一旦けんさんがカフカにどうやって関わり始めたのかとか
そういった話を簡単に聞きたいなと思うんですけど
僕が最初に
何年前になるんだろう
2000
忘れてしまった
日本にいるときなので
15年前かな
まずストリーム仕事を
ストリーム仕事を
ストリーム仕事を
ストリーム仕事のデータベースで
AWSが出してる
Kinesis Streamっていうやつがあって
聞いたことありますか
Kinesis
データパイプラインとかのサービスですかね
そうそうそう
AWSはストリーム仕事の
カフカ
アパッチカフカのマネージドサービスとして
MSKMっていうのを出してるんだけど
AWSが独自で出してるストリーミング仕事のデータベースで
Kinesis Streamっていうのがあった
それも似たような感じで
全然カフカとできることは違うんだけど
ストリーム仕事のデータベースで
ストリーム仕事という意味では同じのがあって
当時入社して
最初に入った
Cookpadの広告事業系の
チームで
Kinesis Streamを使った
リアルタイムログ
分析プラットフォームみたいなのが
すでにあったんですよね
僕が実装したわけじゃなくて
その前の人たちが実装した
そこで初めて運用する側に回って
なんか面白い
そこが初めて僕にとって
ストリーム仕事のデータベースについて
触れる機会だったんですけど
それ面白いなっていうことで
広告時代にいる中に
1回か2回くらい別のアプリケーションを使う時に
今度は自分での似たような構成で
Kinesis Streamを使って
実装するみたいな経験もさせてもらって
すごい楽しかったんだけど
それがストリーム面白いなっていうことで
Kinesis Streamって
マネージドの割と使いやすいサービスなんだけど
Apacheカフカっていうのはもちろん
業界スタンダードとしてあるっていうのは
出てて
そのタイミングでCookpadの中で
グローバルチームに転席になった時に
グローバルでは既に
カフカを使ってたんですよね
Apacheカフカを
それが初めて運用側として
カフカに触れるきっかけだったかな
当時はApacheカフカを使うにも
いくつか種類があって
マネージドのサービスを使うか
自分でセルフホストするか
っていう形なんだけど
当時はConfluent Cloudっていう
まあ
Apacheカフカのコミッターたちがいる
Apacheカフカのマネージドサービスみたいなのがあって
それを使ってたから
18:01
それを使い始めたかな
日本にいた時は
Kinesisを使ってデータストリーミングをやっていて
海外支部に来てからカフカっていうことで
なんかそのやっぱり
同じような概念で
考えとか思考とか
知識とかスキルが生きるようなところはあったんですか?
そのカフカに移りやがって
そうだね
あの基本的には
そのなんだろう
もちろんそのコンフィグどうするかとか
メトリックどうするかっていうのは
取れるメトリックスも違うし
コンフィグの形も違うんだけど
そのストリーム思考ということで
ベースで考えなきゃいけないってことは
結構似てるんですよね
例えばこういった
そのさっき最初に言ったんだけど
連続的に無限にデータが流れてくるシステムを使うと
例えばこういったそのさっき最初に言ったんだけど連続的に無限にデータが流れてくるシステムを使うと
例えば考えなきゃいけないよくあるパターンとしては
遅れてきた遅延した
ラグがあるデータをどう扱うかっていうのが
一つアプリケーションのパターンとしてあるんですよね
例えばさっきのIoTデバイスの話で言うと
世界各国のIoTデバイスからセンサーデータが入ってくるんだけど
ネットワークの問題とか
Wi-Fiが遅い問題とある
IoTデバイスから
5分遅れてデータが入ってきますと
でもその5分遅れて入ってきたデータを処理した時点では
すでに他の99.9%のニアリアルタイムに入ってきたデータ処理し済みで
それをターゲット先のデータベース
イラストリックサーチでもMySQLでも書き込んじゃってましたみたいな
そんな時にラグをされたデータをどうやって処理しますか
出ますかそれとも書き込みますか
それとも別のラグ用のデータに書き込んどいてもいいのかと言うと
それとも別のラグ用のデータに書き込んどいてもいいのかと言うと
あとでアグリゲートしますかみたいなのとかは
Kafka使ってようがKinesis使ってようが
他のストリーミングデータベース使ってようが
関わってくるところなので
そういったストリーミング志向のアプリケーションパターンっていうのは
すごい行きましたね
前後にあるKafkaとかKinesisの前後にあるところは共通して
同じような処理をすることが多いから
そこをIQっていう感じですかね
それを対応するために
WaterMarketerとかIoTとかの
WaterMarketerという考え方があってとかあるんだけど
そこら辺のキーワードとかは一緒なので
自分の会社でのKafkaを導入したみたいな話があって
その中でやっぱりKafkaの他にもいろいろサービスがあると思うんです
今おっしゃったようなKinesisもあるし
GCPではCloud PubSubって結構近いのかなと思ったりとか
あとRabbitLQみたいなサービスがあったりとか
っていうのがいろいろあると思うんですけど
いろいろサービスがある中で
どれを選べばいいのかとか
どういう時にKafkaを選ぶのかみたいなのも
21:00
ちょっと気になっていて
例えばどういう規模だったらKafkaを選ぶのかとか
いろいろあると思うんですけど
なんかその辺で
こういう処理に向いてるよみたいな
もしあれば教えていただきたいなと思います
いい質問ですね
RabbitMQは使ってこないんで
ちょっとよく分かんないですけど
細かいところがね
例えばストリーミングとかって言うと
例えばストリーミングとかって言うと
ストリーミング指向のデータベースによって
どこまで細かく設定できるかってのが
まず違うのと
そのスケーラビリティをどこまで担保してるかってのが
違うのと
多分よくある技術選定の話になるんだけど
その技術に慣れてる人がどれぐらいいるかって話になっていて
例えばじゃあクラウドパブサブと
Apache KafkaとRabbitMQ使うみたいになった時に
マネージドで
じゃあコンフレントクラウドのKafkaと
クラウドパブサブとRabbitMQ使うみたいになった時に
クラウドパブサブとRabbitMQ使うみたいになった時に
多分マネージドで使うんだったら
サポートしてるスケーラビリティの
アッパーリミットってのが多分違うと思うんですよね
まずそこら辺の
要件で消去法的に消していくのが
まず一つありますよね
例えばクラウドパブサブでは
ここまでしかサポートされてないんだけど
今回の要件ではめちゃくちゃスケーラビリティが必要で
クラウドパブサブだと思う
パブサブ結構多分サポートしてると思うんだけど
そういった
サポートが
ある感じで消去法的に消して
あとは
よくあるのは
ログのセマンティクス
っていう
考え方があって
例えば
At least once
とかデリバリーの
ログを渡す時の
セマンティクスっていうのがあるんですけど
それは
例えば
さっきの同じ例でいうと
IoT
センサーの
のデバイスがカフカにデータを 渡すと思うんですけど ネットワーク
の瞬断とかによって ログがうまく 届かないケースってたくさんある
と思うんですよね そんなときに データを ドロップされたデータ
をそのまま見過ごすのかどうか もしくは 再送するのかどうか もしくは
必ずエグザクトリバンス 1回だけ 送られることを保証するのかどうか
っていう この3パターンがあって ですね これはビジネス要件によって
変わってきます 例えば 重複された データが入ってきてもいいけど
データはなるべく落とさないで ね みたいな要件のものだったら
そのセンターのデータを ドロップ さないといけないというような
セマンティクスを選ばなきゃ いけないですし あとは とりあえず
どんどんどんどんデータを送って くれて 0.1パーセントぐらいドロップ
されても全然問題ないよみたいな 欠けてることが許されるビジネス
24:01
要件だったら そういったセマンティクス を選べばいいし ストリーミング
の中で 例えば ファイナンス系 とかですね 必ず1回は送られた
ということ 例えば ドロップされたら 再送するし 重複で送信すること
はないということ ちゃんと保証 してくださいみたいなセマンティクス
が必要なときにはそれを使う それが使うPubSubとかApache Kafkaでサポート
されてるかどうかっていうのが 大事なポイントですね Kafkaの場合
はすごいコンフィギュラブル 徹底 の柔軟度が高いので 基本的に
設定で大体サポートできるので そういった問題で じゃあしょうがない
Kafka使うかってなるケースも多い かなと思います
確かに In-Uとかだと 2回送って しまったら 例えば二重計算になって
しまうみたいな例も考えられますか
もね そういうのを絶対に防ぎたい からこそ よりしっかりしたほう
を選びたいみたいな流れはあるん ですかね
二重決済はどこでされるかっていう のがあって 別にKafkaというか ストリーミング
がデュプリケートで遅れてきて くてもしょうがないから コンシューマー
側で実装すればいいっていうの が多分よくあるパターンなんだ
けど 仮にストリームが本当にexact リバンスを保証してくれたら それ
に勝ることはないので
そうですね ありがたい
その分でもやっぱり 再送とか 1回を保証するみたいなのは 負荷
がかかってくるんですかね
もちろんかかってきますね やる ことを どこでコンピュテーション
処理をするかっていうのは違い に過ぎないので どこに重荷を負
わせるかっていう話に過ぎない ので あとは最後には やっぱりKafka
を使ってる
知ってるデベロッパーがこっち とかイギリスとか欧米圏だと多い
気がするので そういった技術親和 性を考えて Kafka使ってるとことか
も多いかな またPubSubとかKinesis Stream使うの
そんな難しくないんで ベンダー ログインとかそこまで考えそう
そうそう シンプルだから 基本的 にはパブリッシャーとサブスクライバー
もしくはコンシューマー データをプッシュ して
ある意味 Kafkaはラーニングカード が結構厳しいというか ところ
があるから 知ってる人がいない ところでは導入しづらいかなっていう
のはありそうですかね
かもしれないね
やっぱり小さい規模とかスタートアップ とかだと 最初はそういうパブリック
マネージサービスを使っていく のがやりやすいみたいなところ
はあるかもしれないですね
それが多いと聞く感じも いきなり スタートアップがアパートサービス
とかアパッチカフカのセルフホスト とかはちょっと
それだけで終わっちゃいました
何をしてるんだというか GCPのPubSub とかAWSのKinesis Streamとかすごい
27:02
よくできてるんで ボタン一つで 結構スケールしますし
そういうところからストリーム の概念を理解していくっていう
のが 時間がないときはいいかもし れないですね
そうですね
あとさっきアパートサービスの アパートサービスっていうのが結構
大きくなってくるんですよね そうですね
はい
アパートサービスのアパートサービス のコネクトの話したと思うん
ですけど 例えば Elasticsearchとか 別のデータベースの各ブックに
コネクト使えるよっていったん だけど 似たような考え方はもちろん
GCPとかAWSでもサポートしてるん ですよね
要するに イタゴラスイッチ的に いろんな特徴のあるデータベース
とかコンポーネント組み合わせて いく 例えばAWSだったらKinesis Stream
の先にラムダを挟んでから DynamoDBに入れてみたいなのがすごい難しくて
悪くないというか 割とやりやすい 場合によってはGUIだけで設定でき
たりとかするから そのイタゴラス イッチがAWSの中だけ組みやすく
なってるので そこら辺がどこまで 自分たちのビジネス要件に合う
か やりやすいかっていうのも一 つコールポイントかな
Kafkaと並んでApache Zookeeperっていう のも結構名前も聞くんですけど
これはどういうふうに使われるん ですか
おー いい質問ですね 今日の中で 一番好きな質問
なぜ好きかというと まずApache Zookeeper っていうのは また別のバイナリー
ですと サービスですと 確か4KB までだったかな デフォルトだと
Apache Kafkaの中でどう使われてる かっていうと Apache Kafkaを運用する
ためには
複数台のノードなんですよね 例えば 最低3台から4台 5台のノードが動いて
いて それらがコンセンサスを取り ながら スケールアップしたり データベース
として インストリビューティッド データベースとして分散データベース
を動いてるんですけど その分散 データベースを運用するためには
いろいろなメタデータが必要なん ですね メタデータといってる
のは まず 例えば 誰がリーダー かっていう話になるんですけど
ちょっと話が飛び過ぎたら戻り ますが 例えばじゃあ Kafkaを運用
するために Kafkaのノードとしては プロセスとしては3台必要なんですね
最低 基本的には この3台 別々の じゃあ 例えば US East 1のリージョン
の ここのアバイラビリティゾーン と ここのアバイラビリティゾーン
と ここのAZで3台動いてて その 3台のうち 1台がリーダーっていう
ものを動かす &他の2台が ホロワー という形で動いてます
Kafkaではこれどうなるかっていう とすべてのデータは まずリーダー
30:02
にいくんですよ すべてのデータ がね リーダーが処理するんだけど
そのリーダーが処理したデータ を 2台のフォロワーにレプリケーション
複製コピーするんですね これ なぜかというと 分散データベース
1台だと対障害性がないからですね
例えばこのリージョンのこのAZ
アバイラビリティゾーンで動かしていたとして
AZ障害 ゾーン障害があって
リーダーが落ちました
リーダーが落ちたら
それに書き込んでたデータはなくなりますよね
リーダーが立ち上がるまで ゾーンが戻るまで
それが許容できないので
2つ以上のフォロワーを作り
そのフォロワーにデータをリプリケーションして
もしゾーン障害とか
あとはリーダーのノードが
マシン障害で消えちゃったときには
可能な限り瞬時に別のフォロワーがリーダーに昇格して
今度こっちに書き込んでねということができるように
作られている必要があるんですよね
こういったディスリビューティッドデータベース
そのときに誰がリーダーなのって
どこに保存するのって話ですよね
うん
分かります?
誰がリーダーなのっていう
これはリーダーノードにはもちろん保存できないですよね
だってリーダーが死んだら
誰がリーダーなのっていうのが
誰も分からなくなってしまう
はい
なので
Apache Kafkaの3台のノードとは別の
ZooKeeperという
メタデータのデータベースを持っておいて
そこにKafkaを運用するのに必要不可欠な
例えば誰がリーダーですかとか
あとはこのリーダーとフォロワーがどこの
IPアドレスでどこのAZにいますかみたいな
最低限のちっちゃいメタデータを保存しておくための
別のZooKeeperというものがいた
いる
いる
いる
はい
でZooKeeperはZooKeeperで
ちゃんと対象外線を考慮された3台とか5台のノードなので
2つのディスリビューティッドデータベースが
組み合わさってApache Kafkaを動かしているということになりますね
このZooKeeperは他のデータベースとかでも
こういったメタデータストアとして使われることが多いですね
Kafka以外でも使えるんですね
使います
似たものとしては例えばKubernetesとかETCDとかね
みたいな感じですね
状態とかを関連しているわけですね
コントロールプレイにある
そうそう
コントロールプレイとはちょっと違いますね
リーダーっていうのはいるから
コントロールプレイ
リーダーっていうのがいるから
リーダーっていうのがいるから
リーダーっていうのがいるから
うん、コントロールペンのディフィニションの定義次第ですけど。
つまり、ZooKeeperが落ちるとKafkaは機能しなくなりますね。
そうなんですね。めちゃくちゃ重要な存在なんですね。
33:03
そうそう。だから、セルフホストのApache Kafkaをするときって、今までだったらApache ZooKeeperも運用しなきゃいけなかったので、超めんどくさい。
そういう人なら、それを込めてやってくれると。
うん、そう。なんだけど、これがなぜいい質問になったかっていうと、すごいタイムリーなんですけど、Apache Kafkaの中で、Kafkaを向上させるためのプロジェクトっていうことで、Kafka Improvement Project、KIP、KIPっていうのがあって、
これが、なんだろうね。
GitHubのIssue番号が、
GitHubのIssue番号なんですけど、要するに。これがその、コンフルエンス化のウィキに、例えば、KIPの〇〇〇番は、Apache Kafkaのこういう新しい新機能を実装しますみたいな形で、Kafka Improvement Proposalか、そういうものがあるんだけど、KIP、KIP500番っていう、割と有名なプロポーザルがありまして、語呂もいい500番。
これは、KIP500は、
Replace Zookeeper with a Self-Managed Metadata Quorumというところで、この500番、KIP500のプロポーザルが目立ちているところは、Kafkaを運用するために、今まで必要だったZookeeperをなくしましょうっていうプロポーザルなんですよ。
すごい、革新的な。
そう。だって、Kafkaを運用するために、なんでわざわざ別のZookeeperも必要なの?みたいな。
マシンリソースも食うし。
Zookeeperの運用も考えなきゃいけないし、みたいな。
ですね。
これが今、すごい粛々と動いていて、やってることとしては、RAFTっていうコンセンサスアルゴリズムを、Apache Kafkaの中に組み込むことで、そのリーダーエレクションとかにメタデータストアを必要としないっていう、割とよくあるパターン。例えば、Neo4jとかでもそうなんだけど。
そうなんですね。
うん。
すごい人がコンフルエントに入ってですね、ガリガリ詰めてて。Apache Kafkaの2.8から、ベータみたいな感じで使えるようになってますので。
まだ立ち位置としては、本番では使わない方がいいかもね、みたいな物言いだった気がしますが。
でも、かなり使えるレベルに上がってきている、仕上がってきているんじゃないかなっていう。
そうそうそう。
へぇー。
上場企業とか、フィンテック企業の、ヘアワンのプロダクションはまだ使わない方がいいかもしれないけど、ちょっとしたエクスペリメンタルとか、あとは、あまりビジネス要件がクリティカルじゃないってことがあったら、全然試してみて、Apache Kafkaコミュニティにフィードバックするくらいでいいんじゃないかな。
普段にまだ、年収サービスにはこういうのが反映されてるなと思うんですけどね、そしたら。
36:03
あー、MSK。AWS、MSKとか。
はい。
そういうクラウドとか。
ちょっと分かんないですね。でも、MSKを使うという意味に関しては、そこまで気にしなくていいはずなので。
そうですよね。自分でやらないと。
確かに。
メイトとしてはクラウド側、ベンダー側でコストが下がるっていうところになると思うんで、こちら側はそんなに。
そうそうそう。そうなんですよ。マシンリソースが減るし、運用コストも減るんで。これがもう、完璧に動いてくれたらもう。
すごい、最高の機能ですね。
インスタンスを、3台とか結構でかいですもんね。それなりに。
そう。
ちゃんと冗長性を保って運用していくっていうのは。
うん。
これだけだいぶ、コスト面では大きそうですね。
大きいですね。
うん。
そう。
こんな感じかな。
アリゴリズムとかっていうのは結構、ブロックチェーンとかもやってるようなプログラム。そういうところとも繋がってきそうで、面白いですね。
分散DBだったら、基本。
はい。
基本的には、コンセンサスアリゴリズムがないと。
はい。
なので、保証できないので。
確かにそうです。面白い。学学会ですね。
うん。
こんな感じかな。
はい。
はい。
じゃあ、そうですね。カフカについての深掘りは、別の回でもう少しやりたいなと思ったんですけど。
うんうん。
はい。
今回、最後にそうですね。なんか、キャッチアップとかカフカをしていくのに、おすすめの方法とかって、もしあれば伺いたいなと思うんですけど。ストリーミングの全体を見ててもいいんですけども。
うん。
こういう方法でやっていくと、理解しやすいよとか。
あー。
もしあれば、伺いたい。
はい。
分かりました。
まず、キャッチアップでどこまでを目指して。
はい。
キャッチアップを目指したいか次第で。
はい。
もう、アパチカフカって、良くも悪くも、枯れてる側の技術だと僕は認識していて。
はい。
ストリーミング商品は。もちろんどんどん進化はしてるんだけどね。結構その、ベストプラクティスみたいなのも出てきたし、メトリクスとか、運用方法みたいなのも、割とどんどんどんどん進化して、枯れてきている。いい意味で枯れてきているので。
はい。
で、その、マネージドサービスもいいのが出てきて。
はい。
例えばさっき言った、アパチカフカのコミッターとか所属しているコンフルエントクラウドとか、あとは対抗馬のAmazonのMSKとか。
はい。
で、自分たちでKubernetesとして動かそうとすれば、例えばStreamGみたいなオペレーターを使うと、まあ、めんどくさいけど、まあ、自分たち、今まで売れ簡単にできたりとか、進んできているので。
39:01
はい。
その、カフカの内部構造を知りたい。もしくはカフカの運用側に回りたい。
うん。
まあ、回らなくてはいけないっていう、まあ、人たちなのか、単純にカフカを、その、ディベロッパーとして書き込み、読み込みがしたいだけなのか。
うん。
そこが、まず大きな分かれ道ですね。
確かに。
で、その、全社のカフカを運用する側に回ると、多分、全世界のこう、ディベロッパーの割合で、多分、そんなに1%もいないぐらいだと思うんですよね、多分。
うん。
なんか、ビッグテックとか、それこそAmazonのMSKとか、コンフルの裏側で、カフカを運用しなきゃいけない。
はい。
ような人たち、もしくは、既にカフカを導入している、中規模以上のサイズの企業に採用が決まりました、ぐらいの人たちなので。
はい。
基本的には、まあ、なんだ、カフカをユーザーとして使いしたいディベロッパーがほとんどだと思うので、そうなるとキャッチアップはそんな難しくないかなと思うんですよね。
クラウドサービスで立ち上げることができるし、まあ、セルフホストでもそんなに難しくはないと。
運用は難しいんだけど、使う側、例えば、カフカにクライアント使ってプロデューサーとしてロゴを書き込んだり、コンシューマーを読み込んだりみたいなところはそんな難しくない。
クライアントもいいクオリティの方が出てるので、Goとか、Javaはもちろんあります。
結構、いろいろ例が挙がってて、それを真似せれば。
はい。
簡単にできるみたいなところはありそうですね。
うん、そんなに難しくない。ディベロッパーとして使うだけだったらね。
うん。
仮に運用に回らなくちゃいけないっていうシチュエーションが出た、もしくは、何らかの理由でセルフホストしなきゃいけないみたいになったら、なんだろう、まあ、なんか近道とかあるのかは知らないけど。
はい。
うーん。
まあ、Confluent Cloudが定期的にブログを出してるので、それを使うことができる。
はい。
うん。
それはRSSで読んでるとか、あとは、やっぱり学習リソースがすごい充実してるんだよね。Confluent Cloudがマーケティング目的でいろんなビデオ出してたりとか、Confluent Cloudベースの資格もあるんで、アパティカフカの運用にフォーカスした。
フォーカスとか。
うん。
3万ぐらいで受けられるやつで、僕は持ってないんだけど、うん。
なんか勉強はした。うん。
うん。
だからそういうのを、試験を受けて、最近のAPIとか。
うん。
チェックしてみるとか。
それはいいですね。
うん。
とか、いろいろ出ると思うので。
うん。
そう。
また、押さえなきゃいけない概念っていうのがある程度あって、これオライリーからいい本が、アパティカフカみたいな、もうまさにみたいなタイトルで、今出てるので、それを読むとかかな。
ちょっとじゃあ、それも小ノートに貼ってみましょう。
42:01
はい。
わかりました。
ありがとうございます。
ありがとうございます。
ありがとうございます。
はい。
話ですね。
はい。
すごいいろいろ聞けて勉強になりました。
ZOOkeeperの話とかもすごく面白かったです。
うん。
ちょっと深掘りしたいところ結構あったので、また次の回でお話しさせていただければと思います。
はい。
なんかコメントとか、もし気になることとかあれば、ぜひよろしくお願いします。
お願いします。
では今日はこんなところで。ありがとうございました。
はい。お疲れ様。
