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

참고도서: 컴퓨터 네트워킹 : 하향식 접근. 7판. James F. Kurose , Keith W.Ross 지음

인터넷 비디오

• 비디오 데이터는 결국 여러장의 이미지를 가지고 있는 데이터이다. 일반적으로는 초당 24~25장의 프레임(이미지)를 가지고 있다.
• 이런 비디오는 용량이 크기 때문에 여러 방법으로 이미지들을 압축해서 비디오의 용량을 줄이는 인코딩이 존재한다. 일반적으로 비슷한 지역의 픽셀들이 다시 등장하는 spatial 한 특성과 현 프레임에서 다음 프레임으로 갈 때 비슷한 색의 값을 가진 픽셀이 다시 사용되는 temporal 한 특성을 사용해서 비디오를 인코딩한다.
• 비디오를 인코딩하는 방식을 고정적으로 사용하는 것을 CBR(Constant Bit Rate) 라고 하고, spatial, temporal 한 정보를 이용해서 상황에 맞게 인코딩하는 방식을 VBR(Variable Bit Rate) 라고 한다.

HTTP 스트리밍

• 전통적인 스트리밍 서비스는 RTSP(Real-Time Streaming Protocol)으로 실시간으로 데이터를 서버에서 받아와 사용자에게 바로바로 보내주는 형태였다. 그러나 이런 방식은 한 서버에 여러 사용자가 몰리게 되는 문제가 있고 사용자도 서버에 부하가 걸리면서 영상을 제대로 시청하지 못하게되는 현상이 발생했다.
• 그래서 최근에는 HTTP 방식으로 비디오 데이터를 송수신하는 방법이 고안되었다.
• HTTP 방식은 일반적으로 사용자가 비디오를 요청하면 사용자는 서버와 TCP 연결을 설정하고 비디오 데이터를 받기 시작한다.
• 클라이언트는 어플리케이션 버퍼에 전달된 데이터의 바이트들을 저장하고 일정 바이트 이상 데이터가 모이면 화면을 재생하기 시작한다.
• 초기에는 TCP로 연결했을 때, 클리이언트의 한 번의 요청으로 전체 파일을 다운로드 하는 방법으로 구현되었으나 이런 방식은 사용자가 비디오를 다 시청하지 않고 종료할 경우에 TCP 연결이 끊어지게 되므로 처음부터 데이터를 다시 받아와야하는 문제가 있다.
• 이런 문제를 해결하기 위해 고안된 Progressive Downloading 방법은 파일을 Chunk 단위로 나누어두고 사용자가 비디오를 시청하는 중에 지속적으로 이 chunk를 다운로드 하는 방식으로 구현되어 있다.
• 여러가지 방법론이 제시됨에도 불구하고 HTTP 방식이 해결하지 못하는 문제는 모든 클라이언트들이 각각의 가용 대역폭의 차이와 상관없이 똑같이 인코딩된 파일을 제공받는 것이다.

Dynamic Adaptive Streaming over HTTP(DASH)

• DASH 는 HTTP 스트리밍 방식의 문제점을 해결하기 위해 개발 되었다.
• DASH는 서버가 한 비디오 파일이 여러 버전으로 인코딩된 파일을 준비해 둔다. 클라이언트는 자신의 가용 대역폭에 맞는 인코딩 비트율을 요청하고 서버는 해당 요청에 맞는 인코딩된 비디오를 송신해주는 방법이다.
• 이때 클라이언트는 파일을 자신의 가용 대역폭에 맞게 chunk 단위로 요청하므로 대역폭 상황에 맞게 동적으로 비디오의 비트율을 결정할 수 있다는 장점이 있다.
• 서버에는 여러 비트율로 인코딩된 파일이 존재하기 떄문에 이 비트율에 따른 각 비디오 버전의 URL 정보를 보관하고 있어야 할 필요가 있다. 이 맵핑정보를 가진 파일이 매니패스트(manifest) 파일이다.
• 클라이언트는 먼저 서버에 매니페스트 파일을 요청하고 받은 뒤에 자신이 원하는 버전의 비디오를 선택해서 HTTP GET 요청을 서버로 보내게 된다.
• 따라서 DASH는 클라이언트에게 많은 결정을 맡기게 되는 방식이다.

Content Distribution Networks(CDNs)

• 스트리밍 서비스를 운영하는 가장 쉬운 방법은 하나의 데이터 센터를 만들어서 모든 비디오를 보관한 뒤에 사용자에게 데이터를 보내주는 방식이다.

• 그러나 오늘날에는 수 많은 사용자가 비디오 데이터를 요청하면서 몇 가지 문제점들이 발생하게 된다.

  • 클라이언트가 데이터 센터로부터 물리적으로 먼 위치에 있는 경우에는 많은 수의 링크와 라우터를 거치게 되는데 이 때 하나의 링크라도 낮은 전송용량을 가지면 사용자가 비디오를 시청하기 어려운 환경이 된다.
  • 사용자가 직접 데이터센터로 데이터를 요청하기 때문에 인기있는 비디오의 경우에는 데이터센터가 동일한 데이터를 계속해서 전송하게 된다.
  • 데이터 센터에 장애가 생기면 모든 사용자가 비디오에 접근할 수 없게 된다.
• CDN은 다수의 위치에 분산된 서버들을 운영하고 데이터들의 복사본을 분산된 서버에 저장해둔다.

• CDN은 두 가지 운영철학 중 하나를 선택해서 운영하게 된다.

  • Enter Deep : 서버 클러스터를 전세계 곳곳의 access network 안에 구축해서 서버를 최대한 사용자에 가까이에 위치시키려는 방법이다. 하지만 분산된 서버의 설계로 인해 유지관리 비용이 크게 발생한다는 단점이 있다.
  • Bring Home : 서버 클러스터를 access network 주변에 구축해서 유지 및 관리가 용이하면서도 비용을 줄이는 방법이다. 그러나 Enter Deep 방식만큼 사용자에게 빠른 전송률을 제공하지는 않는다.
• CDN에는 모든 데이터의 복사본이 있을 필요는 없다. 어떤 비디오는 특정 지역에서만 인기가 있고 다른 지역에서는 잘 요청받지 않는 비디오라면, 인기가 없는 지역의 CDN에는 해당 비디오가 필요가 없다.

CDN 동작원리

• CDN은 다음과 같은 과정을 통해 비디오를 요청하고 송수신한다.

  • 사용자 호스트가 웹 브라우저에서 URL을 입력하여 비디오의 재생을 요청한다.
  • CDN은 해당 요청을 가로챈다.
  • CDN은 지금 시점에서 클라이언트에게 가장 잘 맞는 CDN 클러스터를 선택하고 클라이언트의 요청을 해당 클러스터의 서버로 연결시킨다.

OTT(Over The Top) Challenges

• OTT는 주로 스트리밍 데이터를 요청한 클라이언트에 직접적으로 제공하는 컨텐츠 제공 사업자를 의미한다.
• CDN에서 가장 중요한 부분은 OTT가 어떤 서버 클러스터에 데이터를 요청할 것인지에 대한 부분이다.

• 가장 단순하고 확실한 방법은 클라이언트와 물리적으로 가장 가까이에 있는 클러스터를 할당하는 것이다.

  • 하지만 일부 클라이언트에서는 자신의 로컬 DNS서버를 자신과 멀리 떨어진 DNS서버로 지정할 수도 있고, 지리적으로 가까운 DNS서버가 네트워크 hop 상에서도 가장 가깝다는 보장이 없다.

CDN Content Access

• Netflix 는 기본적으로 CDN을 사용하지만 동시에 manifest 파일을 사용하는 구조로 작동한다. Netflix는 다음과 같은 과정을 거쳐 비디오를 송수신한다.

  • 넷플릭스의 사용자가 넷플릭스의 아마존 클라우드에 비디오에 대하 요청을 보낸다.
  • 넷플리스의 아마존 클라우드는 manifest 파일을 응답으로 보내준다.
  • 넷플릭스는 여러개의 CDN 서버에 비디오에 대한 사본을 저장해두고 manifest 파일에는 이 주소가 저장되어있다.
  • 클라이언트는 manifest 파일에서 얻은 CDN 서버로 접근해서 데이터를 가져와 사용자에게 스트리밍해준다.
  • 넷플릭스는 DNS redirection 을 사용하지 않고, 국가마다 사용자들이 선호하는 데이터들의 사본을 우선적으로 저장하는 push caching 정책을 사용한다.

• Youtube 는 private CDN을 사용해서 사용자에게 비디오를 스트리밍한다.

  • 유투브는 DNS redirection 과 pull caching 정책을 사용한다.
  • 유투브는 load balancing 을 위해서 RTT가 가장 짧은 클러스터 서버를 선택하는 정책을 사용한다.
• Kankan 은 p2p를 기반으로 하지만 p2p의 네트워크가 사용자를 모두 감당하기 어려우면 CDN을 함께 사용하는 정책을 사용한다.