[네트워크] 2.6 비디오 스트리밍과 콘텐츠 분배 네트워크

이 절에서는 오늘날 인터넷에서 널리 사용되는 비디오 스트리밍 서비스가 어떻게 구현되는지에 대한 개요를 제공한다. 

캐시와 같은 기능을 하는 Application level Protocol과 Server를 사용하여 구현된 것을 볼 수 있다.

 

2.6.1 인터넷 비디오

녹화된 비디오는 서버에 저장되어, 사용자가 비디오 시청을 서버에게 온디맨드로 요청한다. 넷플릭스, 유튜브(구글), 아마존, 틱톡 등 많은 인터넷 회사가 비디오 스트리밍을 지원하고 있다.

 

비디오는 이미지의 연속으로서, 일반적으로 초당 24개 또는 30개의 이미지로 일정한 속도로 표시된다. 압축되지 않은 디지털 인코딩 이미지는 픽셀 단위로 구성되며, 각 픽셀은 휘도와 색상을 나타내는 여러 비티들로 인코딩된다.

비디오의 중요한 특징은 압축될 수 있다는 것이다.

비트 전송률이 높을수록 이미지 품질이 좋아지고, 전반적인 사용자 시청 환경이 향상된다.

 

 

2.6.2 HTTP 스트리밍 및 DASH

HTTP 스트리밍에서 비디오는 HTTP 서버 내의 특정 URL을 갖는 일반적인 파일로 저장된다.

1. 사용자가 비디오 시청을 원하면, 클라이언트는 서버에게 TCP 연결을 설립하고, 해당 URL에 대한 HTTP GET 요청을 발생시킨다.
2. 그러면 서버가 기본 네트워크 프로토콜 및 트래픽 조건이 허용되는 대로, HTTP 응답 메시지 내에서 비디오 파일을 전송한다.
3. 클라이언트 쪽에서는 애플리케이션 버퍼에 전송된 바이트가 저장된다. 이 버퍼의 바이트 수가 미리 정해진 임곗값(threshold)을 초과하면, 클라이언트 애플리케이션이 재생을 시작한다.
   특히 스트리밍 비디오 애플리케이션은, 클라이언트 애플리케이션 버퍼에서 주기적으로 비디오 프레임을 가져와서 프레임을 압축해제한 다음 사용자의 화면에 표시한다. 따라서 비디오 스트리밍 애플리케이션은 비디오의 후반 부분에 해당하는 프레임을 수신하고 버퍼링할 때 비디오를 표시한다.

▶ Problem: 클라이언트가 가용 대역폭 차이에도 불구하고 똑같이 인코딩된 비디오를 받는다.

HTTP 스트리밍은 유튜브 등 많은 시스템에서 실제 적용되고 있으나, 중요한 문제점이 있다. 바로 클라이언트가 그들 사이의 가용 대역폭 차이에도 불구하고 똑같이 인코딩된 비디오를 받는다는 점이다. 가용 대역폭의 차이는 각기 다른 클라이언트들 간에 존재할 뿐만 아니라, 동일한 클라이언트에서도 시간에 따른 차이가 발생한다. 

 

▶ Solution: DASH (Dynamic Adaptive Streaming over HTTP)

이 문제점으로 인해 새로운 형태의 HTTP 기반 스트리밍인 DASH가 개발되었다. DASH에서 비디오는 여러 가지 버전으로 인코딩되며, 각 버전은 비트율과 품질 수준이 서로 다르다.

클라이언트는 동적으로 서로 다른 버전의 비디오를 몇 초 분량의 길이를 갖는 비디오 조각(chunk) 단위로 요청한다. 가용 대역폭이 충분할 때는 높은 비트율의 비디오 버전을 요청하며, 가용 대역폭이 적을 때는 낮은 비트율의 비디오 버전을 요청한다. 클라이언트는 HTTP GET 요청을 이용해 다른 버전의 비디오 조각을 매번 선택한다.

 

DASH는 서로 다른 인터넷 접속 회선을 가진 클라이언트들에게 서로 다른 인코딩률을 갖는 비디오를 선택할 수 있도록 허용한다. 

 

DASH를 사용할 때, 각 비디오 버전은 HTTP 서버에 서로 다른 URL을 가지고 저장된다. HTTP 서버는 비트율에 따른 각 버전의 URL을 제공하는 매니페스트 파일(manifest file)을 갖고 있다. 

1. 클라이언트는 먼저 manifest file을 요청하여, 서버에서 제공되는 다양한 버전에 대해 알게 된다.
2. 이후 클라이언트는 매번 원하는 버전의 비디오 조각 단위 데이터를 선택하여, HTTP GET 요청 메시지에 URL과 byte-range를 지정하여 요청한다.
3. 비디오 조각 단위 데이터를 다운로드하는 동안에, 클라이언트는 측정된 수신 대역폭과 비트율 결정 알고리즘을 이용해, 다음에 선택할 비디오 조각 단위 데이터의 버전을 결정한다.
   클라이언트가 충분한 분량의 버퍼링된 비디오를 갖고 있고, 측정된 수신 대역폭이 크다면 당연히 고품질의 비디오 조각 단위 데이터를 선택할 것이다. 반대로 클라이언트가 적은 분량의 버퍼링된 비디오를 갖고 있고, 수신 대역폭이 작다면 낮은 품질의 비디오 조각 단위 데이터를 선택할 것이다.

 

 

2.6.3 콘텐츠 분배 네트워크(CDN)

오늘날 많은 인터넷 비디오 회사들은 날마다 수많은 사용자들에게 Mbps 비디오 스트림을 분배하고 있다. 유튜브같은 회사는 수천만에 이르는 소장 비디오를 가지고 매일 수억 명의 사용자들에게 스트리밍 서비스를 제공한다. 이 엄청난 스트리밍 트래픽을 전 세계에 걸친 지점에 끊김 없이 안정적으로 제공하는 일은 매우 큰 문제다.

 

인터넷 비디오 회사에 스트리밍 서비스를 제공하는 가장 단순한 방법은 단일한 거대 데이터 센터를 구축하고, 모든 비디오 자료를 데이터 센터에 저장한 뒤, 전 세계의 사용자에게 비디오 스트림을 데이터 센터로부터 직접 전송하는 것이다.

 

그러나 이 방법에는 중대한 문제가 있다.

• 첫째, 클라이언트가 데이터 센터로부터 지역적으로 먼 지점에 있는 경우, 서버로부터 클라이언트로의 패킷 경로는 많은 다양한 통신 링크와 ISP를 거쳐 가게 되는데, 이러한 ISP는 각기 다른 대륙에 위치할 수도 있다. 이 링크들 중 하나라도 비디오 소비율보다 낮은 전송 용량을 갖는다면, 종단 간 처리율이 낮아지고 결국 사용자는 짜증스러운 화면 정지 현상을 겪게 된다. (종단 간 처리율: 병목 지점의 링크에 의해 좌우된다.) 종단 간 길이가 길어질수록 이와 같은 현상은 증가한다.
• 두 번째 문제는 인기 있는 비디오는 같은 통신 링크를 통해 여러 번 반복적으로 전송된다는 점이다. 이는 네트워크 대역폭의 낭비는 물론이고, 인터넷 비디오 회사는 회선을 제공하는 ISP들에게 동일한 바이트를 전송하는 것에 대해 중복 비용을 지불하는 결과를 초래한다.
• 세 번째 문제점은 단일한 데이터 센터를 구축하면, 한 번의 장애로 인해 전체 서비스가 중단될 수 있는 위험이 있다는 것이다.

 

▶ Solution: CDN (Content Distribution Network; 콘텐츠 분배 네트워크)

전 세계의 사용자들에게 엄청난 양의 비디오 데이터를 분배하는 문제를 해결하기 위해 거의 대부분의 비디오 스트리밍 회사들은 CDN을 이용한다.

CDN은 다수의 지점에 분산된 서버들을 운영하며, 비디오 및 다른 형태의 웹 콘텐츠 데이터의 복사본을 이러한 분산 서버에 저장한다. 사용자는 최선의 서비스와 사용자 경험을 제공할 수 있는 지점의 CDN 서버로 연결된다.

CDN은 콘텐츠 제공자가 소유한 사설 CDN (private CDN)일 수 있으며, 예를 들어 유튜브의 비디오는 구글의 CDN을 통해 분배된다. 또는 제3자가 운영하는 CDN을 통해 다수의 콘텐츠 제공자가 서비스할 수도 있는데, Akamai, Limelight, Level-3가 제3자가 운영하는 CDN (third-party CDN)에 속한다.

 

CDN은 일반적으로 서버의 위치에 대해 다음 두 가지 철학 중 하나를 채용하고 있다.

• Enter Deep: 서버 클러스터를 세계 곳곳의 접속 네트워크에 구축함으로써, ISP의 접속 네트워크로 깊숙히 들어가는 것이다. 
  --> 서버를 최대한 사용자 가까이에 위치시켜, 사용자와 CDN 서버 사이의 링크 및 라우터 수를 줄이고, 사용자가 경험하는 지연 시간 및 처리율을 개선한다.
• Bring Home: 좀 더 적은 수의 핵심 지점에 큰 규모의 서버 클러스터를 구축하며 ISP를 Home으로 가져오는 것이다.
  --> 접속 ISP에 연결하는 대신, 이러한 CDN들은 일반적으로 그들의 클러스터를 인터넷 교환 지점(IXP)에 배치한다.
  Enter Deep에 비해 Bring Home 방식은 클러스터 유지 및 관리 비용이 줄어드는 대신에 사용자가 느끼는 지연 시간과 처리율은 상대적으로 나빠진다.

 

서버 클러스터의 위치가 정해지면 CDN은 콘텐츠의 복사본을 이들 클러스터에 저장한다. CDN은 각 클러스터마다 모든 비디오의 복사본을 전부 유지할 필요는 없는데, 이는 어떤 비디오는 인기가 거의 없거나 일부 특정 국가에서만 인기가 있을 수 있기 때문이다.

실제로 CDN은 클러스터에 대해 푸시(push) 방식이 아닌, 풀(pull) 방식을 사용한다. 어떤 사용자가 지역 클러스터에 없는 비디오를 요청하면, 해당 비디오를 중앙 서버나 다른 클러스터로부터 전송받아 사용자에게 서비스하는 동시에 복사본을 만들어 저장한다.

 

CDN 동작

사용자 호스트의 웹 브라우저가 URL을 지정함으로써 특정 비디오의 재생을 요청하면,

1. CDN은 그 요청을 가로채, 그 시점에서 클라이언트에게 가장 적당한 CDN 클러스터를 선택하고,
2. 클라이언트의 요청을 해당 클러스터의 서버로 연결한다.

 

▶ CDN이 사용자의 요청을 가로채는 방법:

대부분의 CDN은 사용자의 요청을 가로채고 다른 곳으로 연결하는 데 DNS를 활용한다.

1. 사용자가 NetCinema의 웹 페이지를 방문한다.
2. 사용자가 http://video.netcinema.com/6Y7B23V 링크를 클릭하면, 사용자의 호스트는 video.netcinema.com에 대한 DNS 질의를 보낸다.
3. 사용자의 지역 DNS 서버(LDNS)는 호스트 이름의 'video' 문자열을 감지하고는 해당 질의를 NetCinema의 책임 DNS 서버(authoratative DNS server)로 전달한다. NetCinema의 책임 DNS 서버(authoratative DNS server)는 해당 DNS 질의를 KingCDN으로 연결하기 위해 IP 주소 대신에 KingCDN의 호스트 이름(예: a1105.kingcdn.com)을 LDNS에게 알려준다.
4. 이 시점부터 DNS 질의는 KingCDN의 사설 DNS 주소로 들어가게 된다. 사용자의 LDNS는 a1105.king.com에 대한 두 번째 질의를 보내고, 이는 KingCDN의 DNS에 의해 KingCDN 콘텐츠 서버의 IP 주소로 변환되어 LDNS에게 응답된다. 이때 클라이언트가 콘텐츠를 전송받게 될 서버가 결정된다.
5. LDNS는 콘텐츠를 제공할 CDN 서버의 IP 주소를 사용자 호스트에게 알려준다.
6. 클라이언트는 KingCDN 서버의 IP 주소를 얻고 나면, 해당 IP 주소로 직접 TCP 연결을 설정하고, 비디오에 대한 HTTP GET 요청을 전송한다. 만약 DASH가 사용된다면, 서버는 먼저 각기 다른 버전의 비디오에 대한 URL 목록을 포함하는 manifest file을 클라이언트에게 전송하고, 클라이언트는 동적으로 각기 다른 버전의 비디오 조각 단위 데이터를 선택할 수 있다.

 

클러스터 선택 정책 (cluster selection strategy)

: 클라이언트를 동적으로 어떤 서버 클러스터 또는 CDN 데이터 센터로 연결하는 방식

 

CDN은 클라이언트가 DNS 서비스를 수행하는 과정에서 클라이언트의 LDNS 서버의 IP 주소를 알게 된다. IP 주소를 알아낸 CDN은 해당 IP 주소에 기초해 최선의 클러스터를 선택할 필요가 있다. 

• 클라이언트에게 지리적으로 가장 가까운 클러스터를 할당하는 기법
• 현재의 네트워크 트래픽 상황을 반영한 최선의 클러스터를 선택하기 위해, CDN은 주기적으로 클러스터와 클라이언트 간의 지연 및 손실 성능에 대한 실시간 측정(real-time measurements)을 수행하기도 한다.

 

 

2.6.4 사례연구: 넷플릭스, 유튜브

넷플릭스 비디오 스트리밍 플랫폼

• 콘텐츠 수집: 넷플릭스는 고객들에게 비디오를 분배하기 전에 먼저 영화를 수집하고 처리해야 한다. 넷플릭스는 영화의 스튜디오 마스터 버전을 받아서 아마존 클라우드 시스템의 호스트에 업로드한다.
• 콘텐츠 처리: 아마존 클라우드 시스템의 기기에서는 데스크톱 컴퓨터, 스마트폰, TV에 연결된 게임 콘솔 등 고객들의 다양한 플레이어 기기 사양에 적합하도록 각 영화의 여러 가지 형식의 비디오를 생성한다. 또한 DASH를 이용한 HTTP 적응적 스트리밍 서비스를 위해 각 형식별로 다양한 비트율의 여러가지  버전을 생성한다.
• CDN으로의 버전 업로드: 일단 영화의 다양한 버전이 생성되면, 아마존 클라우드 시스템의 호스트는 이러한 버전을 CDN으로 업로드할 수 있다.

1. 넷플릭스 비디오 라이브러리를 탐색하는 웹 페이지는 아마존 클라우드 서버에서 제공된다. 
   사용자가 재생할 영화를 선택하면, 아마존 클라우드에서 실행 중인 넷플릭스 소프트웨어가 먼저 해당 영화 사본을 갖고 있는 CDN 서버를 결정한다. 영화가 있는 서버 중에서 소프트웨어는 클라이언트 요청에 '최적의' 서버를 결정한다.클라이언트가 해당 ISP에 설치된 CDN 서버 랙에 있는 로컬 ISP를 사용하고 있고, 이 랙에 요청된 사본이 있는 경우, 일반적으로 이 랙 서버가 선택된다. 그렇지 않은 경우 근처에 있는 IXP 서버가 선택된다.
2. 일단 넷플릭스가 콘텐츠를 전달할 CDN 서버를 결정하면, 클라이언트는 요청된 영화의 다른 버전에 대한 URL을 가진 manifest file과 특정 서버의 IP 주소를 보낸다.
3. 그러면 클라이언트와 해당 CDN 서버는 독점 버전의 DASH를 이용하여 직접 상호작용한다.
   클라이언트는 HTTP GET 요청 메시지의 byte-range 헤더를 이용해, 각기 다른 버전의 비디오 조각 단위 데이터를 요청할 수 있다. 클라이언트가 비디오 조각 단위 데이터를 다운로드하는 동안 수신 처리율을 측정하고, 전송률 결정 알고리즘을 이용해 다음에 요청할 비디오 조각 단위 데이터의 품질을 결정한다.