CI におけるリザーブド対オンデマンドのコンピュートとは？モデルを選ぶ

リザーブドコンピュートはより低い料金で事前に容量にコミットし、オンデマンドコンピュートは完全な柔軟性を持ちながら使用分だけ支払いますが料金は高くなります。CI のワークロードはどちらにもぎこちなく収まります。

これら 2 つの料金モデルはクラウドインフラ由来ですが、特に self-hosted の runner において、CI のコスト判断に直接影響します。リザーブドは柔軟性を割引と引き換えにし、オンデマンドは割引を柔軟性と引き換えにします。CI のバースト的で予測不能な負荷は、この選択を本当に難しくしており、それがマネージド runner が存在する理由の一部です。

オンデマンドコンピュート

オンデマンドとは、使用している間だけ標準料金で容量に支払い、コミットメントがないことを意味します。CI のバースト的な性質に最適で - アイドル容量に支払うことは決してありません - ただし単位あたりの料金はモデルの中で最も高くなります。

リザーブドコンピュート

リザーブド（またはコミット型）コンピュートとは、より低い料金と引き換えに、一定期間にわたって一定レベルの容量にコミットすることを意味します。割引は本物ですが、使うか使わないかにかかわらずコミットメントに支払うため、安定した予測可能な負荷に適しています。

なぜ CI はどちらにもうまく収まらないのか

CI の負荷はスパイク的で予測不能です。静かな夜もあれば、忙しいリリース日もあります。オンデマンドはスパイクに対応しますが単位あたりのコストが高く、リザーブドは単位あたりでは安いものの、静かな期間中もコミット済みの容量に支払い続けることになります。どちらもきれいな適合ではありません。

spot / プリエンプティブルという選択肢

spot インスタンスは余剰容量に対して大幅な割引を提供しますが、job の途中で回収されることがあります。CI にとってそれは、安い分数と引き換えに、中断されて二重に課金される job のリスクを意味します - プラットフォームがプリエンプションを透過的に自己修復しない限りは。

モデルを組み合わせる

コスト最適な答えは通常、組み合わせです。安定した負荷には小さなリザーブドまたはウォームなベースライン、スパイクにはオンデマンドまたは spot を使います。その組み合わせを self-hosted の runner で手動で管理するのは、実際の運用作業です。

マネージド runner が組み合わせを行う

マネージドプラットフォームはコンピュートのミックスをあなたのために最適化します - ウォームなベースラインに加えて弾力的な容量、多くの場合は自己修復を伴う spot を使って中断を吸収します。Latchkey はこの組み合わせによる効率性を、GitHub ホステッドのオンデマンド料金より約 70% 低いコストで、予約を管理することなく提供します。

重要なポイント

オンデマンドはより高い料金で使用分だけ支払い、リザーブドはコミットメントに対して割引します。
CI のバースト的な負荷は、どちらのモデルにも単独ではきれいに収まりません。
spot コンピュートは最も安価ですが、回収されて二重に課金される job のリスクがあります。