Lapis Lazuli

technical blog for web developer

CodeBuildのキャッシュ効果がすごかった

CodeBuildのキャッシュの種類

最近CodeBuildを導入して使っていますが、ビルド時に使用するリソースをキャッシュしておく機能があります。
主に2種類のタイプがあって、S3に保存するタイプとローカルに保存するタイプがあります。
それぞれ特徴があって、利用するケースによって使い分ける形です。

docs.aws.amazon.com


S3保存はその名の通り、キャッシュデータをS3に保存します。
メリットはローカルに依存しないので、複数のビルドで使い回す事ができることです。S3は保存コストが低いので、キャッシュをためておいてもそこまで料金がかさみません。
もちろんデータを消さない限りキャッシュが永続化するので、ビルドがそこまで頻繁にしないケースもこちらを利用することになります。
欠点はCodeBuildとネットワーク経由で接続されるので、容量が大きいとそれなりに時間かかったりします。

もう一つのローカルキャッシュは後から追加されたのですが、ローカルに保存するタイプです。
ローカル直結のキャッシュなのでめちゃくちゃ早いです。実際に使ってみたらビルド時間が5分の1になりました。効果絶大ですね。
ただインスタンスなデータなので、しばらく使わないと効果がなくなってしまいます。
なので短時間で何度もビルドするような開発に向いてますね。

残念ながらうちのチームはそこまで頻繁にビルドしないので(本番も開発も)S3キャッシュを選択することにしました。
でもローカルも気になったので、どれくらい効果あるか一度試してみましたが・・・

キャッシュの使い方

ではキャッシュの使い方ですが、S3の場合はビルドキャッシュのバケットとパスを指定します(パスはオプション)

f:id:cres-tech:20200831230317p:plain

あとばbuildspecでキャッシュする箇所を指定します。

cache:
  paths:
  - '/go/pkg/**/*'

これでそのパスはS3に保存されます。
ビルド実行したあとに確認すると、圧縮され一つのファイルになったキャッシュの存在が確認できると思います。
保存されていればキャッシュが利用されているので、これで次回からのビルドが早くなるはずです。

結果

5GBほどある巨大なGoリポジトリをビルドしたところ、20分かかっていたのが8分に短縮されました。
半分以下なのでかなり効果ありますが、ローカルの場合だと3分だったので、やっぱりローカルは早い・・・という結果でした。
とはいえ8分もまだまだ長いので、更に削減できないか四苦八苦しています。