2分台で1500examples完走！爆速CIを支える環境構築術 - Kaigi on Rails 2025

https://kaigionrails.org/2025/talks/falcon8823/#day1

CI/CD環境が高速であることは、開発物の信頼性を維持しながら高速に成果をユーザに届けることを可能にします。CI/CD環境が遅いと、失敗に気づくのも遅くなり修正サイクルはどんどん重くなっていきます。特に我々のプロダクトを提供しているライブイベント業界においては、イベント当日に万が一問題があれば、本番環境への即時修正対応が求められるため、CI/CDの速度は開発体験だけではなく、ビジネス価値にも直結しています。
本セッションでは、Railsアプリケーションのrspecを2分台で1500examples以上を完了させるために、並列実行による工夫を中心に、CI/CD実行環境の最適化をどのように試行錯誤したかを紹介します。

Transcript

1. 2025年9月26日 2 分 台 で 1 5 0 0 e x a m p l e s 完 走 ！ 爆 速 C I を 支 え る 環 境 構 築 術 株式会社TwoGate 取締役CTO 奥本 隼
2. 奥本 隼 (Hayato OKUMOTO) @falcon_8823 株式会社TwoGate 取締役CTO チーム組成から12年 / 創業10期目 長野高専出身 Rails歴14年 自己紹介
3. TwoGateの主要なソリューション ライブイベント向け OEM型モバイルオーダーアプリ オンラインくじ ファンクラブアプリ チケットサイト Shopify EC構築支援 その他の事業領域 ライブエンタメ領域に対して、 コンパウンド戦略でサービスを複数展開 しています。 150 150 9 200 実績数
4. Caravan - イベント物販に特化したアプリ
5. 技術スタック サーバサイド フロントエンド インフラ
6. ピークトラフィック CDN 50,000 RPS ALB / Rails 8,000 RPS 決済エンドポイント 660 RPS
7. https://aws.amazon.com/jp/blogs/startup/tech-interview-twogate-2025/
8. Rails × 爆速CI 本発表のテーマ
9. なぜCIを速くしたい？ 失敗の早期発見 不具合の原因特定と修正のサイクルを早く回せる リリースの早期化 安定したリリースを早期にできる 開発体験の向上 遅いとイライラするよね！
10. CIが高速＝ビジネスに直結 TwoGateのプロダクト＝ライブ会場で使われる 問題があれば即時対応、即時反映する必要がある そこに炎天下の中待っているお客さんたちが！！！
11. TwoGateのCI環境 GitLab CE + GitLab Runner DockerコンテナベースのCI環境 EC2にてAuto Scaling + Spot Instanceで運用 iOSアプリビルド用にMac miniをオンプレでも管理
12. 題材 TRIPLE - OEM型チケット販売プラットフォーム Rails(Ruby 3.3/Rails 7.1/sorbet)+PostgreSQL+Redis Code: 19,035 Test: 58,182 Code to Test Ratio: 1:3.1 C0 Cov: 80.4%
13. bundle exec rspec 1,981examples APIベースのアプリケーションなので比較的軽量なテスト 単体テスト / APIテスト 実行時間：29分38秒 EC2 c7i.2xlarge (8vCPU / 16GB)
14. 今日のテーマ 話さないこと specそのものの改善（既にたくさんの知見が既発表） 話すこと 並列実行による高速化 CI環境ののチューニングの話し
15. RSpecの実行を速くするためには 直列実行でCPUを使い切れていない 2コアなのに1コアしか使っていない 並列実行すればよい => どうする？
16. parallel_tests gem Rubyのテストフレームワークの並列実行をサポートする RSpec / Minitest / Turnip / Cucumberなどに対応 マルチプロセスでの並列実行をサポート そのまま実行すると…？ DatabaseCleanerも同時実行されて、テストできない…
17. 論理DBを分ける parallel_testの機能に存在 TEST_ENV_NUMBER環境変数にプロセスごとの番号が入る
18. 均等に並列化されない Process 1 spec単位での実行時間にはバラツキがある 均等に並列実行しないと意味が無い Process 2 Process 3 Process 4 20分 10分 5分 15分 Process 1 Process 2 Process 3 Process 4 13分 13分 13分 13分 現実 理想 ？？？
19. Knapsack Pro spec単位の実行時間の履歴を記録して最適な分割をしてくれ る gemを入れてセットアップする
20. rake parallel:spec 条件 8コアCPUで8並列で実行 (1/8になる？？） 実行環境 EC2 c7i.2xlarge (8vCPU/16GB) 実行時間 23分20秒 (元:29分38秒) ？？？
21. I/Oに気をつけろ EC2のEBS(gp3)のデフォルトは3,000IOPS 8並列ではDB書き込みでIOがサチる
22. I/Oスペックを上げるには EBSのIOPSを上げる 課金する？ NVMe SSDを使う (EC2ではストレージ最適タイプ) 悪くない。マウントポイントの設定などが要。 1-3万IOPS ？？？ 速い！
23. tmpfsを使う メモリ上に作成できるファイルシステム 再起動で揮発する / RAMより大きい領域は確保できない Dockerのオプションからも簡単に利用可能 --tmpfs=/var/lib/postgresql GitLab Runnerではこの2行の設定を書くだけ
24. rake parallel:spec w/tmpfs 条件 8コアCPU で実行 + ストレージをtmpfsに 実行環境 EC2 c7i.2xlarge (8vCPU/16GB) 実行時間 5分 (元:29分38秒) 6倍スピードアップ
25. もっと速くしよう さらなるスピードに挑戦？
26. もっと速くしよう https://world.hey.com/dhh/we-have-left-the-cloud-251760fb
27. 物理マシンにする 👊👊👊 CPU: Ryzen 9 / RAM: 64GB / SSD: NVMe 4.5GHz / 32コア 実行時間：32並列 / 1分59秒！！ 約30分のCIが2分で完了（15倍）
28. コストメリット 32core / 64GBのマシンを手に入れるには EC2 c7i.8xlarge: 1,294.27USD/month = 19.5万/月 オンデマンドインスタンス 物理: 24万円 = 減価償却4年: 5,000円/月 　仮にspotインスタンスでも10倍ぐらいの価格差
29. まとめ RSpecを並列に実行すること 均等に並列実行すること（大事） tmpfsを使うこと 物理マシンを使うこと（一番大事） CIサーバは可用性含めて着手しやすいはず 約30分のCIが2分で完了（15倍） コストが1/10 〜 1/40に