runner のキューとは？なぜ job は実行前に待つのか

runner のキューとは、空いた runner を待つ job の列です - job がキューで過ごすすべての秒は、最初の step が始まる前の時間です。

利用可能な runner よりも多くの job があると、余分な job はキューに入ります。キューの時間は純粋な無駄です。何も build されず、何もテストされず、チームはただ待っているだけです。なぜキューが形成されるかを理解することが、それを取り除く第一歩です。

なぜキューが形成されるのか

• 並列数の上限: プランやフリートが同時に動く runner 数を制限する。
• 遅いスケーリング: autoscaling が runner を追加できるより速くバーストが到着する。
• ウォームなキャパシティの欠如: すべての job が cold start を払い、スループットが需要に遅れる。
• label の不一致: job が利用可能なキャパシティのない runner タイプを要求する。

キュー時間の読み方

キュー時間は、job が作成されてから実際に開始するまでのギャップ（started_at から created_at を引いたもの）です。一貫して高いギャップは、build 自体の問題ではなく、キャパシティまたはスケーリングの問題を意味します。

キューイングのコスト

キューはチーム全体を遅らせます。フィードバックループの長期化、ブロックされる merge、そしてチェックを無効化する圧力。CI の請求では見えないことが多い（キューの時間には課金されない）一方で、開発者のフラストレーションには非常にはっきり現れます。

解消の方法

キャパシティを追加し（autoscaling）、cold start を取り除き（warm pool）、並列数を適切にサイジングします。warm pool と高速な autoscaling の組み合わせが、バースト中でもキューを空に保つものです。

キューのない runner

Latchkey は job を warm pool から提供し autoscale するため、job は通常約 1 秒でキューなしに開始します - 複数が同時に到着したときでも。

重要なポイント

• runner のキューとは、利用可能な runner を待っている job です。
• 並列数の上限、遅いスケーリング、またはウォームなキャパシティの欠如が原因です。
• キュー時間は started_at から created_at を引いたもの - 純粋に無駄なフィードバック時間です。
• warm pool と autoscaling がキューを空に保ちます。

関連ガイド