CI における cold start とは？最初の step 前の待ち時間

cold start とは、job が 1 つの step を実行できるようになる前に、真新しい runner をプロビジョニングする - boot し、登録し、準備する - のに費やされる時間です。

ephemeral runner はすべての job にクリーンなマシンを与えますが、クリーンなマシンはまず作成されなければなりません。そのセットアップ時間が cold start であり、新しい runner に当たるすべての job で、フィードバックのレイテンシとして払うデッドタイムです。

cold start の間に起きること

インスタンスを起動し、OS を boot し、runner エージェントを起動して GitHub に登録し、それから job を開始します。完全に冷えた経路では、イメージのサイズとインフラによって、数十秒から数分に及ぶことがあります。

cold start vs warm start

warm start は、すでに boot・登録済みの runner に job を渡すため、最初の step は約 1 秒で始まります。冷たいと温かいの違いは、完全にあなたが事前に行った、または行わなかったプロビジョニング作業によるものです。

cold start を悪化させるもの

• pull と boot に時間がかかる大きい runner イメージ。
• job が到着するまで runner が存在しない、ゼロからのスケール。
• 復元元の cache がない、重い依存関係のインストール。

取り除く方法

事前起動された runner の warm pool を維持して job が準備済みのマシンを掴めるようにし、cache を使って新しい runner でも依存関係を再構築するのではなく高速に復元できるようにします。

Latchkey では cold start なし

Latchkey は job を warm pool から提供するため、cold start の待ちなしに ephemeral runner のクリーンな状態の利点が得られます - job は通常約 1 秒で開始します。

重要なポイント

• cold start とは、新しい runner が job を実行できるようになる前のプロビジョニング遅延です。
• warm start は約 1 秒で始まり、cold start ははるかに長くかかります。
• 大きいイメージ、ゼロからのスケール、cache されていない依存関係が悪化させます。
• warm pool と cache が cold start の税をなくします。

関連ガイド