エンジニアの皆さん、こんにちは。GitHub Actionsの実行時間が「また増えた……」と、ダッシュボードのグラフを見て溜息をついたことはありませんか？
CI/CDは開発者の心臓部です。ここが遅いと、開発のフィードバックループが死にます。今日は、世界中の高負荷プロジェクトを渡り歩いてきた私が、「GitHub Actionsの実行時間を半分にし、コストを劇的に最適化する」ための禁断の奥義を伝授します。
これは単なるマニュアルの焼き直しではありません。現場で何度も血を流して学んだ「生存戦略」です。
—
1. なぜ「キャッシュ戦略」が勝敗を分けるのか
多くの初心者が陥る罠は、「毎回ゼロから環境を構築する」ことです。`npm install` や `pip install` を毎度実行するのは、毎朝通勤のために新しい靴を買っているようなもの。非効率極まりない。
`actions/cache` の真髄
単にキャッシュするだけでは不十分です。「何を」「どう」キャッシュするかが肝です。
- name: Cache dependencies
uses: actions/cache@v3
with:
path: ~/.npm # キャッシュするディレクトリ
# keyが一致すれば復元、しなければ新規作成。
# package-lock.jsonが更新されたらキャッシュを破棄する設計です。
key: ${{ runner.os }}-node-${{ hashFiles(‘/package-lock.json’) }}
restore-keys: |
${{ runner.os }}-node-
極限のヒント:
- 圧縮レベルを意識せよ: 巨大な `node_modules` は圧縮に時間がかかります。頻繁に更新される依存関係と、静的なライブラリを分けてキャッシュする戦略が有効です。
- パスの正規化: キャッシュキーのハッシュ値生成時に、OSやランナーのバージョンを含めることで、環境不整合による「動かない！」という悲劇を未然に防ぎます。
—
2. セルフホストランナーという「最終兵器」
GitHub提供のランナーは手軽ですが、大規模プロジェクトではコストと性能の限界が来ます。そこで登場するのがセルフホストランナーです。
導入の選定基準
「自前でサーバーを立てる」のは手間ですが、以下の条件に当てはまるなら今すぐ導入すべきです。
1. ビルド時間が毎回15分を超える: GitHubの課金上限を超え、かつ分単価が高騰し始めるラインです。
2. GPUや特殊なネットワークが必要: クラウド上の仮想環境では不可能なIO操作がある場合。
3. セキュリティポリシー: 社内ネットワーク内からしかアクセスできないDBへ接続する必要がある場合。
極限のヒント:
AWSの EC2 Auto Scaling を活用し、「ジョブが来た時だけ立ち上げ、終わったら即座に消す」構成を組んでください。アイドル時間にお金を払うのは、開発者として最大の罪です。
—
3. コスト削減の鍵：トリガー制御と並列化
「全コミットで全テスト」を走らせていませんか？ それは貴社の資金をドブに捨てているのと同じです。
path-filtering（パスフィルタリング）を徹底せよ
ドキュメントの修正でビルドを走らせる必要はありません。
on:
push:
paths:
- ‘src/’ # ソースコードが変わった時だけCIを起動
- ‘!docs/’ # ドキュメント変更は無視
並列実行の魔術
一つの大きなジョブにすべてを詰め込むのはやめましょう。`jobs` を細分化し、並列実行させるのです。
jobs:
lint:
runs-on: ubuntu-latest
steps: …
test:
runs-on: ubuntu-latest
needs: lint # lintが通ったらtestを実行
strategy:
matrix:
# テストを3分割して並列実行！
shard: [1, 2, 3]
steps: …
これで、テスト時間は単純計算で1/3に短縮されます。
—
4. 今日から始める「HelloWorld」的最適化
まずは、今のワークフローにこの「キャッシュ最適化」を一行加えることから始めてください。
練習ステップ:
1. 既存の `.github/workflows/ci.yml` を開く。
2. 依存関係インストールステップの直前に `actions/cache` を挿入する。
3. `hashFiles` で依存関係ファイルを指定する。
4. 実行結果を「Actions」タブから見て、「Cache hit」と表示されているか確認する。
これだけで、数秒〜数分の短縮が、毎日何度も繰り返されることになります。一ヶ月後には、チーム全体の開発効率がどれほど跳ね上がっているか、想像してみてください。
最後に
DevOpsとは、ツールを導入することではありません。「無駄を極限まで削ぎ落とし、価値あるコードを書く時間を最大化する思想」のことです。
最初は小さく、キャッシュから始めてみてください。その小さな「秒」の短縮の積み重ねが、やがてプロジェクト全体の「年」単位の生産性向上に繋がります。
次回の更新では、さらに踏み込んだ「Dockerレイヤーキャッシュ」の最適化術をお届けします。お楽しみに！