GitHub Actions、10秒のジョブに付く1分の料金

要約

GitHubは各ジョブの端数時間を一分単位に切り上げる。六つのジョブが各10秒なら、合計実行時間は60秒でも課金上は六分になる。
現在の標準Linux・2コアx64の毎分0.006ドルを当てはめると、計算上の消費額は0.036ドル。一つの60秒ジョブなら0.006ドルで、差額は包含計算枠の消費や、その枠を使い切った後の支払いに効く。

一分は誰にとっても60秒だ。ただし、その60秒をGitHub Actionsで六つのジョブに分けたとき、料金の一分は六回登場できる。料金が数えるのは、ジョブごとに区切った時間だ。

ランナー料金表は、各ジョブが使った時間の端数を一分へ切り上げると定める。ワークフロー全体の秒数を最後に一度だけ丸める方式ではない。短い作業を独立したジョブにするたび、最低一分の箱を一つずつ買う形になる。

比較の条件を固定しよう。私有リポジトリで、同じ標準Linux・2コアx64ランナーを使う。六つのジョブがそれぞれ正確に10秒で完了する場合と、一つのジョブが正確に60秒で完了する場合を考える。どちらもランナー上の実行時間の合計は60秒だ。

前者は10秒をそれぞれ一分へ切り上げ、六分。後者は一分のまま。料金表の毎分0.006ドルなら、消費額は0.036ドルと0.006ドルになる。一回につき差は0.03ドル。これは公式ルールと仮定したジョブ時間による試算で、実際の作業をまとめた結果を測った数字ではない。

重要なのは「ジョブ時間」という条件だ。十秒のコマンドが走ったからといって、そのジョブ全体が十秒とは限らない。環境の準備や後処理を含め、実際に計測される時間で判断する必要がある。六つを一つにまとめた場合も、実行時間がきれいに60秒になる保証はない。まず値札の仕組みを分離して見るための比較である。

同じ丸め方では、61秒のジョブは二分、60秒なら一分になる。一秒縮めるだけで課金数量が半分になる境目がある。一方、11秒を10秒へ短縮しても、どちらも一分だ。節約した秒数と節約した料金は比例しない。

だから、最も速くなった処理が最も安くなるとは限らない。料金の境界に近いジョブを少し短くする方が、すでに十分短いジョブをさらに磨くより請求量に効くことがある。技術者が計測する秒と、購買が買う分の間には、階段がある。

もう一つの時計は、開発者が結果を待つ時間だ。六つを並行実行すれば待ち時間を短縮できる場合があるが、合計ランナー時間は各ジョブの時間を足したものになる。その後さらに、個別の切り上げが来る。画面上で早く終わったという一つの数字だけでは、三つの時計を説明できない。

現在の課金説明では、プランに含まれる計算資源枠を金額で表す。対象となるランナー利用やクラウドのサンドボックス計算・メモリーなどが同じ枠を消費し、対象利用の種類に優先順位はない。枠を使い切ると追加利用が請求され、課金周期の開始時に枠がリセットされる。

従って、六分という数量が毎回直ちに追加支払いになるわけではない。枠の中なら、まず他の対象用途に使えた金額を消費する。枠の外なら追加支払いになる。同じ資源消費でも、請求書に現れる時期が違う。

標準のGitHubホスト型ランナーを公開リポジトリで使う場合は、この計算枠とは独立して無料だ。大型ランナーは公開リポジトリでも有料となる。今回の数字は私有リポジトリと指定した標準ランナーの話であり、料金区分を揃えてから比較すべきだ。

Actionsの構成説明によると、一つのジョブ内のステップは同じランナーで動く。別ジョブはそれぞれの実行環境を持ち、依存関係のないジョブは標準で並行して動く。現在の機能では一部のステップを同じジョブ内で並行実行することもできるため、並行処理をすべてジョブ分割と同一視はできない。

別OSでの検証、環境の分離、障害の切り分け、早い結果返却は、それぞれの箱を買う理由になる。安い丸め方だけを求めて必要なテストを削れば、買う成果まで変わってしまう。

実行時間の表示方法は、ジョブの実行時間と課金分数を確認する入口になる。そこからランナーの区分と現在の単価をつなぎ、利用明細まで追う。実際の購入判断には各ジョブの時間、同じ検証結果、完了までの待ち時間、再実行と包含枠の利用状況が要る。

費用を負担するのは実行を開始した個人ではなく、リポジトリの所有者だ。一方、何個のジョブを作るかは作業を設計する側が選ぶ。小さな技術的な区切りが、別の部署の購入単位になる。短い仕事だから安い、と安心する前に、会社がいくつの最低料金を買ったかを数えたい。