| 리포트 | 기술문서 | 테크-블로그 | 글로벌 블로그 | 원샷 갤러리 | 통신 방송 통계  | 한국 ICT 기업 총람 |

제품 검색

| 네트워크/통신 뉴스 | 기술자료실 | 자유게시판 |  
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 
스폰서채널 |

 

  스폰서채널 서비스란?
인터넷 비디오 전문 Transparent Caching 벤더 - Qwilt 솔루션 분석 (2013.05.08)
Analysis on Qwilt Transparent Caching Solution
March 19, 2013 | By Netmanias (tech@netmanias.com)
banner
코멘트 (10)
15

 

[Last Updated: 2013년 5월 8일] 최근 몇 년 사이 국내외적으로 많은 인터넷 비디오 서비스 사업자 (OTT: YouTube, Netflix, Pooq, Naver, Tving 등)들이 출현하여 다양한 유무선 단말을 통해 고품질의 비디오 서비스를 제공하고 있다. 이러한 OTT 서비스의 성공으로 통신사업자는 “매출과 무관한 네트워크 비용 증가”와 “기존 비디오 서비스 매출 감소”라는 이중고에 시달리게 되었다. 

 

세계 각국의 통신사업자는 OTT 사업자로 인한 네트워크 비용을 최소화하고 더 나아가 OTT를 활용하여 새로운 수익 모델을 발굴하기 위해 노력하고 있으며 이는 모든 통신사업자들의 큰 숙제이다.통신사업자의 이러한 고충에 대한 해답으로 Transparent Caching 기술이 제시되고 있다. 

 

Transparent Caching 기술은 초기에는 P2P 파일을 캐싱하여 네트워크 비용을 줄이는 시도에서 시작이 되었으나 최근에는 P2P 파일보다 인터넷 비디오 파일의 유통량이 더 많아졌고 또한 비디오 파일의 캐싱은 P2P 파일과 다른 특성을 가지고 있어 비디오 캐싱에 특화된  Transparent Caching 기술 및 솔루션이 시장에서 요구되기 시작하였다. 

 

이를 충족시키는 비디오 전문 캐싱 벤더로 Qwilt (www.qwilt.com)를 들 수 있으며 본 보고서에서는 Qwilt의 솔루션 (QB-시리즈)에 대해 심층 분석하였다.

 

손장우 (son@netmanias.com)

이정훈 2013-03-19 16:52:57
안녕하세요 좋은 자료 감사합니다.


Qwilt QB장비의 구성은 tab 포트를 통해 traffic 복사해서 받으며 동영상 화일들을 caching하고 가지고 있는 동영상 관련 http request가 들어오면 단말에 redirect를 보내 자신에 접속토록 하는 구조인거죠?

redirect해서 단말이 동영상을 받아가게 하려면 최소 Qwilt 장비가 IP를 라우터와 연결된 인터페이스에 가지고 있어야 되는거죠 ?
넷매니아즈 2013-03-19 21:47:03
Qwilt QB장비의 구성은 tab 포트를 통해 traffic 복사해서 받으며 동영상 화일들을 caching하고 가지고 있는 동영상 관련 http request가 들어오면 단말에 redirect를 보내 자신에 접속토록 하는 구조인거죠?

=> 맞습니다.

redirect해서 단말이 동영상을 받아가게 하려면 최소 Qwilt 장비가 IP를 라우터와 연결된 인터페이스에 가지고 있어야 되는거죠 ?

=> 맞습니다.

* 통찰력이 대단하시네요. 3 페이지의 그림에서 1,2,3은 optical tap을 통해 양방향 트래픽을 모니터링하고 캐싱하는 과정이고, 4,5,6은 라우터에 연결된 인터페이스 (10Gbps)를 통해 Redirect, HTTP GET, 컨텐츠 다운로드하는 과정입니다.
이상흔 2013-03-19 23:22:52
안녕하세요. 저는 퀼트 코리아 APAC 기술지원을 담당하고 있는 이상흔 입니다.
저희 퀼트 제품과 솔루션에 많은 관심을 가져 주신 모든 분들께 깊이 감사 드립니다.
아울러 금일 공유된 파일은 현재 저희 퀼트가 넷매니아즈를 통해 제공하고저 하는 기술문서의 최종본은 아닙니다.
좀 더 많은 내용과 알차고 좋은 정보를 추가하여 조속한 시일 내에 업데이트 해드릴 것을 약속드립니다.
감사합니다.
이상흔 2013-03-19 23:27:25
넷매니아즈 담당자께,
2페이지, 상단 부분 .. Adaptive Bite Rate ==> Adaptive Bit Rate 수정 바랍니다.

- 퀼트 코리아 이상흔
양병두 2013-03-20 02:45:17
안녕하세요. 항상 좋은 자료에 감사드립니다. Qwilt 사의 QB의 caching 로직을 보다보면 다른 벤더사의 장비와는 다르게 유저의 http request 메세지를 분석하여 캐싱동작을 한다고 했는데요. 그럼 그동안 TIC 상세동작원리에서 말씀하셨던 초기 origin 서버로 부터 일부 컨텐츠를 받아서 행하였던 contents의 변경여부, 유료 content 보호, CP에 user behavior 제공등의 기능은 어떻게 하는 건지요??
넷매니아즈 2013-03-20 10:23:40
좋은 질문 감사합니다.

기존 벤더의 경우 (Content 일부를 해싱하여 식별자로 삼음), 자신에게 캐싱되어 있는 컨텐츠에 대한 요청이 관측되면 바로 이용자에게 컨텐츠를 전달하지 않고 반드시 오리진 서버에서 해당 컨텐츠(200 OK와 비디오 파일의 앞부분 10KB 정도)를 받은 후 이를 해싱하여 자신이 가지고 있는 해싱 리스트에서 찾아 있으면 오리진 서버로 자기가 TCP FIN을 보내고 이용자에게 자기가 캐싱하고 있는 컨텐츠를 전달해줍니다.

이 과정에서 자연스럽게 Content에 대한 Validity Check(오리진 서버에서 어제 삭제된 컨텐츠인지 아닌 지, 내가 캐싱하고 있는 파일과 오리진 서버에 있는 파일이 똑 같은 것인 지)가 되는 것이고 오리진 서버로부터 이용자가 요청한 컨텐츠가 전달되어 온다는 것은 이 이용자가 해당 컨텐츠를 수신할 권한이 있다는 것이고 또 조회수도 1 증가하고요.

Qwilt의 경우는 이를 어떻게 처리하는 지는 저도 궁금한 부분이며 추가로 분석하여 리포트를 업데이트하도록 하겠습니다.
이동욱 2013-03-20 15:24:14
일반적으로 VOD 를 위한 HTTP ABR 방식을 이용할 경우에 하나의 Meta file과 많은 chunk 파일을 생성 한 후에 전달 하는 것으로 알고 있는 본 기고에는 chunk 파일이 매번 다르다고 말씀 하셨는데, 좀 이해가 가지 않아서 여쭤보고 싶습니다.
가입자에게 Content 전달 시, 한개의 Content가 있을 경우 이를 Real time으로 매번 HTTP ABR로 변경해서 적용을 하는 것인지요?
그리고 VOD가 아닌 실시간 방송일 경우 HTTP ABR에 대한 TIC 서버의 캐싱이 가능 한지도 부탁 드리겠습니다.
넷매니아즈 2013-03-20 16:40:20
HTTP Adaptive Streaming (ABR이라고도 하지요) 방식은 애플의 HLS와 마이크로소프트의 Smooth Streaming을 들 수 있습니다.

HLS의 경우는 영화 한편을 약 10초 정도 사이즈의 청크로 미리 잘라서 오리진 서버에 올려 놉니다.
예를 들어 1시간짜리 영화가 있으면 10초 짜리 청크가 360개(1.ts 파일 ~ 360.ts 파일)가 생성됩니다.
클라이언트는 명시적으로 파일명을 적어 요청합니다(GET /...../1.ts,...,GET /...../360.ts).

반면에 Smooth Streaming은 영화 한편에 파일 하나가 나옵니다.
그리고 클라이언트가 요청할 때 0초, 2초, 4초...로 요청을 합니다(GET /..../350000/Video=0,....,GET /...../350000/Video=1798).

두 경우 모두 각 청크 사이즈는 이용자별로 다르지 않습니다.

아래 문서들을 참고하세요.
* One-Shot Gallery: HTTP Adaptive Streaming 비교
https://www.netmanias.com/bbs/view.php?id=oneshot&no=303

* One-Shot Gallery: Microsoft Silverlight Smooth Streaming - Workflow
https://www.netmanias.com/bbs/view.php?id=oneshot&no=40


그런데, Netflix의 경우는 Smooth Streaming 방식인 데, Netflix Player(Netflix가 개발)가 청크를 요청할 때
그때 그때 다른 사이즈 (화질 Profile이 같아도)의 청크를 요청한다는 점이 특이합니다.

본 보고서의 7 페이지의 윗쪽 그림처럼 서버는
KungFuPanda.ismv라는 하나의 파일을 가지고 있고
Netflix Player가 요청(GET /kungfupanda.ismv/range/0-34217...)하는 바이트 범위의 데이타를 그대로 전달해줍니다.

서버가 ABR을 위한 무슨 처리를 하는 것은 아닌거죠.

제가 아는 바로는 이렇게 동일 비디오를 시청할 때 각 청크의 사이즈를 다르게 하는(즉 이용자 A와 B가 요청하는 청크 사이즈가 다른) OTT가 Netlfix말고도 더 있는 것으로 알고 있습니다.

아마도 Netflix가 자사의 컨텐츠가 통신사업자망내에 캐싱되는 것이 싫어서 이렇게 하는 듯합니다.
김태양 2013-04-11 15:10:08
안녕하세요~~ 항상 좋은 자료를 이해하기 쉽게, 더구나 인사이트까지 담아주셔서 너무 잘 보고 있습니다.
이번 자료를 보면 넷플릭스의 비디오 요청 방식이 기존의 TIC 서버의 캐싱 능력을 무력화 시킨다고 하셨는데,
이렇게 OTT들이 TIC서버를 무력화 시키려는 이유는 무엇인가요??

contents의 변경여부, 유료 content 보호, CP에 user behavior 제공 등의 이슈만 없다면,
Telco의 TIC가 Origin 서버의 Processing Power 줄여주는 효과가 있을 것 같은데 말이죠.
넷매니아즈 2013-04-12 11:22:43
Netflix와 YouTube는 각각 Netflix Cache, Google Global Cache라는 이름의 서버를 통신사업자에게 무상으로 제공해주고 있습니다.

통신사업자도 역시 IDC 요금을 받지 않고 이 서버들을 자사 IDC에 들어오게 하고요.

YouTube와 Netflix는 저가의 서버 비용만 자신이 감당하고 매월 나가야 하는 IDC 이용 요금을 내지 않고도 자신들의 CDN을 통신사업자의 망내로 확장시켜 나가고 있는 것이지요.

OTT입장에서 보면 TIC 서버는 자신들이 control할 수 없는 장비이고 자사 Cache 서버는 자신들이 control합니다.

따라서 어떤 가입자가 어떤 컨텐츠를 선호하고 시청 습관은 어떻게 되고 전달 품질을 어떠했고 등을 모두 알 수 있겠지요.

그리고 향후 OTT가 신규 서비스를 만들었을 때 이 서비스도 자기 Cache를 통해 제공될 수도 있을 것이고요.

따라서 OTT들은 통신사업자가 TIC으로 자사 컨텐츠를 캐싱하는 것보다 자사의 Cache 서버를 통신사업자망내에 밀어 넣기를 원하는 것이고

그래서 TIC이 OTT 컨텐츠를 쉽게 캐싱하지 못하게 하는 것으로 판단됩니다.

넷매니아즈 블로그글 OTT Cache(Google, Netflix)와 통신사업자 Transparent Cache - I를 참고하세요

https://www.netmanias.com/bbs/view.php?id=blog&no=367
Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Transcript
넷매니아즈 벤더 솔루션 분석 리포트
Qwilt - 통신사업자용 비디오 캐싱 솔루션 전문 벤더

최근 몇 년 사이 국내외적으로 많은 인터넷 비디오 서비스 사업자 (OTT: YouTube, Netflix, Pooq, Naver, Tving 등)들이 출현하여 다양한 유무선 단말을 통해 고품질의 비디오 서비스를 제공하고 있다. 이러한 OTT 서비스의 성공으로 통신사업자는 “매출과 무관한 네트워크 비용 증가”와 “기존 비디오 서비스 매출 감소”라는 이중고에 시달리게 되었다. 세계 각국의 통신사업자는 OTT 사업자로 인한 네트워크 비용을 최소화하고 더 나아가 OTT를 활용하여 새로운 수익 모델을 발굴하기 위해 노력하고 있으며 이는 모든 통신사업자들의 큰 숙제이다.

통신사업자의 이러한 고충에 대한 해답으로 Transparent Caching 기술이 제시되고 있다. Transparent Caching 기술은 초기에는 P2P 파일을 캐싱하여 네트워크 비용을 줄이는 시도에서 시작이 되었으나 최근에는 P2P 파일보다 인터넷 비디오 파일의 유통량이 더 많아졌고 또한 비디오 파일의 캐싱은 P2P파일과 다른 특성을 가지고 있어 비디오 캐싱에 특화된 Transparent Caching 기술 및 솔루션이 시장에서 요구되기 시작하였다.

이를 충족시키는 비디오 전문 캐싱 벤더로 Qwilt(www.qwilt.com)를 들 수 있으며 본 보고서에서는 Qwilt의 솔루션 (QB-시리즈)에 대해 심층 분석하였다.

2013년 3월 19일
손장우 (넷매니아즈 대표이사)
www.netmanias.com

About NMC Consulting Group/Netmanias
NMC Consulting Group was founded on year 2002 and is advanced, professional network consulting company which is specialized for IP Network area like FTTH, Metro Ethernet and IP/MPLS, Service area like IPTV, IMS and CDN, Wireless network area like Mobile WiMAX, Wi-Fi and LTE.
Copyright ⓒ 2002-2013 NMC Consulting Group. All rights reserved.

인터넷 비디오 사업자(OTT)의 성공과 통신사업자의 고민

최근 몇 년 사이 국내외적으로 많은 인터넷 비디오 서비스 사업자 (OTT: YouTube, Netflix, PooQ, Naver, TVing 등)들이 출현하여 PC, 스마트 폰, 스마트 패드, 스마트 TV, 전용 STB 등 다양한 단말을 통해 고품질의 비디오 서비스를 제공하고 있다. 프로그레시브 다운로드와 HTTP Adaptive Bit Rate(ABR) 스트리밍과 같은 인터넷 비디오 전달 기술의 등장으로 IP 네트워크의 QoS를 보장받지 않아도 끊김 없는 안정적인 비디오 재생이 가능해졌고 영상 품질도 초기에는 500~700Kbps에서 최근에는 2~7Mbps까지 초고화질로 제공 되고 있어 OTT 서비스 이용자수가 폭증하고 있다. 이러한 OTT 서비스의성공으로 통신사업자는 “기존 비디오 서비스 매출 감소”와 “매출과 무관한 네트워크 비용 증가”라는 이중고에 시달리게 되었다.
즉, 이용자들이 통신사업자가 제공하는 비디오를 안 보고 OTT 사업자가 제공하는 비디오 컨텐츠를 소비하게 되어 자사의 비디오 서비스 매출 저하를 초래시킨다는 점과 OTT 사업자가 발생시키는 막대한 트래픽으로 인해 통신사업자의 국제 회선 구간, 백본망 구간 그리고 유무선 액세스망 구간에 트래픽이 폭증하고 있고 이를 감당하기 위한 네트워크 비용은 해마다 증가하고 있다는 점이다. 국내 통신사업자 A사의 경우 2012년 국제 회선의 36%가 YouTube 트래픽으로 관측되었고 또 다른 통신사업자 B사의 경우 2012년 전체 이동통신 트래픽의 53%가 OTT 사업자의 비디오 트래픽이다. 세계 각국의 통신사업자는 OTT 사업자로 인한 네트워크 비용을 최소화하고 더 나아가 OTT를 활용하여 새로운 수익 모델을 발굴하기 위해 노력하고 있으며 이는 모든 통신사업자들의 큰 숙제이다.

Qwilt Unified Universal Video Delivery Solution: 통신사업자망내 비디오 컨텐츠 캐싱

OTT 사업자는 비디오 컨텐츠의 전달을 위해 자체로 CDN 망을 구축하거나 상용 CDN 서비스를 받고 있는 데 이 서버들은 통상 통신사업자망의 외부에 위치한다. 최근에 OTT의 비디오 트래픽을 통신사업자 망내의 에지에서 캐싱하여 트래픽량을 획기적으로 줄여 네트워크 비용을 감시켜주는 Transparent Caching (약어로 TIC: Transparent Internet Caching) 기술이 상용망에 적용되기 시작하고 있다. Transparent Caching 기술은 인기있는 OTT 비디오 컨텐츠를 통신사업자망내에서 캐싱하고 이용자가 해당 컨텐츠를 요청하면 OTT 오리진 서버에서 다운로드받아 전달해주지 않고 통신사업자망내 캐싱된 컨텐츠를 전달해줌으로써 통신사업자는 국제 회선 비용과 백본 비용을 절감할 수 있고 이용자에게는 이용자 위치에서 가까운 캐싱 서버에서 컨텐츠를 전달해주므로 응답시간이 빨라 고품질의 비디오 서비스를 안정적으로 받을 수 있다는 장점을 제공한다.

Transparent Caching 기술은 초기에는 P2P 파일을 캐싱하여 네트워크 비용을 줄이는 시도에서 시작이 되었으나 최근에는 P2P 파일보다 인터넷 비디오 파일의 유통량이 더 많아졌고 또한 비디오 파일의 캐싱은 P2P 파일과 다른 특성을 가지고 있어 비디오 캐싱에 특화된 Transparent Caching 기술 및 솔루션이 시장에서 요구되기 시작하였다. 이를 충족시키는 비디오 전문 캐싱 벤더로 Qwilt를 들 수 있으며 본 보고서에서는 Qwilt의 솔루션 (QB-시리즈)에 대해 살펴 보도록 한다.

기존의 Transparent Caching 기술은 HTTP Response 메시지를 분석하여 컨텐츠를 식별하고 캐싱 동작을 수행하는 데 반해 Qwilt는 HTTP Request 메시지를 분석하여 컨텐츠를 식별하고 캐싱한다. 이용자가 OTT 서버로 비디오 요청 메시지 (HTTP GET)를 보내면 이 메시지는 옵티컬탭을 통해 QB (Qwilt사의 Transparent Caching 장비명)로 전달된다.
QB는 URI Path, URI Parameters 그리고 HTTP 헤더 정보를 이용하여 요청된 비디오 파일에 대한 식별자인 Content ID (CID)를 생성한다. 예를 들어 YouTube의 경우 HTTP Request 메시지내의 URI 파라미터 중 id (YouTube 비디오 ID)와 itag (해상도) 값 및 다양한 파라미터를 해싱하여 CID를 생성한다. 캐싱되어 있는 비디오 파일들에 대한 CID를 검색하여 요청된 비디오 파일이 캐싱되어 있는 지 확인한다. 해당 비디오에 대한 최초 요청의 경우에는 QB에 비디오 파일이 캐싱되어 있지 않으므로 Cache Miss가 발생한다. 이후 YouTube 서버로부터 옵티컬탭을 통해 비디오 파일을 전달받으면 이를 캐싱한다.
다른 이용자가 동일 비디오 파일에 대한 비디오 요청 메시지를 보내면 QB는 동일 방식으로 CID를 생성하고 Content DB를 검색한다. 이 경우 Cache Hit가 발생하고 QB는 이용자 단말로 HTTP 302 Redirect 메시지를 전달해주어 자신에게 비디오 요청 메시지를 보내게 한다. 이 때 Source IP를 YouTube 서버 IP로 하여 TCP FIN을 보내 단말이 YouTube 서버와의 TCP 연결을 해제하여 YouTube 서버로부터의 파일 다운로드를 중단시키게 한다. 단말은 QB로 비디오 요청 메시지를 보내고 QB는 해당 비디오 파일을 전달해준다.

이와 같이 Qwilt는 기존 TIC 벤더처럼 컨텐츠 자체를 해싱하여 컨텐츠를 식별하지 않고 HTTP Request 메시지를 분석하여 식별한다는 점과 이용자로부터 자신에게 캐싱되어 있는 컨텐츠에 대한 요청을 받으면 302 Redirect 메시지를 단말로 보내 자신에게 접속시켜 받아가게 하는 독특한 캐싱 로직을 가지며 이로 인해 기존 방식에 비해 네트워크 안정성, 네트워크 성능, 캐싱 성능, 캐싱 효율, 신규 수익모델 지원 등의 측면에서 다양한 장점을 제공한다.

일체형 장비

일체형 장비

Problem Description: 기존의 TIC 솔루션으로 10Gbps의 처리 용량을 지원하기 위한 구성이 아래 그림 왼쪽에 나타나있다. 캐싱 솔루션을 구성하기 위해 여러 대의 캐싱 서버, 스토리지, 스위치가 요구되며 기존 네트워크에도 트래픽 분류 및 리다이렉트를 위해 라우터에 PBR을 설정하거나 고가의 DPI 장비를 도입해야 한다. 많은 공간을 차지하고 전력 사용량이 크며 여러 장비를 관리하기 위한 운영 비용도 증가한다. 국내 통신사업자들의 국제 회선용량과 국내 통신사업자간 피어링 용량이 각각 수백 Gbps에 이르고 있는 데 이러한 기존 방식의 구성은 CAPEX/OPEX 측면에서 통신사업자에게 큰 부담을 준다. 또한 DPI 장비를 도입하거나 기존에 도입된 DPI 장비를 사용하여 TIC 솔루션을 구축하는 경우 DPI 장비와 TIC 솔루션간에 연동이 요구되기 때문에 상용망 도입전에 충분한 연동 시험과 검증을 거쳐야 하므로 즉각적인 상용망 도입이 어렵다는 단점도 가지고 있다.

Qwilt Solution: 반면에 Qwilt의 경우는 기존 네트워크에 PBR 설정을 하거나 DPI 장비를 도입할 필요없이 있는 그대로의 네트워크를 유지하면서 QB 시리즈 도입만으로 Transparent Caching을 가능케 해준다. 단일 장비로 비디오 요청 메시지 및 비디오 파일 획득, 비디오 트래픽 분류, 분석, 전달, 부하 분산을 모두 수행하며 Qwilt의 인터넷 비디오에 특화된 Transparent Caching 로직으로 인해 2U의 단일 서버로 20Gbps의 트래픽 분석 능력과 10Gbps의 비디오 전달 능력을 제공한다. 이로 인해 통신 사업자는 공간과 전력 사용량 그리고 운영 비용을 절감할 수 있다. 또한 TIC 벤더 솔루션 중 유일하게 DPI(Deep Packet Inspection)가 QB내에 내장되어 있어 정교한 트래픽 분류와 모니터링이 가능하며 DPI 구매를 위한 추가 비용이 발생하지 않는다. DPI를 사용하여 트래픽을 분류 및 리다이렉트시키는 경우에 DPI 장비와 TIC 서버간의 연동이 필요한 데 QB는 이러한 벤더간 연동 이슈를 없애주어 TIC 서버의 즉각적인 상용망 적용을 가능하게 해준다.

네트워크성능과 안정성

네트워크 성능과 안정성 (Passive Monitoring and Redirect 구조)

Problem Description: 기존의 Transparent Cache는 라우터에 PBR을 설정하여 80 포트인 패킷을 모두 TIC 서버로 리다이렉트시켜서 단말과 오리진 서버간의 HTTP 패킷을 수신한다. 즉, 통신사업자가 인터넷 비디오 파일만을 캐싱하려고 해도 일단 모든 HTTP 트래픽은 TIC 서버로 인가되고 TIC 서버가 HTTP 메시지를 분석하여 비디오 파일이 아닌 패킷들은 다시 라우터로 돌려보낸다. 즉, TIC 서버는 캐싱과 무관한 불필요한 트래픽들을 모두 처리해야 한다. 라우터는 H/W (패킷 포워딩 ASIC 칩)로 패킷을 포워딩하는 데 반해 TIC 서버는 S/W (CPU)로 패킷을 처리하므로 전체 네트워크 성능이 저하되게 된다. 또한 라우터의 PBR 설정으로 인해 웹 트래픽과 비디오 트래픽이 모두 TIC 서버를 통해 전달되므로 만일 TIC 서버가 다운되면 비디오 시청뿐만 아니라 일반적인 웹 서핑도 모두 통신 두절 상태가 된다.

Qwilt Solution: Qwilt는 Passive Monitoring and Redirect라는 독특한 구조를 갖는다. Passive Monitoring 인터페이스를 통해 양방향 패킷들은 모두 QB로 전달된다. QB내의 DPI 엔진은 HTTP Request 메시지를 분석하여 캐싱할 컨텐츠이면 (예를 들어 YouTube, Netflix, Pooq 등) 캐싱 엔진으로 보내고 아니면 버린다. 캐싱되어 있는 비디오 파일에 대한 HTTP Request 메시지를 Passive Monitoring 인터페이스를 통해 수신하면 해당 단말로 302 Redirect 메시지를 보내 자신에게 접속하여 비디오 파일을 받아가게 한다. 즉, QB가 처리하는 트래픽은 QB가 판단하여 Redirect를 보내 자신에게 컨텐츠 요청을 한 트래픽만 처리하고 일반 웹 서핑 메시지에 대해서는 Redirect를 보내지 않고 통신에 개입하지 않으므로 PBR 방식의 기존 TIC 서버와 달리 네트워크상에 전달 성능 병목점이 사라진다. 만일 QB가 다운이 되어도 단말이 보낸 비디오 요청 메시지를 Redirect하지 않게 되므로 오리진 서버로 접속하여 비디오 파일을 다운로드 받게 되고 일반 웹 서핑 트래픽은 QB와 무관하므로 통신 두절이나 성능 저하가 전혀 없다는 장점을 갖는다.

ABR 처리 성능

ABR (Adaptive Bit Rate) 처리 성능

Problem Description: 초기의 인터넷 비디오 서비스는 HTTP 프로그레시브 다운로드 (Progressive Download: PDL) 방식 위주였으나 최근에는 비디오 시청 중 발생되는 트래픽량이 작고 이용자 체험 품질이 우수한 HTTP Adaptive Bit Rate (ABR) 방식으로 진화하고 있다. PDL 방식은 한 번에 전체 파일을 요청하여 다운로드 받는 데 반해 ABR 방식은 하나의 파일을 수 초 정도 길이의 작은 청크로 조각내고 클라이언트가 비디오 시청 중에 지속적으로 청크를 요청하여 다운로드 받아가는 방식이다.

비디오 전달 방식이 PDL 방식에서 ABR 방식으로 전환되면서 기존의 TIC 서버의 캐싱 성능이 크게 저하되고 있는 데 그 이유는 다음과 같다. 기존의 TIC 서버는 비디오 파일의 앞부분 10KB 정도를 해싱하여 Content ID(컨텐츠 식별자)로 사용한다. 문제는 PDL 방식에서는 전체 파일 하나에 대해 한번의 해싱 계산만 하면 되는 데 ABR 방식에서는 예를 들어 비디오가 1시간짜리이고 청크 사이즈가 2초이면 이용자가 하나의 비디오를 시청하는 동안 1,800번의 해싱 계산을 수행해야 한다는 점이다. 하나의 TIC 서버가 2만 가입자에게 동시에 캐싱된 컨텐츠를 ABR 방식으로 전달해주는 경우에는 시간당 36,000,000번, 초당 10,000번의 해싱 계산이 필요하다. ABR 방식을 채택하는 OTT가 늘어나면서 컨텐츠 해싱 기반인 기존 TIC 서버에 대한 대안 방식이 요구되어지고 있다.

Qwilt Solution: 매 청크에 대해 해싱 계산을 수행해야 하는 Object 기반 방식과 달리 Qwilt는 HTTP Request 메시지를 기반으로 컨텐츠를 식별하고 하나의 파일에 속한 청크들을 하나의 CID (Content ID)로 관리한다. 따라서 매 청크 요청에 대해 해싱 계산이 필요없으므로 ABR 방식으로 비디오를 전달할 때 기존 TIC 서버 대비 높은 처리율을 얻을 수 있다. Tolly의 테스트 리포트에 따르면 Qwilt의 QB 시리즈는 기존 벤더 대비 5배 정도의 처리율을 제공한다[Tolly, Qwilt QB-100 Transparent Caching and Video Delivery Platform: Performance and Feature Evaluation, 2012].

ABR 캐싱 효율

ABR (Adaptive Bit Rate) 캐싱 효율

Problem Description: 미국 인터넷 트래픽의 33%를 차지하는 세계 최대 OTT인 넷플릭스는 ABR 방식으로 비디오 컨텐츠를 전달해준다. 넷플릭스 ABR 전달 방식의 특징은 아래 그림 (a)와 같이 Byte Range Request를 통해 청크 (수 초 짜리 영상 파일 조각)를 요청한다는 점이다. 그런데 특이한 점은 넷플릭스 플레이어가 요청하는 각 청크들의 시작 바이트와 끝 바이트가 그때 그때 다르다는 점이다. 아래 그림 (b)처럼 이용자 A와 B가 동일 비디오를 시청할 때 이용자 A에게 전달되는 각 청크들의 시작 바이트와 끝 바이트가 이용자 B에게 전달되는 값과 다르다.

이러한 넷플릭스의 비디오 요청방식은 기존의 TIC 서버의 캐싱 능력을 무력화시킨다. 기존의 TIC 서버는 HTTP Request 메시지를 참조하지 않고 요청된 파일의 앞부분 10KB 정도를 해싱한 값으로 컨텐츠를 식별한다. 따라서 전달되고 있는 청크들이 하나의 파일에 속한 조각들이라는 사실을 모르고 각 청크들을 별개의 파일로 인식한다. 그런데 동일 비디오 파일이 요청시마다 서로 다른 청크 사이즈로 전달이 되니 TIC 서버는 모두가 다 다른 파일이라고 인식하게 되며 따라서 Cache Hit가 발생하지 않는 것이다.

Qwilt Solution: QB의 경우에는 HTTP Request 메시지를 기반으로 컨텐츠를 식별하기 때문에 현재 전달되고 있는 청크들이 한 비디오 파일의 조각들이라는 것을 인식할 수 있고 각 청크들을 캐싱하여 넷플릭스 서버에 있는 원본 파일과 같은 하나의 비디오 파일로 저장한다. 이후 동일 컨텐츠에 대해 어떠한 바이트 범위의 요청이 와도 요청된 범위의 조각을 전달해 주기 때문에 캐싱 효율이 대폭 향상된다.

YouTube 캐싱 효율

모바일 유튜브 캐싱 효율

Problem Description: 모바일 단말에서 YouTube에 접속하여 비디오 컨텐츠를 시청할 때는 유선 PC 환경에서와 매우 상이한 비디오 요청 패턴이 관측된다. 유선 액세스망과 달리 무선 구간 네트워크 자원이 매우 제한적인 모바일 환경에서는 단말로 전달되나 보지 않는 비디오 분량을 최소화하기 위해서 클라이언트는 한번의 전체 파일을 요청하지 않고 처음에 1/2정도의 분량만 받고 이후 이용자가 계속 시청을 하면 나머지 1/4정도의 분량을 요청하고 역시 이용자가 계속 시청을 하면 나머지 1/4의 분량을 요청한다. 이로 인해 중간에 다른 비디오 시청을 위해 시청중인 비디오를 나가는 경우 발생하는 불필요한 트래픽 전달을 최소화해 줄 수 있다. 이렇게 실제 시청을 하는 분량만 전달해줌으로써 OTT 이용자는 단말에 들어와 있으나 시청하지 않은 비디오 트래픽 분량도 통신사업자에게 요금을 지불하게 되는 불합리성을 막아 준다.

문제는 동일 단말에서 OTT 사이트의 동일 컨텐츠를 다운로드 받을 때도 매번 이 1/2, 1/4에 해당하는 비디오 분량이 다르다는 점이다. 아래 그림에 갤럭시 노트에서 KT LTE망을 통해 YouTube 사이트의 원더걸스 비디오를 여러 번 시청할 때 단말에서 요청되는 Byte Range값이 약간씩 다름을 확인할 수 있다. 이로 인해 컨텐츠의 앞부분 10KB정도를 해싱하여 컨텐츠를 식별하는 Object 기반의 기존 TIC 서버는 매 조각의 앞부분이 조금씩 다르므로 매 조각을 서로 다른 컨텐츠라고 판단하므로 Cache Hit가 발생하지 않는다. 따라서 기존 TIC 서버는 TIC 도입으로 인한 트래픽량 절감을 기대할 수 없다.

Qwilt Solution: QB의 경우에는 HTTP Request 메시지를 기반으로 컨텐츠를 식별하기 때문에 현재 전달되고 있는 청크들이 한 비디오 파일의 조각들이라는 것을 인식할 수 있고 각 청크들을 캐싱하여 YouTube 서버에 있는 원본 파일과 같은 하나의 비디오 파일로 저장한다. 이후 동일 컨텐츠에 대해 어떠한 바이트 범위의 요청이 와도 요청된 범위의 조각을 전달해 주기 때문에 캐싱 효율이 대폭 향상된다. 이 장점도 넷플릭스 비디오 캐싱과 마찬가지로 인터넷 비디오 파일은 임의의 길이로 잘라진 채 전달될 수 있다는 점을 고려하여 캐싱 로직을 설계하였기 때문에 얻을 수 있는 장점이다.

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2019년 1월 현재 넷매니아즈 회원은 49,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호