はじめに
Day1に引き続きKaigi on Rails2025のセッションレポート(Day2)です。
Day1の記事も公開していますのでこちらもどうぞ
参加したセッション
ActiveRecord使いが知るべき世界：Java/Go/TypeScriptのORMアプローチ比較
各言語で使われているORM(O/Rマッパー)について、クエリ発行・スキーマ管理・多機能性に着目してそれぞれの実装の違いについてまとめたお話でした。
どの言語においても「型安全性が確保されているか」「コンパイル言語かどうか」などそれぞれの言語が持つ特徴を生かした実装がなされている印象を受けました。Rails(というかRuby)の場合「コード記述が直感的に書けること」が重視されていることが他言語との比較でよりわかりやすくなり、やっぱりRubyは個人的に性にあった開発言語だなーと再確認させられました。
小規模から中規模開発へ、構造化ログからはじめる信頼性の担保
プロダクト規模が大きくなることに合わせ、Datadogなどのデータ解析ツールの機能を十分に活用できるように実装したログ出力手法についてのお話でした。
非構造的なログでは解析にも使いづらい上にログ容量を圧迫するだけになってしまうので、継続的な運用を続けていくなら避けては通れないことですよね
今までLogrageとかのgemで対応していましたがRails8.1で構造化ログが標準サポートされるとのことで、こういった「ライブラリだけどほぼ必須になっている機能」が標準で組み込まれるようになっていくのはRailsではよくあるイメージですね
Sidekiq その前に：Webアプリケーションにおける非同期ジョブ設計原則
非同期ジョブを実装する上で考えるべきことについてまとめたお話でした。
「そもそも非同期で動かす必要のある処理か」などの導入の是非や「ジョブの処理単位をなるべく小さくできないか」など非同期処理に伴うリスク管理について検討することの重要性を再認識しました。特に非同期処理のネックだった「時間のかかるジョブの中断・再開機能」もRails8.1にてActiveJobContinuationsで実装されると考えると夢が広がりますね
Railsアプリから何を切り出す？機能分離の判断基準
大規模なRailsアプリケーションに対して、特定機能を別アプリケーションとして切り出すための5つの判断基準について紹介するセッションでした。
規模が大きくなるにつれてモノリシックなシステムだとだんだん苦しくなるので切り出したくなることは多々ありますが、いざ切り出してみたら大体管理が煩雑化してだんだんメンテしにくくなるんですよね。。。（特に連携周り）
切り出しを検討する前にこの判断基準は意識しておきたいですね。
非同期処理実行基盤、Delayed脱出〜SolidQueue完全移行への旅路。
Delayed(DelayedJob)からSolidQueueに移行させた時の作業手順とその際に発生した問題についてのお話でした。
移行先としてSidekiqProも選択肢にあったそうなのですが、リソース管理やコスト面の都合からSolidQueueを選択したとのことでした。Redisが不要でコスト的にもありがたいSolidQueueですがパフォーマンスが良すぎてDB負荷もそれなりにかかるようなので、移行の際には前項の非同期処理周りのチューニングも合わせて確認していく必要がありそうです。
Railsだからできる、例外業務に禍根を残さない設定設計パターン
例外業務(特定ユーザにのみに適用されるような独自業務)の設定について、その設定部分の実装をどのように進めていくか、に関してのお話でした。
弊社サービスでもこのような「例外業務」は多く、その管理をどのように設計するか？はかなり悩ましいところです。セッションでは「設定業務を担当者に簡潔に委譲できること」を意識して変更頻度と設定パターンに応じて設計を変えていった、とのことでそういった考え方はうまく取り込んでいきたいです。
ドメイン指定Cookieとサービス間共有Redisで作る認証基盤サービス
複数システム間で認証情報を共有する場合に用いられる認証基盤について、社内システム間での認証情報を共有するために検討したシンプルな構成についてのお話でした。
SSOほどリッチにしなくてもいいという場合には使えそうではありますが、Cookieに鍵情報持たせるのはいささかセキュリティリスクがあるような印象を受けました。しかしながら選択肢の一つとして持っておく分には悪くはないのかも？とは思っています。
「技術負債にならない・間違えない」権限管理の設計と実装
Railsアプリケーションの権限管理について、「間違えない」ことを重点においた設計やそれを実装したモジュールについてのお話でした。
admin?とかmanager?って実装時点では一見シンプルではありますが、その権限範囲が時間経過で変わったりその結果それらを超えるsuper_admin?が生えてきたり・・・、というのは大いにあるあるですね
なので、「この役職ができる機能は何なのか」というよりも「この機能が使えるのはどんな役職なのか？」ということを一元管理できるようにするだけでも一定の効果があると思いました。
それと認可周りのgemというと個人的にはcancancanを思い出すのですが、今回提示されたモジュールだと「対象、役割、操作、条件」を明確に切り分けられるので慣れれば扱いやすくなるのかもしれないですね
Keynote: Building and Deploying Interactive Rails Applications with Falcon
Pumaに代わるWebサーバとして開発されたFalconについて、それをRailsに導入するfalcon-railsの内部実装についての解説でした。
Shopifyで導入されているという実績やリクエストの並列処理パフォーマンス面でもpumaより優れている、とのことで導入する価値はありそうな印象を受けました。
まだ安易に自社サービスに導入するわけにはいかないとは思いますが、スタートアップのプロダクトであれば導入してみても良さそうに思えました。
終わりに
色んなセッションを通してRailsに対する知見というものがより広げられたように感じます。特に最近の技術について疎い部分も多かったので、そういった内容を学べる良い機会だったと思いました。
またほとんどのスピーカーの方が共通して「継続と改善」を強調していたように感じます。新規機能のリリースも重要ではありますが、それ以上に「既存の機能をどのように改善していくか」「その改善リリースを継続してできるようにする」開発体制を整えていくことも重要であると改めて考えさせられました。
自社サービスの発展のためにもこれからの業務にちゃんと取り入れていきたいです！
次回は渋谷開催
来年も楽しみです！