1:1 수준의 개인화된 시청 환경은 TV 경험을 변화시키고 있습니다. 시청자는 한 가지 방식으로 모든 시청자에게 적합한 광고, 맞춤형 콘텐츠, 새 프로그램 추천, 정확한 DRM/차단 관리 등 시청자의 디바이스 유형, 위치, 기록, 인구 통계 및 기타 데이터를 기반으로 타겟팅되고 관련성이 높은 광고, 맞춤형 콘텐츠, 정확한 DRM/차단 관리를 받을 수 있습니다.
그러나 개인화된 비디오 스트림을 수백만 명의 시청자로 확장하는 것은 특히 스포츠와 같은 라이브 프로그래밍의 경우 야구 경기에서의 사이클을 타격하는 것만큼이나 어렵습니다. 시청자 볼륨은 킥오프, 초과 근무, 근접 경기 등 반드시 봐야 할 순간에 수십만 명이 급증할 수 있습니다. 개인화를 지원하는 인프라가 적응성과 확장성이 부족하다고 가정해 보십시오. 이 경우, 개인화된 경험은 게임 오버가 될 것이며, OTT의 세계에서 전체 비즈니스가 위험에 처할 수 있습니다.
매니페스트 서버의 개인 설정 중심 역할
OTT 개인화는 매니페스트 서버의 성능에 달려 있어 컨텐츠, 광고 및 재생 지침의 고유한 재생 목록을 생성합니다. 매니페스트 서버는 다음 종속성과 경합해야 합니다.
- AD 서버 지연 시간 – AD 서버와의 통신은 특히 여러 홉이 관련된 경우 워크플로우에 고려해야 하는 지연 시간을 추가할 수 있습니다.
- 수익 창출/보고 – 광고가 재생되면 광고 노출을 측정하고 수익을 창출할 수 있도록 비콘을 광고 (s)로 다시 전송해야 합니다.
- 인터넷의 상태 비저장 측면 – 개인화된 매니페스트가 규모에 맞게 작동하려면 각 시청자에 대한 여러 요청 전반에 걸쳐 상태를 유지해야 합니다.
- DRM/인증 – 매니페스트 서버는 DRM(디지털 권한 관리), 세션 수준 암호화 및 인증을 계속 모니터링해야 합니다.
- 차단/콘텐츠 권한 및 제한 – 사용자의 위치에 따라 스트리밍 콘텐츠는 다양한 차단 규칙의 적용을 받을 수 있으며, 이 모든 규칙은 정확하게 관리되어야 합니다.
- 콘텐츠 추천 – 온라인 시청자는 검색 및 검색 프로세스에 도움이 되는 권장 사항을 알고 맞춤화할 수 있기를 기대합니다.
- 컨텐츠 현지화 – 주요 이벤트의 경우 오디오 트랙, 청각 장애인용 자막, 자막 등 지역별 변형을 사용자에게 제공하는 것이 중요합니다.
실시간 스트림 개인화
이 블로그 시리즈의 1부에서 다룬 바와 같이 라이브 또는 VOD 피드는 슬라이서 소프트웨어 응용 프로그램에서 인제스트, 인코딩 및 패키징됩니다. 콘텐츠 소유자가 시청자의 경험을 사용자 지정할 수 있도록 광고 경계를 삽입할 수 있습니다. 광고는 인제스트되면 클라우드에서 실행되는 슬라이서를 통해 처리되어 방송과 같은 재생 환경이 제공됩니다.
슬라이서가 라이브 또는 VOD 스트림을 수집하기 시작하면 백엔드 인프라와 지속적으로 통신하여 사용 가능한 세그먼트 수에 대한 데이터베이스를 업데이트합니다. 매니페스트 서버는 해당 데이터를 사용하여 각 뷰어에 대한 환경을 개인화합니다. 플레이어가 스트림을 요청하면 매니페스트 서버는 매니페스트 파일에 나열되어야 하는 비디오 및 오디오 세그먼트를 결정하며, 이 세그먼트는 재생 목록 역할을 합니다. 사용자별 수준에서 매니페스트를 동적으로 변경하거나 사용자 정의할 수 있으므로 시청 환경을 맞춤화할 수 있습니다. 라이브 비디오의 경우 몇 초마다 새 매니페스트가 요청되므로 보기 조건이 변경되면 매니페스트 서버에 의해 동적으로 조정이 적용될 수 있습니다.
비디오 스트림을 개인화하는 매니페스트 서버의 중심 역할
위에서 보듯이 매니페스트 개인화의 핵심은 커뮤니케이션입니다. 대부분의 OTT 비즈니스 요구 사항에서 이는 광고 서버와의 커뮤니케이션을 통해 타겟팅된 맞춤형 광고를 실시간으로 제공한다는 것을 의미합니다. 시청자의 IP 주소, 위치 및 장치 유형을 포함한 개별 데이터(기본적으로 엄격한 PII 규칙 및 규정을 준수하면서 캡처할 수 있는 모든 정보)가 광고 결정 시스템에 제공됩니다. 이 솔루션은 라이브 스트리밍 중에 광고를 전송할 때 시청자와 관련된 내용을 파악할 수 있을 만큼 강력합니다. 또한 이 시스템은 콘텐츠 추천 및 기타 현지화와 같은 중요한 개인화 기능을 지원하면서 차단 제한 및 사용자별 콘텐츠 권한 관리와 같은 과제에 대처할 수 있을 만큼 견고합니다.
확장할 매니페스트 인프라 설계
비디오 플랫폼에서 매니페스트 서버는 각 시청자에 대한 맞춤형 스트리밍 매니페스트를 생성하는 역할을 합니다. 또한 콘텐츠 제한 및 권장 사항과 같이 위에서 언급한 다른 요구 사항도 알고 있어야 합니다. 이 모델에서는 하나의 통합된 스트림을 전송합니다. 즉, 클라이언트가 스트림 중간에 광고가 로드되기를 기다리는 동안 “버퍼 휠” 문제가 없습니다.
탄력적인 매니페스트 전달 시스템을 구축하기 위해 전 세계 여러 지역에 분산된 매니페스트 생성 서버 클러스터를 클라우드에 유지 관리합니다. 예를 들어, 미국에서는 이러한 서버가 전국의 5 개 지역으로 구성되어 있습니다. 미국에 기반을 둔 플레이어로부터 새로운 스트림에 대한 요청이 들어오면 그 요청은 무작위로 미국 지역 중 하나로 라우팅됩니다.
‘천둥 무리’의 도전
이것은 직관적이지 않은 것처럼 보일 수 있지만 계단식 실패 모드를 방지하기 위해 수행됩니다. 미국 시청자의 대부분은 국가의 동부에 위치하고 있습니다. 가장 가까운 구역으로 라우팅할 때 클라우드 공급자가 해당 지역에서 장애를 경험했다면 대부분의 시청자가 장애를 경험했을 것입니다. 문제를 복잡하게 하면, 모든 시청자가 스트림을 새로 고치고 시청자를 다음 가장 가까운 건강한 영역으로 안내하면 실패한 영역의 모든 시청자가 다음 가장 가까운 영역으로 도그파일 화하는 “천둥 무리”문제가 발생합니다. 예상치 못한 트래픽 급증으로 인해 새로운 영역에 있는 시스템이 추가 수요에 맞게 확장될 때까지 2차 장애가 발생할 수 있습니다.
대신, 미국 시청자를 무작위로 배포하면 초기 장애의 영향을 완화하고 장애 조치 트래픽을 나머지 정상 영역에 균등하게 분산시킬 수 있습니다.
스트리밍 플랫폼에서는 매니페스트 서버 부하를 여러 영역에 분산시킵니다. 이렇게 하면 시청자가 급증하는 동안 특정 구역의 과부하를 방지할 수 있습니다. 특히 장애 조치 중에 시청자가 갑자기 인접 구역으로 이동하는 경우 더욱 그렇습니다.
각 영역에는 관련 세션 데이터를 저장하는 전용 데이터 저장소가 별도로 있습니다. 뷰어가 영역으로 라우팅되면 해당 뷰어에 대한 세션을 생성하고 영역의 세션 클러스터에 저장합니다. 세션은 뷰어에 대한 데이터와 고객이 해당 뷰어에 맞게 세션을 사용자 정의하는 방법에 대해 제공하는 매개 변수입니다. 인터넷의 상태 비저장 특성으로 인해 발생하는 문제를 극복하기 위해 매니페스트 서버는 플레이어에 반환된 매니페스트에 포함된 각 세션에 대한 URL을 빌드합니다. 플레이어의 후속 요청은 시청자의 세션이 생성되고 저장된 영역으로 직접 라우팅됩니다(다른 영역 중 하나로 임의로 라우팅되지 않음).
아래 세 그래프에서 볼 수 있듯이, 이벤트마다 청중의 규모와 청중이 지역적인지 또는 지리적으로 분산되어 있는지에 따라 다양한 요구 사항이 있을 수 있습니다. 방송사가 라이브 이벤트 지원에서 직면한 인프라스트럭처 과제를 보여주는 세 가지 예를 살펴보십시오.
첫 번째 시나리오에서 우리는 음식 먹기 경연 대회 (예, 우리는 이들 중 하나를 라이브 스트리밍했습니다)를 특징으로합니다. 왜냐하면 그것은 분산되어 있지만 작은 관객 크기를 보여줍니다. 아마도 음식 먹기 경연대회가 주류가 될 날이 올 것이지만, 현재로서는 넓은 지리적 측면에서 소수의 시청자를 끌어들이는 틈새 이벤트로 남아 있습니다. 매니페스트 서버 로드는 여러 영역과 매니페스트 서버 클러스터에 쉽게 분산됩니다. 각 지역에 적합한 광고를 쉽게 삽입할 수 있고, 권한 및 제한 사항을 관리할 수 있으므로 개인화의 가치가 분명해집니다.
이 시나리오는 텍사스 주 축구 선수권 대회, 많은 수의 시청자가 같은 지리에있는 경우 상당히 변경됩니다. 우리는 이것을 몇 가지 방법으로 처리합니다. 위에서 설명한 바와 같이, 시청자의 경험에 영향을 주지 않으면서 인접한 지역 외부에 위치한 매니페스트 서버에 시청자를 할당할 수 있습니다. 또한 각 영역의 시청률 수준을 모니터링하고 필요에 따라 구역별로 매니페스트 생성 서버를 자동으로 스핀업할 수 있는 시스템이 있습니다.
NBA 파이널과 같은 대규모 이벤트의 예상 시청률을 기준으로 사전 스케일을 조정할 수 있습니다. 그럼에도 불구하고 자동 스케일링 시스템이 사전 워밍업 없이도 거의 백만 명의 시청자를 처리한 여러 이벤트가 있었습니다. 확장성을 높일 수 있을 뿐 아니라 영역에 구애받지 않는 방식으로 매니페스트 서버 간에 로드를 즉시 분산할 수 있으므로 네트워크 전반의 안정성과 중복성이 크게 향상됩니다.
플레이어 요청 및 광고 표지
업계 전반의 수많은 변화와 추세로 인해 클라우드 확장이 그 어느 때보다 중요해지고 있습니다. 주요 동인은 플레이어의 요청 사이의 축소 간격입니다. 우리의 표준 라이브 리니어 8 초 “다음”플레이어 요청은 5 초로 진행되며 낮은 대기 시간이 중요한 스트림의 경우 2 초마다 짧을 수 있습니다. 이는 서버가 8초 간격에 비해 2초 간격으로 4배 많은 요청에 응답해야 하기 때문에 CPU 활용도에 큰 영향을 미칩니다. 또한 오류를 방지하기 위해 이전보다 더 자주 차단 및 콘텐츠 권장 사항을 확인해야 합니다.
마찬가지로 광고 기술 세계는 점점 더 복잡해지고 까다로워지고 있습니다. 스트림에 삽입되는 모든 광고에 대해 광고 서버는 보고 목적으로 사용되는 최소 5개의 비콘을 갖게 됩니다. SSAI(Server-Side Ad Insertion) 솔루션은 해당 비콘을 전송하여 고객이 광고주로부터 돈을 받을 수 있도록 해야 합니다. 5개의 비콘이 최소이지만 더 많을 수 있습니다. 사실, 우리는 단일 광고가 어디서나 30 ~ 100 비콘에보고하는 경우를 보았습니다.
또한, 광고 서버의 복잡한 네트워크는 고객의 캠페인에서 더욱 일반화되고 있습니다. 여러 광고 네트워크 홉이 대기 시간 문제를 일으킬 수 있습니다. 예를 들어, 네트워크 #1은 “이 휴식기의 광고 목록은 여기 있다”라고 말할 수 있지만, 해당 휴식기의 광고 #2는 다른 네트워크에 대한 요청이 필요하다는 것을 발견할 수 있다. 광고 #3은 두 개의 홉을 더 소개합니다.
위의 예에서 광고 중단은 CPU 사용률을 두 배 또는 세 배로 늘릴 수 있습니다. 라이브 비디오 플레이어 요청은 이 요인을 10-30% 가량 증가시킬 수 있습니다.
Looking ahead – 마이크로서비스 및 확장성
복잡성이 증가함에 따라, 우리가 취한 단계 중 하나는 이전에 매니페스트 서버에서 처리했던 다른 작업 부하를 더 작은 마이크로서비스로 분리하는 것입니다. 우리가 만든 첫 번째 단계는 광고 서버 통신과 비컨닝을 자체 서비스로 이동하여 광고 서버 지연 문제를 해결하는 것입니다. 이 광고 프록시 서비스는 향후 블로그 게시물에서 더 자세히 논의할 몇 가지 고급 기능을 제공합니다.
앞으로도 매니페스트 서버에서 더 많은 작업을 제거하고 확장성에 대한 보다 타겟팅된 접근 방식을 제공하기 위해 다른 마이크로서비스를 계속 개발할 것입니다. 조만간 여러 클라우드 제공업체의 존을 추가하여 단일 클라우드 제공업체의 장애에 대처할 수 있도록 지원할 예정입니다.
확장 가능한 SSAI를 마이크로서비스와 결합함으로써 서버 비용, 코드 기반 구조 및 광고 트래픽과 관련된 기타 특성을 최적화할 수 있습니다. 또한 광고 서버 지연 시간, 차단 제한, 수익 창출 등 몇 가지 주요 문제를 해결할 수 있습니다. 동시에, 처리 부담을 여러 영역에 분산시킴으로써 Akamai의 라이브 비디오 스트리밍 서비스는 광범위하게 확장하고 주요 과제를 극복할 수 있으므로 전송 네트워크에 부담을 주지 않으면서 수백만 개의 동시 개인화된 스트림을 안정적으로 전송할 수 있습니다.