9. netflix

1. 기능 요구 사항

원활하게 함께 작동하여 끝없이 고객에게 만족스러운 비디오를 제공해야 합니다.

• 모든 디바이스에서 동영상 재생
• 세계 여러 나라에서 같은 동영상 재생
• 다양한 사용자에게 개인화된 비디오를 추천

 

2. 추정 및 제약 사항

• 애플리케이션에 등록된 활성 사용자 수 = 1억
• 1분마다 업로드되는 비디오 콘텐츠의 평균 크기 = 2500MB
• 지원해야 하는 해상도 및 코덱 형식의 총 조합 = 10
• 사용자가 매일 시청하는 평균 동영상 수 = 3

초당 시청한 동영상 수 = (활성 사용자 * 매일 시청한 평균 동영상)/86400 = (100M * 3/86400) = 3472

매일 저장되는 콘텐츠의 크기 = 분당 업로드되는 비디오의 평균 크기 *  해상도와 코덱의 조합 * 24* 60 = (2500MB * 10 * 24 * 60) = 36TB/일

 

3. 기본 시스템 설계 및 알고리즘

클라이언트는 Netflix 비디오를 TV, XBOX, 노트북 또는 휴대전화 등 모든 디바이스에서 탐색하고 재생합니다.

빠른 재생을 위해서 전 세계 여러 위치에 Netflix 비디오를 저장합니다. 재생 시 CDN에서 장치로 비디오 스트림이 재생되고 클라이언트에 표시됩니다.

CDN — CDN(콘텐츠 전달 네트워크)은 사용자의 지리적 위치, 웹 페이지의 출처 및 콘텐츠 전달 서버를 기반으로 페이지 및 기타 웹 콘텐츠를 사용자에게 전달하는 분산 서버(네트워크) 시스템입니다

3-1. Netflix가 영화/비디오를 온보딩하는 방법

영화를 사용자에게 제공하려면 먼저 Netflix에서 사용자의 기기에 가장 적합한 형식으로 비디오를 변환해야 합니다. 이 프로세스를 트랜스코딩 또는 인코딩이라고 합니다.

트랜스코딩은 비디오 파일을 한 형식에서 다른 형식으로 변환하여 다양한 플랫폼과 장치에서 비디오를 볼 수 있도록 하는 프로세스입니다.

 

 

3-2. 트랜스 코딩을 왜 해야 하는가?

Netflix는 스마트 TV, Adroid, IOS, 게임 콘솔, 웹 앱 등을 포함한 2200개의 다양한 장치를 지원합니다.

각 장치는 서로 다른 해상도와 네트워크 속도를 갖추고 있습니다. 다른 네트워크 속도로 많은 장치를 제공할 수 있으려면 원본 비디오가 다른 형식으로 있어야 합니다.

문제는 프로덕션 하우스의 비디오 크기가 매우 큽니다. 상업용 블루레이 2시간 영화의 경우 15-25Gb를 가집니다. 이를 다른 형식의 사용자에게 제공하면 데이터와 대역폭이 소모되므로 Netflix는 원본 비디오에 일련의 사전 처리를 수행하여 다른 파일 형식으로 변환합니다. 이러한 전처리를 인코딩 및 트랜스코딩이라고 합니다.

인코딩은 단일 대상 장치와 호환되도록 비디오 및 오디오 파일을 압축하는 프로세스입니다. 반면에 트랜스코딩을 사용하면 이미 인코딩 된 데이터를 다른 인코딩 형식으로 변환할 수 있습니다.(MP4, WLM, MOV, MPEG-4) 이 프로세스는 사용자가 다른 휴대폰 및 웹과 같은 여러 대상 장치를 사용할 때 특히 유용합니다.

 

전처리의 이유는 매우 간단합니다.

• 파일 크기를 줄임
• 스트리밍 비디오의 버퍼링을 줄임
• 해상도 또는 종횡비를 변경
• 오디오 형식 또는 품질을 변경
• 오래된 파일을 최신 형식으로 변환
• 특정 기기(컴퓨터, 태블릿, 스마트폰, 스마트TV, 레거시 기기)와 호환되는 동영상 생성
• 특정 소프트웨어 또는 서비스와 호환되는 비디오 생성

 

 

Netflix는 다양한 네트워크 속도에 최적화된 파일을 생성합니다. 빠른 네트워크에서 시청하는 경우 느린 네트워크를 통해 시청하는 것보다 더 높은 품질의 비디오를 볼 수 있습니다. 원본 비디오를 다른 작은 청크로 나누고 AWS의 병렬 작업자를 사용하여 이러한 청크를 다양한 해상도(예: 4k, 1080p 등)에서 다른 형식(예: mp4, 3gp 등)으로 변환하며 하나의 영화에 대해 약 1,200개의 파일을 생성합니다!!!!

비디오가 트랜스 코딩되면 이 파일은 모든 OC 서버로 푸시됩니다.

 

 

3-3. open connect

비디오에서 재생 시 발생하는 모든 일은 Open Connect에서 처리합니다. 이 시스템은 비디오를 장치로 스트리밍 하는 역할을 합니다. 다음 다이어그램은 재생 프로세스가 작동하는 방식을 보여줍니다.

Netflix Open Connect

open connect는 인터넷 제공 사업자(ISP) 네트워크에 캐시 서버를 설치하고 회원들이 자주 시청하는 콘텐츠를 새벽 시간대에 미리 저장해두는 방식입니다. 넷플릭스 회원과 가까운 곳에 저장해둔 콘텐츠를 스트리밍하기 때문에 넷플릭스로 인해 발생하는 트래픽을 현저히 낮추고, 먼 거리로 데이터를 전송하는 비용을 절감해줍니다. 더 빠른 속도로 고품질의 영상을 제공할 수 있습니다.

캐시서버를 활용한 다른 콘텐츠 전송 기술과 차이점은 엔터테인먼트 스트리밍 서비스의 특징에서 찾아볼 수 있습니다. 넷플릭스 회원들은 콘텐츠를 업로드하거나 인터넷 방송을 진행하는 것이 아닌, 넷플릭스가 보유하고 있는 콘텐츠를 스트리밍해 즐기는 '한 방향' 형태로 서비스를 제공합니다. 또 국가별로 어느 시간대에, 어떠한 콘텐츠를 회원들이 많이 시청할지 미리 '예측'할 수 있습니다. 예를 들어 새롭게 론칭한 특정 인기 콘텐츠를 시청하는 회원 수요를 고려해 미리 대비할 수 있습니다.

1. OCA는 AWS 인스턴스를 ping을 체크하여 상태, 경로, 보유하고 있는 파일을 보고합니다.
2. 클라이언트 디바이스의 사용자가 AWS의 Netflix 애플리케이션에서 타이틀(TV 프로그램 또는 영화) 재생을 요청합니다.
3. Netflix 재생 서비스는 사용자의 승인, 권한 및 라이선스를 확인한 다음 현재 네트워크 속도와 클라이언트 해상도를 고려하여 클라이언트에 제공할 파일을 선택합니다.
4. 조정 서비스는 파일을 제공해야 하는 OCA를 선택하고 이러한 OCA에 대한 URL을 생성한 다음 재생 서비스에 다시 전달합니다.
5. 재생 서비스는 OCA의 URL을 클라이언트로 전달하고 클라이언트는 해당 OCA에서 비디오 파일을 요청합니다.

 

 

3-4. ELB

Netflix는 Amazons Elastic Load Balancer(ELB) 서비스를 사용하여 트래픽을 프런트엔드로 라우팅 합니다. ELB는 2 계층 로드 밸런싱 방식이기 때문에 먼저 영역 간에 부하가 분산된 다음 인스턴스에 분산되도록 설정됩니다.

• 첫 번째 계층은 기본 DNS 기반 라운드 로빈 로드 밸런싱으로 구성됩니다. 여러 지역의 LB를 묶는 첫 번째 계층으로 여러 지역으로 분포되어 있는 두 번째 계층을 하나로 묶는 역할을 하며, 어느 지역이 빠를지, 부하가 없는지를 판단하여 더욱 빠른 지역으로 연결합니다.
• ELB 서비스의 두 번째 계층은 로드 밸런서 인스턴스 어레이(AWS에서 직접 프로비저닝)로, 동일한 영역에서 뒤에 있는 자체 인스턴스에 대해 라운드 로빈 로드 밸런싱을 수행합니다.

 

 

4. 백엔드 아키텍처

Netflix는 마이크로 서비스 아키텍처의 주요 동인 중 하나입니다. 시스템의 모든 구성 요소는 협력하는 느슨하게 결합된 서비스의 모음으로 크고 복잡한 애플리케이션을 빠르고 자주 안정적으로 전달할 수 있습니다. 아래 그림은 백엔드 아키텍처의 개요입니다.

 

1. 클라이언트는 AWS에서 실행되는 백엔드에 재생 요청을 보냅니다. Netflix는 Amazon의 Elastic Load Balancer(ELB) 서비스를 사용하여 서비스로 트래픽을 라우팅 합니다.
2. AWS ELB는 해당 요청을 API 게이트웨이 서비스로 전달합니다. Netflix는 Zuul을 API 게이트웨이로 사용합니다. 이 게이트웨이는 동적 라우팅, 트래픽 모니터링, 보안, 클라우드 배포 장애 복원을 위해 구축되었습니다.
3. 애플리케이션 API 구성 요소는 Netflix 운영의 핵심 비즈니스 로직입니다. 가입 API, 동영상 추천 검색을 위한 검색/추천 API 등 다양한 사용자 활동에 해당하는 여러 유형의 API가 있습니다. 이 시나리오에서는 API 게이트웨이 서비스에서 전달된 요청을 Play API에서 처리합니다.
4. Play API는 요청을 이행하기 위해 마이크로 서비스 또는 마이크로 서비스 시퀀스를 호출합니다.
5. 마이크로 서비스는 대부분 상태 비저장 소규모 프로그램이며 수천 개의 이러한 서비스가 서로 통신할 수 있습니다.
6. 마이크로 서비스는 이 프로세스 동안 데이터 저장소에서 데이터를 저장하거나 가져올 수 있습니다.
7. 마이크로서비스는 개인화된 권장 사항의 실시간 처리 또는 비즈니스 인텔리전스 작업의 일괄 처리를 위해 사용자 활동 또는 기타 데이터를 추적하는 이벤트를 스트림 처리 파이프라인으로 보낼 수 있습니다.
8. Stream Processing Pipeline에서 나오는 데이터는 AWS S3, Hadoop HDFS, Cassandra 등과 같은 다른 데이터 저장소에 영구적일 수 있습니다.

 

4-1. Zuul API 게이트웨이

Netflix는 Amazon의 Elastic Load Balancer(ELB) 서비스를 사용하여 트래픽을 서비스로 라우팅 합니다. ELB는 로드가 먼저 영역 간에 균형을 맞춘 다음 인스턴스에 분산되도록 설정됩니다.

 

이 로드 밸런서는 API 게이트웨이 서비스로 요청을 라우팅합니다. Netflix는 Zuul을 API 게이트웨이로 사용하며 모든 요청을 처리하고 마이크로 서비스 애플리케이션의 동적 라우팅을 수행합니다.

예를 들어 /api/products는 제품 서비스에 매핑되고 /api/user는 사용자 서비스에 매핑됩니다. Zuul 서버는 요청을 해당 백엔드 애플리케이션으로 동적으로 라우팅합니다. Zuul은 에지 서비스에 기능을 빠르고 민첩하게 적용할 수 있는 다양한 유형의 필터를 제공합니다.

Netflix의 Cloud Gateway 팀은 80개 이상의 Zuul 2 클러스터를 실행 및 운영하여 초당 100만 개 이상의 요청에 해당하는 약 100개의 백엔드 서비스 클러스터에 트래픽을 전송합니다.

https://netflixtechblog.com/open-sourcing-zuul-2-82ea476cb2b3

• Netty 서버
  네트워크 프로토콜, 웹 서버, 연결 관리 및 프록시 작업을 담당합니다. 요청이 Netty 서버에 도달하면 요청을 인바운드 필터에 프록시합니다.
• 인바운드 필터
  인증, 라우팅 또는 요청 장식을 담당합니다. 그런 다음 요청을 엔드포인트 필터로 전달합니다.
• 엔드포인트 필터
  정적 응답을 반환하거나 요청을 백엔드 서비스로 전달하는 데 사용됩니다. 백엔드 서비스로부터 응답을 받으면 요청을 아웃바운드 필터로 보냅니다.
• 아웃바운드 필터
  콘텐츠를 압축하거나, 메트릭을 계산하거나, 사용자 정의 헤더를 추가/제거하는 데 사용됩니다. 그 후 응답은 Netty 서버로 다시 전송되고 클라이언트가 수신합니다.

장점:

• 트래픽의 다른 부분을 다른 서버에 분산하여 몇 가지 규칙을 만들고 트래픽을 분산시킬 수 있습니다.
• 개발자는 일부 시스템에서 새로 배포된 클러스터에 대한 부하 테스트를 수행할 수 있습니다.
• 클러스터의 일부 기존 트래픽을 라우팅하고 특정 서버가 견딜 수 있는 부하를 확인할 수 있습니다.
• 새로운 서비스를 테스트할 수 있습니다. 서비스를 업그레이드하고 실시간 API 요청과 함께 작동하는 방식을 확인하려는 경우 특정 서비스를 한 서버에 배포하고 트래픽의 일부를 새 서비스로 리디렉션하여 실시간 API 요청을 확인할 수 있습니다.
• 엔드포인트 필터 또는 방화벽에서 사용자 지정 규칙을 설정하여 잘못된 요청을 필터링할 수 있습니다.

 

4-2. 애플리케이션 API

현재 애플리케이션 API는 Signup API (등록 , 청구, 무료 평가판 등과 같은 비회원 요청용 ), Discovery API(검색, 추천 요청), Play API( 스트리밍, 보기 )의 세 가지 범주로 정의됩니다. 예를 들어, 사용자가 가입을 클릭하면 Zuul은 요청을 Signup API로 라우팅 합니다.

이미 가입한 사용자의 예를 고려한다면. 사용자가 최신 에피소드에 대해 재생을 클릭한다고 가정하면 요청이 재생 API로 라우팅 되고 API는 차례로 내부에서 여러 마이크로 서비스를 호출합니다. 이러한 호출 중 일부는 서로 의존하지 않기 때문에 병렬로 수행될 수 있습니다. API에는 필요에 따라 호출을 시퀀싱 하고 병렬화하는 모든 로직이 포함되어 있습니다. 그러면 장치는 고객이 "재생"을 클릭할 때 내부적으로 진행되는 오케스트레이션에 대해 아무것도 알 필요가 없습니다.

 

가입 요청은 백엔드 서비스 가입에 매핑되고 재생 요청은 일부 예외를 제외하고는 재생 백엔드 서비스에만 매핑되며 마찬가지로 검색 API는 검색 서비스에 매핑됩니다.

 

 

 

4-3 Hystrix- 분산 API 서비스 모니터링

많은 종속성이 있는 분산 환경(MSA)에서 필연적으로 많은 서비스 종속성 중 일부가 실패합니다. 점점 더 많은 서비스가 재개되고 일부 서비스가 중단되거나 단순히 중단될 수 있으므로 모든 서비스의 상태와 상태를 모니터링하는 것은 관리하기 어려울 수 있습니다. Hystrix는 사용자 친화적인 대시보드를 제공하여 도움을 제공합니다. Hystrix 라이브러리는 대기 시간 허용 및 내결함성 논리를 추가하여 이러한 분산 서비스 간의 상호 작용을 제어하는 데 사용됩니다.

 

예를 들어 액션 영화 목록을 사용자에게 제공하는 마이크로 서비스가 있습니다. 만일 해당 서비스가 실패하면 가족 분위기 상위 10 개 영화를 단순히 반환하는 다른 기본 마이크로 서비스로 실패를 우회하기 위해 트래픽을 다시 라우팅 합니다.

각각의 서버와의 종속성 안정성을 위해 다음을 확인합니다.

• 복잡한 분산 시스템에서 계단식 오류를 중지합니다.
• 타사 클라이언트 라이브러리를 통해 (일반적으로 네트워크를 통해) 액세스 된 종속성으로 인한 지연 및 장애 제어.
• 빠르게 실패하고 빠르게 복구합니다.
• 가능한 경우 폴백(fallback)하고 점진적으로 저하됩니다.
• 실시간에 가까운 모니터링, 경고 및 운영 제어를 가능하게 합니다.
• 동시성 인식 요청 캐싱. 요청 축소를 통한 자동 일괄 처리

Netflix Hystrix는 더 이상 개발 중이 아니며 현재 유지 관리 모드에 있습니다. 일부 내부 프로젝트는 현재 resilience4j로 구축 중입니다.

https://github.com/resilience4j/resilience4j

 

 

4-4 Titus 타이터스 - 컨테이너 관리

https://netflix.github.io/titus/

Titus는 여러 시스템에서 사용 가능한 리소스를 중개하는 클러스터 관리 시스템인 Apache Mesos를 기반으로 하는 프레임워크입니다. Titus는 Netflix의 프로덕션 환경에서 실행되어 수천 개의 AWS EC2 인스턴스를 관리하고 배치 및 서비스 워크로드 모두에 대해 매일 수십만 개의 컨테이너를 시작합니다. Kubernetes의 Netflix 버전으로 일주일에 약 300만 개의 컨테이너를 실행합니다.

 

 

 

 

5. 데이터 저장소

5-1. EV캐시

캐시의 주요 목적은 느린 스토리지 계층에 액세스를 줄여 데이터 검색 성능을 높이는 것입니다. 속도와 용량을 절충하여 캐시는 일반적으로 데이터의 하위 집합을 일시적으로 저장합니다.

https://github.com/Netflix/EVCache

캐싱의 두 가지 사용 사례는 다음과 같습니다.

• 자주 저장되는 데이터에 대한 빠른 액세스를 제공합니다.
• 계산된(메 모리화 된) 데이터에 대한 빠른 액세스를 제공합니다. Netflix의 마이크로 서비스는 캐시를 사용하여 회원의 시청 기록, 평점, 맞춤 추천과 같은 다양한 유형의 데이터에 빠르고 안정적으로 액세스 합니다.

 

Netflix는 EV 캐시라는 자체 사용자 지정 캐싱 레이어를 구축했습니다. EV 캐시는 Memcached를 기반으로 하며 실제로 Memcached를 둘러싼 래퍼입니다.

Netflix는 여러 AWS EC2 인스턴스에 많은 클러스터를 배포했으며 이러한 클러스터에는 Memcached의 캐시 클라이언트도 있습니다. 데이터는 동일한 영역 내의 클러스터에서 공유되며 여러 캐시 복사본이 샤딩된 노드에 저장됩니다. 클라이언트에 쓰기가 발생할 때마다 모든 클러스터의 모든 노드가 업데이트되지만 캐시에 읽기가 발생하면 가장 가까운 클러스터(모든 클러스터 및 노드가 아님)와 해당 노드에만 전송됩니다. 노드를 사용할 수 없는 경우 다른 사용 가능한 노드에서 읽습니다. 이 접근 방식은 성능, 가용성 및 안정성을 향상합니다.

 

 

5-2. 캐싱용 SSD

일반적으로 캐싱은 RAM에서 수행되지만 많은 양의 데이터를 저장하는 것은 비용이 많이 듭니다. 따라서 Netflix는 일부 캐싱 데이터를 SSD로 이동시켜 사용합니다.

SSD를 기반으로 하는 최신 디스크 기술은 데이터에 대한 빠른 액세스를 제공하지만 RAM에 비해 훨씬 저렴한 비용으로 제공됩니다. SSD에 1TB의 데이터를 저장하는 비용은 RAM을 사용하여 동일한 양을 저장하는 것보다 훨씬 저렴합니다.

Evolution of Application Data Caching : From RAM to SSD

 

5-3. MySQL

Netflix는 결제 인프라에 AWS EC2 MYSQL 인스턴스를 사용합니다. 결제 프로세서는 청구 거래를 처리하기 위해 RDBMS의 ACID 기능이 필요했습니다. 결제 인프라는 Netflix 회원의 결제 상태를 관리하는 역할을 합니다. 여기에는 미결/지불 청구 기간, 회원 계정의 크레딧 금액 추적, 회원의 결제 상태 관리, 청구 요청 시작 및 회원이 결제한 날짜가 포함됩니다.

 

5-4. 아파치 카산드라

Cassandra는 많은 상용 서버에서 대량의 데이터를 처리하도록 설계된 무료 오픈 소스 분산형 칼럼 저장소 NoSQL 데이터베이스로서 단일 장애 지점 없이 고가용성을 제공합니다.

Netflix는 확장성, 단일 실패 지점, 교차 지역 배포를 위해 Cassandra를 사용합니다.  사실상 단일 글로벌 Cassandra 클러스터는 애플리케이션을 동시에 서비스하고 여러 지리적 위치에서 데이터를 비동기식으로 복제할 수 있습니다.

Netflix는 Cassandra DB 인스턴스에 모든 종류의 데이터를 저장합니다. 사용자가 수집한 모든 이벤트 메트릭은 Cassandra에 저장됩니다.

Cassandra 위에 구축된 OpenTSDB 와 같은 시계열 데이터베이스를 사용하여 자막을 저장할 수 있습니다. 비디오 자막을 저장하는 데 사용할 수 있는 데이터 모델의 스니펫을 아래에 표시했습니다. 이 모델(미디어 문서라고 함)에서는 각 이벤트가 타임라인에서 시간 간격을 차지하는 이벤트 기반 표현을 제공했습니다.

{
	“events”: [
	{
	       “startTime”: T0,
	       “endTime”: T1,
	       “metadata”: {
	              “subtitle”: “Hi there! How are you?”
	       }
	},
	{
	       “startTime”: T2,
	       “endTime”: T3,
	       “metadata”: {
	              “subtitle”: “Thanks for asking”
	       }
	}]
}

사용자 데이터가 증가하기 시작하면서 데이터 스토리지를 보다 효율적으로 관리할 수 있는 방법이 필요했습니다. Netflix는 두 가지 주요 목표를 염두에 두고 데이터 스토리지 아키텍처를 재설계했습니다.

• 더 작은 저장 공간.
• 구성원당 재생이 증가함에 따라 일관된 읽기/쓰기 성능.

대용량 데이터 문제에 대한 해결책은 이전 행을 압축하는 것이었습니다. 데이터는 두 가지 유형으로 나뉩니다.

• 라이브 시청 기록(LiveVH): 최근에 자주 업데이트되는 적은 수의 최근 시청 기록. 데이터는 압축되지 않은 형태로 저장됩니다.
• 압축된 시청 기록(CompressedVH): 데이터가 업데이트된다면 오래된 시청 기록 데이터는 저장 공간을 줄이기 위해 압축됩니다. 압축된 시청 기록은 행당 단일 열에 저장됩니다.

 

 

6. 데이터 분석

6-1 스트림 처리 파이프라인

Netflix가 당신만을 위해 영화 아트워크를 개인화한다는 사실을 알고 있습니까? 각 비디오에 표시되는 이미지가 사용자를 위해 특별히 선택되었다는 사실을 알고 놀라실 수도 있습니다. 모든 사람이 같은 이미지를 보는 것은 아닙니다. Netflix는 시청 기록 및 관심 분야에서 대해 알게 된 데이터를 기반으로 비디오에서 가장 관련성이 높은 부분을 강조하는 아트워크를 선택하려고 시도합니다.

Stream Processing Data Pipeline은 비즈니스 분석 및 개인화된 추천 작업은 거의 실시간으로 모든 마이크로 서비스 이벤트를 생성, 수집, 처리, 집계 및 다른 데이터 프로세서로 이동하는 작업을 담당합니다.

스트리밍 데이터는 일반적으로 데이터 레코드를 동시에 작은 크기(킬로바이트 단위)로 보내는 수천 개의 데이터 소스에서 지속적으로 생성되는 데이터입니다. 스트리밍 데이터에는 모바일 또는 웹 애플리케이션을 사용하여 고객이 생성한 로그 파일, 전자 상거래 구매, 게임 내 플레이어 활동, 소셜 네트워크의 정보, 금융 거래 또는 지리 공간 서비스의 정보, 연결된 데이터의 원격 측정과 같은 다양한 데이터가 포함됩니다.

What Is Streaming Data? | Amazon Web Services (AWS)

 

데이터는 레코드 별로 또는 슬라이딩 시간 창에 따라 순차적으로 증분적으로 처리되어야 하며 상관관계, 집계, 필터링 및 샘플링을 비롯한 다양한 분석에 사용해야 합니다.

이러한 분석에서 파생된 정보는 기업에 서비스 사용량(측정/청구용), 서버 활동, 웹사이트 클릭, 장치, 사람 및 물리적 상품의 지리적 위치와 같은 비즈니스 및 고객 활동의 여러 측면에 대한 가시성을 제공합니다. 새로운 상황에 신속하게 대응할 수 있습니다. 예를 들어, 기업은 소셜 미디어 스트림을 지속적으로 분석하여 브랜드 및 제품에 대한 대중의 감정 변화를 추적하고 필요에 따라 적시에 대응할 수 있습니다.

스트림 처리 플랫폼은 하루에 수조 개의 이벤트와 페타바이트의 데이터를 처리합니다.

Netflix 추천 시스템은 최소한의 노력으로 즐길 수 있는 프로그램이나 영화를 찾을 수 있도록 노력하고 있습니다. 다음을 포함한 여러 요소를 기반으로 카탈로그에서 특정 타이틀을 시청할 가능성을 추정합니다.

• 여러 서비스와의 상호 작용(예: 시청 기록 및 다른 타이틀 평가 방법),
• 서비스에 대한 비슷한 취향과 선호도를 가진 다른 회원(https://about.netflix.com/en/news/a-global-approach-to-recommendations)
• 장르, 카테고리, 배우, 출시 연도 등과 같은 제목에 대한 정보.
• 시청하는 시간
• Netflix를 시청하는 기기 및 탐색 시간

협업 필터링(CF) 알고리즘은 두 클라이언트가 유사한 등급 기록을 가지고 있으면 미래에 유사하게 행동할 것이라는 아이디어에 기반합니다(Breese, Heckerman 및 Kadie, 1998). 예를 들어 가능성이 매우 높은 두 명의 사용자가 있고 그중 한 명이 영화를 보고 좋은 점수로 평가한다면 두 번째 사용자도 비슷한 패턴을 가질 것이라는 판단 합니다.

콘텐츠 기반 필터링(CB)은 사용자가 이전에 좋아했던 영화와 유사한 항목이나 영화를 추천하는 것을 목표로 합니다. 이 접근 방식과 CF의 주요 차이점은 CB가 등급별 유사성뿐만 아니라 제품의 정보(Aggarwal, 2016), 즉 영화 제목, 연도, 장르, 배우에 대한 정보를 기반으로 추천을 제공한다는 것입니다.  이 방법론을 구현하기 위해서는 각 항목을 설명하는 정보가 필요하며 사용자가 무엇을 좋아하는지 설명하는 일종의 사용자 프로필도 필요합니다. 작업은 사용자 기본 설정을 학습한 다음 사용자 기본 설정과 "유사한" 항목을 찾거나 추천합니다.

 

시청기록 서비스는 회원이 재생한 모든 동영상을 캡처합니다. Beacon은 Netflix 내의 모든 노출 이벤트 및 사용자 활동을 캡처하는 서비스입니다. Viewing History 및 Beacon 서비스에서 수집한 모든 데이터는 Kafka로 전송됩니다.

 

 

6-2 Apache Kafka - 스트리밍 데이터 분석

Kafka는 스트리밍 데이터를 저장, 읽기 및 분석하기 위한 프레임워크를 제공하는 오픈 소스 소프트웨어입니다.

Netflix는 이벤트, 메시징 및 스트림 처리 요구 사항에 대한 사실상의 표준으로 Apache Kafka®를 수용합니다. Kafka는 모든 지점 간 및 Netflix Studio 전체 통신을 위한 브리지 역할을 합니다.

https://www.confluent.io/blog/how-kafka-is-used-by-netflix/

 

 

6-3. Apache Chukwe- 스트리밍 데이터 분석

Apache Chukwe는 분산 시스템에서 로그 또는 이벤트를 수집하기 위한 오픈 소스 데이터 수집 시스템입니다. HDFS 및 Map-reduce 프레임워크를 기반으로 구축되었습니다. Hadoop의 확장성 및 견고성 기능이 함께 제공되며 데이터 모니터링 및 분석하기 위한 강력하고 유연한 툴킷이 많이 포함되어 있습니다. Chukwe는 시스템의 여러 부분에서 이벤트를 수집하여 Hive를 통해 Parquet 데이터 형식으로 s3에 저장합니다. 기본적으로 시간별 또는 일별 빈도로 전체 데이터를 일괄 처리합니다.

• 동영상 시청 활동
• UI 활동
• 오류 로그
• 공연 이벤트
• 문제 해결 및 진단 이벤트

EMR/S3에 이벤트를 업로드하기 위해 Chukwa는 Kafka(실시간 데이터 처리의 메인 게이트)에 대한 트래픽도 제공합니다. Kafka에서 다양한 싱크(S3, Elasticsearch 및 버퍼)로 데이터를 이동하는 일을 담당합니다. 이러한 메시지의 라우팅은 Apache Samja 프레임워크를 사용하여 수행됩니다.

 

6-4.  검색

최근 몇 년 동안 Netflix 내에서 Elasticsearch 사용이 크게 증가했습니다. Netflix는 인스턴스가 있는 약 150 개의 탄력적 검색 클러스터와 3,500개의 호스트를 실행하고 있습니다.

Netflix는 데이터 시각화, 고객 지원 및 시스템의 일부 오류 감지를 위해 탄력적 검색을 사용하고 있습니다. 예를 들어 고객이 비디오를 재생할 수 없는 경우 고객 관리 담당자는 Elasticsearch을 사용하여 이 문제를 해결합니다. Elasticsearch에 있는 데이터를 통해 사용자를 검색하고 사용자의 기기에서 동영상이 재생되지 않는 이유와 같이 특정 사용자에게 발생하는 모든 정보와 이벤트를 알게 됩니다.

Elasticsearch은 또한 관리자가 일부 정보를 추적하는 데 사용되며 리소스 사용량을 추적하고 등록 또는 로그인 문제를 감지하는 데 사용됩니다.

 

 

참고 사항

https://medium.com/@narengowda/netflix-system-design-dbec30fede8d

https://dev.to/gbengelebs/netflix-system-design-how-netflix-onboards-new-content-2dlb

https://dev.to/gbengelebs/netflix-system-design-backend-architecture-10i3

https://www.youtube.com/watch?v=psQzyFfsUGU&ab_channel=TechDummiesNarendraL

https://www.youtube.com/watch?v=x9Hrn0oNmJM&ab_channel=GauravSen

https://www.youtube.com/watch?v=lYoSd2WCJTo&ab_channel=codeKarle

https://www.youtube.com/watch?v=XtsZxjWzNDA&ab_channel=TechTakshila

https://elatov.github.io/2021/02/distributed-systems-design-netflix/

https://systeminterview.com/design-youtube.php

https://www.geeksforgeeks.org/system-design-netflix-a-complete-architecture/?ref=rp

https://techtakshila.com/system-design-interview/chapter-2/