CI の分単位課金とは？切り上げ・単価・実コスト

分単位課金とは、job が消費する runner 時間の 1 分ごとに CI の料金を支払うことを意味し、ほぼ常に次の 1 分単位に切り上げられます。

分単位課金はホスト型 CI で支配的な料金モデルです。単純に聞こえますが、その詳細 - 切り上げ、OS 乗数、同時実行 - が、パイプラインが安いか高いかを決めます。何がメーターを回すのかを正確に知ることで、内容を減らさずにコストが下がるパイプラインを設計できます。

メーターの動き方

時計は job が runner 上で実行を開始した時に始まり、終了時に止まります。実際に使った core の数に関係なく、その実時間の長さで課金されます。9 分 5 秒の job は、典型的な job ごとの切り上げでは 10 分として課金されます。

切り上げ税

各 job は独立して切り上げられるため、作業を多数の小さな job に分割すると切り上げが倍増します。10 秒の matrix の脚が 50 本あれば、50 分の丸 1 分として課金され得ます。些細な job を統合することは、分単位課金を削る最も簡単な方法の 1 つです。

サイズと OS による単価

1 分あたりの単価はマシンサイズと OS でスケールします。GitHub ホストの Linux 2-core は約 $0.008/分、4-core は約 $0.016、8-core は約 $0.032 です。Windows は Linux の約 2 倍、macOS は約 10 倍なので、同じ 1 分でも固定価格からは程遠いのです。

同時実行と並列化

job を並列に実行しても課金される総分数は減りません - 各 1 分の job 10 本は、直列でも同時でも 10 分かかります。並列化は実時間の速度を買うのであって、コストを下げるわけではありません。総作業量を減らすことが請求額を下げます。

支払っても恩恵のない分

毎回依存関係を再インストールする cold start の setup。
一度成功した作業を再課金する flaky な再実行。
過大な runner の遊休の余裕分。

1 分あたりのコストを下げる

各 job を速くし（caching、適切なサイズ化）、無駄な分を減らします（flaky な再実行をなくす、小さな job を統合する）。基本単価が低ければあらゆる節約が積み重なります - Latchkey のマネージド runner は同じ分を約 70% 安く課金し、cold start の分を削る warm pool と、flaky な job に 2 回支払うのを防ぐ自己修復を備えます。

重要なポイント

分単位課金は runner の実時間に対して、job ごとに切り上げて課金します。
多数の小さな job は重い切り上げ税を招きます - 可能なら統合しましょう。
並列化は速度を買うのであって、総分数を減らすわけではありません。