GithubActions における DockerImage の Buildキャッシュ戦略

どうも、PHPerです。

直近、業務でECSへのデプロイワークフローを実装することになりました。

主な流れは以下の通りです。

1. フロントエンドのビルド
2. Docker Image のビルド
3. ECR へのログイン
4. ECR へPush
5. ECS のサービス更新

この中でボトルネックになるのが 「2. Docker Image のビルド」 です。

毎回フルビルドしていると時間がかかりすぎるため、キャッシュの利用は必須です。

Docker Buildx のキャッシュバックエンドには、大きく分けて以下の3つの選択肢があります。

1. GitHub Actions Cache (type=gha)
2. GitHub Container Registry (type=registry)
3. Amazon ECR (type=registry)

これらを比較検討した結果、今回は 「GitHub Actions Cache (type=gha)」 を採用しました。

その理由はズバリ、「利用料（ランニングコスト）」と「実装（設定）コスト」が最も低かったからです。

比較検討：3つのキャッシュ戦略

それぞれの特徴を「コスト」と「手間」の観点で整理しました。

1. Amazon ECR (type=registry)

AWS環境に統一できるメリットはありますが、以下のデメリットがあります。

• 実装コスト
  IAMロールの設定、aws-actions/amazon-ecr-login の設定が必要。
• 利用料
  • データ転送量
    GitHub Actions (インターネット) ⇔ AWS ECR 間の通信が発生します。
    NAT Gatewayを経由する場合などは特に通信費がかさむ可能性があります。
  • ストレージ料金
    キャッシュイメージの分だけECRのストレージ料金が発生します。
  • 実行時間
    ネットワーク越しにPush/Pullするため、ビルド時間が伸び＝GitHub Actionsの課金対象時間（Minutes）も消費します。

2. GitHub Container Registry (type=registry)

GitHubのエコシステム内で完結しますが、こちらも考慮が必要です。

• 実装コスト
  docker/login-action での認証設定や、パッケージの読み書き権限設定が必要。
• 利用料
  • Organizationのプランによっては、GHCRのストレージ容量やデータ転送量に制限・課金が発生する場合があるらしい

3. GitHub Actions Cache (type=gha)

今回採用した方法です。

• 実装コスト
  認証設定が一切不要。YAMLに数行書くだけ。
• 利用料
  • 通信費ゼロ
    GitHub Actionsの内部ネットワークで完結するため、外部への転送コストがかかりません。
  • ストレージ無料
    リポジトリあたり10GBまで利用可能（超過分は古いものから自動削除されるだけなので、追加課金のリスクがない）。
  • 実行時間短縮
    ネットワークが高速なため、キャッシュのリストアが速く、結果としてActionsの実行時間を節約できます。

比較まとめ表

キャッシュ戦略	実装(設定)コスト	利用料(ランニングコスト)	速度
GHA Cache (type=gha)	◎ (認証不要)	◎ (基本無料)	◎ (最速)
GHCR (type=registry)	△ (Token設定必要)	◯ (プラン依存)	◯
ECR (type=registry)	△ (IAM設定必要)	△ (通信費・保管費)	△ (通信発生)

なぜ type=gha を選んだか

今回の要件において、私が重視したのは以下の2点です。

1. ワークフローの利用料を抑えたい
   • 無駄なデータ転送費やストレージ料金を払いたくない。
   • ビルド時間を短縮して、GitHub Actionsの利用枠（Minutes）を節約したい。
2. 実装コストを最小限にしたい
   • キャッシュのためだけにIAM権限を調整したり、Secretsを管理したりする手間を省きたい。
   • シンプルに保ち、メンテナンスしやすくしたい。

この2点を満たすのが type=gha でした。

「ローカル開発環境でも同じキャッシュを使いたい」という要件があれば registry 系が候補に挙がりますが、今回は「CIの高速化」が主目的だったため、迷わずこちらを選択しました。

実装コード

設定は驚くほどシンプルです。docker/build-push-action に cache-from / cache-to を追加するだけです。

      # Buildxのセットアップ（必須）
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      # ビルド & Push
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.login-ecr.outputs.registry }}/my-app:latest
          # ★ここがポイント
          cache-from: type=gha
          cache-to: type=gha,mode=max

ポイント：mode=max

cache-to: type=gha,mode=max を指定することで、最終的なイメージだけでなく、中間レイヤー（npm install などを行ったレイヤー）もキャッシュされます。
これにより、コードを少し変更しただけでもフルビルドが走るのを防げます。

まとめ

技術選定において「高機能であること」も重要ですが、「コストがかからない」「設定が楽」 というのは、運用を続ける上で正義です。

ECSデプロイのビルド時間に悩んでいる方は、まずは一番手軽で財布に優しい type=gha から試してみてはいかがでしょうか。