アイドルrunnerコストとは? 何もしないマシンに支払う
アイドルrunnerコストとは、稼働しているが有用な仕事をしていないrunner容量 - プロビジョニング済み、起動中、待機中、または過大 - に支払うものです。
アイドルコストは厄介です。マシンが価値を生んでいないときでも、請求書上では忙しく見えるからです。hostedとself-hostedのrunnerで現れ方は異なりますが、どちらにせよ成果ではなく容量に費やされたお金です。アイドルコストがどこに隠れるかを理解することが、無駄のないCI請求の鍵です。
hosted runnerでのアイドル
分単位のhosted runnerでは、アイドルコストは、有用な仕事が始まる前のコールドスタートの起動時間とセットアップ、加えてコアが未使用のまま座っている過大なマシンとして現れます。buildがほとんど働いていなくても、その間ずっと分単位のレートを支払います。
self-hosted runnerでのアイドル
jobを待ってオンラインのままのself-hosted runnerは、忙しくても暇でも、その間ずっとお金がかかります。ピーク負荷に合わせてサイズを決めたfleetは、オフピークではほとんどアイドルで、利用率に関係なく24時間365日クラウドインスタンスの請求を支払います。
warm poolとコールドなアイドル
素朴なwarm poolは、コールドスタートを避けるためにマシンを稼働させ続け、アイドルコストと引き換えに速度を得ます。うまく設計されたmanaged warm poolは、ちょうど十分な容量だけを準備しておき、残りをリサイクルします。大きなアイドルfleetの対価を払うことなく、速度の恩恵を捕捉するのです。
アイドルコストとしての過剰プロビジョニング
2コアで済むjobに8コアrunnerを予約すると、6コアが実質的にアイドルとなり、より大きなrunnerの割増料金で課金されます。適正サイズ化は、そのアイドルな余裕を節約へと戻します。
アイドルの計測
self-hosted fleetでは利用率 - 忙しいminuteをプロビジョニングされたminuteで割ったもの - を追跡します。低い利用率は直接のアイドルコストです。hosted runnerでは、アイドルな無駄の代理指標として、コールドスタート時間とrunnerサイズのフィットを注視します。
アイドルコストの排除
managed runnerは、アイドルの問題をプロバイダーへ移します。Latchkeyは需要に合わせてサイズを決めた自己管理型のwarm poolを運用するため、アイドルのままのfleetの対価を払うことなく高速な起動が得られます。しかも基礎となるレートは、GitHub-hostedよりおよそ70%低いのです。
重要なポイント
- アイドルrunnerコストとは、有用な仕事をしていない容量に支払うことです。
- hosted:コールドスタートと過大なコア。self-hosted:常時稼働のfleet。
- 過剰なプロビジョニングは、割増料金で課金されるアイドルコストです。