CIのキュー時間のコストとは？Runnerを待つ

CIのキュー時間とは、jobがトリガーされてから実際にrunnerがそれを拾い上げるまでの待ち時間です - 直接請求されない場合でも生産性のコストがかかります。

キュー時間は、請求書ではなく生産性の中に隠れているCIコストの一部です。runnerが不足していると、jobは待ち、リリースは滞り、開発者はコンテキストスイッチをします。プラットフォームによっては待ち時間に対して支払いさえ発生します。キューのコストを理解することで、遅いCIが本当にいくらかかるのかという全体像が完成します。

キューを引き起こす原因

キュー時間は、利用可能なrunnerよりもjobが多いときに発生します。同時実行の制限、上限のあるself-hostedフリート、またはcold-startのプロビジョニング遅延です。capacityが空くか新しいrunnerが起動するまで、jobはキューに入ったままになります。

直接コスト

ほとんどのhostedプラットフォームでは、キューにいる間は請求されませんが、一部のself-hostedや予約された構成では、あなたが待っているcapacityはすでにコストになっています。いずれにせよ、キューを避けるためにサイズ設定されたアイドルの予約capacityは、実際の費用です。

間接コスト

より大きなコストは人的なものです。キューに入ったbuildを待つ開発者はコンテキストスイッチをするか、手が空いてしまいます。キューの後ろでブロックされたリリースは、遅れて出荷されます。チーム全体では、キューによる遅延はあらゆる直接請求をはるかに上回ることがあります。

capacityのトレードオフ

runnerを過剰プロビジョニングすることでキューをなくすことはできますが、それはキューのコストをアイドルコストと引き換えにします。目標は、ほとんど使われない大きなフリートに支払うことなく、キューを短く保つのに十分なcapacityを持つことです。

キューのコストを測定する

jobごとのキュー滞在時間と、待機する実行の割合を追跡しましょう。意味のあるキュー遅延に開発者の時間とリリースへの影響を掛け合わせ、CIの請求書には決して現れない間接コストを見積もりましょう。

キュー時間を削減する

マネージドのウォームプールは、アイドルの無駄なしにキューを解決します。Latchkeyは事前初期化されたrunnerのプールを準備しておき、jobがほぼ即座に開始できるようにし、需要に合わせてcapacityをスケールします - キューのコストとアイドルフリートのコストの両方を、GitHub-hostedのレートより約70%低い価格で回避できます。

重要なポイント

キュー時間とは、jobがrunnerを得るまでの待ち時間です。
キューに対する直接請求はまれで、本当のコストは失われた生産性です。
過剰プロビジョニングでキューをなくすことは、それをアイドルコストと引き換えにするだけです。