セルフホストランナーのAWS費用を30%削減するまでの道のり

セルフホストランナーのAWS費用を30% 削減するまでの道のり GitHub Actions Meetup Tokyo#4サイボウズ株式会社 開発本部 生産性向上チーム 加瀬 健太（@Kesin11）

自己紹介 ▌加瀬 健太（@Kesin11） ▌経歴 ◼ ~2023/06 株式会社DeNA SWET第二グループ @Kesin11 ◼ 2023/07 サイボウズ株式会社 生産性向上チーム @Kesin11 ▌業務 ◼ Github Actionsセルフホストランナーの運用など ▌日課はgithub.blog/changelogを見ること @kesin11.bsky.soci al

Productivity Weekly ▌「1週間の間に発見された開発者の 生産性向上に関するネタを共有する 会」を社内で開催した内容をzennで 公開 ▌100回を突破して現在160回！ ▌CI/CD関連のネタが多いのでぜひ

• https://zenn.dev/p/cybozu_ept

Software Design 7月号の特集に寄稿しました！！

Cybozuの成熟したセルフホストランナー基盤の 最近の運用とコスト削減

目次 ▌Cybozuのセルフホストランナーの近況 ▌AWS費用の移り変わり ▌Cybozuのセルフホストランナー基盤のアーキテクチャ紹介 ▌無駄なプールサイズ削減 ▌スポットインスタンスの費用削減 ▌今後：NAT Gatewayの料金について ▌まとめ

Cybozuのセルフホストランナーの近況 ▌1年前の時点で既に機能は十分で安定運用 https://www.docswell.com/s/miyajan/ZW1XJX-large-scale-github-actions-self-hosted-runner-by-philips-terraform-module https://www.docswell.com/s/miyajan/ZW1XJX-large-scale-github-actions-self-hosted-runner-by-philips-terraform-module

• https://www.docswell.com/s/miyajan/ZW1XJX-large-scale-github-actions-self-hosted-runner-by-philips-terraform-module

Cybozuのセルフホストランナーの近況 ▌Terraformの運用が苦しい ◼ tfstateが巨大すぎる問題 ◼ Terragrunt, tfcmt導入で運用の手間はかなり改善 ▌AWSのAPIリミットが苦しい ◼ 上限緩和を申請できるものは申請して改善した ◼ SSM ParameterStoreがたまにAPIリミットに当たるが対策が難しいので後回し ◼ philips-labs/terraform-aws-github-runner が実質的にKVストアとして使っている ▌利用チームの増加 ◼ AWSの費用増加がさすがに無視できなくなってきた

AWS費用の移り変わり

AWS費用の移り変わり（削減前） ▌利用チームの増加や主力プロダクト のE2Eテストなどで右肩上がり ▌内訳はEC2とEC2その他（ほぼ NAT Gateway）が2/3を占める

Cybozuのセルフホストランナー基盤のアーキテクチャ

Cybozuのセルフホストランナー基盤のアーキテクチャ ▌OSSを利用 philips-labs/terraform-aws-github-runner

Cybozuのセルフホストランナー基盤のアーキテクチャ ▌OSSを利用 philips-labs/terraform-aws-github-runner ▌ジョブごとに飛ぶwebhookでLambdaからEC2を起動する ▌あらかじめEC2を起動しておくランナープール機能もあり（後述） ▌Repo or Orgランナーしか作れない（ Enterpriseランナー） ◼ Orgごとにランナーが分離されてしまうのでリソース集約効率が悪い

ランナープール = 待機状態のランナーを用意しておく方式 ランナープールなしの構成 workflow_job webhook ランナープールありの構成 時系列 EC2起動 ジョブ開始 GitHub Actions Lambda workflow_job webhook ジョブ開始 GitHub Actions Lambda EC2（ランナー） cronで実行 EventBridge スケジューラー EC2（ランナー） EC2起動

Cybozuでのランナープール ▌Orgごとに最低1台、最大は現在のところ60台 ▌高スペックランナーのプールはE2Eを頻繁に動かすOrgのみ ▌固定費的な部分なので地道に無駄を削った ◼ 非アクティブなOrgのプール数を削減 ◼ 高スペックランナーを夜間・休日にスケールインしていなかったミス修正 ◼ Terraform定義の凡ミス ◼ 高スペックランナーをプールしているOrgは僅かだったので見逃していた

スポットインスタンスの費用削減

スポットインスタンス復習 ▌圧倒的に安い（最大90%とAWS公式は言ってる） ▌起動中に中断される可能性がある ▌スポットプールに複数のインスタンスタイプを混ぜることが可能 （m5.large, m6i.largeなど） ▌基本的にスポット価格が安く、かつ在庫が余っているインスタンスタイプが 起動される ◼ AWS推奨のprice-capacity-optimized戦略の場合

Cybozuのランナーでのスポットインスタンスの利用 ▌初期から全てのランナーがスポットインスタンス ◼ スポット中断=ジョブの謎のfail は許容してもらっている ▌中断対策としてインスタンスタイプを増やしていた（2023/07） ◼ 初期はm5, m6iのみ ◼ m5d, m5n, m6id, m6inを追加 ◼ n: ネットワークが強化されたバリエーション ◼ d: ローカルSSD付き

スポットインスタンスの種類と価格の変動 ▌AWSのスポットリクエストから確認可能

スポットインスタンスの種類と価格の変動（m5系バリエーション） ▌m5に対してm5n, m5d, m5dnなどは大体順当に 高い ▌nやdの付加価値は セルフホストランナーとして はメリットがないので割高

EC2の費用について考えていたある日 ▌社内の別チームがm7iのスポットインスタンスを利用していることを知る ▌最新のm7は高そうだが、m5nやm5dと入れ替えることでスポット中断 率を維持できるならば高スペックな分お得なのでは？ ▌ついでに前から気になっていたAMD系のインスタンスも調べてみるか

スポットインスタンスの種類と価格の変動（世代別） ▌スペックと価格が比例して いないことがある ▌オンデマンド料金は m5 = m6i < m7i-flex < m7 ▌8/2時点では m7i-flexが最安値 m5が最高値

スポットインスタンスの種類と価格の変動（世代別+AMD系） ▌さらにAMD系のm5a, m6aを追加すると・・・ ▌m6a安すぎでは （褒め言葉）

スポットプールの調整 ▌スポットプールに最新世代のm7系を追加 ◼ m7i, m7aを追加 ◼ インスタンスガチャのSSR ◼ m7i-flexは調べても性能特徴がよく分からなかったのでスキップ ◼ m5a, m6a, m7aのAMD系x86 CPUを追加 ◼ Intel系と同じx86なので互換性はあるはずだが心配はしていた ◼ AMD系由来の問題は今のところ社内から聞いていないので結果オーライ

スポットプールの調整 ▌現在のスポットプールのリスト→ ▌large, xlarge, 2xlargeの ３種類のスポットプールを用意 ◼ =3種類のスペックのセルフホストランナーを提供

スポットインスタンスの費用削減 ▌スポットプールに追加してみた結果・・・EC2費用が激減！

スポットインスタンスの費用削減 ▌インスタンスの内訳を見るとほぼm6a 切り替わっている ▌AWS内で余ってる説・・・？

スポット中断も改善 ▌変更後に中断回数が激減 ▌以前からジョブが謎に中断さ れる話は聞いていたが、予想 以上に中断されてた ▌ついでに改善されて社内の ユーザー体験も向上

最終的な費用削減の効果測定 ▌対策ごとに削減効果が出ている ▌スポットの調整が圧倒的成果

最終的な費用削減の効果測定 ▌EC2費用が3月->4月で30%削減 ▌11月水準まで戻り、横ばいを維持

最終的な費用削減の効果測定 ▌3->4月は全体でも約27%削減 ◼ Taxは全体に連動するので減るの は分かる ◼ EC2その他（ほぼNAT GW） はスポットインスタンスの改善と関 連しないはずなので理由不明 ◼ 2月3月にプロダクト側でもE2Eテ ストに改善が入った影響かも？

今後

今後：NAT GWの料金を削減したい ▌ EC2その他（NAT GWのネットワークの費用）は高止まりしたまま ▌ 3つの対策を予定 ◼ VPCフローログの分析 ◼ ◼ どこへの通信が多いのかを計測可能にする AthenaからS3にクエリする際のパーティション設定とBIツールの選定で苦戦中 ◼ Dockerのミラーレジストリ構築とpull-throughキャッシュ ◼ ◼ 先行調査でDocker Hubへの通信が多いことが判明している pullしたイメージを自動キャッシュするレジストリサーバーをVPC内に構築し、NAT GWの通信を減らす予定 ◼ IPv6 + Egress-Only Internet Gateway ◼ ◼ ◼ IPv6であればNAT GWを通らずに外向きの通信が可能らしい Docker Hub以外への通信も減らせるのではと期待している 参考：AWS Summit Japan 2024 “IPv6 on AWS ～Public IPv4 アドレス削減に向けてできるこ とできないこと～（AWS-20）”

• https://pages.awscloud.com/rs/112-TZM-766/images/AWS-20_Network_AWS_Summit_JP_2024.pdf

まとめ ▌Cybozuのセルフホストランナーの近況紹介 ▌最近はAWS費用削減に取り込み中 ◼ 無駄にプールしているOrganizationのランナー数を削減 ◼ スポットプールにm7世代、AMD系CPUを追加 ▌主にスポットプール調整の効果でEC2費用が30%削減 ▌今後はNAT GW周りの費用改善を予定