AWS 하이브리드 렌더팜 아키텍처를 위한 스토리지 캐시 설계

클라우드 컴퓨팅은 새로운 기준(New Norma)이 되었습니다. 컴퓨팅 리소스가 필요한 산업군 어디에서나 이제는 클라우드를 먼저 생각합니다. 미디어 및 엔터테인먼트 시장도 예외는 아닙니다. 특히 컴퓨팅 자원이 많이 필요한 렌더링 분야에서 빠르게 성장하고 있습니다.

사용자들은 점점 4K 영상과 같은 더 높은 해상도를 원하고 있으며 이에 따라 데이터와 콘텐트 셋의 크기도 더 커지고 있습니다. 이런 데이터를 렌더링하기 위해서는 더 높은 성능과 더 많은 컴퓨팅 자원이 필요합니다. 하지만, 자체 렌더팜에 대한 TCO는 매우 높습니다. 프로듀서나 렌더팜 운영 담당자는 일반적으로 프로젝트를 진행한 후 얼마 지나지 않아 곧 보유한 용량보다 더 많은 컴퓨팅 자원이 필요한 것을 깨닫게 됩니다. 그리고 이런 일들은 새로운 프로젝트가 진행될 때마다 반복됩니다. 반면에 컴퓨팅 자원을 탄력적으로 확보하고 확장하는 것은 매우 어렵고 비용도 많이 듭니다.

클라우드를 통한 동영상 렌더링 요구 사항
이런 요구에 대한 해결 방법으로 제3의 공급자 솔루션을 찾거나 렌더팜 대여 업체를 통하면 해결 가능할 것으로 생각하기도 합니다. 하지만 이런 방법을 통해서는 정확하게 고객의 요구사항을 맞추는 것은 어려우며, 필요한 시점에 원하는 용량을 확보해서 사용하는 것도 어렵습니다. 무엇보다 콘텐트에 대한 보안이 가장 높은 우려 사항입니다.

그래서 클라우드를 활용하는 것이 큰 대안으로 고려되고 있습니다. 클라우드를 사용하여 얻는 장점들이 많이 있지만, 필요할 때 원하는 만큼의 컴퓨팅 용량을 바로 사용할 수 있는 탄력성을 손꼽을 수 있습니다. 이 특징은 렌더링 시장에서 클라우드를 사용할 수 밖에 없는 가장 중요한 이유이기도 합니다.

렌더링을 주로 하는 분야는 비주얼 이펙트(VFX)와 애니메이션 스튜디오입니다. 컴퓨팅 자원 소비에 따라 스튜디오를 분류해보면 아래 그림처럼 티어-1, 티어-2 그리고 티어-3으로 시장을 세분화할 수 있습니다.

티어-1은 월트 디즈니 애니메이션 스튜디오처럼 전세계적으로 몇 안 되는 대형 스튜디오들이 해당 됩니다. 이런 스튜디오는 주로 리눅스로 구성되어 있고 1,000노드에서 10,000노드 규모의 렌더팜을 자체적으로 운영하고 있습니다. 티어-2 규모의 스튜디오는 중형 스튜디오나 부띠크 포스트들로 100노드에서 500노드 규모의 렌더팜을 운영합니다. 전세계적으로 250개 정도의 스튜디오가 있으며, 기호에 따라 리눅스나 윈도우를 구성해 운영합니다. 티어-3 는 전세계적으로 10,000개 이상의 소형 스튜디오부터 개별 사용자와 프로수머로 구성되어 있습니다. 이들은 주로 윈도우 환경에서 렌더링 작업을 수행합니다.

렌더링 작업을 위해 클라우드를 고려할 때, 대형 및 중형 스튜디오들은 렌더링에 최적화된 자체 렌더팜과 클라우드 렌더팜을 함께 활용하는 하이브리드 파이프라인 아키텍처를 일반적으로 고려합니다. 반면에 중소형 스튜디오는 렌더링 작업을 온전히 클라우드에서 수행하는 올-인 파이프라인 아키텍처를 고려합니다. 각각의 아키텍처는 2015년 re:invent에서 발표한 월트 디즈니 애니메이션 스튜디오에서의 클라우드 렌더링 세션을 통해서 확인할 수 있습니다.

중소형 스튜디오의 일반적인 클라우드 렌더링 아키텍처가 올-인 파이프라인 아키텍처이지만 하이브리드 아키텍처에 대한 요구도 적지 않습니다. 이렇게 하이브리드로 구성하게 되면, 컴퓨팅 자원을 필요한 만큼 탄력적으로 확보해서 그래픽 아티스트들에게 환경 변화 없이 아주 매끄럽게 렌더링할 수 있도록 구성 가능합니다. 즉, 렌더링하기 위해 클라우드로 씬파일이나 스크립트, 텍스처 이미지 등을 별도로 전송할 필요 없이 아티스트들이 기존과 동일하고 투명하게 렌더링 작업이 가능한 환경을 제공할 수 있습니다. 또한 보유하고 있는 온-프레미스 렌더팜과 클라우드 렌더팜을 연동할 수 있기 때문에 기투자에 대한 보호도 할 수 있습니다.

하이브리드 아키텍처에서의 핵심 구성요소는 클라우드 내에 스토리지 캐시를 구성하는 것입니다. 스토리지 캐시를 위해 중대형 스튜디오에서 활발하게 사용하는 제품은 AWS 파트너 생태계 솔루션인 Avere vFXT 엣지 파일러입니다. Avere vFXT 엣지 파일러는 아주 작은 워크로드에서부터 매우 큰 워크로드까지 상당히 안정적으로 그 역할을 수행합니다. 다만 예산과 비용에 제약을 많이 받는 작은 스튜디오는 이런 솔루션을 사용하는 것이 적잖은 부담으로 작용합니다.

그래서 이번 블로그에서는 윈도우를 주로 사용하는 소형 스튜디오에서 안정적이면서 비용 최적화할 수 있는 스토리지 캐시 솔루션을 도입해 하이브리드 아키텍처를 구축할 수 있는 방법을 소개하려고 합니다.

소형 스튜디오를 위한 하이브리드 아키텍처 소개
AWS에서는 마이크로소프트 윈도우 서버 AMI를 제공하고 있습니다. 이를 통해서 윈도우 서버 인스턴스를 클라우드에서 쉽게 생성하고, 윈도우 기반 렌더팜을 간단히 구축하여 렌더링 작업을 수행할 수 있습니다. 그리고 스토리지 캐시 솔루션은 윈도우 서버에 기본적으로 탑재된 MS BranchCache 기능을 활용하여 해결할 수 있습니다.

윈도우 BranchCache는 기본적으로 WAN 대역폭을 최적화하는 기술입니다. 이 기술을 활용하여 온-프레미스 데이터 센터 내에 있는 데이터를 AWS 클라우드에서 지연시간을 줄여서 빠르게 접근할 수 있도록 할 수 있습니다. BranchCache는 클라우드에서 온-프레미스에 있는 스토리지 콘텐츠를 접근할 때, WAN 대역폭을 최적화하기 위해 온-프레미스 데이터센터 콘텐츠를 복사해서 클라우드에 캐시하고, 클라우드에 있는 클라이언트들이 WAN이 아닌 로컬 내에서 콘텐츠를 바로 접근할 수 있도록 해줍니다.

BranchCache를 이용하여 클라우드에서 콘텐츠를 캐시하는 방법은 두 가지가 있습니다. 캐시 전용 호스트에 저장하거나 클라우드내에 있는 클라이언트 컴퓨터들 간에 분산 저장하는 방법입니다. 전자를 호스트 캐시 모드라고 하고, 후자를 분산 캐시모드라고 합니다. 분산 캐시모드는 호스트 캐시 서버로 사용할 수 있는 로컬 서버가 없는 소규모 환경에서 간단하게 구성하는 방법입니다. 분산 캐시 모드를 사용하는 경우 클라이언트가 오프라인 상태가 되면 캐시 효율이 떨어질 수 있습니다. 그래서 캐시 효율성을 안정적으로 높이고, 다중 서브넷의 모든 클라이언트에서도 콘텐츠를 접근할 수 있는 호스트 캐시 모드 사용을 권장합니다.

Microsoft BranchCache 구성
BranchCache 구성은 아래 그림처럼 3가지로 구성되어 있습니다. 온-프레미스 데이터 센터에 있는 콘텐츠 스토리지, 그리고 AWS 클라우드에 있는 호스트 캐시 서버와 캐시된 데이터를 접근하는 클라이언트입니다.

원본 데이터와 콘텐츠가 저장된 온-프레미스의 콘텐츠 스토리지는 BranchCache 기능이 탑재되어 있어야 합니다. 만일 컨텐츠 스토리지를 윈도우 서버 2008 R2 또는 그 이상의 윈도우 서버로 구성했다면 설정은 상대적으로 간단합니다. 공유 스토리지로 많이 사용되는 EMC VNX 스토리지와 NetApp 스토리지에도 이 기능이 탑재되어 있습니다. 따라서 사용하는 볼륨에 대해서 이 기능을 활성화할 수 있습니다.

클라우드 내에 구성되는 호스트 캐시 서버는 윈도우 서버 2008 R2나 윈도우 서버 2012를 사용합니다. 호스트 캐시 서버는 콘텐츠 스토리지와 클라이언트인 렌더팜 노드들 사이에서 동작하며, 이를 통해서 렌더팜 노드들이 온-프레미스에 있는 컨텐츠 스토리에 대한 접근을 최소화시켜 데이터를 빠르게 접근하고 효과적으로 처리할 수 있도록 도와줍니다.

렌더팜 노드인 클라이언트가 온-프레미스 공유 콘텐츠 스토리지를 접속할 때, 데이터가 호스트 캐시 서버에 저장되어 있으면 바로 접근하여 지연시간을 극적으로 줄여 줍니다. 이를 통해 네트워크 성능을 개선하고, 대역폭 사용량도 줄이게 됩니다. 따라서 렌더팜 노드들이 클라우드에 배포된 캐시 서버를 통해 온-프레미스 데이터 센터와 클라우드간의 속도와 생산성을 높일 수 있습니다.

AWS 클라우드		온-프레미스
렌더팜노드(클라이언트)	호스트 캐시 서버	콘텐츠 스토리지
윈도우 7,8, 및 10 또는 윈도우 서버 2008 R2 또는 그 이상	윈도우 서버 2008 R2 또는 그 이상	윈도우서버 2008R2 또는 그 이상
		EMC VNX 스토리지
		NetApp 스토리지
		BranchCache 기능이 있는 기타 스토리지

BranchCache를 사용할 때의 추가적인 장점은 네트워크 토폴로리를 특별하게 변경하지 않고도 호스트 캐시 서버를 추가하고 간단한 구성과 설정만으로 온-프레미스와 클라우드 간의 데이터 교환 성능을 향상시킬 수 있도록 해줍니다.

MS BranchCache 설정하기
이 기능을 사용하기 위해서는 온-프레미스 콘텐츠 저장 스토리지상에서 공유 볼륨에 대해 BranchCache 기능을 활성화합니다. 설정 방법은 아래에 있는 스토리지 공급사에서 제공하는 절차를 따릅니다.

EMC VNS 스토리지 – Configuring BranchCache on VNX
NetApp 스토리지 – Configuring BranchCache – NetApp
윈도우 서버 2008 R2 또는 그 이상 (예: 2012 설치 가이드)

호스트 캐시 서버의 경우는 윈도우 서버 2008 R2보다는 그 이상의 서버로 구성하기를 권장합니다. 윈도우 2008 R2를 사용할 경우 호스트 캐시 서버와 클라이언트에 인증서를 등록하는 절차를 수행해야 하기 때문에 구성 방법이 다소 복잡합니다. 반면 윈도우 서버 2012의 경우는 인증서를 등록하지 않고도 쉽게 구성할 수 있으며, 다중의 호스트 캐시 서버도 구성할 수 있는 장점을 제공합니다. 또한 캐시될 데이터를 호스트 캐시 서버에 미리 적재할 수 있는 기능도 제공합니다. 윈도우 서버 2012를 이용한 호스트 캐시 서버 설정 방법은 Microsoft 기술 문서를 참조합니다.

AWS 에서 렌더팜으로 사용되는 BranchCache 클라이언트의 경우 AWS에서 기본으로 제공하는 윈도우 서버 AMI로 구성하거나, EC2 가져오기 기능을 활용해서 윈도우 7, 8 및 10과 같은 클라이언트 운영체제를 AWS내로 가져와서 구성할 수 있습니다. 후자의 경우 Microsoft로부터 별도의 라이선스를 구매(BYOL)해야 하고 EC2 전용 인프라에서 구성해야합니다. 따라서 특별한 요구 사항이 없다면 AWS에서 기본으로 제공하는 윈도우 서버 AMI를 활용해서 구성합니다. 다만 BranchCache 클라이언트는 파일 및 폴더의 SMB 캐싱을 위해 오프라인 파일 기능을 활용한다는 것을 유념해야 합니다. 이 기능은 윈도우 클라이언트 운영체제에는 기본적으로 설치되어 있지만, 윈도우 서버에는 설치되어 있지 않습니다. 따라서 윈도우 서버 AMI를 활용하는 경우 아래 작업이 선행되어야 합니다:

작업표시줄에서 서버 관리자를 클릭합니다
역할과 기능추가를 클릭하고 다음을 클릭합니다
역할기반 또는 기능기반 설치를 선택하고 다음을 클릭합니다
서버 선택의 기본 설정을 그대로 두고 다음을 클릭합니다
서버 역할의 기본 설정을 그대로 두고 다음을 클릭합니다
BranchCache 기능을 선택합니다
User Interfaces and Infrastructure 밑에 있는 Desktop Experience를 선택합니다
팝업 창에서 요구하는 추가 기능에 대해서 Add Features를 선택한 후 다음을 클릭합니다
Install을 클릭합니다
설치가 종료될 때까지 대기하고, 끝나면 닫기를 클릭합니다
재시작을 수행합니다
윈도우에 원격 접속합니다
마우스를 시작 메뉴에 올려놓고 우측 마우스를 클릭합니다
제어판을 클릭합니다
Sync Center를 선택합니다
Manage offline files를 선택합니다
Enable offline files를 선택합니다

이 절차가 끝난 이후에는 Microsoft 기술 문서를 참고하여 클라이언트 설정을 마무리하고 테스트를 해봅니다.

맺으면서
BranchCache를 활용한 스토리지 캐시 솔루션은 소형 스튜디오의 하이브리드 렌더팜 아키텍처 설계에 많은 장점을 제공합니다. 스토리지 캐시를 위한 별도의 전용 어플라이언스 구매없이 윈도우 서버 인스턴스만으로 간단히 구성할 수 있기 때문에 비용 부담을 덜어줍니다. 또한 구성 방법도 간단하고 기존의 네트워크 환경 및 전체 아키텍처에 대한 변경 없이 가능합니다. 복잡한 구성 변경 없이 단순히 호스트 캐시 서버를 추가하면 되고, 각 구성요소들간에 BranchCache 기능만 활성화하고 설정만 하면 됩니다. 이를 통해서 온-프레미스와 AWS 클라우드간의 데이터 이동을 최소화해서 지연시간과 대역폭 문제를 해결 할 수 있습니다.

또한, AWS 클라우드 내에 있는 렌더팜 노드들이 동일한 공간에 있는 스토리지 캐시 노드에서 데이터를 빠르게 읽을 수 있고, 이를 통해 렌더링 처리를 하므로 보다 빠른 결과물을 얻을 수 있습니다. 렌더링 작업이 끝나면 AWS 클라우드 내에 있던 모든 렌더팜 노드들과 더불어 스토리지 캐시를 제거함으로써 사용한 인스턴스 비용만을 지불할 수 있어서 비용도 최적화 할 수 있습니다. 이번 블로그를 통해서 여러분들의 온-프레미스 렌더팜 확장 용도로AWS클라우드가 활용될 수 있다는 아이디어를 얻으셨기를 기대해봅니다.

본 글은 아마존웹서비스 코리아의 솔루션즈 아키텍트가 국내 고객을 위해 전해 드리는 AWS 활용 기술 팁을 보내드리는 코너로서, 이번 글은 박철수 솔루션즈 아키텍트께서 작성해주셨습니다.