라이브 비디오 서비스 구축을 위한 노하우 - 1회

처음으로 공개 블로그인 Popit에 글을 올려봅니다. 단어나 표현이 조금 부족하더라도 너그러운 마음으로 읽어 주세요. 감사합니다.

초고속 인터넷망의 지속적인 확산과 모바일 환경이 빠른 속도로 진화를 거듭해왔지만,  고해상도 디지털 비디오를 인터넷으로 전송하는 작업은 항상 품질에 대한 확신을 할 수 없는 어려운 일이다. 최근 VoD(Video-on-Demand) 사업의 경쟁이 치열해지다보니 라이브 비디오 스트리밍 서비스를 이용한 새로운 사업들이 디지털 비디오 시장의 새로운 성장 동력이 되어 많은 회사들이 시장에 진입하고 있는 상황이다.

라이브 비디오 스트리밍 서비스는 전송 비용 부담으로 수익성 있는 사업을 만들기도 어렵지만, 여전히 기술적으로 품질을 보장할 수 있는 시스템을 구축하는 것은 여전히 큰 난제이다.  비디오는 대역폭이 넓다고 해서 서비스의 품질이 절대 보장되지 않는다. 웹페이지나 사진과 달리 비디오는 재생할 시점에 재생될 데이터가 반드시 있어야 하는 실시간 처리가 필요한 미디어라는 특성때문에 기술적인 어려움이 다른 미디어에 비해서 매우 높다. 특히 라이브 방송을 비디오 스트리밍을 할 경우에 그 어려움은 더욱 가중된다.

고품질의 라이브 스트리밍 서비스를 구축하고자 하는 많은 분들을 위하여 지금까지 경험과 노하우를 2회에 걸쳐 조금 풀어볼까 합니다.

Bandwidth(대역폭), Throughput(처리량), Latency(지연시간)

비디오나 오디오를 인터넷으로 스트리밍 서비스하는데 있어서 대부분의 사람들이 네트워크 속도가 빠르면 고품질 서비스가 보장될 것이라고 잘못 알고 있다. 이러한 잘못된 생각에서 벗어나기 위해서는 우선 이 세가지 개념에 대한 정확한 이해가 필요하다. 한국의 초고속 인터넷 환경인 탓인지 유능하다는 많은 엔지니어들도 항상 혼동을 하는 개념이다. 이 세 개념을 물이 흐르는 파이프의 예를 들어 쉽게 정의 해보자.

pvc-pipe-1840447

  • Latency - 파이프로 물이 통과하는데 걸리는 총 시간
  • Bandwidth - 파이프의 폭
  • Throughput - 파이프를 통해 흐른 물의 총량

즉, 파이프의 폭이 넓다고 해서 흐르는 물의 양이 많아질 수는 있으나 물이 빠르게 흐르지는 않는다. 과거에는 전송될 비디오 데이터 크기에 비해 파이프의 폭이 문제의 주된 원인이었으나 , 최근 Adaptive streaming기술등의 발전으로 네트워크 대역폭(Bandwidth)보다는 각 비디오 패킷이 전송될때 latency 문제가 가장 심각하게 대두되고 있다.

라이브 스트리밍 서비스에서 실시간으로 동영상이 끊어지지 않고 재생되기 위해서는 대역폭을 늘리는 것보다  Latency를 낮추는 것이 기술의 핵심이라고 할 수 있다.. Latency가 높을 경우 발생하는 일들에 대한 예를 들어보자, 아파트에서 한일전 축구 경기를 라이브 스트리밍 서비스를 통해 모바일 폰으로 본다고 상상해보자. 내 모바일폰에서는 지금 막 골문 앞으로 한국의 공격수가 일본의 골대를 향해 돌진하고 있다. 그런데 옆집에서는 환호성이 터지면서 벌써 골이 들어가 버렸다. 헉~ 얼마나 김빠지는 경기가 될까?

999AB2355B89E62A17

예를 한가지 더 들어보자. 스푼라디오나 아프리카TV는 한국의 대표적인 개인 방송 서비스이다. 시청자가 채팅방에 진입할때 BJ가 환영 인사를 하며 들어오는 시청자를 한명씩 반겨 준다. 이때 Latency가 높은 경우 내가 진입한 후 2분이 지나서야 환영인사가 들려온다. 헉~~. BJ와 어떻게 대화를 나눌 수 있을까?

392x696bb

Latency(지연시간)이 높아지는 이유들

라이브 비디오 스트링밍 서비스는 방송 송출에서부터 사용자의 모바일 디바이스에 도달할 때까지 복잡한 파이프 라인을 거쳐 간다.  특정 한가지 이유로 Latency가 높아지는 것이 아니라 여러가지 이유가 복합적으로 섞이면서 더욱 원인을 찾기가 어렵다. 또한, 각 단계별로 어떻게 설정하느냐에 따라 Latency에 많은 영향을 준다. 아래 그림은 대규모 라이브 스트리밍 서비스를 위한 시스템 구조이다. 전체 시스템에서 각 파이프 라인의 단계별로 지연시간의 원인이 될 수 있는 요소들을 살펴보자.

live-streaming-architecture

  • Encoding & packaging - 해상도, 전송 비트레이트, 압축 표준 선택이 중요하고, 전송 프로토콜에 따라 패키징하는 시간과 주기등을 결정해야 한다.
  • Uploading (First mile upload) - 녹화 후 인코딩된 패킷을 Ingestion단으로 전송을 해야 한다. 이 부분이 불안정할 경우 방송 중단 및 방송사고로 이어질 수 있는 중요한 부분이다. 현재 산업계에서 많이 사용하는 프로토콜은 RTMP, RTSP, RTP, SRT등을 사용한다. 최근에는 이 단계의 낮은 latency 및 안정적인 연결을 위한 UDP기반의 프로토콜들에 많은 관심이 쏠리고 있다.
  • Ingestion server - 통상 산업계에서 CDN에서 직접 접속하기전에 Wowza, Red5 pro같은 스트리밍서버를 중간 설치하여 녹화, 알람, 불법 콘텐츠 모니터링등에 이용한다. 이 단계에서 캐쉬를 너무 크게 잡거나  latency 조정을 잘못할 경우 지연시간이 길어 질 수 밖에 없다.
  • Cache (or CDN) - 최근에는 치열한 CDN가격으로 고맙게도 CDN 비용이 많이 낮아졌다. 그러나, 각 CDN업체들도 실시간 비디오 스트리밍에 난제라 latency를 줄이기 위하여 많은 노력을 하고 있다. 특히 CDN은 캐쉬(Cache)기능을 하다 보니 latency에 가장 민감할 수 밖에 없고, 서비스가 대규모가 될 경우 캐쉬의 효율적인 운영을 위하여 쉐도우(shadow)라는 2중 캐쉬를 사용한다. 이경우 latency는 더 길어질 수 밖에 없다. CDN 사업자를 선정할 때는 서비스 지역과 가격 및 안정성을 고려하여 선정하는 것이 좋다. CDN사업자를 잘못 선정하여 큰 라이브 이벤트를 망치는 경우도 종종 목격했다.
  • Last mile delivery - 인터넷으로 전송하는 단계이며 공공망이라 통제 가능한 부분이 사실상 없다. 하지만 실시간 Adaptive Streaming, 적절한 프로토콜 선정(HLS, RTMP, MPEG-DASH, SDP 등)을 적극 고려하는 것이 좋다. 특히 스트림라이저를 통하여 항상 전송이 잘되고 있는지 확인 하면 더욱 좋습니다. (잠깐 저희 광고~)
  • Media player buffer - 미디어 플레이어의 버퍼링을 얼마큼 해야하는지는 결정은 항상 엔지니어들의 머리를 가장 아프게 하는 난제 중 난제이다. 많은 회사들이 직관적으로 최대한 짧게 잡으려고 한다.  최대한 짧게 잡게 되면 그 만큼 재생 중간에 버퍼링이 발생할 확률이 높아진다. 특히, 라디오 방송이나 음악 방송 같은 경우 중간에 버퍼링이 발생하면 치명적이다.  버퍼링에 대한 절대적이고 완벽한 답은 없기 때문에 서비스의 특성, 콘텐츠의 특성, 사용자들의 성향에 따라 정량화된 데이터를 기반으로 튜닝작업이 많이 필요하다. (한번 더 광고..죄송~. 스트림라이저를 사용하여 튜닝 작업을 할 수 있죠~)

Latency vs Scalability vs Video Quality

실시간 라이브 스트리밍 서비스를 구축하는데 있어서 Latency, Scalability, Quality는 Trade-off관계에 있다. 적절한 선택을 해야 하는데 이는 사업적인 결정에 따라 세가지를 현명하게 조정하는 것이 중요하다. 1~2분정도의 지연시간은 업계에서 매우 평균적인 지연 시간이다. 최근에 Low latency 솔루션들이 나오면서 8~10초까지 지연시간이 짧게 할 수 있게되었다.  그러나, Latency는 확장성과 화질등을 고려하여 적정하게 조정해야 한다.

확장성(Scalability)

현장에서 서비스를 처음 구축하시는 분들은 항상 확장성에 대한 걱정과 고민을 매우 깊게 한다. 시스템을 구축하는데 있어서 가장 불확실성이 높고, 잘못된 기술적인 결정을 할 경우 사업 성장에 큰 영향을 미치게 된다.

한 예를 들어보면, RTMP 프로토콜을 사용할 경우 Latency가 다른 프로토콜에 비해 낮은 편이고 적은 규모에서는 상당히 성능 좋은 프로토콜이다. 그러나, 서버에서 초기 셋업하는데 동작이 매우 복잡하여 대규모 서비스로 갔을데 서버의 부담이 늘어나서 라이브 이벤트시 시청자가 동시에 접속할 경우 서버 다운이 될 가능성이 다른 프로토콜에 비해 높은 편이다. 그래서 최근에 HTTP기반의 애플의 HLS, 마이크로 소프트의 Smooth streaming, Adobe의 HDS(HTTP Dynamic Streaming), MPEG-DASH등을 많이 사용한다. HTTP 프로토콜 기반으로 하다 보니 CDN업체들도 확장성에 대하여 조금 더 쉬운 대응이 가능해졌다.

화질(Video Quality)

최근에 사용자들은 더 좋은 품질의 비디오를 찾는 성향이 강하다. 사업자 입장에서는 해상도(resolution)을 올리거나 초당 프레임수(Frame rate)을 올리고 있다. 이 경우 패킷량이 크게 늘어나 전송에 필요한 시간, 트랜스코딩/인코딩 시간, 버퍼링 시간의 증가가 불가피하다.  이를 개선하기 위하여 HEVC, AV1, VP9등 새로운 코덱들이 산업계에 소개되고 있으나, 사업의 방향과 수익성을 고려하여 선택하는 것이 좋다.

일반적으로 생방송,  화상회의, 보안 감시 시스템 같은 경우 화질을 약간 희생하더라도 Latency를 낮추는 방향으로 시스템을 조정하고, 고화질 프레미엄 서비스, 고품질 VOD서비스 같은 경우 Latency를 약간 올리고 화질을 높이는 선택을 한다. 결론적으로 얘기를 하자면 화질은 사업적인 판단에 따라 조정을 하는 것이 중요하다.

1회에는 기초 지식과 현장에서 접하는 문제들을 정리해보았다. 2회에는 Latency에 대한 이해와 산업계의 대응, 현재 산업계에서 논의되고 있는 미래 방향에 대하여 얘기해보겠습니다~~. 그럼 다음 회를 기대해주세요~.

Popit은 페이스북 댓글만 사용하고 있습니다. 페이스북 로그인 후 글을 보시면 댓글이 나타납니다.