2025/9/26-27に開催されたKaigi on Rails 2025に、スマートバンクはゴールドスポンサーとして協賛し、登壇者3名を含む計21名で参加しました。
今回のブログでは、最近入社したメンバーを中心に、それぞれの視点から見たKaigi on Railsの模様をお届けします。セッションをはじめ普段なかなか会う機会のない他社のエンジニアの皆さんと直接交流できたことは、私たちにとって大きな収穫となりました。どうぞご覧ください！
すてにゃん (id:stefafafan) からはMasayoshi Takahashi氏による「Railsアプリケーション開発者のためのブックガイド」についてレポートします。
本発表は「書籍を読むことについて」「Railsアプリケーション開発者のためのブックガイドとは何かを考える」「書籍紹介」の三部構成となっており、前半で書籍を読むことの意義を整理してから、大量の推薦書籍を紹介するという流れでした。
冒頭で印象的だったのは、サービスを作るというのは単にソフトウェアを作ることにとどまらず、チームや文化を作ることでもあるという主張です。たしかに、「サービス」とはチームで作ることが多いですし、それをさらにユーザーに公開しフィードバックを受けるところまでの流れを考えるとおのずとチームや文化が大事になってきます。また、共通認識を揃えるという意味で書籍は便利という指摘にも共感しました。手元の作業メモ → 社内ドキュメント → 公開ブログ → 同人誌や書籍といった流れでスコープを広げていくことでより幅広い人の参考にしやすくできるなと常日頃思っていたので、とても納得できました。
ブックガイドの考え方として、大量の本を一生懸命読む必要はなく、気になった時にちょっとだけ読むので良いという主張がキャッチーですが理にかなっています。完璧主義に陥らず、必要な時に必要な部分を参照する「辞書的な使い方」を推奨するというスタンスが実践的でした。個人的には発表中で言及された「不良のための読書術」という本が気になりました。
後半の書籍紹介パートでは、信じられないスピードで次々と紹介されて爽快でした。「表紙はみたことがある」本も多く紹介され、「読んでなかったけどやっぱりこれは買うべきなんだな〜」と何度も思わされてよかったです。会場には「本屋さん」があったので、後ほど覗いてみたところ、本発表で紹介された本がわかりやすく展示されていました。Kaigi on Railsならではのとてもいい仕組みで、発表を聞いてすぐに興味を持った本を手に取れるのは素晴らしい体験でした。
実際のブックガイドはSpeaker Deckにて公開されているので、ぜひともご参考ください。
Railsアプリケーション開発者のためのブックガイド – Speaker Deck
masawada(
id:masawada)からは、Koya Masudaさん(@koxya)による「GraphQL×Railsアプリのデータベース負荷分散 – 月間3,000万人利用サービスを無停止で」についてレポートします。
現在、弊社のプロダクトではGraphQLを利用していませんが、以前の職場で利用した経験があり興味を持ったため参加しました。
発表の概要は、運用しているサービスがテレビで紹介されたことにより普段とは異なる傾向のアクセスが発生し、キャッシュが効かないページへのリクエストが増えてMySQLのToo many connectionsエラーが出たため、参照をレプリカに振り分けて対策したという内容でした。私自身も過去、特定の時刻にスパイクする性質のWebサービスを運用しており、瞬間的にAurora MySQL インスタンスあたりの max_connections の上限*1近くまで同時接続数が増えるような事象に遭遇したことがあります。そのため、非常に親近感のある内容でした。
GraphQLは基本的に、単一のHTTPエンドポイントにQuery(参照系リクエスト)とMutation(更新系リクエスト)をPOSTする形式で実装します。Railsには、更新系のHTTPリクエスト(POST, PUT, PATCH, DELETEなど)と参照系のHTTPリクエスト(GET, HEADなど)で接続先のDBを切り替える仕組みがありますが、GraphQLではすべてがPOSTになるため、この仕組みをそのままでは利用できません。そこで、graphql-rubyのtracing機能を活用し、 execute_multiplex イベントにフックしてDBを切り替えているとのことでした。
なお、Persisted Queryという仕組みを利用すれば参照系をGETリクエストにすることも可能です。ただし、事前に想定クエリを保存し、そのハッシュ値でやりとりする仕組みであるため、クライアント側とハッシュ値をうまく共有する必要があり、導入には手間がかかります。発表後に伺ったところ、検討はしたものの労力的に見合わないと判断し、導入は見送ったとのことでした。
また、本来は参照系であるはずのQuery内でDBに書き込みを行ってしまっているケースへの対策も紹介されていました。こちらはActive Support Instrumentationを利用してQuery内で発行されるSQLを特定し、参照のみと分かっているものだけを許可リストに加えるという手法でした。このように、GraphQLを利用する際に役立つテクニックがいくつか紹介されており、大変参考になる発表でした。
tanihiroからはMarco Roth氏による「Introducing ReActionView: A new ActionView-Compatible ERB Engine」についてレポートします。ReActionViewは、既存のRailsアプリケーションにドロップインで導入できる新しいERBエンジンで、従来のERBでは不可能だった高度なエラー表示やデバッグ機能を提供し、将来的にはサーバ側でのステート管理やReactコンポーネントとの統合まで視野に入れたプロジェクトです。
使い方はとても簡単で、bundle add reactionviewでgemを追加した後に、簡単な設定をするだけで既存の.html.erbテンプレートがそのままHTML構造を理解できる賢いエンジンで処理されるようになります。Erubi::EngineとAPI互換なので移行コストはゼロです。
ReActionViewの基盤となっているのは、RubyKaigi 2025で発表されたHTML-aware ERBパーサー「Herb」です。Erubiが正規表現ベースでERBタグを抽出するのに対し、HerbはPrismを活用してHTMLとERBの統合的なSyntax Tree（Interleaved Syntax Tree）を構築します。この構造により、HTMLタグの閉じ忘れなどをピンポイントで指摘できるエラー表示やデバッグ機能が実現されています。
特にデバッグ機能のデモでは、パーシャルのパスが画面上にオーバーレイ表示され、クリックするとエディタの該当箇所に直接ジャンプできる機能などが表示され、非常に優れた開発体験を垣間見ることができ、会場も沸いていました。
発表では、ReActionViewの6段階のロードマップが示されました。現在はLevel 1（エラーメッセージ改善）とLevel 2（HTML-awareエンジン）が実装済みです。今後Level 3ではActionViewの最適化、Level 4ではPhoenix LiveView風のリアクティブなビュー機能。さらに将来的なLevel 5-6では、React Server Componentsの概念をERBに持ち込む「ERB Client Components」や、ReactやVueコンポーネントを直接ERB内で使える統合まで視野に入れているようです。
昨今のWeb開発では複雑なUIはReactなどにお任せし、RailsはもっぱらAPIモードでの稼働が主流になっていますが、ReActionViewはRailsのViewレイヤーそのものを現代的に進化させることで、再びRailsでViewを構築したくなる世界を実現しようとしています。RailsのViewの未来にワクワクする素晴らしいセッションでした。
capytan からは Shohei Kobayashi (@srockstyle) さんによる「非同期処理実行基盤、Delayed 脱出〜SolidQueue 完全移行への旅路」の発表についてレポートいたします。株式会社スタディスト様で7年間運用してきた Delayed から Solid Queue への完全移行を半年で成し遂げた事例の発表でした。弊社でも Solid Queue の本番運用を始めたばかりであり、実践的な知見が得られるのではないかと期待して拝聴いたしました。
発表では技術選定理由、Delayed の線形スケールアウト不可能問題（FOR UPDATE による DB ロック競合）を Solid Queue の UPDATE SKIP LOCKED で解決した技術的背景、Solid Queue に監視機能がないための自前実装、そして移行後に直面した enqueue_after_transaction_commit 問題と過負荷問題への対応などが語られました。特に Solid Queue の内部実装の解説もあり、利用したことがない人にとっても分かりやすいトークだったと感じました。
day 2ではすろっくさんのセッションの前には非同期処理についての基本的な考え方が語られ、後にも enqueue_after_transaction_commit について語られておりました。day 2 は Rails の非同期処理について理解が深まる日だったのではないでしょうか。(「Sidekiq その前に：Webアプリケーションにおける非同期ジョブ設計原則」「非同期jobをtransaction内で呼ぶなよ！絶対に呼ぶなよ！」)
まとめとして、すろっくさんが「AI時代だからこそ、内部実装理解と設計・リリース計画が超大事」と強調されたことが印象に残っています。技術選定の背景にあるライブラリに対する理解、慎重な移行設計、予期せぬ課題への対応などが語られた後の締めくくりだったため、その言葉に重みがありました。また、運用を見据えて監視の仕組みを自前実装したお話など、愚直にソフトウェアエンジニアリングでサービスの信頼性を担保しようとしているその動き方について、同じ SRE に携わる者として見習わなければならないなと思いを新たにしました！
occhiからはkatakyoさんによる「もう並列実行は怖くない ~コネクション枯渇解消のための実践的アプローチ~」についてレポートいたします。
この発表では、外部のLLM APIサービスとの通信で長時間のI/O待ちが発生する処理を並列実行する際に遭遇する、データベースコネクション枯渇の問題とその解決策について解説されていました。外部APIを利用する実装においてよく直面する課題であり、非常に実践的な内容でした。
発表で紹介されていた主なアプローチは以下の3つです。
1. コネクションプールのサイズ設定
アプリケーション側で設定するコネクションプールのサイズについて、バッチ処理の場合とSidekiqによるバックグラウンド処理の場合それぞれで気をつけるべきポイントが解説されていました。特に、スレッド数とコネクションプールのサイズの関係性について、具体的な計算方法が示されていたのが印象的でした。
2. DB側の同時最大接続数(max_connections)の算出方法
データベース側で設定すべき同時最大接続数について、Webアプリケーション、バッチ処理、バックグラウンド処理それぞれからのコネクション数を考慮した算出方法が紹介されていました。登壇資料ではAWSを使用した場合の例が説明されていましたが、Google CloudやAzureなど他のクラウドインフラを使っている場合でも同じ考え方が適用できそうです。
3. コネクションを占有し続けないようにする工夫
長時間のI/O処理中にコネクションを保持し続けないための具体的な実装テクニックとして、以下の2つが紹介されていました。
ActiveRecord::Base.connection_pool.with_connectionを用いて、外部API通信中はコネクションを解放する- トランザクション外に長時間のI/O処理を分離する
これらのテクニックは、Railsでバックグラウンド処理を実装する際に知っておくべき重要なパターンだと感じました。特に、外部APIとの通信が頻繁に発生するシステムでは、このようなコネクション管理の工夫が性能とスケーラビリティに大きく影響するため、実務でも活かせる知見が得られる発表でした。
toshimaruからはTomohiro Hashidate (joker1007)
さんによる「今改めてServiceクラスについて考える 〜あるRails開発者の10年〜」の発表についてレポートいたします。『パーフェクトRuby on Rails』でServiceクラスの章を担当されたjokerさんが語るServiceクラス談、ということで興味深く聞かせていただきました。
私自身、『Fat Model の倒し方』という発表でServiceクラスについてはまとめたことがありますが、私の立場は下記の通りです。
- Serviceクラス: 定義がボンヤリしがちなので、その定義を明確にすることができ、チームでコンセンサスが得られるならアリ
- Form Object: “Form handles no Model” or “Form handles many Models” なときに使う Form Object 利用はアリ
- PORO: 特定のユースケース（単一責任）を処理するPlainなRubyクラスとして実装するのはアリ。モデルの補助輪として利用するイメージ。
まとめると、Serviceクラスに関しては否定寄り、Formクラス・POROはアリ、という立場です。なので、jokerさんの「実際の仕事の現場では（Serviceクラスは）出来る限り使わない方が良い」という意見には共感を覚えました。
Railsの敷いたレールを外れるのは相当な勇気と覚悟がいることです。深く考えずに「なんとなく便利そうだから」という理由だけでそこから外れるのは、Railsの良さを毀損する危険性があります。Railsが提供する高速開発は、CoC(Convention over Configuration)によって可能になるからです。
発表内で話されていた「想像が付く」実装とは、Railsの用意したMVCの枠を外れずにドメインモデルをきちんとコードに落とすことだと理解しました。私自身もエリック・エヴァンスのDDD本を読んで、DDDのキーコンセプトはユビキタス言語と境界づけられたコンテキスト、この2つであると感じています。
Railsを使っているとそのフレームワークの優秀さゆえ、ドメインの理解がおろそかになってしまうことがあります（Railsの技術的な制約にマインドが支配される）。しかし、Railsについて詳しくなればなるほど、そしてコードベースが肥大化すればするほど、重要なのはいかにRailsの制約の中でドメインモデルを境界付けて綺麗にコードベースに落とし込めるかであり、まさに「継続的に何度も判断を下し続けてコードとメンタルモデルを相互に改良し続ける」営みと言えるでしょう。
いかがでしたでしょうか。来年は10月に渋谷で開催とのことで今から楽しみですね！
スマートバンクでは、一緒にRailsで開発していく仲間を募集しています！
