Netflix의 신속한 이벤트 알림 시스템

Netflix에는 2억 2천만 명 이상의 활성 회원이 있으며 각 세션에서 프로필 이름 변경부터 제목 보기에 이르기까지 다양한 작업을 수행합니다. 이러한 작업에 거의 실시간으로 대응하여 여러 장치에서 일관된 경험을 유지하는 것은 최적의 회원 경험을 보장하는 데 중요합니다. 지원되는 다양한 장치와 회원들이 수행하는 작업의 양을 고려할 때 이것은 쉬운 일이 아닙니다. 이를 위해 확장 가능하고 확장 가능한 방식으로 서버가 장치와 통신을 시작해야 하는 사용 사례를 지원하기 위해 RENO( Rapid Event Notification System )를 개발했습니다.

Netflix 회원 기반의 급속한 성장과 시스템의 복잡성 증가로 인해 당사 아키텍처는 온라인 및 오프라인 계산을 모두 지원하는 비동기식 아키텍처로 발전했습니다. 다양한 플랫폼(iOS, Android, 스마트 TV, Roku, Amazon FireStick, 웹 브라우저)과 다양한 장치 유형(휴대폰, 태블릿, 텔레비전, 컴퓨터, 셋톱 박스)에서 원활하고 일관된 Netflix 경험을 제공하려면 기존 요청 이상의 것이 필요합니다. - 응답 모델. 시간이 지남에 따라 백엔드 시스템이 구성원 주도 변경 사항을 알리거나 경험 업데이트를 빠르고 일관되게 알리기 위해 장치와 통신을 시작해야 하는 사용 사례가 증가하는 것을 보았습니다.

사용 사례

• 보기 활동
  회원이 쇼를 보기 시작하면 해당 보기를 반영하기 위해 회원의 모든 장치에서 "계속 시청" 목록이 업데이트되어야 합니다.
• 개인화된 경험 새로 고침
  Netflix 추천 엔진은 모든 회원에 대한 추천을 지속적으로 새로 고칩니다. 업데이트된 권장 사항은 최적의 회원 경험을 위해 적시에 장치에 전달되어야 합니다.
• 멤버십 플랜 변경
  회원은 종종 플랜 유형을 변경하여 모든 장치에 즉시 반영되어야 하는 경험의 변경으로 이어집니다.
• 회원 "내 목록" 업데이트
  회원이 제목을 추가하거나 제거하여 "내 목록"을 업데이트하면 변경 사항이 모든 장치에 반영되어야 합니다.
• 회원 프로필 변경 회원
  이 프로필 추가/삭제/이름 변경과 같은 계정 설정을 업데이트하거나 콘텐츠에 대한 선호 성숙도를 변경할 때 이러한 업데이트는 모든 기기에 반영되어야 합니다.
• 시스템 진단 신호
  특별한 시나리오에서는 문제를 해결하고 추적 기능을 활성화하는 데 도움이 되도록 디바이스의 Netflix 앱에 진단 신호를 보내야 합니다.

디자인 결정

시스템을 설계하면서 우리는 RENO의 아키텍처를 형성하는 데 도움이 되는 몇 가지 주요 결정을 내렸습니다.

1. 단일 이벤트 소스
2. 이벤트 우선 순위
3. 하이브리드 통신 모델
4. 타겟 배달
5. 높은 RPS 관리

1.단일 이벤트 소스

우리가 지원하고자 하는 사용 사례는 다양한 내부 시스템과 구성원 작업에서 비롯되었기 때문에 여러 다른 마이크로 서비스의 이벤트를 수신 대기해야 했습니다. Netflix에서 당사의 거의 실시간 이벤트 흐름은 Manhattan이라는 내부 분산 계산 프레임워크에 의해 관리됩니다(자세한 내용은 여기에서 확인할 수 있음). 우리는 맨해튼의 이벤트 관리 프레임워크를 활용하여 RENO에 대한 이벤트의 단일 소스 역할을 하는 간접적인 수준을 만들었습니다.

2. 이벤트 우선 순위

사용 사례가 소스와 중요성 측면에서 광범위하다는 점을 고려하여 이벤트 처리에 세분화를 구축했습니다. 예를 들어 "프로필의 성숙도 수준 변경”"보다 훨씬 더 높은 우선순위를 가져야 합니다.시스템 진단 신호".따라서 우선 순위별 대기열 및 해당 이벤트 처리 클러스터로 라우팅하여 각 사용 사례에 우선 순위를 할당하고 이벤트 트래픽을 분할했습니다. 이러한 분리를 통해 다양한 이벤트 우선 순위 및 트래픽 패턴에 대해 시스템 구성 및 확장 정책을 독립적으로 조정할 수 있습니다.

3. 하이브리드 통신 모델

이 게시물의 앞부분에서 언급했듯이 RENO와 같은 서비스의 핵심 과제 중 하나는 여러 플랫폼을 지원하는 것입니다. 모바일 장치는 거의 항상 인터넷에 연결되어 있고 연결할 수 있지만 스마트 TV는 사용 중일 때만 온라인 상태입니다. 이러한 네트워크 연결 이질성은 단일 전달 모델을 선택하는 것을 어렵게 만들었습니다. 예를 들어, 기기가 업데이트를 위해 자주 집에 전화를 거는 풀 모델에 전적으로 의존하면 모바일 앱이 수다스러워집니다. 그러면 iOS 및 Android 플랫폼이 적용하는 앱별 통신 제한이 트리거됩니다(저대역폭 연결도 고려해야 함). 반면에 푸시 메커니즘만 사용하면 스마트 TV가 하루 종일 꺼져 있는 동안 알림을 놓칠 수 있습니다.

Push-and-Pull 전달 모델 조합을 사용하면 단일 통신 모델로 제한된 장치도 지원합니다. 여기에는 푸시 알림을 지원하지 않는 구형 레거시 장치가 포함됩니다.

4. 타겟 배달

사용 사례가 소스 및 대상 장치 유형 모두에서 광범위하다는 점을 고려하여 장치별 알림 전달에 대한 지원을 구축했습니다. 이 기능을 사용하면 사용 사례에 따라 특정 장치 범주를 알릴 수 있습니다. 실행 가능한 이벤트가 도착하면 RENO는 사용 사례별 비즈니스 로직을 적용하고 이 알림을 수신할 수 있는 장치 목록을 수집하고 전달을 시도합니다. 이는 나가는 트래픽 공간을 상당히 제한하는 데 도움이 됩니다.

5. 높은 RPS 관리

2억 2천만 명 이상의 회원이 있는 우리는 RENO와 같은 서비스가 시청 세션 동안 회원당 많은 이벤트를 처리해야 한다는 사실을 인식했습니다. 피크 시간에 RENO는 초당 약 150,000개의 이벤트를 제공합니다. 하루 중 특정 시간 동안 이러한 높은 RPS는 엄청난 무리 문제 를 생성하고 내부 및 외부 다운스트림 서비스에 부담을 줄 수 있습니다. 따라서 몇 가지 최적화를 구현했습니다.

• 이벤트 기간
  장치에 통지해야 하는 많은 이벤트는 시간에 민감하며 거의 즉시 전송되지 않는 한 가치가 없거나 거의 없습니다. 오래된 이벤트 처리를 피하기 위해 부실 필터가 게이팅 검사로 적용됩니다. 이벤트 기간이 구성 가능한 임계값보다 오래된 경우 처리되지 않습니다. 이 필터는 처리 단계 초기에 장치에 가치가 없는 이벤트를 제거하고 백업되었을 수 있는 오래된 업스트림 이벤트로 인해 대기열이 넘치지 않도록 보호합니다.
• 온라인 장치
  지속적인 트래픽 공간을 줄이기 위해 Zuul에서 최신 상태로 유지하는 기존 레지스트리를 활용하여 현재 온라인 상태인 장치에만 알림이 전송됩니다(자세한 내용은 여기 참조 ).
• 확장 정책
  엄청난 무리 문제를 해결하고 대기 시간을 허용 가능한 임계값 아래로 유지하기 위해 클러스터 확장 정책은 축소 정책보다 더 공격적으로 구성됩니다. 이 접근 방식을 사용하면 대기열이 증가할 때 컴퓨팅 성능이 빠르게 따라잡을 수 있습니다.
• 이벤트 중복 제거
  iOS 및 Android 플랫폼 모두 백그라운드 앱에서 생성되는 활동 수준을 적극적으로 제한하므로 수신 이벤트가 RENO에서 중복 제거되는 이유입니다. RPS가 높은 경우 중복 이벤트가 발생할 수 있으며 장치에 대한 컨텍스트 손실을 일으키지 않는 경우 함께 병합됩니다.
• 대량 전송 다중 다운스트림 서비스는 Apple 기기용
  APNS (Apple Push Notification Service) 및 Android용 Google FCM (Firebase Cloud Messaging) 과 같은 외부 플랫폼을 포함하여 다양한 기기 플랫폼으로 푸시 알림을 보내는 데 사용됩니다 . 전체 알림 서비스를 중단시키는 다운스트림 서비스로부터 보호하기 위해 이벤트 전달은 여러 플랫폼에서 병렬화되어 플랫폼별로 최선을 다합니다. 다운스트림 서비스 또는 플랫폼이 알림을 전달하지 못하는 경우 다른 장치에서 푸시 알림을 수신하는 것이 차단되지 않습니다.

Architecture

위의 다이어그램에서 볼 수 있듯이 RENO 서비스는 다음과 같은 구성 요소로 나눌 수 있습니다.

이벤트 트리거

구성원의 장치에서 경험을 새로 고쳐야 하는 구성원 작업 및 시스템 기반 업데이트.

이벤트 관리 엔진

맨해튼이라고 하는 Netflix의 거의 실시간 이벤트 흐름 관리 프레임워크는 특정 이벤트를 수신하고 이벤트를 다른 대기열로 전달하도록 구성할 수 있습니다.

이벤트 우선 순위 기반 대기열

우선 순위 기반 이벤트 전달 규칙으로 채워진 Amazon SQS 대기열은 우선 순위 기반 트래픽 샤딩을 허용하도록 맨해튼에 설정됩니다.

이벤트 우선 순위 기반 클러스터

동일한 우선 순위로 해당 대기열을 구독하는 AWS 인스턴스 클러스터. 해당 대기열에 도착하는 모든 이벤트를 처리하고 장치에 대한 실행 가능한 알림을 생성합니다.

아웃바운드 메시징 시스템

회원에게 인앱 푸시 알림을 보내는 Netflix 메시징 시스템은 모바일 장치에 라스트 마일에 RENO 생성 알림을 보내는 데 사용됩니다. 이 메시징 시스템은 이 블로그 게시물 에 설명되어 있습니다.

웹, TV 및 기타 스트리밍 장치에 대한 알림의 경우 온라인 장치와의 "항상 켜진" 지속적인 연결을 제공하는 Zuul Push라는 자체 개발 푸시 알림 솔루션을 사용합니다. Zuul Push 솔루션에 대해 자세히 알아보려면 Netflix 동료의 이 강연 을 들어보세요.

영구 저장소

각 장치에 대해 RENO에서 내보낸 모든 알림을 저장하는 Cassandra 데이터베이스는 해당 장치가 고유한 케이던스에서 메시지를 폴링할 수 있도록 합니다.

이익

• 새로운 사용 사례를 쉽게 지원할 수 있습니다.
• 더 높은 처리량으로 수평 확장

RENO 구축을 시작할 때 목표는 제품의 "개인화된 경험 새로 고침" 사용 사례로 제한되었습니다. RENO의 디자인이 발전함에 따라 새로운 사용 사례에 대한 지원이 가능해졌고 RENO는 Netflix의 모든 제품 영역에 대한 중앙 집중식 신속한 알림 서비스로 빠르게 포지셔닝되었습니다.

새로운 사용 사례를 "플러그 앤 플레이" 솔루션으로 추가하고 모든 플랫폼에 하이브리드 제공 모델을 제공하는 등 초기에 내린 설계 결정은 성과를 거두었습니다. 우리는 빠른 속도로 추가 제품 사용 사례를 온보딩하여 많은 혁신을 차단할 수 있었습니다.

이 플랫폼을 구축하는 데 있어 중요한 학습은 시간이 지남에 따라 더 많은 유형의 이벤트와 더 높은 처리량이 필요함에 따라 RENO가 수평적으로 확장될 수 있다는 점이었습니다. 이 기능은 주로 이벤트 처리를 위해 더 많은 시스템을 추가하여 확장할 수 있는 비동기 이벤트 기반 처리 모델을 사용하는 것과 함께 이벤트 유형 또는 우선 순위에 따라 샤딩을 허용함으로써 달성되었습니다.

https://netflixtechblog.com/rapid-event-notification-system-at-netflix-6deb1d2b57d1