PumaからFalconに移行したRailsアプリケーションでの実践

https://kaigionrails.org/2026/talks/falcon8823/

Transcript

1. KAIGI ON RAILS 2026 PumaからFalconに移行した Railsアプリケーションでの実践 奥本 隼 / 株式会社TwoGate Kaigi on Rails 2026 · 2026.10.16
2. ABOUT ME 奥本 隼（おくもと はやと）/ @falcon_8823 株式会社TwoGate 取締役CTO ライブエンタメを支えるサービスの 設計・開発・インフラに携わっています。 Kaigi on Railsで話してきたこと 2024：ハイトラフィックとアーキテクチャ 2025：RailsのCI高速化 2026：Falconへの移行と本番運用 近況：子どもが産まれました 隼 ＝ はやぶさ ＝ falcon。falconが、Falconを紹介します。 KAIGI ON RAILS 2026 2
3. TODAY'S TALK 認証アダプターのFalcon移行で、変えたこと・分かったこと 01 なぜ移行したか 対象サービスと負荷 PumaとFalconの仕組み 02 › どう移行したか コードの変更と段階導入 本番で見つかった不具合 03 › 何が変わったか 性能と運用の結果 改善しなかった別の事例 自分のRailsアプリで検討するときの、判断材料に。 KAIGI ON RAILS 2026 3
4. 01 / 05 · SERVICE & WORKLOAD 移行対象サービスの概要と 負荷の特徴 KAIGI ON RAILS 2026 4
5. CARAVAN TICKET アーティストの世界観を表現できるチケットプラットフォーム 申込・販売 先着販売 / 抽選受付 決済 購入・支払い 電子チケット 表示・分配・入場 アーティストの世界観・ブランドを、チケットサイトにも。 01 · サービスと負荷 5
6. MULTI-TENANT 世界観はサイトごとに。チケットの仕組みは共通に。 アーティストAのサイト Aの世界観・ブランド Aの会員ID アーティストBのサイト Bの世界観・ブランド Bの会員ID アーティストCのサイト Cの世界観・ブランド Cの会員ID それぞれのサイトを、一つの基盤上の「テナント」として提供。 01 · サービスと負荷 6
7. IDENTITY BRIDGE ID基盤ごとの違いと待ち時間を、認証アダプターで受け止める Caravan Ticket テナントA OIDC テナントB OIDC テナントC OIDC ・ ・ は接続先の例 A B C 基盤ごとに別のRailsアプリ 認証アダプター A 接続先のID基盤 アーティストAのID基盤 認証アダプター B 今回のFalcon移行対象 認証アダプター C 事務所BのID基盤 ID 接続先の方式・情報APIに対応 独自認証・独自API 別の認証方式・情報API アーティストCのID基盤 接続先の方式・情報APIに対応 必要情報は固有API 認証方式・情報API・応答時間の違いを、各アダプターで扱う 認証アダプターを分離し、遅い外部APIの影響が本体に広がるのを抑える。 01 · サービスと負荷 7
8. TRAFFIC SPIKE 事前に増強しても、遅いAPI待ちでリクエストが詰まる 販売開始・当落発表に集中 ログイン要求が一斉に到着 コンテナを事前増強しても リクエストの滞留が頻発していた 対象テナントでは、 外部APIの応答が遅い ログイン状態確認 → 後続APIを3回 後続3回は従来から並行実行 それでも、数百ms単位の応答待ち 仮説：このAPI待ちの集中こそ、Falconで効率よく扱えるのではないか。 01 · サービスと負荷 8
9. 02 / 05 · CONCURRENCY & FALCON 並行処理とFalcon I/O待ちの間に、どう処理を進めるのか。 KAIGI ON RAILS 2026 9
10. OPTIONS FOR TRAFFIC SPIKES 単位時間あたりに処理できるリクエスト数を増やすには 方法・Rubyの仕組み 効く場面・特徴 プロセスを増やす CPU処理を複数コアへ分散 Process.fork Rubyのオブジェクトは別々 スレッドを増やす I/O待ちを重ねる Thread 同じメモリを共有できる 非同期I/O I/O待ちの間に別の処理 Fiber ＋ Scheduler Falcon：今回の対象 少数のスレッドで多くの待ち 主なコスト・制約 プロセスごとにメモリが必要 生成・起動にもコスト スタック・共有データの同期 CRubyのRuby実行はGVLで制約 対応するI/O処理が必要 CPU処理自体は並列化しない Falconの非同期I/Oで、外部API待ちのリクエストを多く扱いたい。 02 · 並行処理とFalcon 10
11. PROCESS → THREAD → FIBER 主要なRackサーバで、リクエストの扱いはどう違うか Unicorn （プロセス） リクエストA Worker 2（プロセス） Thread → リクエストB Worker 1 Thread → で一度に1件 1 worker プロセス境界 02 · 並行処理とFalcon Puma （プロセス） Thread 1 → リクエストA Worker Thread 2 → worker スレッド リクエストB 内に複数thread Falcon （プロセス） Worker Thread Fiber A Fiber B リクエストA リクエストB thread 内に複数Fiber Fiber 11
12. PUMA · TWO REQUEST THREADS Pumaの動きの例 リクエスト到着 Thread 1 Thread 2 Ruby 0 2 A B A 処理 4 C 6 外部API待ち D 8 E 10 12 14 時間 →（単位は模式的） 16 18 22 ： 待ち A C C：API待ち C E E：API待ち B B：API待ち B D D：API待ち D C：空き枠待ち D：空き枠待ち E：空き枠待ち A API 待ち行列 C 待ち行列 D 待ち行列 E Rubyの実行 A B A C B D C E D I/O待ちは重ねられる。RubyのCPU処理は、GVLにより一度に1スレッド。 スレッド上限は、メモリ・応答時間・接続数を負荷試験で確かめて決める。 02 · 並行処理とFalcon 20 24 E E 12
13. FALCON · REQUEST FIBERS Falconの動きの例 リクエスト到着 Fiber A Fiber B Fiber C Fiber D Fiber E Ruby 0 2 A B A 処理 4 C 6 外部API待ち D 8 E 10 12 14 ： 待ち A B B：API待ち B C C：API待ち C D D：API待ち D E E：API待ち 時間 →（単位は模式的） 16 18 20 22 24 A API E 同じスレッド A B C D A E B C D E Fiberで待ちを重ねる。ただし、受付数・上流への同時接続数は別途制御する。 02 · 並行処理とFalcon 13
14. 03 / 05 · MIGRATION Falconに移行するための変更 コードの変更と、本番で見つかった不具合。 KAIGI ON RAILS 2026 14
15. HTTP CLIENT CHANGE 3本の同時実行を、FiberのTaskへ移した 変更前：Faraday＋Typhoeus 変更後：Async::HTTP＋Barrier connection.in_parallel do member = connection.post(path_a, params) email = connection.post(path_b, params) contacts = connection.post(path_c, params) end barrier = Async::Barrier.new begin member = barrier.async { call(path_a) } email = barrier.async { call(path_b) } contacts = barrier.async { call(path_c) } barrier.wait ensure barrier.stop end Fiberでも、3回を順番に書けば直列。3つのTaskを起動して完了を待つ。 03 · Falconに移行するための変更 15
16. MIGRATION TROUBLE 移行時のトラブル 基本的には、トラブルはなかった HTTPクライアント変更に伴う挙動の違いで、不具合が1件 アプリ側のエラー判定を修正し、既存の挙動に合わせた それ以外にFalcon固有の予期しない挙動は経験していない 全量切り替え後、数か月運用。安心して使えているが、移行リスクはゼロではない。 03 · Falconに移行するための変更 16
17. 04 / 05 · PRODUCTION RESULTS 性能評価 性能はどう変わり、その後どう動いているか。 KAIGI ON RAILS 2026 17
18. REQUESTS PER CPU TIME 消費CPU 1コア相当あたりのRPSで比較 消費CPU 1コア相当あたりのRPS Puma 構成 Falcon 21.9 RPS 約3.9倍 構成 84.6 RPS 0 20 40 60 80 複数タスクの実測RPSを、合計CPU使用量（コア相当）で割って比較。 04 · 性能評価 18
19. 05 / 05 · WORKLOAD MATTERS 効果が得られないワークロード 別のワークロードで、同じ効果は得られるか。 KAIGI ON RAILS 2026 19
20. ANOTHER WORKLOAD 別のRailsアプリでも、同じ効果は得られるか？ 検索リクエスト → Rails API → DynamoDB GetItem × 2 DynamoDBからデータを取得して返す、シンプルな検索API。 低負荷時のAPI応答は約11ms。短い処理でPumaとFalconを比較。 05 · 効果が得られないワークロード 20
21. NO OBSERVED GAIN この検索APIでは、CPU効率の改善は見られなかった 消費CPU 1コア相当あたりのRPS 125 RPS Puma 119 RPS Falcon 0 50 100 既存レポートのCPU時間／リクエストから換算。各40 vCPUの負荷試験。 05 · 効果が得られないワークロード 21
22. WORKLOAD HYPOTHESIS 仮説：I/O待ちが短く、待ちを重ねる効果が小さかった 認証アダプター 外部APIの応答は100ms単位 待っているリクエストが滞留 今回の検索API GetItem平均：0.93〜0.97ms 既存レポートでは、短いデータ参照 待ち時間が短く、Rails・署名・JSON処理などのCPU処理が、性能を左右していたのでは。 05 · 効果が得られないワークロード 22
23. FUTURE WORK 次は、Ruby master × PuMaNyも試したい RubyのM:Nスレッドスケジューラを使う実験的なRackサーバ。 05 · 効果が得られないワークロード 23
24. SUMMARY まとめ 課題：遅い外部API待ちで詰まる認証アダプターをFalconへ 移行：起動・状態管理の設定と、HTTPクライアントを変更 結果：CPU効率が改善。カナリアを経て数か月運用 適性：短いデータ参照では改善せず。待ち時間とCPU処理の比重が鍵 falconでした。ありがとうございました。 05 · 効果が得られないワークロード 24