CIにおけるCold Start vs Warm Start: 待ち時間はどこから来るのか

cold startとは、jobが始まる前にrunnerを作成して起動しなければならないことを意味し、warm startとは、すでに1つが待機していることを意味します。その違いは、どのstepが実行される前にも感じるキューから開始までの遅延です。

jobが1つのstepを実行する前に、runnerは存在し、起動し、登録され、割り当てられなければなりません。それがオンデマンド（cold）で行われるか、準備済みのpool（warm）から行われるかが、各jobの前にどれだけのアイドル待ち時間が置かれるかを決めます。

cold startに含まれるもの

新しいインスタンスのプロビジョニング（VMの割り当て）。
runner imageの起動とエージェントの開始。
CIサービスへの登録とjobの割り当て。
そこで初めて - そのときになってようやく - 最初のstepが始まります。

warm startが省くもの

warm startは、あらかじめプロビジョニング、起動、登録されたrunnerのpoolから引き出します。jobはほぼ即座にそのうちの1つに引き渡され、プロビジョニングと起動の遅延を省きます。最初のstepは、jobを割り当てるのにかかる時間程度で始まります。

トレードオフ

warm runnerは、仕事を待ってアイドルしている間もお金がかかります。cold startは各jobにレイテンシのコストがかかりますが、アイドル中は何もかかりません。マネージドrunnerプラットフォームは、需要に合わせてサイズを調整したwarm poolでこれをバランスします。通常の負荷を吸収できるだけの準備済みrunnerを用意し、あふれた分はcold startのプロビジョニングで対応します。

コストと体感にとって重要な理由

cold startの時間は、依然として支払う可能性のあるデッドタイムであり（job内のセットアップは課金対象です）、特に短いjobが多いとCIを重く感じさせます。それを - warm poolと起動の速い無駄のないimageによって - 減らすことで、請求と開発者体験の両方が改善されます。長いキューの後の緑のチェックも、依然としてプロビジョニングの問題を隠しています。

重要なポイント

Cold start = jobが始まる前にプロビジョニング + 起動 + 登録。
Warm start = プロビジョニング済みのrunnerを再利用し、その遅延を省く。
warm poolはアイドルのコストがかかり、cold startはjobごとのレイテンシがかかる。
起動の速いimageと適切なサイズのwarm poolはコストと体感を改善する。