実行待ちが増え、ワークフローの処理中にほかの実行まで滞るようになったら、まず待ち行列と実行記録、CPU・メモリーの推移を確認します。
判断：実行処理をメインプロセスから分ける必要がある場合はキューモードを検討します。ただし、単一ワークフローが自動的に速くなる仕組みではなく、すべての単一インスタンスに必要な変更でもありません。
単一インスタンスで実行待ちや処理の競合が見え始めた開発者は、移行条件を確認できます。
AI関連の処理とほかの自動化を並行させたい小規模チームは、メインプロセス、Worker、Redisの役割を整理できます。
Docker Composeとサーバーの構成を管理する担当者は、データ保存や復旧まで含めた導入手順を確認できます。
n8nキューモードの導入前判断
キューモードではメインプロセスがワークフロー実行の受付を行い、Workerが実行処理を担います。Redisは実行情報を受け渡すキューとして使われ、データベースはワークフローや実行に関する情報を保持します。サービスを分ける目的は、受付と実行の役割を分離することです。n8n公式のキューモード説明で、現在の構成要件を確認してください。
「待ち行列ができる」「1つの処理が遅い」「サーバーの資源が不足している」は、似て見えても原因が異なります。キューモードで改善の可能性があるのは、実行処理をWorker側に分離して並行処理の構成を整えたい場合です。外部サービスの応答待ちや、ワークフロー内部の処理自体が遅い問題には、分離だけでは効果が出ないことがあります。
n8nの単一インスタンスから切り替える目安は何ですか。
一時的な処理集中ではなく、実行待ちが繰り返し発生し、実行履歴にも失敗や遅延が残っているかを確認します。同じ期間のCPU・メモリー使用傾向も記録し、処理待ちが実行資源の競合によるものか、外部依存やワークフロー設計によるものかを切り分けてから判断します。
次のチェックリストで移行の要否を判断します。
- [ ] 実行待ちや遅延が繰り返し発生し、実行記録にも負荷の兆候がある。受付と実行を分ける理由が明確なら、検証環境でキューモードを試します。
- [ ] 遅いのは特定のワークフローだけである。外部接続やワークフロー内部の待ち時間を先に調べ、原因が残る間は単一インスタンスを維持します。
- [ ] CPUやメモリーの不足が続いている。Workerを増やす前に、データベース、Redis、ホスト全体の負荷を確認します。
- [ ] 実行待ちは一時的で、継続的な失敗や資源競合は見られない。キューモードへの移行は急がず、記録を続けます。
移行前の記録と互換性確認
最初に、現行のn8nバージョン、起動方法、データベースの種類、データ保存先、環境変数を記録します。設定ファイルだけでなく、暗号化キーの保管場所も確認してください。Workerを別サービスとして起動するときも、メインプロセスと同じキーを使える状態にしておく必要があります。
データベースは全インスタンスから一貫して利用できる構成にします。SQLiteを使っている場合は、キューモードでそのまま使えるとは考えず、キューモードの要件と対応データベースの設定を照合し、移行方法を先に決めます。DB接続情報や暗号化キーがサービスごとに食い違うと、Workerが期待どおりに実行できない原因になります。
キューモードでファイルシステムにバイナリデータを保存できますか。
ファイルシステムを使うバイナリデータ保存は、キューモードと互換性がないと公式文書に記載されています。実行データにファイルを含む場合は、バイナリデータ保存の対応条件を確認し、利用する保存方式が現在の構成と契約条件に適合するか、移行前に判断してください。
Docker Composeでサービスを分ける
Composeファイルでは、メインプロセス、Worker、Redis、対応するデータベースの役割を分けて記述します。メインプロセスは受付、Workerは実行、Redisはキュー、データベースは永続データを担当します。各サービスが同じComposeネットワーク上で名前解決できることと、必要な保存領域が再起動後も維持されることを確認します。
設定の軸になるのは、EXECUTIONS_MODE=queue、Redis接続用のQUEUE_BULL_REDIS_HOST、および全インスタンスで一致させるN8N_ENCRYPTION_KEYです。これらの名称と値の指定方法は、キューモード用環境変数の公式一覧を参照し、使用するバージョンに合う形で設定してください。データベース接続の環境変数も同様にそろえ、秘密情報を不用意にComposeファイルへ直書きしない運用にします。
n8nのメインプロセスとWorkerはどう接続しますか。
メインプロセスとWorkerが同じRedisとデータベースを利用し、同じ暗号化キーと互換性のある設定で動作するようにします。Worker側だけに異なるホスト名やキーを設定すると、キューから処理を受け取れない、または保存データを正しく扱えないことがあります。Compose上のサービス名、環境変数、ネットワーク、保存先を並べて照合してください。
Workerの並列数や同時実行制御は、処理内容を見ずに大きくしないでください。並行処理を増やすと、WorkerだけでなくDB、Redis、ホストのCPUやメモリーにも負荷がかかります。同時実行数の制御に関する公式説明を確認し、まず小さな変更で実測します。Composeのサービス定義と永続化の基本は、公式のDocker Compose導入手順と照らし合わせてください。
起動後の動作確認
起動しただけで移行完了とは判断しません。以下の順序で、キューへの投入から結果の記録までを確認します。
- Redisへ接続できることを、メインプロセスとWorkerのログで確認します。
- Workerが起動し、メインプロセスと同じDB、Redis、暗号化キーの設定を使っていることを照合します。
- 再現可能なテスト用ワークフローを実行し、実行がキューに入り、Workerで処理されたことをログと管理画面の両方で確認します。
- 成功結果だけでなく、意図的に失敗するテストも行い、エラー内容と実行履歴が一致するかを確かめます。
待ち行列から実行が進まない場合、最初にWorkerの稼働状態、Redis接続、共有設定、エラーログを確認します。根拠がないままWorker数や並行数を増やすと、DBやホスト側の負荷を悪化させる可能性があります。Composeの設定を変更したときは、変更箇所と確認結果を記録しておくと、原因を戻って調べやすくなります。
負荷を観察して追加Workerを判断する
安定運用に入ったら、待ち行列の推移、実行開始までの待ち時間、失敗記録、CPU・メモリー・ディスクの使用傾向を同じ観察期間で記録します。短時間の集中と、平常時にも続く滞留を分けて見ることが重要です。実行が並列化できる場合はWorker追加を検討できますが、直列に依存する処理や外部APIの待ち時間には、Worker追加だけで改善しない場合があります。
キューモードへの変更は、単一処理そのものを速くする約束ではありません。処理時間が変わらない一方、同時実行によってDBやRedis、ディスクへの要求が増えることもあります。記録した負荷から、設定調整、Worker追加、サーバー資源の見直しのどれが必要かを選びます。
自ホスト環境では、共有型の仮想サーバーでCPUやメモリーの余裕が読みづらい場合や、保存領域を個別に計画しにくい場合もあります。ただし、負荷が軽く、実行待ちもほとんどないなら、専用サーバーへ移る必要はありません。まずはサーバー構成の選択肢を実際の提供内容と照らし、記録した負荷に対して独占リソースが必要かを判断してください。
バックアップとロールバックの準備
切り替え前に、DBとCompose設定、環境変数など復元に必要な情報を保全します。暗号化キーはDBのバックアップと分けて安全に保管し、復元時に参照できることも確認してください。同じサーバー内に複製を置くだけでは、ホスト障害に備えた別場所のバックアップにはなりません。データの取り扱い方針は、データ取り扱いに関する案内も確認できます。
旧構成へ戻す前には、切り替え後に新しい実行データが作られていないか、復元するDBと設定の組み合わせに矛盾がないかを確認します。キューに残った実行をどう扱うかも決め、移行前のバックアップを戻せば常に無損失で戻れるとは想定しないでください。バージョン更新後は環境変数、Worker、Task Runner、バイナリデータの条件を改めて検証します。
移行可否を決める際は、実際のn8n実行記録と資源推移を基準にしてください。共有型サーバーでは隣接する利用者の負荷やCPU資源の割り当てが影響し得るほか、保存領域や構成の自由度が要件に合わない場合もあります。実行負荷が継続し、独占した計算資源や明確なストレージ構成が必要なら、XFP Cloudの独立サーバーの実際の構成・OS選択肢を確認し、記録した要件と合うかを比較するのが現実的です。利用期間や請求条件も検討材料になるため、料金と請求方法を確認したうえで、負荷に見合う移行か判断してください。