비디오 스트리밍과 CDN — 부호화에서 가까운 서버 찾기까지

1. 비디오 트래픽의 두 가지 문제 — 규모와 이질성

응용 계층의 마지막 주제는 비디오 스트리밍과 콘텐츠 분배 네트워크(CDN, content distribution network)입니다. 지금 인터넷에서 대역폭을 가장 많이 쓰는 트래픽이 스트리밍 비디오입니다. 넷플릭스, 유튜브 같은 서비스의 비디오가 가정용 ISP 트래픽의 대부분을 차지합니다.

이런 서비스를 만들 때 부딪히는 문제는 둘입니다.

해결은 네트워크 코어를 바꾸지 않고 응용 쪽에서 합니다. 서버를 여러 곳에 흩어 두고, 사용자마다 다른 품질의 비디오를 보냅니다. 앞쪽은 CDN이, 뒤쪽은 DASH라는 스트리밍 방식이 맡습니다. 이 글은 비디오를 비트로 만드는 부호화부터 시작해 재생 버퍼, DASH, CDN 순서로 갑니다.

2. 비디오 부호화 — 중복을 줄여 비트 수를 줄인다

비디오는 이미지 여러 장을 일정한 속도로 이어서 보여 줍니다. 영화라면 초당 24장, 방송이나 게임 영상이라면 초당 30장이나 60장입니다. 이미지 한 장은 픽셀의 배열이고, 픽셀 하나의 색은 비트 몇 개로 나타냅니다. 이 비트를 그대로 보내면 양이 너무 많습니다.

부호화(coding)는 이미지 안과 이미지 사이의 중복(redundancy)을 이용해 비트 수를 줄이는 일입니다. 중복이 어디에 있느냐에 따라 두 종류가 있습니다.

문제 1

가로 1920, 세로 1080 픽셀인 이미지를 픽셀당 24비트로 나타내고 초당 30장을 보여 줍니다. (가) 부호화하지 않고 보내면 몇 bps가 필요합니까. (나) 부호화해서 6 Mbps로 줄였다면 몇 분의 1로 줄어든 것입니까. (다) 6 Mbps로 부호화한 2시간짜리 영화 파일의 크기는 몇 GB입니까.

(가) 한 장이 1920 × 1080 × 24 = 49,766,400비트이고, 초당 30장이면 49,766,400 × 30 = 1,492,992,000비트, 약 1.49 Gbps입니다. (나) 1,492,992,000 / 6,000,000 ≈ 249이므로 약 249분의 1입니다. (다) 2시간은 7,200초이므로 6,000,000 × 7,200 = 43,200,000,000비트이고, 8로 나누면 5,400,000,000바이트, 5.4 GB입니다. 부호화하지 않은 비디오는 가정용 회선 대부분으로 실시간 전송이 불가능합니다.

3. 부호화율 — CBR과 VBR

부호화한 비디오가 1초에 쓰는 비트 수를 부호화율(encoding rate)이라고 합니다. 부호화로 줄어드는 양은 장면마다 다릅니다. 하늘이 화면을 채운 장면은 공간 중복이 크고, 인물이 가만히 말하는 장면은 시간 중복이 큽니다. 반대로 폭발이나 빠른 추격 장면은 이웃 프레임끼리도 많이 달라 줄일 여지가 적습니다. 그래서 부호화율을 다루는 방식이 둘로 나뉩니다.

부호화 표준에 따라 쓰는 부호화율의 범위도 다릅니다. CD-ROM에 쓰던 MPEG-1은 1.5 Mbps, DVD의 MPEG-2는 3~6 Mbps 정도이고, 인터넷에서 흔히 쓰는 MPEG-4는 64 kbps부터 12 Mbps까지 넓게 씁니다. 같은 비디오도 부호화율을 여러 단계로 만들어 둘 수 있다는 점이 6절의 DASH에서 다시 쓰입니다.

4. 저장된 비디오 스트리밍

가장 단순한 경우부터 봅니다. 비디오 서버가 미리 녹화해 둔 비디오 파일을 가지고 있고, 클라이언트가 요청하면 인터넷을 거쳐 보냅니다. 이것을 저장된 비디오 스트리밍(streaming stored video)이라고 합니다. 넷플릭스나 유튜브에서 이미 올라와 있는 영상을 보는 경우입니다.

스트리밍(streaming)은 클라이언트가 비디오 앞부분을 재생하는 동안 서버가 뒷부분을 계속 보내는 방식입니다. 파일 전체를 내려받은 뒤에 재생하면 5.4 GB 영화는 한참 기다려야 하지만, 스트리밍은 앞부분만 오면 바로 볼 수 있습니다.

누적 데이터로 보기

가로축을 시간, 세로축을 지금까지 쌓인 데이터의 양으로 놓고 세 가지를 그려 보면 흐름이 잘 보입니다.

1. 서버의 전송 — 서버가 초당 30프레임짜리 비디오를 같은 간격으로 보내면, 한 칸에 한 프레임씩 올라가는 일정한 계단이 됩니다.
2. 클라이언트의 수신 — 네트워크 지연이 늘 똑같다면 수신 계단은 전송 계단을 그 지연만큼 오른쪽으로 옮긴 모양입니다.
3. 클라이언트의 재생 — 받은 프레임을 같은 간격으로 보여 주면 재생 계단도 일정합니다.

문제는 실제 네트워크에서 서버와 클라이언트 사이의 대역폭이 시간에 따라 바뀐다는 점입니다. 집 안 와이파이, 접속망, 네트워크 코어, 비디오 서버 어느 곳에서든 혼잡 정도가 달라집니다. 혼잡이 생기면 패킷이 늦게 오거나 사라지고, 그러면 재생이 늦어지거나 화질이 떨어집니다.

5. 재생 버퍼와 재생 지연

재생에는 지켜야 할 조건이 있습니다. 클라이언트가 재생을 시작하면 그 뒤로는 원래 녹화된 시간 간격 그대로 보여 줘야 합니다. 30 fps로 찍은 영상은 30 fps로 끊김 없이 나와야 합니다. 이것을 연속 재생 제약(continuous playout constraint)이라고 합니다.

그런데 네트워크 지연은 패킷마다 다릅니다. 어떤 프레임은 40 ms 만에 오고 어떤 프레임은 120 ms 걸립니다. 패킷마다 지연이 달라지는 현상을 지터(jitter, 지연 변이)라고 합니다. 받는 대로 바로 재생하면, 늦게 온 프레임 자리에서 화면이 멈춥니다.

그래서 클라이언트는 받은 프레임을 클라이언트 쪽 버퍼(client-side buffer)에 모아 두고, 첫 프레임이 와도 곧바로 재생하지 않고 정해진 시간만큼 기다렸다가 재생을 시작합니다. 이 기다리는 시간이 클라이언트 재생 지연(client playout delay)입니다. 재생이 시작된 뒤에는 일정한 간격으로 버퍼에서 프레임을 꺼내 보여 줍니다. 수신 시각과 재생 시각 사이에 생긴 여유만큼의 비디오가 버퍼에 쌓여 있으므로, 중간에 몇 프레임이 늦게 와도 그 프레임의 재생 차례 전에만 도착하면 화면은 끊기지 않습니다.

재생 차례가 왔는데 그 프레임이 아직 버퍼에 없으면 버퍼가 바닥난 것입니다. 재생은 그 프레임이 도착할 때까지 멈추고, 화면에는 로딩 표시가 돕니다. 재생 지연을 길게 잡으면 끊김은 줄지만 첫 화면이 늦게 뜹니다. 짧게 잡으면 빨리 시작하지만 중간에 멈출 가능성이 커집니다. 지터가 클수록 더 오래 기다려야 끊기지 않습니다.

재생 버퍼가 해결해야 하는 일은 그 밖에도 있습니다. 사용자는 일시정지하고, 빨리 감고, 되감고, 원하는 지점으로 건너뜁니다. 잃어버린 비디오 패킷을 다시 받아야 하는 경우도 있습니다.

문제 2

서버가 프레임 0부터 5까지를 시각 0, 1, 2, 3, 4, 5(단위는 100 ms)에 하나씩 보냅니다. 각 프레임의 네트워크 지연은 차례로 3, 2.5, 5, 3, 4, 2입니다. 클라이언트는 프레임 0이 도착하고 p만큼 기다린 뒤 재생을 시작해 한 단위에 한 프레임씩 순서대로 재생합니다. (가) 한 번도 멈추지 않는 가장 작은 p는 얼마입니까. (나) p = 1이면 어떻게 됩니까.

도착 시각은 보낸 시각에 지연을 더해 3, 3.5, 7, 6, 8, 7입니다. 프레임 0은 시각 3에 오므로 프레임 k의 재생 차례는 3 + p + k입니다. 멈추지 않으려면 모든 k에 대해 도착 시각 ≤ 3 + p + k여야 합니다. 이 조건을 정리하면 p ≥ (프레임 k의 지연) − 3이고, 가장 큰 지연이 5이므로 (가) p = 2입니다. 가장 큰 지연에서 첫 프레임의 지연을 뺀 값만큼 기다리면 됩니다. (나) p = 1이면 프레임 2의 차례가 3 + 1 + 2 = 6인데 도착은 7이므로 재생이 1단위(100 ms) 멈춥니다. 프레임 2를 7에 재생한 뒤 프레임 3, 4, 5의 차례는 8, 9, 10으로 밀리고, 이들은 각각 6, 8, 7에 이미 도착해 있으므로 더 멈추지 않습니다.

6. DASH — HTTP로 하는 동적·적응형 스트리밍

재생 버퍼는 지연의 흔들림을 견디게 해 주지만, 가용 대역폭 자체가 부호화율보다 낮으면 소용이 없습니다. 3 Mbps 회선으로 5 Mbps 비디오를 받으면 버퍼는 결국 바닥납니다. 1절의 이질성 문제가 여기서 드러납니다. 이를 해결하는 방식이 DASH(Dynamic, Adaptive Streaming over HTTP)입니다.

아래는 매니페스트에 담기는 정보를 단순하게 적어 본 예입니다. 실제 형식은 XML이지만 담는 내용은 같습니다.

청크 1:  1 Mbps  http://video.example.com/m42/1M/c1
         3 Mbps  http://video.example.com/m42/3M/c1
         6 Mbps  http://video.example.com/m42/6M/c1
청크 2:  1 Mbps  http://video.example.com/m42/1M/c2
         ...

청크를 1, 3, 6 Mbps 세 단계로 만들어 두었다면, 잰 대역폭이 4 Mbps일 때는 3 Mbps 청크를, 8 Mbps로 올라가면 6 Mbps 청크를, 2 Mbps로 떨어지면 1 Mbps 청크를 요청합니다. 광랜 사용자는 고화질을, 휴대폰 사용자는 저화질을 받고, 같은 사용자도 엘리베이터에 타면 화질이 잠시 떨어졌다가 내리면 돌아옵니다.

결정은 클라이언트가 내린다

DASH에서 서버는 청크를 저장해 두고 요청에 답할 뿐입니다. 판단은 클라이언트가 합니다.

• 언제 요청할지 — 버퍼가 바닥나지도(buffer starvation) 넘치지도(overflow) 않게 요청 시점을 정합니다.
• 어떤 부호화율로 요청할지 — 대역폭이 넉넉하면 높은 화질을 고릅니다. 버퍼에 비디오가 많이 쌓여 있으면 잠깐 대역폭이 떨어져도 화질을 유지할 수 있으므로, 실제 플레이어는 버퍼 양도 함께 봅니다.
• 어디에 요청할지 — 같은 청크를 여러 서버가 가지고 있으면, 클라이언트와 가깝거나 가용 대역폭이 큰 서버의 URL을 고릅니다. 이 서버들이 다음 절의 CDN입니다.

DASH는 보통의 HTTP 요청과 응답을 그대로 쓰므로 일반 웹 서버와 웹 캐시로 비디오를 나를 수 있고, 웹 트래픽을 통과시키는 방화벽도 그대로 지납니다. 지금까지를 묶으면 스트리밍 비디오는 부호화, DASH, 재생 버퍼링 세 가지로 이루어집니다.

7. 메가 서버 하나로는 안 되는 이유

이제 규모 문제로 갑니다. 수백만 개의 비디오 가운데 각자 고른 비디오를 동시 접속자 수십만 명에게 보내야 합니다. 가장 쉬운 방법은 거대한 데이터 센터 하나, 이른바 메가 서버(mega-server)에 모든 비디오를 두는 것입니다. 이 방법은 다음 이유로 버티지 못합니다.

사용자가 늘수록 이 문제가 모두 커지므로 이 설계는 확장되지 않습니다(doesn't scale). 앞 글의 P2P 파일 분배에서 본 클라이언트-서버 방식의 한계와 같은 종류의 문제입니다.

문제 3

새 드라마가 공개된 날 저녁, 한 나라에서 24,000명이 같은 회차를 평균 5 Mbps로 동시에 봅니다. (가) 메가 서버 하나로 보낸다면 서버의 출력 링크에 필요한 대역폭은 얼마입니까. (나) 이 나라의 접속망 안에 CDN 서버 40곳을 두고, 각 사이트가 원 서버에서 이 회차의 5 Mbps 버전을 한 번씩 받아 저장한 뒤 자기 지역 시청자에게 보낸다면, 원 서버가 이 회차 때문에 내보내는 데이터는 메가 서버 방식의 몇 분의 1입니까. 사본을 받는 데 걸리는 시간은 같다고 봅니다.

(가) 24,000 × 5 Mbps = 120,000 Mbps = 120 Gbps입니다. (나) 원 서버는 사본을 시청자 수만큼 보내지 않고 사이트 수만큼 보내므로 24,000 / 40 = 600, 600분의 1입니다. 사이트 하나가 맡는 시청자는 평균 600명이고, 그 3 Gbps 트래픽은 사이트와 사용자 사이의 짧은 구간만 지납니다.

8. CDN과 서버 배치 — enter deep, bring home

CDN은 비디오 사본을 지리적으로 흩어진 여러 사이트에 저장해 두고, 사용자에게 가까운 사이트에서 보내는 서버 네트워크입니다. 비디오 서비스 회사가 직접 CDN을 운영하기도 하고(private CDN), CDN 회사가 여러 콘텐츠 회사의 비디오를 대신 나르기도 합니다(third-party CDN). 서버를 어디에 두느냐에 따라 대표적인 방식이 둘 있습니다.

POP(point of presence)는 상위 ISP가 하위 ISP를 연결받기 위해 둔 라우터들의 모임입니다. 여러 ISP가 서로 직접 트래픽을 주고받는 곳이 IXP(Internet exchange point)입니다. 인터넷 구조를 다룬 앞 글들에서 본 용어입니다.

CDN 사이트는 모든 비디오를 다 가지고 있지 않습니다. 사이트에 없는 비디오를 요청받으면 원 서버나 다른 사이트에서 가져와 보내면서 사본을 저장하고, 저장 공간이 차면 잘 찾지 않는 비디오를 지웁니다. 웹 캐시가 동작하는 방식과 비슷합니다. 인기가 높을 것으로 예상되는 비디오는 요청이 오기 전에 미리 올려 두기도 합니다(push).

9. DNS로 CDN 서버 찾기와 클러스터 선택

사용자는 콘텐츠 회사의 주소를 클릭했는데 실제 비디오는 CDN 서버에서 와야 합니다. 이 연결은 앞 글에서 본 DNS가 해 줍니다. 영화 사이트 MovieHub(moviehub.example)가 비디오 배포를 CDN 회사 FastCDN(fastcdn.example)에 맡겼다고 합시다. 사용자 지수가 영화를 고릅니다.

1. 지수가 moviehub.example의 웹 페이지에서 비디오 링크 http://video.moviehub.example/m42를 누릅니다.
2. 지수의 컴퓨터가 video.moviehub.example의 주소를 로컬 DNS 서버에 묻습니다.
3. 로컬 DNS 서버가 질의를 따라가 MovieHub의 책임 DNS 서버에 닿습니다. 이 서버는 IP 주소 대신 FastCDN 쪽 호스트 이름, 예컨대 a42.fastcdn.example을 CNAME 레코드로 돌려줍니다.
4. 이제부터 질의는 FastCDN의 영역입니다. 로컬 DNS 서버가 a42.fastcdn.example을 FastCDN의 책임 DNS 서버에 묻고, 이 서버가 지수에게 알맞은 FastCDN 콘텐츠 서버의 IP 주소를 답합니다.
5. 로컬 DNS 서버가 그 IP 주소를 지수의 컴퓨터에 넘깁니다.
6. 지수의 클라이언트가 그 CDN 서버와 TCP 연결을 열고, HTTP로 비디오(DASH라면 먼저 매니페스트)를 요청합니다.

CNAME 레코드가 돌려주는 값은 호스트 이름입니다. DNS는 URL의 경로(/m42)를 다루지 않습니다. 경로는 6단계의 HTTP 요청에 실려 CDN 서버로 갑니다. MovieHub는 자기 DNS에 CNAME 한 줄만 두면 되고, 어느 서버로 보낼지는 4단계에서 FastCDN이 정합니다.

클러스터 선택 전략

FastCDN의 책임 DNS 서버에 질의를 보내는 쪽은 지수의 컴퓨터가 아닌 로컬 DNS 서버입니다. 그래서 CDN은 질의를 보낸 로컬 DNS 서버의 IP 주소를 기준으로 클러스터를 고릅니다.

• 지리적으로 가장 가까운 클러스터 — 상용 위치 데이터베이스로 로컬 DNS 서버의 IP 주소가 어느 지역인지 찾아, 그 지역에서 가장 가까운 클러스터를 고릅니다. 대부분의 경우 잘 맞지만, 사용자가 멀리 있는 로컬 DNS 서버를 쓰면 사용자와 먼 클러스터가 골라질 수 있습니다. 지리적으로 가까워도 네트워크 경로상 홉 수가 많거나 혼잡할 수 있다는 한계도 있습니다.
• 실시간 측정 — 클러스터와 각 지역 로컬 DNS 서버 사이의 지연과 손실을 주기적으로 재서, 지금 가장 상태가 좋은 클러스터를 고릅니다. 측정용 패킷에 응답하지 않는 로컬 DNS 서버도 많아서, 실제 클라이언트 트래픽을 관찰한 값을 쓰기도 합니다.

클러스터가 정해진 뒤에도 클라이언트는 DASH로 버전을 바꿔 가며, 경로가 혼잡하면 매니페스트의 다른 서버 URL로 옮겨 갈 수 있습니다.

10. OTT와 넷플릭스 사례

비디오 서비스는 인터넷에 특별한 기능을 요구하지 않습니다. 인터넷이 제공하는 호스트와 호스트 사이의 통신을 그대로 쓰고, 그 위에서 자기 서비스를 운영합니다. 이런 서비스를 OTT(over the top)라고 합니다. 인터넷 자체는 혼잡을 해결해 주지 않으므로, OTT 서비스는 혼잡한 인터넷에 응용 쪽에서 대응해야 합니다. 어느 CDN 노드에서 비디오를 가져올지, 혼잡할 때 시청자가 어떻게 행동할지, 어떤 비디오를 어느 노드에 둘지를 서비스가 직접 정합니다.

넷플릭스는 이 글의 요소를 모두 씁니다. 비디오마다 부호화율이 다른 여러 버전을 만들어, 클라우드에서 CDN 서버들로 미리 올려 둡니다. 시청자가 영상을 보기까지의 흐름은 다음과 같습니다.

1. 가입과 결제 같은 계정 관리는 넷플릭스의 계정 서버가 처리합니다.
2. 시청자가 앱에서 볼 영상을 둘러봅니다.
3. 영상을 고르면 그 영상의 매니페스트 파일을 받습니다. 청크별, 부호화율별 URL이 들어 있습니다.
4. 클라이언트가 매니페스트를 보고 CDN 서버와 버전을 골라 청크를 요청하고, 스트리밍이 시작됩니다.

계정과 둘러보기는 넷플릭스의 중앙 서버가 처리하고, 비트를 실제로 많이 보내는 비디오 전송은 시청자 가까이의 CDN 서버가 맡습니다. 3단계 뒤로는 어느 서버에서 어떤 화질을 받을지를 클라이언트가 정합니다.

정리

비디오 부호화는 한 이미지 안의 공간 중복과 이웃 이미지 사이의 시간 중복을 줄여 비트 수를 낮추고, 부호화율을 고정하는 CBR과 장면에 따라 바꾸는 VBR이 있습니다. 저장된 비디오 스트리밍에서는 대역폭과 지연이 계속 바뀌므로, 클라이언트가 재생 지연만큼 기다리며 버퍼에 비디오를 쌓아 지터를 견딥니다. DASH는 비디오를 청크로 나누고 청크마다 여러 부호화율로 저장한 뒤, 클라이언트가 매니페스트를 보고 대역폭에 맞는 청크를 HTTP로 요청하게 합니다. 메가 서버 하나는 확장되지 않으므로 CDN이 사본을 여러 곳에 두며, 접속망 깊숙이 넣는 enter deep과 POP·IXP 근처에 큰 클러스터를 두는 bring home 방식이 있습니다. 콘텐츠 회사의 DNS가 CNAME으로 CDN에 질의를 넘기고, CDN의 책임 DNS 서버가 로컬 DNS 서버의 위치나 측정값으로 클러스터를 골라 그 서버의 IP 주소를 돌려줍니다.