こんにちは、虎の穴ラボ FantiaエンジニアのT.Kです。今回はGCPのCloudBuildでビルドした際、リソースをモニタリングする方法と、それをAIを使用して簡潔に分析する方法を共有します。

CloudBuildとは

CloudBuildはサーバーレスなCI/CDプラットフォームで、常に同じ環境下でビルドを実行できます。 AWSでいうCodeBuildのようなものです。

なぜリソースモニタリング？

CloudBuildで日々ビルドを続けているうち、ビルド時間が長くなってくるのはよくあることだと思います。
CloudBuildで使用するサーバーのスペックは「ワーカープール」を変更することで可能ではあるのですが、そもそも「リソース不足で遅いのか？それ以外が原因か？」を判別する手段がありませんでした。
GCEのVMインスタンスのようにCPU使用率やメモリ使用量が可視化できればよいのですが、標準ではそういった機能がないため、スペックをあげるべきなのかどうか？がわかりにくい状態でした。

モニタリング

今回は継続的に監視してアラートを出したいというよりは、実際に中で起こっていることを分析したいという意図なので、以下のように冒頭でprocpsとsysstatを導入して定期実行することにしました。

apt-get update && apt-get install -y procps sysstat
nohup bash -c 'while true; do
  echo "======== [CLOUDBUILD_MONITOR] Resource monitoring at $(date) ========"
  echo "[CLOUDBUILD_MONITOR] CPU Usage:"
  top -bn1 | head -n 20
  echo "[CLOUDBUILD_MONITOR] Memory Usage:"
  free -m
  echo "[CLOUDBUILD_MONITOR] Disk I/O:"
  iostat -x 1 1
  echo "[CLOUDBUILD_MONITOR] Load Average:"
  uptime
  echo "[CLOUDBUILD_MONITOR] ========================================"
  sleep 30
done' > /tmp/resource_monitor.log 2>&1 &

結果

以下のような結果を30秒ごとに記録したテキストログが、CloudBuildの最後に出力されます

[CLOUDBUILD_MONITOR] CPU Usage:
top - 15:40:07 up 12 min,  0 user,  load average: 0.41, 0.56, 0.40
Tasks:   5 total,   1 running,   4 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st 
MiB Mem :   3930.7 total,   1293.7 free,   1113.1 used,   1815.5 buff/cache     
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   2817.6 avail Mem 
（略）
[CLOUDBUILD_MONITOR] Memory Usage:
               total        used        free      shared  buff/cache   available
Mem:            3930        1111        1294           0        1815        2818
Swap:              0           0           0
[CLOUDBUILD_MONITOR] Disk I/O:
（略）
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.43    0.04    6.66    0.94    0.06   73.88
Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz     f/s f_await  aqu-sz  %util
sda             35.70   1201.00    19.41  35.22    0.51    33.64   85.80   7249.74   281.57  76.65   14.12    84.50    1.58   1518.69     0.00   0.00    0.59   961.66   20.86    0.05    1.23   8.47
[CLOUDBUILD_MONITOR] Load Average:
 15:40:07 up 12 min,  0 user,  load average: 0.41, 0.56, 0.40

これを見ることで、例えば「bundle install」が重いんだなとか、そういうことがわかりました。

分析

しかし、大量のテキストデータを読み解くには時間がかかります。そこで、ChatGPTやGeminiなどのAIに分析を任せることで、要約してもらうことにしました。

 例）
全体的な傾向
ビルドは開始後、約1.5分から2分にかけてCPUとメモリを最も消費し、その後は徐々にリソース消費量が低下していく傾向が見られます。特に、ビルドの初期段階でCPUとメモリが大きく使われていることがわかります。

CPU使用率と負荷平均
開始から約30秒後: 複数のプロセスが同時に動作し、CPU使用率が100%に達しています。これは、ビルドの初期ステップがリソースを大量に消費していることを示しています。ロードアベレージ（システム負荷の平均値）も初期のピーク時には 2.17 と高く、システムがタスク処理に忙しい状態でした。
開始から約1分後: CPU使用率は100%を維持し、npm ins+ プロセスがCPUを131.2%と非常に高く使用しています。これは、2コアのCPUを最大限に活用していることを意味します。この時点でメモリ使用量も急増し始めました。
（略）

メモリ使用量
開始から約30秒後: 使用メモリ量が約 899 MiB でした。
開始から約1分後: npm ins+ プロセスによって使用メモリ量が約 1.5 GiB に急増します。
（略）

ディスクI/O
開始から約30秒後: ディスク書き込み量（wkB/s）が約 37 MB/秒 でした。これは、ビルドの初期ステップでファイル書き込みが活発に行われていることを示しています。
開始から約2.5分後以降: ディスク書き込み量は徐々に低下し、ビルドが終盤に近づくにつれてディスクI/Oの負荷も下がっていきました。
（略）

このビルドは、ビルドの初期から中間にかけてCPUとメモリを非常に集中的に利用する一方で、後半ではリソース使用量が安定し、ビルドが終了に向かうことが明確に示されています。特にメモリ消費のピークが顕著であり、このビルドの性質を理解する上で重要なポイントと言えます。

ざっくりと推移や傾向を知りたいだけだったので、非常に手軽でした。