Self-hosted runner で rspec 高速化

参考になった

レビュー投稿日の情報になります

STORES株式会社 / White-Green

メンバー / バックエンドエンジニア

最終更新日2025/10/24投稿日2025/10/24

アーキテクチャ

アーキテクチャの意図・工夫

ジョブを実行するEC2インスタンスをAutoScalingGroupで管理し、その必要台数をLambdaで計算し制御する設計。 GitHubからのWebhook(ジョブの実行要求など)を起点に、ランナーの稼働台数を性能別に制御するためこのような構成になっている。 EC2 Spot Instanceを利用することで更なるコストの低減が見込めるが、中断のデメリットが大きかったため現状はOn-Demand Instanceのみを利用している。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

CIで実行しているrspecに長時間かかっており、またコストも高額だった

どのような状態を目指していたか

CIの所要時間短縮またはコストの圧縮、可能であれば両方

比較検討したサービス

GitHub Actions Self-hosted runner(採用)
GitHub Actions larger runner
AWS CodeBuild

比較した軸

「コードベースと同じ場所でCI workflow定義を行う」という既存のGitHub Actionsで慣れている運用を大きく崩さないこと

選定理由

GitHub Actionsのworkflow定義をそのまま利用することができ、larger runnerよりもコストを抑えられる点

導入の成果

主に以下の要因によりCIの実行時間短縮に成功した

通常のGitHub-hosted runnerよりも高性能なマシンで動くrunnerをlarger runnerよりも低コストに用意できる
あらかじめ専用AMIにパッケージをインストールすることでworkflow内でのインストール作業を削減

導入に向けた社内への説明

上長・チームへの説明

それまで利用しているGitHub-hosted runnerから円滑に移行し、何かあればすぐにロールバックできるよう、できる限りGitHub-hosted runnerと同じ動作をするrunnerを構築した。運用開始後も環境差異に起因する問題が数回発生したが、GitHub-hosted runnerの挙動に合わせることで対処を行った。