runnerの並行性とは？同時に何個のjobが動くか

runnerの並行性は、CIが同時に実行できるjobの数です - jobのバーストが並列で動くか、キューに積み上がるかを決める上限です。

10個のjobが一度にトリガーされたとき、並行性はいくつが即座に動きいくつが待つかを決めます。並行性が少なすぎるとチームはキューに並び、固定の並行性が多すぎるとアイドル容量に支払うことになります。正解は弾力的であることです。

何が制限を決めるか

並行性は、利用可能なrunnerの数（フリートのサイズやプランの上限）と、設定したworkflowごと・組織ごとの上限によって制約されます。実効的な上限はこれらのうち最も小さいものです。

並行性とキュー

トリガーされたjobの数が並行性を超えると、余剰がキューに入ります。ピーク時に頻繁にキューされたjobを目にするチームは、jobごとのパフォーマンス問題ではなく、並行性の上限に達しています。

サイジングのトレードオフ

• 固定・高い並行性: キューは出ないが、アイドル容量が金を食う。
• 固定・低い並行性: アイドル時は安いが、ピークでは苦しい。
• 弾力的な並行性: autoscalingが需要に応じて上限を広げる。

弾力的な並行性

最良の答えは需要に応じてスケールする並行性です。autoscalingがバースト時にrunnerを追加しアイドル時に取り除くので、ピークのスループットをオフピークに支払うことなく得られます。マネージドプラットフォームはこの弾力性を標準で提供します。

workflowレベルの並行性制御

フリートの容量とは別に、GitHub Actionsには同じworkflowの重複した実行を直列化またはキャンセルするconcurrencyキーがあります - 二重に実行したくないデプロイに便利です。これは容量のツールではなく調整のツールであり、両者を混同すべきではありません。

重要なポイント

• runnerの並行性は同時に実行されるjobの数です。
• フリートのサイズと設定した上限によって制約されます。
• 制限を超えると余剰のjobはキューに押し込まれます。
• 弾力的でautoscaledな並行性は、あらゆる固定上限に勝ります。

関連ガイド