해당 포스팅은 공부 목적으로 작성된 포스팅입니다. 왜곡된 내용이 포함되어 있을 수 있습니다.
Netflix와 YouTube, Amazon Prime과 같은 스트리밍 서비스가 전체 인터넷 트래픽중 80%를 차지한다고 한다. 이러한 스트리밍 버스가 어떻게 동작하는지 알아보자.
2.6.1 Internet Video
저장 스트리밍 비디오 서비스들은 사전에 녹화된 비디오이다. user가 server에 요청하면 video를 건네주는 방식이다. 현재의 많은 internet 회사는 스트리밍을 지원하고 있다.
비디오는 image의 일련의 순서이다.(1초에 24,30 장) 이미지 압축은 상당히 중요한 특징인데, video quality에 직결되기 때문이다. 오늘날 압축 알고리즘은 비디오를 더 높은 quality로 원하는 속도로 압축할 수 있다.
네트워크 관점에서 비디오의 가장 중요한 특징은 높은 비트 전송속도이다. 압축된 비디오는 100 kps(low-quality) - 4 Mbps(streaming high-definition) 속도를 가진다. (quality가 낮으면 더 가벼운거 아닌가? -> 가벼울수록 속도가 빠르지 않아도 된다?) 이러한 비디오는 높은 traffic과 storage를 필요로한다.(2 Mbps의 67분 길이의 video는 1 gb 의 storage와 traffic을 필요로한다.) streaming의 가장 중요한 성능 척도는 평균 end-to-end throughput이다.
하나의 비디오에 대해서 여러 압축을 해볼 수 도 있는데, 300kbps, 1 Mbps, 3 Mbps 3가지 버전에 대해서 user는 현재 bancwidth에 맞는 비디오를 볼 수 있다. 3 Mbps의 비디오를 고른 user는 높은 internet connection을 가졌을 것이고 3G smartphone 사용 유저는 300 kbps 버전을 볼것 이다.
2.6.2 HTTP Streaming and DASH
HTTP streaming에서 비디오는 file의 형태로 URL를 가지는 형태로 저장된다. user가 비디오를 보기 위해서 TCP connectiond을 통해 URL에 GET 요청을 보낸다. server는 video file을 HTTP response message에 보낸다. client는 client application buffer에 byte들이 쌓이게 되고, threshold값을 넘어가게 되면 application에서 스트리밍을 시작한다. application은 주기적으로 video frame을 압축해제하여 screen에 보여준다. client에 적합한 bandwidth가 있음에도 불구하고, 모든 client는 동일한 video를 받게 되는데, DASH(Dynamic Adaptive Streaming)이라는 새로운 streaming 기술이 등장하게 되었다. DASH에서 video는 다른 전송 속도를 가진 여러 버전으로 인코딩된다. client는 video segment를 요청하게되고 이때 bandwidth에 알맞는 버전을 요청하게 된다. DASH는 client마다 다른 streaming 속도를 제공한다. DASH는 client의 end-to-end bandwidth가 변경되도 적응할 수 있게된다.
DASH와 함께, 각각의 video는 HTTP server에 저장되게 되고, 서로 다른 URL를 가지게 된다. HTTP server 는 비트 전송 속도에 따른 URL을 제공하는 manifest file을 가지게 된다. client는 처음에 manifest file에 요청하여 다양한 버젼을 알게 된다. 이후 client는 하나의 chuck를 선택하여 가져오게 된다. chuck를 받아오는 동안 client는 received bandwidth를 측정하여 다음 request에 선택할 chunk을 선택할 결정 알고리즘을 실행한다.
2.6.3 Content Distribution Networks
많은 internet 회사는 분산 스트리밍을 지원하고 있다. 지구 전체 지역에 스트리밍하면서 지속적인 재생과 높은 성능은 상당히 어려운 일이다.
internet 회사들은 하나의 거대한 데이터 센터를 통해 모든 video를 data center에서 관리하도록 하는데, 이러한 구조는 client가 data center로 부터 멀경우가 문제가 발생한다. 예를들어 end-to-end throughput이 consumption 속도보다 느린 경우 user에게 delay가 발생한다. 이러한 경우는 end-to-end path가 커질 경우 발생할 수 있는 문제점이다, 두번째로 유명한 video는 어러번 보내지게 되는데, internet video는 매번 동일한 bytes를 ISP에게 제공하게 된다. 세번째로 하나의 data center의 경우, data center에서 문제가 발생하면 모든 video streaming이 중단될 수 있다.
ㄴ위와 같은 상황을 방지하고자 video-streaming 회사는 분산 환경을 위해 CDNs(Content Distribution Networks)을 사용하고 있다. CDN 관리 server는 분산된 위치에서 video를 저장하고, user에게 가장 좋은 video를 제공할 CDN을 연결 시켜둔다. CDN는 private CDN형태로 존재한다. 이러한 third-party CDN은 분산환경을 제공한다. CDN은 다음 두가지 server 배치 철학중 하나를 채택한다.
- Enter Deep: 지구 전체의 ISP에 server cluster를 구축하여 provider에게 access network를 제공하는 것. user간 가까워져 user와 CDN사이의 links와 router를 줄이는 것을 목표로한다. cluster를 유지하고 관리하는 것이 어렵니다
- Bring Home: ISP 에 더 적은 site에 large cluster를 구축하는 것,CDN을 ISP 대신 IXP에 두고, 유지 보수 overhead를 낮춘다.
cluster가 구춘되면 CDN은 cluster를 통해 content를 복사한다. CDN은 cluster에 video를 push 하지않고 pull 한다(?) client가 cluster가 가지고 있지 않은 video를 요청하여 cluster는 다른 cluste에게 video를 검색하고, client에게 streaming함과 동시에 저장한다. cluster가 모두 차면 가장 요청이 적은 video를 삭제한다.
brower host가 특정video를 검색하면 CDN은 request를 가로채, client에게 적절한 CDN server cluster를 결정하고, client의 request를 해당 cluster에게 redirct한다.
대부분의 CDNs은 DNS를 이용하여 request를 intercept하고 redirct한다.
- user가 NetCinema가 접속한다.
- user가 video URL를 클릭하면 user host는 DNS를 netcinema에게 보낸다.
- user의 local DNS server는 DNS query를 video와 관련된 authoritative DNS server에 보내고, IP 주소를 반환하는 대신 DNS server는 LCDN domain를 return 한다.
- DNS query CDN server로 보내져, CDN의 private DNS로 보내진다. user LDNS은 CDN content server의 ip address를 return 받는다.
- LDNS는 CDN node에게 ip address 를 forward한다.
- client가 CDN ip address를 받고, TCP connectiond을 통히 video를 받는다. 만약 DASH를 사용한다면 clinet는 manifest file를 먼저 받아 client는 알맞는 version을 선택하게 된다.
cluster selection strategies 은CDN에서의 중요한 기술로 client와 server cluster, data center를 결정한다. CDN은 client의 LDNS의 ip address를 DNS look up 하면서 알게된다. ip address를 얻은 후, CDN은 ip에 알맞는 적절한 cluster를 결정해야한다. CDN은 독점 cluster 결정 전략을 사용한다.
첫번째 전략은 geographically closest 한 cluster를 주는 것이다. 각각의 LDNS ip address는 위치정보를 가지고 있다. DNS request를 LDNS가 받으면 CDN은 지리적으로 가장 가까운 cluster를 선택한다. 이는 효과적이지만 지리적으로 가장 가까운 cluster가 network path으 측면에서 가장 closet 한 cluste가 아닐 수 있다. 또한 LDNS가 client와 멀리 떨어져 있는 경우, 효과적이지 못하다(LDNS와 client를 같다고 가정하고 보기 때문에). internet path에 따른 bandwidth도 고려하지 않은 전략이다.
가장 좋은 cluster를 고리기 위해 CDNs은 delay, loss performance를 주기적으로 측정할 수 있다. CDNs은 cluser에게 ping을 전달할 수 있다. 이 접근은 많은 LDNS가 이러한 probe(ping)에 응답하지 않도록 설정되어 있다(보안땜에 그런가?)
2.6.4 Case Studies: Netflix and YouTube
이러한 streaming stored video의 사례로 Netflix와 Youtube가 있다. 각각 system을 살펴보면서, 위와 같이 언급된 문제를 어떻게 해결하였는지 살펴보자
Netflix
Netflix video는 Amzon cloud와 자체 private CDN으로 분산 환경을 지원했다. Netflix은 user 등록, login, 구독과 같은 기능을 제공하는 web site가 존재한다. 이러한 website는 Amazon cloud의 Amazon server에서 구동된다. Amazon cloud은 다음 기능을 다루고 있다.
- Content ingestion: Netflix는 영화사에게 영화를 받아 Amazon cloud host에 업로드한다.
- Content processing: Amazon cloud는 영화 각각에 대해서 다양한 format을 제공하여 client의 다양한 형태를 대처한다. 이러한 다양한 format은 bit rate에 따라 다양한 version으로 생성되어 DASH를 제공한다.
- Uploading versions to its CDN: 영화의 모든 버전에 대해서 Amzaon cloud은 CDN에 upload한다.
Netflix가 video streaming 처음 지원할 2007년에는 third-party CDN 회사들이 video content를 지원했다. 이후에 Netflix는 자체 private CDN을 구축하여 video content를 제공한다. 자체 CDN을 구축하기 위해 Netflix는 ISP아래 IXP rack를 설치하였고, 현재 200개 이상의 IXP에 server rack을 가지고 있다. netflix rack을 수용한 수백개의 ISP가 있고 각각의 rack에는 10 Gbps의 Ethernet port와 100 Tb의 storage가 존재한다.IXP에는 Netflix streaming library가 존재하고, DASH를 위한 다양한 버전이 존재한다. Netflix의 CDN은 IXP, ISP에 대해서 pull caching을 사용하지 않고, 대신에 video를 CDN에 push한다. 해당 CDN은 모든 library를 가질 수 없기때문에 Netflix는 가장 유명한 video를 push 한다.(매일 순위가 정해진다.)
client가 video를 선택하면 netflix software는 어떤 CDN server가 video의 copy를 가지고 있는지 결정한다. 적합한 server를 선택하고, client은 해당 isp에 설치된 Netflix CDN rack의 ISP를 사용하고 있고 해당 rack에 video가 있는 경우 해당 server로 결정한 그렇지 않으면 근치의 IXP가 선택된다.
CDN이 결정되면 CDN에서 해당 ip addredd와 mainfest file를 client에게 보낸다. client와 CDN은 DASH를 통해 상호작용하게 된다. 이후에 앞서 말한 것 처럼 Netflix는 chunk를 보내고 client는 해당 chunk received throughput을 측정하면서 해당 chunk의 quality를 속도 결정 알고리즘을 통해 결정한다.
Netflix은 자체 CDN을 구현했다는 점에서 DNS을 통해 direct할 필요 없이 software에서 직접 CDN을 알려준다.
YouTube
YouTube은 세계에서 가장 큰 video sharing site이다. YouTube도 Netflix와 동일하게 수백개의 IXP와 ISP위치 서버 cluster를 설치했다. 그러나 Netflix와 달리 YouTube은 pull caching을 사용하여 DNS direct을 사용한다. YouTube은 client와 cluster간의 RTT가 가장적도록 cluster 결정 전략을 사용한다. 그러나 로드 밸런싱을 위해 때때로 먼거리의 cluster를 주기도 한다.
YouTube은 DASH와 같은 적용형 streaming을 제공하지 않는다. 재배치에 의한 리소스 낭비를 절약하기 위해 video가 prefetched되고 data를 전송한다.
YouTube은 업로드된 video를 YouTube video foramt으로 변경하고, 다양한 version을 만든다.
