CI における過剰プロビジョニングのコストとは？余裕に支払う

過剰プロビジョニングのコストとは、job が実際に使う以上の runner のサイズや容量に支払うことで無駄にするものです。

過剰プロビジョニングは CI の無駄の最も一般的な形です。なぜなら安全に感じられるからです - 「念のため」に大きな runner や大きなフリート。しかし、使われないコアやアイドル状態のマシンはすべて課金され、その安全マージンは静かに CI コストの中で最大の回避可能な項目になり得ます。

サイズによる過剰プロビジョニング

2 コアで足りる job に 8 コアの runner を予約するということは、6 コアが大きな runner のプレミアム料金で支払われてアイドル状態になるということです。8 コアは 2 コアの約 4x の料金がかかるため、サイズが大きすぎる runner はその job で 4 分の 3 が無駄になり得ます。

容量による過剰プロビジョニング

self-hosted フリートでは、ピーク負荷に合わせてサイジングすると、ほとんどの runner がオフピーク時にアイドル状態でありながら課金され続けます。決してキューにならないように構築されたフリートは、定義上、ほとんどの時間その大部分がアイドル状態です - コアの無駄ではなく容量の無駄です。

なぜチームは過剰プロビジョニングするのか

それはリスク回避です。OOM になったりキューになったりする小さすぎる runner は目に見えて苦痛ですが、アイドル状態の余裕は dashboard 上では見えません。そのためチームは「念のため」に切り上げ、決して切り下げに戻しません。

どれだけのコストがかかるか

runner の容量やコア時間の半分が未使用なら、実際に行う作業に対して約 2 倍を支払っていることになります。継続的な CI の 1 年を通じて、その余裕はかなりの、完全に取り戻せる数字になります。

余裕を取り戻す

job をプロファイルして各 job を正しくサイジングし、固定のピークサイズのフリートの代わりにオートスケーリングを使い、ワークロードの変化に応じて定期的にサイズを見直しましょう。目標は、恒久的な安全マージンに支払うことなく、苦痛を避けるのに十分な容量を持つことです。

マネージド runner がジレンマを取り除く

マネージドプラットフォームはオートスケールし、需要に合わせてサイジングされたウォームプールを維持するため、アイドル容量を保有することなく、高速でキューにならない起動が得られます。Latchkey は正しくサイジングされたエフェメラルな runner を GitHub ホステッドより約 70% 低いコストで実行し、過剰プロビジョニングの無駄を節約に変えます。

重要なポイント

過剰プロビジョニングとは、job が使わない runner のサイズや容量に支払うことです。
サイズが大きすぎる runner は料金を無駄にし、大きすぎるフリートはアイドル容量を無駄にします。
無駄が見えず不足が苦痛であるため、チームは過剰プロビジョニングします。