現地速報！ Kaigi on Rails 2025 Day2

はじめに

ブルーモ証券でエンジニアをしている才記です。
普段は Ruby on Rails でブルーモのバックエンド開発をしています。

昨日9月26日、 Kaigi on Rails が開幕しました！
今日9月27日の Day2 も引き続き、会場の様子を速報的にお伝えできたらと思います！

2重リクエスト完全攻略HANDBOOK

Web アプリではよくありがちな二重リクエストに対する対策の話。
弊社もそうですが、特にお金が関わるようなサービスは二重に同じ処理を行ってしまうと致命的なことになりかねません。

発表では実際の対策方法について、クライアント側とバックエンド側に分けて9つ紹介されていました。
基本的なサブミットボタンの無効化にはじまり、テーブル設計レベルで防ぐ方法やレートリミットを入れてしまうなど、いろいろなアプローチが紹介されていて面白かったです。

防御策自体はいろいろ考えられるものの、二重リクエストが実際に発生するとどれぐらいまずいのか、それを防ぐのにどれぐらいコストをかけていいのか、なども考える必要があります。
重要な箇所は堅牢に、そうでもないところは軽めに、など、バランスも考えながら導入していくのが実際の現場だと大事になりそうです。

実際、弊社でも何か間違った状態が発生するとダメージが大きい箇所についてはリクエスト内容のチェックを厚めにしていたりするので、聞いていて共感できたり、参考にしたいと思えることが多い発表でした。

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

非同期 Job の考え方について改めて整理するという、ベーシックだけど大事なことを再確認させてくれた発表。
Web アプリケーションがリクエストをさばくところから話が始まったので初心者でもわかる優しいセッションになっていた印象。

設計原則としては短時間、冪等なJobにしていくべき…だが、現実的にそれが難しいこと自体は多々あるよね、だから破り方も言及するね、というのが印象的というか面白かったです。
また、Rails 標準の機能として実行の中断や継続対策ができるようになるところについても言及されていて、そこもまたよかったです。

現状、結構原則を破ってしまっている Job も多いので、改めて今の Job でいいのかは再考したいところですね…

非同期処理実行基盤、Delayed脱出〜SolidQueue完全移行への旅路。

最近流行りの SolicQueue。 Delayed(Job) は私は使ったことがないのですが、比較的古めの非同期処理実行基盤だという認識なので、そこからの置き換えは大変そうだけどかなり意義あることなんだろうなという気持ち。

課題感としては「スケーラビリティ」、「柔軟なJob管理」、「ActiveJobへの（Rails Wayへの）移行、統一」という3点があったとのこと。

最終的には移行に成功、しかも処理性能は40倍！と、一見大成功…と思いきや、非同期Jobをトランザクション内で呼んでておかしなことになったり、性能が上がりすぎて本体DBが高負荷で死ぬ…みたいな障害発生していて、（ちょっと申し訳ないですが）面白く、ためになる発表でした。

弊社は Sidekiq を使っているのですが、個人的には SolidQueue を使ってみたい気持ちもありつつ…現状でものすごく困っているという訳でもないので難しいところです。
ビルドインの管理画面が現状だとなさそう？なのでそのあたりが整ってくるとより良さそうな感じがしています。

https://x.com/hanoniku_chan/status/1971801193631699286

Railsだからできる、例外業務に禍根を残さない設定設計パターン

提携農家さんの作るお野菜をいい感じに詰め合わせてユーザに送る、そんな素敵サービスを運営している坂ノ途中さん。ぱっとシンプルそうに聞こえるそのサービスもふたを開けると大量の例外業務があふれるビジネスだった…というお話。

お話全体を通じて、それが「例外業務」なのか「仕様として組み入れるべきものなのか」の判断はやっぱりなかなか難しそうだなぁという印象を受けました。例外業務なんてない方がいい、という前提もあって猶更。

とはいえ最初から仕様にするのはコストもかかる、例外として一旦処理したい、みたいなことは往々にしてありそうですし…などと考えていたのですが、「ああ、これも結局は dynamic なのか」と途中で思ったりしました。シンプルに作って対応しつつ、のちの変更に備える、ができていれば例外を定常にするときも（当然コストはかかるけど）そこまで恐れなくていいのか、と。

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

複数サービスがあるとどうしても逃げられない、サービスをまたいだ認証基盤的なやつをどう作るか、というお話。

いくつかの実装パターンが考えられる中、一般的に使われがちな OIDC だと自社サービスだけには過剰すぎる、外部サービスは…なぜなのかはあまり語られてなかったですが採用せず、 Redis に認証状態を保存するような形で認証基盤を構築している事例紹介でした。

OIDC というある種の安牌があるような分野ではありつつ、それだと考えることが多すぎて自社サービス内でのみ使うのには微妙…というところから、ある種「シンプルな」方法を選び取って実装されているのが良いなと感じました。 dynamic.

Keynote: Building and Deploying Interactive Rails Applications with Falcon

最後はキーノート、 Falcon で Rails を更に高速にする話。
実際に Shopify で数千台のサーバが不要になったというかなりインパクトの大きい例が出てきていてすごい。
Rails 8 以降であれば設定変更もほぼ不要でそのままサクッと置き換えが可能、 Job 周りについても対応してパフォーマンスも向上する、と、かなり良さそう。
ActionCable 周りだけちょっと怪しい（HTTP/2 の Websocket にブラウザが対応していない）のでそこは別途対応が必要そう…？

アプリケーションサーバの話かと思いきや、デプロイ回りや監視周りの話まで全部盛り込まれていてすごいとしか言いようがなかったです。だいたいなんでもある。最後のライブコーディングもインパクトがすごかったですね…

パフォーマンス面でのメリットはかなり大きそうなので、ちょっと様子見はしつつどこかで導入を検討してみたい気持ちになりました。

まとめ

以上、2日目の Kaigi on Rails 2025 まとめでした。

2日間の発表全体を通じて、根底に dynamic、継続的に作り、改善し、進化させ続けることに対して立ち向かった結果の話が多かったという印象を受けました。
ソフトウェア、サービスを作ってそれによって価値を提供するということが、どれだけ動的な、 dynamic な行いなのかを改めて知ることができた2日間だったと思います。濃密な2日間でした。

私事ではあるのですが、今年初めてプロポーザルを提出するということをしてみて見事落選してしまったので、来年こそはいい感じのネタを用意して登壇出来たらなぁ、と思っています。

最後に、このような素晴らしい会を開いていただいた運営、スタッフの方々、スピーカーの方々には感謝してもしきれません。本当にありがとうございました！次回も楽しみにしています！