[컴퓨터네트워크] video streaming and content 분산 프로그램

비디오 트래픽의 증가 속도

비디오 트래픽은 유뷰트와 넷플릭스의 인기로 많은 비율을 차지하고 있습니다. 사용자 수도 보면 유튜브는 거의 10억명 정도의 사용자, 넷플릭스도 7500만명 이상의 사용자들을 가지고 있는 것으로 보입니다.

 

이러한 비디오 스트리밍에서 중요한 문제가 여러가지가 있는데 첫번째 문제는 사용자 수가 엄청나게 많아졌을 때 어떻게 적절하게 다룰 것인가, 동시 사용자 수의 급격한 증가의 효과적 대처에 대한 문제 등이 있습니다. 

 

사용자들은 각각 가지고 있는 환경(대역폭. 디바이스, 유무선 등등)이 다릅니다. 이런 것을 적절하게 다루기 위해서 distributed, application-level의 infrastructure가 필요합니다.

 

비디오란?

일정한 속도로 실행되는 이미지들의 sequence, 연속된 이미지들을 비디오라고 얘기합니다.

 

디지털 이미지는 픽셀의 배열입니다. 여기서 각각의 픽셀은 비트들로 표현이 됩니다. 코딩이라고 하는 것을 이미지를 인코딩하기 위해서 부화를 줄이기 위해서 사용하는 것입니다. 

• spatial 코딩
• temporal코딩

CBR(Constant Bit Rate)

각각의 프레임을 균일한 용량으로 압축하는 것 

VBR(Variable Bit Rate)

각 프레임들의 차이를 분석해서 움직임이 적은 부분에서는 적은 용량, 많은 부분에서는 고용량으로 영상 내부에서의 일정하지 않은 방식으로 압축하는 것 

 

예시

• MPEG1 (CD-ROM) 1.5 Mbps
• MPEG2 (DVD) 3-6Mbps
• MPEG4 (often used internet 64kbps ~ 12Mbps)
• H.264( MPEG-4 part10, AVC)

스트리밍 저장 비디오

비디오 서버 - 인터넷 - 클라이언트

 

서버와 클라이언트의 대역폭은 시간이 지나면서 계속해서 변합니다. 서버에서 클라이언트의 대역폭이 변하고 패킷들이 전달될 때 loss될 수 있기 때문에 이것을 처리하고 지연이 발생할 수 있기 때문에 해결을 해주어야 합니다. 

 

이는 비디오 품질에 영향을 주는 것입니다. 

 

연속적인 재생 제한

재생 시간이 원래 재생 시간과 매치가 되어야 합니다. 인터넷 상에서 딜레이가 발생하면서 클라이언트 측과 맞추기가 쉽지 않기 때문에 일치시키기 위해서 연속적인 재생 제한 사양을 지키기 위해서 버퍼링을 하는 것입니다.

 

또 다른 해결해야 할 문제는 다양하게 있습니다. 

• 클라이언트 측의 상호작용 : 일시정지, 빠르게 되검거나, 점프하는 경우
• 비디오 패킷의 손실문제

버퍼링을 이용해서 constant bit rate video playout를 지원을 해주도록 합니다. 클라이언트의 버퍼링과 재생 지연을 적절하게 버퍼링을 통해서 재생 지연을 처리를 하는 것입니다.

 

스트리밍 비디오 프로토몰 : DASH

Dynamic, Adaptive Streaming over HTTP

 

서버

• 비디오 컨텐츠 파일을 여러개의 복수 조각으로 분할을 합니다.
• 각각의 chunk는 다른 레이트로 인코딩이 됩니다.
• 다른 레이트로 인코딩된 조각들은 다른 파일로 저장이 됩니다.
• 파일은 분산된 CDN 노드들에게 복제가 됩니다. 
• manifest file이 만들어집니다. 이는 각각 조각들에 대한 URL을 제공합니다.

CLIENT

• 서버로부터 비디오 파일에 대한 Chunk를 받으면서 대역폭을 측정합니다.
• 측정된 대역폭에 따라서 manifest 파일을 조회합니다.
• 현재 시점에 가장 적절한 coding rate의 chunk파일을 선택합니다.
• 해당 chunk파일 다른 서버로부터 가장 적절한 coding rate에 대한 파일을 선택합니다.

즉 DASH 프로토콜은 client측에 "intelligence"가 있는 형태입니다. 스스로 대역폭을 측정하면서 결정을 해야하는 방식으로 언제 chunk를 요청할 것인지, 그리고 enccoding rate의 어떤 것을 요청할 것인지, 어디에 chunk를 요청할 것인지 클라이언트가 적절한 encoded rate를 요청을 하게 됩니다.

 

Streaming video = encoding + DASH + playout buffering

 

컨텐츠 분산 네트워크

동시 사용자 수가 많을 때 해결하는 방법은?

 

1. 단일의 "mega-server" 구축

• single point of failure 문제
• 네트워크 혼잡이 서버로 집중
• 클라이언트마다 서버의 거리가 다름

여러가지 문제가 존재해서 확장성이 부족하다라는 단점이 있습니다.

 

2. CDN 

• 지리적으로 분산된 위치의 복수의 서버 두고서 복수개의 비디오 사본 저장 클라이언트에게 서비스
• enter deep : 많은 access entwork에 CDN server를 두는 법 : Akamai는 120개 국가에 24만개의 서버를 둔다.
• bring home : POP지점에 수십개의 서버를 두는 것 Limelight 대표적인 예시

CDN의 서비스 과정

넷플릭스가 MadMen이라는 비디오 파일을 저장하고 CDN으로  서비스한다고 가정을 해봅시다.

 

복제된 사본을 각각 서버에 저장을 할 것입니다. 사용자가 넷플릭스에서 해당 영화를 보고자 할 때 해당 영화를 클라이언트에게 manifest 제공하고 그 manifest파일을 참조해서 가장 가까운 CDN서버 혹은 가장 지연이 적은 CDN서버로부터 컨텐츠를 스트리밍 받아서 봅니다.

 

그러다가 콘텐츠를 스트리밍 하고 있는 도중에 네트워크 경로상에서 지연이 많이 발생한다면 다른 CDN서버로 경로를 변경해서 계속해서 스트리밍을 받습니다. 

 

OTT : "Over The Top"

 

CDN 컨텐츠 access의 구체적 설명

사용자 Bob이 netcinema라는 회사로부터 어떤 영화를 보고 싶을 때 url의 비디오를 요청해서 비디오 콘텐츠를 실시간으로 스트리밍 하는 과정을 간단하게 보면

1. Bob이 넷시네마사에 영화 비디오 컨텐츠를 선택해서 URL을 얻습니다.
2. 로컬 DNS 서버로 조회해서 해당 ip주소를 가져오는 과정을 실행합니다.
3. 넷시네마의 책임 네임 서버에 ip주소를 요청합니다.
4. 책임 DNS서버는 가장 적절한 위치의 CDN서버의 URL을 응답을 해줍니다.
5. 로컬 DNS서버는 해당 URL의 IP를 다시 얻기 위해서 KingCDN의 책임네임서버에게 IP주소를 요청합니다.
6. KING cdn가 ip주소를 응답해주면 실제 밥은 KingCDN서버에 접속해서 스트리밍으로 받아볼 수 있는 것입니다.

우리가 넷플릭스에서 영화를 감상하는 과정또한 간단하게 보면

1. 사용자가 넷플릭스에 계정을 얻음
2. 넷플릭스 영화 목록 중 원하는 영화 선택
3. 아마존 클라우드에 배치되어 있다면 원하는 컨텐츠를 선택하고
4. 넷플릭스는 사용자가 선택한 비디오에 대한 Manifest 파일을 응답
5. 사용자는 해당되는 Manifest파일을 이용하여 가장 적절한 CDN 서버로부터 스트리밍