runnerのスケーリングラグとは？容量が届くまでの遅延

runnerのスケーリングラグは、需要の急増から新しいrunnerが実際に準備完了になるまでの時間です - autoscalingが追いつく間にjobがキューされる窓です。

autoscalingは瞬時ではありません。jobのバーストが到着すると、システムはそれに気づき、インスタンスを起動し、それがbootして登録するのを待たなければなりません。その遅延がスケーリングラグであり、autoscaledなfleetでも一時的にキューが生じうる理由です。

ラグはどこから来るか

検出: コントローラがpollし、遅延を伴ってキューに気づく。
Launch: 新しいインスタンスを要求し起動するのに時間がかかる。
Bootと登録: 各新runnerはjobを取る前にcold-startする。

なぜ重要か

ラグの間、システムが正しくスケールアップしていてもjobはキューに座ります。短いバーストでは、新しい容量が届く前にキューが片付くことすらあります - つまり開発者は何のためでもなく待ったことになります。

warm poolがどう隠すか

warm poolはすでにbootされたrunnerでバーストの最初の波を吸収するので、autoscalingが裏でより多くの容量をプロビジョニングする間、jobは即座に開始します。poolはラグを覆う時間を稼ぎます。

ラグを最小化する

より速い検出、事前ウォームされた容量、より小さいイメージはすべてラグを縮めます。マネージドプラットフォームはwarm poolと高速なautoscalingを組み合わせ、バーストが即座に処理されラグが見えなくなるようにします。

スケーリングラグ vs cold start

両者は関連しますが別物です: cold startは1つのrunnerがプロビジョニングに時間をかけることで、スケーリングラグはシステムがそもそもrunnerを追加すると判断するのに時間をかけることです。warm poolでcold startを排除しても、poolがバーストに対して小さすぎればラグは依然として見えます。

重要なポイント

スケーリングラグはautoscaledなrunnerがオンラインになるまでの遅延です。
検出、launch、bootと登録の時間から生じます。
ラグの間、システムが正しくスケールしていてもjobはキューされます。
warm poolがバーストを吸収し、ラグを開発者に見えなくします。