NetDrive와 함께하는 VFX 및 3D 렌더링 스튜디오 — 로컬 복사 없는 렌더 팜
VFX 및 3D 렌더링 스튜디오가 NetDrive로 Google Cloud Storage를 드라이브로 마운트해 사전 동기화 없이 렌더 노드가 프레임과 텍스처를 읽는 방법.
한 중견 VFX 스튜디오는 캐시된 유체 시뮬레이션, EXR 프레임 시퀀스, 그리고 진행 중인 프로젝트 전반에서 30TB를 넘어 계속 커지는 공유 텍스처 라이브러리를 Google Cloud Storage에 보관하고 있습니다. 렌더 팜의 모든 렌더 노드가 이 라이브러리에 읽기 접근이 필요하지만, 작업을 시작하기 전에 전체 작업 세트를 각 머신에 다운로드하는 것은 로컬 스크래치 파일에 쓰일 수 있는 디스크 공간을 낭비하고, 동기화에 걸리는 시간만큼 모든 렌더링을 지연시킵니다. NetDrive로 버킷을 드라이브로 마운트하면 각 노드가 사전 렌더링 복사 단계 없이, 작업이 실제로 필요로 하는 프레임과 텍스처만 온디맨드로 읽을 수 있습니다.
렌더 팜 전체에서 클라우드 스토리지 마운트
NetDrive 는 Google Drive, OneDrive, S3, SFTP, WebDAV 등을 Windows 와 macOS 에서 일반 드라이브처럼 보이게 합니다 — 동기화도, 전체 다운로드도 없이.
- 읽기 전용 드라이브로 렌더 노드가 원본 자산을 건드리지 못하도록 보호
- 최대 1TB 캐시 크기 옵션으로 반복적인 텍스처 읽기를 흡수
- 부팅 시 자동 마운트로 사용자 세션 없이도 드라이브가 준비 상태 유지
무료 체험. 평생 라이선스와 구독 플랜 제공.
사전 동기화보다 온디맨드 접근이 나은 이유
렌더 팜 노드는 보통 동일하고 언제든 교체 가능하도록 프로비저닝됩니다 — 어떤 작업이든 어느 노드에서나 처리할 수 있다는 것이 기본 전제입니다. 이는 전체 자산 라이브러리를 로컬 디스크에 사전 동기화하는 방식과는 상충합니다. 작업이 50개 노드 중 어디로든 갈 수 있는 순간, 50개 모두가 거대하고 끊임없이 낡아가는 전체 로컬 복사본을 가지고 있어야 하거나, 매 작업이 시작되기 전에 동기화 단계가 실행되어야 하며, 이는 프레임당 몇 초밖에 걸리지 않을 렌더링에 몇 분의 유휴 시간을 더하게 됩니다.
NetDrive는 Google Cloud Storage 버킷을 네트워크 드라이브 또는 읽기 전용 드라이브로 마운트하며, 렌더 엔진은 R:\assets\textures\ 같은 평범한 파일 경로를 보게 됩니다. 프레임과 텍스처는 작업이 실제로 읽을 때만 전송되며, NetDrive의 캐싱은 최근에 사용된 파일을 버킷에서 매번 다시 가져오지 않고도 동일한 텍스처가 필요한 다음 작업에서 바로 사용할 수 있게 유지합니다.
렌더 노드를 위한 읽기 전용 자산 드라이브 설정하기
- NetDrive를 열고 Drive Manager에서 + Add Drive를 클릭합니다.
- 공급자 목록에서 Google Cloud Storage를 선택합니다.
- 샷 라이브러리 버킷으로 범위가 지정된 서비스 계정 자격 증명을 입력합니다 — 자산을 소비하기만 하는 노드에는 읽기 전용 IAM 역할로 충분합니다.
- 버킷 이름을 입력합니다.
- Drive Type에서 Read-only drive를 선택합니다. 렌더 노드는 원본 자산 버킷에 다시 써야 할 이유가 없으며, 읽기 전용 마운트는 잘못 구성된 작업이 실수로 공유 텍스처를 덮어쓸 가능성을 없애줍니다.
- 렌더 노드는 로그인된 워크스테이션이 아니라 무인 머신으로 동작하므로 Mount on을 Boot로 설정합니다.
- 드라이브 설정에서 캐시 크기를 늘립니다 — NetDrive는 (3.16.589에서 추가된) 100GB부터 1TB까지의 캐시 크기를 지원하며, 이는 하나의 시퀀스 안에서 여러 프레임에 걸쳐 같은 텍스처 세트를 반복해서 참조하는 렌더 노드에 중요합니다.
- Mount를 클릭합니다.
렌더링을 막지 않고 프레임 다시 쓰기
읽기 접근은 텍스처와 시뮬레이션 캐시를 다루지만, 완성된 프레임은 여전히 어딘가에 저장되어야 합니다. 출력 버킷에 대해 읽기-쓰기로 마운트된 두 번째 드라이브가 이 부분을 처리합니다. NetDrive의 백그라운드 업로드 모드는 완성된 프레임을 먼저 로컬 캐시에 기록한 뒤 비동기적으로 Google Cloud Storage에 업로드하므로, 렌더링 프로세스는 모든 쓰기 작업마다 네트워크 I/O로 멈추는 대신 곧바로 다음 프레임으로 넘어갈 수 있습니다.
이러한 분리 — 공유 자산 라이브러리를 위한 읽기 전용과, 출력을 위한 백그라운드 업로드가 포함된 읽기-쓰기 — 는 두 데이터 경로가 서로 간섭하지 않도록 해줍니다. 4K 텍스처를 읽는 렌더 노드는 동일한 연결 시맨틱을 두고 자신의 프레임 출력 큐와 경쟁하지 않습니다.
여러 노드로 확장하기
각 노드가 동일한 버킷을 독립적으로 마운트하기 때문에, 팜에 용량을 추가하는 일은 공유 스토리지 경합을 조율하는 문제가 아니라 동일한 NetDrive 드라이브 설정으로 다른 머신을 프로비저닝하는 문제가 됩니다. 각 노드가 자신만의 로컬 캐시만 유지하기 때문에, 작업 도중 노드가 오프라인이 되어도 공유 파일 시스템이 불일치 상태로 남지 않습니다 — 버킷 자체가 유일한 단일 진실 공급원으로 남습니다.
혼합 환경을 운영하는 스튜디오의 경우, 동일한 버킷이 Windows 렌더 노드와 macOS 아티스트 워크스테이션에 동일하게 마운트되므로, 샷을 검토하는 아티스트도 팜이 렌더링에 사용한 것과 같은 경로 구조에서 자료를 가져옵니다.
마무리
클라우드 스토리지를 드라이브로 마운트하면 렌더 팜이 Google Cloud Storage 버킷을 평범한 로컬 경로처럼 다룰 수 있으며, 읽기 전용 마운트는 원본 자산을 보호하고 백그라운드 업로드는 프레임 출력이 다음 렌더링을 막지 않도록 해줍니다. 기본이 되는 설정에 대해서는 Windows에서 NetDrive로 Google Cloud Storage 마운트하기 또는 macOS에서 NetDrive로 Google Cloud Storage 마운트하기를 참고하세요. CI 방식의 자동화된 렌더링 파이프라인을 운영하는 스튜디오라면, 무인 노드가 의존하는 부팅 시 마운트 패턴에 대해 CI 팀을 위한 S3 테스트 픽스처도 유용할 수 있습니다.
— Morgan, NetDrive