Video streaming and content distribution networks

상위 문서: Application Layer

개요

사전 녹화된 비디오 스트리밍은 현재 북미의 주거용 ISP 트래픽 대부분을 차지한다. 특히, 넷플릭스(Netflix) 와 유튜브(YouTube) 만으로도 2015년 기준 각각 37%와 16%의 트래픽을 소비했다. 이는 넷플릭스와 유튜브가 2015년 기준 약 7500만명, 10억명의 이용자 수를 가지고 있기 때문이다. 또한 많은 사용자 수는 heterogeneity라는 문제를 발생시키는데, 이는 사용자가 모두 다른 환경을 가지고 있기 때문에 모든 사용자에게 동일한 품질을 제공할 수 없어 생기는 문제이다. 해당 문서에서는 현재 인터넷에서 널리 사용되는 비디오 스트리밍 서비스가 어떻게 구현되는지에 대해 설명하는 것을 목표로 한다.

Video

비디오는 일련의 이미지이며, 초당 24~30프레임의 일정한 속도로 표시된다. 이때 디지털 이미지 하나는 픽셀 배열로 이루어져 있고, 각 픽셀은 밝기(luminance) 와 색상(color) 정보를 표현하는 비트들로 인코딩된다.

비디오의 가장 중요한 특성 중 하나는 압축 가능하다는 것이다. 압축을 통해 비디오 품질과 비트레이트(bitrate) 사이의 절충이 가능하며, 비트레이트가 높을수록 영상 품질이 더 좋아진다. 이때 압축된 비디오는 보통 100kbps~3Mbps 정도를 요구하는데, 비디오가 끊김없이 재생되기 위해서는 average end-to-end throughput이 압축된 비디오의 bitrate보다 더 커야 한다. 이 때문에 사용자는 자신의 네트워크 상태에 맞는 비디오 버전을 선택하여 재생할 수 있어야 한다.

HTTP streaming

HTTP streaming에서는 비디오가 일반 파일처럼 HTTP 서버에 저장되고, 고유한 URL을 갖는다. 사용자가 재생하려고 하면, 클라이언트는 서버에 TCP 연결을 맺고 해당 URL로 HTTP GET 요청을 보낸다. 그리고 서버는 HTTP 응답 메시지에 비디오 파일을 담아 전송한다.
클라이언트 측에서는 수신된 바이트가 애플리케이션 버퍼에 쌓이고, 버퍼가 일정 임계치를 넘으면, 재생을 시작한다. 이후 프레임을 주기적으로 가져와 압축 해제하고, 화면에 출력하는 방식으로 비디오를 재생한다. 즉 비디오를 받으면서 동시에 재생하는 구조이다.

하지만 이는 모든 사용자에게 동일한 비디오 인코딩이 재공된다는 단점이 있다. 사용자마다 네트워크 환경이 크게 다르고, 같은 사용자도 시간에 따라 네트워크 상태가 변동하기 때문에 이를 반영할 새로운 메커니즘이 필요하다.

Dynamic Adaptive Streaming over HTTP

DASH (Dynamic Adaptive Streaming over HTTP)는 위의 HTTP 스트리밍의 문제를 해결한 방식이다.

DASH 작동원리

server는 비디오를 서로 다른 bitrate의 여러 버전으로 인코딩하고, 해당 비디오 파일들은 여러 개의 청크(chunk) 단위로 나누어 저장된다. 클라이언트는 비디오 URL을 통해 서버에 접근하여 먼저 manifest file을 요청한다. menifest file은 각 버전의 비디오 파일들의 URL과 bitrate 정보를 가지고 있다. 클라이언트는 서버로부터 manifest file을 받아 현재 자신의 네트워크 상태에 맞는 bitrate 버전을 판단하고 이에 대한 URL을 선택해서 서버에 요청한다. 이후로도 클라이언트는 주기적으로 server-to-client bandwidth를 측정하여 현재 속도에서 감당 가능한 최대 품질의 청크를 로드한다. 이 과정은 매 청크마다 반복된다. 이는 유동적으로 변화하는 네트워크 상황에서도 고화질, 혹은 저화질 영상을 전환하며, 안정적인 비디오 스트리밍 서비스를 제공하도록 한다.

DASH 특징

DASH는 사용자의 단말기가 지능적으로 작동하여 'Dynamic, Adaptive Streaming'을 가능케한다. 사용자의 단말기는 manifest file을 바탕으로 아래의 세 가지를 스스로 판단한다.

1. when to request chunk?
   • 너무 일찍 요청하면 버퍼가 넘칠 수 있고, 너무 늦게 요청하면 버퍼가 비어서 재생이 끊길 수 있다.
     즉, 클라이언트는 현재 버퍼 상태를 고려해 적절한 시점에 청크를 요청한다.
2. what encoding rate to request?
   • 네트워크가 빠르면 high bitrate 청크를 선택하고 느리면 low bitrate 청크를 선택하여 품질을 조정해야 한다.
3. where to request chunk?
   • 하나의 비디오가 여러 서버(CDN 노드)에 분산되어 있을 수 있어, 클라이언트는 가까운 서버, 또는 가용 대역폭이 넉넉한 서버를 선택해야 한다.

Contents Distribution Network

유튜브 같은 기업은 수백만 개 이상의 비디오를 전 세계 사용자에게 매일 스트리밍하고 있다. 이렇게 많은 데이터를 빠르게, 안정적으로 전송하는 것은 매우 어려운 일이다. 이를 해결할 수 있는 단순한 방법은 하나의 대형 데이터 센터를 만들고 모든 비디오를 거기에 저장해서 전 세계로 직접 전송하는 것이다. 하지만 이런 방식에는 다음과 같은 큰 문제가 있다:

• single point of failure: 데이터 센터 단 하나에만 문제가 생겨도 전 세계를 대상으로 하는 서비스가 중단될 수 있다.
• point of network congestion: 단 하나의 서버가 모든 유저들의 비디오 스트리밍을 지원해야 하므로, 서버의 network congestion이 증가한다.
• long path to distant client: 예를 들어 미국에 있는 데이터 서버는 한국에서 접속할 때 물리적인 거리도 멀고, 여러 통신 링크와 ISP를 거쳐야 하므로 delay가 증가한다.
• multiple copies of video sent over outgoing link: 인기있는 비디오의 요청에 대해 하나의 데이터 센터가 일일히 처리해야 하므로 그 비효율성이 커진다.

CDN(Contents Distribution Network)는 이러한 문제 상황을 해결하기 위해서 등장하였다. CDN은 전 세계 여러 지역에 서버를 분산 배치하고, 비디오(및 이미지, 문서 등 웹 콘텐츠)를 복제하여 저장한다.

Pull 전략

CDN은 클러스터에 모든 비디오를 다 복제해두지는 않는다. 그 이유는 어떤 비디오는 인기가 없어, 저장해 봤자 공간을 낭비하거나, 특정 국가에서만 인기가 있어 다른 국가의 클러스터에는 저장할 필요가 없기 때문이다. 이 때문에 대부분의 CDN은 클러스터에 선제적으로 비디오를 push하지 않고, 클라이언트 요청이 있을 때에만 Pull 전략을 사용한다. 클러스터에 해당 비디오가 없는데 클라이언트가 요청하면, 클러스터는 중앙 저장소나 다른 클러스터로부터 그 비디오를 가져오며 동시에 클라이언트에게 스트리밍을 시작한다. 가져온 비디오는 클러스터 내에 저장해두고, 다른 사용자가 요청하면 바로 제공할 수 있도록 한다. 클러스터의 저장 공간이 가득차면, 인기없는 비디오를 제거하고 새로 요청된 비디오를 저장한다. 이를 통해서 자주 요청되는 비디오를 클러스터에 저장하여 웹 캐시(web cache)와 비슷한 방식으로 효율적인 비디오 재생을 지원한다.

CDN의 유형

CDN은 크게 두가지 유형으로 나뉜다. 첫번째 하나는 enter deep 방식으로, 그 이름처럼 전세계의 ISP access network 안쪽으로 깊숙히 구석구석 CDN server들을 배치하는 방식이다. 이는 사용자와 CDN server를 가까이 위치해 delay를 감소시키고, 실질적인 throuput을 증가시켜 더욱 쾌적한 품질의 비디오를 사용자에게 제공할 수 있다는 장점이 있다. 하지만 관리해야 할 서버가 많기 때문에 유지/운영이 복잡하다는 단점이 있다.
또 다른 하나는 bring home 방식으로, enter deep 방식에 비해 상대적으로 더 적은 수의, 하지만 더 대형인 서버를 access network 근처의 POP에 설치하는 방식이다. 이는 더 적은 수의 서버만을 운영하므로 관리가 용이하고 비용적으로도 저렴하다는 장점이 있다. 하지만 enter deep 방식에 비해 사용자가 더 CDN server에서 멀어질 수 있어, 그런 사용자에게 상대적으로 더 높은 delay와 더 낮은 throughput을 제공할 수 있다는 단점이 있다.

CDN operation

DNS redirects a user’s request to a CDN server

DNS redirects a user’s request to a CDN server

아래는 CDN의 작동 과정을 설명하기 위해서 준영이가 웹 사이트에서 비디오를 클릭한 순간부터, 실제로 비디오를 제공하는 CDN 서버에서 콘텐츠를 받기까지의 과정 예시이다. 준영이는 영상 콘텐츠를 제공하는 웹사이트인 Netfoolix를 이용한다. 그리고 Netfoolix는 자체적으로 전 세계 서버를 운영하지 않고, ZZangCDN이라는 외부 CDN 회사에 콘텐츠 배포를 맡겼다고 하자. 또한 비디오에는 고유한 URL이 존재하며, 예를 들어 람바 1/2에는 고유한 URL(http://video.netfoolix.com/6Y7B23V)이 존재한다. 이 상황에서 준영이가 Netfoolix 웹사이트에 들어가서 이 URL을 클릭했을 때, 벌어지는 일은 다음과 같다:

1. 준영이가 브라우저를 통해서 Netfoolix에 접속하고, 람바 1/2 비디오를 클릭하고자 한다.
2. 준영이가 http://video.netfoolix.com/6Y7B23V를 클릭하고, 브라우저는 해당 URL에 대한 IP주소를 얻기 위해 DNS query를 보낸다.
   • 먼저 Local DNS server에 접속하여 video.netfoolix.com에 대한 IP주소를 물어본다.
3. Local DNS server는 자신이 모른다고 판단하면 Netfoolix의 authoritative DNS에 query를 보낸다.
   • 이때 질의를 받은 Netfoolix의 DNS server는 서비스를 ZZangCDN에 맡겼으므로 video.netfoolix.com에 대한 실제 IP주소가 아닌 ZZangCDN에 대한 URL을 반환한다. (예를 들어 http://ZZangCDN.com/NetF6y&B23)
4. Local DNS server는 ZZangCDN의 IP 주소를 얻기 위해서 다시 DNS query를 ZZangCDN DNS server으로 보낸다.
   • ZZangCDN DNS server는 준영이에게 여러 서버 클러스터 중 준영이에게 가장 가까운 서버 클러스터의 IP 주소를 반환한다.
5. Local DNS server는 최종적으로 얻은 IP주소를 사용자에게 전달한다.
   • 브라우저는 video.netfoolix.com에 대한 IP 주소를 가지게 되었으며, 이는 사실상 ZZangCDN 콘텐츠 서버의 IP주소와 같다.
6. 준영이는 해당 IP주소를 바탕으로 CDN서버와 TCP 연결을 맺은 후, CDN 서버에게 비디오 재생을 요청한다.
   • 이때 DASH 기술이 사용되고 있다면 CDN server는 먼저 menifest file을 클라이언트에게 제공한다.
     이를 통해서 준영이는 현재의 네트워크 상태에 따라 알맞은 화질의 청크를 선택하여 비디오를 재생한다.