runner の autoscaling とは？需要に追従するキャパシティ

runner の autoscaling は、job がキューに溜まるとより多くの runner を自動的に起動し、需要が下がると削除します - 理想的には何も動いていないときはゼロまで。

CI の負荷はスパイクします。1 時間何もなく、そして 17 時に 50 個の job。固定プールは、アイドルでお金を無駄にするか、ピーク時にチームを枯渇させるかのどちらかです。autoscaling は runner 数を実際の需要に、瞬間ごとに合わせます。

なぜ固定キャパシティは失敗するのか

ピークに合わせてプロビジョニングすれば、1 日の大半はアイドルなマシンに払うことになります。平均に合わせれば、最も忙しい時間帯が長いキューに詰まります。どちらも受け入れられず、だからこそ autoscaling が存在します。

autoscaling の仕組み

controller が job のキューを監視します。キューに溜まった job が利用可能な runner を超えると、より多くを起動します。runner がしきい値を超えてアイドルになると、それを終了します。目標は、マシンにお金を燃やさせずにキューを掃くのに十分なキャパシティです。

ゼロへのスケール

理想は、job が何も動いていないときにアイドルの runner をゼロまでスケールダウンし、時間外のコストをゼロにすることです。落とし穴は、ゼロからのスケールが cold start を再び持ち込むこと - だからこそ warm pool と autoscaling は通常組み合わされます。

スケーリングのラグ

需要への反応には時間がかかります。キューを検知し、インスタンスを起動し、boot し、登録します。その遅延がスケーリングのラグであり、バーストが新しい runner がオンラインになる前に一時的にキューに溜まる理由です。

手間なしの autoscaling

self-hosted runner で autoscaling を構築するとは、controller を書いて運用することを意味します。Latchkey のようなマネージドプラットフォームはあなたに代わって autoscale し、ゼロまでスケールし、warm pool がゼロからのスケールの cold start を覆い隠します。

重要なポイント

autoscaling は runner 数をリアルタイムの job 需要に合わせます。
アイドルの無駄とピーク時のキューイングの両方を避けます。
ゼロへのスケールは時間外のコストを節約しますが、cold start を再び持ち込みます。
マネージドプラットフォームはあなたに代わって autoscale し、warm pool と組み合わせます。