GigaOM Radar Edge Platform Leader & Outperformer 2024 | 
라이브 스포츠는 보는 것이 흥미롭습니다. 특히 중요한 순간에, 샷이 게임에서 승리하기 위해 아무데도 나오지 않을 때와 같은. 이러한 순간은 유동적인 실시간 액션을 담당하는 기술 팀에게도 흥미로울 수 있습니다. 라이브 스포츠 스트림은 몇 가지 기술적 고려 사항과 균형을 이루어야 하며, 현장에서 라이브 게임보다 평균 30초 뒤처져야 합니다. 왜 늦어지는가?
콘텐츠 전송 네트워크는 필수적이지만 비디오 워크플로우의 다른 부분으로 인해 발생하는 지연 시간을 줄일 수는 없습니다. 예를 들어, 이미지가 신호로 변환될 때 인제스트 시점부터 대기 시간이 추가됩니다. 그런 다음 원시 신호를 압축된 형식으로 변환하여 비디오 프로세싱 센터로 전송해야 합니다. 일반적으로 오프사이트와 클라우드로 전송해야 하는데, 이는 가용 대역폭과 인프라의 영향을 받을 수 있습니다. 다음은 다양한 장치 및 대역폭에 맞게 콘텐츠를 트랜스코딩하고 패키징하는 과정입니다. 마지막으로, 스트림이 재생됨에 따라, 광고가 인터넷의 마지막 마일을 통해 시청자의 디바이스로 이동하기 직전에 스트림에 동적으로 삽입될 수 있다. 여기서 플레이어는 디코딩을 버퍼링하고 압축을 풀고 최종 비디오 세그먼트를 렌더링합니다. 이는 팀의 승리 목표와 콘텐츠 전송 네트워크 사이에는 많은 단계가 있습니다. 그리고 그들은 더할 수 있습니다, 특히 수백만 명의 시청자에게 동시에 일어날 때. 예를 들어, 슈퍼볼 라이브 스트림의 지연 시간은 평균 28 ~ 47초입니다.
스트리밍 서비스 제공업체는 지연 시간을 줄이는 데 주력하고 있습니다. 경마와 같은 초 단위의 게임 베팅에 묶인 스포츠의 경우 지연된 스트림은 원격 참가자에게 경기장에 있는 참가자에게 불리한 영향을 미칩니다. 시청자 및 뉴스캐스터의 라이브 트윗은 TV 및 라이브 스트리밍으로 시청하는 팬들에게 흥미로운 순간을 망칠 수 있습니다. 또한 스포츠 생중계를 시청하는 시청자가 점점 더 많아짐에 따라 라이브 이면의 시간을 줄이는 것이 경쟁력을 유지하고 뛰어난 시청 경험을 제공하기 위한 중요한 요구 사항으로 부각되고 있습니다.
지연 시간 단축은 Edgecast의 초점 영역으로, 현재 Edgio입니다. 이러한 노력에는 각 처리 단계 및 라이브 스트림 전송과 관련된 기타 요인에 대한 점진적인 개선을 연구하고 구현하는 작업이 포함됩니다. 이 게시물에서는 지연 시간 감소의 한 가지 특정 측면인 컨텐츠 딜리버리 네트워크가 점차 인기를 끌고 있는 낮은 지연 시간 전략으로 인해 증가하는 요청 볼륨을 처리하는 방식, 즉 세그먼트 크기를 줄이는 방식에 대해 살펴봅니다.
라이브 이면의 시간을 줄이기 위해 스트리밍 서비스 제공업체들은 더 짧은 HLS 또는 DASH 세그먼트 기간을 수용하기 시작했습니다. 이로 인해 지연 시간이 크게 줄어들 수 있지만 추가 오버헤드 및 재버퍼링 위험 증가와 같은 단점이 있습니다. 이러한 장단점이 가치가 있는지 여부는 전적으로 다른 QoE 고려 사항과 비교하여 지연 시간에 대한 우선 순위에 따라 달라집니다. 위에서 언급한 바와 같이, 일부 상황들에서는 낮은 지연이 최우선 순위인 반면, 다른 상황들에서는, 현재의 지연 레벨들이 개인화된 광고, 4K 프로그래밍을 전달하거나, 라이브 콘텐츠를 편집하기 위해 허용될 수 있다.
지연 시간에서 세그먼트 크기의 역할
스트리밍 비디오 업계는 스트리밍을 여러 개별 비디오 세그먼트 또는 청크로 분할하는 ABR(Adaptive Bitrate) 기술을 오랫동안 사용해 왔습니다. 각 세그먼트는 동일한 지속 시간 또는 크기를 갖지만 다른 비디오 품질 수준 또는 비트 전송률로 인코딩되므로 스트림은 새로운 세그먼트가 요청될 때 시청자의 가용 대역폭에 맞게 조정됩니다. 두 가지 주요 ABR 프로토콜인 Apple의 HLS 및 MPEG-DASH는 세그먼트 크기 조정을 위한 컨트롤을 제공합니다.
세그먼트 크기는 플레이어가 라이브 스트림을 재생하기 전에 미리 설정된 수의 세그먼트를 다운로드해야 하기 때문에 지연 시간에 중요한 역할을 합니다. 이렇게 하면 클라이언트 비디오 플레이어가 네트워크에 정체가 있을 때 리버퍼링 없이 부드럽게 비디오를 재생할 수 있도록 충분한 비디오를 버퍼링할 수 있습니다. 그러나 이것은 또한 처음부터 라이브 뒤에 스트림을 넣어. 일반적으로 iOS 장치와 웹 브라우저에 내장된 비디오 플레이어는 재생을 시작하기 전에 세 개의 비디오 세그먼트를 버퍼링합니다. 세그먼트의 길이가 4초이고 플레이어가 3개의 세그먼트를 버퍼링해야 재생을 시작할 수 있는 경우, 클라이언트는 이미 라이브보다 12초 늦은 상태입니다. DASH 프로토콜은 매니페스트 파일이 버퍼링해야 하는 파일의 양을 지정할 수 있도록 하여 어느 정도 유연성을 제공합니다. 그러나 많은 DASH 플레이어와 장치는 아직 이 기능을 구현하지 않았습니다.
라이브 지연 시간 단축
3개의 세그먼트를 버퍼링하는 것이 사실상 표준이므로 라이브 지연 시간을 줄이는 가장 일반적인 방법은 각 세그먼트의 크기나 기간을 줄이는 것입니다. 아래 예에서는 세그먼트 크기를 4초에서 2초로 줄이면 라이브 지연 시간이 6초로 줄어듭니다. 이는 4초 세그먼트의 절반입니다.
세그먼트가 작을수록 재버퍼가 발생할 수 있음
더 작은 세그먼트 크기를 사용할 경우 버퍼 없는 라이브 비디오 스트리밍 경험을 제공하려면 비디오 워크플로우가 더 반응해야 합니다. 이는 다음 두 가지 요인에 기인합니다.
첫째, 세그먼트 크기를 줄임으로써 고정 된 세그먼트 수를 저장하는 플레이어는 이제 비디오를 덜 저장하게됩니다. 또한 세그먼트 크기가 짧을수록 더 많은 파일이 생성되므로 비디오 워크플로우와 콘텐츠 전송 네트워크는 주어진 스트림 시간 동안 플레이어로부터 2배나 많은 파일 요청을 처리하고 전송해야 합니다. 네트워크 정체 시 플레이어에서 버퍼링되는 비디오가 적기 때문에 정체 현상으로 인해 리버퍼링이 발생할 가능성이 높습니다. 플레이어는 이제 더 작은 정체 이벤트에서도 정체에 더 민감합니다.
둘째, 최근 기술 기사인 라이브 스트리밍을 위한 CDN 최적화에서 설명했듯이 라이브 스포츠에서는 인기 있는 이벤트가 시작되거나 마지막 경기가 끝날 때 시청자가 급증하는 것이 일반적입니다. 파일 요청 수가 증가함에 따라 CDN은 동일한 시간 내에 더 많은 파일 요청을 수용해야 합니다. 이 작업은 Adaptive Bitrate 매개 변수에 의해 지정된 다양한 장치 유형 및 연결 속도에 의해 복합됩니다.
파일 볼륨 증가를 나타내기 위해 그림 2는 서로 다른 길이 세그먼트로 전달되는 16초 길이의 비디오 세그먼트를 보여줍니다. 4초 세그먼트의 경우 16초 세그먼트를 전송하는 데 4개의 파일만 필요합니다. 그러나 2초 세그먼트로 이동하면 8개의 개별 파일이 필요하며, 이는 CDN을 통해 처리해야 하는 파일의 두 배입니다.
핫 파일링을 통한 세그먼트 납품 성능 개선
우리는 많은 라이브 시청자가 동시에 스트림에 참여하는 소위 “플래시 크라우드” 현상을 해결하기 위해 핫 파일링(Hot Filing)이라는 기능을 만들었습니다. 이 기능은 인기있는 세그먼트 또는 “핫 파일”을 POP(Point of Presence) 내의 추가 서버로 신속하게 복제하여 수요가 급격히 증가함에 따라 시청자에게 빠르게 전달할 수 있도록 하는 기능입니다.
핫 파일링은 로드를 여러 서버에 분산시켜 파일 요청이 갑자기 급증할 때 서버 하나에 압도되는 것을 방지합니다. 서비스 거부 공격과 마찬가지로 서버가 오버로드되면 서버가 파일 요청에 응답하는 속도가 느려져 클라이언트 플레이어에서 리버퍼링이 발생할 수 있습니다. 핫 파일을 신속하게 식별하고 복제함으로써 단일 서버에 과부하가 발생할 위험이 훨씬 낮습니다. 이제 지연 시간을 추가하지 않고도 갑작스러운 수요 변화를 충족할 수 있습니다.
그림 3은 핫 파일링(그림 3.b)이 서버 과부하를 방지하여 성능을 향상시키는 방법을 보여줍니다. 핫 파일링(그림 3.a)을 사용하지 않으면 세그먼트의 모든 트래픽이 서버 1(S1)로 이동합니다. 사용자의 수요가 급증하면 추가 트래픽이 S1로 흘러 100명의 사용자 용량을 초과하게 됩니다. S1이 최대 200명의 시청자에게 서비스를 제공함에 따라 상황은 계속 악화되고 있습니다. 반면 핫 파일링(그림 3.b)은 파일을 두 서버(S1 + S2)로 복제하고 파일 요청을 새로 사용 가능한 서버로 다시 라우팅하여 이러한 추가 로드를 처리합니다.
빠른 핫 파일 식별
최근 핫 파일을 여러 서버로 이동하는 시간을 1초 단축하여 핫 파일링을 개선했습니다. POP 내에서 핫 파일을 식별하는 방법을 변경하여 반응 시간을 개선했습니다. 중앙 프로세스를 사용하여 분석을 위해 파일 요청과 바이트 수를 집계합니다. 이전에는 각 서버의 웹 서버 프로세스에서 데이터를 가져왔습니다. 이 방법은 잘 작동했지만 느린 웹 서버로 인해 핫 파일 데이터의 집계가 느려질 수 있다는 사실을 발견했습니다. 이 문제를 해결하기 위해 서버는 이제 요청과 바이트 수를 매초마다 디스크에 기록합니다. 결과적으로 중앙 프로세스가 데이터를 가져올 때 데이터가 이미 솔리드 스테이트 디스크에 기록되기 때문에 웹 서버 프로세스를 기다릴 필요가 없습니다. 이 변경만으로도 대부분의 라이브 이벤트에 대한 로드를 수용하기에 충분합니다.
라이브 이벤트에 대한 빠른 대응 시간의 중요성은 그림 3.c에 나와 있습니다. 이 그림은 추가 리소스를 모집하기 위해 핫 파일링 프로세스가 어떻게 작동하는지에 대한 통찰력을 제공합니다. 그림 3.c에 표시된 예에서 S1 서버가 100명의 사용자 용량을 초과하면 용량에 도달하면 파일이 S2로 빠르게 이동합니다. 따라서 시스템은 200명의 사용자 모두를 신속하고 효율적으로 수용할 수 있으며 사용 가능한 서버의 전체 용량을 사용할 수 있습니다.
여러 포트의 핫 파일링
프로 축구 플레이 오프 게임 또는 주요 국제 축구 경기 등 매우 인기있는 이벤트의 경우 트래픽이 급증하고 급증하는 것은 매우 중요 할 수 있습니다. 이 요구 수준을 충족하려면 파일 세그먼트의 복제 방식을 변경하여 서버 용량을 늘려야 합니다. 이전에는 콘텐츠 전송 네트워크가 서버당 하나의 포트로 세그먼트를 복제하는 것으로 제한되었습니다. 하지만 이제는 각 서버의 여러 포트에 파일을 복제할 수 있습니다. 따라서 각 서버의 처리량이 크게 증가하여 각 POP가 더 많은 요청을 처리할 수 있으므로 이전보다 훨씬 큰 라이브 이벤트를 처리할 수 있습니다.
이 시스템에서 로드 밸런싱은 CARP(Cache Array Routing Protocol) 해싱에 의해 처리됩니다. 일반 컨텐츠의 경우 여러 서버에서 파일을 복제하는 접근 방식이 있으며, 각 서버에서 단일 포트를 선택하기 위해 CARP 해싱을 사용합니다. 이렇게 하면 중복 요청이 오리진 서버로 전송되지 않도록 하고 프로세스 간 통신을 제한할 수 있습니다.
파일이 충분히 뜨거워지면 CARP는 더 많은 요청을 지원하기 위해 서버당 여러 포트를 선택하기 시작합니다. 이 방법은 핫 파일은 서버에서 제공하는 고유 파일의 일부이므로 유용합니다. 열리는 포트 수는 핫 파일에 대한 요구에 따라 달라집니다. 이 접근 방식은 서버당 제공되는 데이터 볼륨과 이러한 요청을 처리하는 데 사용할 수 있는 CPU 전력을 증가시킵니다.
결론
스트리밍 서비스 제공업체가 비디오 세그먼트의 크기를 줄여 지연 시간을 줄임에 따라 Edgio의 Platform Hot Filing 기능은 콘텐츠 전송 네트워크가 비디오 파일에 대한 증가하는 요청을 관리할 수 있도록 지원하며, 특히 인기 있는 스포츠 이벤트의 시청자 수가 증가함에 따라 더욱 그렇습니다.
