はじめに
Kaigi on Rails 2025に参加してきました。
このようなカンファレンスに参加するのはRubyKaigi2025以来です
(良ければそのときのレポートも見ていただけると幸いです)
本記事ではDay1で自分が参加したセッションの個人的な感想をまとめていきます。
参加したセッション
Keynote: dynamic!
dynamic＝「動的に変化しつづけること」と定義してdynamicという発想をRuby、Rails、そしてプロダクトとスケールしていく、というお話でした。
「実現したいと思った機能についてベストプラクティスも時間経過や要件変更により変わってくるものであり、その時々に応じて設計を決めていく」という考え方はアジャイル的な発想だなと感じました(これは講演者の方もそうおっしゃっていましたが)。
自分の開発アプローチを思い返すと無意識的にやっていたことでもあるのですが、プロダクトレベルでのアプローチ(企画-開発間で動的にやり取りして設計を進めていく)はまだまだ弱い部分でもあるのでそういった部分は改善していきたい、と思いました。
そのpreloadは必要？──見過ごされたpreloadが技術的負債として爆発した日
設計方針の変更により使われなくなったpreloadを放置していたことによってOOMが発生し障害発生してしまった、というお話でした。
N+1問題の対応として何も考えずpreloadやincludesを使うことは多いですが、不要になったあとのメンテナンスって割と見落としがちだよなー、とドキッとさせられました。
（思い返せば弊社サービスでもそういうものは結構ありそう
）
メモリ監視を徹底する、bulletgemなどを導入するといった対策はもちろんですが、プロダクト成長に伴って扱うデータ量が増えたときにパフォーマンス影響などのデメリットについても意識しておくことを忘れないようにしたいと思いました。
もう並列実行は怖くない コネクション枯渇とデッドロック解決の実践的アプローチ
※今回の事象にデッドロックはあまり関係がなかったとのことで「デッドロック解決」という文言はなくなってました
業務上必要となる多数の情報を処理するためのバッチ処理を並列化したところ、DBコネクション数を適切に設定していなかったためにうまく動作しなかった、というお話でした。
RAILS_MAX_THREADSとかsidekiqのconcurrencyってよくわからないまま値を設定するケースが多いので、その意味を理解した上で設定しないといけないと痛感しました。
特に「この処理で最大でどのぐらいのコネクションが必要になるか」「そのコネクション数を担保できるスペックのDBインスタンスを用意できているか」について今後の機能設計ではちゃんと意識できたら、と思います。
全問正解率約3%: RubyKaigiで出題したやりがちな危険コード5選
Rubykaigi2025での出展ブースにて出題されていた問題についての解説でした。
「Railsで実装されたAPIのコードについて、パフォーマンスやセキュリティ的に問題がある箇所を指摘する」という内容だったのですが、5箇所全てを指摘できたのが約3%だったとのことです。
指摘すべき箇所は基本的なものであり実際にコード動かしてみれば気づけたかもしれない、と思いましたがコードだけ見てそれを見つけるのは困難でありコードレビューの難しさを同時に感じました。
ちなみに当時Rubykaigiに参加していた自分は「後でやろう」と思ってそのままやらずじまいでした
5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム
Fintechを扱うシステムに5年間携わってきた中で、高信頼性を保つために実践していることの内容共有を中心としたお話でした。
取り扱う領域の関係上システム要件として高い信頼性とセキュリティ性が求められるため、「システムとしてあってほしくない状態とは何か」「仮に発生してしまった場合に速やかに対応する方法」を意識している、とのことでした。
とはいえ属人的なそれを形式知に落とし込んで管理できる状態に持っていくのは中々難しい。。。
2分台で1500examples完走！爆速CIを支える環境構築術
30分近くかかっていたCIを2分台まで短縮するまでの過程を解説するお話でした。
rspecの並列実行とかtmpfsを活用したI/Oアクセスコストの削減など興味深いものもありましたが、最終的に物理サーバを購入してその中でCIを動かすというオチでズッコケました(笑)
GIT環境をオンプレで運用しているからこそできるウルトラC(死語)ですね
Railsによる人工的「設計」入門
「設計が体得できていない」とはどういうことなのか、そういったエンジニアに設計を体得してもらうためにどのように伝えていけば良いのか、についてのお話でした。
「システムの完成系をイメージして必要な要件に細分化していく」という自分の中でなんとなく無意識に実践している（はず）のやり方ではありましたが、無意識であるが故に「体得できていない」エンジニアがどのように考えているかというところまで考えが及んでいなかったように感じました。
今後ジュニアに設計を考えてもらう際のアプローチとして、このことを念頭に置いていきたいと感じました。
今改めてServiceクラスについて考える 〜あるRails開発者の10年
パーフェクトRuby on Railsにて掲載された「Serviceクラス」について、そのコラム作成者ご自身が10年以上経った現在改めてその必要性について考えてみた、というお話でした。
「Serviceクラスは良くない」と断じる、というよりかは「ビジネスロジックを雑にServiceクラスという括りに落とし込んだ実装をするべきではない」ということが言いたいのかな、と感じました。
個人的にはビジネスロジックを適宜別レイヤーのクラスとして切り出していくのはそんなに悪いことではないと思っているのですが、「〇〇Service」って名称そのものが抽象的な印象を受けるので用途に応じて〇〇Formとか〇〇Usecaseという名称で扱いたい派です。
まぁ処理内容が過不足なく推測できるようにクラス名が命名されていることは大前提ではありますが。
おわりに
RubyKaigiでは処理系やgemそのものに関するお話が多かった印象ですが、Kaigi on Railsではより実務に近い話が多くとても参考になったものもありました。
Day2も面白そうなセッションが多数予定されているので積極的に参加していきたいと思います。