Live Video Service 구축 내용 정리
💡 비디오나 오디오를 인터넷으로 스트리밍 서비스하는데 있어서 대부분의 사람들이 네트워크 속도가 빠르면 고품질 서비스가 보장될 것이라고 잘못 알고 있습니다.
⇒ 이러한 잘못된 생각에서 벗어나기 위해서는 아래 세 가지 가념에 대해 정확한 이해가 필요합니다.
- 물이 흐르는 파이프의 예를 들어 설명해보겠습니다.
- Bandwidth(대역폭) : 파이프의 폭
- Throughput(처리량) : 파이프를 통해 흐른 물의 총량
- Latency(지연시간) : 파이프로 물이 통과하는데 걸리는 총 시간
⇒ 즉, 파이프의 폭이 넓다고 해서 흐르는 물의 양이 많아질 수 있으나 물이 빠르게 흐르지는 않습니다.
과거에는 전송될 비디오 데이터 크기에 비해 좁은 파이프의 폭이 주된 원인이었지만, 최근 Adaptive Streaming 기술 등의 발전으로 네트워크 대역폭보다는 각 비디오 패킷이 전송될 때 Latency 문제가 가장 심각하게 대두되고 있다고 합니다.
라이브 스트리밍 서비스에서 실시간으로 동영상이 끊어지지 않고 재생되기 위해서는 대역폭을 늘리는 것보다 Latency를 낮추는 것이 기술의 핵심이라고 합니다.
Latency가 높아지는 이유
- 실시간 비디오 스트리밍 서비스는 송출에서부터 사용자의 디바이스에 도달할 때까지 복잡한 파이프 라인을 거쳐갑니다.
- 특정 한 가지 이유로 Latency가 높아지는 것이 아니라 여러가지 이유가 복합적으로 섞이면서 더욱 원인을 찾기 어렵습니다.
- 또한, 각 단계 별로 어떻게 설정하느냐에 따라 Latency에 많은 영향을 줍니다.
- 아래 사진은 대규모 라이브 스트리밍 서비스를 위한 시스템 구조이다.(참고만 하면 될 것 같습니다.)
- Encoding & Packaging : 해상도, 전송 비트레이트, 압축 표준 선택이 중요하고, 전송 프로토콜에 따라 패키징하는 시간과 주기 등을 결정해야 합니다.
- Uploading : 녹화 후 인코딩된 패킷을 Ingestion단으로 전송을 해야 합니다. 이 부분이 불안정할 경우 방송 중단 및 사고로 이어질 수 있는 중요한 부분입니다. 산업계에서 많이 사용하는 프로토콜은 RTMP & HLS, RTSP, RTP, SRT등을 사용한다고 합니다. 최근에는 이 단계의 낮은 Latency 및 UDP 기반의 프로토콜들에 많은 관심이 있습니다.(WebRTC)
- Ingestion Server : 통상 산업계에서 CDN에서 직접 접속하기 전에 Wowza와 같은 스트리밍 서버를 중간 설치하여 녹화, 알람 등에 이용합니다. 이 단계에서 캐시를 너무 크게 잡거나 Latency 조정을 잘못할 경우 지연시간이 길어질 수 밖에 없습니다.
- Cache( or CDN[Cloud Delivery Network]) : CDN이란 지리적 제약 없이 전세계 사용자에게 빠르고 안전하게 컨텐츠를 전송할 수 있는 컨텐츠 전송 기술을 의미합니다. CDN은 서버와 사용자 사이의 물리적인 거리를 줄여 컨텐츠 로딩에 소요되는 시간을 최소화합니다. CDN은 각 지역에 캐시서버(PoP[Points of presence])를 분산 배치해, 근접한 사용자의 요청에 원본서버가 아닌 캐시서버에서 웹사이트 컨텐츠를 사용자에게 전송하는 방식입니다.
[하지만 특정 국가나 지역만을 타겟으로 하는 웹서비스를 운영한다면 CDN 서비스를 활용할 필요가 없다.] - Last mile delivery : 인터넷으로 전송하는 단계이며 공공망이라 통제 가능한 부분이 사실상 없습니다. 하지만 실시간 Adaptive Streaming, 적절한 프로토콜 선정(HLS,RTMP,SDP…)을 적극 고려하는 것이 좋습니다.
- Media player buffer : 미디어 플레이어의 버퍼링을 얼만큼 해야하는지에 대한 결정은 항상 엔지니어들이 많은 고민을 하게 만드는 난제입니다. 많은 기업들이 직관적으로 최대한 짧게 잡으려고 하지만 그 만큼 재생 중간에 버퍼링이 발생할 확률이 높아집니다. 버퍼링에 대한 절대적이고 완벽한 답은 없기 때문에 서비스의 특성, 컨텐츠의 특성, 사용자들의 성향에 따라 정량화된 데이터를 기반으로 튜닝작업이 많이 필요합니다.
RTMP와 WebRTC 간단 비교
