CIにおけるコンピュートコストとは？ pipeline請求の中核

CIにおけるコンピュートコストは、コードをbuildおよびテストするrunnerの処理時間に対して支払うものであり、通常はCI請求における最大の単一項目です。

CIが課金するあらゆるものの中で、コンピュートが支配的なものです。すべてのbuild、テスト、deployはマシンを占有し、そのマシンの時間が計測されます。コンピュートコストを押し上げるもの - 実行時間、runnerのサイズ、jobの実行頻度 - を理解することが、CI支出全体をコントロールする土台となります。

コンピュートコストの計算方法

コンピュートコストは、runner時間のminuteに、そのマシンのサイズとOSに対する分単位のレートを掛けたものです。$0.008/minのLinux 2コアrunnerでの10分のjobは$0.08です。同じjobを8コアrunnerで実行すると、分あたりでその4倍になります。

実行時間が最大のレバー

コストは実行時間に比例するため、jobを短くするものはすべてコンピュートコストを直接下げます。依存関係のcaching、変更のない作業のスキップ、クリティカルパスの並列化は、いずれも課金されるminuteを減らします。

runnerのサイズと適切なフィット

大きなrunnerは分あたりのコストが高いものの、より速く終わりうります。最も安い選択肢は、jobのボトルネックにならない最小のrunnerです。過剰なプロビジョニングはアイドルなコアに割増料金を払い、過少なプロビジョニングは余分なminuteで支払うことになります。

頻度がすべてを掛け算する

多忙なチーム全体で、すべてのpush、PR、mergeで実行されるpipelineは、月に数千回動きます。実行ごとの小さなコンピュートコストが、純粋に頻度によって大きな月額になります。だからこそ、実行ごとの節約が非常に大きく積み上がるのです。

支払っているのに無駄になるコンピュート

cacheされずに実行ごとに繰り返されるコールドスタートのセットアップ。
すでに成功した作業を再課金するflakyな再実行。
冗長なmatrixのレッグと、フィルタリングされていないトリガー。

コンピュートコストを削る

jobを短くし、runnerを適正サイズにし、安全なところでは実行頻度を減らします。それからレート自体を攻めます。Latchkeyのmanaged runnerは、同じコンピュートをGitHub-hostedよりおよそ70%安く提供し、コールドスタートのコンピュートを取り除くwarm poolと、flakyなjobの再課金を防ぐ自己修復を備えています。

重要なポイント

コンピュートコスト = runnerのminute × 分単位のレート。通常はCI請求を支配します。
実行時間が最大のレバーです。jobが短ければ、実行ごとのコストが下がります。
頻度は、実行ごとのコストを大きな月額へと掛け算します。