라이브 비디오 서비스 구축을 위한 노하우 - 2편
1편에 이어 2편을 올려봅니다.
Latency에 대한 이해
1편에서 언급하였듯이 Latency가 높아지는 (길어지는) 이유는 전송단의 각 파이프 라인 단계별 변수들이 복합적으로 작용하기 때문에 실무에서는 정확한 원인과 해결책을 찾기는 매우 어렵다. 또한, 종단간 (End-to-End) latency를 기술적으로 측정하는 정량화된 방법도 아직은 없는 상태이다. 어떤 분들은 카메라 앞에서 손을 흔들고 시간을 측정하시는 분들도 있고, 어떤 분들은 "아" 소리를 내고 들릴때까지 측정하는 사람도 있다. 저도 매우 원시적인 방법을 사용하고 있다. Millisecond로 표시되는 디지털 시계를 카메라로 계속 생중계하면서 단말기에서 보이는 화면과 실제 시간을 비교하는 방법을 사용하고 있다. 즉, 정량화된 방법은 부재인 상태이지만 기본적으로 가장 이상적인 환경에서 구축한 서비스의 Latency를 측정할 필요는 있다.
이러한 정량적인 방법의 부재로 현실적인 다른 관점에서측정방법을 하나 소개하고자 한다. 지금까지의 경험으로 비추어 보아 Latency의 최종 결과물인 시청자들의 시청경험(QoE: Quality-Of-Experience)라는 관점에서 Latency에 대한 설명을 해보자.
아래 그림은 한개의 동영상을 보는 생애주기(life-cycle)를 표시해 보았다. 즉, 동영상이 있는 웹사이트 페이지나 모바일 앱의 페이지 방문을 시작으로 동영상을 끝까지 볼때까지 생애 주기이다.
1. Join latency (Start buffering)
이 부분은 동영상의 재생(play) 버튼을 누른 후 혹은 자동재생이 시작된 후 첫번채 영상이 화면에 표시될 때까지 시간이다. 재생 버튼을 누르는 순간부터 비디오 데이터의 전송이 시작된다. 이 시간이 너무 길어지면 시청자 이탈이 발생한다. 약 10초일때 약 50% 시청자들이 이탈되는 것으로 알려져 있다. 이 시간을 짧게 하는 것은 사업적으로 매우 중요하지만, 그렇다고 너무 짧게 줄이면 버퍼에 충분한 비디오 데이터가 저장되어 있지 않아 재생 중간에 버퍼링 발생 확률이 높아진다. 그러므로 시청자 이탈을 최소화 하면서 중간에 버퍼링 확률을 최소화하도록 조정하는 일이 매우 중요하다.
물론 동영상이 있는 페이지 방문시 미리 데이터를 다운을 받아 재생하는 방법도 있으나, 시청자들이 동영상을 시청하지 않고 다른 페이지로 넘어갈 경우 사용하지 않는 비디오 데이터로 추가 CDN비용이 발생한다.
참고로, 많은 한국 회사들이 초고속 인테넷이라는 환경 탓인지 정량적인 측정을 하지 않고 비트레이트를 일단 낮추고 약 2초 정도로 조정을 하거나 상사의 지시로 무조건 짧게 만드는 경우도 너무 많이 보았다. 최고 스트리밍 회사인 N사 같은 경우 플레이 버튼을 누른 후 8초내에 재생 가능한 CDN와 비트레이트(Bitrate)를 선택하도록 미디어 플레이어를 똑똑하게 만들어 놓았다. 8초라는 숫자는 여러가지 빅데이터 분석을 통해 얻은 결과이다.
2. End-to-end latency (Buffering)
latency의 영향으로 발생하는 또 하나의 좋지 않은 사용자 경험은 버퍼링이라고 할 수 있다. 버퍼링 또한 시청자 이탈율을 높이며 전체 시청시간 감소를 유발한다. 이를 측정하는 기준이 여러가지가 있는데 그 중 하나가 버퍼링율로 다음과 같이 정의 한다.
버퍼링율 (%) = 버퍼링시간 / (시청시간 + 버퍼링시간) * 100
1% 증가할 때 마다 시청자당 시청시간이 월 평균 약 14분 정도 낮은것으로 알려져 있다. 즉 광고 매출을 사업 모댈로하는 회사는 광고 매출이 낮아지는 것을 의미한다. 업계에서 평균적으로 1% 이상되는 경우 저품질 서비스로 판단하고 0.4% ~ 0.1%가 좋은 서비스로 평가되고 있다.
버퍼링시간을 "0"로 만드는 것은 현실적으로 불가능하다. 이 시간을 줄이기 위한 과도한 투자도 ROI를 계산하여 판단하여야 한다.
Latency에 따른 접근법
라이브 온라인 비디오 서비스를 구축하시는 분들을 만날때 "Latency가 어느 정도로 조정해야 되죠?"라는 질문을 자주 받는다. 이 질문에 대하여 쉽게 답하기는 힘들다. 서비스의 종류와 사업의 특성에 따라서 선택을 해야한다.
단방향 라이브인 경우 1~2분정도를 추천하고, 양방향일 경우도 20~ 30초, 고화질 VoD인경우는 Adaptive Streaming을 사용하고 Start buffering 시간을 약 8초에 맞추라고 권고를 드리고 있다. 또한, Ultra-low latency가 필요한 경우 확장하는데 비용이 많이 들더라도 RTMP, WebRTC를 권하는 경우도 종종 있다. 이 질문과 요구 사항에 따른 접근법을 정리해보았다.
- Common Latency - 일반적인 대규모 시청자들가 있는 단방향 비디오 서비스
- Reduced Latency - 라이브 뉴스 중계, 스포츠
- Low latency - 게임중계(e-sports), 비디오 감시, 온라인 경매, 카지노, 스포츠 도박, 스포츠 생중계
- Realtime - 화상회의, 비디오 스트리밍게임, 음성 통화
최근 산업계의 동향
- RTMP로의 회귀 - 아직까지도 많은 CDN회사들이 RTMP를 지원하고 있다. 그러나, 차츰 CDN회사들도 지원을 줄여가고, 많은 웹브라우저들도 지원하지 않는 방향으로 움직이고 있다. 향후 확장성을 고려하여 추천하고 싶지는 않다.
- WebRTC - UDP기반으로 low latency라는 강력한 장점이 있지만, 지원하는 CDN회사가 거의 없다고 볼수 있다. 특히, WebRTC를 선정할때에는 서비스의 성격에 맞추어 선정하는 것이 좋다. 특히 대규모 Broadcasting이나 VoD를 할 경우에는 절대 추천하지 않는다. 왜냐하면 1:1서비스를 위해 개발된 프로토콜이라 대규모로 시청자들이 동시에 접속하는 서비스에 적용하여 안정적으로 운영되는 시스템을 아직 보지 못했다. 상당한 튜닝작업 후에 라이브에는 효과적으로 적용되는 솔루션은 간혹 보았으나 VoD일 경우에는 대규모의 캐쉬가 되지 않은 한 장점이 없는 것으로 판단된다.
- MPEG-DASH/HLS based - 아직 시장에 현존하는 가장 안정적이고 좋은 선택으로 볼 수 있다. HTTP 기반이라는 약점이 있지만 세그멘트 크기를 줄이는 등 기존에 있는 선택사항을 최적화하여 라이브에서 안정적으로 운영되고 있다.
- SRT(Secure Reliable Transport) - 올해 alliance가 만들어지면서 주목을 받고 있는 프로토콜이다. 역시 UDP기반으로 Low latency를 추구하고 있다. 아직은 상용화하기에는 초기 단계이나 업계를 주도하고 있는 회사들이 많이 참여하면서 더욱 활성화 될 것으로 예상된다.계속 주목을 할 필요가 있다.
결론
고화질의 라이브 방송을 만드는 일은 지속적인 인력, 기술 투자가 필요한 부분이다. 규모가 작은 사업은 기존 솔루션을 최대한 활용하는 것이 좋고, 대규모 사업을 할 경우 빅데이터 분석을 비롯하여 서비스와 사업 규모에 맞게 적절한 투자와 기술 개발을 하도록 조언을 드리고 있다. 앞으로 라이브는 개인방송, e-sports를 비롯하여 무궁 무진한 사업 영역이 기다리고 있다. 이 글을 기초로 라이브 서비스와 사업을 만드는데 조금이나마 도움이 되었으면 합니다.
긴 글을 끝까지 봐주셔서 감사합니다.
참고자료
[1] http://www.zender.tv/news/2018/3/23/ultra-low-latency-streaming-the-current-stat
[3] https://www.wowza.com/products/capabilities/low-latency
[4] https://www.linkedin.com/pulse/importance-low-latency-video-streaming-steven-tielemans