はじめに
合同会社春秋でエンジニアをしているfukuです！
弊社の研修の一環として、Kaigi on Rails 2025に参加してきました！🙏
Kaigi on Railsとは、「初学者から上級者までが楽しめるWeb系の技術カンファレンス」をコンセプトに、2020年から開催されています。
僕自身はRailsを扱う開発に携わって約1年半になります。今回は実際に参加してみて特に印象に残ったセッションをイベント参加レポートとして、3つほどピックアップしていこうと思います！
参加したセッション
Day1
- Keynote: dynamic!
- RailsのPostgreSQL 18対応
- そのpreloadは必要？──見過ごされたpreloadが技術的負債として爆発した日
- Railsアプリケーション開発者のためのブックガイド
- 全問正解率約3%: RubyKaigiで出題したやりがちな危険コード5選
- あなたのWebサービスはAIに自動テストしてもらえる？アクセシビリティツリーで読み解く、AIの『視点』
- Kamalって便利？社内プロジェクト3つをKamal + AWSで運用した体験談
- Railsによる人工的「設計」入門
- 今改めてServiceクラスについて考える 〜あるRails開発者の10年〜
Day2
- 2重リクエスト完全攻略HANDBOOK
- 小規模から中規模開発へ、構造化ログからはじめる信頼性の担保
- Sidekiq その前に：Webアプリケーションにおける非同期ジョブ設計原則
- Railsアプリから何を切り出す？機能分離の判断基準
- 非同期処理実行基盤、Delayed脱出〜SolidQueue完全移行への旅路。
- 非同期jobをtransaction内で呼ぶなよ！絶対に呼ぶなよ！
- ドメイン指定Cookieとサービス間共有Redisで作る認証基盤サービス
- "複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用
- rails g authenticationから学ぶRails8.0時代の認証
- Keynote: Building and Deploying Interactive Rails Applications with Falcon
印象に残ったセッション3選
そのpreloadは必要？──見過ごされたpreloadが技術的負債として爆発した日
本セッションは、開発当初はpreloadの実装はN+1を解消するために必要だった実装が、プロダクトの成長に伴い技術的な負債になってしまっていたという内容でした。具体的には、設計の変更や更新があり、preloadしていたモデルに子モデルが増えていたことで、取得されるインスタンスも増えてメモリを圧迫していたというものでした。
対応策としては、
- メモリ監視、アラートを用意する
- preloadのリスクを認識する
- gem bulletを使って不要なpreloadを確認できるようにする
という方法が紹介されていました。
また、このセッションから、当時は適切実装をしていても、プロダクトの成長に伴って適切な実装も変化するんだという気づきがありました。実装する時にはプロダクトの変化に応じてメンテナンスできるように考えておくことが大事で、そのために「システムの監視」と「実装のリスクを事前に認知しておくこと」がその一歩につながるんだなと思いました。
本セッションはpreloadの実装に関する具体的な一例でしたが、他の実装においても、プロダクトの成長に合わせて改修していくことが大事で、そのために「メンテナンスしていくには何が必要か？」という視点で考えて実装することも大事であることを学びました。
Railsによる人工的「設計」入門
本セッションは、「設計を体得できていない状態って？」、「設計って？」、「じゃあ設計するにはどうしたらいいの？」を扱った内容になっていました。
私自身も、最近実務で初めて設計をしてみて「難しかったな〜」と困っていた体験があったので、その体験を思い出しながら聞いていました。
セッション内容でも挙げられていましたが、私自身も「実装前に設計してね」「設計する時には図とか表にするといいよ」というアドバイスをもらい、いざ設計してみたのですが、設計するためにまずは具体的に実装コードを考えて、そのコードをベースに図や表を考えて etc…とセッションと全く同じ思考・作業プロセスを辿っていました。頷き止まりませんでした。
では、そもそも「設計って何だろう？」について
- コードのレベルで考えることではない
- 全体の構造、技術的要素を考え作るものを考える
- 作業の段取りを考えても良い状態にすること
と紹介されていました。
これを踏まえた上で、「なるほど。自分が設計だと思ってやっていたことって設計ではななかったんだな〜」、「実は、ただの手順の羅列だっだんだな」と気づきがありました。
では、「どうしたら設計できるのか？」に対して、「完成したシステムから、何が必要なのか？を逆算的に考える方法」が紹介されていました。具体的にゴールから考えることで、「そのためには何が必要か？」「Aの実装？Bの実装？それぞれどんなメリデメがあったのかな？」というふうに実装の構造を考えていくことができそうだと思いました。実際に試してみて、設計の感覚をつかんでいきたいと思いました。
非同期jobをtransaction内で呼ぶなよ！絶対に呼ぶなよ！
本セッションでは、トランザクション処理内で非同期処理を行うことの危険性について触れていました。具体的には、非同期処理の実行タイミング次第で、ActiveRecord::RecordNotFound が発生することがあるというものでした。この問題の厄介な点は、問題の発生が非同期処理の実行タイミングに依存することで、トランザクション処理のコミット前か後なのかで結果が変わることで、「実行が、トランザクションのコミット前だと失敗するし、コミット後だと成功する」状態になってしまうことです。
こうなると、挙動が安定しないために検証が困難になってしまうなと感じました。
対策としては、
- 非同期処理はトランザクション外で行う
- gem(after_commit_everywhere)を活用する
- enqueue_after_transaction_commit(Ruby on Rails 7.2以降の場合)を活用する
という方法が紹介されていました。
実は僕自身も業務でこの問題に遭遇していて、その時は、非同期処理をトランザクション外で行うことで解決しました。（環境がenqueue_after_transaction_commitに対応していいなかったため。）また、gem(after_commit_everywhere)を活用するというアプローチについては、思いつかなかったので新たな知見になりました。
gemやenqueue_after_transaction_commitを活用する方法は、一度設定するとその後は「トランザクション内で呼んでないか？」と意識せずに手軽に実装できるメリットがある反面、gem導入にかかるコストや環境による制約があるので、ファーストオプションには向かないかもと感じました。
基本的に開発時には、導入コストや環境依存も無いため、「非同期処理はトランザクション外で行うようにする」を意識して実装し、どうしてもそれができない場合や実装ミスを無くしてより安全にしたい時などに、セカンドオプションとしてgemやenqueue_after_transaction_commitの活用を検討すると良いのかなと思いました。
まとめ
今回は記事で書いていないものセッションについても、日頃の業務で悩んでいたことのヒントになるものが多く、どのセッションも勉強になり面白かったです。
個人的には、去年初参加だったKaigi on Rails 2024の時よりも、同期的に理解できる内容が増え、成長を実感できる機会にもなったのですごく楽しかったです。
また、カンファレンスに参加することで、セッションを通して「新しい発見」や「学びにつながったこと」もそうですが、たくさんの社外のエンジニアの方とも交流できる場でもあり、良い刺激を受けることができました🙌
「もっと頑張らなきゃな〜」とさらに学習のモチベーションアップにもつながったので、今後も学習を継続して来年はさらに成長した状態で参加できるようにしたいと思います✨
Discussion