philips-labs/terraform-aws-github-runnerによるGitHub Actions セルフホストランナーの大規模運用

philips-labs/terraform-aws-github-runner による GitHub Actions セルフホストランナーの⼤規模運⽤ CI/CD Test Night #6 サイボウズ株式会社 開発本部 ⽣産性向上チーム 宮⽥ 淳平（@miyajan）

⾃⼰紹介 ▌宮⽥ 淳平（@miyajan） ▌サイボウズ株式会社 n 2009年 新卒⼊社 n 2015年 ⽣産性向上チーム⽴ち上げ n サイボウズの開発者の⽣産性を上げる 「⽣産性向上チーム」とは︕︖ ▌『GitHub Actions 実践⼊⾨』執筆など ▌最近 ICL ⼿術を受けました👁

• https://note.com/cybozu_dev/n/n1c1b44bf72f6

本⽇の話 ▌サイボウズ⽣産性向上チームのセルフホストランナー運⽤事例 ▌過去にブログ記事にした話＋最近の話 n philips-labs/terraform-aws-github-runner でオートスケール するセルフホストランナーの構築・運⽤ - Cybozu Inside Out | サ イボウズエンジニアのブログ

• https://blog.cybozu.io/entry/2022/12/01/102842

セルフホストランナーが必要な背景

サイボウズの開発基盤 ▌社内ネットワークからしかアクセスできないシステムへの依存がある ▌GitHub Enterprise Cloud (GHEC) だけでなく GitHub Enterprise Server (GHES) も利⽤ n GHES で Actions を使うにはセルフホストランナーが必須

philips-labs/terraform-aws-github-runner

philips-labs/terraform-aws-github-runner ▌Philips 社が OSS で公開している Terraform モジュール n この発表では以降『philips モジュール』と呼びます ▌AWS 上にオートスケールするセルフホストランナーを構築できる n GitHub App を別途⼿動で作成する必要あり ▌GitHub 公式ドキュメントの推奨オートスケールソリューションに⼊ってる n Autoscaling with self-hosted runners - GitHub Docs

• https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners

仕組み（いろいろ省略版） ランナー⽤ インスタンス起動 Webhook workflow_job GitHub App API Gateway Lambda EC2 ランナー登録 GitHub

引⽤元: https://github.com/philips-labs/terraform-aws-github-runner/blob/b1019faff11a736a1fc0dbb2044571eff9ae1149/docs/component-overview.svg

• https://github.com/philips-labs/terraform-aws-github-runner/blob/b1019faff11a736a1fc0dbb2044571eff9ae1149/docs/component-overview.svg

選定理由 ▌すでに社内ネットワークと AWS を接続する仕組みがあった n Transit Gateway で AWS を社内ネットワークの延⻑として使う Cybozu Inside Out | サイボウズエンジニアのブログ ▌GHEC/GHES の両⽅に対応 ▌活発に開発されている ▌コンテナ系ソリューションだと dind がハマりそう n 2020年ぐらい当時の気持ちで、現在は違う認識です

• https://blog.cybozu.io/entry/2022/12/14/104414

サイボウズでの運⽤

複数 org 運⽤ ▌サイボウズでは GitHub の org は複数存在する ▌philips モジュール単体だと複数の GitHub org をサポートしていない n 議論はあります n Multi Org self-hosted runners · philips-labs/terraformaws-github-runner · Discussion #1916 ▌org の数だけモジュールを適⽤して AWS リソースを作成 n 楽にするため philips モジュールをラップしたモジュールを作成 n GitHub App も org の数だけ作成

• https://github.com/philips-labs/terraform-aws-github-runner/discussions/1916

staging / production ▌設定変更や philips モジュールのバージョンアップをいきなり適⽤するの は怖い n 問題があると多くのチームのビルドが⽌まる危険性 ▌⽣産性向上チームの org を staging 環境として利⽤

ephemeral とプール ▌ephemeral（ランナー使い捨て）設定を有効化 ▌インスタンスの起動待ち時間が発⽣する n 2,3 分ぐらい ▌緩和するため常時⼀定台数ランナーをプールする設定を有効化 n Webhook がうまく動かなかったケースも救える n プールを維持する速度よりビルドの頻度が⾼いと待ち時間が発⽣

AMI ▌philips モジュールはデフォルトだと Amazon Linux 2 の AMI を使う ▌しかし、GitHub が提供するランナーは Ubuntu が使われることが多い n なのでそちらに慣れてる⼈のほうが多い ▌社内のワークフローでよく使われるソフトウェア⼀式は事前にインストールさ れてると嬉しい ▌Ubuntu の AMI を⾃作

AMI 作成 ▌公式の actions/runner-images を検討したけど断念 n 社内で使わないソフトウェアのインストールにビルド時間やディスク容量 を取られすぎる ▌Packer で必要最低限のソフトウェアがインストールされた AMI を作成 ▌社内で要望があればソフトウェアを追加

• https://github.com/actions/runner-images

AMI の⾃動更新 ▌AMI は週⼀回⾃動更新 n インストールされているソフトウェアのバージョンを最新に保つため ▌前は AMI を更新するたびに terraform apply が必要だったけど、今 は SSM パラメータを更新するだけでよい設定にしている n CI に強い権限を渡さなくて済む ▌インストールされたソフトウェアとバージョン⼀覧をドキュメントに⾃動⽣成 n 利⽤者がビルド環境を確認しやすいように

現在の利⽤規模 ▌30 org で利⽤中 ▌170 台以上のインスタンスを常時プール ▌ピーク時 600 台以上のインスタンスが起動 ▌利⽤が⼤規模化するにつれて新たに発⽣する問題や要望も

ランナーのスケールアップが遅い問題

ジョブ実⾏が⻑時間待たされるという問い合わせ ▌⻑いときは⼀時間以上待たされる ▌ジョブの実⾏頻度はたしかに⾼い ▌しかし、頻度に関係なく待たされても 2,3 分になるはずでは…︖🤔 n Webhook でインスタンスを起動しているので

Lambda の同時実⾏制限 ▌インスタンスを起動する Lambda にデフォルトで同時実⾏制限があった n 同時実⾏数 1 ▌Lambda の実⾏速度よりジョブの実⾏頻度が⾼いと詰まる ▌philips モジュールの設定に Lambda の同時実⾏数の設定があったの で、無制限に同時実⾏するようにして解決🕵

インスタンスの種類を増やしてほしい要望

インスタンスのリソース ▌最初は CPU 2 コア、メモリ 8GB のインスタンスのみ提供 ▌↓のように書くとこのセルフホストランナーが使える n runs-on: [self-hosted, internal-network] ▌もっと強いランナーもほしい要望 n ビルド時間短縮などのため

philips モジュールでの実現⽅法 ▌通常の philips モジュールだとランナーの設定は⼀種類のみ ▌multi-runner モジュールが別途⽤意されている n 複数のランナーが設定可能 n Webhook は runs-on に指定されたラベルを⾒て起動するランナー を決定する

• https://github.com/philips-labs/terraform-aws-github-runner/blob/main/modules/multi-runner/README.md

ラベル設計 ▌強いインスタンスに設定するラベルをどうするか ▌初期案 n runs-on: [self-hosted, internal-network, large] ▌しかし、これだとダメ🙅 n runs-on: [self-hosted, internal-network] でも強いインスタン スが使われてしまう ▌runs-on: [self-hosted, internal-network-large] にした🙆

現在のインスタンスの種類 ▌CPU 2 コア、メモリ 8GB n runs-on: [self-hosted, internal-network] ▌CPU 4 コア、メモリ 16GB n runs-on: [self-hosted, internal-network-large] ▌CPU 8 コア、メモリ 32GB n runs-on: [self-hosted, internal-network-xlarge] ▌今後、特定の環境がほしい要望に対応しやすくなった

今後改善したいこと

Terraform リソース多すぎ問題 ▌複数 org 運⽤とマルチランナー対応の結果、リソースがすごい多い n 6,000 以上 ▌terraform plan に時間がかかる n 差分が多すぎて厳しいときも ▌AWS API の Rate Limit エラーに引っかかることも ▌複数 org 運⽤を共通リソースでできるようにしたい ▌philips モジュールに修正が必要そう n リポジトリ上でも議論はある

• https://github.com/philips-labs/terraform-aws-github-runner/discussions/1916

メトリクス ▌インスタンス数や起動時間などすでに取得してるメトリクスはある ▌どのジョブの実⾏時間が多いか、キュー待ち時間が多いか、とかも⾒たい

インスタンス起動時間 ▌現状 2,3 分ぐらい ▌⼤きな不満が出ているわけではないけど、早ければ早いほどよい ▌改善の余地はある n userdata でランナーのダウンロードなどしているのを AMI に含めると か

まとめ

philips モジュール ▌作り込まずに⼿軽にセルフホストランナーを構築可能 n AWS や Terraform がある程度わかれば⼗分 n まじめに運⽤するとモジュールの深い理解や⼯夫は必要 ▌それなりの規模でそれなりに回る

今後の⽅向性 ▌セルフホストランナーの改善は継続 ▌さておきセルフホストランナーの必要性は減らしていきたい n 社内ネットワークに依存しない開発への移⾏ n GHES から GHEC へ移⾏

Q&A