Self-hosted runner で rspec 高速化
STORES株式会社 / White-Green
メンバー / バックエンドエンジニア
アーキテクチャ

アーキテクチャの意図・工夫
ジョブを実行する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の挙動に合わせることで対処を行った。
活用方法
よく使う機能
Self-hosted runner上でのworkflow実行
ツールの良い点
- 広く使われているため公開されている周辺ツールや広く共有されている知見が多い
- Self-hosted runnerを利用すればそれらを活かしつつコストを抑えたり実行環境をカスタムできる
ツールの課題点
- Self-hosted runnerの実行環境を構築、運用する手間がかかる
STORES株式会社 / White-Green
メンバー / バックエンドエンジニア
よく見られているレビュー
STORES株式会社 / White-Green
メンバー / バックエンドエンジニア
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法



