GitHub Actionsの「キャッシュ地獄」を制圧せよ：大規模プロジェクトのためのストレージ最適化戦略
GitHub Actionsのキャッシュ機能は、パイプラインの高速化における「諸刃の剣」だ。依存関係の解決を数秒に短縮する一方で、不適切なキャッシュ戦略は、リポジトリのストレージ制限を瞬く間に食いつぶし、ビルドの失敗を誘発する。
諸君、GitHubが提供する10GBのキャッシュ枠は、大規模プロジェクトにとって「砂漠のオアシス」ほどに儚い。本稿では、GitHub Actionsのキャッシュアーキテクチャの深層に切り込み、運用負荷をゼロに近づけるための「極限の最適化ハック」を伝授する。
—
1. キャッシュキー設計の解像度を極限まで高める
多くのエンジニアが陥る罠は、`hashFiles(‘/package-lock.json’)` のような安直なキー指定だ。これは「依存関係が少しでも変わればキャッシュが無効になる」という設計であり、キャッシュの再利用率を著しく低下させる。
推奨戦略：マルチレイヤー・キャッシュキー
依存関係全体を一つの塊と見なすのではなく、「頻繁に変わるもの」と「恒久的なもの」を分離せよ。
GitHub Actionsにおける階層的キャッシュキーの例
- name: Cache Node Modules
uses: actions/cache@v3
with:
path: ~/.npm
# 依存関係のベースと、ロックファイルのハッシュを組み合わせて粒度を調整
key: ${{ runner.os }}-node-${{ hashFiles(‘/package-lock.json’) }}
# 前回のキャッシュが存在しない場合、直近のキャッシュをリストアして差分更新を狙う
restore-keys: |
${{ runner.os }}-node-
極意: `restore-keys` を活用し、完全一致しなくても「以前のキャッシュ」から再利用することで、初回ダウンロード量を劇的に削減せよ。
—
2. GitHub APIを叩く「キャッシュ抹殺スクリプト」の自動化
GitHub Actionsのキャッシュは、放置すれば古いブランチの残骸で溢れかえる。公式のインターフェースには「一括削除」ボタンなど存在しない。ならば、GitHub CLI (`gh`) と API を駆使して、「戦術的クリーンアップ」を自動化するのがプロの流儀だ。
以下は、`gh api` を用いて、特定期間アクセスがないキャッシュを自動削除するワークフローのコアロジックである。
!/bin/bash
delete-stale-caches.sh
最終アクセスからN日経過したキャッシュを特定し削除する
1. 削除対象のキャッシュキーをリストアップ
（GitHub APIのレートリミットを考慮してページネーションを実装すること）
CACHE_LIST=$(gh api repos/:owner/:repo/actions/caches –paginate -q ‘.actions_caches[] | select(.last_accessed_at < (now - 86400 7) | .id)')
for CACHE_ID in $CACHE_LIST; do
echo "Deleting stale cache: $CACHE_ID"
gh api -X DELETE repos/:owner/:repo/actions/caches/$CACHE_ID
done
これを `workflow_dispatch` または `schedule` で定期実行せよ。リポジトリのキャッシュ容量は常に一定の「健康的な数値」を維持するはずだ。
---
3. 「キャッシュ爆発」を引き起こす依存関係の排除
そもそも、「キャッシュすべきではないもの」をキャッシュしていないか？
大規模プロジェクトでは、CI環境とローカル環境の差異を埋めるために、不必要なバイナリやテスト生成物までキャッシュに含めがちだ。
- Node.jsの場合: `node_modules` を直接キャッシュするのはアンチパターンだ。インストール済みのパッケージのキャッシュディレクトリ（`~/.npm`）をターゲットにせよ。
- Dockerビルドの場合: `docker/build-push-action` の `cache-to` / `cache-from` モードにおいて、`type=local` ではなく `type=gha` を使用せよ。GitHubの共有ストレージを直接活用することで、I/O負荷とストレージ消費を最小化できる。
Dockerの最適化例
- name: Build and push
uses: docker/build-push-action@v5
with:
cache-from: type=gha
cache-to: type=gha,mode=max # mode=maxを指定して中間レイヤーまでキャッシュする
—
4. アーキテクチャの深層：メモリ消費とコンテキストスイッチ
最後に、CIパイプラインの低レイヤ視点での最適化だ。キャッシュのリストアはネットワークI/Oに依存する。キャッシュサイズが数百MBを超えると、リストア時間だけで数分を浪費する。
- 圧縮アルゴリズムの最適化: GitHub Actionsの内部ではキャッシュの圧縮に時間がかかる。依存関係が膨大であれば、`npm ci –prefer-offline` 等を併用し、ネットワークフェッチを極限まで減らした上で、あえて「圧縮率を下げて展開速度を上げる」というトレードオフを検討せよ。
- モノレポの罠: モノレポ構成では、ルートの `package-lock.json` だけでキャッシュを管理すると、無関係なパッケージの変更でキャッシュが無効化される。`workspaces` ごとにキーを細分化し、キャッシュの局所性を高める設計が必須だ。
—
結びに：伝説的エンジニアからの提言
CI/CDの最適化とは、単なるツールの設定ではない。「いかにして待ち時間をゼロに近づけ、開発者の認知負荷を排除するか」という、エンジニアリングの芸術である。
キャッシュの管理を怠る者は、パイプラインの肥大化という「技術的負債」の利息を毎日支払うことになる。今すぐ、諸君のパイプラインから「不要なキャッシュ」をパージし、洗練されたアーキテクチャへと昇華させよ。
最適化に終わりはない。計測し、分析し、自動化せよ。それが我々の職務である。