n8nの処理が増えたら、workflow自体の無駄と、同時実行の待ち時間を分けて測ります。Queue modeでworkerを増やす方法はありますが、外部APIの上限や一件の重い処理まで自動で解消されるわけではありません。
遅い一件と、順番待ちの件数を分ける
一件の中で大きなファイルを変換しているなら、その処理のメモリやCPUを調べます。一件は短いのに着手まで待つなら、処理が集中する時間と同時実行を確認します。
測る時間
受付 → 実行開始:順番待ち
実行開始 → 最後のノード:処理時間
最後のノード → 保存完了:結果保持の時間
同時実行を増やす前に、同じ対象を二つの実行が更新してもよいかを決めます。処理が速くなっても、注文の状態が古い値へ戻るなら業務上は失敗です。
Queue modeでは、受付とworkerの役割が分かれる
Queue modeは、実行する仕事をキューへ渡し、workerが処理する構成です。DBやRedisなどの準備と、それぞれの接続設定を揃える必要があります。構築条件は公式Queue modeで確認してください。
Credentialsをworkerが扱うため、必要な暗号化キーなどの設定も一致させます。設定ファイルへ秘密を散らして複製するのではなく、配置と更新の手順を決めて管理します。
添付や生成物の置き場も、workerから読めるようにする
一台のローカルディスクへ置いたファイルを、別workerが同じように読めるとは限りません。Queue modeで対応するbinary保存方式と、自分の契約・版で利用できる外部ストレージを照合します。
| 増やす前の確認 | 止める条件 |
|---|---|
| DB・キューへ接続できる | workerごとに設定が違う |
| ファイルを取得・保存できる | 保存元の端末にしかファイルがない |
| 外部APIの許容量 | 並列化すると上限を超える |
| 更新するIDの排他 | 同じIDへ同時更新する |
少数のworkerで、停止と再開も確認する
処理時間、待ち件数、エラー率、メモリ、DBの負荷を記録し、実行中にworkerが停止したときの扱いも確認します。受付が成功したまま結果が消える構成では、workerを増やす前に状態管理を直す必要があります。
単に順番を管理したい場合は、Loopと待機で足りることもあります。まず遅さの場所を測り、運用できる範囲で構成を増やしてください。