사전 요구 사항
n8n v2.25여기에 제공된 요구 사항은 n8n Cloud를 기반으로 한 예시이며 설명 목적으로만 제공됩니다. n8n은 CPU를 많이 사용하지 않으므로 AWS 및 GCP와 같은 제공업체의 소형 인스턴스도 대부분의 사용 사례에 충분합니다.
여기에 제공된 요구 사항은 n8n Cloud를 기반으로 한 예시이며 설명 목적으로만 제공됩니다. 실제 요구 사항은 사용자 수, 워크플로 수, 실행 수에 따라 다를 수 있습니다. 자세한 내용은 n8n에 문의하세요.
| 컴포넌트 | 크기 | 지원 환경 |
|---|---|---|
| CPU/vCPU | 최소 10 CPU 사이클, 필요에 따라 확장 | 모든 퍼블릭 또는 프라이빗 클라우드 |
| 데이터베이스 | 512 MB - 4 GB SSD | SQLite 또는 PostgreSQL |
| 메모리 | 320 MB - 2 GB |
CPU 고려 사항#
n8n은 CPU를 많이 사용하지 않으므로 AWS 및 GCP와 같은 제공업체의 소형 인스턴스도 대부분의 사용 사례에 충분합니다. 일반적으로 메모리 요구 사항이 CPU 요구 사항보다 우선하므로 인프라를 계획할 때 리소스를 메모리에 집중하세요.
데이터베이스 고려 사항#
n8n은 데이터베이스를 사용하여 자격증명, 과거 실행 기록, 워크플로를 저장합니다.
n8n의 핵심 기능 중 하나는 데이터베이스를 선택할 수 있는 유연성입니다. 지원되는 모든 데이터베이스에는 각각 장단점이 있으므로 개별적으로 고려하여 필요에 가장 적합한 것을 선택해야 합니다. 기본적으로 n8n은 지정된 위치에 데이터베이스가 없는 경우 SQLite 데이터베이스를 만듭니다.
n8n은 모든 n8n 인스턴스에 전용 데이터베이스를 갖는 것을 권장합니다. 이는 의존성 및 잠재적인 성능 저하를 방지하는 데 도움이 됩니다. 모든 n8n 인스턴스에 전용 데이터베이스를 제공할 수 없는 경우 n8n은 Postgres의 스키마 기능을 활용할 것을 권장합니다.
Postgres의 경우 데이터베이스가 DB 인스턴스에 이미 존재해야 합니다. n8n 프로세스의 데이터베이스 사용자는 사용하거나 생성하는 모든 테이블에 대한 전체 권한이 필요합니다. n8n이 데이터베이스 스키마를 생성하고 유지 관리합니다.
모범 사례#
- SSD 스토리지 사용.
- 컨테이너화된 클라우드 환경에서는 컨테이너를 중지/시작할 때 볼륨이 지속되고 마운트되는지 확인하세요. 그렇지 않으면 모든 데이터가 손실됩니다.
- Postgres를 사용하는 경우
tablePrefix구성 옵션을 사용하지 마세요. 가까운 미래에 deprecated될 예정입니다. - 새 버전의 변경 로그에 주의를 기울이고 다운그레이드 전에 마이그레이션 되돌리기를 고려하세요.
- IP 허용 목록 및 백업과 같은 기본적인 데이터베이스 보안 및 안정성 메커니즘을 최소한 설정하세요.
메모리 고려 사항#
n8n 인스턴스는 일반적으로 대용량 메모리를 필요로 하지 않습니다. 예를 들어 유휴 상태의 n8n Cloud 인스턴스는 ~100MB를 필요로 합니다. 메모리 요구 사항은 워크플로의 특성과 처리되는 데이터에 따라 결정됩니다.
예를 들어, 대부분의 노드는 워크플로의 다음 노드로 데이터를 전달하지만, 코드 노드는 데이터의 사전 처리 및 사후 처리 복사본을 만듭니다. 대용량 바이너리 파일을 처리할 때는 사용 가능한 리소스를 모두 소비할 수 있습니다.
배포 권장 사항#
자세한 설정 옵션은 호스팅 문서를 참조하세요.
사용자 데이터#
n8n은 n8n Cloud 내부에서 사용하는 것과 동일하거나 유사한 방법을 따를 것을 권장합니다: Rook을 사용하여 사용자 데이터를 저장하고, n8n 서버가 다운되면 동일한 데이터를 사용하여 다른 머신에서 새 인스턴스가 시작됩니다.
이로 인해 재앙적인 장애의 경우나 사용자가 지정된 보존 기간(n8n Cloud의 경우 2주) 내에 계정을 재활성화하려는 경우를 제외하고는 백업을 사용할 필요가 없습니다.
백업#
n8n은 다른 컨테이너를 연결하고 모든 데이터를 두 번째 컨테이너에 복사하는 방식으로 야간 백업을 생성할 것을 권장합니다. 이 방식으로 RAM 사용량이 미미하여 서버에 배치할 수 있는 사용자 수에 영향을 미치지 않습니다.
재시작#
인스턴스가 다운되거나 재시작 중인 경우, 이 기간 동안 누락된 실행(예: Cron 또는 Webhook 노드)은 복구할 수 없습니다. 100% 가동 시간을 유지하는 것이 중요한 경우 데이터를 캐시하는 또 다른 프록시를 앞에 구축해야 합니다.