Programming/MSA

MicroService로 Netflix 비디오 처리 파이프라인 재구축 -1

armyost 2024. 2. 12. 22:13
728x90

원문링크 : https://netflixtechblog.com/rebuilding-netflix-video-processing-pipeline-with-microservices-4e5e6310e359

 

Rebuilding Netflix Video Processing Pipeline with Microservices

This is the first blog in a multi-part series on how Netflix rebuilt its video processing pipeline with microservices, so we can maintain…

netflixtechblog.com

 

Netflix가 어떻게 마이크로서비스로 비디오 처리 파이프라인을 재구축하여 빠른 혁신 속도를 유지하고 회원 스트리밍 및 스튜디오 운영을 위한 시스템을 지속적으로 개선할 수 있는지에 대한 여러 부분으로 구성된 시리즈를 연재할 생각입니다.

Netflix 비디오 처리 파이프라인은 2007년 스트리밍 서비스 출시와 함께 활성화되었습니다. 그 이후로 비디오 파이프라인은 상당한 개선과 폭넓은 확장을 거쳤습니다.

  • Standard-Definitions의 SDR(Standard Dynamic Range)을 시작으로 인코딩 파이프라인을 4K 및 HDR(High Dynamic Range)로 확장하여 프리미엄 서비스를 지원할 수 있었습니다.
  • 우리는 중앙 집중식 선형 인코딩에서 분산 Chunk 기반 인코딩으로 전환했습니다. 이러한 아키텍처 변화로 인해 처리 지연 시간이 크게 줄어들고 시스템 복원력이 향상되었습니다.
  • 수량에 제약이 있는 전용 인스턴스 사용에서 벗어나 마이크로서비스 자동 확장으로 인해 생성된 Netflix의 internal trough를 활용하여 Computing 탄력성과 리소스 활용 효율성이 크게 향상되었습니다.
  • 우리는 타이틀별, 샷별 최적화와 같은 인코딩 혁신을 출시하여 Netflix 회원들에게 상당한 QoE(경험 품질) 향상을 제공했습니다.
  • 스튜디오 콘텐츠 시스템과 통합함으로써 파이프라인을 통해 크리에이티브 측면의 풍부한 메타데이터를 활용하고 대화형 스토리텔링과 같은 더욱 매력적인 회원 경험을 만들 수 있었습니다.
  • 우리는 기존 스트리밍 사용 사례와 비교하여 대기 시간 및 탄력성 요구 사항이 다른 스튜디오/콘텐츠 개발 사용 사례를 제공하기 위해 파이프라인 지원을 확장했습니다.

지난 15년 간의 경험을 통해 스트리밍 서비스와 스튜디오 파트너를 혁신하고 지원할 수 있는 효율적이고 유연한 비디오 처리 파이프라인이 Netflix의 지속적인 성공에 매우 중요하다는 확신이 더욱 강화되었습니다. . 이를 위해 ET(Encoding Technologies)의 비디오 및 이미지 인코딩 팀은 차세대 마이크로서비스 기반 컴퓨팅 플랫폼 Cosmos에서 비디오 처리 파이프라인을 재구축하는 데 지난 몇 년을 보냈습니다.

 

From Reloaded to Cosmos

Reloaded

2014년부터 3세대 플랫폼 Reloaded에서 영상 처리 파이프라인을 개발 및 운영했습니다. Reloaded는 잘 설계되어 우수한 안정성, 확장성 및 합리적인 수준의 유연성을 제공했습니다. 이는 우리 팀이 개발한 수많은 인코딩 혁신의 기반이 되었습니다.

Reloaded를 설계할 때 우리는 스튜디오에서 받은 고품질 미디어 파일(메자닌이라고도 함)을 Netflix 스트리밍용 압축 자산으로 변환하는 단일 사용 사례에 중점을 두었습니다. Reloaded는 ET의 다양한 미디어 팀과 플랫폼 파트너 팀인 콘텐츠 인프라 및 솔루션(CIS)의 개발자가 동일한 코드 베이스에서 작업하여 모든 미디어 자산을 처리하는 단일 시스템을 구축하는 단일 모놀리식 시스템으로 만들어졌습니다. 수년에 걸쳐 시스템은 다양한 새로운 사용 사례를 지원하도록 확장되었습니다. 이로 인해 시스템 복잡성이 크게 증가했으며 Reloaded의 한계가 나타나기 시작했습니다.

  • 결합된 기능: Reloaded는 여러 작업자 모듈과 오케스트레이션 모듈로 구성되었습니다. 새로운 리로디드 모듈을 설정하고 오케스트레이션과 통합하려면 적지 않은 노력이 필요했고, 이로 인해 새로운 기능을 개발할 때 생성보다는 증강 쪽으로 편향되게 되었습니다. 예를 들어 Reloaded에서는 비디오 품질 계산이 비디오 인코더 모듈 내부에서 구현되었습니다. 이 구현에서는 다시 인코딩하지 않고 비디오 품질을 다시 계산하는 것이 매우 어려웠습니다.
  • 모놀리식 구조: 리로디드 모듈은 동일한 저장소에 함께 배치되는 경우가 많았기 때문에 코드 격리 규칙을 간과하기 쉬웠고 강력한 경계여야 하는 코드가 의도치 않게 재사용되는 경우가 꽤 있었습니다. 이러한 재사용으로 인해 긴밀한 결합이 발생하고 개발 속도가 감소했습니다. 모듈 간의 긴밀한 결합으로 인해 모든 모듈을 함께 배포해야 했습니다.
  • 긴 릴리스 주기: 공동 배포는 이 규모의 배포에서는 디버깅 및 롤백이 어려울 수 있으므로 의도하지 않은 생산 중단에 대한 두려움이 커졌다는 것을 의미합니다. 이로 인해 "릴리스 트레인"이 접근하게 되었습니다. 2주마다 모든 모듈의 "스냅샷"이 촬영되어 "릴리스 후보"로 승격되었습니다. 그런 다음 이 릴리스 후보는 가능한 한 넓은 표면적을 포괄하는 철저한 테스트를 거쳤습니다. 이 테스트 단계에는 약 2주가 걸렸습니다. 따라서 코드 변경 사항이 병합된 시기에 따라 프로덕션에 도달하는 데 2~4주가 걸릴 수 있습니다.
    시간이 지남에 따라 기능이 증가함에 따라 Reloaded의 새로운 기능 기여 비율은 떨어졌습니다. 건축학적 한계를 극복하는 데 필요한 대규모 작업으로 인해 몇 가지 유망한 아이디어가 포기되었습니다. 한때 우리에게 큰 도움이 되었던 플랫폼이 이제는 개발에 방해가 되고 있었습니다.

 

Cosmos

이에 대응하여 2018년 CIS팀과 ET팀은 차세대 플랫폼인 Cosmos 개발에 착수했습니다. 개발자들이 Reloaded에서 이미 누린 확장성과 안정성 외에도 Cosmos는 시스템 유연성과 기능 개발 속도를 크게 높이는 것을 목표로 했습니다. 이를 달성하기 위해 Cosmos는 워크플로우 중심, 미디어 중심 마이크로서비스를 위한 컴퓨팅 플랫폼으로 개발되었습니다.

마이크로서비스 아키텍처는 서비스 간의 강력한 분리를 제공합니다. 마이크로서비스별 워크플로 지원은 복잡한 미디어 워크플로 논리를 구현하는 부담을 덜어줍니다. 마지막으로 관련 추상화를 통해 미디어 알고리즘 개발자는 인프라 문제보다는 비디오 및 오디오 신호 조작에 집중할 수 있습니다. 코스모스가 제공하는 혜택의 전체 목록은 링크된 블로그에서 확인하실 수 있습니다.

 

Building the Video Processing Pipeline in Cosmos

Service Boundaries

마이크로서비스 아키텍처에서 시스템은 여러 개의 세분화된 서비스로 구성되며, 각 서비스는 단일 기능에 중점을 둡니다. 따라서 첫 번째(아마도 가장 중요한) 일은 경계를 식별하고 서비스를 정의하는 것입니다.

우리 파이프라인에서는 미디어 자산이 생성, 수집, 전달을 거쳐 분석 및 변환과 같은 여러 처리 단계를 거치게 됩니다. 우리는 이러한 처리 단계를 분석하여 "경계"를 식별하고 이를 여러 도메인으로 그룹화했으며, 이는 결국 우리가 엔지니어링한 마이크로서비스의 구성 요소가 되었습니다.

예를 들어 Reloaded에서 비디오 인코딩 모듈은 5단계를 번들로 묶습니다.

1. 입력 비디오를 작은 덩어리로 나눕니다.

2. 각 청크를 독립적으로 인코딩

3. 각 청크의 품질 점수(VMAF)를 계산합니다.

4. 인코딩된 모든 청크를 단일 인코딩된 비디오로 조립합니다.

5. 모든 청크의 품질 점수를 집계합니다.

시스템 관점에서 보면 조합된 인코딩된 비디오가 주요 관심사인 반면 특정 대기 시간 및 복원력 요구 사항을 충족하기 위해 내부 청크 및 별도의 청크 인코딩이 존재합니다. 또한 위에서 언급한 것처럼 비디오 품질 계산은 인코딩 서비스와 완전히 별개의 기능을 제공합니다.

따라서 Cosmos에서는 VES(비디오 인코딩 서비스)와 VQS(비디오 품질 서비스)라는 두 개의 독립적인 마이크로서비스를 만들었습니다. 각 마이크로서비스는 명확하고 분리된 기능을 제공합니다. 구현 세부 사항으로 청크 인코딩과 조립이 VES로 추상화되었습니다.

 

 

Video Services

위에서 설명한 접근 방식은 나머지 비디오 처리 파이프라인에 적용되어 기능과 서비스 경계를 ​​식별하여 다음과 같은 비디오 서비스²를 생성했습니다.

 

  • 영상 검사 서비스(VIS): 이 서비스는 메자닌을 입력으로 받아 다양한 검사를 수행합니다. 다운스트림 서비스를 위해 메자닌의 다양한 계층에서 메타데이터를 추출합니다. 또한 검사 서비스는 유효하지 않거나 예상치 못한 메타데이터가 관찰되면 문제에 플래그를 지정하고 업스트림 팀에 실행 가능한 피드백을 제공합니다.
  • CAS(복잡도 분석 서비스): 최적의 인코딩 레시피는 콘텐츠에 따라 크게 달라집니다. 이 서비스는 메자닌을 입력으로 받아 콘텐츠 복잡성을 이해하기 위한 분석을 수행합니다. 사전 인코딩을 위해서는 Video Encoding Service를, 품질 평가를 위해서는 Video Quality Service를 호출합니다. 결과는 재사용이 가능하도록 데이터베이스에 저장됩니다.
  • 래더 생성 서비스(LGS): 이 서비스는 특정 인코딩 제품군(H.264, AV1 등)에 대한 전체 비트 전송률 래더를 생성합니다. CAS에서 복잡성 데이터를 가져오고 최적화 알고리즘을 실행하여 인코딩 레시피를 생성합니다. CAS와 LGS는 이전에 기술 블로그에서 소개한 많은 혁신을 다루고 있습니다(타이틀별, 모바일 인코딩, 샷별, 최적화된 4K 인코딩 등). 래더 생성을 별도의 마이크로서비스(LGS)로 래핑하여 래더 최적화 알고리즘을 CAS에 있는 복잡성 분석 데이터의 생성 및 관리에서 분리합니다. 우리는 이를 통해 더 많은 실험의 자유를 누리고 더 빠른 혁신 속도를 얻을 수 있을 것으로 기대합니다.
  • 비디오 인코딩 서비스(VES): 이 서비스는 메자닌과 인코딩 레시피를 가져와 인코딩된 비디오를 생성합니다. 레시피에는 원하는 인코딩 형식과 출력 속성(해상도, 비트 전송률 등)이 포함됩니다. 또한 서비스는 사용 사례에 따라 대기 시간, 처리량 등을 미세 조정할 수 있는 옵션도 제공합니다.
  • VVS(비디오 검증 서비스): 이 서비스는 인코딩된 비디오와 인코딩에 대한 기대 목록을 가져옵니다. 이러한 기대에는 인코딩 레시피에 지정된 속성과 코덱 사양의 적합성 요구 사항이 포함됩니다. VVS는 인코딩된 비디오를 분석하고 표시된 기대치와 결과를 비교합니다. 발신자에게 경고하기 위해 응답에 불일치 사항이 표시됩니다.
  • VQS(비디오 품질 서비스): 이 서비스는 메자닌과 인코딩된 비디오를 입력으로 사용하고 인코딩된 비디오의 품질 점수(VMAF)를 계산합니다.

 

Service Orchestration

각 비디오 서비스는 전용 기능을 제공하며 함께 작동하여 필요한 비디오 자산을 생성합니다. 현재 Netflix 비디오 파이프라인의 두 가지 주요 사용 사례는 회원 스트리밍과 스튜디오 운영을 위한 자산을 생성하는 것입니다. 각 사용 사례에 대해 전용 워크플로 조정자를 만들었으므로 서비스 조정을 해당 비즈니스 요구 사항에 가장 잘 맞게 사용자 지정할 수 있습니다.

스트리밍 사용 사례의 경우 생성된 비디오는 Netflix 회원이 사용할 수 있도록 CDN(콘텐츠 전송 네트워크)에 배포됩니다. 이 비디오는 수백만 번 쉽게 시청할 수 있습니다. Streaming Workflow Orchestrator는 거의 모든 비디오 서비스를 활용하여 완벽한 회원 경험을 위한 스트림을 생성합니다. VIS를 활용하여 비준수 또는 품질이 낮은 메자닌을 감지 및 거부하고, 인코딩 레시피 최적화를 위해 LGS를 호출하고, VES를 사용하여 비디오를 인코딩하고, 분석 및 모니터링 목적을 위해 품질 데이터가 Netflix의 데이터 파이프라인에 추가로 공급되는 품질 측정을 위해 VQS를 호출합니다. 스트리밍 워크플로 오케스트레이터는 비디오 서비스 외에도 오디오 및 시간 제한 텍스트 서비스를 사용하여 오디오 및 텍스트 자산을 생성하고 패키징 서비스를 사용하여 스트리밍용 자산을 "컨테이너화"합니다.

스튜디오 사용 사례의 경우 비디오 자산의 예로는 마케팅 클립 및 일일 프로덕션 편집 프록시가 있습니다. 스튜디오 측의 요청은 일반적으로 지연 시간에 민감합니다. 예를 들어 제작팀의 누군가가 다음 날 촬영 계획을 결정하기 위해 비디오를 검토하기를 기다리고 있을 수 있습니다. 이 때문에 Studio Workflow Orchestrator는 빠른 처리를 위해 최적화하고 핵심 미디어 처리 서비스에 중점을 둡니다. 이때 Studio Workflow Orchestrator는 VIS를 호출하여 수집된 자산의 메타데이터를 추출하고 사전 정의된 레시피로 VES를 호출합니다. 회원 스트리밍과 비교할 때 스튜디오 운영에는 비디오 처리에 대한 다양하고 고유한 요구 사항이 있습니다. 따라서 Studio Workflow Orchestrator는 포렌식 워터마킹 및 타임코드/텍스트 번인과 같은 일부 인코딩 기능의 독점적인 사용자입니다.