Kaigi on Rails 2024に参加しました

こんにちは。

メディアサービス開発部 Webアプリケーション開発課のフサギコ(髙﨑)、シゲタ、今永です。普段はニコニコ漫画などのWebサービスのバックエンドをRailsを使って開発しています。

本記事では、2024年10月の25日から26日にかけて開催された、Kaigi on Rails 2024に参加したことについてお話します。また、本記事は各セクションを複数人で同時並行に執筆するモブブロギングによって書いています。

Kaigi on Railsとは

Kaigi on Railsは、主にRuby on Railsを使ってWebサービスを開発している開発者を対象とした技術カンファレンスです。

kaigionrails.org

日々の仕事としてのWebサービス開発の役に立つ考え方、事例の発表に重点を置いている点が、最も有名なRubyに関するカンファレンスであるRubyKaigiとは異なる特色となっています。

聞いたセッションの概要と感想

シゲタ：RailsのPull requestsのレビューの時に私が考えていること

RailsのPull requestsのレビューの時に私が考えていること - Speaker Deck

Railsコミッターの本田さんがレビューをする際に何を考えているのか直接話を聞ける機会ということで、非常に楽しみにしていました。

今回、個人的に特に重要だと感じたのは次の2点です。

バグレポートを提出する際には、問題の再現手順が特に重要であること
PRを出す際には、ユースケースが明確であり、かつそれが多くのユーザーに役立つものであること

最近、OSSにコントリビュートする機会が増え、実は今まさにRailsにissueを開こうかと検討していたため、これらのポイントが重要であると再確認できたのは良かったです。 OSSのレビュアーも本業の合間を縫って活動されているため、興味を持たれても不備があれば途中で離脱されてしまうこともあります。こちらも限られた時間を使ってOSS活動を行う以上、無駄にならないようにしっかりと準備をした上でissueやPRを作成していこうと思いました。

フサギコ：Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -

igaigaさんの発表で、スライドは下記に公開されています。
KaigiOnRails2024 - Speaker Deck

できるだけRails wayに乗りながら、様々な現実世界の物事の複雑さをどうやってRailsのモデルに落とし込むかについての発表でした。

DBに記録するべきモデルは、Resource型とEvent型*1に大別されますが、Eventを発見するのは意外と難しく、その見つけ方などの手法はこれまで自分が経験的にやっていた、体系化されていないやり方の言語化としてしっくりくるものでした。

また、DBに記録するべきかどうか判断できない何かを見つけたときにとりあえず名詞で命名したPORO*2として表現しておき、必要性が判明したらその必要性の段階に応じてActiveModel::ModelやActiveRecord::Baseを継承させる、という発展のさせ方は今までの発想になかったので、目から鱗が落ちる思いでした。

また、Service層を置くのは可能な限り避けたほうが良いという話のなかで、Event型のモデルを丁寧に探せればService層の誕生はかなり遅延できるというのも自分の中にはなかった知見でした。

全体として、今まではこの発表の中でも言及されていたyasaichiさんの過去発表の
「Railsは複数の層を意図的に密結合させることによってコードの記述量を減らし、機能作成にかかる時間を劇的に短縮する思想のフレームワークであるので、層をむやみに増やすのはその長所を自ら捨てている」
という内容は知っていつつも、複雑な内容を整理しきれなかったときにとりあえずSerivceを作って逃げるという選択をしてしまっていて、それに歯止めをかけられていない現状に一つの整理指針をもらえたような気がしました。

シゲタ：cXML という電子商取引のトランザクションを支えるプロトコルと向きあっている話

cXML という電子商取引のトランザクションを支えるプロトコルと向きあっている話 - Speaker Deck

cXMLという外部制約に振り回されながらも粘り強く向き合い続けている中で得た学びについての話でした。

購買管理システムにおいて接続先ECサイトとのデータ連携をさせる上でcXMLというプロトコルを使う必要があり、以下のような苦労があると話されていました。

仕様がリファレンスが600ページにも渡るくらい膨大でgemも全てを網羅できていない
接続先ECによって微妙に仕様が異なるのですり合わせが必要
伝票に印字できる文字数に制限があり商品が届かなかったなどの物理的制約

どのサービスも外部の制約には苦労されていると思うのですが、ECとのデータ連携はコアに近い機能だと思うので、余計に難しさが増している印象を受けました。それでもcXMLは面白いと話されており、この複雑さに向き合い続けてきた方ならではの凄みを感じました。

最後に話されていた、イレギュラーケースにどう向き合うかがエンジニアとしての腕の見せ所、という言葉もとてもいいなと思いました！

今永：デプロイを任されたので、教わった通りにデプロイしたら障害になった件〜俺のやらかしを越えてゆけ〜

デプロイを任されたので、教わった通りにデプロイしたら障害になった件～俺のやらかしを越えてゆけ～ - Speaker Deck

デプロイを任された当時新卒1年目の発表者が、デプロイに起因して発生した3つの障害について、それぞれどのように原因を究明していったのか、どのように対応したのかについての発表でした。

私自身新卒1年目で、デプロイの仕組みを完全に理解できているとは言えない中で、親近感を持つと同時に、「明日は我が身」と身の引き締まる思いで聞いていました。

また、原因究明までの流れが丁寧に説明されており、学びのある発表でした。原因調査の際に発表者が先輩からアドバイスされたという、「原因調査をしたくなるのもわかるが、まずは関係部署に連絡と顧客影響を調査」という言葉が印象に残っています。開発者以外にも大勢の関係者がいるという点は私もまだ忘れがちなため、今後意識していきたいです。

この発表をきっかけに、私もデプロイに目を向けていきたいと感じました。

今永：推し活のハイトラフィックに立ち向かうRailsとアーキテクチャ

推し活のハイトラフィックに立ち向かう Railsとアーキテクチャ - Kaigi on Rails 2024 - Speaker Deck

突発的に秒間660件にも及ぶ決済リクエストが発生するイベント物販サービスにおいて、トラフィックにどのように対処しているのかという発表でした。

スロークエリを起こさないようにし、CDN やアプリケーションでのキャッシュを活用しても、トラフィックが多いと耐えきれなくなってくるとのことでした。それに対する対処の一例として、リクエストが特に集中する先着販売において在庫確保をどのように行うか、外部決済 API のレートリミットにどのように対処しているのかという話がありました。

在庫確保に関しては、テーブルの1行を1つの在庫に対応させるようなテーブル設計にすることで、行ロックによって発生するロック待ちやデッドロックを回避するというやり方が紹介されていました。ハイトラフィックなサービスにおいては、セオリーから離れた設計が必要になるという学びがありました。

決済関連 API のレートリミットへの対処については、「正しく諦める」という言葉が印象的でした。手を尽くしても解決できない問題があり、それに対してどう対処していくかが大事であるという視点が得られました。

この発表を通して、ハイトラフィックに対処するための1つの解を知ることができたと感じています。

フサギコ：Sidekiq vs Solid Queue

Sidekiq vs Solid Queue - Speaker Deck

Webサービスを開発しているとたびたび生まれる非同期ジョブの実行について、その実行を担うライブラリの変遷を追いながら、現在最も使用されているSidekiqと、Rails8.0で新たにデフォルトとなったSolid Queueそれぞれの長所と短所を比較するものでした。

DBをジョブキューとして使用する非同期ジョブライブラリというと、僕がまず連想するのはdelayed_jobでしたが、これは発表中でも言われている通り大量にワーカーを起動したときにロック競合が起きるためスケーラビリティの点で難点を抱えていることが知られています。

そのため僕個人としては「DBをジョブキューとして使うのは悪手なのでやめたほうが良く、sidekiqのほうがピーク性能が高いため良い」という認識で止まっていたのですが、時代が進んで

DBサーバーのブロックストレージがHDDからSSDになってシーク待ちなどに起因する読み込み待ちが劇的に短くなったこと
MySQL 8系がSELECT FOR UPDATEとSKIP LOCKEDに対応したこと

によって、Solid QueueではDBをバックエンドにしてredisが不要でありながらある程度ボトルネックになりづらくなっており、一定の性能を達成できるようになったというのは技術選定の候補として考えるうえで参考になる情報でした。

なお、僕が仕事で開発しているニコニコ漫画の新バックエンドはAWSを大いに活用しているため、定時実行ではない非同期ジョブのバックエンドとしてはaws-sdk-railsに実装されているsqsアダプタを、定時実行するジョブにはrakeタスクとecscheduleの組み合わせを用いています。

フサギコ：Importmapを使ったJavaScriptの読み込みとブラウザアドオンの影響

Importmapを使ったJavaScriptの読み込みとブラウザアドオンの影響 - Speaker Deck

仕事で開発しているニコニコ漫画の新バックエンドはAPIモードのRailsであり、Webフロントエンドは普段ほとんど触っていないのですが、Rails 7.0でwebpackerではなくimportmap-railsがデフォルトになったというくらいの情報は追っています。そのimportmap-railsを実際に使ったときにどのようなコードになるのか、どのような困ったことが起きたか、というものでした。

エラートラッキングのライブラリをCDNから読み込もうとしてファイル名一致で見るアドブロッカーにブロックされてturboとして動いていなかった事例はなんとも言えない気持ちになりつつ、機能のために本質的に必要でブロックされづらく、サイズの大きいものが選択的にimportmapを通じて外から読み込まれるようになっていくのかな、という感想を持ちました。

また、これら内容をうけての3階のわいわい部屋で、DHHは各時代のjavascript界隈の動向を思ったよりもちゃんと観察していて、sprockets、webpacker、importmap-railsまたはjsbuilding-railsと各時点においてシンプルなツールを出している。けれどそれらの間にかなり大きな破壊的変更があって、フロントエンドまでrailsにベットするのはなかなか辛い…といったような雑談をしたりしました。

フサギコ：Data Migration on Rails

Data Migration on Rails - Speaker Deck

DBのスキーマを変更するスキーママイグレーションと、DBに記録されているデータを変更するデータマイグレーション、厳密には異なるこの二つのマイグレーションですが、場合によっては同時に実行したくなることもあります。

そんなデータマイグレーションについて、どのような実行方法があるかを使用するライブラリなども含めてサーベイするような内容でした。

過去にはrailsのスキーママイグレーション機能を使ってみていた時期もありましたが、そうするとモデルの実装がリファクタによって消えたりしたときにエラーが発生するようになって困ったことは僕も経験していて、みんな困っているんだなぁと思いました。

最後に紹介されていたshopifyのmaintenance_tasksも小耳にはさんだことはありましたが、仕事で開発しているニコニコ漫画の新バックエンドはAPIモードのRailsであり(2回目)、またDBスキーマの管理もridgepoleを使っているのでrailsのスキーママイグレーション機能に乗るのも難しく、APIモードなのでsidekiqのようなRails engineでダッシュボードを提供されるようなgemは導入しづらかったり… 結果として主にrakeタスク、緊急性が高い場合はRailsコンソールで操作していて、今も試行錯誤が続いています。

参加してみての感想

フサギコ

総じて、Kaigi on Railsのコンセプト通り、明日から仕事としてWebサービスを開発していくうえでの一つの指針として参考になる発表が多かったなと思います。

Palkanさんの基調講演から、igaigaさん、そして最後のsnoozer05さんの基調講演まで、RailsでWebサービスを開発する上では、いかにして必要以上のレイヤ分割を避け、認知負荷が下がるようにシンプルに整理するかが重要という経験則、メッセージが一貫していたように思いました。

スポンサーブースでもYOUTRUSTさんのブースでUseCase層を設けたときのspecの書き方や、更にCQRS*3をしたときの嬉しさについて話し込んだりして、コンピュータサイエンス方面の知識欲の刺激になるRubyKaigiとはまた異なる種類の、日常の仕事に対する刺激を多く受けたカンファレンスでした。

シゲタ

私は一昨年のRubyKaigi 2022以来のカンファレンス参加だったのですが、会場のエンジニアの方々との交流で刺激を受け、イベントに参加することって大切だよねというのを再確認しました。

特に印象に残っているのは、業務で使っているgemのメンテナーの方々に、直接感謝をお伝えできたことです。普段お世話になっている方々が一堂に集まる場はそうないので、Kaigi on Railsのような大きなカンファレンスの魅力を改めて感じました。

懇親会でも多くの方と与太話から仕事のことまで広く交流ができました。私が書いたブログを読みましたといってくれた方ともお話ができて、それも大変嬉しかったです。

今回はセッションから学びを得る目標とは別に、参加者の方々と積極的に交流しようという裏目標を立てていましたが、どちらも達成でき充実したKaigi on Railsになりました。

今永

今回、初めてカンファレンスに参加しました。私が Rails を学び始めたのは今年の5月頃からで、まだ半年も経っていない中での参加でした。そのため、発表内容を理解できるかという点に一抹の不安がありましたが、初学者向けの発表も多くあり、十分に楽しむことができました。発表内容についても、開発の事例や Rails と共によく用いられるライブラリの話、開発の際の設計指針など、幅広いことに驚きました。

懇親会は他社のエンジニアの方々とお話しする良い機会となりました。他社の方との交流を通して多くの刺激を受けることができ、Rails について学びを深めていきたいという意欲が湧いてきました。

総じて参加して良かったと思えたカンファレンスでした。来年も機会があればまた参加したいです。