CI 分（CI minute）とは？ CI 請求額を左右する単位

CI 分とは、runner があなたの job の 1 つを実行するのに費やす 1 分間の実時間（wall-clock）です。ほぼすべての CI プロバイダーが計測し課金する単位です。

CI の「分」と言うとき、それは課金対象の runner 時間を意味します。パイプラインが実行するすべての job は、runner があなたの step を開始した瞬間から終了するまで分を消費します。パイプラインはあらゆる push と pull request で実行されるため、これらの分はすぐに積み重なります。だからこそ CI 請求額を気にするなら、CI 分は理解すべき最も重要な単位なのです。

何が 1 分としてカウントされるか

CI 分は、あなたの job が実行されている間の runner 上の実時間です - checkout、依存関係のインストール、build、テスト、deploy。CPU 時間でも開発者の時間でもなく、マシンがあなたのために稼働している時間です。job が 7 分 10 秒かかった場合、それを実行したマシン上のその経過時間で課金されます。

切り上げと最小単位

ほとんどのプロバイダーは各 job を次の 1 分単位に切り上げるため、12 秒の job でも丸 1 分分かかります。50 個の小さな job から成る fan-out の matrix を実行すると、切り上げだけで実際に支払う compute が倍になることもあります。この切り上げ税のため、多数の些細な job よりも、少数のやや大きな job の方が安くつくことがよくあります。

分がどのように金額になるか

GitHub ホストの Linux 2-core runner は 1 分あたり約 $0.008 で、月 100,000 分はより大きな runner や OS の乗数を適用する前でおよそ $800 になります。表面上の単価はごくわずかに見えますが、忙しいチームでは 1 日に何千回も分が消費され、請求額は単に単価にカウントを掛けたものです。

分はすべて同じではない

Windows runner の 1 分は通常 Linux の 1 分の約 2 倍、macOS の 1 分は約 10 倍かかります。同じ workflow でも、どの runner の OS とサイズに割り当てられるかによってコストは大きく変わります。したがって、1 分あたりの単価を伴わない「使用した分数」は物語の半分しか語りません。

分が無駄になる場所

cache を復元する代わりに毎回依存関係を再ダウンロードする cold start。
完全な再実行を強制し、同じ作業に 2 回課金される flaky なテスト。
「念のため」に予約され、遊休の余裕分にプレミアム料金を課す過大な runner。
一部のプラットフォームでの、空き runner を待つ間も課金されるキュー時間。

より少ない分で済ませる

分を削る方法は 2 つあります: 各 job を速くする（caching、適切なサイズの runner、冗長な step の削減）ことと、不要だった分の支払いをやめる（flaky な再実行をなくす、過大なマシンを外す）ことです。1 分あたりの単価が安ければ、その効果が倍増します - Latchkey のマネージド runner は同じ job を GitHub ホストより約 70% 安く実行し、warm pool と自己修復がその上で無駄な分を削減します。

重要なポイント

CI 分は job ごとの課金対象となる runner の実時間 1 分です。
job は通常 1 分単位で切り上げられるため、小さな job が多いと無駄が生じます。
分は OS とサイズによって金額が異なります: Windows は Linux の約 2 倍、macOS は約 10 倍。