WireGuard 암호화 · BBR 혼잡 제어 · 공유 캐시 · 글로벌하게 분산된 크리에이티브 팀을 위한 구성입니다.
현대의 크리에이티브 작업은 점점 더 분산되고 있습니다. 3D 파이프라인에는 뉴욕에 있는 아트 디렉터, 베를린의 라이팅 팀, 서울의 프리랜서 룩-데브 아티스트, 그리고 또 다른 대륙의 render farm이 함께 존재할 수 있습니다. 이 네 주체가 동일한 기가비트 LAN에 연결되어 있다면 render farm 접근은 문제가 되지 않습니다. 그렇지 않은 경우 워크플로우는 공용 인터넷을 통과하게 되며, 장거리 라우팅의 모든 특성이 일정에 영향을 주기 시작합니다.
이러한 환경에서는 세 가지 문제가 반복됩니다. 첫째는 지연 시간입니다. 대륙 간 150~250 ms의 왕복 시간은 원격 데스크톱의 반응성을 크게 바꾸고, 렌더 매니저나 에셋 스트리밍 프로토콜의 모든 자잘한 통신을 더 두드러지게 만듭니다. 둘째는 지터입니다. 국제 회선은 종종 과부하 상태이며 패킷 타이밍이 변동합니다. 셋째는 대역폭 비용과 경합입니다. 40 GB 씬 파일을 대륙 간 회선으로 한 번 끌어오는 것은 받아들일 수 있지만, 각 렌더 노드가 자체 캐시를 가지고 있어서 스무 번을 끌어오는 것은 그렇지 않습니다.
로컬 render farm은 이 대부분을 우회합니다. 아티스트와 동일한 데이터센터 리전에 이미 클러스터를 두고 있는 팀이라면 이 페이지에서 설명하는 내용 대부분이 필요하지 않습니다. 다음 중 하나에 해당할 때 cross-country 렌더링이 올바른 아키텍처 선택이 됩니다.
이 중 하나라도 해당한다면 질문은 운영적으로 바뀝니다. 즉 세계 반대편의 render farm이 마치 아티스트의 로컬 네트워크 일부처럼 동작하도록 어떻게 만들 것인가입니다. 이 페이지의 나머지는 Super Renders Farm에서 이를 어떻게 접근하는지를 다룹니다.
Cross-country 연결은 한 번에 하나씩이 아니라 네 가지를 함께 적용해 최적화합니다.
고객 엔드포인트에서 render farm으로 향하는 모든 연결은 WireGuard를 거칩니다. 고객의 머신은 WireGuard 피어가 되고, 메인 데이터센터는 허브를 운영합니다. 암호화는 자동이며 종단 간으로 이루어집니다. 고객은 공용 인터넷에서 평문 트래픽을 볼 수 없으며, 우리 또한 마찬가지입니다. WireGuard는 장거리 회선에서 병목이 될 만큼 무겁지 않습니다. 그 오버헤드는 전통적인 IPsec 스택에 비해 현저히 작습니다.
Linux 커널의 기본 혼잡 제어인 CUBIC은 지터와 패킷 손실에 보수적으로 반응합니다. 손실을 속도를 줄이라는 신호로 해석하며, 그 손실이 간헐적인 국제 라우팅 때문이고 실제 혼잡이 아니어도 그렇습니다. BBR(Bottleneck Bandwidth and RTT)은 회선의 실제 대역폭-지연 곱을 측정해, 용량이 있는 한 파이프를 가득 유지합니다. 안정적인 대륙 간 경로에서 BBR은 동일한 하드웨어로 CUBIC의 보통 2~3배 처리량을 제공합니다. 지터가 있는 경로에서는 그 격차가 더 큽니다.
패킷이 WireGuard 같은 터널을 지날 때 유효 MTU는 하부 인터페이스보다 작습니다. TCP 연결이 터널이 운반할 수 있는 것보다 큰 MSS를 협상하면 두 가지 일이 생깁니다. 작은 패킷은 통과하고, 큰 패킷은 조용히 사라집니다. 증상은 원격 작업에서 가장 답답한 종류에 속합니다. SSH는 동작하고 ping도 동작하지만, TLS 핸드셰이크, RDP 세션, 의미 있는 크기의 SMB 파일 복사가 모두 멈춥니다. 우리는 WireGuard 게이트웨이에서 MSS를 클램핑하여 모든 TCP 연결이 터널이 실제로 전달 가능한 세그먼트 크기를 협상하도록 합니다.
팜 내부에서는 내부 DNS 해석을 위한 `dnsmasq`와 시간 동기화를 위한 `chrony`를 운영합니다. 둘은 조용한 인프라이지만 보이는 것보다 더 중요합니다. 내부 DNS 덕분에 렌더 노드는 공유 캐시를 IP 주소가 아닌 `cache.lan`으로 참조하며, 토폴로지를 재배치하기 쉽습니다. 시간 동기화는 대부분의 렌더 매니저와 로그 파이프라인이 시계 오프셋에 민감하기 때문에 중요합니다. 파일럿 대비 30초 어긋난 노드는 혼란스러운 작업 할당 동작을 만들 수 있습니다. 두 서비스 모두 내부 네트워크에서만 청취하며, 공용 인터넷에서 직접 통신하는 것은 없습니다.
함께 결합되면 이 네 요소는 장거리 render farm을 원격 머신이 아니라 아티스트 워크스테이션의 느린 LAN 확장처럼 느껴지게 만듭니다. 어느 것도 이국적이지 않으며, 가치는 이 요소들을 스택으로 적용하고 고객 트래픽이 실제로 지나는 경로에 맞게 매개변수를 튜닝하는 데 있습니다.
Cross-country 구성에 사용하는 배포 형태는 허브 앤 스포크 토폴로지입니다. 단일 주요 데이터센터를 허브로 두고, 하나 이상의 보조 사이트가 site-to-site WireGuard로 연결됩니다.
이 토폴로지에는 매번 반복되는 몇 가지 결정 사항이 있습니다.
엣지와 캐시는 세 대가 아니라 한 박스에서 동작합니다. 외부에서 WireGuard를 종단하는 동일한 Ubuntu 머신이 Samba 캐시, 내부 DNS, 시간 서비스도 호스팅합니다. 특정한 이유가 없는 한 이 역할을 여러 머신에 나누지 않습니다. 라이트사이징은 의도적입니다. 단일 전용 캐시 박스는 들어오는 네트워크 경로와 나가는 네트워크 경로가 각각 하나여서 라우팅 계산이 단순합니다. 또한 장애 모드를 추론하기 쉽습니다. 캐시가 살아 있으면 내부 서비스도 살아 있고, 죽으면 내부적으로 아무것도 동작하지 않습니다. 이 단일 신호는 세 개의 분리된 신호보다 알림을 걸기 더 쉽습니다.
Site-to-site WireGuard가 보조 위치를 처리합니다. 배포가 두 물리적 위치에 걸쳐 있을 때 — 예를 들어, 메인 데이터센터와 동일 메트로 내의 더 작은 임차 사이트 — 두 위치는 공용 ISP 위의 site-to-site WireGuard 터널로 연결됩니다. 호스트 관점에서 둘 사이의 트래픽은 하나의 큰 서브넷처럼 보입니다. 보조 사이트의 렌더 그룹 B는 메인 DC의 캐시를 그룹 A와 같은 방식으로 읽되, 홉이 더 많을 뿐입니다.
네트워크는 Layer-3 라우팅 가능합니다. 모든 노드는 다른 노드가 직접 주소 지정할 수 있는 실제 IP 호스트입니다. 특정 렌더 매니저를 강요하지 않습니다. Deadline을 선호하는 팀은 고객 측 코디네이터 노드에서 자체 Deadline 리포지토리를 운영할 수 있고, 다른 것을 선호하는 팀은 그것을 사용할 수 있습니다. 팜은 호스트, 네트워크, 캐시, 최적화 스택을 제공하며, 그 위의 오케스트레이션 계층은 고객의 선택입니다.
더 깊은 워크스루는 운영 배포 가이드가 전체 절차를 단계별로 다루며, 아키텍처 심층 분석이 WireGuard와 캐시 설계에 대해 더 자세히 들어갑니다.
대륙 간 대역폭은 두 가지 의미에서 비쌉니다. 클라우드 송신 청구서에 돈이 들고, 아티스트가 에셋이 파이프를 타고 내려오기를 기다릴 때 시간이 듭니다. 이 부분을 고려하지 않는 렌더 파일럿은 각 작업의 월타임 가운데 적지 않은 부분을 건물 내 다른 곳 캐시에 이미 있는 씬 파일을 콜드로 끌어오는 데 쓸 수 있습니다.
공유 캐시 패턴은 가장 단순하면서도 가장 큰 레버입니다. 메인 데이터센터의 Samba(SMB3) 캐시 서버가 프로젝트 에셋을 보관합니다. 각 렌더 노드는 캐시를 마운트하고 LAN으로 씬 파일을 읽습니다. 새 에셋이 작업에서 참조되면 캐시는 고객의 클라우드 스토리지에서 그것을 한 번만 끌어옵니다. 이후 그 에셋이 필요한 모든 노드는 LAN 사본에서 읽습니다. 같은 40 GB 씬 파일을 스무 번 끌어와야 했을 20 노드 파일럿이 한 번만 끌어옵니다.
원칙은 단순합니다. 실무에서는 설계의 두 부분이 중요합니다.
노드별 캐싱은 피합니다. 각 렌더 노드에 큰 로컬 SSD를 주고 원하는 것을 캐싱하게 두고 싶을 수 있습니다. 10 TB의 프로젝트 데이터가 있는 20 노드 파일럿에서 이는 공유 무효화 로직 없이 200 TB의 중복 스토리지가 됩니다. 우리는 그렇게 하지 않습니다. 공유 캐시가 유일한 캐시이며, 노드는 로컬 디스크를 스크래치 공간으로 취급하지 프로젝트 아카이브로 취급하지 않습니다.
D-day 전에 캐시를 미리 데워 둡니다. 고객이 프로젝트가 월요일에 시작한다고 알리면 우리는 주말 동안 캐시를 워밍합니다. 월요일의 첫 작업은 스무 시간의 콜드 풀을 일으키지 않고 따뜻한 캐시에서 읽습니다. 이는 프로젝트의 첫 렌더가 빠르게 느껴지게 하는 가장 신뢰할 만한 방법입니다.
라이트사이징에 대한 노트입니다. 캐시 박스는 ext4 파일시스템의 단일 SATA SSD를 사용합니다. 캐시의 경우 — 1차 스토리지와 달리 — 단일 디스크 구성이 올바른 트레이드오프입니다. 캐시는 진실의 원천이 아닙니다. 그것은 고객의 클라우드 스토리지이며, 캐시는 클라우드에서 다시 끌어오거나 프로젝트 백업에서 rsync로 재구성할 수 있습니다. 암호화된 볼륨 위에 중복 어레이를 구성하는 것은 비용과 복잡성을 더하지만 운영적 이야기를 바꾸지는 못합니다. 캐시를 잃은 노드는 하룻저녁의 재구성이지 데이터 손실 사건이 아닙니다. 캐시 하드웨어를 그 역할에 맞게 사이징하는 것은 운영 비용을 예측 가능하게 유지하는 가장 쉬운 방법 중 하나입니다.
단일 cross-country 배포가 아닌 영구 클러스터를 고려하는 팀은 dedicated cluster options 페이지에서 그 구성을 자세히 다룹니다.
Cross-country render farm이 보편적으로 더 나은 옵션은 아닙니다. 특정한 유형의 워크플로우에는 의미가 있고, 로컬 팜에 대비해 예측 가능한 트레이드오프를 가집니다.
GPU 노드를 인터랙티브하게 다뤄야 하는 아티스트의 경우 — 예를 들어 Cinema 4D 씬을 Redshift와 함께 열거나, IPR 프리뷰를 만들거나, 전체 작업을 제출하기 전 렌더 프레이밍을 하는 경우 — 우리는 Moonlight을 클라이언트로, Sunshine을 호스트로 사용합니다. 둘 다 렌더 노드의 GPU에서 NVENC 하드웨어 인코딩을 사용하여, 소프트웨어로 인코딩되는 원격 데스크톱 프로토콜보다 눈에 띄게 부드러운 스트림을 만들어냅니다. 잘 튜닝된 장거리 회선 위의 인코딩된 비디오는 고밀도 뷰포트 인터랙션을 포함해 실제 업무에 사용 가능한 경험을 제공합니다. 같은 워크로드를 일반 RDP로는 종종 그렇게 되지 않습니다. Parsec은 Sunshine이 세션 협상에 어려움을 겪는 드문 경우를 위한 폴백으로 구성되어 있습니다.
잘 튜닝된 대륙 간 회선은 통상 왕복 150~250 ms 사이에 자리합니다. 숫자는 지리적 분리와 고객 트래픽이 실제로 지나는 경로에 따라 달라집니다. 우리는 이 페이지에 특정 도시쌍 지연을 게시하지 않습니다. 그것은 일반화되지 않기 때문입니다. 고객의 ISP, 피어링, 로컬 홉이 우리가 인용할 수 있는 어떤 숫자만큼 경험을 좌우합니다. 계획 단계에서 후보 엔드포인트로부터 프로브를 돌려, 팀이 사용할 경로에 대한 실제 측정값을 공유해 드릴 수 있습니다.
우리의 cross-country 배포는 고객 자체 클라우드 플랫폼 위의 프로젝트 스토리지와 함께 현행 세대 컨슈머 GPU(RTX 5090급 하드웨어)를 사용해 20 노드 클러스터 규모로 운영되었습니다. 이는 앞 절들의 아키텍처 선택이 의미를 갖기 시작하는 대략적인 규모입니다. 더 작은 파일럿에서는 덜 최적화된 구성도 어느 정도 통할 수 있습니다.
Cross-country 렌더링은 아티스트가 분산되어 있고 렌더 파일럿이 어딘가에 있어야 할 때, 프로젝트 데이터가 이미 특정 클라우드 리전에 있을 때, 로컬 옵션이 제공하지 못하는 IP 격리 인프라가 필요할 때, 또는 GPU 가용성이나 비용이 특정 리전에 유리할 때 적합합니다.
팀 전원이 렌더 파일럿과 동일한 사무실이나 국가에서 일한다면 이 페이지의 최적화는 대부분 불필요한 오버헤드입니다. 더 짧은 파이프와 더 단순한 라우팅을 가진 로컬 팜이 운영하기 더 쉽고, BBR이나 MSS 클램핑의 혜택을 같은 방식으로 받지 않습니다. 정직한 대비 포지셔닝이 중요합니다. 모든 팀이 이 아키텍처를 필요로 하지는 않습니다. 아티스트와 렌더 하드웨어가 같은 리전에 자리할 수 있는 워크로드라면, 표준 render farm rental options 페이지가 그 경우를 잘 다룹니다.
일반적으로 잘 튜닝된 장거리 회선은 왕복 150~250 ms 범위에 자리하며, 정확한 수치는 아티스트의 ISP, 트래픽이 지나는 경로, 엔드포인트의 지리적 위치에 따라 달라집니다. 계획 단계에서 후보 워크스테이션으로부터 프로브를 돌려, 실제 경로에 대해 측정된 수치를 공유해 드릴 수 있습니다.
BBR 혼잡 제어가 주된 완화책입니다. 회선에 지터가 있을 때 처리량을 안정적으로 유지하며, 기본 CUBIC처럼 패킷 손실에 무너지지 않습니다. WireGuard 자체도 IPsec 터널처럼 세션 상태를 유지하지 않기 때문에 짧은 네트워크 끊김에 관대합니다. ISP 수준 장애의 경우, 업스트림 경로가 복구되는 즉시 터널이 재연결됩니다. 진행 중인 렌더 작업은 아티스트 연결 상태와 무관하게 팜 측에서 계속 실행됩니다.
네. 모든 링크는 WireGuard로 암호화됩니다. 아티스트 엔드포인트에서 메인 데이터센터까지, 그리고 메인 DC와 모든 보조 사이트 사이의 site-to-site 연결까지 마찬가지입니다. 공용 인터넷에서 관찰자가 팀과 렌더 파일럿 사이의 평문 트래픽을 읽을 수 있는 지점은 없습니다. 우리는 중간 전송 계층에 신뢰를 요구하지 않습니다. 암호화는 WireGuard 계층에 있으며, 옵션으로 위에 덧붙인 것이 아닙니다.
네. WireGuard 허브는 여러 피어를 받아들이므로, 임의의 수의 아티스트가 임의의 수의 위치에서 동시에 같은 팜에 연결할 수 있습니다. 각 아티스트는 자신의 워크스테이션에서 WireGuard 클라이언트를 실행하고, Moonlight을 열어, 자신에게 할당된 렌더 노드에 연결합니다. 캐시와 DNS 같은 내부 서비스는 파일럿 전체에서 공유되므로, 서로 다른 대륙에서 같은 씬을 작업하는 두 아티스트가 동일한 에셋 집합을 봅니다.
공유 SMB 캐시를 통해 처리합니다. 렌더 작업이 캐시가 아직 보지 못한 에셋을 참조하면, 캐시는 고객의 클라우드 스토리지에서 그것을 한 번만 끌어옵니다. 동일 에셋이 필요한 후속 노드는 캐시에서 LAN을 통해 회선 속도로 읽으며, 대륙 간 회선을 거치지 않습니다. 시작일을 예측할 수 있는 프로젝트의 경우, 우리는 D-day 전에 캐시를 미리 데워, 프로젝트의 첫 렌더가 콜드 풀 캐스케이드를 일으키는 대신 따뜻한 캐시의 이점을 누리도록 합니다.
방식은 동일하게 작동합니다. 지리적 분리는 캐시로의 초기 풀이 동일 리전 스토리지보다 더 오래 걸린다는 의미일 뿐입니다. 일단 에셋이 캐시에 들어오면 지리적 분리는 더 이상 중요하지 않습니다. 렌더 노드는 LAN으로 읽습니다. 이런 시나리오에서는 보통 캐시를 미리 데워, 크로스 리전 풀이 프로젝트 시작 전 우리 측에서 일어나도록 하고, 첫 렌더 중에 일어나지 않도록 합니다.
데이터 주재는 렌더 파일럿 자체가 프로비저닝되는 위치에 따라 달라지며, 이는 고객과 사전에 함께 계획합니다. 특정 주재 요구사항이 있는 팀의 경우, 프로젝트 데이터가 어디에 보관되는지, 렌더가 어디에서 생성되는지, 로그가 어디에 저장되는지, 계약 종료 시 데이터가 어떻게 삭제되는지를 다뤄야 합니다. 이는 단일한 예/아니오의 답이 아니라 계획 대화입니다. 사례의 구체적인 사항을 논의하려면 저희에게 연락해 주십시오.
렌더 자체는 계속됩니다. 렌더 작업은 아티스트 터널의 상태와 무관하게 팜 측에서 실행됩니다. 작업이 분배되면 아티스트는 완전히 연결을 끊을 수 있으며, 프레임은 계속 생성됩니다. 터널이 복구되면 아티스트는 WireGuard 피어를 재설정하고 Moonlight을 통해 동일 세션에 다시 연결합니다. 렌더 중간의 터널 끊김이 갖는 가장 흔한 실용적 영향은 단절 기간 동안 아티스트가 진행 상황을 실시간으로 모니터할 수 없다는 것입니다. 렌더 자체는 재시작되지 않습니다.
