작업 대기가 쌓이지만 어떤 실행 단계가 병목인지 불분명하다면, 무조건 Worker부터 늘리지 않는 편이 좋습니다.
n8n 큐 모드 배포는 실행 업무를 메인 프로세스와 Worker로 나누려는 경우에 적합합니다. 단일 워크플로의 실행 속도를 자동으로 높이지는 않습니다.
적합: 실행 대기와 리소스 사용 기록에서 지속적인 경합이 확인되고, 공유 데이터베이스와 Redis 구성을 준비할 수 있는 경우입니다.
부적합: 단일 작업 자체가 느린 경우, 일시적인 대기만 발생한 경우, 파일 시스템 기반 이진 데이터 저장을 그대로 유지해야 하는 경우입니다.
이 안내는 단일 인스턴스에서 분리 배포를 검토하는 n8n 운영자를 위한 내용입니다.
AI 작업과 일반 자동화를 함께 운영하는 소규모 팀도 서비스별 역할을 확인할 수 있습니다.
Docker Compose와 서버 자원 계획을 맡은 담당자는 배포 전 확인 항목과 되돌리기 기준을 점검할 수 있습니다.
먼저 큐 모드가 필요한 상황인지 판별합니다
큐 모드에서는 메인 인스턴스가 워크플로 정보를 받고, Worker가 실행 작업을 처리합니다. Redis는 대기열 전달에 쓰이며, 각 인스턴스는 같은 데이터베이스와 암호화 설정을 사용하도록 맞춰야 합니다. 자세한 역할과 구성 조건은 n8n 공식 큐 모드 안내에서 확인할 수 있습니다.
이 구조는 실행 업무를 나누는 방법이지, 모든 느린 실행을 빠르게 만드는 설정은 아닙니다. 한 워크플로가 오래 걸린다면 그 안의 외부 API 응답, 대량 데이터 처리, 코드 실행 단계가 원인일 수 있습니다. 이런 병목은 Worker 추가만으로 없어지지 않습니다.
n8n 단일 인스턴스는 언제 큐 모드로 바꾸나요?
다음 기록을 같은 기간에 비교합니다.
- 실행이 시작되기 전 대기하는 일이 반복되는지 확인합니다.
- 실패 기록에서 시간 초과, 연결 오류, 메모리 부족 등 실패 원인을 구분합니다.
- CPU와 메모리 사용 추이를 확인해 작업이 몰릴 때 자원 경합이 함께 나타나는지 살펴봅니다.
- 실행 시간이 길어도 대기열이 쌓이지 않는다면, 먼저 개별 워크플로의 병목을 조사합니다.
판단 조건은 다음과 같습니다.
- 대기가 계속 쌓이고 실행 작업을 서로 분리할 필요가 있다면 큐 모드 전환을 검토합니다.
- 대기열은 짧고 특정 워크플로만 느리다면 해당 워크플로부터 분석합니다.
- 자원 사용이 계속 높지만 실행을 나눠도 여유가 생기지 않을 것으로 보인다면, Worker 수를 늘리기 전에 서버와 데이터베이스의 여유를 확인합니다.
- 기록이 부족하다면 기존 구성을 유지하고 대기 시간과 자원 사용을 먼저 관찰합니다.
변경 전에 버전과 데이터 저장 조건을 기록합니다
현재 n8n 버전, 컨테이너 실행 방식, 데이터베이스 종류, 데이터 디렉터리와 암호화 키 보관 위치를 기록합니다. 암호화 키는 같은 구성을 복제할 때 빠뜨리기 쉽습니다. 메인 인스턴스와 Worker가 같은 키를 사용하도록 설정해야 기존 자격 증명을 일관되게 처리할 수 있습니다. 키의 역할과 큐 구성은 n8n 큐 모드 환경 변수 안내와 데이터베이스 설정 안내를 함께 확인합니다.
데이터베이스는 여러 실행 프로세스가 같은 상태를 읽을 수 있도록 구성해야 합니다. 기존 배포가 큐 모드에서 지원되는 데이터베이스인지 확인하고, 지원 범위가 불분명하면 현재 설정을 그대로 복사하지 말고 공식 문서 기준으로 전환 계획을 세웁니다.
이진 데이터 저장 방식도 전환 전에 확인합니다. 공식 큐 모드 문서는 파일 시스템 저장 방식의 이진 데이터가 큐 모드와 호환되지 않는다고 안내합니다. 따라서 파일을 워크플로 실행 데이터로 보관한다면 지원되는 저장 방식을 먼저 설계해야 합니다. 데이터 저장 옵션은 이진 데이터 저장 안내에서 확인할 수 있습니다.
| 점검 항목 | 전환 전에 확인할 내용 | 미확인 상태에서 생길 수 있는 문제 |
|---|---|---|
| n8n 및 실행 구성 | 메인 인스턴스와 Worker의 이미지 버전, Task Runner 설정 | 구성 차이로 실행 결과가 달라지거나 Worker가 작업을 처리하지 못할 수 있습니다 |
| 데이터베이스 | 지원 여부, 연결 정보, 두 역할에서 같은 데이터 사용 여부 | 실행 상태가 일관되지 않거나 연결 오류가 발생할 수 있습니다 |
| Redis | 메인 인스턴스와 Worker가 같은 Redis에 연결하는지 | 작업이 대기열에 전달되지 않거나 Worker가 찾지 못할 수 있습니다 |
| 암호화 키 | 모든 관련 인스턴스에서 같은 키를 안전하게 사용하도록 설정했는지 | 저장된 자격 증명 처리에 문제가 생길 수 있습니다 |
| 이진 데이터 | 파일 시스템 저장 여부와 전환할 저장 방식 | 큐 모드에서 이진 데이터에 접근하지 못할 수 있습니다 |
서비스를 나눈 Compose 구성을 준비합니다
n8n 자체 호스팅 구성에서 메인 인스턴스는 웹 화면과 작업 접수를 맡습니다. Worker는 대기열에서 작업을 받아 실행합니다. Redis는 대기열을 전달하고, 데이터베이스는 실행에 필요한 상태를 공유합니다. 각 서비스의 환경 변수와 버전 조건은 공식 Docker Compose 배포 안내와 큐 모드 문서에 맞춰 조정합니다.
아래는 구성 요소를 나누는 틀입니다. 실제 이미지 태그, 데이터베이스 주소와 비밀 값은 사용 중인 배포 환경에 맞게 정합니다. 예시는 완성된 운영 설정이 아니며, 버전별 환경 변수와 실행 옵션은 배포 전에 공식 안내와 대조해야 합니다.
services:
n8n-main:
image: n8nio/n8n:${N8N_VERSION}
environment: &n8n-common
EXECUTIONS_MODE: queue
QUEUE_BULL_REDIS_HOST: redis
QUEUE_BULL_REDIS_PORT: 6379
DB_TYPE: postgresdb
DB_POSTGRESDB_HOST: ${DB_HOST}
DB_POSTGRESDB_DATABASE: ${DB_NAME}
DB_POSTGRESDB_USER: ${DB_USER}
DB_POSTGRESDB_PASSWORD: ${DB_PASSWORD}
N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
depends_on:
- redis
n8n-worker:
image: n8nio/n8n:${N8N_VERSION}
command: ["worker", "--concurrency", "${WORKER_CONCURRENCY}"]
environment: *n8n-common
depends_on:
- redis
redis:
image: redis:${REDIS_VERSION}
volumes:
- redis_data:/data
volumes:
redis_data:
이 틀은 데이터베이스가 별도로 준비되어 있다고 가정합니다. 데이터베이스를 같은 Compose 구성에 둘 경우에는 지속성, 접근 제어와 백업 절차도 함께 정의합니다. Redis의 연결 주소와 인증 설정, n8n의 실제 환경 변수 이름은 사용 중인 버전의 공식 환경 변수 문서에 맞춰 검증합니다.
Task Runner를 쓰는 구성이라면 메인 인스턴스와 Worker의 실행 방식만 복사해서는 충분하지 않을 수 있습니다. Task Runner 공식 설정 안내를 기준으로 필요한 구성과 버전 일치를 확인합니다. 동시 실행 설정은 작업 특성에 맞춰 정하고, 값만 키우면 데이터베이스와 호스트의 부하도 함께 늘 수 있습니다. 공식 동시 실행 안내도 배포 전에 확인합니다.
| 서비스 | 맡는 일 | 연결·운영 확인 |
|---|---|---|
| 메인 인스턴스 | 웹 요청과 워크플로 접수 | Worker와 같은 데이터베이스, Redis, 암호화 키를 사용합니다 |
| Worker | 대기열에서 작업을 가져와 실행 | 같은 n8n 버전과 실행 설정을 사용하고 처리 로그를 확인합니다 |
| Redis | 대기 중인 작업 전달 | 메인 인스턴스와 Worker 양쪽에서 접근 가능한 주소인지 검사합니다 |
| 데이터베이스 | 실행 상태와 관련 데이터 저장 | 지원되는 구성이며 양쪽 역할이 같은 데이터에 연결되는지 확인합니다 |
시작한 뒤 작업이 이동하는지 검증합니다
설정 파일을 작성했다고 배포가 끝난 것은 아닙니다. 다음 순서로 서비스 연결과 실제 실행을 확인합니다.
- Redis가 실행 중이고 메인 인스턴스와 Worker에서 연결되는지 확인합니다.
- 메인 인스턴스 로그에서 데이터베이스와 Redis 연결 오류가 없는지 살펴봅니다.
- Worker 로그에서 등록과 대기열 작업 수신 여부를 확인합니다.
- 부작용이 적고 결과를 확인하기 쉬운 테스트 워크플로를 실행합니다.
- 화면의 실행 상태, 메인 인스턴스 로그와 Worker 로그를 함께 대조합니다.
- 테스트 실행 결과와 기존 데이터 접근이 정상인지 확인한 뒤 실제 작업을 전환합니다.
작업이 대기열에 남아 있다면 Worker가 실행 중인지, 두 역할의 Redis 주소와 암호화 키가 일치하는지, 데이터베이스 연결이 정상인지부터 검사합니다. 오류가 보이지 않는다는 이유로 Worker 수나 동시 실행 설정을 즉시 늘리지는 않습니다. 먼저 어느 단계에서 작업이 멈췄는지 로그로 좁혀야 합니다.
안정화 뒤 확장과 롤백을 결정합니다
일정 기간 실제 작업을 운영하면서 대기열 변화, 작업 대기 시간, CPU와 메모리 사용 추이, 디스크 여유를 함께 기록합니다. 짧은 순간의 급증과 계속 이어지는 적체를 구분해야 합니다. 대기열이 쌓여도 데이터베이스가 먼저 한계에 닿는다면 Worker를 늘리는 선택은 오히려 병목을 키울 수 있습니다.
증가한 Worker가 효과를 내는지는 작업이 서로 독립적으로 실행될 수 있는지에 달려 있습니다. 한 작업의 결과가 다음 작업을 기다리는 구조라면 실행 프로세스를 추가해도 해당 단계가 빨라지지 않습니다. 실행량이 늘어난 뒤에는 Redis와 데이터베이스 부하도 다시 확인합니다.
전환 전에는 데이터베이스와 설정의 복구 가능한 사본을 준비하고, 암호화 키를 별도로 안전하게 보관합니다. 같은 서버 안의 복사본만으로는 장비 장애에 대비한 외부 백업이 되지 않습니다. 되돌리기 전에는 큐에 남은 작업과 이미 끝난 실행의 상태를 확인해 중복 실행이나 누락이 생기지 않도록 합니다. 버전을 올린 뒤에도 같은 테스트 워크플로로 연결과 실행 결과를 다시 검증합니다.
마지막으로, 실행이 분리되어야 한다는 기록이 있고 공유 구성까지 검증되면 큐 모드를 유지합니다. 대기열이 줄지 않거나 개별 작업만 느리다면 먼저 해당 병목을 조정합니다. 데이터베이스나 호스트 자원이 지속해서 부족하다면 실행 프로세스를 추가하기보다 전체 구성의 여유를 다시 평가합니다.
서버를 옮길지 판단할 때는 기록한 동시 작업과 저장 공간, 운영체제 조건을 기준으로 실제 선택지를 비교해야 합니다. 공유형 인스턴스는 CPU 자원 경합, 초과 할당 가능성, 저장 공간이나 운영체제 선택의 제약이 있을 수 있습니다. 장기간 안정적으로 실행할 독립 자원이 필요하다면 XFP Cloud의 서버 구성과 시스템 선택지를 실제 작업 기록과 대조해 보십시오. 과금 주기를 검토할 때는 이용 기간별 청구 안내도 확인할 수 있습니다. 필요한 자원과 운영 기간이 확인되지 않았다면 서둘러 이전하기보다 현재 구성을 관찰하는 편이 합리적입니다.