Chapter 2-6(기말고사 범위)

video streaming and content distribution networks

 

유튜브나 넷플릭스 : 7500만명씩 접속함 -> 서버 과부하 어케 해결?

-> 분산, 어플리케이션 레벨에서 만들어서 서비스를 하겠다!!

 

video 

이미지의 연속

일정한 속도로 연속적인 이미지가 계속 출력 

이 때 각각의 이미지들은 픽셀로 구성(이미지를 2d array로 봤을 때 각각의 array하나하나를 픽셀로봄)

픽셀은 휘도와 색상을 나타내는 여러 비트들로 인코딩 

중요한 특징 : 압축될 수 있다

비디오 품질과 비트 전송률은 서로 반비례(trading off)

 

coding :  이미지 안에 있는 중복되는특성을 씀 or 이미지들간의 중복성을 쓴다

사용하는 비트수(이미지를 표현하는데 있어서 크기)를줄여서 이미지를 encoding하려고 redundancy를 사용

spatial : 이미지 안의 중복성을 쓰는것(위치), 비디오 프레임의 공간적인 측면, 보라.20(보라보라보라보라...보라보라 이렇게 안하고)

temporal : 이미지들간의 중복성을 쓰는 것 (시간), 비디오 프레임의 시간적인 측면, i번째 이미지와 i+1번째 이미지는 대부분 비슷할것임, 앞부분 이미지가 있다면 뒷부분 이미지를 쓸 필요가 없음 차이가 나는 부분만 쓰는 방식 

 

CBR(constant bit rate) : 비디오의 인코딩 rate이 똑같이 고정(video encoding rate fixed), 아무런 기법도 쓰지 않음, 데이터 손실x, 

VBR(variable bit rate) : spatial과 temporal의 coding 방법을 써서 encoding rate을 바꾸는 것

 

내가 영상을 어떻게 encoding하느냐에 따라서 encoding rate이 달라지고 

encoding rate이 달라진다는 것은 -> 이 영상을 재생하는데 있어서 필요한 데이터 사이즈가 바뀐다는 것이고

-> 내가 이영상을 보기위해 필요한 메모리수??밴디스?? 가  달라진다 -> 다운로드 속도가 달라진다 

(동일한 영상이지만 encoding만 바꿔주면 내 네트워크환경 좋을때, 다운로드 속도 빵빵할 때 고화질로 볼 수 있고, 인터넷 속도 안좋으면 저화질로도 볼 수 있다)

 

 

 

 

 

 

Streaming stored video 

유튜브는(streaming이 아닌이상) 영상들은 다 video server에 저장되어 있다 

1. video가 녹화됨 

2. video가 서버로 들어감

3. 서버에서 일정한 processing을 통해서 network으로 전송함(전송하는 속도도 encoding된 속도와 유사한 속도로 전송됨)

4. 이 전송된게 network delay 시간 동안 시간 이후에 receiver에 도착

5. 리시버에서 일정한 속도로 플레이됨 

(이상적인 경우, 실제로는 network delay가 굉장히 다양)

문제점

1. 버퍼링

2. 사용자들이 보다가 일시정지시키거나 앞으로 앞당기거나 뒤로 가거나(앞으로 앞당기려면 그 앞까지 영상오려면 건너뛴 부분만큼의 영상이 전송되어야하니까 시간이 오래걸림, 뒤로 가도 뒤에내용 재전송해야함)

 

 

 

 

 

 

 

 

 

 

 

 

 

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

1. 사용자가 비디오 시청 원하면 클라이언트는 서버에게 TCP 연결을 설립하고 해당 URL에 대한 HTTP GET요청 발생시킴

2. 서버가 기본 네트워크 프로토콜 및 트래픽 조건이 허용되는 대로 HTTP 응답 메시지 내에서 비디오 파일을 전송

3. 클라이언트 쪽에서는 애플리케이션 버퍼에 전송된 바이트가 저장됨

4. 이 버퍼의 바이트 수가 미리 정해진 임곗값(threshold)을 초과하면 클라이언트 애플리케이션이 재생을 시작

-> 특히 스트리밍 비디오 애플리케이션은 클라이언트 애플리케이션 버퍼에서 주기적으로 비디오 프레임을 가져와서 프레임을 압축해제한 다음 -> 사용자의 화면에 표시함

=> 비디오 스트리밍 애플리케이션은 비디오의 후반 부분에 해당하는 프레임을 수신하고 버퍼링할 때 비디오를 표시

 

 

 

 

 

 

 

DASH(Dynamic, Adaptive Streaming over HTTP)

 

 

배경 : HTTP스트리밍의 문제점이 있다, 모든 클라이언트가 그들 사이의 가용 대역폭 차이에도 불구하고 똑같의 인코딩된 비디오를 전송받는다는 점 !!!!!!!!!!!

-> 가용 대역폭의 차이는 각기 다른 클라이언트들 간에 존재할 뿐만 아니라 동일한 클라이언트에서도 시간에 따라 차이가 발생 

 

해결 => 새로운 형태의 HTTP 기반 스트리밍인 DASH

 

정의 : 비디오 및 오디오 콘텐츠를 인터넷을 통해 스트리밍하는 데 사용되는 표준화된 프로토콜

(기본적으로 영상을 요청할때 HTTP프로토콜을 이용해서 보냄)

(멀티미디어 재생의 표준)

 

-비디오는 여러 가지 버전으로 인코딩됨, 각 버전은 비트율과 품질 수준이 서로 다름

-클라이언트는 동적으로 서로 다른 버전의 비디오를 몇 초 분량의 길이를 갖는 비디오 청크 단위로 요청 

-가용 대역폭이 충분할 때 : 높은 비트율의 비디오 버전 요청

-가용 대역폭이 적을 때 : 낮은 비트율의 비디오 버전 요청

-클라이언트는 HTTP GET요청을 이용해 다른 버전의 비디오 조각을 매번 선택함 

 

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

-클라이언트에게 세션 유지 중에 시간에 따라 변화하는 종단 간 가용 대역폭에 적응할 수 있도록 허용

ㄴ> 이동 사용자에게 중요, 이동 중에 접속하는 기지국의 상황에 따라 가용 대역폭이 자주 변화하기 때문

-클라이언트가 서로 다른 품질 수준을 자유롭게 변화시킬 수 있도록 허용 

 

Manifest file : 각 비디오 버전은 HTTP서버에 서로 다른 URL을 가지고 저장하는데, HTTP서버는 비트율에 따른 각 버전의 URL을 제공하는 매니페스트 파일을 갖고 있음

1. 클라이언트는 먼저 매니페스트 파일 요청, 서버에서 제공되는 다양한 버전에 대해 알게됨

2. 이후 클라이언트는 매번 원하는 버전의 비디오 조각 단위 데이터를 선택하여 HTTP GET요청 메시지에 URL과 byte-range를 지정하여 요청 

3. 청크 다운로드 하는 동안 클라이언트는 측정된 수신 대역폭과 비트율 결정 알고리즘을 이용해 다음 선택 청크 버전 결정

크다면 고품질 선택, 작다면 낮은 품질 선택

=> 서로 다른 품질 자유롭게 변화 가능 

 

 

--------------------------------------------------------------------------------------------------------------------------------------------- 

일정량의 버퍼가 확보되면 그제서야 플레이가 시작, 버퍼가 줄지 않는다면 추가로 데이터 요청 X

(추가로 요청? 기본적으로 클라이언트가 영상 처음 재생할때 첫시작에 대한 영상 데이터 요청하면 서버가 그 부분을 준다)

서버는 온전한 비디오를 청크 단위로 쪼갬, 클라이언트는 해당 청크를 요청하는 것임(HTTP로 요청하고 청크 받음) 

서버는 하나의 청크를 서로 다른 rate으로 encoding한 버전을 여러개 가지고있음(고화질버전, 저화질버전 등)

왜? -> 클라이언트가 요청할 때 서로 다른 네트워크 환경에서 다운로드 속도가 다 다르니까 

그리고 이 다양한 청크를 하나의 서버만 가지고 있지 않음, 다른 서버들도 나눠서 가지고 있음

-> 그럼 그 영상이 어디 서버에 있는지 어떻게암??

-> 주관이 되는 서버는 알아야함 : manifest file (서로 다른 청크들이 어디에 저장되어 있는지 URL을 제공)

클라이언트 입장에서 : 주기적으로 서버로부터 요청, 다운받는 속도 측정, 속도 안좋아지면 요청하는걸 낮춤 더 낮은 화질로 요청함, 다운 속도는 낮아졌지만 내가 받아야 하는 파일 사이즈도 작아져서 시간내로 받을 수 있다

=> 주기적으로 bandwidth를 측정함 -> 측정 결과로 manifest요청 -> 그중의 하나의 청크 요청(현재 주어진 다운로드속도(bandwidth)를 내가 유지가능한 다운로드 속도의 maximum만큼의 bps의 속도의 최고 화질로 요청), 시간 단위로 서로 다른 시점마다 서로다른 coding을 선택(왜? 내 네트워크 환경이 계속 바뀌니까, 환경에 맞춰서 동영상 화질을 결정)

클라이언트 :

1. 언제 청크를 요청하지? -> 버퍼가 소진되기 전, 소진되지 않거나, 오버플로우(필요이상으로 버퍼보다 불필요하게 다운)만 아니면 다운을 받지 않겠다 => 버퍼가 기준량보다 적어지면 요청하겠다 

2. 어떤 encoding rate를 요청하지? -> 내가 이용가능한 bandwidth에 한해서 최대치를 요청, 무엇을? 내가 감당할 수 있는만큼의 maximum

3. 어디서 요청하지? -> 언제, 어떤걸 요청할건지 나오면 그 청크가 어디에 있는지는 manifest를 통해 알 수 있다, 그 manifest에 적힌 URL의 청크를 요청 

근데!!!!!!!!!!!!! 그 rate로 청크가 해당하는게 하나만 존재하지는않음 그 URL이 하나가 아님!!! , 여러군데 있을 수 있음 그럼 어디에 있는걸 들고옴? -> 1. 클라이언트로부터 가까운곳의 서버? 2. bandwidth가 좋은서버? 이건 선택의 문제 

---------------------------------------------------------------------------------------------------------------------------------------------

 

 

 

 

 

 

 

CDNs (Content distribution networks)

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

-> 문제점

1. 클라이언트가 데이터 센터로부터 지역적으로 먼 지점에 있는 경우 -> 서버로부터 클라이언트로의 패킷 경로는 많은 다양한 통신 링크와 ISP를 거쳐 가게 되는데, 이러힌 ISP는 각기 다른 대륙에 위치할 수도 있다. -> 이 링크들 중 하나라도 비디오 소비율보다 낮은 전송용량을 갖는다면 종단 간 처리율이 낮아지고 결국 사용자는 짜증스러운 화면 정지현상 겪게됨 => 종단 간 경로 길이가 길어진수록 이러한 현상 증가 

2. 인기 있는 비디오는 같은 통신 링크를 통해 여러 번 반복적으로 전송될 것, 네트워크 대역폭의 낭비, 인터넷 비디오 회사는 회선을 제공하는 ISP들에게 동일한 바이트를 전송하는 것에 대해 중복 비용 지불 

3. 한 번의 장애 -> 전체 서비스 중단될 수 있다

 

sol1) single, large 메가서버

서버하나 죽으면 서비스도 죽음(3번)

한쪽에 요청몰리면 congestion발생 (2번)

하필 서버가 미국에 있음 오래걸림 (1번)

그 서버에 몰리는데 사람들이 동일 파일 요청함, 같은 copies 여러번 보내야함 낭비임 

=> 해결못함 

 

sol2) CDN

다수의 지점에 분산된 서버들을 운영, 비디오 및 다른 형태의 웹 콘텐트 데이터의 복사본을 이러한 분산 서버에 저장 

필요한 청크를 여러군데에 퍼뜨려놓자! 지리적으로 여러군데 퍼뜨려 놓자

동일한 video의 동일한 청크를 서로 똑같은 encoding rate를 가진애를 퍼뜨려 놓자

서버 하나 죽음? ㄱㅊ~

한쪽으로 몰리지 않음 지리적으로 분산되어 있으니까

long path안나옴 아시아면 아시아 서버에 가면 되니까!

multiple copies가 나가긴 하지만 하나가 감당하는거보다 6개가 감당하면 1/6로 줄어드니까  부하 감소 

 

=> dash, cdn쓰면 아까 문제 해결됨 

cdn도 두가지 방법이 있음 -> 비디오 서버들을 어디에 설치할까?

 

CDN은 일반적으로 서버의 위치에 대해 두가지 중 하나는 채용한다 

1. enter deep : 서버들을 많은 access networks에 설치하겠다 즉, 유저들 근처에 놓겠다, 수천개의 지점에 서버 클러스터를 구축, ISP의 접속 네트워크로 깊숙이 들어가는 것  

작은 슈퍼 여러개 

목적 : 서버를 최대한 사용자 가까이에 위치시켜 사용자와 CDN 서버 사이의 링크 및 라우터 수를 줄이고, 사용자가 경험하는 지연 시간 및 처리율을 개선하는 것 

문제점 : 고도로 분산된 설계로 인해 서버 클러스터를 유지 관리하는 비용이 커짐

 

2. bring home : 작은 숫자를 설치하겠다 대신, 숫자는 작지만 larger cluster, 대형 마트 몇개정도

좀 더 적은 수의 핵심 지점에 큰 규모의 서버 클러스터를 구축하여 ISP를 Home으로 가져오는 개념

접속 ISP에 연결하는 대신, 이러한 CDN들은 일반적으로 그들의 클러스터를 인터넷 교환 지점(IXP)에 배치됨

문제점 : 클러스터 유지 및 관리 비용이 줄어드는 대신에 사용자가 느끼는 지연 시간과 처리율은 상대적으로 나빠짐 

 

CND은 각 클러스터마다 모든 비디오의 복사본을 전부 유지할 필요는 없다

=> 어떤 비디오는 인기가 거의 없거나, 일부 특정 국가에서만 인기가 있을 수 있기 때문

 

-푸쉬(push) 방식이 아닌 풀(pull) 방식을 사용 

-어떤 사용자가 지역 클러스터에 없는 비디오를 요청 -> 해당 비디오를 중앙 서버나 다른 클러스터로부터 전송받아 사용자에세 서비스하는 동시에 복사본을 만들어 저장

(공간 가득차면 자주 사용되지 않는 비디오 데이터는 삭제됨)

 

 

 

 

CND 동작

 

사용자 호스트의 웹 브라우저가 URL을 지정함으로써 특정 비디오의 재생을 요청하면 CDN은 그 요청을 가로채 1. 그 시점에서 클라이언트에게 가장 적당한 CDN클러스터를 선택하고, 2. 클라리언트의 요청을 해당 클러스터의 서버로 연결한다. 

 

NetCinema라는 콘텐츠 제공자가 KingCDN이라는 CDN업체를 이용해 비디오를 고객에게 분배한다 가정

 

 

1. 사용자가 NetCinema의 웹 페이지 방문

2. 사용자가 http://video.netcinema.com/slkfwe 링크를 클릭하면, 사용자의 호스트는 video.netcinema.com에 대한 DNS질의를 보낸다

3. 사용자가 지역 DNS서버는 호스트 이름의 'video'문자열을 감지하고는 해당 질의를 NetCinema의 책임 DNS서버로 전달한다. 책임 서버는 해당 질의를 KingCDN으로 연결하기 위해 IP주소 대신에 KingCDN의 호스트 이름(a1105.kingcdn.com)을 지역 DNS서버에게 알려준다.

4. 이 시점부터 DNS질의는 KingCDN의 사설 DNS구조로 들어가게 된다. 사용자의 지역 DNS서버는 a1105.kingcdn.com에 대한 두번째 질의를 보내고 이는 KingCDN의 DNS에 의해 KingCDN 콘텐츠 서버의 IP주소로 변환되어 지역 DNS서버에게 응답된다. 이 때 클라이언트가 콘텐츠를 전송받게 될 서버가 결정된다

5. 로컬DNS서버는 콘텐츠를 제공할 CDN서버의 IP주소를 사용자 호스트에게 알려준다

6. 클라이언트는 KingCDN 서버의 IP주소를 얻고 나면, 해당 IP주소로 직접 TCP연결을 설정하고, 비디오에 대한 HTTP GET요청을 전송한다. 만약 DASH가 사용된다면 서버는 먼저 각기 다른 버전의 비디오에 대한 URL 목록을 포함하는 매니페스트 파일을 클라이언트에게 전송하고 클라이언트는 동적으로 각기 다른 버전의 비디오 조각 단위 데이터를 선택할 수 있다

 

 

 

 

 

 

 

 

 

 

 

 

 

 

클러스터 선택 정책

CDN 구축의 핵심 중 하나

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

-CDN은 각기 고유한 클러스터 선택 정책 사용함

1. 지리적으로 가장 가까운 클러스터를 할당

대부분의 클라이언트를 대상으로 상당히 잘 동작함

BUT 일부 클라이언트에게는 잘 동작하기 않음

-> 지리적으로는 가장 가까운 클러스터가 네트워크 경로의 길이 홉(hop)의 수에 따라 가장 가까운 클러스터가 아닐 수 있기 때문 

-> DNS 기반 방법에 내재된 문제로서, 일부 사용자는 상히 멀리있는 DNS서버를 지역DNS서버로 사용하도록 설정할 수 있다. 이 경우 지역 DNS서버의 IP주소를 기반으로 선택한 클러스터는 사용자 호스트로부터 멀리위치하게 됨, 인터넷 경로의 지연이나 가용 대역폭의 변화 등은 무시하고 항상 같은 클러스터를 클라이언트에게 할당하게 됨

 

현재 네트워크 트래픽 상황을 반영한 최선의 클러스터를 선택하기위해 CDN은 주기적으로 클러스터와 클라이언트 간의 지연 및 손실 성능에 대한 실시간 측정을 수행함

 

 

 

사례연구 : 넷플릭스

넷플릭스 비디오 배포 두 가지

1. 아마존 클라우드

2. 자체 CDN 인프라

 

웹사이트(및 백엔드 데이터베이스)는 아마존 서버 안에 있는 아마존 클라우드에서 모든것이 실행

아마존 클라우드가 처리하는 중요한 기능

1. 콘텐츠 수집

넷플릭스는 고객들에게 비디오를 분배하기 전에 먼저 영화를 수집하고 처리함

영화의 스튜디오 마스터 버전을 받아서 아마존 클라우드 시스템의 호스트에 업로드함

 

2. 콘텐츠 처리

아마존 클라우드 시스템의 기기에서는 데스크톱 컴퓨터, 스마트폰, TV에 연결된 게임 콘설 등 고객들의 다양한 플레이어 기기 사양에 적합하도록 각 영화의 여러 가지 형식의 비디오 생성

DASH를 이용한 HTTP 적응적 스트리밍 서비스를 위해 각 형식별로 다양한 비트율의 여러 가지 버전 생성

 

3. CDN으로의 버전 업로드

영화의 다양한 버전이 생성되면 아마존 클라우드 시스템의 호스트는 이러한 버전을 CDN으로 업로드 할수있음

 

넷플릭스는 자체 CDN을 구축하기 위해 IXP 및 거주용 ISP 자체에서 서버랙을 설치함 

각각의 랙 서버에는 10 Gbps 이더넷 포트와 100테라바이트 이상의 스토리지가 있음

랙에 있는 서버의 수는 다양함

IXP 설치에는 수십 개의 서버와 DASH를 지원하는 여러 버전의 비디오를 포함한 전체 스트리밍 비디오 라이브러리가 포함되어 있다

풀 캐싱을 사용하여 IXP및 ISP의 CDN서버를 채운다

대신 사용량이 적은 시간에 비디오를 CDN 서버에 푸시하여 배포함 

전체 라이브러리를 보유할 수 없는 위치의 경우 매일매일 가장 많이 결정되는 비디오만 푸시함

 

 

-영화 전송에 관련한 서버와 클라이언트간의 동작

 

1. 사용자가 재생할 영화를 선택하면

2. 아마존 클라우드에서 실행 중인 넷플릭스 소프트웨어가 먼저 해당 영화 사본을 갖고 있는 CDN서버를 결정

    영화가 있는 서버중에서 소프트웨어는 클라이언트 요청에 '최적의' 서버를 결정함

    클라이언트가 해당 ISP에 설치된 CDN 서버 랙에 있는 로컬 ISP를 사용하고 있고, 이 랙에 요청된 사본이        있는 경우 일반적으로 이 랙 서버가 선택됨 그렇지 않은 경우 근처에 있는 IXP서버가 선택됨

3. 넷플릭스가 콘텐츠를 전달할 CDN 서버를 결정하면 클라이언트는 요청된 영화의 다른 버전에 대한 URL을 가진 매니페스트 파일과 특정 서버의 IP주소를 보낸다 

4. 클라이언트와 해당 CDN서버는 독점 버전의 DASH를 이용하여 직접 상호작용함 

 

비디오만 배포하는 자체 CDN을 사용하고 있다

특정 클라이언트를 CDN 서버에 연결하기 위해 DNS 리다이렉션을 사용할 필요 없다

대신 아마존 클라우드에서 실행되는 것처럼 넷플릭스 소프트웨어는 클라이언트에게 특정 CDN 서버를 사용하도록 알려줌

넷플릭스 CDN은 풀캐싱보다 푸시 캐싱을 사용한다 

콘텐츠는 캐시 미스 중에 동적으로 사용되는 것이 아니라 사용량이 적은 시간 중 예약된 시간에 서버에 푸시