runnerの稼働率とは？アイドル時間に支払っていないか？

runnerの稼働率は、支払っているrunner時間のうち実際に有用な作業をしている割合です - 残りは金を燃やしているアイドル容量です。

低い稼働率は静かなCIコストです。bootしたままアイドルのrunnerや、シングルスレッドのjobを動かす16コアのマシンは、価値を返さずに費やされた金です。稼働率を測ることで、どこに無駄があるかがわかります。

2種類の無駄

時間ベースの無駄は、課金されながらアイドルなrunner（過剰にプロビジョニングされたpool、遅いscale-down）です。リソースベースの無駄は、jobに対して大きすぎるrunner - シングルスレッドのビルドが決して触れないコアとメモリに支払うことです。

なぜ稼働率が下がるか

• ピークに合わせてサイジングされ、一日の大半アイドルな固定pool。
• 「念のため」に選ばれた過大なrunner。
• 支払い対象のrunner時間として数えられる長いプロビジョニングやキュー時間。
• 並列容量を使わずに残す逐次的なjob。

稼働率を高める

runnerをjobにright-sizingし、autoscalingとscale-to-zeroでアイドル時間のコストをゼロにし、作業を並列化してマシンを忙しく保ちます。秒単位課金も役立ちます - 切り上げられたアイドルの末尾に支払うのをやめられます。

マネージドrunner上の稼働率

マネージドプラットフォームは稼働率を自動的に高めます: scale-to-zeroがアイドルの無駄を取り除き、right-sizingが過大なマシンを避けます。Latchkeyの秒単位課金とautoscalingは、アイドルではなく作業に支払うことを意味します。

測定する

アクティブなjob時間を課金されたrunner時間の総計と対比し、要求したrunnerサイズをjobごとに実際に使われたCPUとメモリと比較しましょう。どちらの軸でも大きな差は、過剰プロビジョニングをまっすぐ指し示します - 最も安いCIの節約はたいていそこにあります。

重要なポイント

• 稼働率は支払ったrunner時間のうち有用な作業をしている割合です。
• アイドルなpoolと過大なrunnerが無駄の主な原因です。
• right-sizing、scale-to-zero、並列化がそれを高めます。
• autoscalingと秒単位課金がコストを実際の作業に合わせます。

関連ガイド