Baelog 🏝️
[Networks] 대규모 비디오 스트리밍 프로토콜 (Netflix, YouTube, ...)

[Networks] 대규모 비디오 스트리밍 프로토콜 (Netflix, YouTube, ...)


Networks Protocol

tl;dr

  • 현재 대부분의 대규모 비디오 스트리밍 서비스들은 UDP가 아닌 HTTP/TCP 기반 프로토콜을 선호
  • 안정성, 호환성, 방화벽 친화적인 특성
  • 또한 HTTP를 사용하면 기존 CDN 인프라를 효과적으로 사용할 수 있음

DASH (Dynamic Adaptive Streaming over HTTP)

  • 비디오를 작은 Chunk로 나누고 각 청크를 HTTP Req/Resp을 통해 전달하는 방식
  • 동작 방식
    1. 비디오를 청크로 나눔
    2. 비디오 구성 정보가 포함된 매니페스트 파일 다운로드
    3. 클라이언트가 각 청크 당 HTTP GET 요청
    4. 서버에서 청크 응답
    5. DASH가 실시간으로 네트워크 상태를 모니터링해 네트워크 상황이 변할 때마다 비트레이트 조정

왜 UDP가 아닌 TCP(HTTP)를 쓰나?

1. 신뢰성

  • TCP는 데이터 전송 중 패킷 손실 발생 시 재전송
  • 모든 데이터가 정확히 수신되는 것이 보장됨
  • 반면 UDP는 패킷 손실 시 재전송이 없기 때문에 비디오의 품질 저하에 큰 영향을 끼칠 수 있음

2. HTTP 인프라

  • DASH는 HTTP를 기반으로 하기 때문에 모든 HTTP 인프라(CDN, 캐싱 서버, 방화벽, 프록시 등)와 원활히 작동
  • 대부분의 인터넷 인프라가 HTTP 트래픽을 최적화하도록 설계되어 있으므로 새로운 프로토콜을 도입할 필요 없이 스트리밍 성능 극대화 가능

3. 네트워크 호환성

  • HTTP/TCP는 대부분의 네트워크 환경에서 잘 작동하며 방화벽이나 프록시 등에서 차단되지 않는 경우가 많음
  • 반면 UDP는 종종 방화벽에서 잘 차단되는 편
  • TCP는 혼잡 제어를 자동으로 처리하지만, UDP는 이런 기능이 없어서 트래픽 제어를 좀 신중히 해야함

4. 적응형 스트리밍

  • DASH의 핵심은 적응형 스트리밍
    • 네트워크 상황에 맞춰 클라이언트가 다양한 비트레이트와 해상도 중에서 선택하는 방식
  • TCP의 안정적인 연결을 기반으로 하는 HTTP의 요청/응답 모델이 이 방식과 핏함

UDP는 Live streaming에 더 적합

  • 라이브 스트리밍은 더 낮은 지연 시간을 제공하기 위해 UDP를 많이 활용하고 있음 (e.g., Twitch, …)
  • 그러나 데이터 신뢰성을 위해 TCP 또한 병행해서 활용 중 (e.g., VOD 재생 등)

Netflix 사례

AWS Infrastructure

  • 콘텐츠 수집
    • 영화를 수집하고 처리
    • 영화의 마스터 버전을 받아 AWS 상의 호스트에 업로드
  • 콘텐츠 처리
    • 인스턴스에서 데스크탑, 스마트폰, TV 등 각 기기 사양에 적합하도록 각 영화를 여러 형식의 비디오로 변환
    • DASH를 이용해 각 형식별로 다양한 비트율의 여러가지 버전 생성
  • CDN으로 버전 업로드
    • AWS의 각 호스트는 생성한 다양한 버전의 영화를 CDN으로 업로드

자체 CDN

  • IXP 및 거주용 ISP 자체에 서버 랙 설치
    • 200대 이상의 서버 랙 / 수백 개 이상의 ISP 장소 보유
  • 각 서버 랙은 10 Gbps 이더넷 포트 / 100 TB 이상의 스토리지
  • Push Caching 방식을 사용해 각 CDN 서버를 채움
    • 클라이언트 요청이 발생하기 전에 미리 예상해서 CDN을 채워 놓는 방식

Steaming Flow

  1. 사용자가 재생할 영화 선택
  2. AWS에서 실행 중인 넷플릭스 애플리케이션이 영화 사본을 갖고 있는 CDN 서버를 결정
  3. 영화가 있는 서버 중 클라이언트 요청에 대한 최적의 서버 할당
  4. 클라이언트는 요청된 영화의 다른 버전에 대한 URL을 가진 매니페스트 파일과 특정 서버의 IP 주소를 보냄
  5. 클라이언트와 해당 CDN 서버는 독점 DASH를 이용해 직접 상호작용

YouTube 사례

  • Netflix와 마찬가지로 자체 CDN 사용
  • 대부분의 클러스터 선택 정책은 클라이언트와 클러스터 간의 RTT가 가장 적은 곳을 선택
    • 작업 부하를 위해 멀리 있는 CDN을 선택하기도 함
  • 재생 위치 조정과 조기 종료로 인한 대역폭과 서버 리소스 낭비를 줄이기 위해 HTTP byte-range 헤더를 사용해 목표한 분량의 선인출 데이터 이후에 추가로 전송되는 데이터 흐름을 제한
© 2024 Seungwon Bae 🇰🇷