1. 未分類
  2. 1083 view

GitHub Actionsのキャッシュは常に有効にしない方がいいかも、という話

自作アプリのビルドにGitHub Actionsを使っています。Electron製アプリのmacOS・Windows・Linuxのそれぞれのビルドができるので、とても助かっています。

プライベートリポジトリのビルドなので、料金が掛かります。Linuxは1分あたり0.008ドルと安価なのですが、Windowsは0.016ドル(2倍)、macOSは0.08ドル(10倍)という価格になっています。ビルドには約10分掛かるので、1回あたり(0.008+0.016+0.08)*10=1.04ドルの費用が掛かります。開発版をナイトリービルドすると月に約30ドル掛かることになります。

なるべく費用を抑えられないかとキャッシュ機能を導入してみたのですが、微妙な効果となり、利用は見送ることにしました。この記事ではどう微妙だったのかを記載します。

キャッシュとは

GitHub Actionsの標準機能で、作成に処理時間やネットワークアクセスを要するファイルを再利用するために保存しておき、あとで再利用することでビルドを効率的にするためのものです。

キャッシュした内容

Electron製アプリなので、Nodeモジュールを多数使用しており、そのインストールに時間が掛かっていました。

macOSWindowsLinux
yarn install1:182:421:07

この時間を削減すべく、node_modulesディレクトリをキャッシュ・・・しようとしたのですが、公式ドキュメントではYarnのキャッシュをキャッシュすることが推奨されていました。パッケージをネットワークから取得する時間が掛からなくなるので、処理時間の削減が期待できます。なぜnode_modulesではなくYarnキャッシュなのかは調べていませんが、公式推奨に従っておきました。

キャッシュ方法

公式ドキュメントからほぼコピペです。

- name: Get yarn cache directory path
  id: yarn-cache-dir-path
  run: echo "::set-output name=dir::$(yarn cache dir)"
- uses: actions/cache@v1
  with:
    path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
    key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
    restore-keys: |
      ${{ runner.os }}-yarn-

ベンチマーク結果

キャッシュヒットミス時

macOSWindowsLinux
Run actions/cache@v10:010:000:00
yarn install1:182:421:07
Post actions/cache@v13:530:360:33
合計5:123:181:40

まずはキャッシュが存在しない、もしくは、キャッシュの展開が終わっていなかった場合です。後者について補足です。ベンチマークすべく2回連続で同じビルドを実行したところ、1回目で作成したキャッシュを2回目で見つけることができませんでした。そのまま丸1日放置して3回目の実行をしたところ、そちらではキャッシュが見つかりました。どうやらキャッシュがクラウド上に展開されるまで多少の時間が掛かるようなのです。

さて、処理時間ですが「Run actions/cache@v1」と「Post actions/cache@v1」が増えています。「Run actions/cache@v1」はキャッシュを取得する処理です。今回はキャッシュヒットミス時なので、すべてのOSで一瞬で終わってます。「Post actions/cache@v1」はキャッシュヒットミス時に、次回実行に備えて今回の処理結果をキャッシュする処理です。macOSの処理時間の長さが目立ちます。アクションのログを確認したところ、tarでディレクトリを単一ファイルにgzip圧縮していました。

/usr/bin/tar -cz -f /Users/runner/runners/hogehoge/cache.tgz -C /Users/runner/Library/Caches/Yarn/v6 .

キャッシュヒット時

macOSWindowsLinux
Run actions/cache@v12:371:190:12
yarn install0:461:010:36
Post actions/cache@v10:020:040:01
合計3:252:240:49

続いてキャッシュヒット時です。「Run actions/cache@v1」にそれなりに時間が掛かっています。tar+gzipの伸張を行っています。「Post actions/cache@v1」はキャッシュの更新は不要なので、一瞬で終わっています。

まとめ

macOSWindowsLinux
キャッシュなし1:182:421:07
キャッシュヒットミス時5:123:181:40
キャッシュヒット時3:252:240:49

キャッシュヒット時でも、キャッシュなしの場合と同じぐらい(Windows・Linux)か、遅くなって(macOS)いますね。今回は採用を見送った方が良さそうです。

GitHub Actionsのキャッシュはtar+gzip形式で保存されるため、作成・利用のどちらのタイミングでもそれなりに処理時間が掛かってしまうようです。そのため「とりあえず有効にしておく」のではなく、しっかりベンチマークを行った上で、キャッシュすべきかどうか、見極める必要があることがわかりました。

おまけ

macOSだけ処理時間が長かった理由ですが、単純にキャッシュ対象サイズが大きかっただけでした。macOSの環境の性能が低いわけではありませんでした。tar+gzipの伸張にその分だけ時間が掛かる点は納得です。

macOSWindowsLinux
キャッシュなし1,526,082,694223,371,849226,353,276

未分類の最近記事

  1. JestでVue.js 単一ファイルコンポーネントのカバレッジが計測できなかった問題への対…

  2. GitHub Actionsのキャッシュは常に有効にしない方がいいかも、という話

  3. 個人開発を丸2年続けられたので進捗報告させてください

  4. Inversifyの基本

  5. NeDBの基本

関連記事

PAGE TOP