Kaigi on Rails 2020に登壇して、Kafkaを使ったサービス分割の話をしてきました。

2020/10/3 に開催されたKaigi on Rails 2020に登壇してきました。

オンラインのイベントやカンファレンスに登壇したことはあるんですが、今迄割とカンファレンスの現場感みたいなのが薄いなと感じる中で、Kaigi on Railsはかなり以前の祭り感みたいなのを感じることが出来て、とても良いカンファレンスだったと思います。

特にSpatial Chatでカンファレンス会場の廊下っぽい空気を完璧とは言えないまでも再現出来てたのはとても良い試みだと思いました。

さて、私はというとキーノートを除いた通常発表のトリとして発表させていただきました。

(午前だったら寝坊してたのでやばかった……、運営チームの気遣いに感謝しておりますw)

内容は以下の通りです。

speakerdeck.com

背景とか反省とか

RailsというWebアプリケーション開発のフレームワークを中心にしたカンファレンスということで、割と業務ドメイン特有の要素が前提になっていても良いかなあと思い、無理に一般的な話として頑張らないことにしました。

最近、増え続けるデータ量と複雑化するデータパイプラインの活用に頭を悩ませ続けているので、そういった高負荷な非同期処理が連鎖する環境でKafkaを活用してサービスをバラしつつ高トラフィックかつ複雑な処理を実装する、ということをやってまして、Railsでやってたころとどの辺りが違うのか、という話を中心に資料を作りました。

発表後にTwitterで何人かに「何故こんなことをRailsでやるのか分からん」みたいな感想をもらいましたが、自分も「ほんまそれ」と思いますねw

私がこの会社に正式に入ったのは4年ぐらい前で、当時は扱うデータは数百万件ぐらいだったんですよ。トラフィックも総データ量も当時から100倍以上は増えていて、しかもビジネス上重要だった機能を廃止して注力する方向を変えたり等もあって、根本的に構造が噛み合ってない箇所がいくつか残ったりしている状況でした。

なので、最初のころはRailsでも何とかなったっちゃなった訳です。

で、増え続けるトラフィックに対応しつつ機能開発をやり、その中で段階的にRailsと噛み合わない処理を色々と引き剥がしてきたので、こういう感じになっているという背景があります。

そういった機能開発要求の中で特にハードだったのが、データパイプラインの準リアルタイム化で、バッチベースの処理から大きくアーキテクチャを転換する必要に迫られました。

そこでアーキテクチャの中心にKafkaを置いて、業務のコアとなるデータパイプラインとWebアプリケーション側の非同期処理の複雑な非同期処理を上手く連携できる仕組みに寄せていこうと判断しました。

今回の発表は、そういった開発の流れの中で現在進行形で戦っている最中の話でした。

今も試行錯誤している最中の話だし、私自身が全ての範囲を見て実装できている訳ではないので、きっちりまとめ切って確信を持って話しが出来なかったのが多少心残りではあります。

特に、一般化してコードに落としたり知見をgemにまとめたりといったことが全然出来ていないので、そこは大分残念でした。

そして、いざ資料を書いてしまったら補足説明とかで色々と書き過ぎた結果、20分に全然収まらなくなってしまって、すげー発表時間をオーバーしてしまいました……。申し訳ありません。(この辺りも順番が最後の方でまだマシだった)

やっぱ、登壇経験がそこそこあっても、ちゃんと時間測って喋るリハーサルやらないと駄目だなーと反省しております。

結構資料が難産だったので、サボってしまったのが良くなかったですね。

という訳で、今回の発表は自己評価としては微妙な感じになってしまいましたが、何かしら伝わるものがあったなら幸いです。

来年もKaigi on Railsをやるぞ、という感じらしいので、またコンテンツ提供出来る様に頑張りたいと思います。次回もよろしくお願いします。

(来年はオフラインで集まれるんだろうか……)