미디어 워크로드를 위한 권장사항

이 페이지에서는 미디어 워크로드에 Cloud Storage를 사용할 때의 권장사항을 설명합니다. 이러한 워크로드에는 Media CDN, Live Stream API, Transcoder API, Video Stitcher API와 같은 다양한 Google Cloud 제품이 포함되는 경우가 많습니다.

개요

Google Cloud 는 다음 유형의 미디어 워크로드를 최적화하기 위한 솔루션을 제공합니다.

  • 미디어 프로덕션: 컴퓨팅 사용량이 높고 고성능 컴퓨팅을 위해 GPU를 사용하는 경우가 많은 동영상 편집을 포함한 동영상 포스트 프로덕션과 같은 워크로드를 포함합니다. Cloud Storage에 있는 미디어 관련 데이터는 Compute Engine 또는 Google Kubernetes Engine에서 실행되는 애플리케이션에서 처리되는 경우가 많으며, 이러한 프로세스의 출력이 다시 Cloud Storage에 기록됩니다. 이러한 워크로드는 Cloud Storage에서 컴퓨팅 클러스터로의 총 읽기 및 쓰기 처리량을 확장하고 GPU 유휴 시간을 줄일 필요가 있습니다. 또한 꼬리 지연 시간을 줄이기 위해서도 읽기 및 쓰기 지연 시간을 낮게 유지해야 합니다.
  • 미디어 애셋 관리: 효율적인 스토리지, 검색, 사용을 위한 미디어 애셋 관리를 포함합니다.
  • 콘텐츠 서빙 및 배포: 주문형 동영상(VoD) 및 라이브 스트리밍 서비스를 비롯한 사용자에 대한 미디어 스트리밍을 포함합니다. VoD 중에 사용자가 콘텐츠 전송 네트워크(CDN)에 캐시되지 않은 콘텐츠를 요청하면 Cloud Storage 버킷에서 콘텐츠를 가져옵니다. 라이브 스트리밍 요청의 경우 스토리지 버킷에 콘텐츠 기록과 CDN에서 읽기가 동시에 수행됩니다.

미디어 워크로드를 위한 권장사항

미디어 워크로드에 적용되는 권장사항은 다음 섹션을 참조하세요.

데이터 전송

Storage Transfer Service를 사용하여 동영상 카메라 또는 온프레미스 스토리지와 같은 온프레미스 소스에서 Cloud Storage로 1TiB 이상의 원시 미디어 파일을 업로드합니다. Storage Transfer Service는 객체 및 파일 스토리지 시스템 간에 원활한 데이터 이동을 지원합니다. 소규모 전송의 경우에는 전송 시나리오에 따라 Cloud Storage 간 데이터 전송 또는 파일 시스템 간 전송 서비스를 선택합니다.

버킷 위치

미디어 프로덕션과 같은 컴퓨팅 리소스가 필요한 워크로드의 경우 컴퓨팅 리소스와 동일한 리전 또는 이중 리전에 버킷을 만들어야 합니다. 이 방법은 처리 워크로드, 비용, 대역폭의 읽기 및 쓰기 지연 시간을 줄여서 성능을 최적화하는 데 도움이 됩니다. 버킷 위치 선택에 대한 자세한 내용은 버킷 위치 고려사항을 참조하세요.

스토리지 클래스

미디어 워크로드 유형에 따라 선택해야 할 스토리지 클래스가 달라집니다. 각 미디어 워크로드에 권장되는 스토리지 클래스 유형은 다음과 같습니다.

  • 아카이브 동영상과 같은 미디어 애셋을 관리하기 위해서는 버킷의 기본 스토리지 클래스가 Archive Storage여야 합니다. 가용성 또는 액세스 요구가 각기 다른 객체에 대해 서로 다른 스토리지 클래스를 지정할 수 있습니다.
  • 미디어 프로덕션 및 콘텐츠 서빙 워크로드의 경우 Cloud Storage 버킷에서 데이터를 자주 읽으므로, Standard Storage에 데이터를 저장해야 합니다.

버킷의 스토리지 클래스 선택에 대한 자세한 내용은 스토리지 클래스를 참조하세요.

데이터 수명 주기 관리

미디어 애셋 관리를 위해서는 수명 주기 구성을 정의하여 버킷의 객체 수명 주기를 관리해야 합니다. 객체 수명 주기 관리 기능을 사용하면 객체의 TTL(수명) 설정, 객체의 이전 버전 보존, 비용 관리를 위한 객체 스토리지 클래스 다운그레이드를 포함하여 데이터 수명 주기를 관리할 수 있습니다.

데이터 패턴이 예측 가능한 경우에는 버킷의 수명 주기 구성을 설정할 수 있습니다. 데이터의 액세스 패턴이 예측 불가능하거나 알 수 없으면 버킷의 자동 클래스 기능을 설정할 수 있습니다. Cloud Storage는 자동 클래스를 통해 자주 액세스되지 않는 데이터를 저비용 콜드 스토리지 클래스로 자동으로 이동합니다.

클라이언트 서빙 및 배포 워크로드를 위한 권장사항

VoD 및 라이브 스트리밍 워크로드 모두 재생 오류, 재생 시작 지연, 최종 사용자의 동영상 플레이어에서 동영상을 재생할 때 발생하는 버퍼링을 방지하는 것이 목표입니다. 또한 이러한 워크로드는 대규모 동시 뷰어 수를 고려하기 위한 읽기 확장이 필요합니다. 모든 경우에 고객 트래픽 읽기는 CDN을 통과해야 합니다.

콘텐츠 서빙 및 배포 워크로드에 적용되는 권장사항은 다음 섹션을 참조하세요.

효율적인 CDN 사용

Cloud Storage 버킷 앞에 콘텐츠 전송 네트워크(CDN)를 사용하면 CDN에 콘텐츠가 캐시되어 지연 시간을 줄이고 대역폭 효율성을 높여주므로 최종 사용자 경험이 개선됩니다. CDN을 사용하면 대역폭 비용을 줄이고, 리소스 사용률을 최적화하고, 성능을 개선하여 총소유비용(TCO)을 줄일 수 있습니다. Media CDN은 캐시 채우기 비용이 없으므로 최종 사용자에게 콘텐츠를 제공하기 위한 TCO를 줄이는 데 도움이 됩니다. Media CDN은 다른 서드 파티 CDN의 소스로 사용할 수 있습니다. 다른 CDN을 사용하면 원점 대신 이 Media CDN 캐시에서 콘텐츠를 제공할 때 일부 TCO 감소 효과를 얻을 수 있습니다.

서드 파티 CDN을 사용 중일 때 CDN Interconnect는 선택한 공급업체가 다양한 위치에서 Google 에지 네트워크와 다이렉트 피어링 링크를 설정할 수 있게 해줍니다. 이러한 링크 중 하나를 통해 Google Cloud에서 이그레스되는 네트워크 트래픽은 지원되는 CDN 제공업체로 직접 연결되고 요금은 할인된 가격으로 자동 청구됩니다. 승인된 공급업체 목록은 Google 승인 서비스 제공업체를 참조하세요.

다음은 CDN을 설정할 때 구성할 수 있는 옵션을 보여줍니다.

원본 실드 위치 선택

원본 실드 위치는 CDN과 Cloud Storage 사이의 캐시입니다. CDN에서 원본 실드 위치를 선택할 수 있으면 CDN 가이드라인에 따라 원본 실드를 Cloud Storage 버킷의 리전에 가깝게 배치하는 것이 나은지 아니면 최종 사용자 트래픽 집중 위치에 가깝게 배치하는 것이 더 나은지 결정하세요. 원본 실드는 원본 서버가 과부하되지 않도록 보호하는 수단입니다. 원본 실드가 있는 CDN은 원본과 CDN 사이에 추가 캐시를 배치하여 원본을 오프로드하는 데 도움이 됩니다. 예를 들어, Media CDN은 가능한 한 캐시 채우기를 적극적으로 최소화하도록 설계된 심층 계층 에지 인프라를 제공합니다.

요청 병합 사용 설정

CDN에 요청 병합이 사용 설정되어 있는지 확인합니다. 여러 요청을 단일 요청으로 병합하면 Cloud Storage 클래스 B 작업 비용이 줄어듭니다. CDN에는 전 세계에 걸쳐서 분산 캐시가 배포되었지만 여러 최종 사용자 요청을 원본에 대한 단일 요청으로 병합하는 방법을 제공합니다. 예를 들어 Media CDN은 동일한 캐시 키에 대한 여러 사용자 기반 캐시 채움 요청을 에지 노드별 단일 원본 요청으로 병합함으로써 버킷에 수행되는 요청 수를 줄여줍니다.

CDN에서 재시도 동작 구성

CDN에서 HTTP 5xx 응답 코드(502, 503, 504)를 반환하는 서버 문제에 대한 재시도 동작을 구성해야 합니다. CDN은 원본 재시도를 지원하여, 원본에 대한 실패한 요청을 재시도하도록 허용합니다. 대부분의 CDN에서는 현재 원본의 재시도 횟수를 지정할 수 있습니다. Media CDN에서 원본 요청 재시도에 대한 자세한 내용은 원본 요청 재시도를 참조하세요.

콘텐츠 배포를 위한 위치 옵션

VoD 유형 콘텐츠의 콘텐츠 서빙 및 배포와 같이 CDN에 캐시되지 않은 데이터를 Cloud Storage에서 읽는 워크로드의 경우 버킷 위치를 선택할 때 다음 요소를 고려하세요.

  • 비용 최적화를 위해 단일 리전에 생성된 버킷은 스토리지 비용이 가장 낮습니다.
  • 가용성 최적화를 위해 다음을 고려하세요.
    • 대부분의 미디어 워크로드에서는 가용성 향상을 위해 2개의 리전에 객체를 복제하도록 이중 리전 버킷을 사용하는 것이 좋습니다.
    • 지리적 중복성과 함께 콘텐츠 서빙 및 분석이 필요한 사용 사례의 경우 최고 수준의 가용성을 위해 멀티 리전의 버킷을 사용합니다.
  • 지연 시간을 최적화하고 네트워크 비용을 줄이기 위해서는 다음을 고려하세요.
    • VoD의 경우 최종 사용자가 대부분 있는 위치와 가장 가까운 리전 또는 트래픽 집중이 가장 큰 리전을 선택합니다.
    • 라이브 스트리밍 중에 버킷은 트랜스코더에서 쓰기 요청을 수신하고 콘텐츠를 캐시하고 최종 사용자에게 배포하는 CDN에서 읽기 요청을 수신합니다. 스트리밍 성능 개선을 위해서는 트랜스코딩에 사용되는 컴퓨팅 리소스와 동일한 리전에 있는 리전 버킷을 선택합니다.

라이브 스트림을 위한 동영상 세그먼트 길이 최적화

라이브 스트림의 경우 짧은 동영상 세그먼트가 롱테일 쓰기 지연 시간에 더 민감하기 때문에 최저 권장 세그먼트 크기는 2초입니다. 롱테일 쓰기 지연 시간은 액세스 빈도가 낮거나 요청 볼륨이 낮은 콘텐츠에 대한 느리거나 지연된 쓰기 작업을 의미합니다.

버킷 위치와 최종 사용자의 재생 위치 사이의 물리적 거리는 전송 시간에 영향을 줍니다. 최종 사용자가 버킷 위치에서 멀리 있으면 동영상 세그먼트 크기를 길게 하는 것이 좋습니다.

시청자에게 최적의 경험을 제공하려면 트랜스코더의 Cloud Storage 쓰기 작업에 2초 이상의 롱테일 지연 시간을 완화하고, 약 10초 정도의 긴 버퍼 시간을 실험적으로 적용할 수 있도록 재시도 전략과 요청 헤징을 사용하는 것이 좋습니다.

점진적 QPS 늘리기

Cloud Storage 버킷은 초기 IO 용량을 기준으로 초당 최대 1,000개의 객체를 쓸 수 있고 5,000개의 객체를 읽을 수 있습니다. 라이브 스트림 워크로드의 경우 초당 1,000개 쓰기와 5,000개 읽기로 시작하고 20분마다 요청 비율을 두 배로 늘려서 점차적으로 요청을 확장하는 것이 좋습니다. 이렇게 하면 Cloud Storage가 여러 서버 간에 부하를 재배포할 수 있으며 재생 문제가 발생할 가능성을 줄여서 버킷의 가용성과 지연 시간이 개선할 수 있습니다.

QPS가 더 높은 라이브 스트림 이벤트의 경우 버킷을 사전 준비하거나 버킷에서 계층적 네임스페이스를 사용 설정하여 버킷에서 확장을 구현해야 합니다. 버킷에서 확장을 구현하려면 먼저 다음 태스크를 수행해야 합니다.

출처에 대한 QPS 추정

시청자 수가 100만 명인 라이브 스트림이 있다고 가정해 보세요. CDN에는 100만 개의 QPS가 수신됩니다. CDN의 캐시 적중률은 99.0%이며, Cloud Storage에 대한 결과 트래픽은 1%입니다. QPS는 총 뷰어(100만) 중 1%이며, 이는 10,000 QPS에 해당합니다. 이 값은 초기 IO 용량보다 많습니다.

QPS 모니터링 및 확장 오류 문제 해결

QPS를 모니터링하고 모든 확장 오류를 문제 해결해야 합니다. 자세한 내용은 Cloud Storage의 모니터링 개요를 참조하세요. 읽기 및 쓰기 요청을 모니터링하려면 Google Cloud 콘솔에서 총 읽기/나열/가져오기 요청 수 차트와 총 쓰기 요청 수 차트를 각각 모니터링합니다. 이전 섹션에서 언급한 지정된 늘리기 가이드라인보다 빠르게 버킷에서 QPS를 확장하면 429 너무 많은 요청 오류가 발생할 수 있습니다. 429 너무 많은 요청 오류 해결 방법을 알아보세요.

다음 섹션에서는 원점에 대해 QPS를 추정한 후 높은 QPS를 위해 버킷을 확장하는 방법을 설명합니다.

버킷을 사전 준비하여 버킷에서 QPS 확장 구현

버킷을 사전 준비하여 라이브 스트리밍 이벤트 전에 확장 프로세스 속도를 높일 수 있습니다. 라이브 스트리밍 이벤트 전에 버킷에 대한 합성 트래픽을 생성해야 합니다. 이 트래픽은 이벤트 기간 동안 CDN의 원본 서버가 받을 것으로 예상되는 최대 QPS와 일치합니다. 또한 예상되는 CDN의 캐시 적중률을 기준으로 50% 버퍼를 추가합니다. 예를 들어 이벤트 기간 동안 원본에 대한 추정 QPS가 10,000개로 예상되는 경우, 이벤트에 대해 원본을 준비하기 위해 초당 15,000개의 요청을 시뮬레이션해야 합니다.

이 시뮬레이션된 트래픽에는 세그먼트 및 매니페스트와 같은 이전 이벤트의 실시간 피드 파일 또는 테스트 파일을 사용해야 합니다. 사전 준비 프로세스 전반에 걸쳐서 파일이 고유해야 합니다.

이 시뮬레이션된 트래픽을 생성할 때는 초당 5,000개 요청부터 시작해서 목표에 도달할 때까지 점진적으로 개수를 늘리는 점진적 확장 방법을 따릅니다. 예상되는 부하를 달성할 수 있도록 이벤트 전에 충분한 시간을 할당합니다. 예를 들어 초당 5,000개 요청으로 시작해서 20분마다 부하를 두 배로 늘려 초당 15,000개 요청에 도달하려면 약 30분이 걸립니다.

원본 서버는 트래픽이 일관적일 때까지 용량을 유지합니다. 원본 서버의 용량은 24시간 동안 기준 레벨로 점차적으로 감소합니다. 원본 서버에서 라이브 스트림 이벤트 사이에 몇 시간이 걸리는 경우, 각 이벤트 전에 트래픽을 시뮬레이션하는 것이 좋습니다.

높은 초기 QPS를 위해 계층적 네임스페이스가 사용 설정된 버킷 사용

계층적 네임스페이스가 사용 설정된 Cloud Storage 버킷은 HNS가 없는 버킷보다 최대 8배 더 많은 초기 QPS를 제공합니다. 초기 QPS가 높을수록 데이터 집약적인 워크로드를 더 쉽게 확장하고 처리량을 개선할 수 있습니다. 계층적 네임스페이스가 사용 설정된 버킷의 제한사항에 대한 자세한 내용은 제한사항을 참조하세요.

QPS 확장을 위한 동영상 세그먼트의 순차적 이름 방지

QPS 확장을 사용할 경우 요청이 여러 서버 간에 재배포됩니다. 하지만 모든 객체에 무작위로 지정되지 않았거나 순차적인 프리픽스가 사용된 경우에는 성능 병목 현상이 발생할 수 있습니다. 순차적 이름 대신 완전한 무작위 이름을 사용하면 부하 분배가 최적으로 수행됩니다. 하지만 객체 이름의 일부로 일련의 숫자나 타임스탬프를 사용하려면 일련의 숫자나 타임스탬프 앞에 해시 값을 추가하여 객체 이름에 임의성을 도입합니다. 예를 들어 사용하려는 원본 객체 이름이 my-bucket/2016-05-10-12-00-00/file1이면 원본 객체 이름의 MD5 해시를 계산하고 해시의 처음 6개 문자를 객체 이름 프리픽스로 추가할 수 있습니다. 새 객체는 my-bucket/2fa764-2016-05-10-12-00-00/file1.이 됩니다. 자세한 내용은 전체 키 범위에 걸쳐 부하를 균일하게 분배하는 이름 지정 규칙 사용을 참조하세요. 동영상 세그먼트에 순차적 이름 지정을 피할 수 없으면 계층적 네임스페이스가 사용 설정된 버킷을 사용하여 더 높은 QPS를 가져옵니다.

각 라이브 스트림마다 다른 버킷 사용

동시 라이브 스트림의 경우 각 라이브 스트림에 서로 다른 버킷을 사용하면 버킷의 IO 한도에 도달하지 않고도 읽기 및 쓰기 부하를 효과적으로 확장하는 데 도움이 됩니다. 각 라이브 스트림에 서로 다른 버킷을 사용하면 확장 지연으로 인해 큰 이상치 지연 시간이 감소합니다.

다음 단계