Kaigi on Rails 2025 参加記

バックエンドエンジニアの河久保です

2日間にわたる Kaigi on Rails 2025 お疲れ様でした

今回の会場が東京駅丸の内南口から徒歩1分で着く会場だったので、中央線（一番丸の内寄りにホームがある）ユーザーの私としてはものすごくアプローチが良くて最高でした

次回は渋谷（神泉寄り）とのことで、井の頭線使うかなぁーとか考えながら帰途に就いてました

今回の Kaigi on Rails では聴講したすべてのセッションをスマートフォンで録音し、終わり次第 Notebook LM に音声データを渡すということを実践してみました

日英のセッション問わず文字起こし精度も良く、音声まとめ、レポート作成といったもの良い体験が得られました

以下のスクリーンショットは『Sidekiq その前に：Webアプリケーションにおける非同期ジョブ設計原則 / morihirok | Kaigi on Rails 2025』の音声データをソースとしてテキストレポートを作成したものになります

セッション中も PC のタイピングなどに気が削がれることがなかったので、今後のカンファレンスもこのスタイルで臨もうと思えるものでした

さて、ここからは本編の感想になります

聴講したセッションからいくつか所感交えて取り上げます

---

kaigionrails.org

他のセッションでも言及されていたのですが、今年の Kaigi on Rails は「非同期ジョブ」に関するセッションが多かったです

こちらのセッションは非同期ジョブのバックエンドを Delayed から Rails 8 から導入された Solid Queue に移行するというものでした

ここで紹介されていた障害事例（トランザクション内で perform_later）は弊社でも踏んでいたので、「わかる〜〜」と頷きながら聞いていました

弊プロダクトのコードを見てみると以下のような module でケアされていました

module TransactionAwareClient
  extend ActiveSupport::Concern
  include AfterCommitEverywhere

  included do
    around_enqueue do |_, block|
      after_commit do
        block.call
      end
    end
  end
end

今は Rails 7.2 移行に update されているので enqueue_after_transaction_commit オプションに切り替え済みです

フレームワークの進化に感謝です

---

kaigionrails.org

Rails 8.0 で本体から提供されるようになった認証プロセスの generator で生成されるコードを使って、 Rails がどんな処理を行っているかをステップを追って解説する内容でした

ブルートフォースアタックへのケアとして、Rails 7.2 でサポートされた controller の rate limit を利用したり、わざとハッシュ生成を遅らせる機構が入れていたりするということでした

またタイミング攻撃への考慮もされているよという紹介もありました

セッションは User と 1 : 多関係の Session というモデルで DB 管理で
理由はセッションハイジャック時にログインセッションを削除する際に redis データを全件調べる必要があり遅くなるからとのこと

セッション情報は ActiveSupport::CurrentAttributes を継承した Current というモデルでスレッドローカルなグローバル変数として格納するという実装になっている

パスワードリセットの挙動についても丁寧に説明いただきました

これだけみても devise にお任せしたくなる気持ちはとてもわかりますが、 Web アプリケーションを開発する身としては知っておくべき内容なので、普段触っているフレームワークのコードでレクチャーいただけるとても良い内容でした

---

kaigionrails.org

セッション終了して即座に社の Slack に投稿してしまうくらい印象に残ったセッションでした

module による table prefix を連動させた分離は packwerk を用いない形でコードとDBスキーマへの責務を見た目で分かるようになるので、導入してみたい気持ちが沸々と湧いてきました

運用面の事例紹介も大変学びが多かったです

バッチ処理のリスト化

目的や起動タイミング・頻度にとどまらず、何か異常ステータスになった際のリカバリ緊急度、リトライ可否といった内容が記載することを MUST として、属人化を防ぐ取り組みをされていました

エラートラッキング

弊社も Datadog によるエラートラッキングをやっていますが、エラーの軽重含めて通知量が多かったり、あまり理解できていないドメインの通知が飛んで来たりして取りこぼしがあったりします

これに対してはオーナーシップを持たせた旗振り役のがんばりで通知チャンネルの正常化させたというエピソードが紹介されていました

Runbook

障害対応やデータメンテといった本番環境の作業手順書の作成だけにとどまらず、 Runbook の利用回数、作業時間なども記録していました

これにより複数回実施されていたり、対応時間のかかるものに対して運用の見直しや恒久対応に向けた定量指標に基づいたトリアージが行われるということでした

---

9/30 に社内でのプチ参加報告会の機会をいただき、発表スライドを使って私の方から口頭にていくつかのセッションを取り上げて紹介させていただきました

早くみんなで同時視聴して感想戦したいので、アーカイブが公開されることを待ち望んでいます