Argo Workflows の並列実行数周りの整理

Argo の並列実行数は1つの数字では決まらない

絞り込みの順番

code:_

① 構造 DAG/steps の依存 + fan-out(withItems等)

└→ 「同時に実行可能なノード数」が決まる（出発点）

↓ 絞る

② template.parallelism / spec.parallelism（1 Workflow 内の上限）

↓ 絞る

③ synchronization (semaphore/mutex) (Workflowを横断した上限)

↓ 絞る

④ controller の workflow-parallelism / namespace-parallelism（ワークフロー本数）

↓ 絞る

⑤ Kubernetes のリソース・スケジューリング（現実の枠）

実際に使う時は、2方向で気にしたくなる

上限を決める方向

スペックの問題で、同時に動かすのは10個までに制限したい

parallelismとsynchronizationは上限を制限するもの

増やす方向

速く終わらせたいので100個並列に動かしたい

① DAGとかの種類によって決まる

DAG Templateは依存がないタスク、依存が満たされたタスクは同時にスケジュールされる

code:yaml

- name: dag-example

dag:

tasks:

- name: A # 依存なし → すぐ走る

- name: B # 依存なし → すぐ走る

- name: C # 依存なし → すぐ走る

- name: D

dependencies: A, B, C # A,B,C完了後に走る

Steps Templateは-で並べたものは並列になる

code:yaml

- name: steps-example

steps:

- - name: step1a # この2つは並列

- name: step1b

- - name: step2 # step1a/b 完了後に直列で実行

loop

withItems (argo), withParam (argo), withSequence (argo) は

1つのテンプレート呼び出しを items の数だけ並列に展開する

code:yaml

- name: fan-out

steps:

- - name: process

template: worker

withItems: a, b, c, d, e # → 5個のpodが同時に生まれようとする

② spec.parallelismやtemplate.parallelismで1つのWorkflow内での上限が決まる

parallelism はそのスコープ内で同時にRunningできるpod/ノード数を制限する

なので spec.parallelism: 10 の Workflow を3本起動すると原理上 30 pod 動きうる

code:yaml

spec:

parallelism: 10 # (A) ワークフロー全体で同時10ノードまで

templates:

- name: my-dag

parallelism: 3 # (B) このテンプレート（DAG/steps）配下で同時3まで

dag: ...

(A) spec.parallelism

そのワークフロー全体での同時実行ノード数の上限

(B) template.parallelism

DAG/steps テンプレート単位の上限

ネストした子のループ展開を抑えるのによく使う

例えば 1 の fan-out で 100 個展開されても、

parallelism: 10 を置けば同時に走るのは10個までで、残りは待ちになる

③ spec.synchronizationやtemplate.synchronizationで Workflowを横断した並列実行数の上限が決まる

ちなみに、Workflowの実行数を増やすなら何発も起動すれば良い

例えば、Workflow A を連打したとき

spec.synchronizationをNにすると、同時に走るのは N 本までで、N+1 本目は待ちになる

templateも同じで、Workflowを横断した全体での上限数になる

template.synchronizationはWorkflow毎ではなくグローバルな並列上限数

実際は、③は②と独立に評価され、より厳しい方が適用される

④ コントローラ全体の制限（クラスタ運用者が決める）

ワークフローのYAMLではなく、Workflow Controller (argo) の起動引数 / ConfigMap で決まる

複数のワークフローをまたいだ全体の上限

--workflow-parallelism（旧 --parallelism）

コントローラが同時にRunning状態にできるワークフロー総数

--namespace-parallelism

namespace あたりの同時ワークフロー数

これは「1ワークフロー内の並列pod数」ではなく「走らせるワークフローの本数」の制限

⑤ 最終的に実際に走る数はKubernetesスケジューラで決まる

①〜④で「Argoがスケジュールしたい数」が決まるが、最後にKubernetes側のリソース（ノードのCPU/メモリ、ResourceQuota、podが乗れるかどうか）で実際の同時起動数が決まる

Argoが100pod投げても、クラスタに枠がなければPendingで待つ