Netflix Live Origin의 아키텍처, 저장소 설계, 확장성 최적화를 통해 대규모 라이브 스트리밍을 안정적으로 제공하는 방법을 소개합니다.
14분 읽기
2025년 12월 15일
Xiaomei Liu, Joseph Lynch, Chris Newton
Behind the Streams: Building a Reliable Cloud Live Streaming Pipeline for Netflix에서는 스트리밍 파이프라인의 아키텍처를 소개했습니다. 이 글에서는 라이브를 위해 우리가 구축한 맞춤형 Origin Server, 즉 Netflix Live Origin을 살펴봅니다. 이 시스템은 업스트림 측의 클라우드 라이브 스트리밍 파이프라인과 다운스트림 측의 배포 시스템인 Open Connect, 즉 Netflix의 자체 Content Delivery Network (CDN) 사이의 경계 지점에 위치하며, 어떤 콘텐츠가 Open Connect로 나가고 궁극적으로 클라이언트 디바이스에 도달할지를 관리하는 브로커 역할을 합니다.
엔터 키를 누르거나 클릭하여 전체 크기 이미지 보기
라이브 스트리밍 배포 및 오리진 아키텍처
Netflix Live Origin은 AWS 클라우드 내 EC2 인스턴스에서 동작하는 멀티 테넌트 마이크로서비스입니다. 우리는 Live Origin과 통신하기 위해 표준 HTTP 프로토콜 기능을 활용합니다. Packager는 PUT 요청을 사용해 세그먼트를 이 시스템으로 푸시하며, 이 요청은 URL에 지정된 특정 위치의 스토리지에 파일을 저장합니다. 이 저장 위치는 Open Connect 측에서 해당 GET 요청을 발행할 때 사용하는 URL과 대응됩니다.
Live Origin의 아키텍처는 라이브 스트리밍 아키텍처의 핵심 기술적 결정들에 영향을 받았습니다. 첫째, 복원력은 중복된 리전별 라이브 스트리밍 파이프라인을 통해 달성되며, 클라이언트 복잡성을 줄이기 위해 서버 측에서 페일오버를 오케스트레이션합니다. 클라우드 인코더의 epoch locking 구현은 오리진이 어느 인코딩 파이프라인에서든 세그먼트를 선택할 수 있게 합니다. 둘째, Netflix는 잦은 매니페스트 새로고침을 피하기 위해 segment templates와 constant segment duration을 사용하는 매니페스트 설계를 채택했습니다. 일정한 길이의 템플릿 덕분에 Origin은 세그먼트 게시 일정을 예측할 수 있습니다.
라이브 스트림은 라이브 기여 피드의 비결정적 특성과 엄격한 실시간 세그먼트 게시 일정 때문에 필연적으로 결함을 포함하게 됩니다. 일반적인 결함은 다음과 같습니다.
세그먼트 템플릿 기반 매니페스트를 통해 서버에서 클라이언트로 세그먼트 불연속성을 전달하는 것은 비현실적이며, 이러한 결함 세그먼트는 클라이언트 스트리밍을 방해할 수 있습니다.
중복된 클라우드 스트리밍 파이프라인은 서로 독립적으로 운영되며, 서로 다른 클라우드 리전, 기여 피드, 인코더, Packager 배포를 포함합니다. 이러한 독립성은 두 파이프라인에서 동시에 결함 세그먼트가 발생할 확률을 크게 낮춥니다. 배포 경로 내의 전략적 위치 덕분에 라이브 오리진은 지능적인 후보 선택을 수행할 수 있는 컴포넌트로 자연스럽게 자리 잡게 됩니다.
Netflix Live Origin은 멀티 파이프라인 및 멀티 리전 인지 기능을 갖추고 있습니다. 세그먼트 요청이 들어오면 라이브 오리진은 각 파이프라인의 후보를 결정적인 순서로 확인하고, 첫 번째로 유효한 것을 선택합니다. 세그먼트 결함은 Packager에서 수행하는 경량 미디어 검사로 감지됩니다. 이 결함 정보는 세그먼트가 라이브 오리진에 게시될 때 메타데이터로 제공됩니다. 드물게 두 파이프라인 모두에 동시에 결함이 발생하는 경우, 세그먼트 결함은 다운스트림으로 전달되어 클라이언트 측의 지능적인 오류 은폐에 활용될 수 있습니다.
Live 프로젝트가 시작되었을 때 Open Connect는 이미 VOD 콘텐츠 전달에 매우 최적화되어 있었습니다. nginx는 이 역할에 매우 적합했기 때문에 오래전에 Web Server로 선택되었고, 여기에 더해 여러 향상 기능이 해당 소프트웨어와 기반 운영체제(BSD)에 추가되었습니다. 전통적인 CDN과 달리 Open Connect는 분산 오리진 서버에 더 가깝습니다. VOD 자산은 요청 시 채워지는 것이 아니라 신중하게 선택된 서버 장비(OCA, Open Connect Appliances)에 미리 배치됩니다.
VOD 전달과 함께 비 VOD 자산을 위한 주문형 채움 시스템도 사용되어 왔습니다. 여기에는 아트워크, 클라이언트의 다운로드 가능한 부분 등이 포함됩니다. 이러한 자산 역시 동일한 nginx 워커에서 제공되지만, 별도의 서버 블록과 별도의 호스트 이름 집합 아래에서 처리됩니다.
Live는 이 ‘작은 객체 전달’ 모델에 깔끔하게 들어맞지 않았기 때문에, 우리는 라이브 특화 요구사항을 해결하기 위해 nginx의 proxy-caching 기능을 확장했습니다. 여기서는 Origin Server와의 최적화된 상호작용과 관련된 몇 가지를 다룹니다. Open Connect 측의 더 자세한 내용은 향후 블로그 글에서 소개할 예정입니다.
클라이언트에 제공되는 segment templates는 Live Event Configuration 데이터의 일부로 OCA에도 제공됩니다. Availability Start Time과 Initial Segment number를 이용해 OCA는 어느 시점이든 각 이벤트에 대해 유효한 세그먼트 범위를 판단할 수 있습니다. 이 범위를 벗어난 객체 요청은 거부할 수 있어, fill 계층을 따라 오리진까지 올라가는 불필요한 요청을 막을 수 있습니다. 요청이 오리진까지 도달했지만 세그먼트가 아직 준비되지 않은 경우, 오리진 서버는 404 Status Code(파일을 찾을 수 없음을 의미)와 함께 해당 오류의 만료 정책을 반환하여, 세그먼트가 게시될 것으로 예상되기 직전까지 Open Connect 내부에서 캐시되도록 합니다.
Live Origin이 세그먼트가 자신에게 푸시되는 시점을 알고 있고 라이브 에지가 어디인지도 알고 있다면, 바로 다음 객체에 대한 요청을 받았을 때 또 다른 404 오류를 반환하는 대신(이 경우 요청은 Open Connect를 거쳐 클라이언트까지 되돌아가야 함), Live Origin은 요청을 ‘열어 둔 채’ 유지하고 세그먼트가 게시되면 이를 처리할 수 있습니다. 이렇게 함으로써 너무 일찍 도착한 요청을 처리하는 네트워크 내부의 불필요한 통신량을 크게 줄였습니다. 이의 일환으로 nginx에는 밀리초 단위 캐싱이 추가되어, 세그먼트가 2초마다 생성되는 환경에서 초 단위만 지원하는 표준 HTTP Cache Control을 보완했습니다.
HTTP 표준은 클라이언트와 서버 사이에서 파일이 이동할 때 추가 정보를 제공하기 위해 사용할 수 있는 요청 및 응답 헤더의 추가를 허용합니다. HTTP 헤더는 스트림 내 이벤트 알림을 매우 확장 가능한 방식으로 제공하며, 이는 스트림 내 재생 위치와 무관하게 각 클라이언트 디바이스에 독립적으로 전달됩니다.
이러한 알림은 라이브 스트리밍 파이프라인에 의해 오리진에 제공되며, 오리진은 이를 헤더 형태로 삽입하여 해당 시점에 생성되는 세그먼트에 표시되게 합니다. 그리고 이 정보는 이후 세그먼트에도 지속되며 누적됩니다. OCA가 세그먼트를 받을 때마다 이 알림 정보는 응답 헤더에서 추출되어 이벤트 ID를 키로 하는 메모리 내 데이터 구조를 갱신하는 데 사용됩니다. 그리고 OCA에서 세그먼트를 제공할 때마다 가장 최신의 알림 데이터가 응답에 첨부됩니다. 이는 OCA로 어떤 세그먼트 흐름이 들어오더라도, 설령 그것을 요청하는 모든 클라이언트가 라이브 에지보다 뒤에 있더라도, 항상 가장 최근의 알림 데이터를 보유하게 됨을 의미합니다. 실제로 알림 정보는 새로운 세그먼트를 제공하는 응답뿐 아니라 어떤 응답을 통해서도 전달될 수 있습니다.
프로젝트 초기부터 무효화 시스템이 제공되어 왔습니다. 이 시스템은 캐시에서 객체를 조회할 때 사용하는 키를 변경함으로써 이벤트와 연관된 모든 콘텐츠를 “flush”하는 데 사용할 수 있습니다. 이는 캐시 키에 버전 번호를 포함시키고 필요 시 이를 증가시키는 방식으로 이루어집니다. 이 기능은 이벤트 전 테스트 중에 네트워크를 큰 번거로움 없이 깨끗한 상태로 되돌리는 데 사용됩니다.
Live Origin이 게시하는 각 세그먼트는 자신이 어떤 인코딩 파이프라인에서 생성되었는지와 어떤 리전에서 요청되었는지를 함께 전달합니다. 세그먼트가 네트워크 안으로 들어간 뒤 발견되는 문제는 이러한 변형을 고려하는 향상된 무효화 시스템을 통해 해결할 수 있습니다. 즉, 세그먼트 번호 범위에 대해 무효화를 수행할 수 있으며, 단 encoder A에서 생성된 경우에만, 또는 encoder A에서 생성되었더라도 region X에서 조회된 경우에만 무효화할 수 있습니다.
이 작성자의 업데이트를 받기 위해 Medium에 무료로 가입하세요.
더 빠른 로그인을 위해 나를 기억하기
Open Connect의 향상된 캐시 무효화와 결합하여, Netflix Live Origin은 Open Connect에 세그먼트를 제공할 때 특정 파이프라인의 세그먼트 범위를 제외할 수 있는 선택적 인코딩 파이프라인 마스킹 기능을 제공합니다. 향상된 캐시 무효화와 오리진 마스킹은 라이브 스트리밍 운영이 문제 있는 세그먼트(예: 클라이언트 재생 오류를 일으키는 세그먼트)를 탐지한 뒤 스트리밍 클라이언트에게서 숨길 수 있게 하며, DVR 재생 구간 동안 수백만 스트리밍 클라이언트를 보호합니다.
Live Origin의 초기 저장소 아키텍처는 단순했습니다. SVOD에서와 마찬가지로 AWS S3를 사용하는 것이었습니다. 이는 초기의 저트래픽 이벤트에서는 잘 동작했지만, 규모가 커지면서 우리는 라이브 스트리밍이 주문형 서비스와는 크게 다른 지연 시간 및 워크로드 요구사항을 가진다는 점을 발견했습니다. 주문형에서는 콘텐츠를 미리 충분한 시간 동안 사전 배치할 수 있지만 라이브는 그렇지 않습니다. S3는 명시된 가용성 보장을 충족했지만, 모든 쓰기가 중요한 라이브 이벤트의 특성상 엄격한 2초 재시도 예산 때문에 우리는 대규모 실시간 전달에 특화된 최적화를 탐색하게 되었습니다. AWS S3는 놀라운 객체 저장소이지만, 우리의 라이브 스트리밍 요구사항은 전 세계적으로 저지연과 고가용성을 제공하는 데이터베이스에 더 가까웠습니다. 그래서 우리는 다시 요구사항에서부터 설계를 시작했습니다. 오리진에는 다음이 필요했습니다.
다행히 Netflix는 이전에 KeyValue Storage Abstraction을 구축하는 데 투자한 바 있었고, 이는 Apache Cassandra를 영리하게 활용해 MiB 또는 GiB 크기의 값을 청크 단위로 저장할 수 있게 했습니다. 이 추상화는 원래 게임 상태의 클라우드 저장을 지원하기 위해 만들어졌습니다. 그러나 Live 사용 사례는 쓰기 가용성 (#1), 누적 파티션 크기 (#3), Origin Storm 시 읽기 처리량 (#5) 측면에서 이 솔루션의 한계를 시험하게 되었습니다.
KeyValue Payload Chunking and Compression Algorithm은 O(MiB) 규모의 작업을 더 작은 부분으로 나누어, 각 부분이 엄격한 지연 시간 서비스 수준 목표를 유지하도록 idempotent하게 재시도되고 hedging될 수 있게 하며, 동시에 데이터를 전체 클러스터에 분산시킵니다. 이 알고리즘을 Apache Cassandra의 local-quorum 일관성 모델과 결합하면, 이는 전체 Availability Zone 장애 상황에서도 쓰기 가용성을 허용합니다. 여기에 쓰기에 최적화된 Log-Structured Merge Tree (LSM) 저장 엔진까지 더해져, 첫 네 가지 요구사항을 충족할 수 있었습니다. 이 솔루션의 성능과 가용성을 반복적으로 개선한 결과, 우리는 요구된 쓰기 가용성을 달성했을 뿐 아니라, Origin을 위한 리전 간 복제를 백그라운드에서 처리하면서도 P99 tail 지연 시간을 기존 방식의 P50 average 지연 시간과 비슷한 수준으로 만들 수 있었습니다. 이 새 솔루션은 분명 훨씬 더 비쌌습니다(예상대로 SSD 기반 데이터베이스는 더 많은 비용이 듭니다). 하지만 비용 최소화는 핵심 목표가 아니었고, 낮은 지연 시간과 높은 가용성이 핵심 목표였습니다.
엔터 키를 누르거나 클릭하여 전체 크기 이미지 보기
저장소 시스템 쓰기 성능
이제 쓰기 신뢰성 문제를 해결했으므로, 잠재적으로 수십 개의 Open Connect 상위 계층 캐시가 동시에 여러 O(MiB) 비디오 세그먼트를 요청할 수 있는 Origin Storm 실패 사례를 처리해야 했습니다. 대략적인 계산 결과 최악의 경우 읽기 처리량은 O(100Gbps) 범위에 이를 수 있었고, 이는 일반적으로 Apache Cassandra와 같은 강한 일관성을 가진 저장 엔진에서는 매우 비쌉니다. 청크 접근을 세심하게 튜닝함으로써 우리는 Apache Cassandra에서 네트워크 선속도(100Gbps) 수준으로 읽기 응답을 제공할 수 있었지만, 동시 쓰기에서 받아들일 수 없는 성능 및 가용성 저하를 관찰했습니다. 이 문제를 해결하기 위해 우리는 Memcached 기반의 분산 캐싱 시스템인 EVCache를 사용해 청크에 대한 write-through 캐싱을 도입했습니다. 이를 통해 거의 모든 읽기를 매우 확장 가능한 캐시에서 처리할 수 있게 되었고, 쓰기 경로에 영향을 주지 않으면서도 손쉽게 200Gbps 이상을 달성하여 읽기-쓰기 분리를 실현할 수 있었습니다.
최종 저장소 아키텍처에서 Live Origin은 KeyValue에 읽기와 쓰기를 수행하며, KeyValue는 EVCache(memcached)에 대한 write-through 캐시를 관리하고 대용량 값을 안전하게 청크로 분할하여 저장소 클러스터(Apache Cassandra) 전반에 퍼뜨리는 프로토콜을 구현합니다. 이를 통해 거의 모든 읽기 부하는 캐시에서 처리되고, 미스만 저장소에 도달합니다. 이 캐시와 고가용성 저장소의 조합은 1년이 넘는 기간 동안 우리의 Live Origin의 까다로운 요구사항을 충족해 왔습니다.
엔터 키를 누르거나 클릭하여 전체 크기 이미지 보기
저장소 시스템 상위 수준 아키텍처
리전 간 복제와 분산 캐시에 대한 일관된 write-through 캐싱을 갖춘 대용량 쓰기에서 이 일관된 저지연을 제공하기 위해서는 새로운 기법을 활용해 수많은 어려운 문제를 해결해야 했으며, 이에 대해서는 향후 글에서 자세히 공유할 계획입니다.
Netflix의 라이브 스트리밍 플랫폼은 각 라이브 이벤트에 대해 매우 다양한 스트림 rendition을 대량으로 처리해야 합니다. 이러한 복잡성은 여러 비디오 인코딩 형식(각각 여러 encoder ladder 포함), 수많은 오디오 옵션(언어, 형식, 비트레이트 전반), 그리고 다양한 콘텐츠 버전(예: 광고 포함 또는 비포함)을 지원해야 하기 때문에 발생합니다. 이러한 요소들의 조합은 동시 이벤트 지원과 함께 라이브 이벤트당 상당한 수의 고유한 스트림 rendition을 만들어냅니다. 이는 다시 게시 측 확장성을 보장하기 위해 멀티 테넌트 라이브 오리진 서비스가 높은 Requests Per Second (RPS) 용량을 제공해야 함을 의미합니다.
또한 Netflix의 글로벌 서비스 범위는 조회 측면에서 라이브 오리진에 고유한 과제를 제시합니다. 2024년 Tyson vs. Paul 경기 이벤트 동안 동시 스트림 수는 역사적인 최고치인 6천5백만 건을 기록했습니다. 따라서 대규모 라이브 스트리밍의 성공을 위해서는 라이브 오리진의 확장 가능한 아키텍처가 필수적입니다.
우리는 종단 간 캐시 일관성을 더 잘 제어하고 시스템 아키텍처를 더 단순하게 만들기 위해 전통적인 origin shields 방식에 의존하는 대신 매우 확장 가능한 오리진을 구축하기로 선택했습니다. 이 아키텍처에서 라이브 오리진은 여러 사이트에 지리적으로 분산된 최상위 Open Connect 노드와 직접 연결됩니다. 오리진의 부하를 최소화하기 위해 각 사이트에서는 각 스트림 rendition당 지정된 노드만 오리진에서 직접 fill할 수 있습니다.
엔터 키를 누르거나 클릭하여 전체 크기 이미지 보기
Netflix Live Origin 확장성 아키텍처
오리진 서비스는 EC2 인스턴스를 사용해 수평 자동 확장이 가능하지만, 저장소 플랫폼 용량이나 AWS와 Open Connect 사이의 백본 대역폭 용량처럼 자동 확장이 불가능한 다른 시스템 자원도 존재합니다. 라이브 스트리밍에서는 라이브 오리진으로 들어오는 모든 요청이 동일한 중요도를 갖지 않기 때문에, 시스템 자원이 제한될 때 오리진은 덜 중요한 요청보다 더 중요한 요청을 우선하도록 설계되었습니다. 아래 표는 요청 범주, 식별 방식, 보호 방법을 설명합니다.
엔터 키를 누르거나 클릭하여 전체 크기 이미지 보기
급증할 수 있는 CDN 조회 트래픽과 달리 게시 트래픽은 예측 가능하므로, 경로 분리는 매우 효과적인 해결책입니다. 확장성 아키텍처 다이어그램에서 볼 수 있듯이, 오리진은 지연 시간과 장애에 민감한 오리진 쓰기를 보호하기 위해 별도의 EC2 게시 스택과 CDN 스택을 사용합니다. 또한 저장소 추상화 계층은 key-value (KV) 읽기 작업과 KV 쓰기 작업을 위한 별도 클러스터를 갖추고 있습니다. 마지막으로 저장소 계층 자체도 읽기(EVCache) 경로와 쓰기(Cassandra) 경로를 분리합니다. 이러한 포괄적인 경로 분리는 게시와 조회를 클라우드에서 독립적으로 확장할 수 있게 할 뿐 아니라, CDN 대상 트래픽 급증이 오리진 게시의 성능과 신뢰성에 영향을 주지 못하게 합니다.
Netflix의 규모를 고려하면, 특히 자동 확장이 불가능한 시스템 자원을 감안할 때 트래픽 폭주 상황에서 들어오는 요청을 관리하는 일은 어렵습니다. Netflix Live Origin은 기반 시스템에 스트레스가 가해질 때 우선순위 기반 속도 제한을 구현했습니다. 이 접근 방식은 사용자 영향이 더 큰 요청이 우선적으로 성공하도록 보장하며, 사용자 영향이 더 낮은 요청은 스트레스 상황에서 실패를 허용하여 스트리밍 인프라를 보호하고 나중에 재시도를 통해 성공할 수 있도록 합니다.
Netflix의 마이크로서비스 플랫폼 우선순위 속도 제한 기능을 활용해, 오리진은 저장소 플랫폼에 높은 부하가 걸리는 기간 동안 DVR 트래픽보다 라이브 에지 트래픽을 우선시합니다. 라이브 에지와 DVR 트래픽의 구분은 예측 가능한 세그먼트 템플릿을 기반으로 합니다. 이 템플릿은 데이터 저장소 접근 없이도 우선순위 속도 제한을 가능하게 하기 위해 오리진 노드 메모리에 추가로 캐시되며, 이는 특히 데이터 저장소에 높은 스트레스가 가해지는 시기에 유용합니다.
트래픽 급증을 완화하기 위해 우선순위 속도 제한과 함께 TTL 캐시 제어를 사용합니다. 낮은 우선순위 트래픽이 영향을 받을 때, 오리진은 max-age = 5s를 설정하고 HTTP 503 오류 코드를 반환하여 Open Connect가 속도를 늦추고 동일한 요청을 5초 동안 캐시하도록 지시합니다. 이 전략은 해당 5초 구간 내에서 오리진으로의 반복 요청을 방지함으로써 트래픽 급증을 효과적으로 완화합니다.
다음 다이어그램은 시뮬레이션된 트래픽으로 오리진 우선순위 속도 제한을 보여줍니다. nliveorigin_mp41 트래픽은 낮은 우선순위 트래픽이며 다른 높은 우선순위 트래픽과 혼합되어 있습니다. 첫 번째 행에서 첫 번째 다이어그램은 요청 RPS를, 두 번째 다이어그램은 요청 실패 비율을 보여줍니다. 두 번째 행에서 첫 번째 다이어그램은 데이터 저장소 자원 활용률을, 두 번째 다이어그램은 오리진 조회 P99 지연 시간을 보여줍니다. 결과는 높은 데이터 저장소 활용률에서 낮은 우선순위 트래픽(nliveorigin_mp41)만 영향을 받으며, 오리진 요청 지연 시간은 제어되고 있음을 분명히 보여줍니다.
엔터 키를 누르거나 클릭하여 전체 크기 이미지 보기
오리진 우선순위 속도 제한
게시 경로 분리와 우선순위 속도 제한은 DVR 트래픽 폭주로부터 라이브 오리진을 성공적으로 보호합니다. 그러나 존재하지 않는 세그먼트에 대한 요청이 만들어내는 트래픽 폭주는 추가적인 과제와 최적화 기회를 제시합니다.
라이브 오리진은 메타데이터를 event > stream rendition > segment 형태의 계층 구조로 구성하며, 세그먼트 게시 템플릿은 stream rendition 수준에서 유지됩니다. 이러한 계층적 구조 덕분에 오리진은 높은 캐시 가능성을 가진 event 및 stream rendition 수준 메타데이터를 활용하여 segment 수준 메타데이터에 대한 불필요한 질의를 피하면서 HTTP 404(not found)/410(Gone) 오류로 요청을 선제적으로 거부할 수 있습니다.
저장소 계층에서 메타데이터는 제어 평면 데이터 저장소 안에서 미디어 데이터와 분리되어 저장됩니다. 미디어 데이터 저장소와 달리 제어 평면 데이터 저장소는 캐시 불일치를 피하기 위해 분산 캐시를 사용하지 않습니다. 이벤트 및 rendition 수준 메타데이터는 라이브 오리진 인스턴스에서 메모리 내 캐싱을 사용할 경우 높은 캐시 적중률의 이점을 얻습니다. 존재하지 않는 세그먼트와 관련된 트래픽 폭주 동안 제어 평면 접근의 캐시 적중률은 쉽게 90%를 넘습니다.
메타데이터에 대한 메모리 내 캐싱 사용은 데이터 저장소에 스트레스를 주지 않으면서 라이브 오리진에서 404 폭주를 효과적으로 처리합니다. 이 메타데이터 캐싱은 저장소 시스템의 분산 미디어 캐시를 보완하여 트래픽 급증 보호를 위한 완전한 솔루션을 제공합니다.
최적화된 저장소 플랫폼 위에 구축된 Netflix Live Origin은 라이브 스트리밍을 위해 특별히 설계되었습니다. 이 시스템은 고급 미디어 및 세그먼트 게시 일정 인지 기능을 통합하고, 향상된 지능을 활용하여 스트리밍 품질을 높이고, 확장성을 최적화하며, Open Connect의 라이브 스트리밍 운영을 개선합니다.
수많은 팀과 뛰어난 동료들이 Netflix Live Origin에 기여했습니다. 라이브 오리진 프로젝트의 지지와 후원을 맡아준 Flavio Ribeiro에게 특별히 감사드립니다. 저장소 플랫폼을 함께한 Raj Ummadisetty, Prudhviraj Karumanchi에게도 감사드립니다. 저장소 수명주기 관리를 맡아준 Rosanna Lee, Hunter Ford, Thiago Pontes에게 감사드립니다. e2e 테스트 프레임워크를 지원한 Ameya Vasani, orchestrator integration을 담당한 Thomas Symborski, Open Connect integration을 담당한 James Schek, 플랫폼 우선순위 속도 제한을 담당한 Kevin Wang, 오리진 확장성 테스트를 지원한 Di Li, Nathan Hubbard에게도 감사드립니다.
