Google Global Cache (GGC)는 세계 각국의 통신사업자의 데이터센터에 도입되어 있으며 YouTube의 비디오 파일(싸이의 강남스타일 같은)을 캐싱한다. 이로인해 각국의 이용자들은 자국내 GGC를 통해 버퍼링없는 영상 시청이 가능해진다. 우리나라도 2012년 2월에 SK, LG U+, KINX에 도입이 되었다.
요즘에는 VoD 형태뿐만 아니라 스포츠 같은 Live 프로그램을 YouTube를 통해 시청하는 사람들이 많아졌다.
근데, GGC가 Live 트래픽을 처리하지 않는 다면, 즉 응용 레이어의 멀티캐스팅을 지원하지 않는다면 어떻게 될 까?
예를 들어 류현진 포스트 시즌 경기를 우리나라 이용자들이 YouTube를 통해 시청할 때 엄청난 트래픽이 해외에 있는 Google 데이터센터에서 국내 통신 사업자망으로 유입되게 된다. 720p 화질의 경우 약 3Mbps이고 100,000명이 국내 이용자가 시청한다면 경기 시간내내 3 Mbps x 100,000 = 300 Gbps의 대역폭을 점유하게 된다.
(국내의 경우 KT의 국제 인터넷 회선 용량이 355 Gbps정도 되고 SK와 LG U+는 이보다 작다).
쓰나미다!
경기 시간 동안 국내 이용자들의 정상적인 인터넷 사용이 불가능해질 것이고 류현진 경기 자체도 엄청난 버퍼링이 발생하게 될 것이다.
GGC가 Live 트래픽을 처리하게 되면 해외에서는 단일 스트림만 국내의 GGC로 전달되어 오고 이 GGC를 통해 국내 100,000 이용자들에게 멀티캐스팅되면 국제 인터넷 회선은 3Mbps만 소요되어 병목은 사라지게 된다.
GGC가 Live 트래픽을 처리하는 지, 처리한다면 어떻게 컨텐츠가 전달되는 지 알아보기 위해 테스트를 수행하였다.
※ GGC에 대해서는 이전 블로그 글인 "OTT Cache(Google, Netflix)와 통신사업자 Transparent Cache"와 "
YouTube를 위한 Google Global Cache(GGC) 동작 원리 (2편: LG U+)"를 참조하고 YouTube의 Live 스트리밍 방식은 "모바일 단말에서 YouTube Live TV 스트리밍 방식 분석 - HLS & Adaptive"를 참조하길 바란다.
GGC Call Flow: Live
아래 그림은 모바일 환경(Galaxy S4 with LTE-A, SK Telecom LTE-A 네트워크)에서 YouTube APP을 이용하여 YouTube에 접속한 후 SPOTV Live 채널을 시청하며 파악한 GGC의 동작 방식이다.
이용자가 모바일 단말에 YouTube를 실행한 후 Live 채널인 SPOTV를 선택한다. 단말은 YouTube 서버로 SPOTV Live 채널에 대한 Variant Playlist를 요청한다. 이 때 단말이 수신한 Variant Playlist 파일은 아래 그림과 같다. SPOTV 라이브 채널은 64Kbps(128x72)부터 2.8Mbps (1280x720)까지 6개의 화질 등급(Profile)을 제공함을 알 수 있다.
단말은 Variant Playlist 파일에 있는 화질 중에 가장 낮은 화질 (Profile 1: itag=151, 64Kbps, 128x72)을 선택하고 이 화질의 영상에 대한 Playlist 파일 요청 메시지를 YouTube 서버로 보낸다. 이 때 단말이 수신한 Playlist 파일은 아래 그림과 같다.
YouTube 서버는 5개의 chunk에 대한 URL list를 보내준다. URI 파라미터를 보면 chunk 사이즈가 37KB로 매우 작음을 볼 수 있다(인코딩율이 64Kbps니까).
단말은 첫번째 chunk 파일(348760)을 YouTube 서버로 요청한다. 이 때 YouTube 서버는 수신한 HTTP GET 메시지가 GGC가 도입되어 있는 SK Telecom의 가입자가 보낸 것임을 알아내고 (SK Telecom의 IP 대역) 302 Found 메시지를 보내 SK Telecom내의 GGC로 redirect시킨다.
단말은 SK Telecom내의 GGC 서버로 chunk 요청 메시지를 보내서 받아온다. 첫번째 chunk를 받은 단말은 현재 망의 품질이 좋다고 판단하여 Variant Playlist내의 높은 화질 등급(실측예에서 Profile 6: 2.8Mbps)의 chunk를 요청하려 한다. 근데, Profile 6의 chunk에 대해서는 Playlist (chunk들의 URL list)가 없네! 그래서 Profile 6에 대한 Playlist를 YouTube 서버로 요청한다. 이 때 단말이 수신한 Playlist 파일은 다음과 같다.
(itag 95)Manifest(hls_variant).m3u8
YouTube 서버는 2.8Mbps 화질 영상의 5개의 Chunk에 대한 URL list를 보낸준다. URI 파라미터를 보면 chunk 사이즈가 1.6MB로 매우 큼음을 볼 수 있다(인코딩율이 2.8Mbps니까).
단말은 첫번째 chunk 파일(348760)을 Youtube 서버로 요청하고 YouTube 서버는 이를 다시 SK Telecom내의 GGC로 redirect시킨다. 단말은 SK Telecom내의 GGC로 첫번째 chunk 파일을 요청하여 받아 간다.
[단말이 수신한 Chunk File]
단말은 이런 방식으로 Profile 6의 chunk를 4개를 수신하고 나면 약 5초 정도 더 이상 chunk를 요청하지 않고 5초가 지나면 약 5초마다 한 번씩 Playlist 파일 (Sliding Windows)을 요청하고 다음 chunk를 받아간다.
결론적으로 GGC는 Live 트래픽을 처리하고 있으며 기술적으로는 YouTube 서버로 전달되어오는 chunk 요청 메시지(HTTP GET)을 이용자가 가입한 통신 사업자내의 GGC로 redirect시켜주는 방식을 취하고 있었다. 그리고 비디오 chunk 파일은 GGC를 통해 이용자 단말로 전달되나 Manifest 파일 (Variant Playlist, Playlist)는 GGC가 처리하지 않고 있었다.
즉, 비디오 chunk 파일은 이용자가 가입한 통신사의 GGC(예, SK Telecom: r4---sn-n3hvcpax-bh2.c.youtube.com,LG U+: r4---sn-ab02a0n-jwwl.c.youtube.com)에서 받아오나 Manifest 파일은 지구상의 어느 나라에 있는 이용자나 다 YouTube 서버(www.youtube.com)에서 받아간다.
Google Global Cache가 Live Traffic도 처리하는 가? - 한다!
위 설명 중에 궁금한 부분이 있으신 분들은 아래 Comment에 글 남겨 주세요. 따뜻한 격려 댓글도 대환영 입니다~*
본 글을 프린트하고 싶으시면 로그인 후 우측 상단에 "프린트" 버튼 꾸욱~ 누르세요.
<참고 1>
<참고 2> 수신한 Chunk file의 미디어 정보
상호: (주)엔앰씨컨설팅그룹 주소: 서울시 강남구 테헤란로 128, 3층 387호 대표이사: 손장우 전화: 02-3444-5747 메일: webmaster@netmanias.com 등록번호: 서울 아03722 제호: 넷매니아즈 등록일자: 2015년 5월 4일 발행/편집인: 손장우 청소년보호책임자: 이수정
주소: 본사: 서울시 강남구 테헤란로 128, 3층 387호 Netmanias USA: 5214 36th Ave. NE Seattle, WA 98105 USA
Copyright ⓒ 2002-2023 NMC Consulting Group. All rights reserved.
|
Live stream chunk 들을 실시간으로 만들고 바로 전세계에 흩어져 있는 GGC 서버에 Copy 하는 일이 꽤 많아 보이네요.
=> Initial Buffering을 하고있는 동안 재생 시작되는지 또는 Initial Buffering이 끝나고 재생이 시작되는지는 클라이언트의 내부 동작으로 실측하기가 어려워 확답을 드리기 힘들것 같습니다.
2. Live Stream 에 대한 delay 는 25초 정도인거구요?
=> 말씀하신 25초의 딜레이 외에 OTT 서버에서 Live 방송이 준비하는 시간(비디오 인코딩 시간, HLS용 Manifest 생성 등) 및 네트워크 딜레이 등의 시간을 고려해야하기 때문에 실측해보면 25초 이상의 Delay가 발생합니다.
Video Performance를 얘기할때 2가지 delay factor를 얘기하곤 합니다.
1. Start Up Delay (혹은 Channel Switching Delay): 사용자가 채널 선택 후 얼마만에 영상 재생이 시작되는가? 예를 들어, 10:00:00에 play 버튼을 눌렀고 단말에 영상이 보이기 시작한 시각이 10:00:08이면 start up delay는 8초임.
이 시간은 단말 behavior(몇개의 chunk 수신 후 재생을 시작하는지)와 network delay(서버에서 LTE radio를 거쳐 단말까지 chunk가 도달하는데 소요되는 시간)에 영향을 받습니다.
2. System Delay: Live Encoder(혹은 Live Source)에서 생성한 chunk를 언제 단말이 수신하는가? 예를 들어, Live Encoder에서 chunk 1번을 생성한 시각은 10:00:00이고 단말이 이 chunk를 수신한 시각이 10:01:00이면 system delay는 1분임. (월드컵 스페인전 승부차기에서 홍명보가 골 넣은 영상은 Live Encoder/Source 대비 1분 후에 내 단말에 보임 -.-;;)
VoD 서비스의 경우 해당 chunk들이 이미 cache 서버에 저장되어 있어 이용자에게 즉시 첫번째 chunk 전달이 가능하지만 Live TV 서비스의 경우 encoder에서 생성한 chunk들이 cache 서버로 도달하기 전에 이용자가 해당 chunk를 요청하지 않도록 하기 위해, 즉 이용자들에게 끊김 없는 안정적인 서비스 제공을 위해 보통 latest chunk 보다 몇개 이전의 chunk(과거 영상)를 단말이 요청/수신하도록 합니다.
박용석님의 질문은 아마도 1번 Start Up Delay에 대한 얘기인 듯 합니다.
간단히 시험을 해 보니 단말은 3개의 chunk 수신 후에 영상 재생을 시작합니다. 단, chunk duration이 5초라고 해도 해당 chunk를 unicast로 수신하는데 걸리는 시간은 5초보다 짧습니다. 시험 당시 LTE radio 환경이 별로 좋지 않아서 인지 chunk 3개를 수신하는데 대략 7~8초가 소요되었고 영상은 play 버튼 선택 후 8~9초 후에 재생이 시작되었습니다.
여담이지만 위에서 말씀드린 delay factor는 chunk 기반의 Live 서비스에서는 감수할 수 밖에 없는 문제이며 기존 RTP 기반(packet 기반)의 서비스가 chunk 기반 보다는 delay 면에서 우수합니다.