GitHub Actionsの同一コンカレンシーグループでは、実行中のワークフローと待機中のワークフローをそれぞれ1件に制限でき、新しい待機が以前の待機を置き換える場合があります。公式のコンカレンシー仕様が示すとおり、キューが見えたからといって、すぐにMac Runnerが足りないとは限りません。全チーム共通の必要台数はありません。実際の同時実行数、待ち時間、Runner占有時間を記録し、許容する待ち時間から並列枠を見積もって、少数の追加枠で効果を確かめてください。
個人開発者には、単発の遅延と継続的な容量不足を見分ける方法を。
小規模チームには、メンバー数ではなく作業の重なりから必要枠を考える方法を。
複数リポジトリの担当者やプラットフォーム責任者には、共有Runnerの配分と増設後の確認手順を紹介します。
個人開発者は一時的な混雑と継続的な不足を分ける
個人プロジェクトでは、リリース前や複数ブランチの更新が重なった時だけキューが伸びることがあります。一度の遅延を根拠にRunnerを増やすのではなく、普段の変更と負荷が高い期間の両方で、ワークフローの起動時刻、実行開始時刻、終了時刻、選ばれたRunnerを記録します。
GitHubのワークフロージョブAPIでは、ジョブの状態や開始・完了時刻、Runner名、ラベルなどを確認できます。ジョブ情報のAPI項目を使えば、「待った時間」と「Runnerを使っていた時間」を分けて集計できます。平均だけでなく、待ちが集中する時間帯や、特定のワークフローだけが遅れていないかも確認してください。
待ち時間からiOS Runnerの必要数をどう見積もるか。
記録した起動時刻と実行時間を使い、目標時間帯に同時に走るジョブ数と、許容できる待ち時間を照らし合わせます。すぐに開始させたいジョブが重なるなら、その重なりを処理できる並列枠が必要です。一方、待ち時間を許容できるなら、最大同時実行数をそのまま常設容量にせず、過去のジョブ順序を候補枠数で再生して、待ち時間が目標内に収まるかを比べます。
小規模チームは待ち時間を容量の判断材料にする
チームの人数をRunner数に置き換える方法は適切ではありません。メンバー全員が同時にビルドを開始するとは限らず、レビュー用のテスト、マージ後のビルド、リリース作業では、起動頻度やRunnerを占有する長さが異なるためです。
まず、コミットやマージが重なる時間帯について、ワークフローごとの起動数、キュー時間、実行時間を集計します。平均的な日と負荷の高い日を分け、許容する待ち時間をチームで定めてください。GitHub Actionsのワークフロー構文には、マトリックスジョブの同時実行数を制御するmax-parallelがあります。ワークフロー構文の設定項目も確認し、Runner不足とワークフロー側の並列制限を混同しないようにします。
| 対象 | まず記録する内容 | 容量を増やす判断 |
|---|---|---|
| 個人プロジェクト | 起動時刻、待ち時間、ジョブ占有時間 | 一時的な集中か、複数の期間で続く不足かを比較 |
| 小規模チーム | マージやリリース時の同時実行数、許容待ち時間 | 待ち時間の目標を超える時間帯が繰り返されるかを確認 |
| 複数リポジトリ | ジョブ種別、プロジェクト、Runnerの振り分け | 共有枠で処理するか、特定プロジェクト用の枠を分けるかを検討 |
平均ワークフロー数とピーク並列数のどちらを基準にするか。
平均値は通常の負荷を把握する材料ですが、リリース時の集中を隠すことがあります。ピーク値だけで常時の枠を決めると、使われない容量を抱えやすくなるため、「どの待ち時間まで許容するか」を先に置き、通常時と高負荷時の両方で候補を比べます。
複数リポジトリはジョブの性質とルーティングで分ける
共有Runnerプールは、空いている実行枠を複数プロジェクトで使いやすい一方、重要なリリース処理がテストジョブに押される構成では、待ち時間の予測が難しくなります。単体テスト、完全なビルド、リリース処理を分けて、実行時間、起動頻度、遅延の影響を記録してください。
GitHubのRunnerグループは、組織内でRunnerへのアクセスと振り分けを管理する仕組みです。Runnerグループの公式説明を参照し、リポジトリやワークフローの利用範囲を整理します。ジョブ側のRunner選択ではグループやラベルが使われるため、セルフホストRunnerの選択ルールと合わせて、想定したジョブが対象のMacに届くかを確かめます。
複数のiOSリポジトリにmacOS CIの並列枠をどう割り当てるか。
遅延が許容しにくいリリースジョブは専用のルーティングを検討し、待ち時間を許容できるテストは共有枠にまとめる方法があります。ただし、分離した枠が常に有利とは限りません。空き容量を融通できるか、優先度の異なるジョブが互いに待たせないかを、記録した負荷と運用要件に基づいて判断します。GitHubの説明にないプラットフォーム配額を前提にせず、利用する環境の公式条件を別途確認してください。
容量の見積もりと増設後の検証
見積もりでは、ワークフローの到着頻度、Runner占有時間、目標時間帯の同時実行数、許容待ち時間を一緒に扱います。単純化した目安として、同時実行の必要枠は「目標時間帯に重なる対象ジョブ数」を軸にし、待ちを許容する場合は実際の起動順と実行時間を候補の枠数で再現して比較します。これは計画のための推定であり、GitHubやRunnerが保証する容量ではありません。
APIやRunnerの記録から開始・完了時刻などを集める方法は、セルフホストRunnerの監視・トラブルシューティング資料も参照できます。サンプル期間にリリース集中が含まれるか、失敗したジョブや再実行をどう扱うか、キャッシュのヒット状況が変わっていないかを記録に添えます。キャッシュ状態が違うビルドを同じ占有時間として扱うと、必要枠の推定がぶれるためです。
キューの原因がRunner不足か、ビルド手順にあるかをどう見分けるか。
待ち時間が長く、Runnerが空いていない時間帯と重なるなら、実行枠の不足が候補です。Runnerが空いているのに開始しない場合は、グループやラベルの不一致、依存ジョブ、ワークフローの同時実行制御を確認します。開始後の処理が長い場合は、ビルド工程やキャッシュを調べ、Runnerを追加する前にボトルネックを切り分けます。
以下の項目を埋めてから追加容量を試すと、拡張の効果を比較しやすくなります。
- [ ] 代表的な通常期間と高負荷期間を選び、対象ワークフローの起動時刻を記録した
- [ ] キュー時間とRunner占有時間を別々に集計した
- [ ] 単体テスト、完全なビルド、リリース処理を分けて確認した
- [ ] 許容待ち時間と、優先度の高いジョブを明文化した
- [ ] Runnerグループ、ラベル、ワークフローの並列制御を確認した
- [ ] 少数の並列枠を試し、待ち時間、利用状況、失敗の変化を比較する計画を立てた
追加後に待ち時間が変わらなければ、すぐにさらにMacを増やすのではなく、対象ジョブが追加枠へルーティングされているか、直列の依存関係やワークフロー制限が残っていないかを調べます。モデルAPIの利用料とMacのビルド実行資源は別の費用項目として管理し、同じ容量見積もりに混ぜないことも重要です。
自前のActionsデータで必要な並列枠を見積もった後、長期の安定稼働や物理接続が必要なら、自社保有のMacを含めて比較するのが適切です。反対に、検証期間だけRunnerを増やしたい場合は、常設設備の調達・保守を抱えるより、実際に利用可能な構成や提供条件を確認してから選べるリモートMacのレンタルが候補になります。利用前に接続方法や運用上の確認事項を整理する場合は、Zutcloudのヘルプセンターも参照できます。必要容量を実機に当てはめる段階では、ZutcloudのMac miniレンタル情報で掲載内容を確認し、計測したワークフロー要件と照合してください。
関連記事
iOSビルドの待ち時間を、Zutcloudの専用Mac miniで見直しませんか？
実機の専用Mac miniを利用でき、並列ビルド用の環境をチームの需要に合わせて確保できます。
標準構成から高メモリ構成まで選べるため、ビルド量や同時実行数に応じた導入が可能です。 今すぐ申し込む