개요
넷플릭스, 유튜브와 같은 비디오 스트리밍 서비스가 어떻게 구현되는지 알아보자.
캐시와 같은 기능을 하는 응용 프로그램 수준의 프로토콜과 서버를 사용하여 구현된다(CDN).
2.6.1 인터넷 비디오
기본적으로 온-디맨드 방식이다. 즉, 녹화된 비디오가 서버에 저장되어 있다가, 클라이언트가 요청하면 해당 비디오를 클라이언트에게 보내주는 방식이다.
비디오 = 초당 24/30 개의 이미지(fps) 가 연속적으로 표현되는 것
이미지 = 픽셀 단위
픽셀 = 휘도와 색상을 나타내는 여러 비트
따라서, 비트 전송률이 높아지면, 이미지 품질이 좋아지고, 비디오 시청 환경이 좋아진다.
해상도와 비트 전송률
- 4K : 10Mbps 이상
- 고화질 동영상 : 100kbps ~ 3Mbps
연속 재생을 제공하기 위해, 네트워크는 압축된 비디오의 전송률 이상의 스트리밍 애플리케이션의 평균 처리량을 제공해야 한다.
또한, 압축을 사용하여 동일 비디오를, 여러 품질의 버전으로 만들 수 있다.
2.6.2 HTTP 스트리밍 및 대쉬(DASH)
HTTP 스트리밍에서, 비디오는 HTTP 서버 내의 특정 URL을 갖는 일반적인 파일로 저장된다.
즉, 비디오를 시청하는 경우, 클라이언트가 서버에 TCP 연결을 설립하고, 해당 URL에 대한 HTTP GET 요청을 발생시키면, 서버가 응답 메세지 내에 비디오 파일을 담아서 전송하게 된다.
이때, 클라이언트 측의 애플리케이션 버퍼에 전송받은 바이트가 저장되는데, 미리 정해진 임계값을 초과하면, 클라이언트 애플리케이션이 재생을 시작하게 된다.
HTTP 스트리밍의 문제는, 모든 클라이언트가 똑같이 인코딩된 비디오를 전송받는다는 것이다. 가용 대역폭의 차이에도 불구하고 말이다.
이 문제를 해결하기 위해, HTTP 기반 스트리밍인 DASH(Dynamic Adaptive Streaming over HTTP)가 개발되었다.
클라이언트가 가용 대역폭이 충분한 경우, 높은 비트율의 비디오 버전을 요청하고, 그렇지 않은 경우 낮은 비트율의 비디오 버전을 요청하여,클라이언트가 HTTP GET 요청을 이용해 매번 다른 버전의 비디오 조각을 선택할 수 있도록 하는 것이다.
따라서 DASH는, 예를 들어 클라이언트가 이동하는 경우 가용 대역폭이 바뀌게 될 수 있는데, 이런 경우에도 그에 맞춰서 비디오 스트리밍을 재생하게 해준다.
DASH를 사용할 때, 각 비디오 버전은 HTTP 서버에 서로 다른 URL을 가지고 저장된다. HTTP 서버는 비트율에 따른 각 버전의 URL을 제공하는 매니페스트(manifest) 파일을 갖고 있다.
다음은, DASH의 동작이다.
1. 클라이언트는 먼저 매니페스트 파일을 요청하여, 서버에서 제공하는 다양한 버전을 알게 된다.
2. 클라이언트는 매번 원하는 버전의 비디오 조각 단위 데이터를 선택한다. HTTP GET 요청 메세지에 URL과 byte-range를 지정하여 요청한다.
3. 비디오 조각 단위 데이터를 다운로드하는 동안, 측정된 수신 대역폭과 비트율 결정 알고리즘을 통해 다음에 선택할 비디오 조각 단위 데이터의 버전을 결정한다.
이렇게 함으로써, 클라이언트가 서로 다른 품질 수준의 비디오를 자유롭게 변화시킬 수 있도록 허용한다.
2.6.3 콘텐츠 분배 네트워크(CDN)
인터넷 비디오 회사가 스트리밍을 제공하는 가장 단순한 방법은, "단일한 거대 데이터 센터"를 구축한 뒤 해당 센터에 모든 비디오 자료를 저장하고, 해당 센터에서 모든 비디오를 전송하는 것이다.
이렇게 하는 경우 3가지 문제가 발생한다.
1. 클라이언트가 데이터 센터로부터 지역적으로 먼 지점에 있는 경우
- 너무 많은 링크와 ISP를 거치게 된다. 이때, 링크 중 하나라도 비디오 소비율보다 낮은 전송용량을 갖게 되면, 종단간 처리율이 낮아지고, 화면 정지 현상이 일어날 수 있다. (종단간 처리율은, "병목 지점의 링크"에 의해 좌우된다!!)
2. 인기 있는 비디오는 같은 통신 링크를 통해 여러 번 반복적으로 전송된다
- 네트워크 대역폭의 낭비
- 비디오 회사는 ISP에게 동일한 바이트를 전송하는데 중복 비용을 지불하게 된다
3. 한번의 장애로 전체 서비스가 중단될 수 있다.
위와 같은 문제를 해결하기 위해, 비디오 회사들은 CDN(Contents Distribution Network)을 이용한다.
CDN은, 다수의 지점에 분산된 서버들을 운영하고, 분산된 서버에 비디오들을 저장한다. 또한 사용자는 최선의 서비스를 받을 수 있는 지점의 CDN 서버로 연결된다. CDN은, 컨텐츠 제공자가 소유한 사설 CDN이 있고, 제 3자가 운영하는 CDN을 통해 컨텐츠를 분배할 수도 있다.
CDN은 서버의 위치를 결정짓는데 2가지 방식 중 하나를 사용한다.
1. enter-deep
- 서버 클러스터를 세계 곳곳의 접속 네트워크에 구축함으로써 ISP의 접속 네트워크로 깊숙히 들어가는 것
- 서버 - 사용자간 거리 최소화( = 서버 - 사용자간 링크 및 라우터 수 최소화)
- 지연시간, 처리율 good
- 비용 bad
- Akamai의 서비스 방식
2. bring-home
- 접속 ISP에 구축하는 대신, 규모가 더 큰 IXPs(인터넷 교환지점)에 배치하는 방식
- 지연시간,처리율 bad
- 비용 good
- LimeLight 등 다수의 서비스 방식
서버 클러스터의 위치가 정해지면, CDN은 컨텐츠의 복사본을 클러스터에 저장한다.
이떄, 각 클러스터에 모든 복사본을 저장할 필요는 없다. 어떤 비디오는 일부 지역에서는 인기가 없거나, 특정 국가에서만 인기가 있을 수 있기 때문이다. 실제로, CDN은 클러스터에 대해 Push 방식이 아닌 Pull 방식을 사용한다.
(사용자가 지역 클러스터에 없는 비디오를 요청하는 경우, 해당 비디오를 중앙 서버에서 전송받아와, 사용자에게 서비스하는 동시에 CDN 클러스터에 복사본을 저장한다.)
CDN 동작
실제 구체적인 동작에 대해 알아보자.
1. 사용자의 호스트 웹 브라우저가 URL을 지정함으로써 특정 비디오의 재생을 요청한다.
2. CDN은 해당 요청을 가로챈다
3. CDN은 해당 시점에서 클라이언트에게 가장 적당한 CDN 클러스터를 선택하고, 클라이언트의 요청을 해당 클러스터 서버로 연결한다.
2번 과정에 대해 조금 더 자세히 살펴보자
대부분의 CDN은 사용자의 요청을 가로채고 다른 곳으로 연결하는데 DNS를 활용한다.
NetCinema라는 컨텐츠 제공자가 KingCDN이라는 CDN업체를 이용해 비디오를 고객에게 분배한다고 하자.
NetCinema 웹페이지에는 각 비디오가 "video"라는 문자열과 고유한 ID를 포함하는 URL을 할당받는다.
그리고, 아래의 6단계 과정이 일어난다.
1. 사용자가 NetCinema의 웹페이지를 방문한다.
2. 사용자가 비디오의 URL(http://video.netcinema.com/6Y7B23V)을 클릭하면, 사용자의 호스트는 video.netcinema.com에 대한 DNS 쿼리를 보낸다
3. 사용자의 로컬 DNS 서버는, 호스트 이름이 video를 감지하고, 해당 DNS 쿼리를 NetCinema의 책임 DNS 서버로 전달한다.
책임 DNS 서버는, DNS 쿼리를 KingCDN으로 연결하기 위해 IP 주소 대신, KingCDN의 호스트 이름(a1105.kingcdn.com)을 로컬 DNS에게 알려준다.
4. 이 시점부터, DNS 쿼리는 KingCDN의 사설 DNS 구조로 들어가게 된다.
로컬 DNS 서버는 KingCDN의 호스트 이름(a1105.kingcdn.com)으로 DNS 쿼리를 보내고, 결국 KingCDN의 DNS에 의해 KingCDN의 컨텐츠 서버의 IP 주소로 변환되어 로컬 DNS에게 응답된다.
즉, 이때 클라이언트가 컨텐츠를 전송받게 될 서버가 결정되는 것이다.
5. 로컬 DNS 서버는 호스트에게 컨텐츠를 전송받게 될 CDN 서버의 IP주소를 알려준다.
6. 클라이언트는 해당 IP 주소로 직접 TCP 연결을 설정하고 비디오에 대한 HTTP GET 요청을 전송한다. 이때 DASH가 사용된다면, 서버가 먼저 클라이언트에게 매니페스트 파일(각기 다른 버전의 비디오에 대한 URL 목록을 담은 파일)을 전송하고, 클라이언트가 동적으로 다른 버전의 비디오 조각 단위 데이터를 선택할 수 있다.
클러스터 선택 정책
CDN 클러스터를 어떻게 선택할 것인가?
CDN은 클라이언트가 DNS 서비스를 수행하면서, 클라이언트의 로컬 DNS 서버의 IP 주소를 알게 된다. 해당 IP 주소를 기반으로 CDN은 최선의 클러스터를 선택하게 된다.
1. 지리적으로 가장 가까운 클러스터
Quova와 같은 상용 지리정보 데이터베이스를 이용하면, 로컬 DNS 서버의 IP 주소를, 지리적으로 매핑할 수 있다. 따라서, 현재 로컬 DNS 서버에서 가장 가까운 클러스터를 선택하는 것이다.
문제는, 지리적으로 가장 가까운 클러스터가 실질적인 네트워크 경로 길이로 따지면 가장 가깝지 않을 수 있다는 것이다. 직선 거리로는 가까워도, 실질적인 네트워크 경로는 돌아가는 경로일 수 있기 때문이다.
또 다른 문제는, 클라이언트가 로컬 DNS 서버를 자신과 먼 지점으로 수동으로 선택할 수 있다는 문제가 있다.
2. 실시간 측정
주기적으로 클러스터와 클라이언트 간의 지연 및 손실 성능을 측정한다.
문제는, 많은 로컬 DNS 서버가, 클러스터가 보낸 ping 같은 프로브 메세지에 응답하지 않도록 설정되어 있다는 것이다.
2.6.4 사례 연구 : 넷플릭스, 유튜브, Kankan
넷플릭스
Bring-Home 방식
Push-caching을 사용한다
- 사용량이 적은 시간에 비디오를 CDN 서버에 푸시하여 배포한다
- 전체 라이브러리를 보유할 수 없으면, 매일매일 가장 많이 결정되는 비디오만 푸시한다.
DASH 방식을 이용한다
- 클라이언트가 동적으로 자신의 가용 대역폭에 따라 동영상 품질이 자동 조정된다
클라이언트를 CDN 서버로 연결하기 위해, CDN 업체가 제공하는 CDN 서버의 호스트 이름을 알고, DNS 리디렉션을 할 필요가 없다.
넷플릭스 웹사이트에서 영화를 선택하면, 넷플릭스 소프트웨어가 최적의 CDN 서버를 선택하여 알려준다(넷플릭스 자체 CDN이 구축되어 있기 때문).
유튜브
Bring-Home 방식
DASH 방식을 버리고, 사용자가 특정 버전을 선택하도록 하였다
- 대역폭과 서버 자원의 낭비를 줄이기 위함
Kankan
P2P 방식 사용
- CDN 사용 비용을 줄이기 위함
- 기본적으로 P2P는, 느릴 수 밖에 없다. 피어는 각 사용자인데, 접속 ISP는 기본적으로 다운로드에 특화되어있고 업로드에는 더 많은 시간이 소요되기 때문이다.
현재는 CDN-P2P(하이브리드) 방식 사용
- P2P의 트래픽이 충분하지 않으면 CDN 사용하고, 충분하면 CDN을 사용하지 않는다.
'네트워크 > chapter 2. 애플리케이션 계층' 카테고리의 다른 글
| 2장 문제 (0) | 2022.08.06 |
|---|---|
| 2.7 소켓 프로그래밍 : 네트워크 애플리케이션 생성 (0) | 2022.08.03 |
| 2.4 DNS - 인터넷의 디렉터리 서비스 (0) | 2022.08.01 |
