기본 콘텐츠로 건너뛰기

트위치는 정말 돈이 안되어 철수 했을 까? 일반인은 몰랐던 스트리밍 서비스가 돈이 안되는 이유

일반인은 몰랐던 스트리밍 서비스가 돈이 안되는 이유.

영상 버전 : https://youtu.be/gI_rnpNTTpg



스트리밍 서비스는 크게
Netflix처럼 OTT라는 Over the top의 약자인 영화등의 콘텐츠를 온라인으로 제공하는 것과
Twitch와 같은 실시간 중계서비스를 사용하는 서비스로 나뉩니다.
CDN의 다양한 콘텐츠 딜리버리 기슬중 하나를 사용하여 서비스를 전개하고 있지요.

전 기술을 설명하는 것을 좋아하지만, 여기서 기술 이야기를 하면 다들 주무실 거 같아 패스 합니다. 

여기서 유투브, 넷플릭스같은 단방향 방송 서비스는
HLS(HTTP Live streaming)을 기반으로 서비스하는 게 보통이구요,
트위치나 아프리카 티비는 인터랙티브한 작용이 필요해서 RTMP(Real time messaging protocol)을 주로 사용합니다. 물론 HSL가 실시간 방송이 안된다는 이야기는 아닙니다. 그 기업이 어떤 프로토콜을 더 많이 쓰느냐의 차이라고 보시면 됩니다. 

많은 분들이 유투브가 돈을 많이 버니 유투브 같은 서비스를 설계해 달라고 제게 오는데요..
단연코 말씀드리는데 유투브는 손해보는 서비스 입니다.
지금은 어느정도인지는 모르겠으나,
2010년 경에는 4조원 매출에 8조원이 인프라 비용이었지요.

응? 완전 적자네요? 그런데 왜 유투브는 하고 있는거지요?

제 말을 안 믿고 그럴리 없다고
서비스 오픈 하셨다가 문닫으신 많은 분들은 아셨겠지만,
데이터센터에 서버를 놓고 네트워크 비용을 내보셨으면 아실 겁니다.
지금은 클라우드라 종량이라 덜 나갈 거 같죠?
사람들이 얼마 안들어올 서비스를 만들려면 왜 비즈니스를 하려는 겁니까?

사람이 적으면 매출이 없어서 망하고,
사람이 많으면 인프라 비용내다 망하는게 스트리망 서비스 입니다.

그럼 많은 분들이 이렇게 이야기 하시겠죠..
아마존 비디오는? 넷플락스는? 트위치는? 아프리카 티비는?

그래서 각 서비스의 구조를 설명 드리려 합니다.

우선 유투브의 수익원은 광고 입니다. 촤근 프리미엄이나 구독 기능 들을 추가하면서 수익원을 늘려가고 있었는데요..

한국에서 누군가가 유투브에 k-pop 콘서트 동영상을 올렸습니다.
그런데 필리핀에서 갑자기 그 영상의 조회수가 폭발적으로 늘었습니다.
그러면 필리핀이 한국의 네트웍에서 다운로드를 많이하기 때문에 한국에 해저 케아블 비용을 냅니다.
해저 케이블은 설치한 나라가 이용료도 받지만 사용량에 따른 통신비도 받습니다.
보통 동영상 트래픽은 2Mbps가 많죠. 해저케이블 비용은 비싸서 1Gbps당 거리에 따라 수백에서 수천만원 합니다.'

일본에 계신 분들이 한국 방송을 보는데 사람들이 몰리는 스포츠 같은건 엄청 버벅이죠?
1Gbps만 해도 수백만원인데 단순 계산으로 500명만 들어오면 터집니다.
일본에 있는 50만명 중에 몇 명이 동시에 봤을까요?
그렇다고 돈도안되는 한국 회선을 넓힐 순 없잖아요?

위의 예를 들면 필리핀도 수천만원을 들일 수 없으니 최소한으로 운영을 합니다.
그럼 품질이 낮아서 사람들은 난리치죠.

여기서 구글이 여러 통신사에 제안합니다.
자기네에 서버 1000대와 네트웍 무제한을 무상으로 주면, 유저들에게 해외 동영상을 마음껏 보게 해주겠다구요..
보통 로컬이라 불리는 국내 네트워크는 10G이상인 나라가 늘어나고 있습니다. 한국 같은 경우는 다들 아시는 롤이란 게임의 패치만으로 300Gbps를 동시 처리하는 정도의 방대한 처리도 하고 있죠..
그리고 로컬 네트워크 내에서는 직접 설치한 통신 사업자는 로컬 내 트래픽은 공짜 입니다. 
단지 장비 및 케이블 유지비 등에 써야 하므로 유저에게 통신비를 받아 유지하는 것이지요. 
즉, 저 제안을 받아들인 통신사는 유저들이 답답하지 않게 해외 동영상을 볼 수 있으므로 유저 획득을 위해 구글에게 저정도의 인프라는 줄 수 밖에 없지요..
그렇게 자기돈 하나 안들이고 90만대의 전세계에 서버를 확보 했습니다.

데이터센터는 보통 짓는데만 평균적으로 6000억원, 유지관리가 연간 수백억원에 달합니다. 데이터센터의 랙 하나, 캐비넷 처럼 생긴건데요.. 랙이 보통 45U에서 48U인데 1U사이즈의 서버를 발열 등을 생각하면 20대 정도 넣을 수 있구요, 이 랙 하나만으로 웬만한 가정집 전력이 들어갑니다. 그리고 센터는 보통 4000~8000 랙 정도를 운영하는거구요.. 그리고 정전에 대비한 UPS는 서버 대수에 가깝게 한 층에 적재 합니다. 2년마다 교체하구요.. 등등..

이걸 공짜로 전 세계에서 이용할 수 있게된 깡패가 될 수 있다는 확신으로 적자에 허덕이는 유투브를 구글이 높은 가격에 인수 한 것이죠.
초기에 인수 했을 때는 많은 사람들이 욕했습니다.
수익이 날 수 없는 비즈니스를 인수 했다구요..
지금도 수익은 나지 않지만, 구글의 많은 서비스를 공짜로 올릴 스 있는 힘을 줬기 때문에 전체 비용으로 따지면 유투브는 오히려 효자가 됬죠. 구글이 공짜로 좋은 서비스를 많이 오픈하고, 개발 프로젝트에 수만대의 서버를 그냥 개발용으로 주는 이유가 설명이 됬나요?

넷플릭스나 아마존 프라임 같은 비디오 서비스는 각 로컬에서만 시청 가능하지요? 그 이야기는 저렴한 로컬 회선을 쓰기 때문에 유저당 6달러 정도의 저렴한 비용에도 충분히 수익이 납니다. 하지만 규모가 커지기 전까지는 무조건 적자 입니다. 기본 유지비란게 엄청 크거든요..

만약 여러분이 스트리밍 서비스를 한다 칩시다.

수십Gbps의 트래픽을 해외에서 가져갈 수 있는 콘텐츠가 있다면,
이렇게 거대 자본이 인수하길 바라면서 수 년 동안 적자를 감당할 자금만 있다면 하셔도 됩니다. 수 년이 지나도 인수 안한다면 그게 전부 부채가 되겠지요.

트위치나 아프리카 티비는 이런 대규모 CDN노드를 이용하는 비즈니스가 아니기 때문에 전부 트래픽으로 커버해야 합니다.
안그러면 실시간의 의미가 없지요.. 뭐 약간의 딜레이는 용서한다면 앞에 cdn edge를 두고 해외 서비스는 할 수 있으나 인터랙트 부분은 리얼 트래픽이죠.. 떄문에 트래픽 비용은 CDN처럼 엣지의 로컬 비용만으로는 커버가 안됩니다. 
그런데 수익은 유저가 가끔 던져주는 지원금의 일부만 떼갑니다.
여기서 문제는 아프리카 티비는 서버가 한국에 있고 한국 트래픽을 중심으로 서비스 하지만, 트위치는 글로벌 서비스라 해외에서 한국에 접속하거나 한국에서 해외에 접속하는 등 해외 트래픽을 많이 먹게 되지요. 

게다가 한국의 통신사업자는 트래픽 + 망사용료라는 참신한 과금 룰을 가지고 있지요.
결국 이중으로 과금 하게 되면 수익률이 커버 안되는 사업자들은 하나둘 떠나게 되겠지요. 그러면 결국 힘든건 해저 케이블 트래픽 비용을 내야하는 통신사와 그게 불편한 유저겠지요...

때문에 유저가 별풍선이나 비츠같은 것의 무제한 과금으로 커버해주지 않는 실시간 스트리밍 서비스는 점점 수익구조가 안나와서 철수를 할 수 밖에 없게 됩니다. 

참고로 대부분의 국가는 망중립 데이터센터를 대부분 가지고 있기 때문에 해외 회선을 많이 쓰느냐 로컬 회선을 많이 쓰느냐에 따라 회선을 복수개 연결해서 라우팅을 설정해 놓는 경우가 많습니다. 물론 일본도 마찬가지지요.. 즉, 센터에서 랙을 빌려놓고 개인 인터넷 회선을 신청해도 들어와 줍니다. 


하지만, 한국은 망중립 센터는 고립시키는 담합 때문에 비즈니스를 제대로 할 수가 없었지요.. 2012년 경이었던가요? 외국계의 망중립 센터를 한국에 놓았는데 로컬망을 열어주지 않아서 로컬 접속인데 해외를 통해서 들어오는 어처구니 없는 상황이 있었는데.. 이젠 클라우드 시대라서 망중립이 중심이 되어 잘 진행되고 있겠지요? 저의 한국 정보는 좀 오래 되었으니 아시는 분 지적 부탁 드립니다. 


한국의 몇몇 통신사들은 K-콘텐츠 라는 것을 내세워서 한류 열풍이 있는 동남아 국가에 구글 같은 짓을 하려고 하고 있던게 벌써 7년은 지났는데 성공하셨을지 모르겠네요..


아뭏든.. 


점점 갈라파고스화 되가고 있는 한국을 보면서 

조금이라도 정보가 공유되었으면 하는 마음에 

이 콘텐츠를 만들어 봤습니다. 




giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

댓글

이 블로그의 인기 게시물

Alter table 에서 modify 와 change 의 차이 :: SQL Server

두 개의 차이를 모르는 경우가 많아서 정리합니다.  modify는 필드의 속성값을 바꿀때 사용하구요.. change는 필드명을 바꿀떄 사용합니다.  alter table tbbs modify bNote varchar(2000) NULL; alter table tbbs change bNoteOrg bNoteNew varchar(2000) NULL; change에는 원래 필드와 바꾸고 싶은 필드명을 넣어서 필드명을 바꾸는 것이죠~ 더 많은 SQL Server 팁을 보려면  https://github.com/LowyShin/KnowledgeBase/tree/master/wiki/SQL-Server giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  https://www.youtube.com/watch?v=ZZlW6diG_XM 대규모 트래픽을 커버하는 첫 페이지 만드는 법..  보통 DB를 연결할 때 대규모 설계는 어떻게 하시나요?  잘 만들었다는 전제 하에 동접 3000명 이하는  어떤 DBMS를 사용해도 문제 없이 돌아갑니다.  여기서 이미 터졌다면 이 콘텐츠를 보기 전에 DB의 기초부터 보셔야 합니다.  아.. 개발 코드가 터졌다구요? 그럼 개발자를 때리셔야지요..  만약 3000명을 넘겼다면? 이제 Write/Read를 분리해서  1 CRUD + n개의 READ Replica를 만들겠죠?  보통 Read Replica는 5개가 최대라고 보시면 됩니다.  누가 연구한 자료가 있었는데...  6번째 레플리카를 만든느 순간 마스터가 되는 서버의 효율 저하 때문에  5번째에서 6번쨰로 올릴때의 성능이 급격히 줄어든다는 연구 결과가 있습니다.  때문에 Azure에서도 replica설정할 때 5대까지 밖에 설정 못하게 되어 있지요.  유저의 행동 패턴에 따라 다르긴 하지만,  1 CRUD + 5 Read Replica의 경우 동접 15000명 정도는 커버 합니다.  즉, 동접 15000명 에서 다시 터져서 저를 부르는 경우가 많지요..  이 때부터는  회원 DB, 게시판DB, 서비스DB, 과금 DB 등등 으로 성격, 서로의 연관도에 따라 나누기 시작합니다.  물리적으로 DB가 나눠지면 Join을 못하거나 Linked Table또는 LinkDB등의 연결자를 이용해서 JOIN이 되기도 합니다.  그에 따라 성능 차이가 생기지만 가장 중요한 포인트는  서로 다른 물리적 테이블의 JOIN은 인덱스를 타지 않는다!  라는 것입니다. 즉, JOIN할 테이블들을 최소한으로 만든 뒤에 JOIN을 걸지 않으면 NoSQ...

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만...