InfoGrab DocsInfoGrab Docs

사전 요구 사항

요약

여기에 제공된 요구 사항은 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은 자격 증명1, 과거 실행 내역, 워크플로를 저장하기 위해 데이터베이스를 사용합니다.

n8n의 핵심 기능 중 하나는 데이터베이스를 자유롭게 선택할 수 있다는 점입니다. 지원되는 모든 데이터베이스는 저마다 장단점이 있으므로, 개별적으로 고려하여 필요에 가장 적합한 것을 선택해야 합니다. 기본적으로 지정된 위치에 데이터베이스가 존재하지 않으면 n8n은 SQLite 데이터베이스를 생성합니다.

n8n은 모든 n8n 인스턴스가 전용 데이터베이스를 갖추는 것을 권장합니다. 이는 의존성과 잠재적인 성능 저하를 방지하는 데 도움이 됩니다. 모든 n8n 인스턴스에 전용 데이터베이스를 제공할 수 없는 경우, n8n은 Postgres의 스키마 기능을 활용할 것을 권장합니다.

Postgres의 경우, 데이터베이스가 DB 인스턴스에 이미 존재해야 합니다. n8n 프로세스용 데이터베이스 사용자는 사용하거나 생성하는 모든 테이블에 대해 전체 권한을 가지고 있어야 합니다. n8n은 데이터베이스 스키마를 생성하고 유지 관리합니다.

모범 사례#

  • SSD 스토리지를 사용하세요.
  • 컨테이너화된 클라우드 환경에서는 컨테이너를 중지/시작할 때 볼륨이 지속되고 마운트되는지 확인하세요. 그렇지 않으면 모든 데이터가 손실됩니다.
  • Postgres를 사용하는 경우, tablePrefix 구성 옵션을 사용하지 마세요. 이 옵션은 머지않아 지원 중단될 예정입니다.
  • 새 버전의 변경 로그에 주의를 기울이고, 다운그레이드하기 전에 마이그레이션 되돌리기를 고려하세요.
  • IP 허용 목록 및 백업과 같은 기본적인 데이터베이스 보안 및 안정성 메커니즘을 최소한으로 갖추세요.

메모리 관련 고려 사항#

n8n 인스턴스는 일반적으로 대량의 가용 메모리를 필요로 하지 않습니다. 예를 들어 유휴 상태의 n8n Cloud 인스턴스는 약 100MB만 필요로 합니다. 메모리 요구 사항을 결정하는 것은 워크플로의 특성과 처리되는 데이터입니다.

예를 들어, 대부분의 노드는 데이터를 워크플로의 다음 노드로 그대로 전달하지만, Code node는 데이터의 사전 처리 및 사후 처리 사본을 생성합니다. 대용량 바이너리 파일을 다룰 때는 이로 인해 가용 리소스를 모두 소모할 수 있습니다.

배포 권장 사항#

자세한 설정 옵션은 호스팅 문서를 참고하세요.

사용자 데이터#

n8n은 n8n Cloud 내부적으로 사용하는 것과 동일하거나 유사한 방식을 따를 것을 권장합니다. Rook을 사용하여 사용자 데이터를 저장하고, n8n 서버가 다운되면 동일한 데이터를 사용하는 다른 머신에서 새 인스턴스를 시작합니다.

이러한 방식 덕분에, 치명적인 장애가 발생하거나 사용자가 지정된 보존 기간(n8n Cloud의 경우 2주) 내에 계정을 재활성화하고자 하는 경우가 아니라면 백업을 사용할 필요가 없습니다.

백업#

n8n은 별도의 컨테이너를 연결하여 모든 데이터를 이 두 번째 컨테이너로 복사하는 방식으로 야간 백업을 생성할 것을 권장합니다. 이 방식에서는 RAM 사용량이 무시할 수 있는 수준이므로 서버에 배치할 수 있는 사용자 수에 영향을 미치지 않습니다.

재시작#

인스턴스가 다운되거나 재시작되는 동안 놓친 실행(예: Cron 또는 Webhook 노드)은 복구할 수 없습니다. 100% 가동 시간을 유지하는 것이 중요하다면, 데이터를 캐시하는 별도의 프록시를 앞단에 구축해야 합니다.

Footnotes

  1. n8n에서 자격 증명은 특정 앱 및 서비스에 연결하기 위한 인증 정보를 저장합니다. 인증 정보(사용자 이름과 비밀번호, API 키, OAuth 시크릿 등)로 자격 증명을 생성한 후, 연결된 앱 노드를 사용하여 해당 서비스와 상호작용할 수 있습니다. ↩

사전 요구 사항

n8n v2.29
원문 보기
요약

여기에 제공된 요구 사항은 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은 자격 증명1, 과거 실행 내역, 워크플로를 저장하기 위해 데이터베이스를 사용합니다.

n8n의 핵심 기능 중 하나는 데이터베이스를 자유롭게 선택할 수 있다는 점입니다. 지원되는 모든 데이터베이스는 저마다 장단점이 있으므로, 개별적으로 고려하여 필요에 가장 적합한 것을 선택해야 합니다. 기본적으로 지정된 위치에 데이터베이스가 존재하지 않으면 n8n은 SQLite 데이터베이스를 생성합니다.

n8n은 모든 n8n 인스턴스가 전용 데이터베이스를 갖추는 것을 권장합니다. 이는 의존성과 잠재적인 성능 저하를 방지하는 데 도움이 됩니다. 모든 n8n 인스턴스에 전용 데이터베이스를 제공할 수 없는 경우, n8n은 Postgres의 스키마 기능을 활용할 것을 권장합니다.

Postgres의 경우, 데이터베이스가 DB 인스턴스에 이미 존재해야 합니다. n8n 프로세스용 데이터베이스 사용자는 사용하거나 생성하는 모든 테이블에 대해 전체 권한을 가지고 있어야 합니다. n8n은 데이터베이스 스키마를 생성하고 유지 관리합니다.

모범 사례#

  • SSD 스토리지를 사용하세요.
  • 컨테이너화된 클라우드 환경에서는 컨테이너를 중지/시작할 때 볼륨이 지속되고 마운트되는지 확인하세요. 그렇지 않으면 모든 데이터가 손실됩니다.
  • Postgres를 사용하는 경우, tablePrefix 구성 옵션을 사용하지 마세요. 이 옵션은 머지않아 지원 중단될 예정입니다.
  • 새 버전의 변경 로그에 주의를 기울이고, 다운그레이드하기 전에 마이그레이션 되돌리기를 고려하세요.
  • IP 허용 목록 및 백업과 같은 기본적인 데이터베이스 보안 및 안정성 메커니즘을 최소한으로 갖추세요.

메모리 관련 고려 사항#

n8n 인스턴스는 일반적으로 대량의 가용 메모리를 필요로 하지 않습니다. 예를 들어 유휴 상태의 n8n Cloud 인스턴스는 약 100MB만 필요로 합니다. 메모리 요구 사항을 결정하는 것은 워크플로의 특성과 처리되는 데이터입니다.

예를 들어, 대부분의 노드는 데이터를 워크플로의 다음 노드로 그대로 전달하지만, Code node는 데이터의 사전 처리 및 사후 처리 사본을 생성합니다. 대용량 바이너리 파일을 다룰 때는 이로 인해 가용 리소스를 모두 소모할 수 있습니다.

배포 권장 사항#

자세한 설정 옵션은 호스팅 문서를 참고하세요.

사용자 데이터#

n8n은 n8n Cloud 내부적으로 사용하는 것과 동일하거나 유사한 방식을 따를 것을 권장합니다. Rook을 사용하여 사용자 데이터를 저장하고, n8n 서버가 다운되면 동일한 데이터를 사용하는 다른 머신에서 새 인스턴스를 시작합니다.

이러한 방식 덕분에, 치명적인 장애가 발생하거나 사용자가 지정된 보존 기간(n8n Cloud의 경우 2주) 내에 계정을 재활성화하고자 하는 경우가 아니라면 백업을 사용할 필요가 없습니다.

백업#

n8n은 별도의 컨테이너를 연결하여 모든 데이터를 이 두 번째 컨테이너로 복사하는 방식으로 야간 백업을 생성할 것을 권장합니다. 이 방식에서는 RAM 사용량이 무시할 수 있는 수준이므로 서버에 배치할 수 있는 사용자 수에 영향을 미치지 않습니다.

재시작#

인스턴스가 다운되거나 재시작되는 동안 놓친 실행(예: Cron 또는 Webhook 노드)은 복구할 수 없습니다. 100% 가동 시간을 유지하는 것이 중요하다면, 데이터를 캐시하는 별도의 프록시를 앞단에 구축해야 합니다.

Footnotes

  1. n8n에서 자격 증명은 특정 앱 및 서비스에 연결하기 위한 인증 정보를 저장합니다. 인증 정보(사용자 이름과 비밀번호, API 키, OAuth 시크릿 등)로 자격 증명을 생성한 후, 연결된 앱 노드를 사용하여 해당 서비스와 상호작용할 수 있습니다. ↩