넷플릭스에서 play버튼을 눌렀을 때 일어나는 일

Netflix와 같은 대용량 미디어를 스트리밍 하는 서비스라면 AWS같은 클라우드 서비스에서의 S3와 같은 정적 파일들을 놓는 CDN에서 스트리밍을 해줄 것이라 생각하겠지만, 얼추 맞지만 100%맞는 말은 아니다.

AWS와 Open Connect

넷플릭스는 물론 클라우드 서비스를 이용하지만, AWS만 사용하는게 아니라 Open Connect라는 클라우드 또한 이용한다. 두 클라우드는 사용자가 만족할 정도로 영상 재생 환경을 제공하기 위해 긴밀히 협력한다.

클라이언트, 백엔드 그리고 CDN

넷플릭스는 크게 클라이언드, 백엔드, CDN로 나뉜다.

클라이언트의 경우는 디바이스를 막론하고 넷플릭스 비디오를 재생하고 비디오를 탐색할 수 있도록 UI를 제공한다. 클라이언트에서 플레이 버튼을 누를 때는 백엔드 단의 AWS가 먼저 작동한다. 새로운 영상이 나왔으면 이를 준비하거나 모든 디바이스에서 오는 요청들을 처리한다.

이후에 모든 일은 Open Connect의 몫이다. Open Connect는 Netflix가 자체 설립한 글로벌 CDN(Content Delivery Network)으로, 전세계에 비디오들을 보관한다. 플레이버튼을 누르면 이 Open Connect 서버와의 연결을 시도하고, 비디오 스트림을 보내준다. 클라이언트는 이를 받아 띄워준다.

흥미롭게도 넷플릭스에서는 ‘재생 버튼을 누른다’는 표현 대신 ‘start on a title(타이틀부터 시작한다)’는 표현을 씁니다. 업계마다 고유의 언어가 존재하는 셈이다.

넷플릭스는 우리가 비디오을 보는 경험을 시작부터 끝까지 세밀하게 컨트롤한다.

2008년부터 AWS로 옮기기 시작한 Netflix

넷플릭스는 1998년에 서비스를 시작했는데 당시에는 미국 우체국을 통해 DVD를 배송하는 방식이었다.

(1999년 당시 넷플릭스는 DVD 대여 서비스만 운영했다. 리전드..)

하지만 넷플릭스는 스트리밍 영상이 미래라는 점을 일찍이 내다보았습니다.

2007년, 넷플릭스는 스트리밍 기반 주문형 비디오(Video-on-Demand) 서비스를 시작했습니다. 구독자는 넷플릭스 웹사이트 또는 다양한 디바이스에서 시리즈나 영화를 스트리밍할 수 있게 되었다.

(2008년 당시 넷플릭스는 스트리밍 서비스를 도입하며 UI가 변화함)

당시 많은 스타트업들이 비디오 온디맨드 서비스를 시도했으나 실패했었다. 반면, 넷플릭스는 실행력에서 뛰어났고, 무엇보다 시기가 적절했기 때문에 넷플릭스 성공할 수 있었던 환경이 되었다. 2007년 무렵 인터넷 속도는 충분히 빨라졌고, 데이터 요금도 저렴해졌으며, 스마트폰과 태블릿 같은 기기의 등장으로 사용자들이 언제 어디서나 쉽게 영상을 시청할 수 있게 된 시점이었기 때문이다. ~~인생은 타이밍~~

넷플릭스의 자체 데이터 센터

2007년 EC2는 막 시작된 단계였고, 넷플릭스가 EC2 기반으로 스트리밍 서비스를 시작하는 것은 불가능했다.

그래서 넷플릭스는 서로 인접한 위치에 두 개의 데이터 센터를 지었다. 하지만 이 과정에서 여러 문제를 겪게 된다(후술함).

장비를 주문하고 설치하는 데 너무 많은 시간이 걸렸고,
장비가 다 세팅된 후에도 얼마 지나지 않아 용량이 부족해지는 문제가 반복되었다.

이러한 이유로 넷플릭스는 대형 서버를 중심으로 한 ‘수직 확장(vertical scaling)’ 전략을 채택했습니다. 즉, 모놀리식(monolithic) 아키텍처 (하나의 거대한 프로그램이 모든 기능을 처리하는 구조) 로 서비스 운영을 시작했죠.

하지만 빠르게 성장하던 넷플릭스에 있어 모놀리식 구조는 유지보수와 확장성 측면에서 매우 어려운 구조였고, 결국 심각한 문제로 이어졌습니다.

장애가 넷플릭스를 AWS로 옮기게 만들다

2008년 8월, 넷플릭스는 데이터베이스 손상으로 인해 무려 3일 동안 DVD 발송을 중단해야 했는데, 이는 심각한 문제였다. 넷플릭스는 이를 계기로 과감한 결정을 내리게 됩니다.

넷플릭스는 자신들이 데이터 센터를 짓는데 그렇게 잘 하지 않는다는 사실을 쿨하게 인정해버리고 데이터센터를 어떻게 잘 지을까보다는 콘텐츠를 어떻게 잘 전달할까에 대해 더 집중하는 것을 택했다.

결국 넷플릭스는 데이터 센터 구축과 유지 관리를 포기하고, 그 대신 AWS와 같은 클라우드 서비스를 이용하기로 결정했다.

당시 AWS는 막 성장하던 단계였기 때문에 이 결정은 도전적이었음에도 선택한 이유가 있다.

넷플릭스가 AWS를 선택한 이유

신뢰성 있는 인프라를 갖추기 위함
단일 장애 지점을 없애기 위한 아키텍처 개선
AWS는 고가용성 데이터베이스, 스토리지, 중복된 인프라를 제공
글로벌 서비스 확장을 위한 클라우드 기반 글로벌 접근성 확보
직접 데이터 센터를 짓는 것보다 빠르고 효율적임

이러한 부분을 AWS에서 대부분 효율적으로 도와주었기 때문에, 넷플릭스는 사용자에게 콘텐츠를 효율적으로 제공하는 것 외의 “구분되지 않은 무거운 작업(undifferentiated heavy lifting)” 을 하고 싶어하지 앟았다. 영상 콘텐츠 제공이라는 핵심 가치에 집중하기 위해, 서버 설치나 인프라 운영 같은 본질적이지 않은 작업은 AWS에 맡기겠다는 회사의 가치관에 따라 AWS와 넷플릭스는 협업하게 되었다. 그래서 지금도 수백수천개의 EC2 인스턴스가 넷플릭스용으로 떠있다.

안정적인 AWS

물론 AWS 위에서도 장애는 발생할 수 있지만, 넷플릭스는 이전보다 훨씬 더 높은 안정성을 확보했다. 넷플릭스는 3개의 AWS 리전(region) 에서 서비스를 운영하는데,

미국 버지니아 북부
미국 오리건 포틀랜드
아일랜드 더블린 의 리전에서 운영한다.

각 리전 안에서도 3개의 가용 영역(Availability Zone) 에서 중복적으로 운영됩니다(리전을 추가할 계획은 아직 없다고 한다)

리전 장애 시 자동 회피하기(Evacuating a Region)

3개의 리전을 운영하는 가장 큰 이유는 한 리전이 완전히 망가져도 다른 리전이 서비스 제공을 이어받을 수 있기 때문이다.

예를 들어, 당신이 영국 런던에서 넷플릭스를 시청 중이라면, 일반적으로는 더블린 리전과 연결됩니다.
그런데 더블린 리전 전체에 장애가 생기면 어떻게 될까요? 그럼 넷플릭스는 이를 감지하고 버지니아 리전으로 자동 전환시키기 때문에, 사용자는 이에 대해 장애를 느낄 수 없다. 레이턴시는 조금 느낄 수 있겠지만 아예 작동하지 않는 것보단 훨 낫다.

넷플릭스는 이를 테스트하기 위해 매달 일부러 리전 하나를 죽이는 테스트를 하면서 시스템이 지역 전체 장애를 감당할 수 있는지 검증하느넫, 이 테스트는 6분 안에 리전을 비우고 전환 완료한다고 한다.

이 방식을 넷플릭스는 Global Services Model이라고 부르며, 어떤 사용자든 어느 리전에서든 서비스를 받을 수 있도록 만든 것입니다. 이건 AWS가 자동으로 해주는 기능이 아니라 넷플릭스가 직접 모든 것을 구축했다.

돈 굳은 넷플릭스

넷플릭스는 AWS 클라우드의 가용성 덕분에 직접 데이터센터를 구축하는 것보다 싸게 먹힌다. 최대한의 트래픽이 몰릴 때를 대비해서 서버를 미리 많이 만들어 놓느니, 차라리 그냥 인스턴스가 커지거나 작아지면서 트래픽을 조절하는게 훨씬 효율적이기 때문이다.

Play 버튼을 누르기 전에 일어나는 일

비디오를 서빙하는 것 외의 어떤 일이든 AWS에서 주로 다룬다.(컴퓨팅 조절, 스토리지, 비즈니스 로직, 분산 데이터베이스 , 분석 등등..)

Scalable computing and scalable Storage

Scalable computing and scalable Storage는 확장 가능한 서버와 스토리지를 의미한다. AWS에서는 EC2 인스턴스와 S3이다. 주로 넷플릭스 안에서 쓰이는 API와 같은 것들을 의미한다.

Scalable distributed database

넷플릭스는 DynamoDB와 Cassandra를 분산 데이터베이스에서 사용한다.

Cassandra 분산형 NoSQL 데이터베이스(DB)로, 대량의 데이터를 빠르고 안정적으로 처리할 수 있도록 설계되었다. 특히 쓰기 성능이 뛰어나고, 장애에 강한 구조로 유명하다.

분산되었다는 뜻은 하나의 컴퓨터가 아닌 여러대의 컴퓨터에서 데이터베이스가 돌아간다는 뜻이다. 그래서 사용자 데이터베이스가 하나 실패했다고 해서 날아갈 일이 없다. 세 개의 다른 리전으로 복사돼어 있기 때문이다.

Big data processing and analytics

넷플릭스는 전세계 사람들이 보고 있는 콘텐츠를 언제 어디서 보는지 알고 있다. 이 뿐만 아니라 어떤 비디오를 슬쩍 넘기는지, 자주 어떤걸 보는지 등등의 데이터를 다 가지고 있다. 여기서 이 데이터를 표준화된 형식으로 만드는 것을 처리(processing) 이라고 한다. 처리된 데이터는 특정 질문에 따라 분석(analytics) 된다.

이러한 데이터를 활용하는 대표적인 예는 헤더 이미지이다.

요 리스트에서 나오는 것들이 헤더 이미지이다. 썸네일이라고 이해하면 더 편하다. 이 이미지들이 모든 사람에게 똑같이 나오는 것이 아니라, 내 사용자 활동에 따라서 이에 따른 헤더 이미지가 결정이 되는 것이다.

내가 영상을 누르면 그 영상을 눌렀을 때 떠있던 썸네일 이미지의 정보도 함께 넷플릭스 서버쪽으로 간다. 그렇게 사용자들이 제일 많이 누른 썸네일이 고정되는 방식이다. 이러한 방식은 data-driven방식이라고도 불린다. 이러한 객관적인 데이터를 기반으로 최고의 헤더 이미지를 고른다.

하지만 개별로도 취향이 다를 수도 있어 이러한 부분은 명확하게 나누기가 애매하다. 그렇기 때문에 넷플릭스는 이러한 부분을 개인화시켜 각 개인이 느끼는 가장 좋은 썸네일을 고른다.

위의 예시는 굿 윌 헌팅이라는 영화인데, 사진 내의 위처럼 로맨스 영화를 많이 보면 훈훈한 분위기의 썸네일이 나오고, 아래처럼 코미디를 많이 보면 다른 느낌의 사진으로 나온다. 이 외에도 좋아하는 배우와 관련된 영화를 많이 봤다면 그 배우의 사진 위주로 나온다거나 하는 등 넷플릭스는 사용자 경험을 위해 별 이상한 것들을 많이 만들고 있다. 이러한 사소한 노력들임에도 불구하고 사용자 경험에 얼마나 노력하는지 알 수 있다.

Recommendations(추천)

넷플릭스에서 영화나 드라마 등 볼 것들은 수천개인데 내 화면에는 4~~50개정도밖에까지 뜨지 않는다. 그럼 이 4~~50개의 비디오는 어떻게 고르냐면 머신 러닝을 통해 결정한다. 위에서 말한 것처럼 사용자의 활동 내역을 많이 수집하는 넷플릭스는 이를 학습시켜 내가 좋아할만한 영상들을 예측한다.

내가 보는 영상 트랜스코딩하기

트랜스코딩 서버가 클라이언트의 요구에 맞는 문서가 아예 없다면 에러로 응답하는 것이 맞지만 이론적으로 서버는 기존의 문서를 클라이언트가 사용할 수 있는 무언가로 변환할 수 있는데, 이를 트랜스코딩 이라고 한다. 이러한 트랜스코딩에는 포맷 변환, 정보 합성, 내용 주입 세 종류가 있다. 내용 협상과 트랜스코딩

여기서부터가 넷플릭스가 어떻게 비디오 영상들을 다루는지 시작된다. 넷플릭스는 내가 가장 자주 쓰는 디바이스에서 비디오를 보기 전에, 내 디바이스에 가장 잘 맞는 포맷으로 비디오를 변환한다. 이 과정을 트랜스코딩이라고 한다.(자세한 설명은 위에) 넷플릭스는 비디오를 AWS 클라우드 환경에서 CPU를 사용해서 모든 비디오들을 인코딩해놓는다

source media들의 source

배급사나 스튜디오에서 보내는 비디오는 source media라고 한다. 새로운 비디오는 넷플릭스의 Content Opertaion Team 으로 가서 처리된다.

비디오는 가장 퍼포먼스를 잘 낼 수 있는 포맷으로 보내기 때문에 사이즈가 테라바이트급이다. 60프레임이라고 치면 초당 60장의 사진을 내보내는 셈이니 그럴만하다.

그래서 비디오를 보기 전에 여러 프로세스를 거친다.

Source Media -> Media Pipeline -> Encoded Files

비디오 무결성 검증

가장 먼저 넷플릭스는 비디오의 무결성을 검사한다. 이전 트랜스코딩 시도나 중간에 오류로 색 변환이나 프레임이 사라지는 등 문제들이 있는지 검증한다.

media Pipeline으로 보내기

비디오가 검증되면 media Pipeline이라는 곳으로 보내진다. 파이프라인은 데이터가 사용가능하도록 보내는 작업을 거치는데, 이 과정에서 비디오를 작은 chunk 단위로 쪼갠 다음, 병렬적으로 인코딩이 처리되도록 한다. 병렬적으로 처리하지 않으면 너무 오래걸리기 때문이다. 또한 이 파이프라인에서 원래 비디오를 병렬적으로 처리하되, 순차적으로 데이터를 받도록 한다. 넷플릭스가 AWS EC2 인스턴스를 많이 쓰는 이유가 바로 이 이러한 인코딩 과정에서 여러 청크들을 인코딩할 수 있도록 하기 때문이다.

만들어진 무더기 파일들

인코딩된 파일들은 한개가 아니라 여러개다. 넷플릭스는 인터넷이 연결되어있는 디바이스라면 어디든 재생 가능하도록 만드는 것이 목표이기 때문에 핸드폰 뿐만 아니라 TV, 심지어는 엑박이나 닌텐도 같은 곳에서도 돌아갈 수 있도록 한다. 그렇기 때문에 디바이스 별로 포맷을 맞춘 영상을 여러개 만드는 것이다. 돌아갈 수 있는 디바이스만 2200개 이상이다;;

이 과정에서 생기는 다양한 종류의 포맷의 비디오들을 encoding profile 이라고 한다.

넷플릭스는 네트워크 속도에 따라서 최적화된 파일들 또한 만들어놓는다. 좋은 네트워크에서는 고화질의 영상을 내보내고 느린 네트워크에서는 저화질로 바뀌어 보여진다.

넷플릭스는 각각의 오디오 포맷에 따라서도 파일들을 만들어 놓는다. 각각 다른 음질과 언어 등에 따른 오디오 포맷을 제공한다. 이와 함께 자막은 덤.

여기서 이렇게 말하면 제대로 감이 오지 않을 수 있다. 실제 예를 들어보자면 기묘한 이야기 시즌2의 경우는 8K로 촬영돼서 처리만 190,000 CPU 시간이 걸렸다고 한다.

CPU Hour CPU 한 개(core)를 1시간 동안 100%로 사용한 시간

그렇게 나온 미드 한 시즌에 대한 파일이 비디오, 오디오, 텍스트 합쳐서 9570개이다..

비디오 스트리밍 과정에서의 세 가지 전략

넷플릭스는 세 가지 다른 비디오 스트리밍 전략을 가지고 있다.

작은 CDN
서드파티 CDN
Open Connect

왜 CDN을 구축할까?

이제까지 위에서 설명했던 것과 같이 전 세계에 퍼져있는 사용자들이 하나의 원 서버로 들어오게 되면 이에 대한 부하가 만만치 않기 때문에 CDN을 통해 부하를 분산함과 동시에 지리적으로 가까운 곳에서 파일들을 가져오면서 레이턴시를 줄일 수 있다. 이와 함께 안정적으로 콘텐츠를 전달한다는 점도 크게 작용한다.

각 비디오 콘텐츠를 가지고 있는 컴퓨터의 지역은 PoP(Points of Presence) 라고 불린다. 인터넷을 통해 제공할 수 있는 물리적인 지역이다. 서버, 라우터, 다른 통신 장비 등을 보관한다.(후술함)

첫 CDN은 너무 작았다

2007년 넷플릭스가 처음 스트리밍 서비스를 시작할 때도 사용자는 약 50개국에서 3600만 정도의 사용자를 가지고 있었다. 매달 수조 초의 비디오를 보며, 초당 테라바이트의 콘텐츠 전송을 하고 있었다. 그래서 스트리밍 서비스를 보완하기 위해 넷플릭스만의 CDN을 미국의 5개 지역에 구축했다. 그때 당시만 해도 전 세계의 콘텐츠를 담진 않았기 떄문에 CDN이 그렇게 크진 않았다.

두 번째 CDN은 너무 컸다

2009년 넷플릭스는 서드파티 CDN을 사용하기로 결정한다. 당시 서드파티 CDN의 가격이 내려가고 있었던 당시 합리적인 선택이었다. 그래서 Akamai, Limelight, Level 3와 같은 CDN 서비스 제공자 회사들과 계약하고 그쪽에 콘텐츠 제공 업무를 맡기고 다른 프로젝트에 집중했다. 심지어 크게 써서 NFL 경기 하나 스트리밍에만 하나의 CDN을 썼다.

여기서 집중한 프로젝트의 경우 네트워크 상태에 따라 유동적으로 적응할 수 있는 클라이언트, 에러 처리, 네트워크 과부하, 서버 과부하 등의 업무들을 처리했다. 여기서 넷플릭스 만의 비디오 소스를 스위칭 하는 기술 등이 개발되었다.

이와 동시에 AWS 서비스에서도 많은 노력을 쏟고 있었는데, AWS를 control plane이라고 불렀다.

Control plane 시스템을 관리·조정·통제하는 뇌 역할을 하는 부분

당시에는 CDN 만드는 것보다 이걸 더 잘할 거라고 생각했다.ㄱ

Open Connect는 적절했다.

2011년 넷플릭스는 네트워크 효율성을 최대화할 CDN의 필요성을 느끼고 Open Connect 개발에 들어갔다. 당시 넷플릭스의 주 경쟁력은 이러한 비디오 분산에 있었기 때문이다. 그렇게 2012년 Open Connect가 시동됐다.

Open Connect는 서드파티 CDN보다 더 싸고 좋은 퀄리티를 제공하며, 스케일 조정이 용이했기 때문에 넷플릭스에 많은 이점을 가지고 왔다.

CDN의 기반이 되는 OCA

OCA는 Open Connect Appliance의 약자로, OCA는 넷플릭스가 동영상 저장을 위해 자체 개발한 장비이다.

이 장비는 여러대의 서버에서 각 서버당 몇 개씩의 OCA로 구성된다. 각 OCA 는 빠른 서버로 큰 파일을 보내는데 효율적인 장비이다. 많은 하드 디스크와 플래시 드라이브로 이루어져 있어 큰 파일을 전달하는 데 효율적이다.

이렇게 생겨먹었다. ~~로고 색상으로 장비 만드는 광기~~

이 장비는 크기에 따라 사용하는 용도가 조금씩 다르다. 가장 큰 장비의 경우에는 모든 넷플릭스의 비디오 카탈로그를 담아내고, 작은 장비의 경우에는 일부만 저장할 정도의 용량이 되기 때문에 proactive chaching이라는 작업을 매일 크게 부하가 일어나지 않을 떄 진행된다.

하드웨어 관점에서는 상용 PC 부품을 사용하며 맞춤형 케이스에 조립된다. 소프트웨어 관점에서는 FreeBSD 운영 체제와 웹 서버로 NGINX를 사용하면서 웹 서버를 통해 스트리밍을 제공한다.

FreeBSD 유닉스 계열의 오픈소스 운영체제(OS) 성능, 안정성, 보안성에서 강점을 가지며, 주로 서버 환경에서 많이 사용된다.

OCA의 개수는 넷플릭스가 얼마나 신뢰성 있기를 바라는가에 따라서 개수가 달라질 수 있다.

내가 Play 버튼을 누르면, 특정 내 주변에서 가까운 OCA에 연결되어 비디오를 스트리밍 받게된다. 이러한 보는 환경을 개선하는 가장 좋은 방법은 가까운 곳에 캐싱 하는 것이다.

OCA는 어디에 있을까?

해당 사진이 전 세계에 분포되어 있는 넷플릭스의 CDN이다.

넷플릭스는 이러한 환경을 제공하기 위해 네트워크를 연결해야 하는데, 데이터센터를 포기한 만큼 자기들의 네트워크를 사용하는게 아니라 인터넷 제공자(ISP)와 계약하여 ISP의 데이터센터에 OCA를 놓았다. 우리가 알다시피 한국에서는 kt, u+, skt 등이 있는데, 유플러스와 계약하여 유플러스에 OCA를 놓았다. 그래서 유난히 유플러스에서는 넷플릭스가 빠르지만 다른 통신사 쓰는 사람들은 좀 더 느리다.

https://brunch.co.kr/@jordan777/2685

ISP 뿐만 아니라 IXP에서도 놓았다. 인터넷 서비스 공급자(ISP), CDN 등의 인터넷 인프라 회사가 서로 연결되는 물리적 위치인 IXP에 OCA를 설치함으로써 데이터 센터를 짓지 않고도 데이터센터의 이점만 누리면서 자신들이 원하는 바를 이루어내었다.

IXP는 전 세계 위 사진처럼 분포되어 있을 정도로 매우 많다.

더 자세히 들여다보면 이런 케이블들이 있다. 각 선들은 하나의 네트워크에서 다른 네트워크로 이동하는 과정에서 연결시켜주는 길과 고속도로와 같은 존재이다.

IXP를 보면 이렇게 전 세계에 네트워크들이 연결되어 있는 느낌인데, 그러다 보니 이 IXP에 OCP를 놓으면서 데이터 센터를 구축할 필요가 없어진 것이다.

비디오 캐싱

넷플릭스는 모든 비디오를 S3에 올려놓는다. 그리고 이 영상을 서빙하는 서버도 가지고 있다. 근데 비디오는 어떻게 전달할까? 넷플릭스는 proactive caching이라는 기법을 사용한다. 해당 기법을 사용해서 효율적으로 OCA들이 영상을 복사해가도록 하는 것이다.

그렇다면 이 효율적으로라는 방식은 어떻게 정하는 걸까? 바로 넷플릭스는 예측을 통해 내가 보고 싶은 영상을 미리 캐싱해놓는 것이다. 위에서 말한 것처럼 넷플릭스는 데이터에 진심이고 이러한 예측에 높은 정확성을 가지고 있기 때문에 가능하다. 그래서 이러한 데이터들을 기반으로 예측하고, 내가 내일 볼 것 같은 영상을 미리 캐싱해놓는 것이다. 이렇게 영상을 각 위치에 복사하는 행위를 Prepositioning 이라고 한다. 그렇게 함으로써 우리는 보고 싶은 영상을 빠르게 제공받아 볼 수 있다.

매일 밤마다 OCA는 AWS 서비스에 있는 서비스에게 어떤 영상을 캐싱할지 물어본다. 그러면 AWS는 예측에 기반하여 이렇게 캐싱할 리스트를 보내 주는 것이다. 만약 하나의 OCA에 없다면 로컬 OCA에서 찾기도 한다. 핵심은 매일 밤마다 조용히 함으로써 ISP 대역폭을 감소시킨다는 것이다.

넷플릭스에서는 이러한 캐시를 해야 할 영상을 모두 알고 있기 때문에 캐시 미스가 날 일이 없다. 만약 난다 하더라도, 작은 OCA에서 캐시미스 나면 조금 더 큰 OCA에서 다시 찾아가면 있다.

귀찮아서 그냥 다 복사할 수도 있겠지만 3페타바이트가 넘은 정신나간 용량의 콘텐츠를 모두 담게 된다면 이걸 담는 것도 꽤나 비용이 들기 떄문에 효율적인 성택이다.

OCA 호스팅

근데 이런 넷플릭스가 OCA를 ISP에 설치했다고 하느데 ISP에서는 이걸 왜 허락해줬을까에 대해 문득 굼금해질 수 있다.

우리가 사용하는 인터넷 서비스는 모두 ISP들이 있기에 네트워크를 전달해주고 이를 통해 원할하게 인터넷을 사용할 수 있다. 이 인터넷을 통해 모든 네트워크들이 연결되고 정보를 공유할 수 있기 때문이다. 인터넷이 없는 연결선은 네트워크이지, 인터넷이 아니다.

일반적인 인터넷 트래픽의 흐름을 생각해보자. 사용자가 웹 브라우저에 검색어를 입력하고 엔터를 누르면 요청은 사용자의 ISP를 통해 이동한다. 요청 대상이 ISP 네트워크에 없다면 요청은 인터넷 백본으로 이동하게 된다. 또한 인터넷은 사적으로 소유된 많은 네트워크가 상호 연결되어 있으며, ISP 네트워크는 인터넷 백본을 통해 IXP에서 네트워크들이 서로의 트래픽을 공유한다.

그렇다면 OCA 호스팅 시에는 넷플릭스 비디오 트래픽은 어떻게 갈까? 넷플릭스는 OCA 클러스터를 ISP의 네트워크 내부에 배치함으로써, 사용자가 비디오 시청 버튼을 누르면 넷플릭스 클라이언트는 가장 가까이에 있는 특정 OCA에서 비디오를 스트리밍하는데, 이 때 비디오 트래픽이 ISP 네트워크 내에서만 이동하며, 인터넷 백본으로 나가지 않는다.

인터넷 백본으로 나가지 않는다는 부분이 중요하다. 넷플릭스는 미국 인터넷 트래픽의 37% 이상을 소비할 정도로 엄청난 양의 비디오 트래픽을 발생시키기 때문에 이렇게 OCA를 ISP 네트워크 내부에 호스팅 하지 않으면 트래픽을 감당하기 힘들다. 하지만 그렇다고 ISP로 가는 네트워크의 트래픽을 무시할 수 있는 것은 아니다. ISP는 폭증하는 트래픽을 처리하기 위해 훨씬 더 많은 네트워크 용량을 추가해야 하며, 이는 구축하는 데 비용이 많이 든다.

그래도 나름 ISP도 가지는 이점은 있다. OCA를 ISP 네트워크 내에 배치하게 되면, 넷플릭스 콘텐츠가 다 ISP 네트워크 내부에서 제공되기 때문에, 인터넷 백본까지 트래픽을 감당할 수 있을 정도의 인프라를 구축하지 않아도 되고, 인터넷 백본의 부하가 줄어들어 모든 사용자의 네트워크 성능 향상을 기대할 수 있다. 추가적으로 더 가까운 ISP 쪽에서 제공되는 영상을 통해 레이턴시를 더 줄일 수 있으며, 고품질의 시청 경험을 제공할 수 있다.

결국 서로에게 이득이 되는 전략인 것이다.

신뢰성과 복원력

Open Connect는 앞서 말한 것처럼 AWS 세 개의 다른 리전을 사용하면서 신뢰성을 높였다. 이 중에서도 가장 중요한 점은 OCA가 전부 독립적으로 작동한다는 점이다. OCA는 마치 자급자족적으로 동영상을 제공하는 아키텍처를 사용하면서 다른 OCA의 실패에 영향을 받지 않기 때문에, 완전히 동영상 스트리밍이 멈출 가능성이 거의 없다(레이턴시는 길어질 수 있겠지만)

Open Connect 시스템은 다양한 문제 상황에서도 계속 서비스를 제공하기 위한 다양한 대책을 마련해놓았다.

OCA 실패 시 → 만약 스트리밍 중인 특정 OCA가 실패하면, 시청에 사용 중인 넷플릭스 클라이언트가 즉시 다른 OCA를 찾아 연결하고 스트리밍을 재개합니다2. 사용자는 거의 눈치채지 못할 정도로 빠르게 전환
과부하 시: 한 위치에 있는 특정 OCA에 너무 많은 사용자가 몰리거나, 사용자의 네트워크가 과부하될 경우, 넷플릭스 클라이언트는 자동으로 부하가 더 적은 다른 OCA를 찾아 사용
네트워크 품질 저하 시: 만약 사용자의 네트워크 품질이 저하되어 스트리밍이 원활하지 않으면, 클라이언트는 단순히 비디오 품질을 낮추는 것을 넘어, 성능이 더 좋은 네트워크에 있는 다른 OCA를 찾아 연결

이러한 작동 방식 덕분에 Open Connect는 매우 신뢰성 있고 복원력 있는 시스템으로 꼽힌다.

넷플릭스 클라이언트

넷플릭스는 모든 디바이스에 대한 클라이언트를 직접 조작하기 떄문에 이런 실패에 대해 유연하게 잘 처리할수 있다. 각 네이티브 앱부터 시작해서 스마트 TV 등에 대해서도 클라이언트를 직접 만드는데, 이에 대한 SDK를 만들었기 때문에 클라이언트에 대해서도 큰 지분을 가지고 있다.

총정리

다시금 넷플릭스가 플레이 버튼을 눌렀을 때 일어나는 일에 대해서 정리하자.

재생 요청 전송: 사용자의 장치(디바이스)에서 실행되는 넷플릭스 클라이언트는 사용자가 재생하려는 비디오를 식별하는 재생 요청을 AWS에서 실행 중인 넷플릭스의 Playback Apps 서비스로 보냄.
라이센스 확인: 자료에서는 자세히 다루지 않지만, Playback Apps 서비스는 요청을 받은 후 해당 비디오를 사용자의 위치에서 시청할 수 있는 유효한 라이선스가 있는지 확인하는 과정을 거친다. 넷플릭스가 자체 콘텐츠 제작에 나선 이유 중 하나가 전 세계 동시 출시를 막는 라이선스 문제를 피하기 위함이기도 하다.
OCA URL 목록 반환: Playback Apps 서비스는 관련 정보를 모두 고려하여, 비디오를 스트리밍할 수 있는 최대 10개의 다른 OCA 서버에 대한 URL 목록을 클라이언트로 반환. 이 URL들은 일반적인 웹 브라우저에서 사용하는 것과 같은 형태. 넷플릭스는 사용자의 IP 주소와 ISP 정보를 활용하여 사용자에게 가장 적합한 OCA 클러스터가 무엇인지 파악하고 이 목록을 생성.
클라이언트의 지능적인 OCA 선택: 클라이언트는 수신된 URL 목록에 있는 각 OCA로의 네트워크 연결 품질을 테스트. 이 테스트를 통해 가장 빠르고 신뢰할 수 있는 OCA를 선택하여 먼저 연결. 이 연결 품질 테스트는 비디오 스트리밍 과정 내내 계속 실행.
OCA 연결 및 스트리밍 시작: 클라이언트는 선택된 OCA로부터 콘텐츠를 가장 잘 수신할 수 있는 방법을 결정하기 위한 추가적인 프로빙(probing) 과정을 거친 후, 최종적으로 선택된 OCA에 연결하고 사용자 장치로 비디오 스트리밍을 시작.
네트워크 변화에 따른 품질 및 OCA 적응: 비디오를 시청하는 동안 네트워크 품질은 변동될 수 있음. 넷플릭스 클라이언트는 이러한 네트워크 품질 변화에 지능적으로 적응.
- 네트워크 품질이 저하되면, 클라이언트는 비디오 품질을 낮춰 네트워크 속도에 맞춤. 이 때문에 때때로 화면이 픽셀화되어 보일 수 있음.
- 만약 네트워크 품질이 너무 많이 저하되어 현재 연결된 OCA로부터 원활한 스트리밍이 어렵다고 판단되면, 클라이언트는 자동으로 더 나은 성능의 네트워크에 있는 다른 OCA를 찾아 전환.

🐢꾸준함의 미학

탐색기