public memo

エンジニア向け小ネタ書き溜め用。公開日記だけど親切な文章とは程遠いかもしれない。

CodeBuildのビルド時間が急に長くなった時は、使用イメージの最新化で直る(ことがある)

2020-09-16 by MasakiMisawa
Tweet
このエントリーをはてなブックマークに追加
Pocket
LINEで送る

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

という事で、マネージドコンソールからビルドプロジェクトの環境イメージを最新化(変更)する手順を書いて今回は終わりです。

  1. 対象のビルドプロジェクト詳細からビルドの詳細タブ選択

  2. 今回は、example_build_project を例に進めます。

  3. 環境セクションから編集タブ選択
  4. イメージの上書き選択
  5. イメージのバージョンから選択可能な最新バージョンを選んで環境の更新押下
  6. 新しい環境イメージにマネージド型イメージを、イメージ/イメージのバージョンから選択可能な最新バージョンを選択してページ最下部の環境の更新で全て完了です。

結果

そんなこんなで、事象発生前のビルド実行時間が延びてしまう前の状態に戻す事ができました。

今回は以上です。

Tweet
このエントリーをはてなブックマークに追加
Pocket
LINEで送る

カテゴリー: AWS, CodeBuild タグ: AWS, CodeBuild

profile

profile_img Web系のソフトウェアエンジニアです。
野球観戦(横浜DeNAベイスターズ)、格闘ゲーム、カメラ、ランニング、愛犬、インテリア、美味しいものの食べ歩き、などなどが好き。

  • twitter MasakiMisawa
  • facebook MisawaMasaki
  • github MasakiMisawa
  • instagram masakimisawa
  • follow us in feedly

search

recent entry

  • M1 MacでAppleシリコンとIntelプロセッサのバイナリ管理を分離して共存させる
  • M1 MacでtfenvからTerraform1.0.2未満のダウンロードに失敗する問題を無理矢理解決する
  • GitHub ActionsからAWS利用時に永続的クレデンシャル情報を渡さないようにする
  • TerraformでAuroraのエンジンバージョンアップグレードをする時は、対象リソースをクラスターだけに絞る
  • CloudWatch Logsに出力されたエラーログ本文のSlackへの転送

category

  • AWS (17)
    • ACM (1)
    • AWS CLI (1)
    • Chatbot (2)
    • CloudWatchAlarm (1)
    • CloudWatchLogs (1)
    • CodeBuild (3)
    • DynamoDB (1)
    • IAM (1)
    • Kinesis (2)
    • Lambda (5)
    • OpenId Connect (1)
    • RDS (1)
    • S3 (2)
    • SNS (2)
    • SSM (2)
    • STS (1)
  • CI (2)
  • GCP (1)
    • PageSpeedInsights (1)
  • Git (3)
    • GitHub (2)
      • GitHub Actions (1)
  • M1 Mac (2)
  • Python (2)
  • Redis (1)
  • selenium (1)
  • Slack (3)
  • Terraform (3)
  • その他 (1)

archive

  • 2022年2月 (3)
  • 2021年1月 (1)
  • 2020年12月 (1)
  • 2020年11月 (1)
  • 2020年9月 (2)
  • 2020年8月 (1)
  • 2020年7月 (1)
  • 2020年6月 (1)
  • 2020年5月 (2)
  • 2020年4月 (1)
  • 2020年3月 (1)
  • 2020年1月 (1)
  • 2019年1月 (1)
  • 2017年12月 (1)
  • 2017年9月 (1)
  • 2017年8月 (1)
  • 2017年7月 (1)
  • 2017年2月 (1)
  • 2016年10月 (1)

tag cloud

ACM Aurora AWS AWS CLI Billing CI CloudWatchAlarm CloudWatch Logs CodeBuild Code Format Docker DynamoDB EC2 env find firehose Git GitHub GitHub Actions Homebrew husky IAM Role Java kinesis KinesisFirehose Lambda lint-staged M1 Mac Node.js OpenId Connect PHP Python RDS Redis RI S3 Selenium Slack SNS SSM Terraform tfenv セッションマネジャー リモートワーク 生産性

Copyright © 2023 public memo.