CodeBuildのビルド実行時間が急に長くなってしまい、且つ何も変更をしていないなど原因に対して思い当たる節がない時の対処法の一つです。
ビルド実行時間が長くなる要因は無数にあるのであくまでもその中の1ケースですが、今回のPROVISIONINGの時間が長くなってしまうパターンは割とハマりやすいケースだと思うので紹介します。
発生事象
ある時から急にCodeBuildのビルド実行時間が倍以上かかるようになってしまう事象が発生しました。
長くなってしまった境界線のPRの変更内容はビルド実行時間に影響を与える内容ではなく、原因がさっぱり思い当たりません。
このビルドプロジェクトはCI用途で使用していたものだった為、こうなると自動で走るテストの実行待ち時間が長くなりストレスは溜まるわ、CodeBuildの課金体系が実行時間課金なことから利用料金も高くなるわで大問題です。
どのフェーズが原因か
結果としてビルド実行時間が長くなっていますが、CodeBuildのビルドはSUBMITTEDからCOMPLETEDまで全10個のフェーズに分かれている為、事象発生前と発生後のフェーズ詳細を比較して具体的にどのフェーズが長くなってしまっているのかを調べます。
参考: AWS CodeBuild におけるビルドの詳細の表示
比較してみると、PROVISIONINGフェーズが3分半（約8倍）も長くなってしまっているのが確認可能で、ここが原因である事が分かります。
PROVISIONINGフェーズはCodeBuildのビルドプロジェクト自体の実行コンテナの準備などがメインのフェーズで、ビルドプロジェクトの環境が大きく影響している可能性が高そうです。
ビルドプロジェクトの環境
今回のビルドプロジェクトの環境は以下のような環境ですが、実行コンテナの準備にかかる時間に影響しそうな要因が3つ程見当たります。
1. 環境イメージ
ビルド実行時の環境として各種準備が必要な場合などは自前で用意したカスタムのDockerイメージを用いますが、今回の環境はシンプルなテストを実行できれば十分な用件だった為、AWSが用意してくれているマネージド型のAmazon Linux2のイメージを使用しています。
環境タイプはLinuxで変更していないので実行時間が長くなる影響にはならなさそうですが、イメージのバージョンが当ビルドプロジェクト作成時の最新バージョンから更新されていないのが気になります。
2. VPC/非VPC
VPC環境のリソースにアクセスする為には事前にENIの作成が必要になるなどPROVISIONINGの実行時間が長くなる事が予想されますが、今回は非VPC環境のビルドプロジェクトだった為、これは関係なさそうです。
3. コンピューティングリソースのスペック
使用するコンピューティングリソースのスペックが増減すればその分PROVISIONING時間にも変化を与える事が予想されますが、事象発生前と発生後で特に変更していない為、これが原因の可能性は低そうです。
どう直したか
結論から書くと、環境イメージに使用しているマネージド型のイメージのバージョンを最新化する事で事象発生前の元の実行時間に戻すことができました。
あれが原因かなー、これが原因かなーと試行錯誤した過程から辿り着いた結果ですが、その過程はかなり不毛だったので割合します…w
という事で、マネージドコンソールからビルドプロジェクトの環境イメージを最新化（変更）する手順を書いて今回は終わりです。
- 対象のビルドプロジェクト詳細からビルドの詳細タブ選択
- 環境セクションから編集タブ選択
- イメージの上書き選択
- イメージのバージョンから選択可能な最新バージョンを選んで環境の更新押下
今回は、example_build_project を例に進めます。
新しい環境イメージにマネージド型イメージを、イメージ/イメージのバージョンから選択可能な最新バージョンを選択してページ最下部の環境の更新で全て完了です。
結果
そんなこんなで、事象発生前のビルド実行時間が延びてしまう前の状態に戻す事ができました。
今回は以上です。