20노드 전용 GPU 렌더팜 국경 간 배포 방법 (2026)

서론

크리에이티브 팀이 여러 사이트와 대양을 가로지르는 전용 렌더팜을 요청할 때, 거의 항상 SaaS 렌더팜이 해결할 수 없는 제약을 우회하고 있습니다. 계약상 제3자가 자격 증명을 보유하도록 허용할 수 없는 스튜디오, 한 국가의 아티스트가 다른 국가의 노드를 운영하는 분산 팀, 또는 다개월 약정으로 인해 프레임당 청구가 경제적으로 부적합한 프로덕션 하우스일 수 있습니다.

전용 클러스터를 배포한 경험에서, 어려운 부분은 거의 "더 많은 GPU를 임대하는 것"이 아닙니다. 올바른 조각들을 연결하는 것입니다: 고객 소유 클라우드 스토리지, 워크로드에 맞게 크기가 조정된 프라이빗 GPU 플릿, 지터를 견디는 암호화된 국경 간 전송, 그리고 무거운 3D 뷰포트에서 무너지지 않는 원격 데스크톱 계층. 한 조각이 잘못되면 클러스터는 작동하지만 아티스트들은 알아차립니다 — 그리고 약정은 조용히 저하됩니다.

저희는 상당한 CPU + GPU 플릿을 가진 클라우드 렌더팜인 Super Renders Farm을 운영하며, 기본 관리형 서비스에 맞지 않는 워크플로를 가진 팀을 위해 전용 GPU 클러스터도 구축합니다. 이 글은 그러한 배포에서 얻은 현장 가이드입니다 — 두 사이트를 가로지르고 국경을 넘어 원격 아티스트에게 서비스하는 20노드 전용 GPU 렌더팜을 어떻게 아키텍팅하는지. 관리형 렌더팜 임대에 대해 전용 인프라를 평가하는 경우, 이 가이드는 전용 경로가 추가 아키텍처 표면을 가질 가치가 있는지 결정하는 데 도움이 됩니다.

전용 vs SaaS 결정 기준

대부분의 렌더링 워크로드는 전용 클러스터가 필요하지 않습니다. 관리형 클라우드 렌더팜은 씬을 받고, 프레임을 스케줄링하고, 분당 청구합니다. 프로젝트 기반 작업 — 단일 단편, 30초 광고, 스틸 배치 — 의 경우 그 모델이 모든 관련 축에서 승리합니다.

전용 클러스터는 다음 중 하나 이상이 참일 때만 복잡성이 정당화됩니다:

• 지적 재산권 통제가 계약상이며 선호 사항이 아닙니다. 고객 계약은 제3자가 씬 파일이나 렌더 자격 증명을 보유하는 것을 금지합니다. 씬 업로드를 중재하는 SaaS 파이프라인은 기본 컴퓨팅이 동일하더라도 그 제약을 위반합니다.
• 약정이 며칠이 아닌 수개월 동안 진행됩니다. 고정 형태의 작업 — 장기 애니메이션 시리즈, 다분기 archviz 파이프라인, 진행 중인 가상 프로덕션 무대 — 는 사전 아키텍처 비용을 상각합니다.
• 워크플로가 관리형 파이프라인이 호스팅할 수 없을 만큼 사용자 정의되어 있습니다. 사용자 정의 DCC 플러그인 스택, 사내 렌더 매니저, 공유 캐시로 pre-bake하는 시뮬레이션 중심 파이프라인, 또는 독점 도구 체인은 모두 전용 노드로 밀어붙입니다.
• Bring-your-own-cloud가 엄격한 요구 사항입니다. 고객의 프로젝트 자산이 고객 계정 하의 cloud file-streaming 플랫폼에 있을 때, 클러스터는 인프라 제공자가 아닌 고객으로 로그인해야 합니다.
• 네트워크 분할 요구가 테넌트별 VLAN을 넘어섭니다. 일부 워크플로는 클러스터가 제공자의 더 넓은 네트워크에 보이지 않도록 요구합니다.

이러한 기준 중 어느 것도 적용되지 않으면, 관리형 렌더팜이 거의 확실히 올바른 선택입니다. 두 개 이상이 적용되면, 대화가 전용으로 이동합니다. 남은 질문은 지리적입니다.

아키텍처 개요

국경 간 전용 클러스터를 위해 배포하는 아키텍처는 세 가지 평면을 가집니다: 전송 평면, 컴퓨팅 평면, 그리고 스토리지 가속 평면.

        [ 원격 아티스트 팀 ]
              │  WireGuard (UDP 51820, 종단 간 암호화)
              ▼
   ┌──────────────────────────────────────────────────┐
   │   Main DC (양호한 국제 트랜짓)                       │
   │                                                    │
   │   ┌──────────────────────────────────────────┐    │
   │   │  EDGE + CACHE BOX (단일 Ubuntu 호스트)     │    │
   │   │   • WireGuard hub (NAT/MASQUERADE)        │    │
   │   │   • Samba SMB3 캐시 (단일 SSD, ext4)       │    │
   │   │   • dnsmasq (.lan 존)                     │    │
   │   │   • chrony (NTP)                          │    │
   │   │   • ufw + BBR + TCP MSS 클램핑             │    │
   │   └────────────┬─────────────────────────────┘    │
   │                │ LAN                                │
   │     ┌──────────▼───────────┐                        │
   │     │ Group A — ~10 노드    │  RTX 5090              │
   │     │ (Sunshine + 클라우드  │  C4D / Redshift / 등.  │
   │     │  클라이언트 + 캐시    │                        │
   │     │  마운트)              │                        │
   │     └───────────────────────┘                        │
   │                                                    │
   │     WireGuard site-to-site (공용 ISP 경로)          │
   └────────────────────┬───────────────────────────────┘
                        ▼
   ┌──────────────────────────────────────────────────┐
   │   보조 사이트 (같은 대도시권)                          │
   │     ┌───────────────────────┐                      │
   │     │ Group B — ~10 노드    │  사이트 간 터널로     │
   │     │ (Main DC로 터널)      │  캐시 읽기            │
   │     └───────────────────────┘                       │
   └──────────────────────────────────────────────────┘

   외부 cloud file-streaming 플랫폼 — 고객이 로그인;
   인프라 제공자는 자격 증명을 보유하지 않습니다.

전송 평면은 원격 아티스트를 위한 hub-and-spoke 패턴의 WireGuard와 두 컴퓨팅 사이트 간의 site-to-site 터널입니다. 컴퓨팅 평면은 두 그룹의 10개 Windows 11 Pro 노드이며, 각각 32 GB VRAM의 NVIDIA RTX 5090을 구동합니다. 스토리지 가속 평면은 메인 사이트의 단일 edge-and-cache 박스입니다.

핵심 설계 결정: edge 박스와 cache 박스는 같은 머신입니다. 아키텍처 세부사항을 참조하십시오.

20노드 GPU 클러스터 설정

설명된 배포의 기본 크기는 20개의 RTX 5090 노드입니다 — 두 사이트에 10개와 10개로 분할됩니다. 이 크기는 IP 민감 워크플로에 대해 전용 클러스터가 상각되는 10-20 아티스트 범위의 크리에이티브 팀에 잘 매핑됩니다.

각 노드는 동일한 하드웨어 형태를 가집니다: 32 GB VRAM의 RTX 5090, 현대적 멀티코어 CPU, 64 GB 또는 128 GB 시스템 RAM, 그리고 OS와 스크래치를 위해 크기가 조정된 로컬 NVMe 디스크. 영구 프로젝트 데이터는 공유 캐시 또는 업스트림 cloud file-streaming 플랫폼에 있습니다 — 절대 노드 자체에는 없습니다.

각 노드의 운영 체제는 깨끗한 이미지에서 배포된 Windows 11 Pro입니다. 노드 이미지에 의도적으로 DCC 플러그인 스택을 미리 로드하지 않습니다. 고객은 자체 DCC 도구의 설치를 주도합니다 — Cinema 4D, Redshift, Houdini, After Effects, Blender 등.

Group A와 Group B는 동일하게 구성됩니다. 사이트 간 WireGuard 터널이 올라오고 캐시가 마운트되면, 보조 사이트는 메인 사이트 LAN의 얇은 확장처럼 작동합니다. 플릿은 레이어 3 라우팅 가능합니다 — 고객은 자체 렌더 매니저를 설치합니다.

고객 소유 자격 증명 (Model B)

IP 민감 워크플로에 대해 전용 클러스터를 가장 자주 올바른 답으로 만드는 단일 아키텍처 결정은 Model B라고 부르는 것입니다: 고객 소유 자격 증명. Model A에서 — 자체 SaaS 서비스를 포함한 관리형 렌더팜의 기본값 — 인프라 제공자는 렌더링 파이프라인의 자격 증명을 보유합니다.

Model B에서 인프라 제공자는 하드웨어, 운영 체제, 네트워크, 캐시 계층을 공급하지만, cloud file-streaming 플랫폼이나 프로젝트의 소스 데이터에 대한 고객의 인증 자료를 절대 보유하지 않습니다. 고객은 자체 워크스테이션에서 하는 것과 정확히 같이 각 노드에서 클라우드 플랫폼에 로그인합니다.

세 가지 이유: (1) 계약상 — 고객의 다운스트림 계약이 자격 증명이 어디에 보유될 수 있는지 제한할 때; (2) 감사 — 보안 감사관에게 깔끔한 답변을 제공합니다; (3) 약정 종료 — 제공자가 자격 증명을 보유한 적이 없으므로 정리가 더 간단합니다.

Model B는 모두에게 적합하지 않습니다. 고객의 운영 팀을 각 노드의 자격 증명 수명 주기 책임에 묶습니다. BYOC 심층 분석을 참조하십시오.

Cloud file-streaming 통합

논의 중인 구성에서 고객의 프로젝트 자산은 cloud file-streaming 플랫폼에 있습니다 — 클라우드 백업 프로젝트 트리를 각 노드의 가상 파일 시스템으로 노출하는 서비스. 아티스트가 프로젝트를 마운트하고, 노드가 요청 시 파일을 읽고, 플랫폼이 백업 스토리지, 버전 관리, 지역 간 복제를 처리합니다.

고객이 선택한 일반적인 cloud file-streaming 플랫폼과 통합합니다. 플랫폼은 고객 계정을 사용하여 각 노드에서 로그인 이벤트를 봅니다; 노드의 플랫폼 클라이언트가 프로젝트 트리를 알려진 경로에 마운트합니다; 고객의 DCC 애플리케이션이 로컬 워크스테이션에서와 정확히 같이 그 경로에서 파일을 엽니다.

20노드 클러스터에서 변하는 것은 액세스 패턴입니다. 단일 워크스테이션의 단일 아티스트는 한 번에 하나의 프로젝트 파일을 가져옵니다. 프레임 범위에 대해 동시에 같은 씬을 여는 20개의 렌더 노드는 같은 자산에 대한 동기화된 클라우드 읽기 버스트를 만듭니다 — 캐시가 없으면 각 노드가 각 텍스처를 병렬로 가져옵니다.

write-back의 경우, 렌더 프레임이 완료되면 노드는 출력을 고객 계정을 통해 cloud file-streaming 플랫폼에 다시 씁니다.

공유 캐시 아키텍처

공유 캐시는 잘못하면 클러스터의 가치를 조용히 부식시키는 두세 가지 아키텍처 선택 중 하나입니다. 이전 배포에서 잘못 만들었습니다. 여러 빌드에 걸쳐 지속된 패턴은 의도적으로 보수적입니다.

단일 edge-and-cache 박스가 Ubuntu 22.04 LTS를 실행하며, ext4로 포맷되고 Samba SMB3를 통해 클러스터에 노출되는 단일 8 TB SATA SSD를 가집니다. 캐시 마운트는 각 렌더 노드의 고정 경로에 나타납니다(예: \\cache.lan\proj).

세 가지 의도적 선택: (1) 노드별이 아닌 단일 캐시 — 200 TB 중복을 피합니다. (2) XFS 위 LUKS가 있는 RAID 10이 아닌 ext4의 단일 SSD — 캐시는 진실의 출처가 아니며, 고객의 클라우드입니다. (3) 첫 렌더 날 전에 캐시 pre-warm — D-Day 읽기를 cold cloud pull에서 warm SMB 읽기로 변환합니다.

사이트 간에 Group B는 사이트 간 WireGuard 터널을 통해 캐시를 읽습니다. MSS 클램핑이 올바르게 적용되면 안정적이었습니다.

국경 간 네트워크 최적화

전송 계층이 국경 간 클러스터가 매끄럽게 느껴지는지 깨진 것처럼 느껴지는지를 결정합니다. TCP/IP, IP 단편화, DNS-over-VPN의 기본 동작은 SMB와 원격 데스크톱을 운반하는 장거리 암호화 터널에 대해 미묘하게 잘못되어 있습니다.

WireGuard hub-and-spoke 더하기 site-to-site. 각 아티스트는 워크스테이션에서 WireGuard 클라이언트를 통해 메인 사이트의 허브에 연결합니다. 두 컴퓨팅 사이트도 그들 사이에 WireGuard 터널을 가집니다.

TCP BBR. Linux의 기본 혼잡 제어(CUBIC)는 경미한 패킷 손실이 있는 저지연 링크용으로 설계되었습니다. 암호화된 트래픽을 운반하는 장거리 공용 ISP 링크는 매우 다르게 보입니다. BBR은 일관되게 더 사용 가능한 처리량을 생성합니다. 커널의 스톡 BBR(BBR v1)을 사용합니다.

TCP MSS 클램핑. "클러스터가 대부분 작동하지만 큰 파일은 안 됩니다" 불만의 가장 흔한 원인. 트래픽이 유효 MTU를 줄이는 터널을 통과할 때, 큰 패킷은 단편화되거나(느림) 조용히 드롭됩니다(더 나쁨). 수정: WireGuard 라우터에서 TCP MSS를 클램프하는 것.

dnsmasq에 VPN 인터페이스 나열. 미묘한 함정: dnsmasq는 클라이언트가 비공개 .lan 주소를 쿼리하더라도 구성에서 WireGuard 인터페이스(예: wg0)를 명시적으로 나열해야 합니다. 그렇지 않으면 터널을 통한 DNS 조회가 시간 초과됩니다 — 그러나 ping은 여전히 작동합니다.

chrony for NTP. 시간 동기화는 렌더 매니저(Deadline은 작업에 타임스탬프를 찍음), 사이트 간 로그 상관 관계, 시간 구성 요소가 있는 모든 인증 토큰에 중요합니다.

원격 데스크톱을 위한 Moonlight와 Sunshine

원격 데스크톱은 아티스트가 가장 직접적으로 경험하는 계층입니다. 그 계층이 느리거나 끊기는 것처럼 느껴지면, 렌더러가 얼마나 빠른지는 중요하지 않습니다.

원격 데스크톱을 위해 Moonlight(클라이언트)와 Sunshine(각 노드의 호스트)을 사용합니다. 이 조합은 RTX 5090의 NVIDIA NVENC 하드웨어 인코더를 사용하여 프레임 버퍼를 실시간으로 인코딩합니다. 인코딩이 이미 노드에 있는 GPU에서 발생하므로 렌더러와 경쟁이 없습니다.

3D 뷰포트 작업의 경우, 이것은 전통적인 원격 데스크톱과는 다른 방식으로 중요합니다. 이전 프로토콜 — RDP, VNC — 은 사무실 워크로드용으로 설계되었습니다. Moonlight + Sunshine는 프레임 버퍼를 비디오로 취급합니다 — 3D 작업에 정확히 올바른 모델.

노드를 아티스트에게 인계하기 전에 실행하는 품질 게이트 테스트가 있습니다 — 비공식적으로 "Test 8". Parsec은 실행 가능한 대체입니다. Moonlight, Parsec, RDP 비교를 참조하십시오.

하이브리드 인프라 (자체 + 임대)

전용 클러스터의 경제성을 지속적으로 개선하는 운영 결정 중 하나는 자체 및 임대 컴퓨팅을 혼합하는 것입니다. 설명된 20노드 구성의 경우, 일반적으로 메인 사이트의 기존 용량에서 약 10개 노드와 보조 사이트의 임대 공간에서 약 10개 노드를 구성합니다.

첫 번째 이유: 자본 유연성. 자체 및 임대 용량을 혼합하는 클러스터는 20개의 새 노드를 사전에 구매할 필요가 없습니다. 두 번째 이유: 용량 계획. 다개월 약정은 평평한 수요 곡선을 거의 가지지 않습니다.

두 그룹 모두 고객 관점에서 동일하게 작동합니다. 하이브리드 자체 + 임대 모델을 참조하십시오.

네트워크 분할

이러한 클러스터의 네트워크 분할은 선택 사항이 아닙니다. 고객은 제공자의 인프라에서 작동하지만, 제공자의 더 넓은 네트워크 — NAS, 라우터 관리자 인터페이스, 다른 테넌트 — 를 절대 볼 수 없어야 합니다.

두 계층으로 분할을 구현합니다. Tier 1 — edge 방화벽 — edge-and-cache 박스는 기본 거부 인바운드로 ufw를 실행합니다. WireGuard UDP 포트(51820)만 공용 인터넷에 노출됩니다. Tier 2 — 각 노드의 호스트 방화벽 — 각 노드는 edge 자세를 미러링하는 자체 Windows 방화벽 구성을 가집니다.

실제로 고객은 원해도 제공자의 다른 시스템을 ping하거나 스캔할 수 없습니다. 네트워크 보안 아키텍처를 참조하십시오.

배운 교훈

세운 모든 전용 클러스터에서 디버깅 시간을 절약했거나 — 적용을 잊었을 때 — 디버깅 시간이 들었던 다섯 가지 운영 교훈.

1. Dual-home 게이트웨이 라우팅 함정. edge 박스가 두 개의 네트워크 인터페이스를 가질 때, 작업 순서가 중요합니다. LAN 라우트는 기본 라우트가 변경되기 전에 구성되어야 합니다.

2. WireGuard와 DNS. dnsmasq는 청취해야 하는 모든 인터페이스를 명시적으로 나열해야 합니다, WireGuard 인터페이스 포함.

3. 터널을 통한 TCP MSS 클램핑은 선택 사항이 아닙니다. TLS, RDP, SMB 대용량 파일 읽기 — 큰 패킷을 보내고 싶은 모든 것 — 은 MSS 클램프 없이 조용히 떨어집니다.

4. 스토리지 적정 크기 조정. 캐시는 진실의 출처가 아니며, 고객의 클라우드입니다. 클라우드 계층에 중복이 있을 때 RAID/LUKS가 필요하지 않습니다.

5. 캐시 pre-warm. D-Day에 각 캐시 미스는 국제 왕복 비용이 듭니다. pre-warm 창은 첫 번째 생산 시간을 절약합니다.

배운 교훈 모음을 참조하십시오.

결론

전용 20노드 국경 간 GPU 렌더팜은 IP 통제가 계약적이고, 약정이 다개월이며, 워크플로가 사용자 정의 구성을 필요로 하고, BYOC 인증이 협상 불가능할 때 올바른 아키텍처입니다. 그러한 조건 외에는 관리형 렌더팜이 거의 항상 더 나은 답입니다.

조건이 적용될 때, 여기에 다룬 패턴 — Model B 자격 증명, ext4의 공유 캐시, WireGuard hub-and-spoke 더하기 site-to-site, MSS 클램핑이 있는 BBR, 원격 데스크톱을 위한 Moonlight + Sunshine, 2계층 방화벽 — 은 기본적으로 배포하는 것입니다.

Super Renders Farm의 팀은 관리형 렌더팜 임대와 전용 클러스터 배포를 모두 운영합니다 — 이 가이드 전반에 걸쳐 설명된 전용 GPU 클러스터 구성 및 국경 간 토폴로지를 포함합니다.

FAQ

Q: 일반적인 20노드 전용 클러스터 배포는 얼마나 걸립니까? A: 범위, 임대 사이트의 하드웨어 가용성, 고객의 cloud file-streaming 설정에 따라 일반적인 약정은 하드웨어 및 네트워크 프로비저닝을 위한 몇 주의 리드 타임에서 생산 시작 전 1-2일의 pre-warm 창까지 다양합니다.

Q: 우리 팀이 세 대륙에 분산되어 있다면 어떻게 됩니까? A: 고객-허브 WireGuard 터널은 클러스터 아키텍처를 변경하지 않고 추가 고객 위치로 확장됩니다. 각 원격 아티스트는 WireGuard 클라이언트를 실행하고 메인 사이트의 동일한 허브에 연결합니다.

Q: 다개월 약정에 들어가기 전에 내 쪽에서 클러스터를 볼 수 있습니까? A: 일반적으로 범위 결정 대화 중에 개념 증명 창을 마련합니다. 정확한 형식은 고객의 프로젝트에 따라 다릅니다.

Q: 약정 종료 시 데이터 보안은 어떻게 처리됩니까? A: Model B가 고객 자격 증명을 우리 손에서 멀리하기 때문에 종료는 하드웨어 및 캐시 정리에 중점을 둡니다. SMB 캐시를 지우고, 각 노드를 깨끗한 baseline에서 재이미징하고, 파기에 대한 서면 증명을 제공합니다.

Q: 20개 이상의 노드가 필요하면 어떻게 됩니까? A: 20노드 구성은 가장 일반적인 형태이지만 아키텍처는 그 이상으로 확장됩니다. 추가 사이트에 추가 그룹을 추가하여 더 큰 플릿을 구축했습니다.

Q: Cinema 4D, Redshift 또는 다른 DCC 도구에 대해 내 자체 라이센스를 가져올 수 있습니까? A: 라이센스 모델 — bring-your-own-license 대 제공자 공급 — 은 특정 DCC와 고객의 기존 라이센스 인벤토리에 따른 비즈니스 결정입니다.

Q: EU와 US 제공자의 클라우드 스토리지를 어떻게 처리합니까? A: cloud file-streaming 플랫폼은 고객의 선택입니다. 클러스터는 Windows에서 로그인 클라이언트를 실행하고 고객의 프로젝트 트리를 마운트된 파일 시스템으로 노출할 수 있는 모든 플랫폼과 통합됩니다.

Q: WireGuard 터널이 끊어지면 어떻게 됩니까? A: WireGuard는 기본 네트워크가 복구되면 자동으로 세션을 다시 설정합니다; 고객의 원격 데스크톱 세션은 다시 핸드셰이크 중에 잠시 일시 정지될 수 있습니다.