하이브리드 렌더링 작업장 빌드

이 문서에서는 Google Cloud에서 컴퓨팅 리소스를 사용하도록 기존 온프레미스 렌더링 작업장을 확장하는 방법을 설명합니다. 이 문서에서는 사용자가 이미 온프레미스 렌더링 작업장을 구현했으며 시각적 효과(VFX)와 애니메이션 파이프라인, 큐 관리 소프트웨어, 일반적인 소프트웨어 라이선스 방법에 익숙하다고 가정합니다.

개요

애니메이션, 영화, 광고, 비디오 게임을 위해 2D 또는 3D 요소를 렌더링하려면 많은 컴퓨팅과 시간이 필요합니다. 이러한 요소를 렌더링하려면 하드웨어 및 인프라에 대폭 투자해야 하며 전담 IT 전문가 팀이 하드웨어와 소프트웨어를 배포하고 유지관리해야 합니다.

온프레미스 렌더링 작업장이 100% 활용될 때는 작업을 관리하는 것이 어려울 수 있습니다. 작업 우선순위 및 종속 항목, 중단된 프레임의 재시작, 네트워크/디스크/CPU 부하를 면밀히 모니터링하고 제어해야 하며, 종종 기한도 빠듯합니다.

이러한 작업을 관리하기 위해 VFX 시설은 대기열 관리 소프트웨어를 파이프라인에 통합했습니다. 대기열 관리 소프트웨어로 다음을 수행할 수 있습니다.

온프레미스 및 클라우드 기반 리소스에 작업을 배포합니다.
작업 간 종속 항목을 관리합니다.
애셋 관리 시스템과 통신합니다.
사용자에게 Python과 같이 보편적인 언어를 위한 API 및 사용자 인터페이스를 제공합니다.

일부 대기열 관리 소프트웨어가 작업을 클라우드 기반 작업자에게 배포할 수도 있지만 클라우드에 연결하고, 애셋을 동기화하고, 저장소 프레임워크를 선택하고, 이미지 템플릿을 관리하고, 자체적인 소프트웨어 라이선스를 제공하는 것은 여전히 개발자의 몫입니다.

하이브리드 렌더링 작업장을 구현하기 위한 기술적 리소스가 부족한 일부 중소규모 시설은 Conductor 같은 클라우드 기반 렌더링 작업장 서비스를 사용할 수 있습니다. 시설에 알맞은 솔루션을 파악하려면 Google Cloud 담당자에게 문의하세요.

참고: 이 문서에는 프로덕션 참고사항이 자주 나옵니다. 이 참고사항은 렌더링 작업장을 구축할 때 따라야 할 권장사항을 제시합니다.

클라우드에 연결

워크로드에 따라 파트너 ISP, 직접 연결 또는 공개 인터넷을 통해 시설을 Google Cloud에 연결하는 방법을 결정합니다.

인터넷을 통해 연결

특별한 연결없이 인터넷으로 Google Cloud 서비스에 액세스하여 Google의 네트워크에 연결하고 엔드 투 엔드 보안 모델을 활용할 수 있습니다. gcloud 및 gsutil 명령줄 도구와 같은 유틸리티와 Compute Engine API와 같은 리소스 모두 보안 인증, 승인, 암호화를 사용하여 데이터를 보호합니다.

Cloud VPN

어떤 방법으로 연결했건 간에 가상 사설망(VPN)을 사용하여 연결을 보호하는 것이 좋습니다.

Cloud VPN은 IPsec VPN 연결을 통해 온프레미스 네트워크를 Google Virtual Private Cloud(VPC) 네트워크에 안전하게 연결합니다. 전송 중인 데이터는 암호화된 후에 하나 이상의 VPN 터널을 통해 전달됩니다.

프로젝트의 VPN을 만드는 방법에 대해 알아보세요.

고객 제공 VPN

자체 VPN 게이트웨이를 설정하여 Google과 직접 연결할 수 있지만, 유연성을 높이고 Google Cloud와 더 긴밀히 통합하기 위해서는 Cloud VPN을 사용하는 것이 좋습니다.

Cloud Interconnect

Google에서는 인프라를 Google Cloud에 연결하는 다양한 방법을 지원합니다. 통칭 Cloud Interconnect라고 하는 이러한 엔터프라이즈급 연결은 표준 인터넷 연결보다 가용성이 높고 지연 시간이 짧아 이그레스 가격이 저렴합니다.

Dedicated Interconnect

Dedicated Interconnect는 온프레미스 네트워크와 Google 네트워크 간의 직접적인 실제 연결과 RFC 1918 통신을 제공합니다. Dedicated Interconnect는 다음 연결 유형을 통해 연결 용량을 제공합니다.

하나 이상의 10Gbps 이더넷 연결 및 최대 8개의 연결 또는 상호 연결당 총 80Gbps
하나 이상의 100Gbps 이더넷 연결 및 최대 2개의 연결 또는 상호 연결당 총 200Gbps

Dedicated Interconnect는 암호화되지 않습니다. 따라서 Dedicated Interconnect를 통해 안전하게 데이터를 전송해야 하는 경우에는 자체적인 VPN 연결을 설정해야 합니다. Cloud VPN은 Dedicated Interconnect와 호환되지 않으므로, 이 경우 자체 VPN을 제공해야 합니다.

Partner Interconnect

Partner Interconnect는 지원되는 서비스 제공업체를 통해 온프레미스 네트워크와 VPC 네트워크 간의 연결을 제공합니다. Partner Interconnect는 인프라가 Dedicated Interconnect 코로케이션 시설에 닿을 수 없는 물리적 위치에 있거나 데이터에 굳이 완전한 10Gbps 연결이 필요하지 않을 경우에 유용합니다.

기타 연결 유형

특정 지역에서는 다른 연결 방법을 통해 Google에 연결할 수도 있습니다. Google Cloud에 연결하는 가장 효과적이고 경제적인 방법을 확인하려면 Google Cloud 담당자에게 문의하세요.

콘텐츠 보안

대표적인 헐리우드 스튜디오와 같은 콘텐츠 소유자는 퍼블릭 클라우드 플랫폼에서 콘텐츠를 실행하기 위해 내부와 외부(예: MPAA) 모두에서 정의된 보안 권장사항을 준수해야 합니다.

각 스튜디오는 보안 렌더링 워크로드 요구사항이 서로 다릅니다. cloud.google.com/security에서 보안 백서 및 규정 준수 문서를 찾을 수 있습니다.

보안 규정 준수 감사 프로세스에 대한 질문이 있으면 Google Cloud 담당자에게 문의하세요.

프로젝트 정리

프로젝트는 Google Cloud의 핵심적인 조직 구성요소입니다. 시설에서는 자체 프로젝트 아래에 작업을 정리하거나 작업을 프로젝트 여러 개로 나눌 수 있습니다. 예를 들어 영화의 사전 시각화, 연구 개발, 프로덕션 단계에 별도의 프로젝트를 만들 수 있습니다.

프로젝트는 네트워크 데이터 및 프로젝트 관리를 위한 격리 경계를 설정합니다. 하지만 공통 리소스에 액세스할 수 있는 별도의 프로젝트를 제공하는 공유 VPC를 통해 프로젝트 간에 네트워크를 공유할 수 있습니다.

프로덕션 참고사항: 리소스와 모든 프로덕션 도구를 포함하는 공유 VPC 호스트 프로젝트를 만드세요. 조직 내에서 생성된 모든 프로젝트를 공유 VPC 서비스 프로젝트로 지정할 수 있습니다. 이렇게 지정하면 조직 내 모든 프로젝트가 호스트 프로젝트에서 제공하는 같은 라이브러리, 스크립트, 소프트웨어에 액세스할 수 있습니다.

조직 리소스

이미 설정되어 있을 수도 있는 조직 리소스 아래에서 프로젝트를 관리할 수 있습니다. 모든 프로젝트를 조직에 마이그레이션하면 여러 가지 이점이 있습니다.

프로덕션 참고 사항: 프로덕션 관리자를 개별 프로젝트의 소유자로, 스튜디오 관리자를 조직 리소스의 소유자로 지정하세요.

리소스에 대한 액세스 권한 정의

프로젝트에는 리소스에 대한 보안 액세스와 더불어 사용자 또는 서비스가 작업할 수 있는 곳에 대한 제한사항이 필요합니다. Google Cloud는 액세스 권한을 정의하는 데 도움을 주기 위해 Identity and Access Management(IAM)를 제공합니다. IAM은 리소스에 대한 액세스 권한 수준을 역할별로 정의하여 액세스 제어를 관리하는 데 사용할 수 있습니다.

프로덕션 참고 사항: 사용자가 역할을 기준으로 특정 작업을 수행하는 데 필요한 리소스에만 액세스할 수 있도록 제한하려면 온프레미스와 클라우드 모두에서 최소 권한 원칙을 구현하세요.

예를 들어 커스텀 이미지를 사용하는 사전 정의된 인스턴스 템플릿에서 배포할 수 있는 가상 머신(VM)인 렌더링 작업자를 고려해보세요. 서비스 계정 아래에서 실행 중인 렌더링 작업자는 Cloud Storage에서 읽고 클라우드 파일러나 영구 디스크와 같은 연결된 스토리지에 쓸 수 있습니다. 하지만 개별 아티스트는 클라우드 리소스에 직접 액세스할 필요가 없으므로 이들을 Google Cloud 프로젝트에 추가할 필요가 없습니다.

모든 Compute Engine 리소스에 액세스할 수 있는 렌더 랭글러 또는 프로젝트 관리자에게 역할을 할당하여 다른 사용자가 액세스할 수 없는 리소스를 활용하도록 할 수 있습니다.

이러한 역할이 액세스할 수 있는 조직 내의 리소스 유형을 결정하는 정책을 정의합니다. 다음 표는 일반적인 프로덕션 작업이 Google Cloud의 IAM 역할에 매핑되는 방법을 보여줍니다.

프로덕션 작업	역할 이름	리소스 유형
스튜디오 관리자	`resourcemanager.organizationAdmin`	조직 프로젝트
프로덕션 관리자	`owner`, `editor`	프로젝트
렌더 랭글러	`compute.admin`, `iam.serviceAccountActor`	프로젝트
큐 관리 계정	`compute.admin`, `iam.serviceAccountActor`	조직 프로젝트
개별 아티스트	[액세스 권한 없음]	해당 없음

액세스 범위

액세스 범위는 누가 로그인되어 있는지 관계없이 실행 중인 인스턴스의 권한을 제어할 수 있도록 해줍니다. 인스턴스를 직접 만들 때 또는 대기열 관리 소프트웨어가 인스턴스 템플릿으로부터 리소스를 배포할 때 범위를 지정할 수 있습니다.

범위는 개별 사용자 또는 서비스 계정의 IAM 권한보다 우선합니다. 이 우선순위는 액세스 범위를 설정함으로써 프로젝트 관리자가 인스턴스에 로그인하여 저장소 버킷을 삭제하거나 방화벽 설정을 변경하는 것을 방지할 수 있음을 의미합니다.

프로덕션 참고사항: 기본적으로 인스턴스는 Cloud Storage를 읽을 수 있지만 여기에 쓸 수는 없습니다. 렌더링 파이프라인이 완성된 렌더를 Cloud Storage에 다시 쓰는 경우 생성 시 devstorage.read_write 범위를 인스턴스에 추가하세요.

리소스 배포 방법 선택

클라우드 렌더링의 경우, 필요할 때만 리소스를 사용할 수 있지만 렌더링 작업장에서 이용 가능한 여러 가지 방법 중에서 선택할 수 있습니다.

주문형 배포

최적의 리소스 사용을 위해 렌더링 작업장에 작업을 보낼 때만 렌더링 작업자를 배포하도록 선택할 수 있습니다. 작업의 모든 프레임에서 공유될 여러 VM을 배포할 수도 있고, 한 프레임에 한 VM을 만들 수도 있습니다.

대기열 관리 시스템은 실행 중인 인스턴스를 모니터링하면서 VM이 선점된 경우에는 대기열에 다시 입력하고 개별 작업이 완료되면 종료할 수 있습니다.

리소스 풀 배포

온프레미스 대기열 관리 시스템이 추가 리소스로 액세스할 수 있는 인스턴스 그룹을 특정 작업과 관련없이 배포할 수도 있습니다. 실행 중인 인스턴스 그룹은 주문형 전략보다 덜 경제적이지만 모든 코어를 사용하고 리소스 사용을 극대화함으로써 한 VM에서 여러 작업을 수용할 수 있습니다. 이 접근 방식은 온프레미스 렌더링 작업장에 작업을 채우는 방법을 그대로 따르기 때문에 구현하기에 가장 간단한 전략입니다.

소프트웨어 라이선스

타사 소프트웨어 라이선스는 패키지마다 크게 다를 수 있습니다. 다음은 VFX 파이프라인에서 만날 수 있는 몇 가지 라이선스 체계 및 모델입니다. 각 체계에서 세 번째 열이 권장 라이선스 방식을 나타냅니다.

체계	설명	추천
노드 잠김	특정 MAC 주소, IP 주소, CPU ID에 라이선싱됩니다. 단일 프로세스에 의해서만 실행될 수 있습니다.	인스턴스 기반
노드 기준	특정 노드(인스턴스)에 라이선싱됩니다. 라이선싱된 노드에서 임의의 사용자 또는 프로세스 수가 실행될 수 있습니다.	인스턴스 기반
유동	사용량을 추적하는 라이선스 서버에서 체크아웃됩니다.	라이선스 서버
소프트웨어 라이선스
양방향	사용자가 그래픽 기반 환경에서 소프트웨어를 양방향으로 실행할 수 있도록 합니다.	라이선스 서버 또는 인스턴스 기반
일괄	사용자가 명령줄 환경에서만 소프트웨어를 실행할 수 있도록 합니다.	라이선스 서버
클라우드 기반 라이선스
사용량 기준	프로세스가 클라우드 인스턴스에서 실행될 때만 체크아웃됩니다. 프로세스가 완료되거나 종료되면 라이선스가 해제됩니다.	클라우드 기반 라이선스 서버
가동시간 기준	인스턴스가 활성 상태이고 실행 중인 동안에 체크아웃됩니다. 인스턴스가 중지되거나 삭제되면 라이선스가 해제됩니다.	클라우드 기반 라이선스 서버

인스턴스 기반 라이선스 사용

일부 소프트웨어 프로그램 또는 플러그인은 실행되는 하드웨어에서 바로 라이선싱됩니다. 이 라이선스 방식은 MAC 또는 IP 주소 같은 하드웨어 식별자가 동적으로 할당되는 클라우드에서 문제를 일으킬 수 있습니다.

MAC 주소

인스턴스가 생성될 때 MAC 주소가 할당되며, 인스턴스가 삭제되기 전까지 유지됩니다. 인스턴스를 중지하거나 다시 시작할 때 MAC 주소는 그대로 유지됩니다. 인스턴스가 삭제되기 전까지 이 MAC 주소를 사용하여 라이선스를 만들고 검증할 수 있습니다.

고정 IP 주소 할당

인스턴스를 만들면 내부 IP 주소와 선택적인 외부 IP 주소가 할당됩니다. 인스턴스의 외부 IP 주소를 유지하려면 고정 IP 주소를 예약하고 인스턴스에 할당하면 됩니다. 이 IP 주소는 이 인스턴스에만 예약됩니다. 고정 IP 주소는 프로젝트 기반 리소스이기 때문에 리전 할당량이 적용됩니다.

인스턴스를 만들 때 내부 IP 주소를 할당할 수도 있습니다. 이것은 인스턴스 그룹의 내부 IP 주소가 같은 범위에 속하도록 하고자 하는 경우에 유용합니다.

하드웨어 동글

구형 소프트웨어는 여전히 동글을 통해 라이선싱될 수 있습니다. 동글은 제품 라이선스가 프로그래밍된 하드웨어 키입니다. 대다수의 소프트웨어 회사는 하드웨어 동글을 사용하는 것을 중지했지만 일부 사용자들은 하나 이상의 장치에 연결된 이전 소프트웨어를 사용하고 있을 수 있습니다. 이 문제가 발생하는 경우에는 소프트웨어 제조업체에 연락하여 특정 소프트웨어의 업데이트된 라이선스를 제공할 수 있는지 알아봅니다.

소프트웨어 제조업체가 그러한 라이선스를 제공할 수 없는 경우에는 네트워크 연결 USB 허브 또는 USB over IP 솔루션을 구현할 수 있습니다.

라이선스 서버 사용

대다수의 최신 소프트웨어는 유동 라이선스 옵션을 제공합니다. 이 옵션이 클라우드 환경에 가장 적합하지만, 제한된 숫자의 라이선스가 과소비되지 않도록 더 강력한 라이선스 관리와 액세스 제어가 필요합니다.

라이선스 용량을 초과하지 않도록 작업 대기열 프로세스의 일환으로, 사용할 라이선스를 선택하고 라이선스를 사용하는 작업 수를 제어할 수 있습니다.

온프레미스 라이선스 서버

기존의 온프레미스 라이선스 서버를 사용하여 클라우드에서 실행 중인 인스턴스에 라이선스를 제공할 수 있습니다. 이 방법을 선택하면 렌더링 작업자가 VPN 또는 몇몇 다른 보안 연결을 통해 온프레미스 네트워크와 통신할 수 있는 방법을 제공해야 합니다.

클라우드 기반 라이선스 서버

클라우드에서는 공유 VPC를 사용하여 프로젝트 내에서 또는 프로젝트 간에 인스턴스를 처리하는 라이선스 서버를 실행할 수 있습니다. 유동 라이선스는 때로는 하드웨어 MAC 주소에 연결됩니다. 따라서 고정 IP 주소를 사용하는 작고 오래 실행되는 인스턴스가 여러 렌더 인스턴스에 라이선스를 쉽게 제공할 수 있습니다.

하이브리드 라이선스 서버

일부 소프트웨어는 여러 라이선스 서버를 우선순위 순서대로 사용할 수 있습니다. 예를 들어 렌더러는 온프레미스 서버에서 사용 가능한 라이선스 수를 쿼리하고, 사용 가능한 라이선스가 없는 경우 클라우드 기반 라이선스 서버를 사용할 수 있습니다. 이 전략은 다른 라이선스 유형을 체크아웃하기 전에 영구 라이선스의 사용을 극대화하는 데 도움이 될 수 있습니다.

프로덕션 참고사항: 환경 변수에서 하나 이상의 라이선스 서버를 정의하고 우선순위를 정의합니다. 많이 사용되는 렌더러인 Autodesk Arnold가 이 작업에 유용합니다. 작업이 첫 번째 서버를 사용하여 라이선스를 얻을 수 없으면 다음 예시처럼 목록에 있는 다른 서버를 사용하려고 시도합니다.

export solidangle_LICENSE=5053@x.x.0.1;5053@x.x.0.2

앞의 예시에서 Arnold 렌더러는 x.x.0.1에 있는 서버의 5053 포트에서 라이선스를 가져오려고 시도합니다. 이 시도가 실패하면 IP 주소 x.x.0.2의 동일한 포트에서 라이선스를 가져오려고 시도합니다.

클라우드 기반 라이선스

일부 공급업체는 클라우드 기반 라이선스를 통해 인스턴스에 주문형 소프트웨어 라이선스를 제공합니다. 클라우드 기반 라이선스는 일반적으로 사용량 기준 및 가동시간 기준의 두 가지 방법으로 청구됩니다.

사용량 기준 라이선스

사용량 기준 라이선스는 소프트웨어가 사용되는 시간을 기준으로 청구됩니다. 일반적으로 이러한 유형의 라이선스를 사용할 때는 프로세스가 시작될 때 클라우드 기반 서버에서 라이선스가 체크아웃되고, 프로세스가 완료될 때 해제됩니다. 따라서 라이선스가 체크아웃되어 있는 동안만큼 해당 라이선스의 사용료가 청구됩니다. 이러한 유형의 라이선스는 일반적으로 렌더링 소프트웨어에 사용됩니다.

가동시간 기준 라이선스

가동시간 기준 또는 계량 라이선스는 Compute Engine 인스턴스의 가동시간을 기준으로 청구됩니다. 인스턴스는 시작 프로세스 중에 클라우드 기반 라이선스 서버에 등록되도록 구성됩니다. 따라서 인스턴스가 실행 중인 동안 라이선스는 체크아웃됩니다. 인스턴스가 중지되거나 삭제되면 라이선스가 해제됩니다. 이러한 유형의 라이선스는 일반적으로 대기열 관리자가 배포하는 렌더링 작업자에 사용됩니다.

데이터를 저장하는 방법 선택

Google Cloud에서 선택하는 스토리지 유형은 내구성 요구사항 및 비용과 같은 요소와 함께 선택한 스토리지 전략에 따라 달라집니다. Cloud Storage에 대해 자세히 알아보려면 Compute Engine의 파일 서버를 참조하세요.

영구 디스크

영구 디스크(PD)를 워크로드에 통합함으로써 파일 서버를 아예 새로 구현하는 것을 피할 수 있습니다. PD는 최대 크기가 64TB이며 대다수 VFX 시설과 호환되는 POSIX 규격 블록 저장소 유형입니다. 영구 디스크는 표준 드라이브와 솔리드 스테이트 드라이브(SSD), 두 가지 모두로 사용 가능합니다. PD를 단일 인스턴스에 읽기-쓰기 모드로 연결하거나, 렌더링 작업자 그룹과 같은 다수의 인스턴스에 읽기 전용 모드로 연결할 수 있습니다.

장점	단점	적합한 사용 사례
표준 NFS 또는 SMB 볼륨으로 마운트됩니다. 크기를 동적으로 조절할 수 있습니다. PD를 최대 128개까지 단일 인스턴스에 연결할 수 있습니다. 동일한 PD를 인스턴스 수백 또는 수천 개에 읽기 전용으로 마운트할 수 있습니다.	최대 크기는 64TB입니다. 단일 인스턴스에 연결된 경우에만 PD에 쓸 수 있습니다. 동일한 리전에 있는 리소스만 액세스할 수 있습니다.	작업별로 새로운 디스크를 빌드할 수 있는 고급 파이프라인 소프트웨어 또는 공통 라이브러리와 같이 자주 업데이트되지 않는 데이터를 렌더링 작업자에게 제공하는 파이프라인

객체 저장소

Cloud Storage는 기존 파일 시스템과 달리, 구조화되어 있지 않으며 용량이 거의 무제한인 중복성과 내구성이 뛰어난 저장소입니다. Cloud Storage에 있는 파일은 폴더와 비슷한 버킷에 저장되며 전 세계에서 액세스할 수 있습니다.

기존 스토리지와 달리, 객체 스토리지는 운영 체제(OS)가 논리 볼륨으로 마운트할 수 없습니다. 객체 스토리지를 렌더링 파이프라인에 통합하려면 gsutil과 같은 명령줄 유틸리티 또는 Cloud Storage API를 통해 데이터를 읽고 쓰는 방법을 수정해야 합니다.

장점	단점	적합한 사용 사례
모든 크기의 파일에 알맞은 내구성과 가용성이 높은 스토리지 모든 스토리지 클래스에서 단일 API 사용 저렴함 전 세계에서 데이터 사용 가능 사실상 용량 무제한	POSIX 규격이 아님 API 또는 명령줄 유틸리티를 통해 액세스해야 함 렌더링 파이프라인에서 데이터를 사용하기 전에 로컬에 전송해야 함	Cloud Storage에 데이터를 게시할 수 있는 애셋 관리 시스템이 있는 렌더링 파이프라인 렌더링하기 전에 Cloud Storage에서 데이터를 가져올 수 있는 큐 관리 시스템이 있는 렌더링 파이프라인

기타 스토리지 제품

기타 스토리지 제품이 Cloud Marketplace 같은 타사 채널을 통해 관리형 서비스로 제공되거나, 소프트웨어 저장소 또는 GitHub를 통해 오픈소스 프로젝트로 제공됩니다.

제품	장점	단점	적합한 사용 사례
Elastifile, Cloud File System(ECFS)[Google Cloud에서 인수함]	수천 개의 동시 NFS 연결을 지원할 수 있는 클러스터형 파일 시스템입니다. 온프레미스 NAS 클러스터와 동기화할 수 있습니다.	온프레미스 스토리지 또는 클라우드 동기화를 사용할 수 있지만 한 방향으로만 데이터를 동기화할 수 있습니다. 예를 들어 온프레미스 NAS는 읽고 쓸 수 있지만 클라우드 기반 ECFS는 읽기 전용입니다. 파일을 선택적으로 동기화할 수 있는 방법은 없습니다. 양방향 동기화가 불가능합니다.	클라우드에서 수백 TB의 데이터를 제공해야 하는 중대형 VFX 시설
Pixit Media, PixStor	수천 개의 동시 NFS 또는 POSIX 클라이언트를 지원할 수 있는 수평 확장 파일 시스템입니다. 온프레미스 NAS에서 데이터를 주문형으로 캐시할 수 있으며, 업데이트를 온프레미스 저장소에 자동으로 돌려보낼 수 있습니다.	비용, Pixit라는 타사로부터 지원을 받아야 함	클라우드에서 수백 TB의 데이터를 제공해야 하는 중대형 VFX 시설
Filestore	Google Cloud의 완전 관리형 스토리지 솔루션입니다. 배포 및 유지보수가 간단합니다.	인스턴스당 최대 64TB. NFS 성능이 고정되어 있으며 활성 클라이언트 수와 함께 확장되지 않습니다.	애셋 동기화가 가능한 파이프라인이 있는 중소형 VFX 시설 가상 워크스테이션 간 공유 디스크
Cloud Storage FUSE	Cloud Storage 버킷을 파일 시스템으로 마운트합니다. 비용이 적게 듭니다.	POSIX 규격 파일 시스템이 아닙니다. 구성하고 최적화하기 어려울 수 있습니다.	오픈소스 파일 시스템을 배포, 구성, 유지보수할 수 있으며 애셋 동기화가 가능한 파이프라인이 있는 VFX 시설

Google Cloud에서는 다른 스토리지 유형을 사용할 수 있습니다. 자세한 내용은 Google Cloud 담당자에게 문의하세요.

데이터 스토리지 옵션 추가 정보

Google Cloud에서 사용할 수 있는 스토리지 옵션

스토리지 전략 구현

온프레미스 저장소에 데이터에 직접 액세스하건 온프레미스 저장소와 클라우드 사이에서 동기화하건, 데이터를 처리하는 방법을 결정하는 규칙을 수립함으로써 VFX 또는 애니메이션 프로덕션 파이프라인에서 다수의 저장소 전략을 구현할 수 있습니다.

전략 1: 온프레미스 저장소를 직접 마운트

시설이 최소 10Gbps 이상으로 Google Cloud에 연결되어 있고 Google Cloud 리전과 가까운 곳에 있는 경우 온프레미스 NAS를 클라우드 렌더링 작업자에 직접 마운트할 수 있습니다. 이 전략은 간단하지만 클라우드에서 만들고 스토리지에 다시 쓰는 모든 것이 이그레스 데이터로 계산되므로 비용이 높고 대역폭이 많이 사용됩니다.

장점	단점	적합한 사용 사례
간단한 구현 공통 스토리지에 읽기 및 쓰기 캐싱이나 동기화 필요 없이 데이터 즉시 사용 가능	다른 옵션보다 비쌀 수 있음 지연 시간을 단축시키기 위해 Google 데이터 센터와 가까운 곳에 있어야 함 온프레미스 NAS에 연결할 수 있는 최대 인스턴스 수는 대역폭과 연결 유형에 따라 다름	렌더링 워크로드를 클라우드로 버스트해야 하며 비용에 신경 쓰지 않는 Google 데이터 센터 근처의 시설 Google Cloud에 최소 10Gbps 이상으로 연결된 시설

전략 2: 주문형 동기화

*주문형으로 온프레미스 스토리지와 클라우드 기반 스토리지 간에 데이터 동기화*

프레임이 렌더링되거나 애셋이 게시될 때와 같이 데이터가 필요한 경우에만 데이터를 클라우드에 내보내거나 온프레미스 스토리지에서 가져올 수 있습니다(반대로도 가능). 이 전략을 사용하면 감시 스크립트와 같은 파이프라인 내 메커니즘, Pub/Sub와 같은 이벤트 핸들러, 작업 스크립트에 포함된 명령어 집합에 의해 동기화가 트리거될 수 있습니다.

gcloud scp 명령어, gsutil rsync 명령어, UDP 기반 데이터 전송 프로토콜(UDT)과 같은 다양한 명령어를 사용하여 동기화를 수행할 수 있습니다. Aspera, Cloud FastPath, BitSpeed, FDT 등의 타사 UDT를 사용하여 Cloud Storage 버킷과 통신하는 경우에는 타사 문서를 참조하여 보안 모델과 권장사항에 대해 알아보세요. Google은 이러한 타사 서비스를 관리하지 않습니다.

Push 메서드

일반적으로 애셋을 게시하거나, 시청 폴더에 파일을 넣거나, 렌더링 작업을 완료할 때 Push 메서드를 사용하고 그 후에 사전 정의된 위치에 푸시할 수 있습니다.

예시:

클라우드 렌더링 작업자가 렌더링 작업을 완료하고 최종 프레임이 온프레미스 저장소로 다시 푸시됩니다.
아티스트가 애셋을 게시합니다. 애셋 게시 프로세스 도중에 연관된 데이터가 Cloud Storage의 사전 정의된 경로로 푸시됩니다.

Pull 메서드

일반적으로 클라우드 기반 렌더 인스턴스에 의해 파일이 요청될 때 Pull 메서드를 사용합니다.

예: 렌더링 작업 스크립트의 일환으로, 장면을 렌더링하는 데 필요한 모든 애셋은 렌더링 전에 파일 시스템으로 풀링되고, 이곳에서 모든 렌더링 작업자가 애셋에 액세스할 수 있습니다.

장점	단점	적합한 사용 사례
어떤 데이터가 언제 동기화되는지를 완벽하게 제어합니다. 전송 메서드와 프로토콜을 선택할 수 있습니다.	push/pull 동기화를 트리거하려면 프로덕션 파이프라인에서 이벤트를 처리할 수 있어야 합니다. 동기화 큐를 처리하는 데 추가 리소스가 필요할 수 있습니다.	커스텀 파이프라인이 있으며 애셋 동기화를 완벽하게 제어하려는 모든 규모의 시설

프로덕션 참고사항: 렌더링 작업을 처리하는 데 사용하는 대기열 관리 시스템으로 데이터 동기화를 관리하세요. 동기화 작업은 별도의 클라우드 리소스를 사용하여 가용 대역폭을 극대화하고 네트워크 트래픽을 최소화할 수 있습니다.

전략 3: 온프레미스 저장소, 클라우드 기반 리드스루 캐시

이 전략에서는 리드스루 캐시와 파일 서버 역할을 모두 수행하는 가상 캐싱 어플라이언스를 클라우드에 구현합니다. 각 클라우드 렌더링 작업자는 기존 파일 서버에서와 같이 NFS 또는 SMB 프로토콜로 캐싱 어플라이언스를 마운트합니다. 렌더링 작업자가 캐시에 없는 파일을 읽는 경우에는 파일이 온프레미스 저장소에서 클라우드 파일러로 전송됩니다. 캐싱 파일 서버를 어떻게 구성했는지에 따라 데이터는 다음 시점이 될 때까지 캐시에 남아 있습니다.

데이터 기한이 초과될 때 또는 지정된 기간 동안 한 번도 사용되지 않은 경우
파일 서버에 공간이 필요할 때(이 경우 일정 기간이 지난 데이터가 캐시에서 삭제됨)

이 전략은 여러 동시 렌더 인스턴스를 배포하는 데 필요한 대역폭과 복잡성을 줄입니다.

경우에 따라 렌더링 전에 모든 작업 관련 데이터가 있는지 확인하기 위해 캐시를 예열하려 할 수 있습니다. 캐시를 예열하려면 클라우드 파일 서버의 디렉터리에서 파일 한 개 이상에 read 또는 stat을 수행하여 디렉터리 콘텐츠를 읽습니다. 이러한 방법으로 파일에 액세스하면 동기화 메커니즘이 트리거됩니다.

가상 어플라이언스와 통신하기 위해 물리적 온프레미스 어플라이언스를 추가할 수도 있습니다. 예를 들어 NetApp은 온프레미스 스토리지와 클라우드 간의 지연 시간을 더욱 줄여주는 스토리지 솔루션을 제공합니다.

장점	단점	적합한 사용 사례
캐시된 데이터가 자동으로 관리됩니다. 대역폭 요구사항이 줄어듭니다. 작업 요구사항에 따라 클러스터링된 클라우드 파일 시스템을 확장 또는 축소할 수 있습니다.	추가 비용이 발생할 수 있습니다. 캐시를 예열할 경우 사전 작업을 구현해야 합니다.	여러 동시 인스턴스를 배포하고 여러 작업에서 공통 애셋을 읽는 대규모 시설

데이터 필터링

애셋 유형 및 관련 조건의 데이터베이스를 빌드하여 특정 데이터 유형을 동기화할 것인지 여부를 정의할 수 있습니다. 변환 프로세스 도중에 생성되는 임시 데이터, 캐시 파일, 시뮬레이션 데이터 등 특정 유형의 데이터는 절대로 동기화하지 않을 수도 있습니다. 승인되지 않은 애셋을 동기화할 것인지 여부도 고려하세요. 최종 렌더에서 모든 반복이 사용되는 것은 아니기 때문입니다.

초기 대량 전송 수행

하이브리드 렌더링 작업장을 구현할 때 데이터 세트의 전부 또는 일부를 Cloud Storage, 영구 디스크 또는 기타 클라우드 기반 저장소에 초기 전송할 수도 있습니다. 전송할 데이터 양과 유형, 연결 속도 등 여러 가지 요인에 따라 며칠 또는 몇 주 동안 전체 동기화를 수행할 수도 있습니다. 다음 그림은 온라인 및 물리적 전송의 일반적인 시간을 비교합니다.

Google은 전송 워크로드가 시간 또는 대역폭 제약조건을 초과하는 경우를 대비해 데이터를 클라우드에 전송할 수 있는 Google Transfer Appliance 등의 여러 가지 전송 옵션을 제공합니다.

보관처리 및 재해 복구

데이터 보관처리와 재해 복구의 차이점에 대해 짚어볼 필요가 있습니다. 전자는 완성된 작업을 선택적으로 복사하는 것이고, 후자는 복구할 수 있는 데이터 상태입니다. 시설의 요구에 부합하고 오프사이트 비상대책 계획을 제공하는 재해 복구 계획을 설계할 수 있습니다. 특정 저장소 플랫폼에 적합한 재해 복구 계획을 세우는 데 도움이 필요하면 온프레미스 저장소 공급업체에 문의하세요.

클라우드에서 데이터 보관처리

프로젝트가 완료된 후에는 완성된 작업을 일종의 장기 스토리지에 저장하는 것이 일반적입니다. 주로 LTO와 같은 자기 테이프 미디어가 사용됩니다. 이러한 카트리지는 환경적 요구사항을 따르며 시간이 경과함에 따라 관리하기가 까다로울 수 있습니다. 대형 프로덕션 시설은 때때로 전체 자료실을 전용 공간에 저장하고 보관처리 전담 직원이 데이터를 추적하면서 요청이 있을 때 검색하도록 합니다.

보관처리된 특정 애셋, 촬영본, 영상을 검색하는 데 시간이 걸릴 수 있습니다. 데이터가 여러 카트리지에 저장되어 있거나, 자료실 색인이 누락되거나 불완전하거나, 자기 테이프에서 데이터를 읽는 데 속도 제한이 있을 수도 있기 때문입니다.

데이터 자료실을 클라우드로 이전하면 자료실 미디어를 온프레미스에서 관리하고 저장할 필요가 없어질 뿐만 아니라, 기존 보관처리 방법보다 훨씬 더 쉽게 데이터를 액세스하고 검색하도록 만들 수 있습니다.

기본 보관처리 파이프라인은 다음 다이어그램과 비슷하며 자료실을 조사, 분류, 태깅, 정리하기 위해 여러 가지 클라우드 서비스를 사용합니다. 클라우드에서 날짜, 프로젝트, 형식, 해상도 등의 다양한 메타데이터 조건을 사용하여 데이터를 검색하는 자료실 관리 및 검색 도구를 만들 수 있습니다. Machine Learning API를 사용하여 이미지와 비디오를 태깅하고 분류하면서 BigQuery와 같은 클라우드 기반 데이터베이스에 결과를 저장할 수도 있습니다.

고려해야 할 추가 사항:

검색 수수료가 부과되는 Cloud Storage 스토리지 클래스 내에 있는 콘텐츠의 썸네일이나 프록시를 자동으로 생성합니다. 미디어 애셋 관리 시스템 내에서 이러한 프록시를 사용하면 사용자가 보관처리된 애셋이 아닌 프록시만 읽으면서 데이터를 탐색할 수 있습니다.
머신러닝을 사용하여 실사 콘텐츠를 분류해 보세요. Cloud Vision을 사용하여 텍스처와 배경판에 라벨을 지정하거나 Video Intelligence API를 사용하여 참조 영상을 검색하고 가져올 수 있습니다.
또한 Vertex AI AutoML 이미지를 사용하여 실시간 작업 또는 렌더링된 애셋을 모두 인식하는 커스텀 이미지 모델을 만들 수도 있습니다.
렌더링된 콘텐츠의 경우 렌더링 작업자의 디스크 이미지 복사본을 렌더링된 애셋과 함께 저장하는 것이 좋습니다. 이렇게 하면 보관처리된 촬영본을 다시 렌더링해야 하는 경우 올바른 소프트웨어 버전, 플러그인, OS 라이브러리, 종속 항목을 사용하여 설정을 재현할 수 있습니다.

애셋 및 프로덕션 관리

여러 시설에서 동일 프로젝트를 작업할 때는 특별한 문제가 발생할 수 있습니다. 특히 전 세계에서 콘텐츠 및 애셋을 사용할 수 있어야 하는 경우에 더욱 그러합니다. 사설 네트워크 간에 데이터를 수동으로 동기화하는 것은 비용과 리소스가 많이 들고, 로컬 대역폭 제한의 영향을 받습니다.

워크로드에서 전 세계적으로 사용 가능한 데이터가 필요한 경우에는 Google 서비스에 액세스할 수 있는 곳이라면 어디에서든지 액세스할 수 있는 Cloud Storage를 사용할 수도 있습니다. Cloud Storage를 파이프라인에 통합하려면 객체 경로를 이해하도록 파이프라인을 수정한 후, 렌더링하기 전에 데이터를 렌더링 작업자에게 가져오거나 푸시해야 합니다. 이 방법을 사용하면 게시된 데이터를 전 세계에서 액세스할 수 있지만, 파이프라인이 적절한 시간 안에 애셋을 필요한 곳에 전달해야 합니다.

예를 들어 런던에 있는 조명 아티스트가 사용할 이미지 파일을 로스앤젤레스에 있는 텍스처 아티스트가 게시할 수 있습니다. 이 프로세스는 다음과 같은 형태가 됩니다.

게시 파이프라인이 파일을 Cloud Storage에 내보내고 클라우드 기반 애셋 데이터베이스에 항목을 추가합니다.
런던에 있는 아티스트가 스크립트를 실행하여 장면의 애셋을 수집합니다. 파일 위치를 데이터베이스에서 쿼리하고 Cloud Storage에서 로컬 디스크로 읽어옵니다.
대기열 관리 소프트웨어가 렌더링에 필요한 애셋 목록을 수집하고, 애셋 데이터베이스에서 쿼리하고, Cloud Storage에서 각 렌더링 작업자의 로컬 저장소로 다운로드합니다.

이러한 방법으로 Cloud Storage를 사용하면 Cloud Storage를 보관처리 파이프라인의 일부분으로 사용하기로 선택한 경우 클라우드에서 모든 게시된 데이터를 보관처리할 수도 있습니다.

데이터베이스 관리

애셋 및 프로덕션 관리 소프트웨어를 사용하기 위해서는 초당 수백 또는 수천 개의 쿼리를 처리할 수 있는 호스트에서 처리되는 가용성과 내구성이 뛰어난 데이터베이스가 필요합니다. 데이터베이스는 일반적으로 렌더링 작업자와 동일한 랙에서 실행되는 온프레미스 서버에서 호스트되며 동일한 전력, 네트워크, HVAC 제한사항을 따릅니다.

MySQL, NoSQL, PostgreSQL 프로덕션 데이터베이스를 관리형 클라우드 기반 서비스로 실행하는 것도 고려해보세요. 이들 서비스는 가용성이 뛰어나고 전 세계적으로 액세스 가능하며, 미사용 데이터와 전송 중 데이터를 모두 암호화하고, 복제 기능이 내장되어 있습니다.

대기열 관리

Qube!, Deadline, Tractor 등 상용화된 큐 관리 소프트웨어 프로그램이 VFX 및 애니메이션 산업에서 널리 사용되고 있습니다. 이외에도 OpenCue와 같은 오픈소스 소프트웨어 옵션도 있습니다. 이 소프트웨어를 사용하여 렌더뿐만 아니라 다양한 작업자에게 컴퓨팅 워크로드를 배포하고 관리할 수 있습니다. 렌더를 관리하는 데 사용하는 것과 동일한 스케줄링 프레임워크로 애셋 게시, 입자 및 유동 시뮬레이션, 텍스처 베이킹, 합성을 배포하고 관리할 수 있습니다.

몇몇 시설에서는 위스콘신대학의 HTCondor, SchedMD의 Slurm, Univa Grid Engine과 같은 범용 스케줄링 소프트웨어를 VFX 파이프라인에 구현했습니다. 하지만 VFX 산업 전용으로 설계된 소프트웨어는 다음과 같은 기능에 특히 주목합니다.

작업, 프레임, 계층 기반의 종속 항목. 어떤 작업은 다른 작업이 먼저 완료된 후 시작해야 합니다. 예를 들어 렌더링 이전에 유체 시뮬레이션을 완전히 실행해야 합니다.
렌더 랭글러가 개별 기한 및 일정에 맞춰 작업 순서를 바꾸는 데 사용할 수 있는 작업 우선순위
특정 리소스를 필요로 하는 작업과 해당 리소스를 연결하는 데 사용할 수 있는 리소스 유형, 라벨, 타겟. 예를 들어 GPU 가속 렌더링을 GPU가 연결된 VM에만 배포합니다.
리소스 사용에 대한 이전 데이터를 캡처하고 추후 분석을 위해 API 또는 대시보드로 제공. 예를 들어 렌더의 마지막 몇 차례 반복에서 평균 CPU 및 메모리 사용량을 조사하여 다음 반복 시 리소스 사용량을 예측합니다.
게재 전 및 게재 후 작업. 예를 들어 게재 전 작업에서는 렌더링하기 전에 필요한 모든 애셋을 로컬 렌더링 작업자로 가져옵니다. 게재 후 작업에서는 최종 렌더링된 프레임을 파일 시스템의 지정된 위치로 복사한 후에 애셋 관리 시스템에서 프레임을 완료된 것으로 표시합니다.
Maya, 3ds Max, Houdini, Cinema 4D, Nuke 등의 많이 사용되는 2D 및 3D 소프트웨어 애플리케이션과 통합

프로덕션 참고사항: 큐 관리 소프트웨어를 사용하면 클라우드 기반 리소스 풀을 온프레미스 렌더링 작업자처럼 취급할 수 있습니다. 이 방법을 위해서는 각 인스턴스에서 처리할 수 있는 최대한의 렌더를 실행함으로써 의도적으로 리소스 사용량을 극대화해야 합니다. 이러한 기법을 적재라고 합니다. 일반적으로 이 작업은 알고리즘에 따라 처리되는 동시에 렌더 랭글러에 의해서도 처리됩니다.

클라우드 기반 리소스의 생성, 관리, 종료를 주문형 방식으로 자동화할 수도 있습니다. 이 방법은 대기열 관리자를 사용하여 필요한 리소스를 생성하는 렌더 전후 스크립트를 실행하고, 렌더링 중에 이를 모니터링하고, 작업이 완료되면 스크립트를 종료합니다.

작업 배포 고려사항

온프레미스 및 클라우드 기반 저장소를 모두 사용하는 렌더링 작업장을 구현할 때 대기열 관리자가 고려해야 할 몇 가지 사항이 있습니다.

클라우드 배포와 온프레미스 배포 간에 라이선스가 다를 수 있습니다. 노드를 기준으로 하는 라이선스도 있고, 프로세스를 중심으로 하는 라이선스도 있습니다. 대기열 관리 소프트웨어가 라이선스 가치를 극대화하는 방향으로 작업을 배포하도록 해야 합니다.
특정 작업 유형에 할당될 때만 사용되도록 클라우드 기반 리소스에 고유 태그 또는 라벨을 추가해 보세요.
Cloud Logging을 사용하여 미사용 또는 유휴 인스턴스를 감지합니다.
종속 작업을 시작할 때는 생성된 데이터가 상주할 위치 및 다음 단계를 위해 전송할 위치를 고려하세요.
온프레미스 저장소와 클라우드 기반 저장소의 경로 네임스페이스가 다른 경우에는 위치에 관계없이 렌더링할 수 있도록 상대 경로를 사용하세요. 플랫폼에 따라서는 렌더링 시 경로를 바꾸는 메커니즘을 만들 수도 있습니다.
일부 렌더, 시뮬레이션, 후처리는 난수 생성에 의존하는데 CPU 제조업체에 따라 차이가 발생할 수 있습니다. CPU의 제조업체는 동일하지만 칩 세대가 다른 경우에도 상이한 결과가 나올 수 있습니다. 확신할 수 없는 경우에는 모든 작업 프레임에 동일하거나 유사한 CPU 유형을 사용하세요.
리드스루 캐시 어플라이언스를 사용하는 경우에는 게재 전 작업을 배포하여 캐시를 예열하고 클라우드 리소스를 배포하기 전에 클라우드에서 모든 애셋을 사용할 수 있는지 확인하세요. 이 접근 방식은 애셋이 클라우드로 이동하는 동안 렌더링 작업자가 강제로 기다려야 하는 시간을 최소화합니다.

로깅 및 모니터링

리소스 사용량과 성능을 기록하고 모니터링하는 것은 렌더링 작업장의 필수 요소입니다. Google Cloud는 리소스와 서비스 사용량에 대한 유용한 정보를 제공할 수 있도록 여러 API, 도구, 솔루션을 제공합니다.

VM 활동을 모니터링하는 가장 빠른 방법은 직렬 포트 출력을 보는 것입니다. 이 출력은 인스턴스가 렌더 큐 관리 감독자와 같은 일반적인 서비스 제어 영역을 통해 반응하지 않을 때 유용합니다.

Google Cloud에서 리소스 사용량을 수집 및 모니터링하는 다른 방법은 다음과 같습니다.

Cloud Logging을 사용하여 사용량 및 감사 로그를 캡처하고 결과 로그를 Cloud Storage, BigQuery, 기타 서비스에 내보냅니다.
Cloud Monitoring을 사용하여 VM에 에이전트를 설치하고 시스템 측정항목을 모니터링합니다.
Cloud Logging API를 파이프라인 스크립트에 통합하여 많이 사용되는 스크립트 언어용 클라이언트 라이브러리를 사용해 Cloud Logging에 직접 로깅합니다.
Cloud Monitoring을 사용하여 차트를 만들고 리소스 사용량을 파악합니다.

렌더링 작업자 인스턴스 구성

워크로드를 진정한 하이브리드로 만들기 위해서는 온프레미스 렌더 노드가 클라우드 기반 렌더 노드와 동일해야 하며 OS 버전, 커널 빌드, 설치된 라이브러리, 소프트웨어가 일치해야 합니다. 온프레미스에 있는 마운트 지점, 경로 네임스페이스, 사용자 환경까지 클라우드에 재현해야 할 수도 있습니다.

디스크 이미지 선택

공개 이미지 중 하나를 선택하거나 온프레미스 렌더 노드 이미지를 기반으로 커스텀 이미지를 직접 만들 수 있습니다. 공개 이미지는 사용자 계정을 설정 및 관리하고 Secure Shell(SSH) 키 기반 인증을 사용 설정하는 패키지 모음을 포함합니다.

커스텀 이미지 만들기

커스텀 이미지를 만들기로 선택한 경우에는 Compute Engine 환경에서 제대로 작동하도록 Linux와 Windows 모두에 더 많은 라이브러리를 추가해야 합니다.

커스텀 이미지는 보안 권장사항을 준수해야 합니다. Linux를 사용할 경우 Compute Engine용 Linux 게스트 환경을 설치하여 공개 이미지가 기본적으로 제공하는 기능에 액세스합니다. 게스트 환경을 설치하면 공개 이미지에서 할 수 있는 메타데이터 액세스, 시스템 구성, Google Cloud에 사용할 OS 최적화 등의 작업을 동일한 보안 제어로 커스텀 이미지에서 수행할 수 있습니다.

프로덕션 참고사항: 조직 수준의 별도의 프로젝트에서 커스텀 이미지를 관리하세요. 이 접근 방법을 사용하면 이미지를 만들거나 수정하는 방법을 정밀하게 제어하고 여러 프로덕션에서 서로 다른 소프트웨어나 OS 버전을 사용할 때 유용할 수 있는 버전을 적용할 수 있습니다.

이미지 생성 및 인스턴스 배포 자동화

Packer와 같은 도구를 사용하여 더 쉽게 재현하고, 감사하고, 구성하고, 신뢰할 수 있는 이미지를 만들 수 있습니다. 또한 Ansible과 같은 도구를 사용하여 실행 중인 렌더 노드를 구성하고 그 구성과 수명 주기를 세부적으로 제어할 수 있습니다.

머신 유형 선택

Google Cloud에서 사전 정의된 머신 유형 중 하나를 선택하거나 커스텀 머신 유형을 지정할 수 있습니다. 커스텀 머신 유형을 사용하면 리소스를 제어할 수 있으므로 Google Cloud에서 실행되는 작업 유형에 따라 인스턴스를 맞춤설정할 수 있습니다. 인스턴스를 만들 때 GPU를 추가하고 CPU 수, CPU 플랫폼, RAM 용량, 디스크 유형, 디스크 크기를 지정할 수 있습니다.

프로덕션 참고사항: 프레임당 인스턴스를 하나씩 배포하는 파이프라인의 경우 CPU 부하 또는 메모리 사용과 같은 이전 작업 통계를 기준으로 인스턴스를 맞춤설정하여 모든 샷 프레임에서 리소스 사용량을 최적화해보세요. 예를 들어 모션 블러가 많은 프레임에 CPU 수가 더 많은 머신을 배포함으로써 모든 프레임의 렌더링 시간을 평준화할 수 있습니다.

표준 및 선점형 VM 중에서 선택

선점형 VM(PVM)은 표준 VM보다 훨씬 낮은 가격으로 판매되는 초과 Compute Engine 용량을 의미합니다. Compute Engine은 다른 작업에서 이 리소스가 필요한 경우 이 인스턴스를 종료하거나 선점할 수 있습니다. PVM은 내결함성이 있으며 선점 시 손실되는 작업을 추적하는 큐 시스템에서 관리되는 워크로드를 렌더링하는 데 적합합니다.

표준 VM은 무한정 실행될 수 있으며, 영구적으로 실행되어야 하는 라이선스 서버나 대기열 관리자 호스트에 적합합니다.

선점형 VM은 24시간 후에 자동으로 종료되므로, 그 이상 실행되는 렌더나 시뮬레이션을 실행하는 데 사용하지 마세요.

선점율은 5%에서 15% 사이로, 인하된 가격을 고려했을 때 일반적인 렌더링 워크로드에 무난합니다. 몇 가지 선점형 권장사항이 PVM을 렌더 파이프라인에 통합하는 가장 좋은 방법을 결정하는 데 도움이 될 수 있습니다. 인스턴스가 선점된 경우 Compute Engine은 인스턴스에 선점 신호를 보냅니다. 이 선점 신호를 사용하여 스케줄러가 현재 작업을 종료하고 큐에 다시 추가하도록 트리거할 수 있습니다.

표준 VM	선점형 VM
장기 실행 작업에 사용할 수 있습니다. 기한을 변경할 수 없는 우선순위가 높은 작업에 적합합니다. 무한정 실행될 수 있으므로 라이선스 서버 또는 큐 관리자 호스팅에 적합합니다.	24시간 후에 자동으로 종료됩니다. 선점된 인스턴스를 처리하기 위한 큐 관리 시스템이 필요합니다.

프로덕션 참고사항: 일부 렌더러는 진행 중인 렌더의 스냅샷을 일정한 간격으로 저장할 수 있으므로 VM이 선점된 경우 프레임을 처음부터 새로 시작할 필요 없이 렌더링을 일시 중지하고 재개할 수 있습니다. 렌더러에서 스냅샷 저장이 지원될 때 PVM을 사용하기로 선택하는 경우, 작업 손실을 방지하기 위해 파이프라인에서 렌더 스냅샷 저장을 사용 설정하세요. 스냅샷이 작성되고 업데이트되는 동안 데이터를 Cloud Storage에 쓸 수 있습니다. 이 데이터는 렌더링 작업자가 선점되는 경우 새 PVM이 배포될 때 검색됩니다. 저장소 비용을 피하기 위해 완료된 렌더의 스냅샷 데이터를 삭제하세요.

렌더링 작업자에게 액세스 권한 부여

IAM에서는 클라우드 리소스에 대한 액세스 권한을 필요한 개인에게 할당할 수 있습니다. Linux 렌더링 작업자의 경우에는 OS 로그인을 사용해 SSH 세션 내에서 액세스 권한을 추가로 제한하여 관리자 역할을 제어할 수 있습니다.

하이브리드 렌더링 작업장 비용 억제

비용을 예측할 때는 여러 가지 요소를 고려해야 하지만 하이브리드 렌더링 작업장에 대해서는 다음의 일반적인 권장사항을 방침으로 삼는 것이 좋습니다.

기본적으로 선점형 인스턴스를 사용합니다. 렌더링 작업이 한 프레임에 4시간 이상씩 매우 오래 실행되거나 결과물 전달 기한이 촉박한 경우를 제외하고는 선점형 VM을 사용하세요.
이그레스를 최소화합니다. 온프레미스 저장소로 다시 보내야 하는 데이터만 복사하세요. 대부분의 경우 이 데이터는 최종 렌더링된 프레임이지만 별도의 패스 또는 시뮬레이션 데이터일 수도 있습니다. 온프레미스 NAS를 직접 마운트하거나 자동으로 동기화되는 스토리지 제품을 사용할 경우에는 렌더링된 모든 데이터를 렌더링 작업자의 로컬 파일 시스템에 쓴 후 필요한 내용을 다시 온프레미스 스토리지에 복사하여 임시 데이터나 불필요한 데이터가 이그레스되지 않도록 합니다.
VM 크기를 적절히 조정합니다. 최적의 리소스 사용량에 맞춰 렌더링 작업자를 만들고 필요한 vCPU 수, 최적의 RAM 용량, 올바른 GPU 수만큼만 할당해야 합니다. 연결된 디스크의 크기를 최소화하는 방법도 고려해보세요.
기본 요금인 최소 1분을 고려합니다. Google Cloud에서 인스턴스는 초 단위로 요금이 청구되며 최소 사용 비용 기준은 1분입니다. 워크로드에 1분 미만의 프레임의 렌더링이 포함된 경우에는 컴퓨팅 시간이 1분 미만인 인스턴스가 배포되지 않도록 여러 작업을 하나로 묶는 것이 좋습니다.
대용량 데이터 세트를 클라우드에 유지합니다. 렌더링 작업장을 사용하여 딥 EXR이나 시뮬레이션 데이터 같은 대량의 데이터를 생성하는 경우, 파이프라인의 훨씬 더 아래쪽에 있는 클라우드 기반 워크스테이션을 사용하는 것을 고려해보세요. 예를 들어 FX 아티스트가 클라우드에서 유체 시뮬레이션을 실행하고 캐시 파일을 클라우드 기반 스토리지에 쓸 수 있습니다. 그러면 조명 아티스트가 Google Cloud에 있는 가상 워크스테이션에서 이 시뮬레이션 데이터에 액세스할 수 있습니다. 가상 워크스테이션에 대한 자세한 내용은 Google Cloud 담당자에게 문의하세요.
지속 및 약정 사용 할인을 활용합니다. 리소스 풀을 실행하는 경우에는 지속 사용 할인을 통해 한 달 내내 실행한 인스턴스의 비용을 최대 30%까지 할인받을 수 있습니다. 경우에 따라 약정 사용 할인이 합리적일 수도 있습니다.

온프레미스 및 클라우드 기반 렌더링 작업장 비용 비교

온프레미스 렌더링 작업장을 구축하고 유지관리할 때의 비용을 클라우드 기반 렌더링 작업장을 구축할 때의 비용과 비교해보세요. 다음의 비용 분석 예가 두 시나리오를 비교합니다(모든 비용은 USD).

온프레미스 렌더링 작업장 비용	클라우드 기반 렌더링 작업장 비용
초기 구축 비용 노드당 가격: $3,800 노드 수: 100개 네트워킹 하드웨어, 클린룸 빌드: $100,000 스토리지 하드웨어: $127,000 초기 유틸리티 회사 연결: $20,000 연결 프로비저닝: $2,000 총 구축 비용: $629,000	초기 연결 비용 네트워킹 하드웨어: $10,000 스토리지 하드웨어: $127,000 연결 프로비저닝: $2,000 총 구축 비용: $139,000
연간 비용 네트워킹 지원 계약: $15,000 서버 지원 계약: $34,050	연간 비용 네트워킹 지원 계약: $1,500 서버 지원 계약: $19,050
월별 비용 대역폭: $2,500 유틸리티: $8,000 평방 피트당 비용: $40 필요 면적(평방 피트): 400 IT 인력/지원: $15,000 총 월간 비용: $41,500	월간 비용 대역폭: $2,500 Dedicated Interconnect 2개: $3,600 100GB 이그레스: $12 총 월간 비용: $6,112
렌더링 작업장 사용률 월간 사용률: 50% 월간 렌더링 시간: 36,500시간	렌더링 작업장 사용률 인스턴스 수: 100개 머신 유형: n1-standard-32, 선점형 월간 사용률: 50% 월간 렌더링 시간: 36,500시간
렌더링 시간당 비용: $5.62	렌더링 시간당 비용: $1.46

요약

기존 렌더링 작업장을 클라우드로 확장하는 것은 자본 비용 없이 강력한 저가 리소스를 활용할 수 있는 경제적인 방법입니다. 똑같은 프로덕션 파이프라인은 없기 때문에 어떠한 문서도 모든 주제와 특별한 요구사항을 다룰 수는 없습니다. 렌더링 워크로드를 클라우드로 이전하는 데 도움이 필요하면 Google Cloud 담당자에게 문의하세요.

다음 단계

Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기