넷플릭스, 6,500만 동시 스트림 감당한 라이브 오리진 기술 공개···S3 버리고 카산드라+EVCache로 전환
[테크수다 기자 도안구 eyeball@techsuda.com] 넷플릭스(Netflix)가 2024년 타이슨 vs. 폴 경기에서 역대 최고 6,500만 동시 스트림을 처리한 라이브 스트리밍 핵심 인프라의 설계 원리를 공개했다. 자체 CDN '오픈 커넥트(Open Connect)'와 클라우드 파이프라인 사이에 위치한 '라이브 오리진(Live Origin)'이 그 주인공이다. 초기 스토리지로 채택했던 AWS S3의 한계를 직접 인정하고, 아파치 카산드라(Apache Cassandra)와 EVCache 기반의 자체 설계 스토리지 스택으로 전환한 과정을 상세히 기술했다.
핵심 요약 3줄
- 넷플릭스는 라이브 스트리밍의 2초 세그먼트 주기와 500ms 쓰기 실패 허용 기준을 충족하기 위해 AWS S3에서 자체 스토리지 스택으로 전환했다.
- 아파치 카산드라 + EVCache(멤캐시드) 조합으로 읽기-쓰기를 완전 분리, 200Gbps 이상의 읽기 처리량을 확보했다.
- 이중 인코딩 파이프라인 기반의 세그먼트 선별, 우선순위 레이트 리미팅, 계층적 404 처리를 통해 수백만 동시 스트리머를 실시간으로 보호한다.
S3의 한계, 그리고 자체 스토리지 설계
라이브 오리진은 AWS EC2 위에서 동작하는 멀티테넌트 마이크로서비스다. 넷플릭스는 초기 라이브 이벤트에 SVOD와 동일한 AWS S3를 스토리지로 활용했다. 저트래픽 단계에서는 문제가 없었다. 그러나 규모가 커지자 근본적인 구조 문제가 드러났다. 라이브 스트리밍은 2초마다 새 세그먼트를 발행한다. 500ms 이내에 쓰기에 실패하면 즉각 트리아지 대상이 되는 버그로 분류된다. 이 기준은 온디맨드 스토리지가 아닌 글로벌 저지연 고가용 데이터베이스에 가까운 요구 사항이다.
넷플릭스는 이를 "AWS S3는 놀라운 객체 스토어이지만, 라이브 스트리밍 요구 사항은 글로벌 저지연 고가용 데이터베이스에 더 가깝다"고 직접 서술했다. 해결책은 이미 게임 상태(Game State) 클라우드 저장을 위해 내부에 구축해 둔 키-값 스토리지 추상화 레이어였다. 아파치 카산드라의 로컬 쿼럼(local-quorum) 일관성 모델에 LSM 스토리지 엔진을 결합했다. 단일 가용 영역이 전체 장애 상황에서도 쓰기를 유지하는 구조다.
그러나 수십 개의 오픈 커넥트 노드가 동시에 수백 MiB 세그먼트를 요청하는 '오리진 스톰' 상황에서 카산드라만으로는 쓰기 성능이 급격히 저하되었다. 넷플릭스는 최악의 읽기 처리량을 약 100Gbps로 추산했다. 이를 해결하기 위해 멤캐시드 기반 분산 캐시 EVCache를 통한 라이트-스루(write-through) 캐싱을 도입했다. 거의 모든 읽기는 EVCache가 처리하고, 카산드라는 쓰기에만 집중하는 읽기-쓰기 완전 분리 구조다. 현재 이 스택은 200Gbps 이상의 읽기 처리량을 안정적으로 감당하며 1년 이상 운영 중이다.
이중 파이프라인 선별부터 404 폭풍 방어까지
스토리지 설계와 함께 라이브 오리진의 핵심 가치는 실시간 스트리밍 품질 제어에 있다. 라이브 스트림에는 짧은 세그먼트, 누락된 세그먼트, 타이밍 불연속 등 세 가지 주요 결함 유형이 상존한다. 넷플릭스는 이를 단일 파이프라인이 아닌 독립적으로 운영되는 이중 지역 파이프라인으로 대응한다. 라이브 오리진은 두 파이프라인의 후보를 결정론적 순서로 검사해 첫 번째 유효한 세그먼트를 선택한다.
두 파이프라인이 동시에 결함을 가진 드문 경우에는 클라이언트 측 오류 은닉(error concealment) 정보를 다운스트림으로 전달한다. 강화된 캐시 무효화와 오리진 마스킹 기능은 문제 세그먼트 발견 시 DVR 재생 윈도우 동안 수백만 클라이언트에게 해당 세그먼트를 숨기는 것을 가능하게 한다.
확장성 측면에서는 전통적인 오리진 실드 방식 대신 오픈 커넥트 최상위 노드와의 직접 연결 구조를 택했다. 시스템이 한계에 다다를 때는 우선순위 레이트 리미팅이 작동한다. DVR 트래픽보다 라이브 엣지 트래픽이 자동으로 우선 처리된다. 저우선순위 트래픽에는 max-age=5s 설정과 HTTP 503 오류 코드를 반환해 5초 창 내 반복 요청을 억제한다. 존재하지 않는 세그먼트 요청이 쏟아지는 '404 폭풍' 상황에서는 이벤트·스트림 렌디션·세그먼트의 계층적 메타데이터 구조가 작동한다. 인메모리 캐싱된 상위 계층 메타데이터만으로 요청의 90% 이상을 데이터스토어 접근 없이 차단한다. 밀리초 단위 nginx 캐싱, 세그먼트 발행 일정 기반 요청 홀드 오픈, HTTP 헤더를 통한 실시간 이벤트 알림 전파 등은 오픈 커넥트와의 통신 효율을 높이는 추가 장치들이다.
넷플릭스는 "스토리지 비용 최소화는 핵심 목표가 아니었다"고 명시했다. SSD 기반 데이터베이스 전환이 비용을 높였으나, P99 테일 지연 시간을 기존 방식의 P50 평균과 동등한 수준으로 낮춘 것이 핵심 성과다. 넷플릭스는 리전 간 복제와 라이트-스루 캐싱에서 해결한 구체적인 기술 세부 사항을 향후 별도 포스트로 공개할 예정이라고 밝혔다.
Source: Netflix Technology Blog, 2025년 12월 16일
[테크수다 기자 도안구 eyeball@techsuda.com]
1️⃣ 완역본
https://netflixtechblog.com/netflix-live-origin-41f1b0ad5371
넷플릭스 라이브 오리진
넷플릭스 테크놀로지 블로그 샤오메이 류, 조셉 린치, 크리스 뉴턴
소개
『스트림의 이면: 넷플릭스를 위한 신뢰할 수 있는 클라우드 라이브 스트리밍 파이프라인 구축』에서는 스트리밍 파이프라인의 아키텍처를 소개한 바 있다. 이번 블로그 포스트는 라이브를 위해 자체 구축한 커스텀 오리진 서버, 즉 '넷플릭스 라이브 오리진'을 다룬다. 라이브 오리진은 업스트림의 클라우드 라이브 스트리밍 파이프라인과 다운스트림의 배포 시스템인 넷플릭스 자체 CDN '오픈 커넥트(Open Connect)' 사이의 경계점에 위치하며, 어떤 콘텐츠가 오픈 커넥트를 거쳐 최종적으로 클라이언트 기기에 전달될지를 결정하는 브로커 역할을 한다.
넷플릭스 라이브 오리진은 AWS 클라우드 내 EC2 인스턴스에서 동작하는 멀티테넌트 마이크로서비스다. 라이브 오리진과의 통신에는 표준 HTTP 프로토콜을 활용한다. 패키저는 PUT 요청을 사용해 세그먼트를 오리진에 전송하며, 이는 URL에 지정된 특정 위치의 스토리지에 파일을 저장한다. 해당 스토리지 위치는 오픈 커넥트 측에서 해당 GET 요청을 보낼 때 사용하는 URL과 일치한다.
라이브 오리진 아키텍처는 라이브 스트리밍 아키텍처의 핵심 기술적 결정에 의해 형성되었다. 첫째, 이중화된 지역별 라이브 스트리밍 파이프라인을 통해 복원력을 확보하며, 클라이언트 복잡성을 줄이기 위해 서버 측에서 장애 조치(failover)를 조율한다. 클라우드 인코더에서의 에포크 잠금(epoch locking) 구현을 통해 오리진은 두 인코딩 파이프라인 중 어느 쪽에서도 세그먼트를 선택할 수 있다. 둘째, 넷플릭스는 잦은 매니페스트 갱신을 피하기 위해 세그먼트 템플릿과 고정 세그먼트 지속 시간을 활용한 매니페스트 설계를 채택했다. 이 고정 지속 시간 템플릿을 통해 오리진은 세그먼트 발행 일정을 예측할 수 있다.
멀티 파이프라인·멀티 리전 인식 오리진
라이브 스트림에는 라이브 기여 피드의 비결정적 특성과 엄격한 실시간 세그먼트 발행 타임라인으로 인해 불가피하게 결함이 발생한다. 주요 결함 유형은 다음과 같다:
- 짧은 세그먼트: 누락된 비디오 프레임 및 오디오 샘플
- 누락된 세그먼트: 전체 세그먼트 부재
- 세그먼트 타이밍 불연속: 트랙 프래그먼트 디코드 타임 관련 문제
세그먼트 템플릿 기반 매니페스트를 통해 서버에서 클라이언트로 세그먼트 불연속을 전달하는 것은 비실용적이며, 이러한 결함 세그먼트는 클라이언트 스트리밍을 방해할 수 있다.
이중화된 클라우드 스트리밍 파이프라인은 독립적으로 운영되며, 별도의 클라우드 리전, 기여 피드, 인코더, 패키저 배포를 포함한다. 이러한 독립성은 두 파이프라인에서 동시에 결함 세그먼트가 발생할 확률을 크게 낮춘다. 배포 경로 내 전략적 위치 덕분에 라이브 오리진은 자연스럽게 지능적인 후보 선택이 가능한 구성 요소로 부상한다.
넷플릭스 라이브 오리진은 멀티 파이프라인 및 멀티 리전 인식 기능을 갖추고 있다. 세그먼트 요청이 들어오면 라이브 오리진은 각 파이프라인의 후보를 결정론적 순서로 확인하고 첫 번째 유효한 것을 선택한다. 세그먼트 결함은 패키저에서의 경량 미디어 검사를 통해 감지된다. 이 결함 정보는 세그먼트가 라이브 오리진에 발행될 때 메타데이터 형태로 제공된다. 두 파이프라인에서 동시에 결함이 발생하는 드문 경우에는, 세그먼트 결함 정보가 다운스트림으로 전달되어 지능적인 클라이언트 측 오류 은닉(error concealment)에 활용될 수 있다.
오픈 커넥트 스트리밍 최적화
라이브 프로젝트가 시작될 당시 오픈 커넥트는 VOD 콘텐츠 전달에 고도로 최적화되어 있었다. nginx는 수년 전부터 웹 서버로 채택되어 왔으며, nginx 자체 및 기반 운영체제(BSD)에 다수의 개선이 추가되었다. 일반 CDN과 달리 오픈 커넥트는 분산 오리진 서버에 가깝다. VOD 자산은 수요에 따라 채워지는 방식이 아니라 신중하게 선택된 서버 머신(OCA, 오픈 커넥트 어플라이언스)에 사전 배치된다.
VOD 전달과 함께 아트워크, 클라이언트 다운로드 등 비VOD 자산에는 온디맨드 채우기(fill) 시스템이 사용되었다. 이들도 별도의 서버 블록과 호스트명 세트를 사용하지만 동일한 nginx 워커에서 서비스된다.
라이브는 이 '소규모 객체 전달' 모델에 깔끔히 맞지 않았기 때문에, 라이브 전용 요구 사항을 충족하기 위해 nginx의 프록시 캐싱 기능을 확장했다. 여기서는 오리진 서버와의 최적화된 상호작용과 관련된 몇 가지 사항을 다룬다. 오픈 커넥트 측의 세부 내용은 향후 블로그 포스트에서 다룰 예정이다.
클라이언트에 제공되는 세그먼트 템플릿은 라이브 이벤트 구성 데이터의 일부로 OCA에도 제공된다. 가용 시작 시간(Availability Start Time)과 초기 세그먼트 번호를 사용해 OCA는 언제든지 각 이벤트의 유효한 세그먼트 범위를 결정할 수 있다. 이 범위를 벗어난 객체 요청은 거부되어, 불필요한 요청이 채우기 계층 구조를 통해 오리진까지 올라가는 것을 방지한다. 요청이 오리진까지 도달했으나 세그먼트가 아직 준비되지 않은 경우, 오리진 서버는 해당 세그먼트가 발행될 것으로 예상되는 시점 직전까지 오픈 커넥트 내에서 캐시될 수 있도록 만료 정책과 함께 404 상태 코드를 반환한다.
라이브 오리진이 세그먼트가 언제 전송될지 알고, 라이브 엣지가 언제인지 알면, 바로 다음 객체 요청이 들어올 때 또 다른 404 오류(오픈 커넥트를 거쳐 클라이언트까지 반환되는)를 되돌리는 대신, 라이브 오리진은 요청을 '홀드 오픈(hold open)' 상태로 유지하다가 세그먼트가 발행되면 바로 서비스할 수 있다. 이 방식으로 일찍 도착한 요청을 처리하는 네트워크 내 불필요한 통신량이 크게 줄었다. 이를 위해 nginx에 밀리초 단위 캐싱이 추가되었다. 표준 HTTP 캐시 컨트롤은 초 단위로만 동작하는데, 세그먼트가 2초마다 생성되는 환경에서는 이것이 매우 긴 시간이다.
스트리밍 메타데이터 강화
HTTP 표준은 파일이 클라이언트와 서버 간에 이동할 때 추가 정보를 제공하는 요청 및 응답 헤더 추가를 허용한다. HTTP 헤더는 스트림 내 이벤트 알림을 고도로 확장 가능한 방식으로 제공하며, 이는 스트림 내 재생 위치와 무관하게 클라이언트 기기에 독립적으로 전달된다.
이러한 알림은 라이브 스트리밍 파이프라인에 의해 오리진에 제공되며, 해당 시점에 생성된 세그먼트에 헤더 형태로 삽입된다(이후 세그먼트에도 누적 적용된다). OCA에서 세그먼트가 수신될 때마다 응답 헤더에서 이 알림 정보를 추출해 이벤트 ID를 키로 하는 인메모리 데이터 구조를 업데이트한다. 세그먼트가 OCA에서 서비스될 때마다 최신 알림 데이터가 응답에 첨부된다. 이 방식은 OCA에 유입되는 세그먼트 흐름이 있는 한, 모든 클라이언트가 라이브 엣지보다 뒤처져 있더라도 항상 가장 최신 알림 데이터를 보유할 수 있음을 의미한다. 실제로 알림 정보는 새 세그먼트를 제공하는 응답뿐 아니라 모든 응답에 전달될 수 있다.
캐시 무효화와 오리진 마스크
무효화(invalidation) 시스템은 프로젝트 초기부터 도입되었다. 캐시에서 객체를 조회할 때 사용하는 키에 버전 번호를 포함시키고 이를 필요에 따라 증가시키는 방식으로 이벤트와 연관된 모든 콘텐츠를 '플러시'할 수 있다. 이는 이벤트 전 테스트 시 네트워크를 깨끗한 상태로 되돌리는 데 활용된다.
라이브 오리진이 발행하는 각 세그먼트에는 생성된 인코딩 파이프라인과 요청된 리전 정보가 포함된다. 세그먼트가 네트워크에 들어간 후 발견된 문제는 이러한 변형을 고려한 강화된 무효화 시스템으로 해결할 수 있다. 특정 범위의 세그먼트 번호를 무효화(만료 처리)하되, 인코더 A에서 생성된 것만, 또는 인코더 A에서 생성되었지만 리전 X에서 검색된 것만 선택적으로 처리하는 것이 가능하다.
오픈 커넥트의 강화된 캐시 무효화와 결합해, 넷플릭스 라이브 오리진은 선택적 인코딩 파이프라인 마스킹을 통해 특정 파이프라인의 세그먼트 범위를 오픈 커넥트 서비스에서 제외할 수 있다. 강화된 캐시 무효화와 오리진 마스킹을 통해 라이브 스트리밍 운영팀은 문제 세그먼트(예: 클라이언트 재생 오류를 유발하는 세그먼트)가 감지된 후 DVR 재생 윈도우 동안 수백만 스트리밍 클라이언트에게 노출되지 않도록 숨길 수 있다.
오리진 스토리지 아키텍처
라이브 오리진의 초기 스토리지 아키텍처는 단순했다. SVOD와 마찬가지로 AWS S3를 사용했다. 초기 저트래픽 이벤트에서는 잘 작동했으나 규모를 확장하면서 라이브 스트리밍의 고유한 지연 시간 및 워크로드 요구 사항이 온디맨드와 크게 다름을 발견했다. 온디맨드에서는 콘텐츠를 사전 배치할 충분한 시간이 있다. S3는 명시된 가동 시간 보장을 충족했으나, 라이브 이벤트에서 모든 쓰기가 중요하다는 특성상 2초의 엄격한 재시도 예산이 실시간 대규모 전달에 최적화된 솔루션을 모색하게 했다. AWS S3는 놀라운 객체 스토어이지만, 라이브 스트리밍 요구 사항은 글로벌 저지연 고가용 데이터베이스에 더 가까웠다.
따라서 요구 사항에서부터 다시 시작했다. 오리진에 필요한 것은 다음과 같다:
- [고가용 쓰기] 단일 AWS 리전 내 완전한 쓰기 가용성에 가까운 극도로 높은 쓰기 가용성, 타 리전으로의 수 초 이내 복제 지연. 500ms 이내 실패한 쓰기 작업은 트리아지 및 재발 방지가 필요한 버그로 간주.
- [처리량] 리전 간 수백 MiB 복제를 포함한 높은 쓰기 처리량
- [대형 파티션] 파티션당 O(10k) 키, 이벤트당 O(GiB) 총 크기까지 누적되는 O(MiB) 쓰기를 효율적으로 지원
- [강력한 일관성] 동일 리전 내에서 <1초 읽기 지연 요구 사항(발행된 세그먼트를 읽을 수 있어야 함)을 충족하기 위한 읽기-쓰기 일관성
- [오리진 스톰] 오픈 커넥트 엣지 케이스를 포함한 최악의 부하 시 쓰기에 영향 없이 O(GiB) 수준의 읽기 처리량 처리
다행히 넷플릭스는 MiB 또는 GiB 값의 청크 스토리지를 제공하기 위해 아파치 카산드라(Apache Cassandra)를 영리하게 활용하는 키-값 스토리지 추상화 레이어에 선투자했다. 이 추상화는 처음에 게임 상태의 클라우드 저장을 지원하기 위해 구축되었다. 라이브 유스케이스는 쓰기 가용성, 누적 파티션 크기, 오리진 스톰 시 읽기 처리량 측면에서 이 솔루션의 한계를 시험했다.
대형 페이로드 쓰기의 고가용성
키-값 페이로드 청킹 및 압축 알고리즘은 O(MiB) 작업을 각 파트가 멱등적으로 재시도·헤징될 수 있도록 분해해 엄격한 지연 서비스 수준 목표를 유지하고 전체 클러스터에 데이터를 분산한다. 이 알고리즘을 아파치 카산드라의 로컬 쿼럼(local-quorum) 일관성 모델(전체 가용 영역 장애 시에도 쓰기 가용성 허용) 및 쓰기 최적화 LSM(로그 구조화 병합 트리) 스토리지 엔진과 결합하면 처음 네 가지 요구 사항을 충족할 수 있었다. 이 솔루션의 성능과 가용성을 반복 개선한 결과, 필요한 쓰기 가용성을 달성했을 뿐 아니라, SSD 기반 데이터베이스는 비용이 더 들었지만 기존 방식의 P50 평균 지연 시간과 유사한 P99 테일 지연 시간으로 리전 간 복제까지 처리할 수 있었다. 비용 최소화는 핵심 목표가 아니었으며, 저지연 고가용성이 우선이었다.
Gbps 처리량에서의 고가용성 읽기
쓰기 안정성 문제를 해결한 후에는 오리진 스톰 장애 케이스를 처리해야 했다. 수십 개의 오픈 커넥트 최상위 캐시가 동시에 여러 O(MiB) 비디오 세그먼트를 요청할 수 있는 상황이다. 대략적인 계산에 따르면 최악의 경우 읽기 처리량이 O(100Gbps) 범위에 달하는데, 이는 아파치 카산드라와 같은 강력한 일관성 스토리지 엔진에서는 매우 비용이 높다. 청크 접근 방식을 신중하게 튜닝해 아파치 카산드라에서 네트워크 라인 속도(100Gbps)로 읽기를 처리할 수 있었으나, 동시 쓰기에서 허용 불가능한 성능 및 가용성 저하가 관찰되었다. 이 문제를 해결하기 위해 멤캐시드(Memcached) 기반의 분산 캐싱 시스템 EVCache를 사용해 청크의 라이트-스루(write-through) 캐싱을 도입했다. 이를 통해 거의 모든 읽기를 고도로 확장 가능한 캐시에서 처리하고, 쓰기 경로에 영향 없이 200Gbps 이상을 쉽게 처리해 읽기-쓰기 분리를 달성했다.
최종 스토리지 아키텍처
최종 스토리지 아키텍처에서 라이브 오리진은 키-값 저장소에 쓰고 읽는다. 키-값 저장소는 EVCache(멤캐시드)에 대한 라이트-스루 캐시를 관리하고, 대형 값을 분산시키고 스토리지 클러스터 전체에 파티셔닝하는 안전한 청킹 프로토콜을 구현한다(아파치 카산드라). 이를 통해 거의 모든 읽기 부하를 캐시에서 처리하고, 미스(miss)만 스토리지에 도달한다. 이 캐시와 고가용 스토리지의 조합은 1년 이상 라이브 오리진의 까다로운 요구를 충족해 왔다.
확장성과 확장 가능한 아키텍처
넷플릭스의 라이브 스트리밍 플랫폼은 각 라이브 이벤트에 대해 다양하고 대규모의 스트림 렌디션(rendition)을 처리해야 한다. 다양한 비디오 인코딩 형식(각각 여러 인코더 래더), 다수의 오디오 옵션(언어, 형식, 비트레이트), 다른 콘텐츠 버전(광고 유무 등)을 지원해야 하는 복잡성이 여기서 비롯된다. 이러한 요소들의 조합과 동시 이벤트 지원은 라이브 이벤트당 상당수의 고유 스트림 렌디션을 만들어 낸다. 이는 멀티테넌트 라이브 오리진 서비스에 높은 RPS(초당 요청 수) 처리 용량을 요구한다.
또한 넷플릭스의 글로벌 도달 범위는 검색 측면에서 라이브 오리진에 독특한 과제를 제시한다. 2024년 타이슨 vs. 폴 경기 이벤트에서는 6,500만 동시 스트림이라는 역대 최고 피크가 기록되었다.
확장 아키텍처
전통적인 오리진 실드(origin shield) 방식 대신 더 나은 엔드-투-엔드 캐시 일관성 제어와 단순한 시스템 아키텍처를 위해 고도로 확장 가능한 오리진을 구축하는 방향을 선택했다. 이 아키텍처에서 라이브 오리진은 여러 사이트에 지리적으로 분산된 오픈 커넥트 최상위 노드와 직접 연결된다. 오리진 부하를 최소화하기 위해, 각 사이트에서 스트림 렌디션별로 지정된 노드만 오리진에서 직접 채우기(fill)를 허용받는다.
오리진 서비스는 EC2 인스턴스를 사용해 수평적으로 자동 확장될 수 있지만, 스토리지 플랫폼 용량이나 AWS-오픈 커넥트 백본 대역폭 용량 같은 자동 확장이 불가능한 시스템 리소스도 있다. 라이브 스트리밍에서 라이브 오리진에 대한 모든 요청이 동일한 중요도를 갖지는 않기 때문에, 오리진은 시스템 리소스가 제한될 때 덜 중요한 요청보다 더 중요한 요청을 우선 처리하도록 설계되어 있다.
발행 격리
잠재적으로 급증할 수 있는 CDN 검색 트래픽과 달리 발행 트래픽은 예측 가능하므로, 경로 격리는 매우 효과적인 솔루션이다. 오리진은 별도의 EC2 발행 및 CDN 스택을 활용해 지연 시간 및 장애에 민감한 오리진 쓰기를 보호한다. 또한 스토리지 추상화 계층에는 키-값 읽기와 쓰기 작업을 위한 별도 클러스터가 있다. 스토리지 계층 자체도 읽기(EVCache)와 쓰기(카산드라) 경로를 분리한다. 이 포괄적인 경로 격리는 발행과 검색의 독립적인 클라우드 확장을 가능하게 하며, CDN 대면 트래픽 급증이 오리진 발행의 성능과 신뢰성에 영향을 미치는 것을 방지한다.
우선순위 레이트 리미팅
넷플릭스의 규모에서는 트래픽 폭풍 중 들어오는 요청을 관리하는 것이 어렵다. 특히 자동 확장이 불가능한 시스템 리소스를 고려하면 더욱 그렇다. 넷플릭스 라이브 오리진은 기저 시스템이 스트레스를 받을 때 우선순위 기반 레이트 리미팅을 구현했다. 이 접근 방식은 사용자 영향이 큰 요청이 우선 처리되도록 하며, 스트리밍 인프라를 보호하기 위해 스트레스 시 사용자 영향이 낮은 요청은 실패를 허용하고 나중에 재시도할 수 있게 한다.
넷플릭스 마이크로서비스 플랫폼의 우선순위 레이트 리미팅 기능을 활용해, 스토리지 플랫폼 고부하 시 라이브 엣지 트래픽이 DVR 트래픽보다 우선 처리된다. 라이브 엣지 대 DVR 트래픽 감지는 예측 가능한 세그먼트 템플릿을 기반으로 한다. 템플릿은 데이터스토어 접근 없이 우선순위 레이트 리미팅을 가능하게 하기 위해 오리진 노드에 인메모리 캐시된다. 이는 데이터스토어 고스트레스 시 특히 유용하다.
트래픽 급증을 완화하기 위해 우선순위 레이트 리미팅과 함께 TTL 캐시 컨트롤이 사용된다. 저우선순위 트래픽이 영향을 받을 때 오리진은 max-age=5s를 설정하고 HTTP 503 오류 코드를 반환해 오픈 커넥트가 동일한 요청을 5초간 캐시하도록 지시한다. 이 전략은 해당 5초 창 내에서 오리진에 대한 반복 요청을 방지해 트래픽 급증을 효과적으로 완화한다.
404 스톰과 캐시 최적화
발행 격리와 우선순위 레이트 리미팅은 DVR 트래픽 폭풍으로부터 라이브 오리진을 성공적으로 보호한다. 그러나 존재하지 않는 세그먼트 요청으로 인한 트래픽 폭풍은 추가적인 과제와 최적화 기회를 제시한다.
라이브 오리진은 메타데이터를 이벤트 > 스트림 렌디션 > 세그먼트로 계층적으로 구성하며, 세그먼트 발행 템플릿은 스트림 렌디션 수준에서 유지된다. 이 계층적 구성 덕분에 오리진은 이벤트 및 스트림 렌디션 수준의 높은 캐시 가능 메타데이터를 활용해 세그먼트 수준 메타데이터에 대한 불필요한 쿼리 없이 요청을 선제적으로 거부할 수 있다:
- 이벤트가 알 수 없는 경우: 404로 요청 거부
- 이벤트는 알지만 세그먼트 요청 타이밍이 예상 발행 타이밍과 맞지 않는 경우: 예상 발행 시간에 맞는 캐시 컨트롤 TTL과 함께 404로 거부
- 이벤트는 알지만 요청된 세그먼트가 생성되지 않거나 재시도 기한을 놓친 경우: 클라이언트의 반복 요청을 방지하는 410 오류로 거부
스토리지 계층에서 메타데이터는 컨트롤 플레인 데이터스토어에 미디어 데이터와 별도로 저장된다. 미디어 데이터스토어와 달리 컨트롤 플레인 데이터스토어는 캐시 불일관성을 피하기 위해 분산 캐시를 사용하지 않는다. 이벤트 및 렌디션 수준 메타데이터는 라이브 오리진 인스턴스에서 인메모리 캐싱을 활용할 때 높은 캐시 적중률을 보인다. 존재하지 않는 세그먼트를 포함한 트래픽 폭풍 시 컨트롤 플레인 접근의 캐시 적중률은 90%를 쉽게 초과한다.
메타데이터에 대한 인메모리 캐싱 사용은 데이터스토어 스트레스 없이 라이브 오리진에서 404 폭풍을 효과적으로 처리한다. 이 메타데이터 캐싱은 스토리지 시스템의 분산 미디어 캐시를 보완하며, 트래픽 급증 보호를 위한 완전한 솔루션을 제공한다.
요약
넷플릭스 라이브 오리진은 최적화된 스토리지 플랫폼 위에 구축된 라이브 스트리밍 특화 설계를 갖추고 있다. 고급 미디어 및 세그먼트 발행 일정 인식과 향상된 지능을 활용해 스트리밍 품질을 개선하고, 확장성을 최적화하며, 오픈 커넥트 라이브 스트리밍 운영을 향상시킨다.