GitHub Actions のコストが思ったより高かったので、短期間でできる限り削減した話

こんにちは、株式会社ゼストでエンジニアをしている菊池です。

12月も中旬。今年も残すところあと半月になりましたね。

今回はゼストで行った GitHub Actions の請求金額を 38% カットしたプロセスを紹介します。

GitHub Actions のコストの方程式

まず前提として、GitHub Actions のコストは次の式で決まります。

総コスト = 実行時間 × ランナー単価 × 実行回数

そこで今回は、この3軸をそれぞれ見直していきました。

最初に、どのワークフローが一番時間を使っているかの可視化と実行時間の削減をねらいました。
調査の結果、バックエンド API のテストワークフローが最も時間を消費していました。

処理内容は次のとおりです。

これらに対しての改善案として、biome への移行、tsgo の活用、TypeScript ビルド戦略の見直し、テストの並列度やキャッシュ戦略の最適化など、いくつか出ましたが、 影響範囲が大きく、短期間で安全に導入するのは難易度が高そうだ と判断し、今回は深追いしませんでした。

実行時間を大きく削るよりも、ほかの軸を最適化した方が即効性が高いと判断したため

次に見直したのが ランナー単価 です。

ランナーの確認をしたところ、一部ワークフローが、高スペックのカスタムランナー で動いていることを発見しました。
この高スペックのカスタムランナーに変更した当時は在籍していなかったため、経緯を確認したところ、過去に “安定性を優先して” 導入していたとのことでした。

コスト内訳を調べたところ、このカスタムランナーがコストの大半を占めていました。本当にこのランナーじゃないと動かないのか？と再度検証したところ、当時問題だった

といった課題は、リファクタリング等の効果もあってか現在のコードベースでは再現せず、標準ランナーでも十分安定する ことが確認できました。

そこで、ランナーを順次 ubuntu-latest に置き換えました。

[カスタムランナー]
  単価：★★★★★

[ubuntu-latest]
  単価：★☆☆☆☆

これによって、カスタムランナーに依存していた部分を見直すことができ、約35% とコスト削減につながりました。

なお、今回は対象外としましたが、GitHub公式Runner以外を使う案として、「Blacksmith」の名前を聞くことが増えてきました。
単価および実行時間削減に効果があるとのことで、興味のある方は調べてみてほしいと思います。

最後に見直したのが 無駄に実行される CI の削減 です。

10月の実行回数を調べると、最も多かったのは Renovate の PR でした。
ライブラリ更新が入るたびに force-push → CI 全実行…という状態でしたが、
ゼストではライブラリ更新を一定サイクルでまとめて行っているため、
リアルタイムでの CI 実行は必須ではありません。

そこで Renovate PR で不必要な CI が走らないよう設定を変更しました。
これにより、無駄な CI 実行を大幅に抑制できました。

実行時間自体はほぼ変わっていませんが、

の2つが効き、1ヶ月で約38%の削減 に成功しました。

今回の取り組みでわかったことは、

ということでした。

CI コストが気になってきたら、即効性と効果の観点で、まずは ランナー単価 と 無駄実行の抑制 から見直すのがおすすめです。