대륙 간 render farm 배포: 2026년 현장에서 얻은 여섯 가지 교훈

서론: 아키텍처 다이어그램은 거짓말을 하지만 프로덕션 로그는 그렇지 않습니다

깔끔한 아키텍처 설계도 대 지저분한 프로덕션 현실

기획 문서에서 그리는 아키텍처 다이어그램과 화요일 오후에 실제로 고객을 위해 렌더링을 실행하는 시스템 사이에는 간극이 있습니다. 우리가 배포한 모든 대륙 간 render farm은 그 간극을 어려운 방법으로 메웠습니다 — 우리 자신의 게이트웨이에서 우리를 잠가버린 명령어로, ICMP가 네트워크가 괜찮다고 말하는 동안 조용히 타임아웃되는 DNS 쿼리로, 깔끔하게 완료된 후 큰 패킷이 터널을 가로지르려는 순간 끊어진 TCP 핸드셰이크로.

이 문서는 render farm을 어떻게 구축하는지에 대한 튜토리얼이 아닙니다. 한 나라에 아티스트가 있고 다른 나라에 하드웨어가 도는 고객을 위해 전용 GPU 클러스터를 배포하면서 실제로 우리가 무엇을 부수고 고쳤는지에 대한 기록입니다. 여기서의 교훈은 의도적으로 운영적이며, 아키텍처적이지 않습니다. 벤더의 제품 페이지에 나타나지 않고 공개 컨퍼런스 토크에 거의 진입하지 않는 종류의 것입니다. 왜냐하면 엔지니어링보다는 현장 노트처럼 읽히기 때문입니다.

Super Renders Farm에서 fully managed cloud render farm을 10년 넘게 운영해왔습니다. 팀이 대륙을 가로지르는 전용 클러스터가 필요할 때 — 한쪽에 아티스트, 다른 쪽에 GPU — 이것은 우리가 세 번째 배포 후가 아니라 첫 번째 배포 전에 읽기를 바랐던 여섯 가지 교훈입니다. 또한 정직한 반대-교훈 섹션을 포함합니다: 우리가 시도하고, 거부하고, 의도적으로 배포하지 않은 컴포넌트들. 전체 그림을 원한다면 이 문서를 전체 운영 가이드 및 아키텍처 심층 분석과 함께 읽으십시오.

교훈 1: 듀얼-홈 게이트웨이 라우팅 함정

두 개의 네트워크 인터페이스 — 하나는 공개 인터넷 방향, 다른 하나는 내부 LAN 방향 — 가 있는 게이트웨이 머신을 처음 배포했을 때, 내부 라우트를 설정하기 전에 기본 라우트를 변경했습니다. 3초 안에 SSH 세션이 끊어졌습니다. 재연결할 수 없었습니다. 머신은 아웃-오브-밴드 콘솔이 없는 데이터센터 랙에 있었고, 돌아갈 유일한 길은 원격 핸즈 티켓이었습니다.

이것이 듀얼-홈 게이트웨이 라우팅 함정이며, 우리가 아는 모든 오퍼레이터를 최소 한 번은 물었습니다. 메커니즘은 단순합니다: 머신에 두 개의 NIC가 있을 때, 어떤 게이트웨이가 어떤 네트워크를 처리하는지 커널에 알려줘야 합니다. 기본 라우트를 공개 인터페이스를 가리키도록 변경하고 (외부 트래픽이 WireGuard 엔드포인트, NAT 출구, 또는 설계가 요구하는 곳을 통해 egress하도록), 내부 LAN을 위한 라우트를 아직 핀하지 않았다면, 내부 LAN을 통해 들어오는 SSH 세션은 갑자기 돌아갈 경로가 없어집니다. 노트북으로 돌려보내는 모든 패킷은 공개 인터페이스를 통해 떠나려 하고, 출발지 IP가 그 방향에서 의미가 없기 때문에 upstream 라우터에 의해 떨어지며, 터미널이 멈춥니다.

수정은 기계적입니다: 항상 내부 라우트를 먼저 설정한 다음, 기본을 변경합니다. Ubuntu 22.04를 실행하는 Linux 게이트웨이에서 그 순서는 대략 다음과 같습니다. 먼저 LAN 쪽 게이트웨이를 통해 LAN 서브넷에 대한 명시적 라우트를 추가합니다. 그런 다음, 그리고 그때만, 기본 라우트를 egress 설계가 요구하는 것으로 변경합니다.

# 1단계: LAN 쪽 게이트웨이를 통해 내부 LAN 라우트 핀
sudo ip route add 10.0.0.0/24 via 10.0.0.1 dev eth1

# 2단계: 지금만 기본 라우트 변경
sudo ip route replace default via <public-gateway-ip> dev eth0

실무에서 더 안전하게 만드는 두 가지 운영 습관이 있습니다. 첫째, 어떤 라우팅 변경에도 tmux 또는 screen 같은 도구를 사용합니다. 세션을 잃어도 작업은 연결 끊김에서 살아남고 재연결하는 순간 회복할 수 있습니다. 둘째, 기본 라우트를 건드리는 모든 게이트웨이 변경에 watchdog을 설정합니다: 취소하지 않으면 5분 안에 라우팅 테이블을 known-good 상태로 되돌리는 cron job. 그 cron job은 우리를 한 번 이상 원격 핸즈 티켓에서 구했습니다.

일반화할 수 있는 교훈은 어떤 듀얼-홈 머신에서도 운영의 순서가 최종 상태의 정확성보다 더 중요하다는 것입니다. 잘못된 순서로 적용된 동일한 구성은 올바른 순서로 적용된 동일한 구성과 다른 결과를 산출합니다 — 그리고 차이는 셸을 유지하느냐 아니냐입니다.

교훈 2: WireGuard와 DNS 구성 함정

렌더 노드가 게이트웨이로 WireGuard 터널을 엽니다. 터널이 올라옵니다. ICMP가 양방향으로 작동합니다 — 아티스트 쪽 오퍼레이터가 모든 내부 IP를 핑할 수 있습니다. 네트워크가 건강하다고 확신한 오퍼레이터는 렌더 작업을 실행합니다. 작업이 멈춥니다. 로그는 DNS 해결 타임아웃을 보여줍니다. 혼란이 자리잡습니다. 왜냐하면 오퍼레이터가 방금 모든 내부 주소를 핑 테스트했고 모두 응답했기 때문입니다.

이것이 WireGuard와 DNS 구성 함정입니다. 패턴은 대륙 간 render farm 배포에서 가장 직관에 반하는 디버깅 경험 중 하나입니다. 표준 "네트워크가 살아있는가?" 검사 (ICMP)가 녹색을 반환하는 동안 실제 사용자에게 보이는 실패는 다른 프로토콜 계층에서 일어나기 때문입니다.

근본 원인은 거의 항상 dnsmasq 입니다 — 또는 게이트웨이에서 실행하는 어떤 내부 DNS 리졸버든 — WireGuard 인터페이스에서 리스닝하도록 구성되지 않은 것입니다. 기본적으로 dnsmasq는 시작 시 알고 있는 인터페이스에 바인드됩니다. WireGuard 인터페이스 (wg0)는 dnsmasq 이후에 올라오고, 명시적으로 거기서 리스닝하도록 말하지 않는 한, 터널을 통해 도착하는 쿼리는 리졸버에 결코 도달하지 않습니다. 다른 모든 프로토콜 — ICMP, 내부 IP에 대한 TCP, IP 리터럴에 의한 직접 SMB 마운트 — 가 작동하는 동안 클라이언트에서 타임아웃됩니다.

수정은 dnsmasq 구성의 한 줄입니다:

# /etc/dnsmasq.conf
interface=wg0
interface=eth1
bind-interfaces

bind-interfaces 지시문도 똑같이 중요합니다. 그것 없이 dnsmasq는 와일드카드 0.0.0.0에서 리스닝하며, 이는 많은 경우 작동하지만 일부 방화벽 구성과 잘못 상호작용합니다. 어떤 인터페이스가 DNS를 제공하는지 명시적인 것이 더 안전합니다.

진단 함정은 위험한 부분입니다. ICMP가 작동할 때 자연스러운 인간 본능은 네트워크를 제외하고 애플리케이션 계층을 보는 것입니다. 이 디버그 경로가 시간을 먹는 것을 보았습니다: 오퍼레이터가 렌더 노드에서 방화벽 규칙을 추적하고, 라이선스 서버를 확인하고, 오래된 Deadline 구성을 의심하고, 마침내 — 세 시간 후 — 아티스트 쪽에서 dig @internal-dns-ip cache.lan을 실행하고 타임아웃을 얻습니다. 이 디버그 세션을 한 번 하면 절대 잊지 않습니다. 일반 교훈: 네트워크 건강 smoke test에 DNS 해결을 추가합니다. ICMP만으로는 충분하지 않습니다.

교훈 3: 긴 터널을 위한 TCP MSS clamping

세 번째 교훈은 본 적이 없을 때 가장 많은 시간이 드는 것입니다. 실패 모드가 다른 모든 것과 같아 보이기 때문입니다. 작은 작업이 작동합니다. SSH 세션이 연결을 유지합니다. 포트로의 telnet이 성공합니다. 짧은 HTTP GET이 헤더를 반환합니다. 그런 다음 누군가가 터널을 통해 SMB 공유를 마운트하려 하거나, TLS 핸드셰이크를 시작하거나, RDP 세션을 시작합니다 — 그리고 연결이 영원히 멈춥니다. 오류 없음, 리셋 없음, 그저 침묵.

이것이 MTU 블랙홀 문제이며, 긴 터널에서는 그것에 대해 무언가를 하지 않으면 본질적으로 보장됩니다. WireGuard는 암호화된 봉투와 헤더를 위해 모든 패킷에 약 60바이트의 오버헤드를 추가하여, 터널 내부의 유효 MTU를 표준 1500바이트 이더넷 MTU 아래로 떨어뜨립니다. 두 엔드포인트가 풀-사이즈 패킷을 터널을 통해 보내려 할 때, 중간 라우터는 그것을 분할하거나 (종종 허용되지 않음) 송신자가 더 작게 재시도하도록 ICMP "Fragmentation Needed" 메시지를 돌려보냅니다.

ICMP Fragmentation Needed 메시지는 일상적으로 중간 방화벽에 의해 떨어집니다. path MTU discovery가 이런 식으로 깨지면, 송신자는 터널을 가로지르는 데 조용히 실패하는 oversized 패킷을 계속 보냅니다. 작은 패킷은 통과합니다; 큰 패킷 — 서버 인증서를 운반하는 TLS 핸드셰이크, SMB 협상, RDP 프레이밍 — 은 사라집니다. 세션은 절대 도착하지 않을 응답을 기다립니다.

수정은 TCP MSS clamping입니다. WireGuard 게이트웨이에서 mangle 테이블에 iptables 규칙을 추가하는데, 이 규칙은 wg0을 통해 나가는 모든 패킷에서 TCP MSS 옵션을 path MTU가 실제로 지원하는 것으로 다시 씁니다. 계산은 커널이 처리합니다:

sudo iptables -t mangle -A FORWARD -o wg0 \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

사용자보다 먼저 이를 잡기 위한 진단은 직설적입니다: 터널을 통해 의도적으로 큰 패킷을 보내고 무엇이 일어나는지 봅니다. don't-fragment 비트가 설정된 ping -s 1400은 MSS clamping이 없고 PMTUD가 깨졌다면 실패합니다. 이를 교훈 2의 DNS 검사와 함께 배포 smoke test에 추가합니다. 두 실패가 함께 우리가 분류하는 "네트워크가 작동하지만 앱은 안 됨" 보고서의 대부분을 다루기 때문입니다.

일반화할 수 있는 교훈은 어떤 터널된 오버레이에서도 "TCP가 작동한다"가 "TCP가 큰 페이로드에 대해 작동한다"와 같지 않다는 것입니다. 네트워크가 건강하다고 선언하기 전에 항상 큰 패킷을 엔드-투-엔드로 테스트합니다.

교훈 4: 적정 사이징 대 과잉 엔지니어링

전용 렌더 클러스터를 설계하려 앉을 때, 하이퍼스케일러 백서에서 찾을 종류의 스토리지 스택을 명시하려는 운영적 유혹이 있습니다. 중복성을 위해 네 개의 드라이브에 걸친 RAID 10, 미사용 시 암호화를 위한 LUKS, 누군가가 XFS가 큰 파일을 더 잘 처리한다고 한 번 말했기 때문에 캐시 파일시스템을 위한 XFS. 다이어그램은 인상적으로 보입니다. 부품 명세는 필요하지 않았던 세 개의 드라이브와 컨트롤러를 추가합니다. 그리고 추가된 모든 계층은 실패할 수 있는 또 하나의 계층입니다.

우리가 한 대륙 간 배포 중 하나에서 원래 계획은 정확히 그 스택을 요구했습니다. 배포된 현실은 ext4와 미사용 시 암호화 없이 단일 8 TB SATA SSD였습니다. 캐시 서버는 WireGuard 뒤에 있고, 그 위의 데이터는 며칠이 아닌 몇 시간 안에 클라우드 스토리지에서 재생 가능하며, 고객의 위협 모델은 여러 네트워크 격리 계층 뒤의 데이터센터 랙에 대한 물리적 공격자 접근을 포함하지 않았습니다. RAID 10은 배포가 가지지 않은 문제를 해결했습니다. LUKS는 클라우드 쪽 스토리지가 이미 제공한 암호화를 복제했습니다. XFS는 ext4가 잘 처리하는 워크로드 (캐시된 장면 자산의 순차 읽기) 에 대한 파일시스템 선택을 추가했습니다.

우리가 지금 적용하는 일반 규칙: 계층이 실제 배포의 실제 실패 모드를 수정하지 않는 한 계층을 추가하지 마십시오. 마스터 데이터가 클라우드 스토리지에 있고 전체 캐시 재워밍이 몇 시간 걸릴 때, 캐시 서버의 스토리지 중복성은 불필요합니다. 콘텐츠가 이미 전송 중과 클라우드 소스에서 암호화된 하드웨어에 대한 미사용 시 암호화는 불필요합니다. 워크로드가 기본 선택의 테스트된 봉투 안에 잘 들어맞을 때, 이론적 벤치마크 때문에 덜 일반적인 파일시스템을 선택하는 것은 불필요합니다.

우리가 인정한 트레이드오프: 단일 SSD는 클러스터 상에 중복성이 없습니다. 그 드라이브가 실패하면, 복원할 때까지 캐시는 사라집니다. 우리의 완화책은 직설적입니다 — 별도 NAS로의 야간 rsync, SSD의 SMART 카운터 모니터링, 그리고 SLA 창 내에 클라우드 스토리지에서 캐시를 재구축하는 문서화된 재워밍 절차. 요점은 중복성이 나쁘다는 것이 아닙니다; 요점은 중복성이 기본 반사가 아니라 명확히 표현할 수 있는 실패 모드를 수정하는 곳에 속한다는 것입니다.

과잉 엔지니어링은 또한 운영 가독성 비용이 있습니다. 모든 계층은 다음 오퍼레이터가 디버그하기 위해 이해해야 하는 계층입니다. 단일 SSD 상의 단일 ext4 파일시스템은 모든 Linux 오퍼레이터가 제1원칙에서 트러블슈팅할 수 있는 것입니다. 배포가 무인으로 실행되고 원격 오퍼레이터가 새벽 2시에 복구해야 할 때, 더 단순한 것이 이깁니다.

교훈 5: D-Day 전에 캐시를 사전 워밍

다가오는 마감의 빛을 앞두고 빛으로 채워지는 저수지

render farm은 고객의 첫 프로덕션 날까지 놓치기 쉬운 콜드 스타트 문제를 숨깁니다. 첫째 날, 20개의 렌더 노드가 처음으로 온라인이 되어 필요한 자산을 가져오기 시작합니다. 캐시가 비어 있으면, 그 노드 각각이 동시에 클라우드 스토리지를 두드리고 같은 upstream 대역폭을 위해 경쟁합니다. 클라우드 쪽 rate limit이 시작됩니다. 공유된 인터넷 파이프가 포화됩니다. 렌더 큐가 멈춥니다. 고객의 클러스터에 대한 첫 인상은 이전 워크스테이션보다 느리다는 것입니다.

이것이 cold-pull 문제이며, 완전히 예방 가능합니다. 해결책은 고객의 첫 예정된 렌더 24-48시간 전에 캐시를 사전 워밍하는 것입니다. 메커니즘은 단순합니다: D-day에 앞서 고객과 함께 자산 목록을 얻습니다 — 참조될 프로젝트 파일, 텍스처, 시뮬레이션 캐시, 플러그인 라이브러리. 클러스터에 프로덕션 부하가 없는 동안 그 모든 것을 캐시 서버로 끌어와서, 첫째 날에 렌더 노드가 로컬 LAN에서 그들을 기다리는 따뜻한 캐시를 발견하도록 합니다.

사전 워밍 패스는 또한 smoke test 역할도 합니다. 자산 목록이 해결되지 않는 경로를 포함하면, 첫 렌더의 패닉 대신 사전 워밍 창의 평온함에서 발견합니다. 고객의 클라우드 계정과 가져오는 스토리지 경로 사이에 권한 문제가 있다면, 그것도 발견합니다. 자산 목록이 캐시에 맞지 않는 볼륨에 도달하면, 캐시를 재조정하거나 더 좁은 범위를 협상할 시간이 있습니다. 이러한 대화 중 어느 것도 렌더 큐가 이미 제출된 때 처음 일어나서는 안 됩니다.

관련 관행: 프로덕션 배치가 들어가기 전에 작은 프레임 배치로 smoke-test 렌더. 0일째에 파이프라인을 통해 엔드-투-엔드로 풀 품질의 20프레임. 무언가가 잘못 구성되면 — 누락된 플러그인 라이선스, 잘못된 출력 경로, 아티스트의 워크스테이션과 클러스터 간의 OCIO drift — smoke test가 그것을 표면으로 가져옵니다. 20프레임은 2,000프레임 프로덕션 배치의 800번째 프레임에서 동일한 문제를 찾는 것에 대한 저렴한 보험입니다.

일반 교훈: 새로운 클러스터에서의 첫 렌더는 항상 정상 상태보다 느리고 오류 발생 가능성이 높습니다. 그 주변을 설계합니다. 클러스터를 차갑게 전달하지 마십시오.

교훈 6: 문서화는 운영 도구이지 사후 생각이 아닙니다

여섯 번째 교훈은 보너스 교훈입니다. 기술 패턴보다는 배포가 팀이 나중에 지원할 수 있는 것이 되는 방법에 관한 것이기 때문입니다. 우리는 배포 중에 runbook을 만들고 배포 후가 아니라는 것을 배웠습니다.

우리가 운영하는 모든 배포는 실시간 빌드 로그를 생성합니다: 시간순 항목의 번호 매겨진 changelog, 실제로 실행된 명령, 실제로 돌아온 출력, 그리고 왜 특정 결정이 내려졌는지에 대한 오퍼레이터 코멘트와 함께. 우리는 이 로그를 회고적으로 쓰지 않습니다. 그때는 세부 사항이 이미 사라졌기 때문입니다. 우리는 일하면서 그것을 쓰고, 실행 중인 인프라와 동등한 무게의 deliverable로 취급합니다.

빌드 로그에는 두 명의 청중이 있습니다. 첫째는 클러스터를 만질 다음 오퍼레이터입니다 — 보통 팀 동료, 가끔은 그것을 설정한 오퍼레이터의 미래 버전. 둘째는 고객으로, 빌드 로그를 깨끗한 as-built 참조, 무언가 깨질 때의 복구 절차, 그리고 팀이 소유한 것과 우리가 소유한 것 사이의 운영 경계로 증류하는 인수인계 문서의 형태입니다.

배포 중 문서화의 비용은 배포 시간의 약 15퍼센트입니다. 문서화하지 않는 비용은 무언가가 복구되어야 할 때마다 지원 사이클, 그리고 시스템을 인수하는 팀 동료에 대한 가파른 학습 곡선입니다. 빌드 로그는 매번 첫 달 안에 자체적으로 비용을 회수했습니다.

정직한 반대-교훈: 우리가 하지 않은 것

어떤 운영 보고서에도 최종 스택을 처음부터 명백한 선택인 것처럼 묘사하려는 유혹이 있습니다. 거의 그렇지 않습니다. 다음은 우리가 고려하고, 시도하고, 또는 의도적으로 배포하지 않은 컴포넌트입니다 — 우리가 이미 수행한 실험을 반복하는 데 사이클을 낭비하지 않도록 포함됩니다.

원격 데스크톱을 위해 RustDesk를 배포하지 않았습니다. RustDesk는 일반 사무실 작업에 사용할 만하지만, 스트리밍 품질과 색상 충실도는 3D와 GPU 렌더링에 필요한 곳이 아니었습니다. 아티스트는 텍스처 표면의 압축 아티팩트와 뷰포트 미리보기의 색상 이동을 알아챘습니다. 대신 NVIDIA NVENC 하드웨어 인코딩을 사용하고 고프레임률 고품질 스트리밍을 위해 설계된 Moonlight + Sunshine에 표준화했습니다. Parsec은 합리적인 fallback입니다; RustDesk는 이 워크로드에 맞지 않습니다.

BBR 버전 3을 배포하지 않았습니다. TCP BBR은 커널 기본보다 길고 jitter가 있는 국제 링크를 더 잘 처리하는 혼잡 제어 알고리즘입니다. 우리는 그것을 사용합니다 — 하지만 BBR 버전 1을 사용하고, 버전 3은 아닙니다. BBRv3는 더 새롭고, 이론적으로 개선되었으며, 고객의 프로덕션 데드라인 앞에 두기에 아직 커널 성숙도에 있지 않습니다. BBRv1은 잘 이해되어 있고, 현대 Linux 커널에 표준으로 제공되며, 작업을 수행합니다.

edge 라우터를 NAS의 VM으로 실행하지 않았습니다. 이전 계획은 캐시를 호스팅하는 동일한 Network Attached Storage 박스에서 실행되는 가상 머신에 edge 게이트웨이를 통합하는 것을 고려했습니다. 현실은 관심사의 분리입니다: edge 라우터와 캐시가 동일한 물리적 머신에 있을 때, NAS의 커널 업데이트가 게이트웨이도 다운시킵니다. 잘못 작동하는 디스크가 게이트웨이의 I/O를 굶길 수 있습니다. 캐시 작업을 수행하고 다른 것은 하지 않는 전용 캐시 박스가 운영적으로 더 깨끗합니다.

AWS Global Accelerator나 Cloudflare Tunnel을 배포하지 않았습니다. 둘 다 합리적인 선택적 컴포넌트이며, 어느 쪽이든 일부 고객의 레이턴시를 줄일 것입니다. 그것들은 또한 baseline에 불필요합니다. BBR과 MSS clamping이 있는 WireGuard 터널은 한계 개선이 운영 복잡성을 정당화하지 않을 만큼 긴 국제 링크를 충분히 잘 처리합니다. 우리는 아키텍처 문서에서 Global Accelerator와 Cloudflare Tunnel을 phase 2 선택적 컴포넌트로 명시했지만, 어느 것도 기본 대륙 간 빌드와 함께 출시되지 않았습니다. 고객의 레이턴시 요구사항이 baseline이 지원할 수 있는 것보다 더 엄격해진다면, 다시 방문합니다. 그때까지 필요하지 않은 것은 배포하지 않습니다.

일반적인 반대-교훈: 정직한 배포 보고서는 출시되지 않은 것을 포함해야 합니다. 그렇지 않으면 다음 오퍼레이터는 최종 스택이 불가피했다고 가정하고, 우리가 이미 비용을 지불한 실험을 반복합니다.

자주 묻는 질문

Q: 20노드 전용 대륙 간 render farm 클러스터를 배포하는 데 얼마나 걸립니까? A: 하드웨어 조달부터 고객 준비 완료 클러스터까지, 우리의 일반적인 타임라인은 2-4주에 걸쳐 진행됩니다. 하드웨어 빌드와 OS 이미징은 예측 가능한 부분입니다. 네트워크 구성 — WireGuard, BBR, MSS clamping, DNS, NTP, 방화벽 — 은 며칠을 추가합니다. 사전 워밍과 smoke testing은 하루 이틀을 더 소비합니다. 가변성은 고객 쪽 전제 조건에서 옵니다: 클라우드 계정 액세스 프로비저닝, 자산 목록 합의, 그리고 아티스트 클라이언트 설정 정렬.

Q: 배포 지연의 가장 흔한 원인은 무엇입니까? A: 고객 쪽 자격 증명과 액세스 프로비저닝. 인프라 작업은 예정대로 진행됩니다. 병목은 일반적으로 고객의 클라우드 스토리지 자격 증명을 보안 정책과 호환되는 방식으로 클러스터에 가져오는 것, 그리고 아티스트 쪽 클라이언트 도구 (WireGuard, Moonlight) 를 아티스트가 실제로 사용할 워크스테이션에 설치하는 것입니다. 우리는 그 대화를 마지막 주가 아니라 1일차에 시작하는 법을 배웠습니다.

Q: 내 자신의 DIY render farm 설정에 이 교훈을 따를 수 있습니까? A: 네. 여기서의 교훈은 인프라 패턴이지 비즈니스 비밀이 아닙니다. 듀얼-홈 라우팅 함정, DNS 함정, MSS clamping, 적정 사이징 규율 모두 10노드든 200노드든 모든 cross-network 배포에 적용됩니다. 인프라를 직접 운영하기를 원하지 않는다면, 우리의 fully managed render farm이 공유 인프라에서 이 모든 것을 처리하고, 우리의 전용 클러스터 제공은 자신만의 하드웨어를 원하는 고객을 위해 동일한 일을 합니다.

Q: 호스팅 서비스와 별도로 render farm 인프라에 대한 컨설팅을 제공합니까? A: 컨설팅 시간을 판매하기보다 인프라를 직접 운영하는 데 집중합니다. 구축 대 렌트를 저울질하는 팀을 위해, 우리의 build versus cloud total cost 가이드가 경제를 설명하며, 팀은 우리 하드웨어에서 전용 클러스터를 평가하는 잠재 고객과 아키텍처 질문을 논의하기를 기뻐합니다.

Q: 거리 측면에서 수행한 가장 긴 대륙 간 render farm 배포는 무엇입니까? A: 오늘 우리가 운영하는 배포는 대륙을 가로지릅니다 — 아티스트는 북미에서 작업하고 렌더링 하드웨어는 동남아시아에서 실행됩니다. 링크가 길수록 이 교훈이 더 중요합니다. 짧은 LAN 전용 배포는 MSS clamping과 사전 워밍을 무시할 수 있습니다. 대륙을 가로지르는 배포는 할 수 없습니다.

Q: 이 교훈이 여전히 적용되는 가장 작은 클러스터 크기는 무엇입니까? A: 이 패턴 대부분은 20번째 노드가 아니라 첫 번째 노드부터 중요합니다. 듀얼-홈 라우팅 함정은 인터페이스가 두 개 이상인 모든 게이트웨이에 적용됩니다. DNS 플러스 WireGuard 함정은 내부 이름 해결이 있는 모든 터널 오버레이에 적용됩니다. MSS clamping 요구사항은 의미 있는 길이의 터널을 가로지르는 모든 TCP 트래픽에 적용됩니다. 캐시 사전 워밍은 노드 수가 증가함에 따라 더 중요해집니다. 왜냐하면 cold-pull 대역폭 경쟁이 동시에 클라우드를 두드리는 노드 수에 따라 확장되기 때문입니다.