#사전 준비

클러스터 애플리케이션을 배포하기 전에 다음 준비 작업을 완료해야 합니다.

#상용 플러그인 라이선스

NocoBase 애플리케이션을 클러스터 모드로 실행하려면 다음 플러그인의 지원이 필요합니다.

먼저 위 플러그인에 대한 라이선스를 확보했는지 확인해 주세요. (상용 플러그인 서비스 플랫폼에서 해당 플러그인 라이선스를 구매할 수 있습니다.)

#시스템 구성 요소

애플리케이션 인스턴스 외의 다른 시스템 구성 요소는 각 팀의 운영 요구사항에 따라 운영 담당자가 직접 선택하여 사용할 수 있습니다.

#데이터베이스

현재 클러스터 모드는 애플리케이션 인스턴스에만 적용되므로, 데이터베이스는 임시로 단일 노드만 지원합니다. 만약 마스터-슬레이브와 같은 데이터베이스 아키텍처를 사용한다면, 미들웨어를 통해 직접 구현해야 하며 NocoBase 애플리케이션에 투명하게 작동하도록 보장해야 합니다.

#미들웨어

NocoBase의 클러스터 모드는 클러스터 간 통신 및 조정을 위해 다음과 같은 미들웨어에 의존합니다.

• 캐시: Redis 기반 분산 캐시 미들웨어를 사용하여 데이터 접근 속도를 향상시킵니다.
• 동기화 신호: Redis의 스트림(stream) 기능을 사용하여 클러스터 간 동기화 신호 전달을 구현합니다.
• 메시지 큐: Redis 또는 RabbitMQ 기반 메시지 큐 미들웨어를 사용하여 비동기 메시지 처리를 구현합니다.
• 분산 잠금: Redis 기반 분산 잠금을 사용하여 클러스터 내 공유 리소스 접근의 안전성을 보장합니다.

모든 미들웨어 구성 요소가 Redis를 사용하는 경우, 클러스터 내부 네트워크(또는 Kubernetes)에서 단일 Redis 서비스를 시작할 수 있습니다. 또는 각 기능(캐시, 동기화 신호, 메시지 큐, 분산 잠금)별로 별도의 Redis 서비스를 활성화할 수도 있습니다.

버전 권장 사항

• Redis: 8.0 이상 또는 Bloom Filter 기능이 포함된 redis-stack 버전
• RabbitMQ: 4.0 이상

#공유 스토리지

NocoBase는 storage 디렉터리를 사용하여 시스템 관련 파일을 저장합니다. 다중 노드 모드에서는 여러 노드에서 공유 접근을 지원하도록 클라우드 디스크(또는 NFS)를 마운트해야 합니다. 그렇지 않으면 로컬 스토리지가 자동으로 동기화되지 않아 정상적으로 작동하지 않습니다.

Kubernetes로 배포할 때는 Kubernetes 배포: 공유 스토리지 섹션을 참고해 주세요.

#로드 밸런싱

클러스터 모드는 요청 분배, 애플리케이션 인스턴스의 상태 확인 및 장애 조치를 위해 로드 밸런서를 필요로 합니다. 이 부분은 팀의 운영 요구사항에 따라 직접 선택하고 구성해야 합니다.

자체 구축 Nginx를 예로 들어, 설정 파일에 다음 내용을 추가합니다.

upstream myapp {
    # ip_hash; # 세션 유지를 위해 사용할 수 있습니다. 활성화하면 동일 클라이언트의 요청은 항상 동일한 백엔드 서버로 전송됩니다.
    server 172.31.0.1:13000; # 내부 노드 1
    server 172.31.0.2:13000; # 내부 노드 2
    server 172.31.0.3:13000; # 내부 노드 3
}

server {
    listen 80;

    location / {
        # 정의된 upstream을 사용하여 로드 밸런싱
        proxy_pass http://myapp;
        # ... 기타 설정
    }
}

이는 요청을 역방향 프록시하여 여러 서버 노드로 분산 처리한다는 의미입니다.

다른 클라우드 서비스 제공업체에서 제공하는 로드 밸런싱 미들웨어는 해당 서비스 제공업체의 설정 문서를 참고해 주세요.

#환경 변수 설정

클러스터 내의 모든 노드는 동일한 환경 변수 설정을 사용해야 합니다. NocoBase의 기본 환경 변수 외에도 다음 미들웨어 관련 환경 변수를 설정해야 합니다.

#멀티코어 모드

애플리케이션이 멀티코어 노드에서 실행될 때, 노드의 멀티코어 모드를 활성화할 수 있습니다.

# PM2 멀티코어 모드 활성화
# CLUSTER_MODE=max # 기본적으로 비활성화되어 있으며, 수동으로 설정해야 합니다.

Kubernetes에서 애플리케이션 파드(pod)를 배포하는 경우, 이 설정을 무시하고 파드의 복제본(replica) 수를 통해 애플리케이션 인스턴스 수를 제어할 수 있습니다.

#캐시

# 캐시 어댑터. 클러스터 모드에서는 redis로 설정해야 합니다. (설정하지 않으면 기본값은 인메모리입니다.)
CACHE_DEFAULT_STORE=redis

# Redis 캐시 어댑터 연결 URL. 직접 입력해야 합니다.
CACHE_REDIS_URL=

#동기화 신호

# Redis 동기화 어댑터 연결 URL. 설정하지 않으면 기본값은 redis://localhost:6379/0입니다.
PUBSUB_ADAPTER_REDIS_URL=

#분산 잠금

# 잠금 어댑터. 클러스터 모드에서는 redis로 설정해야 합니다. (설정하지 않으면 기본값은 인메모리 로컬 잠금입니다.)
LOCK_ADAPTER_DEFAULT=redis

# Redis 잠금 어댑터 연결 URL. 설정하지 않으면 기본값은 redis://localhost:6379/0입니다.
LOCK_ADAPTER_REDIS_URL=

#메시지 큐

# Redis를 메시지 큐 어댑터로 활성화합니다. 설정하지 않으면 기본값은 인메모리 어댑터입니다.
QUEUE_ADAPTER=redis
# Redis 메시지 큐 어댑터 연결 URL. 설정하지 않으면 기본값은 redis://localhost:6379/0입니다.
QUEUE_ADAPTER_REDIS_URL=

#워커 ID 할당자

NocoBase의 일부 시스템 컬렉션은 전역 고유 ID를 기본 키로 사용합니다. 클러스터 내에서 기본 키 충돌을 방지하려면 워커 ID 할당자를 통해 각 애플리케이션 인스턴스에 고유한 워커 ID를 할당해야 합니다. 현재 워커 ID 범위는 0-31이며, 이는 동일한 애플리케이션이 최대 32개의 노드에서 동시에 실행될 수 있음을 의미합니다. 전역 고유 ID 설계에 대한 자세한 내용은 @nocobase/snowflake-id를 참고해 주세요.

# 워커 ID 할당자 Redis 연결 URL.
# 생략하면 임의의 워커 ID가 할당됩니다.
REDIS_URL=

CACHE_REDIS_URL=redis://localhost:6379/0
PUBSUB_ADAPTER_REDIS_URL=redis://localhost:6379/1
LOCK_ADAPTER_REDIS_URL=redis://localhost:6379/2
QUEUE_ADAPTER_REDIS_URL=redis://localhost:6379/3
REDIS_URL=redis://localhost:6379/4

Kubernetes를 사용하여 클러스터를 관리하는 경우, 위 환경 변수들을 ConfigMap 또는 Secret에 설정할 수 있습니다. 더 자세한 내용은 Kubernetes 배포를 참고해 주세요.

위 모든 준비 작업이 완료되면, 운영 프로세스로 이동하여 애플리케이션 인스턴스 관리를 계속할 수 있습니다.