CIにおけるコールドスタートのコストとは？実作業の前の数分間

コールドスタートのコストとは、すべての job が有用な作業を行う前に、プロビジョニング、起動、セットアップに費やす課金対象の時間です。

新しい runner はすべてコールドな状態から始まります。最初の実際のステップが実行される前に、起動し、イメージを取得し、依存関係を復元または再構築し、環境を構成します。このオーバーヘッドは分単位の全額レートで課金され、すべての job で繰り返されるため、CIで回避可能な最大の項目の一つになり得ます。

コールドスタートに含まれるもの

コールドスタートには、runner のプロビジョニング、OSの起動、イメージの取得、ツールチェーンのセットアップ、そして build やテストが実際に始まる前の依存関係のインストールが含まれます。ホスト型のエフェメラルな runner では、すべての job がこのオーバーヘッドをゼロから支払います。

どのように積み重なるか

月に5,000回実行される job での90秒のコールドスタートは7,500分 - Linuxの2コアレートで約$60 - に相当し、実際の作業の前に費やされます。多数の pipeline にわたって掛け合わせると、コールドスタートは請求額のかなりの部分を占めるようになります。

cache 対ウォームプール

依存関係の cache はコールドスタートのインストール部分を削減しますが、プロビジョニングと起動は取り除きません。ウォームプールは事前初期化された runner を準備状態で維持するため、job はコールドスタートのシーケンスの大部分を完全にスキップできます - cache では対処できない部分を攻略するのです。

コールドスタートと不安定さ

コールドスタートは不安定さの原因でもあります。セットアップ中のイメージ取得やレジストリ呼び出しは一時的に失敗することがあり、遅い開始を失敗した job と課金される再実行に変えてしまいます。そうなるとコールドスタートのコストは再実行のコストと重なって積み重なります。

測定する

最初の意味のあるステップのタイムスタンプを job の開始と比較してください。その差に実行回数とレートを掛けたものが、月間のコールドスタートコストであり、通常はチームの予想よりも大きくなります。

コールドスタートのコストを解消する

ウォームプールが直接的な解決策です。Latchkeyのマネージド runner は事前初期化された runner のウォームプールを維持するため、job は繰り返しのコールドスタート時間を支払うことなく素早く開始し、自己修復がコールドスタートによって引き起こされ得る一時的なセットアップの失敗を回復します - すべてGitHubホスト型のレートより約70%安く実現します。

重要なポイント

コールドスタートのコストとは、実作業が始まる前に課金されるセットアップ時間です。
すべての job で繰り返されるため、数千回の実行にわたって積み重なります。
cache はインストール時間を削減し、ウォームプールはコールドスタートの大部分を取り除きます。