AWSCodeBuildのビルド時間を改善しました
アイミツ開発チームでエンジニアリングをしている deliku といいます。
今回は、CodeBuildの設定をチューニングしてビルド時間を短縮した方法について紹介します。
CI/CDパイプライン構成
私のチームでは、CI/CDパイプラインにCodePipelineを利用しており、develop や main などのブランチへの変更をトリガーにCodePipelineを開始するように設定しています。その後、CodeBuildにてアプリケーションビルド、Dockerイメージ生成、ECRにDockerイメージPush、CodeDeployによるECSへデプロイするといった構成になっています。
改善前のCodeBuild処理時間
下記は改善前の実行時間を示した図になります。合計で11分23秒、特にBUILDフェーズで476秒かかっていました。
検証1 コンピューティングインスタンスタイプ変更
general1.medium （メモリ 7 GB / vCPU 4）から、general1.large（メモリ 15 GB / vCPU 8）に変更します。AWS CodeBuildのコストは、ビルド 1 分あたりの料金によって変わります。今回スペックを2倍にして実行時間が1/2になった場合、トータルのコストは変わらないことになります。
general1.largeに変更して実行した結果は下記の通りです。BUILDフェーズが20%、POST_BUILDフェーズが40%改善され、合計で8分38秒となりました。
検証2 イメージバージョンを詳細バージョンで固定化
先ほど検証した general1.large（メモリ 15 GB / vCPU 8） のまま、今度は、イメージバージョンを変更してキャッシュメリットを享受できるか（PROVISIONINGフェーズの実行時間短縮）の検証をします。
各イメージの最新バージョンがキャッシュされます。具体的なバージョンを指定すると、キャッシュされたバージョンではなく、そのバージョンのプロビジョニングが CodeBuild によって行われます。これにより、ビルド時間が長くなることがあります。たとえば、キャッシュのメリットを得るには、aws/codebuild/amazonlinux2-x86_64-standard:3.0 のような詳細バージョンではなく aws/codebuild/amazonlinux2-x86_64-standard:3.0-1.0.0 を指定します。
aws/codebuild/standard:5.0 から aws/codebuild/standard:6.0-23.02.16 に変更して検証します。
PROVISIONINGフェーズの実行時間短縮にはつながりませんでした。
検証3 DOCKER_BUILDKIT有効化
general1.large（メモリ 15 GB / vCPU 8） のまま、buildspec.ymlに下記の設定を追加して有効化します。
env:
variables:
DOCKER_BUILDKIT: 1DAG構造を採用した中間言語であるLLBを用いることで、各レイヤーの依存関係を正確に表現し、キャッシュが良く効くようになっています。これにより、従来はマルチステージビルドにおいて依存関係がないビルドも直列で実行されていたのが、BuildKitによる並列実行が可能になっています。
合計で6分45秒となりました。ステージに依存関係がない処理がいくつか並列で実行されるように大幅に処理時間の改善につながりました。
まとめ
CodeBuildの設定見直しにより、 11分23秒 から 6分45秒へ 40%程度改善することができました。普段から使い慣れているツールでも最適化されているとは限らないので、改善できないかな？という気持ちでまずはやってみるのが良さそうだなと思いました。
▶ 【PR】ユニラボ に興味がある方へ
今回の記事を読んでユニラボに興味を持っていただけた方は、まずはカジュアル面談でざっくりお話させていただければと思います！
この記事が気に入ったらサポートをしてみませんか？