runner のライトサイジングとは？マシンサイズを job に合わせる

runner のライトサイジングとは、job を依然として効率的に実行できる、最小かつ最も安価なマシンを選ぶことです - アイドル状態のコアに支払うことも、小さすぎるマシンのために追加の分数を支払うこともありません。

runner のサイズは双方向のコストレバーです。大きすぎればアイドル状態のコアにプレミアム料金を支払い、小さすぎれば job の実行時間が長くなり、より多くの分数を消費します。ライトサイジングは job ごとに最適なバランスを見つけ、pipeline は常に稼働しているため、正しく設定すれば毎回の実行で効果を発揮します。

間違えたときのコスト

8 コアの runner は 2 コアの約 4x の料金がかかります。job が I/O バウンドでコアをまったく使わない場合、そのプレミアムの 4 分の 3 は無駄です。しかし、4 コアの 2 倍の時間がかかる 2 コアの runner は、大きなマシンよりも分数で高くつくことがあります。

適切なサイズの見つけ方

job をプロファイルしましょう。サイズごとに CPU とメモリの使用率を観察します。適切なサイズとは、job がボトルネックにならない最小のもの - コアを追加しても実行時間が意味のある形で短縮されなくなる地点です。それを下回ると分数を無駄にし、上回ると料金を無駄にします。

CPU バウンド対 I/O バウンド

CPU バウンドの job（コンパイル、重いテストスイート）はより多くのコアの恩恵を受け、速く終わる大きな runner の方が安くなることがあります。I/O バウンドの job（ダウンロード、ネットワーク呼び出し）は追加のコアからほとんど恩恵を受けないため、小さいままにすべきです。

pipeline ごとではなく job ごとにライトサイジング

1 つの pipeline 内の異なる job は異なるプロファイルを持ちます。lint の job はほとんど何も必要としませんが、統合スイートには実際のコアが必要になることがあります。各 job を独立してサイジングする方が、pipeline 全体に 1 つのサイズを選ぶよりも優れています。

メモリも重要

ライトサイジングはコアだけの話ではありません。小さな runner で OOM になって kill される job は実行全体を無駄にし、使用量よりはるかに多いメモリを持つ job は払いすぎになります。メモリは推測ではなく、job の実際のピークに合わせましょう。

マネージド runner でのライトサイジング

マネージドプラットフォームは、適正価格のサイズを幅広く提供し、プロビジョニングを処理することでライトサイジングを簡単にします。Latchkey は正しくサイジングされたクラウドインスタンスで job を実行し、GitHub ホステッドより約 70% 低いコストなので、正しくサイジングされた runner はホステッド版と比べて 1 分あたりでも安くなります。

重要なポイント

ライトサイジングは、job を効率的に実行できる最小のマシンを選びます。
大きすぎるとアイドル状態のコアで料金を無駄にし、小さすぎると実行時間で分数を無駄にします。
CPU バウンドの job は大きな runner の方が安くなる場合があり、I/O バウンドの job は小さいままにします。