[컴퓨터 네트워크]-Application layer_Video Streaming and CDNs

저번 글에서는 Application 계층중 P2P를 사용하는 BitTorrent에 대해서 정리해보았다. 이번에는 Video Streaming과 CDN에 대해서 알아보고 정리해보려고 한다.

---

1. Video

 비디오 스트리밍을 생각하면, Netflix, Youtue, Amazon Prime 등 OTT를 떠올리는 사람들이 많을 것이다. 실제로, 이 회사들은 ISP traffic의 80%나 차지한다고 한다. Internet bandwidth의  주 소비자이다. 

 

 그렇다면 이렇게 수요 많은 서비스를 어떻게 잘 이용하게 만들까가 주 과제이다. 즉, 확장성(heterogeneity)에 대해서 신경을 써야 된다는 것이다. 사용자들은 다양한 device를 가지고 있고, 한 쪽은 bandwidth가 엄청나게 좋거나 한 쪽은 엄청나게 안 좋을 수 있다. device마다 혹은 사용자마다 인터넷, 디바이스 파워 등 상황이 다 다르기 때문에 확장성을 제공하기가 매우 힘들다.

 

 이에 대한 해결책은 새로운 레벨의 인프라가 필요하다는 것인데 이게 바로 CDN(=Content Divde Network)이다. CDN에 대해서는 뒤에 더 자세하게 정리해보고 지금은 Video가 어떻게 제공되는지 먼저 알아보자.

 

 video는 연속된 이미지가 일정한 속도로 displayed 되는 것이다. 이 때, 이 연속된 이미지들은 digital image로 구성되어 있다. digital image는 pixel들의 배열인데, 각 픽셀들은 bit로 이루어져 있다. 

 

 

 위 그림은 연속된 이미지이다. 그렇지만 이미지에 별 차이도 없고, 중복된 부분도 많다. 

 

 이 때, 중요한 개념이 이미지 전송에 대해 coding을 할 때, 중복성을 얼마나 효율적으로 고려해서 이미지 전송을 하냐이다. 두 가지의 중복을 고려하면 되는데, 그 두 가지는 바로

• spatial: 이미지 내의 중복(위 frame i의 하늘 색깔)
• temporal: 이미지와 다음 이미지 사이의 중복(frame i와 frame i+1의 중복되는 부분)

이다. 즉, 이런 두 가지의 중복을 고려해 보내려는 정보의 양을 줄여 bandwidth 사용량을 줄이는 것이 video 이미지 전송에 대한 코딩의 목표이다.

 

-Video Encoding

 그럼 이런 비디오는 어떻게 Encoding을 할까? 그 Encoding 기법은 2가지가 있는데, CBR과 VBR이다. 차례대로 알아보자.

• CBR(Constant Bit Rate): 일정한 속도로 처리하기(비효율이 발생할 수 있음)
• VBR(Variable Bit Rate): spatial, temporal 고려한 코딩에 따라 처리하는 속도도 변경하며 처리하기

 여기서, VBR의 예시는, MPEG인데

• MPEG 1: CD-ROM에서 사용하던 인코딩(1.5Mbps 대역폭)
• MPEG 2: DVD에서 사용하던 인코딩(3-6Mbps 대역폭)
• MPEG 4: 인터넷에서 사용하던 인코딩(64Kbps - 12Mbps 대역폭)

---

2. Streaming stored video

 보통 우리는 Youtube나 Netflix를 볼 때, 이미 서버에 stored 된 video를 보게 된다. 즉 다음과 같은 간단한 절차로 우리, 즉 클라이언트가 video를 시청하게 된다.

 

그렇다면, 여기서 고려해야 될 점은 server와 client 사이의 bandwidth가 실시간으로 달라진다는 것이다. 예를 들면, 차안에서 이동하면서 데이터로 유튜브를 시청한다고 가정하자. 이 때 access network가 계속 변하기 때문에 bandwidth도 실시간으로 변하게 된다. 

 

 일단, stored video가 우리에게 보여지는 상황을 살펴보자.

 

 위 그림에서, 가로축은 시간, 세로축은 시간에 따라 축적되는 데이터 양이다. 먼저, 1,2,3 순서대로 살펴보면

1. server에 동영상을 store하는 과정이다
2. 클라이언트의 요청에 따라 video를 전송하는 과정이다
3. 비디오가 클라이언트에게 도착하고 재생되는 과정이다.

 이 때, 2번과 3번 사이에 network로 인한 딜레이가 이 그림에서는 고정된 값이다. 즉, 이처럼 network delay가 고정이 되어 있으면, 클라이언트는 영상을 delay 없이 최적의 상태에서 시청할 수 있게 된다. 그 이유는 이미 보내져서 기다리고 있는 데이터가 클라이언트 버퍼에 있기 때문에 그 버퍼를 넘어서지 않는 한, 최적의 상태에서 시청하게 된다.

 

 그렇지만, 위 상황은 매우 이상적인 network delay를 나타낸 것이고, 앞서 언급했듯이, network delay는 시간에 따라 변화한다. 변화하는 network 때문에 bandwidth도 실시간으로 달라지고 client가 받는 video 양도 달라질 것이다. 이를 해결하기 위해 client 쪽에 버퍼를 설치해 video streaming을 이용한다. 

 

 또, 우리는 순간적으로 동영상을 건너 뛸 수 있고, 2배속으로 재생할 수도 있고, 멈추기까지 한다. 이럴 때, 데이터 손실이 발생할 수 있는데, 이 때 중간 중간 광고를 넣거나 흔히 말하는 로딩중이라는 동그라미를 띄워 놓고 그 시점에 해당하는 데이터를 보여준다. 

 

 이제는 고정된 network가 아닌 상황인 다음 그림을 살펴보자.

이 그래프를 보면, server가 stored된 영상을 보내는 빨간색 선은 속도가 일정하다.

 

 그렇지만, 클라이언트가 받는 비디오는 variable network delay 때문에 시간에 따라 다르다. 검은색으로 된 그래프를 보면, 어느 순간에는 일정 시간동안 들어오는 data가 유지되고, 어느 순간에 다시 받고를 반복한다. 즉, 일정한 계단식으로 상승하는게 아니라 왔다 갔다 하며 데이터를 받는다. 

 

 이 때, t0 시점에 클라이언트는 6chunk만큼의 비디오 데이터를 받았고, 재생은 2chunk 만큼 진행된 상태이다. 예를 들면 클라이언트는 영화의 30분 정도는 데이터를 이미 받아놓고, 10분째 재생하고 있는 것이다. 

 

 위의 예시처럼 미리 데이터를 받아 buffer에 저장해 놓고, 재생을 하면 우리가 원하는 끊김 없는 동영상 재생이 가능하다. 그렇다면 궁금한 것은, 받아놓은 데이터 없이 바로 재생을 하면 어떻게 될까? Youtube를 생각하면 Priemium말고 일반 회원으로 영상을 시청할 때, 가끔 맨 처음에 광고가 나오는 시간이 존재한다. 그 광고가 나오는 시간동안, buffer에 데이터를 받아놓기 시작하는 것이다. 즉, 광고를 이용함으로써 데이터를 미리 저장할 시간을 벌어 놓는 것이다.

---

3. DASH(Dynamic, Adaptive, Streaming over HTTP)

 DASH라는 방법은 동영상을 전송하는데 사용하는 protocol 중 하나이다. 이 프로토콜에서 server와 client는 각각 무슨 일을 하는지, 동영상이 어떻게 전송하는지 알아보자.

 

 먼저 서버측에서 하는 일에 대해서 알아보자. 서버측은 다음과 같은 일을 한다.

• 비디오 파일을 여러 개의 chunk로 쪼갠다
• 각 chunk는 서로다른 비율로 encode된다.(고화질, 저화질별로 따로 인코딩 )
• 다른 비율로 인코딩 된 것들은 서로 다른 파일들에 담긴다.
• 파일들은 다양한 CDN 노드에 복제된다. 
• manifest file이 다양한 chunk들로 파일들에 대한 URL 정보를 포함하고 있다.(일종의 메뉴판 같은 느낌)

 그럼 클라이언트측은 어떨까?

• manifest file들 중, 한 번에 하나의 chunk를 골라 그 chunk가 어디에 있는지 확인한다.
• 몇 번의 test(consulting)을 통해 서버와 클라이언트 사이의 bandwidth를 추정한다
• 현재 주어진 상황의 bandwidth에서 maximum chunk를 선택한다.(그 아래 비율의 것들도 선택 가능)
• 시간이 지남에 따라 bandwidth가 변할 때마다 그 상황에서의 최적의 chunk를 택한다.

 

 이런 기본적인 서버와의 연결을 통해 영상을 받는 것 외에 클라이언트 쪽에는 intelligence가 있다. 이 intelligence를 통해 무슨 일을 할까?

• 언제 chunk를 요청할 지 결정(버퍼가 비어 있다면 요청 또는 overflow라면 요청 안함)
• 요청할 encoding 비율을 결정(bandwidth가 높으면 높은 퀄리티의 chunk 요청, bandwidth 중간에 낮아지면 자동으로 저화질로 변)
• chunk를 어디에 요청할 지 결정(여러 CDN에 있는 하나의 청크에 대해 가장 가깝게 위치한 곳에 요청)

---

4. CDN(Content Distribution Networks)

 DASH에 관한 설명을 하면서, CDN 노드란 것이 나왔다. 그렇다면 이 CDN은 대체 뭐하는 친구일까?

 

 먼저, CDN이 나온 배경부터 알아보자. Netflix는 현재 이용자 수는 2022년 3분기 기준으로 2억 2300만 가구를 넘어섰다. 즉, Netflix는 지금 글을 쓰는 시간에도, Neflix에 존재하는 영상 스트리밍 요청하는 사람이 몇천, 수백만이 넘어설 수도 있다는 것이다. 그럼, 동시에 이런 요청에 대해서 stream을 어떻게 해야지 더 최적의 상태로 할 수 있을지에 대한 해결책으로 CDN이 나오게 된 것이다. 

 

 처음 떠올린 해결책 1번은 하나의 엄청나게 큰 "mega-server"를 두는 것이다. 그렇지만, 아무리 크다고 해도 위와 같은 수의 요청을 동시에 처리하기는 힘들 뿐더러, network 혼잡도도 엄청나게 올라갈 것이다. 또, 만약 물리적으로 거리가 멀다면, 엄청난 propagation delay도 생길 것이다. 이 mega-server는 그다지 좋은 해결책이라고 말할 수 없다.

 

 다음으로 떠올린 해결책이 바로 CDN이다. 간단한 아이디어를 소개하면, 비디오의 여러 카피들을 저장하고 제공는 다수의 (지리적으로) 떨어져 있는 서버를 두는 것이다. 다시 말하면, 사용자 측에 가까운 동영상 저장/제공 용 서버를 둔다는 것이다. CDN의 두 가지 아이디어는 다음과 같다.

• Enter Deep: CDN 서버를 user에 가까운 access network에 deep하게 들어간다.
• Bring Home: 사용자에게 조금 멀더라도 고성능의 서버를 둔다.

둘 중 하나의 아이디어로 제공하는데, Enter Deep의 대표적인 회사는 Akamai, Bring Home의 대표적인 회사는 LimeLight가 있다. 이렇듯 CDN은 오늘날 고품질 영상 스트리밍 서비스를 가능하게 해주는 핵심 인프라다.

 

---

5. Netflix

 그렇다면 대표적인 예시로 넷플릭스가 어떻게 작동하는지 알아보자. 

 

 넷플릭스도, CDN을 이용하는데, 예를 들어 MADMEN이라는 영화 컨텐츠를 구독자가 시청하려고 한다는 상황을 가정해보자.

기본적으로 MADMEN은 넷플릭스가 여러 OpenConnect CDN에 chunk 단위로 복제해서 저장해놨을 것이다. 그렇다면 구독자가 요청할 때 어떤 순서로 일이 진행될까?

1. 구독자가 MADMEN이라는 영화 컨텐츠를 요청하면, service provider는 manifest를 반환한다
2. manifest(앞서 설명했듯이 메뉴판)를 사용해 구독자는 그들의 최적의 상태의 network로 받을 수 있는 가장 좋은 비율로 coding된 chunk들을 받는다
3. 만약 network가 혼잡인 상태이거나 변한다면 다른 비율로 인코딩된 chunk나 복제본을 받는다.

 

 이 CDN node는 network edge에 존재하게 되는데, 조금 더 최적의 방법을 이용하기 위해 인공지능 AI를 사용한다고 한다. 인공지능은 사용자들의 검색기록이나 그 지역의 network 사용자들이 무엇을 최근에 많이 봤는지에 대해서 학습하고, 그 데이터에 기반해 CDN node에 유명한 컨텐츠들을 미리 저장해 놓는다. 이렇게 되면, 그 CDN 노드를 가지고 있는 서버가 같은 network 안에 있는 클라이언트에게 빠르게 응답해서 보내줄 수 있다는 것이다.

 

 다음 예시를 한 번 살펴보자. 이번 예시는 자사의 CDN이 아닌 타사의 CDN을 사용하는 경우이다

타사 CDN 이용할 경우

 그림을 설명하면, netcinema라는 회사가 KingCDN의 CDN 서비스를 이용하는 상태이다. 다음과 같은 순서로 진행된다.

1. Bob이 netcinema.com이라는 웹페이지에서 특정 비디오를 요청한다.
2. URL 정보를 받은 bob은 local DNS에 그 URL에 대한 쿼리를 보낸다.
3. local DNS는 도메인을 보고, netcinema.com이라는 authoriatative DNS에 쿼리를 보낸다.
4. netcinema.com은 실제 영상을 모르기 때문에, 그 URL에 해당하는 진짜 이름(CNAME)을 응답으로 보낸다.
5. local DNS는 CNAME을 보고, KingCDN.com의 authoritative DNS에 쿼리를 보내고
6. KingCDN은 그 비디오에 해당하는 chunk들을 저장하고 있기 때문에 응답을 보내준다.
7. Bob에게 전달하고, Bob은 IP 주소를 기반으로 HTTP GET을 요청해 비디오를 시청하게 된다.

이번에는 Netflix의 예시를 한 번 살펴보자.

자사 CDN 사용할 경우-Netflix

넷플릭스는 이용자 수가 많아 검색 요청도 엄청 많이 들어온다. 그렇기 때문에 그 검색을 위한 서버가 또 필요하다. 그 서버를 amazon 클라우드이다.

 

순서를 한 번 살펴보자

1. Netflix에 Bob이 로그인을 한다.
2. Netflix에 비디오를 검색한다. 이 요청은 Amazon cloud에 들어간다.
3. Amazon cloud는 Manifest file, 즉, 메뉴판을 응답으로 돌려준다.(어느 CDN서버에 어느 비율로 저장돼 있는지 알려줄 것)
4. DASH 서버(제일 가까운 서버)가 선택되고 연결되고 스트리밍이 시작된다.

---