1本で311秒かかる作業を30本に分けると26秒で終わりました。12倍速い計算です。
同じ条件で請求は6.00倍になります。速さと費用が逆向きに動きます。
本数ぶんの準備と切り上げが乗ります。速さを買うと、そのまま費用に出ます。
GitHub Actionsでは、仕事ごとに動かす機械が割り当てられます。公式はそれぞれが実行機の上で動き、1つ以上の手順を順に走らせると述べています。
1つ動かすたびに準備がかかります。分ける本数でどう変わるのか実際に数えて比べました。
1回ぶんの実作業 300秒。準備に1つあたり 12秒かかる 20,000 回ぶんを、いくつに分けるかを変えて数える。請求は1分単位の切り上げ 分け方 実作業の合計 準備の合計 請求される分 実作業との比 並べたときの所要 1個に分ける 99,813分 4,000分 113,794分 1.14倍 311秒 2個に分ける 100,032分 8,000分 128,021分 1.28倍 182秒 4個に分ける 100,135分 16,000分 156,016分 1.56倍 105秒 10個に分ける 99,981分 40,000分 200,000分 2.00倍 52秒 30個に分ける 99,996分 120,000分 600,000分 6.00倍 26秒
所要は311秒から26秒まで縮みます。待ち時間としては12倍の改善です。
同じとき請求は1.14倍から6.00倍になります。実作業の合計は変わっていません。
増えるのは準備と切り上げです。準備は4,000分から120,000分へ、本数に比例して増えます。
切り上げも効きます。1本10秒でも1分として数えられるので、短く分けるほど無駄が増えます。
似た形の判断はCI/CDの記事でも扱っていて、待ち時間を短くする施策には必ず費用側の裏返しがあります。
所要は12分の1になるが、請求は6倍になる。
each of which will execute on a runner machine and run a series of one or more steps原文GitHub Docs「Workflows」 この内容の有効期限2027-02-18
仕事には順序があります。つながった一本道より短くはならず、そこで頭打ちになります。
GitHub Actionsの手順は、複数の仕事をまとめたものです。公式は手順とは、1つ以上の仕事を動かす、設定できる自動の処理であると述べています。
仕事の間には順序があります。同時に動かす数を増やすとどこで止まるのか実際に割り当てて数えました。
処理 60個。合計の作業時間 891分、依存をたどった最長の道のり 275分 依存が終わった処理から、空いている担当に割り当てる 同時に動かす数 全体の終了まで 1担当あたりの稼働率 1つ前からの短縮 1個 891分 100.0% — 2個 455分 97.8% 436分 4個 275分 81.0% 180分 8個 275分 40.5% 0分 16個 275分 20.3% 0分 32個 275分 10.1% 0分
4個で275分に届き、そこから先は0分です。8個にしても16個にしても変わりません。
稼働率だけが下がります。32個では10.1%で、9割は待っているだけになります。
275分は、依存をたどったいちばん長い一本道です。ここが下限になります。
だから頭打ちのあとで効くのは、同時に動かす数ではありません。その一本道の中身を減らすか、依存を外すかのどちらかです。
前の節の分割は、この一本道を短くする手にあたります。ただし請求は本数ぶん増えます。
A workflow is a configurable automated process that will run one or more jobs.原文GitHub Docs「Workflows」 この内容の有効期限2027-02-18
変更のたびに動きます。普段は軽くても、下のほうを触ったときだけ全部が作り直しになります。
GitHub Actionsの手順は、変更のたびに動きます。公式は手順はリポジトリに置かれたYAMLで定められ、リポジトリでの出来事に反応して動く。手動でも、決めた時刻でも動かせると述べています。
毎回どれだけ作り直すのか。1つずつ変えて全部試して数えました。
記述の単位 300個。1単位を作り直すのに 8ms かかる 1つ変えたとき、それを使っている側をすべて作り直す やり方 作り直す単位 かかる時間 全部作り直す 300個 2.40秒 使っている側だけ（中央値） 3個 0.02秒 使っている側だけ（平均） 21.9個 0.18秒 使っている側だけ（99%点） 282個 2.26秒
半分の変更では3個しか作り直しません。全部作り直す2.40秒に対して0.02秒です。
ところが99%点は282個で、2.26秒かかります。全部作り直すのとほぼ同じです。
平均は21.9個ですが、中央値は3個です。この2つが10倍近く離れているとき、平均は実感と合いません。
計画に使うなら99%点です。共通の部分を触った日は、毎回いちばん遅い場合に当たります。
3つの計測はいずれも手元で書いた模型で、実際のGitHub Actionsを動かしたものではありません。準備12秒や1分単位の切り上げは置いた値で、実際の課金の仕様とは別です。処理60個の依存関係も生成したもので、道のりの長さは構成によって変わります。作り直しの計測も、依存の形しだいで中央値と99%点の開きが変わります。ここで見せているのは、分けると速くなるが請求は本数ぶん増えるという点と、同時に動かす数には効かなくなる境目があるという点の2つです。
Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.原文GitHub Docs「Workflows」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る