• Home
• コーポレートブログ
• Kaigi on Rails 2025 にオンラインで参加した

こんにちは、日高です。2025年9月26〜27日に開催された Kaigi on Rails 2025 にオンラインで参加しました。いくつか印象に残ったトークを紹介します。

Kaigi on Rails とは

https://kaigionrails.org/2025/

Concept より引用します。

Kaigi on Railsのコアコンセプトは 「初学者から上級者までが楽しめるWeb系の技術カンファレンス」 です。 Kaigi on Railsは技術カンファレンスへの参加の敷居を下げることを意図して企画されています。 また、名前の通りRailsを話題の中心に据えるカンファレンスではありますが、広くWebに関すること全般（例えばフロントエンドやプロトコルなど）についても扱います。

今回特に感じたのは、実際の業務で得られた知見や教訓が数多く共有されていたことです。RailsやWeb系の業務に取り組んでいる人にとっては身近で、明日からでも活用できる内容が豊富でした。トークの中には難しい内容を扱うものもありましたが、身近なテーマが多かったことが、「参加の敷居を下げる」ことに繋がっていると感じました。

なお、Kaigi on Rails では各発表を「トーク」と呼んでいるため、本記事でも同様に記載します。

もう並列実行は怖くない コネクション枯渇とデッドロック解決の実践的アプローチ

スライド

ActiveRecordのコネクションプールの仕組み、枯渇の原因、安全なコネクション数設計についての話。

非同期処理基盤を構築する際、DBコネクション枯渇は見落とされがちです。考慮を怠ると、サービス全体に障害を引き起こす可能性もあります。このトークでは、コネクションプールの仕組みから、枯渇を防ぐための詳細な見積もり方法まで解説されており、非常に実践的でした。

現在まさに非同期基盤の構築に携わっているため、この内容は大きな学びになりました。特に最大コネクション数の見積り方は、プロジェクトですぐに活用できるものでした。非同期処理やジョブ開発に関わる方は、一読をお勧めします。

そのpreloadは必要？──見過ごされたpreloadが技術的負債として爆発した日

スライド

不要な ActiveRecordのpreload が大量のメモリを消費し、サービス障害に発展した話。

preloadは便利で速い一方、多くのメモリを消費する場合があります。このトークでは、preloadのメモリ消費が増加する仕組みを解説し、防ぐことができなかった理由についても分析しています。「常にトレードオフがある」という教訓は強く印象に残りました。

私自身も最近、Redmine 6.1 のリアクション機能開発で同様の課題に直面しました。当初は素直にpreloadを使いましたが、大量データでの計測ではメモリ消費が顕著に増加。このトーク中で紹介されていた「カウンターキャッシュ」は採用しづらく、結果としてメモリ効率とパフォーマンスを両立するために泥臭い調整を重ねました。最終的な実装に興味がある方は、こちらのコードをご覧ください。

Sidekiq その前に：Webアプリケーションにおける非同期ジョブ設計原則

スライド

非同期ジョブとは何か、なぜ必要なのか、設計原則や指針についての話。

現在進めている非同期基盤プロジェクトの方針を見直す良い機会となりました。特に「その機能は本当に非同期ジョブが必要か？」という問いは、自分の思考を整理するきっかけになりました。設計指針についても再確認でき、今後も資料を読み返したいと思います。

ドメイン指定Cookieとサービス間共有Redisで作る認証基盤サービス

スライド

複数サービスの認証を共通化する基盤を構築した話。

このトークでは、認証・認可の基本から、複数の解決策を比較検討して最適なアーキテクチャを選ぶ考え方までが紹介されました。

私も非同期基盤構築でアーキテクチャ選定を進めているため、大いに参考になりました。特に「標準技術が必ずしも正解とは限らない」という教訓は大きな気づきでした。広く使われている技術は有力な選択肢である一方で、課題や予算、ロードマップなど、プロダクトの状況に応じた冷静な判断が不可欠だと改めて感じました。

最後に

オンラインでの参加でしたが、非常に充実した二日間でした。Kaigi on Rails 2025 のスピーカー・スタッフの皆様に感謝いたします。ありがとうございました。