Ch2-6) Video streaming and content distribution networks

 

• 현재, 비디오 스트리밍 traffic은 ISP traffic의 80%를 차지할 정도로, major consumer of Internet이다.

→ 그렇다면, 우리는 어떻게 10억이 넘는 유저를 관리할 수 있을까? 단순히 하나의 Mega-server 형태는 아닐 것이다.

→ 또한, 각 유저마다 Network에 대해 각각 다른 capability를 보유하고 있을 것인데, 이 간극을 어떻게 해결했을까?

• 바로 distributed, application-level infrastructure을 이용하는 것이다 !

우선, Video의 Streaming 원리에 대해서 살펴보자.

Multimedia : Video

• 비디오는, 초당 24~30개의 image가 연속적으로 나타나는 이미지의 연속이다.
• 압축되지 않은 디지털 이미지는, 픽셀 단위로 구성되며 각각의 픽셀은 비트 단위로 인코딩된다.

→ 또한 매우 많은 양의 데이터( 프레임과 픽셀 ) 을 포함하기 때문에 인코딩 과정에서 효율적으로 computation하는 것이 매우 중요하다. 이를 위해 , ‘Redundancy’를 활용한 계산법이 등장하였다.

• Spatial coding : 이미지 내부에서 발생하는 중복을 줄이는 기법

예를들어, 아래와 같은 사진에서 purple pixel을 가지는 N개의 픽셀을 모두 전송하기보다,

color value, # of repeated value 이 2가지 값을 전송해 전송량을 줄일 수 있다.

 

• Temporal coding : 연속된 프레임 사이의 중복을 줄이는 기법

또한, 위의 사진에서 아래의 사진으로 프레임이 변했다고 하면, 두개의 사진을 모두 전송하는 것이 아니라, 전 프레임과의 “차이점”만을 전송할 수도 있다.

 

 

또한, 비트를 인코딩 할 때에도, 2가지 기법이 존재한다.( Bit rate = 일정시간동안 전송되는 비트의 양 )

1. CBR (Constant Bit Rate )
   • 비트 rate가 고정된 상태로 인코딩하는 방법이다.
   • 비디오의 complexity와 상관없이 항상 일정한 속도로 데이터를 전송한다.
   ⇒ 네트워크나 저장매체의 대역폭이 제한적일 때 사용
   • 네트워크의 대역폭을 예측하기 쉽고, 일정한 대역폭을 유지해야하는 실시간 스트리밍 서비스에서 유리하다.
   • 하지만 비디오가 단순할 때도 일정한 비트율을 사용하기 때문에, 불필요하게 많은 데이터를 사용할 수 있다.
2. VBR (Variable Bit Rate)
   • Vedio의 complexity에 따라 bit rate가 변하는 방법
   • 빠른 움직임이 있는 곳에서는 많은 비트율을, 정적인 곳에선 낮은 비트율을 사용
     • Spatial, Temporal change에 따라서 조정됨
   • 고품질을 유지하면서도 데이터를 효율적으로 전송할 수 있고, 저장공간을 절약할 수 있다.
   • 하지만 Bandwidth 예측이 어렵고 갑작스러운 비트율 증가로 지연이 발생할 수 있다.

⇒ 이 2가지 방법 중 하나를 선택해 사용하는 format이 MPEG format임

• MPEG-1 (CD-ROM) = 1.5Mbp의 CBR 이용
• MPEG-2 (DVD) = 3-6Mbps의 VBR 이용
• MPEG-4 ( internet streaming) = 64kbps - 12Mbps의 VBR이용

Streaming stored Video

그렇다면, 그림으로 Server에 저장된 비디오가 클라이언트로 도달하는 과정을 알아보자.

 

 

1. 우선, 30frames/sec의 데이터를 가지는 video가 서버에 계단식으로 저장되었다고 생각해보자.
2. 서버는, client를 통해 video를 보낼 것이고, network delay(이 예시에선 고정)의 시간 후에 client가 재생하게 된다.
   • 이때, 비디오는 모두 도착하지 않았지만, client는 재생을 시작한다.
   • 비디오는 30frames/sec로 재생되며, 이는 서버가 전송하는 속도와 동기화된다.

⇒ 그런데, 이 상황에서 발생할 수 있는 문제점이 존재한다.

• Continuous Playout Constraint
  • 클리아언트 측의 재생이 시작되면, 비디오는 원래 시간에 맞춰 연속적으로 도착해야한다.
  • 그러나 “네트워크 지연”이 시간에 따라 가변적인 상황이 일반적이다.
  • 네트워크 혼잡 등으로 인해 패킷 도착시간에 변동성이 발생하여, 연속적인 재생을 방해할 수 있다.

⇒ 이를 해결하기 위해, “Client buffer”라는 개념을 도입한다.

• 초기 재생을 시작하기 전에, client buffer은 미리 일정양의 비디오 데이터를 저장해놓고, 지연이 발생해도 중단 없이 영상을 이어갈 수 있도록 한다.
• 아래의 예시를 보자
•  

 

 

• 만약 CBR로 Video를 전송한다고 하면, variable network delay가 발생할 수 있기에, client buffer에 잠시 데이터를 보관해둔다.
• 이후, 충분히 버퍼에 데이터가 모였으면, 서버로부터 처음 데이터가 도착한 이후 “client playout delay”만큼의 시간이 흐른 뒤 video 재생을 시작한다.
• 하지만 이러한 버퍼는 일시적인 끊김이 발생하지 않도록 데이터를 저장하는 것이었다.
  • 장기적인 네트워크 변동이 있을 때에는 버퍼만으로 문제를 해결하기 어렵고, 모바일 환경에서는 네트워크 상태가 자주 변하므로 단순히 버퍼를 사용한 방식만으로는 quality 유지에 한계가 있었다.
• 또한, 버퍼는 “이미 수신된 데이터”를 재생하는 동안만 효과적이다.
  • 네트워크 상황에따라 “실시간 Bit Rate”를 조절할 필요가 있는 경우에는 버퍼는 무의미하다.
  • 예를 들어, CBR에서는 실시간으로 Bit rate를 유연하게 조율할 수 없다.

⇒ 이러한 버퍼의 문제를 해결하기 위해서, HTTP 기반 스트리밍인 DASH가 나오게 되었다.

HTTP Streaming and DASH

• DASH (Dynamic , Adaptive Streaming HTTP)
  • HTTP를 통해 adaptive video streaming을 제공하는 프로토콜이다.
  • 네트워크 상황에 따라 최적의 bit rate를 선택해 재생할 수 있다.
  • ex) youtuve ,Netflix
  •  

 

 

 

이러한 DASH protocol에서, 서버의 역할은 다음과 같다

• Role of server
  • 비디오를 여러 chunk로 나눈다.
  • 이 chunk를, 여러 bit rate로 인코딩한다.
    • 각 청크는 다양한 비트율로 인코딩되어 다양한 품질 옵션을 제공한다.
    • ex) 360p, 720p, 1080p
  • Manifest file을 제공한다.
    • Manifest file은 모든 청크의 URL과 정보를 포함하는 file이다.
    • 클라이언트는, 이 manifest file을 참고하여 필요한 청크를 요청한다.

또한 client의 역할은 다음과 같다

• Role of client
  • 주기적으로, server→client bandwidth를 측정한다.
    • 이는 대역폭을 파악해 네트워크 상태를 체크하기 위함이다.
  • Manifest file을 참고해, 네트워크 상태에 맞는 chunk를 요청한다.
    • 네트워크가 좋으면 높은 bit rate chunk 선택하면 좋겠쬬?
    • 가용 bandwith에 따라 선택

⇒ 그럼, 이러한 DASH protocol의 장점을 살펴보자.

가장 큰 장점은 바로, 클라이언트에게 지능적 결정을 맡기는 것이다 (Intelligence at Client)

• When to request chunk
  • so that buffer starvation, overflow가 발생 x
• What endoing rate
  • higher quality when more network bandwith available
• Where to request chunk
  • 가장 가까운 서버 / 대역폭이 충분한 서버 에서 chunk를 요청한다.
    • 이 과정은 Content Distribution network와 같은 분산 서버에서 이루어진다.

⇒ 이러한 특성 덕분에, DASH Protocol은 3가지 component로 이루어진다

DASH = encoding + DASH + playout buffering

1. Encoding: 비디오를 다양한 비트율과 품질로 인코딩하고,
2. DASH: 클라이언트가 네트워크 상태에 따라 적응형으로 청크를 선택하고 다운로드한다.
3. Playout Buffering: 재생 중단을 방지하기 위해 클라이언트 측 버퍼에서 데이터를 관리한다.

그렇다면, Client가 chunk를 요청하는 Content Distribution Network도 궁금할 것이다.

⇒ DASH는 어떻게 HTTP Protocol을 사용하는지 briefly explain 하시오.

Content Distribution Network ( CDN )

• 우선, DASH 방식에서 Client가 비디오 청크를 요청할때, 다음과 같은 문제가 발생할 수 있다.
  • Client가 data center와 위치가 먼 경우, 다양한 access link와 ISP들을 거치게 되는데, 이. LInk들 중 하나라도 Vedio 소비율보다 낮은 bit rate를 가지는 경우 Bottle neck이 발생한다.
  • 또한 서버 입장에서는, 인기있는 비디오는 같은 access link를 통해 여러번 반복적으로 전송될 것인데, 동일한 Byte를 전송하는데 반복적으로 비용을 지불해야한다.
  ⇒ 이러한 문제를 해결하기 위해 CDN이 나오게 되었다.
• CDN (Content Distribution Network)
  • CDN은 다수의 지점에 분산된 네트워크를 이용해, 비디오 등의 컨텐츠의 복사본을 분산 서버에 저장해놓는다.
  • 사용자는 최적의 서비스를 제공받을 수 있는 CDN에 연결된다
  • 구글처럼 사설 CDN일 수도 있고,제 3자가 운영하는 CDN을 통해 서비스될 수도 있다.
• CDN 서버 위치를 선정할 때 고려하는 점은 다음과 같다.
  1. Enter deep
     
     • Akamai에 의해 주장된 것으로, 서버 클러스터를 세계 곳곳에 구축해 ISP 서버로 깊숙히 침투하는 것이다.
     • 즉, 최대한 서버를 사용자 근처에 위치시켜 라우팅 횟수를 낮추어, delay와 bit rate를 개선한다.
     • 작은 서버 클러스터를 최대한 많은 곳에 분산배치
     • push CDN servers deep into many access networks
  2. Bring home
     • 큰 서버 클러스터를 소수의 지점에 배치
     • POP란, ISP가 사용자에게 네트워크 접속을 제공하는 거점지점이다.
     • 보통 클러스터는 IXP에 배치된다.
     • 이렇게 하면 처리율은 enter deep보다 느려지지만, 유지보수하기 편하다는 장점이 있다.
     • smaller number (10’s) of larger clusters in POP (point of presence) s near (but not within) access networks
  Note) 사실 실제로 CDN은 사용자의 요청이 올때 다른 클러스터로부터 컨텐츠를 전송받아 동시에 복사본을 만들어 저장하는 Pull 방식을 이용한다. 저장공간이 가득 차면, 가장 안쓰는 비디오를 삭제한다.

• 그럼, 그림을 통해 CDN의 동작 과정을 살펴보자
•  

 

• 넷플릭스가, MADMEN이라는 영상을 각 CDN node에 저장해놓는다고 해보자.
• 구독자는, MADMEN에 대한 request를 보내게 된다.
  • 이때 사용자가 요청한 컨텐츠가 저장된 노드로 요청이 리다이렉션 된다.
  • 이로써 delay를 낮추고 빠르게 전송할 수 있게 한다.
• 하지만, congestion이 발생할 경우도 존재한다.
  • 이럴 경우에는 manifest file을 참고해 어떤 노드에 복사본이 있는지 알려주어 사용자가 최적의 경로로 연결될 수 있도록 한다.

이러한 형태의 데이터 전송을 지원하는 것이 바로 OTT (Over-the-Top)인데, OTT에서 CDN은 매우 중요한 역할을 맡게 된다.

• OTT
  • OTT란, 전통적인 방송사나 통신사 네트워크를 거치지 않고 직접 사용자에게 컨텐츠를 제공하는 방법이다.
  • ex) youtube, netflix 등
• OTT가 빠르게 서비를 제공하기 위해서는 곳곳에 CDN을 배치해야 하고, 최적의 경로를 제공해야한다.

이 때, 생각해볼 수 있는 문제점은 다음과 같다.

1. 어느 CDN 노드에서 컨텐츠를 가져올 것인가?
2. congestion이 발생할 때 viewr의 행동 변화는 어떻게 할 것인가?
3. 어느 컨텐츠를 어느 CDN 노드에 배치할 것인가?

이에 대한 해답을 내리기 위해 CDN은 DNS를 이용한다. 하나의 사례를 들어 생각해보자.

 

이 상황은 Bob이라는 client가 http://netcinema.com/6Y7B23V라는 비디오를 요청한 상황이다.

1. 우선, Bob은 URL을 입력한다.
2. 사용자의 host는 URL의 host name에 대한 질의를 Bob의 Loacl DNS로 보낸다 (resolving한다.)
3. 로컬 DNS는 host name의 authoritative DNS server로, CNAME Type으로 질의를 넘긴다.
   • 이때 authoritative server는 해당 질의를 CDN 서버로 연결하기 위해 Local DNS에게 CDN 서버의 athoritative server의 IP 주소를 전달해준다.
4. 로컬 DNS는 다시 CDN Authoritative server로 질의를 넘기고, CDN Authoritative 서버는 CDN 서버의 IP 주소를 로컬 DNS로 응답한다.
   • 여기서 콘텐츠를 제공받게 될 주소 결정!
5. 로컬 DNS는, 호스트에게 CDN 서버의 IP 주소를 넘기낟.
6. 알게된 IP 주소로 HTTP또는 DASH protocol을 이용해 비디오를 받아온다.

• 이때, 4번 과정에서 Authoritative DNS 서버는 CDN의 IP 주소를 로컬 DNS에게 넘겨준다고 하였다.
  • CDN은, DNS를 통해 가로채는 과정에서 클라이언트의 로컬 DNS IP 주소에 기초해 최선의 클러스터를 선택하게 된다.

1. Geographically Close
   • 사용자의 지리정보는 DB를 뒤지면 나오기에 가장 가까운 클러스터를 선택한다.
   • 대부분 맞지만, 홉의 길이와 수에 따라서 아닐 수도 있다.
2. Real-time measurements
   • Client 사이의 delay를 측정해, 현재 네트워크 상황을 반영해 선택한다.
   • 근데 로컬 DNS 서버가 이러한 측정에 응답을 안해준다 ㅋㅋㅋㅋ

위의 과정을 사용하는 OTT의 사례로, Netflix가 존재한다.