컴퓨터 네트워킹 하향식 접근 - Chapter 2, 6장 비디오 스트리밍과 콘텐츠 배포 네트워크

비디오 스트리밍과 CDN : 상황

• 비디오 트래픽 : 인터넷 대역폭의 주요 소비자
  • 넷플릭스, 유튜브 : 가정용 ISP 트래픽의 각각 37%, 16% 차지
  • 약 10억 명의 유튜브 사용자, 약 7500만 명의 넷플릭스 사용자
• 도전 과제 : 규모 - 약 10억 명의 사용자에 어떻게 도달할 것인가?
  • 단일 대형 비디오 서버는 효과가 없다. (이유는?)
• 도전 과제 : 이종성
  • 각 사용자는 서로 다른 능력을 가지고 있음 (예 : 유선 vs 모바일, 대역폭이 풍부한 환경 vs 부족한 환경)
• 해결책 : 분산된 애플리케이션 레벨 인프라

 

 

멀티미디어 : 비디오

• 비디오 : 일정한 속도로 표시되는 이미지 시퀀스
  • 예 : 1초에 24장의 이미지
• 디지털 이미지 : 픽셀 배열
  • 각 픽셀은 비트로 표현됨
• 코딩 : 이미지 내외의 중복성을 이용하여 이미지를 인코딩하는 데 사용되는 비트 수를 줄임
  • 공간적 중복성(이미지 내에서)
  • 시간적 중복성 (연속된 이미지 간에서)
• CBR : (고정 비트율) 비디오 인코딩 속도가 고정됨
• VBR : (가변 비트율) 비디오 인코딩 속도가 공간적, 시간적 코딩의 변화에 따라 변함
• 예시 : 
  • MPEG 1 (CD-ROM) : 1.5Mbps
  • MPEG2 (DVD) : 3.6 Mbps
  • MPEG4 (주로 인터넷에서 사용, 64Kbps ~ 12Mbps)
  • H.264 (→ MPEG-4 part 10, AVC)

 

저장된 비디오 스트리밍

주요 과제

• 서버에서 클라이언트로의 대역폭은 네트워크 혼잡 수준(가정 내, 접속 네트워크, 네트워크 코어, 비디오 서버)에 따라 시간이 지나면서 변동됨
• 혼잡으로 인한 패킷 손실과 지연은 재생 지연을 초래하거나, 비디오 품질 저하를 일으킬 수 있음
• 연속 재생 제약 : 클라이언트에서 비디오 재생 중에는 재생 타이밍이 원래의 타이밍과 일치해야 함
  • 하지만 네트워크 지연은 가변적(jitter)이기 때문에, 클라이언트 측에서 버퍼가 필요하여 연속 재생 제약을 맞춰야 함
• 기타 과제
  • 클라이언트의 상호 작용성 : 일시 정지, 빨리 감기, 되감기, 비디오 내 점프
  • 비디오 패킷 손실 가능성 및 재전

 

재생 버퍼링 (playout buffering)

• 클라이언트 측 버퍼링 및 재생 지연 : 네트워크로 인한 지연과 지연 지터를 보상하기 위해 사용

 

---

스트리밍 멀티미디어 : DASH (Dynamic, Adaptive Streaming over HTTP)

서버 :

• 비디오 파일을 여러 청크로 나눔
• 각 청크는 여러 다른 비트레이트로 인코딩됨
• 각 비트레이트 인코딩은 다른 파일에 저장됨
• 이러한 파일들은 다양한 CDN 노드에 복제되어 저장됨
• manifest file : 다른 청크의 URL을 제공

클라이언트 :

• 주기적으로 서버-클라이언트 간의 대역폭을 추정함
• manifest를 참고하여 한 번에 한 청크씩 요청
  • 현재 대역폭을 고려해 유지 가능한 최대 인코딩 속도를 선택
  • 시간에 따라 가용 대역폭에 따라 다른 인코딩 속도를 선택할 수 있으며, 다른 서버에서 청크를 요청할 수도 있음

 

클라이언트의 지능 : 클라이언트가 결정함

• 언제 청크를 요청할지 결정 (버퍼 고갈이나 오버 플로우가 발생하지 않도록)
• 어떤 인코딩 속도를 요청할지 결정 (대역폭이 많을 때는 더 높은 품질 선택)
• 어디에서 청크를 요청할지 결정 (클라이언트와 가까운 서버 또는 가용 대역폭이 많은 서버에서 청크 요청 가능)

스트리밍 비디오 = 인코딩 + DASH + 재생 버퍼링

 

 

---

콘텐츠 배포 네트워크 (CDN)

• 과제 : 수백만 개의 비디오 중에서 선택된 콘텐츠를 수십만 명의 동시 사용자에게 어떻게 스트리밍할 것인가?
• 옵션 1 : 단일, 대형 메가 서버
  • 단일 장애 지점 
  • 네트워크 혼잡 지점
  • 원거리 클라이언트까지 긴 경로
  • 여러 복사본의 비디오가 아웃고잉 링크를 통해 전송됨
  • 이 해결책은 확정성이 부족함
• 옵션  2 : 지리적으로 분산된 사이트에 여러 복사본을 저장 / 서비스(CDN)
  • enter deep : CDN 서버를 많은 액세스 네트워크에 깊숙이 배치
    • 사용자가 가까운 위치에서 콘텐츠에 접근 가능
    • Akamai가 사용하는 방식 : 2015년 기준으로 24만 대의 서버가 120개 이상의 국가에 배치
  • bring home : POP(Point of Presence) 근처의 대규모 클러스터에 서버를 배치(액세스 네트워크 내부는 아님)
    • 더 적은 수(수십)개의 대형 클러스터
    • Limelight에서 사용하는 방식

 

 

콘텐츠 배포 네트워크들 (CDNs)

• CDN : 콘텐츠의 복사본을 CDN 노드에 저장
  • 예 : 넷플릭스는 MadMen의 복사본을 여러 CDN 노드에 저장
• 구독자가 CDN에서 콘텐츠를 요청
  • 사용자는 가까운 복사본으로 연결되어 컨텐츠를 가져옴
  • 네트워크 경로에 혼잡이 있으면 다른 복사본을 선택할 수도 있음 (다른 CDN 서버 선택할 수도 있음)
• OTT : over the top
  • OTT 서비스 과제 : 혼잡한 인터넷에서의 대응
    • 어떤 CDN 노드에서 콘텐츠를 가져올 것인가?
    • 혼잡 상황에서 시청자의 행동은 어떻게 될 것인가?
    • 어떤 콘텐츠를 어느 CDN 노드에 배치할 것인가?