Netflix의 Cosmos Platform에 대해

원문링크

https://netflixtechblog.com/the-netflix-cosmos-platform-35c14d9351ad

The Netflix Cosmos Platform

 

Cosmos 소개

Cosmos는 마이크로서비스의 장점과 비동기식 워크플로우 및 서버리스 기능을 결합한 컴퓨팅 플랫폼입니다. 그 장점은 몇 분에서 몇 년까지 지속되는 복잡한 계층적 워크플로우를 통해 조정되는 리소스 집약적 알고리즘을 포함하는 애플리케이션입니다. 한 번에 수십만 개의 CPU를 사용하는 높은 처리량 서비스와 인간이 계산 결과를 기다리는 대기 시간에 민감한 워크로드를 모두 지원합니다.

 

Cosmos 탄생 배경

Netflix의 미디어 클라우드 엔지니어링 및 인코딩 기술 팀은 파트너와 스튜디오에서 수신되는 미디어 파일을 처리하여 모든 디바이스에서 재생할 수 있도록 하는 시스템을 공동으로 운영합니다. 이 시스템의 1세대는 2007년 스트리밍 출시와 함께 출시되었습니다. 2세대는 규모를 추가했지만 작동이 매우 어려웠습니다. Reloaded 라고 불리는 3세대는 약 7년 동안 온라인에 있었으며 안정적이고 대규모 확장이 가능 하다는 것이 입증되었습니다 .

 

Reloaded가 설계되었을 때 우리는 제한된 컴퓨팅 클러스터를 운영하는 소규모 개발자 팀이었고 비디오/오디오 처리 파이프라인이라는 하나의 사용 사례에 집중했습니다. 시간이 지남에 따라 개발자 수는 3배 이상 증가했고 사용 사례의 폭과 깊이도 확대되었으며 규모도 10배 이상 증가했습니다. 모놀리식 아키텍처로 인해 새로운 기능 제공이 크게 느려졌습니다. 우리는 더 이상 모든 사람이 새로운 기능을 구축하고 배포하는 데 필요한 전문 지식을 보유할 것이라고 기대할 수 없습니다. 인프라 코드가 애플리케이션 코드와 모두 뒤섞여 있기 때문에 프로덕션 문제를 처리하는 것은 모든 개발자에게 세금을 부과하는 값비싼 일이 되었습니다. 우리가 소규모 팀이었을 때 우리에게 큰 도움이 되었던 중앙 집중식 데이터 모델이 문제가 되었습니다.

우리의 대응은 워크플로우 중심, 미디어 중심 마이크로서비스를 위한 플랫폼인 Cosmos를 만드는 것이었습니다. 첫 번째 목표는 다음을 제공하면서 현재 기능을 유지하는 것이었습니다.

• 관찰 가능성 — 내장된 로깅, 추적, 모니터링, 경고 및 오류 분류를 통해.
• 모듈성 — 서비스를 구조화하고 컴파일 타임 및 런타임 모듈성을 모두 활성화하기 위한 독보적인 프레임워크입니다.
• 생산성 — 특수 테스트 실행기, 코드 생성기 및 명령줄 인터페이스를 포함한 로컬 개발 도구입니다.
• 전달 — 파이프라인, 지속적 통합 작업 및 엔드투엔드 테스트로 구성된 완전 관리형 지속적 전달 시스템입니다. 끌어오기 요청을 병합하면 수동 개입 없이 프로덕션 단계로 넘어갑니다.

그 동안 우리는 확장성, 안정성, 보안 및 기타 시스템 품질도 개선했습니다.

 

Cosmos 개요

Cosmos 서비스는 마이크로서비스는 아니지만 유사점이 있습니다.일반적인 마이크로서비스는 요청 로드에 따라 자동 확장되는 상태 비저장 비즈니스 로직을 갖춘 API입니다. API는 애플리케이션 데이터와 바이너리 종속성을 다른 시스템과 분리하는 동시에 동료와의 강력한 계약을 제공합니다.

 

Cosmos 서비스는 마이크로서비스의 강력한 계약과 분리된 데이터/종속성을 유지하지만 다단계 워크플로와 계산 집약적인 비동기 서버리스 기능을 추가합니다. 일반적인 Cosmos 서비스의 아래 다이어그램에서 클라이언트는 비디오 인코더 서비스 API 계층에 요청을 보냅니다. 일련의 규칙은 워크플로 단계를 조정하고 서버리스 기능 세트는 도메인별 알고리즘을 강화합니다. 함수는 Docker 이미지로 패키징되며 자체 미디어별 바이너리 종속성을 가져옵니다(예: debian 패키지). 대기열 크기에 따라 확장되며 수만 개의 서로 다른 컨테이너에서 실행될 수 있습니다. 요청을 완료하는 데 몇 시간 또는 며칠이 걸릴 수 있습니다.

일반적인 코스모스 서비스

 

우려의 분리

코스모스에는 두 개의 분리 축이 있습니다. 한편으로 논리는 API, 워크플로 및 서버리스 기능으로 구분됩니다. 반면에 로직은 애플리케이션과 플랫폼 간에 분리됩니다. 플랫폼 API는 분산 컴퓨팅의 세부 사항을 숨기면서 애플리케이션 개발자에게 미디어별 추상화를 제공합니다. 예를 들어, 비디오 인코딩 서비스는 API, 워크플로, 기능 등 규모에 구애받지 않는 구성 요소로 구축됩니다. 그들은 자신이 실행하는 규모에 대한 특별한 지식이 없습니다. 이러한 도메인별, 규모에 구애받지 않는 구성 요소는 작업 배포의 세부 사항을 처리하는 세 가지 규모 인식 Cosmos 하위 시스템 위에 구축됩니다 .

• 외부 요청을 내부 비즈니스 모델에 매핑하는 API 계층인 Optimus입니다.
• 비즈니스 규칙 모델링을 위한 워크플로우 레이어인 Plato .
• 상태 비저장 및 계산 집약적 기능 실행을 요구하는 서버리스 레이어인 Stratum 입니다 .

하위 시스템은 모두 대규모, 저지연 우선 순위 큐 시스템인 Timestone을 통해 비동기적으로 서로 통신합니다. 각 하위 시스템은 서비스의 다양한 문제를 해결하며 특별히 구축된 관리형 Continuous Delivery 프로세스를 통해 독립적으로 배포될 수 있습니다. 이러한 관심사의 분리를 통해 Cosmos 서비스를 더 쉽게 작성, 테스트 및 운영할 수 있습니다.

 

코스모스 서비스 요청

Cosmos 서비스 요청의 추적 그래프

 

위 사진은 관측 포털인 Nirvana의 스크린샷입니다. Cosmos(이 경우 비디오 인코더 서비스)의 일반적인 서비스 요청을 보여줍니다.

1. 비디오 소스와 레시피를 포함하는 인코딩을 위한 하나의 API 호출이 있습니다.
2. 비디오는 31개의 청크로 분할되며 31개의 인코딩 기능이 병렬로 실행됩니다.
3. 어셈블 함수는 한 번 호출됩니다.
4. 인덱스 함수는 한 번 호출됩니다.
5. 8분 후에 워크플로가 완료됩니다.

 

서비스 계층화

Cosmos는 서비스의 분해 및 계층화를 지원합니다. 결과적인 모듈식 아키텍처를 통해 팀은 전문 분야에 집중하고 API 및 릴리스 주기를 제어할 수 있습니다.

예를 들어 위에서 언급한 비디오 서비스는 장치에서 재생할 수 있는 스트림을 생성하는 데 사용되는 많은 서비스 중 하나일 뿐입니다. 검사, 오디오, 텍스트 및 포장도 포함하는 이러한 서비스는 더 높은 수준의 서비스를 사용하여 조정됩니다. 이들 중 가장 크고 가장 복잡한 것은 스튜디오에서 소스를 가져와 Netflix 서비스에서 재생할 수 있도록 만드는 역할을 하는 Tapas입니다. 또 다른 고급 서비스로는 마케팅 클립이나 일일 제작 편집 프록시와 같은 스튜디오 운영에 사용되는 Sagan이 있습니다.

Cosmos 서비스 계층화

 

프로덕션 스튜디오에서 새 타이틀이 도착하면 검사 수행, 비디오 인코딩(다중 해상도, 품질 및 비디오 코덱), 오디오 인코딩(다중 품질 및 코덱), 자막 생성(다양한 언어) 요청을 조정하는 타파스 워크플로가 트리거됩니다. , 결과 출력(다중 플레이어 형식)을 패키징합니다. 따라서 Tapas에 대한 단일 요청으로 인해 다른 Cosmos 서비스에 대한 수백 건의 요청과 수천 건의 Stratum 함수 호출이 발생할 수 있습니다.

아래 추적은 최상위 서비스의 요청이 어떻게 하위 수준 서비스로 흘러들어 다양한 작업을 수행할 수 있는지에 대한 예를 보여줍니다. 이 경우 8개의 Cosmos 서비스와 9개의 Stratum 기능이 포함된 수백 가지 작업으로 요청을 완료하는 데 24분이 걸렸습니다.

여러 계층을 통한 서비스 요청 추적 그래프

 

Workflow Rules

아니면 작업 흐름 규칙 이라고 해야 할까요 ? Plato는 서비스 개발자가 도메인 논리를 정의하고 상태 비저장 기능/서비스를 조율할 수 있는 프레임워크를 제공하여 Cosmos의 모든 것을 하나로 묶는 접착제입니다. Optimus API 계층에는 워크플로를 호출하고 해당 상태를 검사하는 기능이 내장되어 있습니다. Stratum 서버리스 계층은 강력한 유형의 RPC 클라이언트를 생성하여 서버리스 기능을 쉽고 직관적으로 호출할 수 있도록 합니다.

Plato는 알고리즘의 비동기식 및 계산 집약적 특성을 활용하는 순방향 연결 규칙 엔진입니다. Netflix의 Conductor 와 같은 절차적 워크플로 엔진과 달리 Plato를 사용하면 "항상 켜져 있는" 워크플로를 쉽게 만들 수 있습니다. 예를 들어, 더 나은 인코딩 알고리즘을 개발함에 따라 규칙 기반 워크플로는 새로운 워크플로를 시작하고 관리할 필요 없이 기존 비디오 업데이트를 자동으로 관리합니다. 또한 모든 워크플로는 다른 워크플로를 호출할 수 있으므로 위에서 언급한 서비스 계층화를 가능하게 합니다.

Plato는 다중 테넌트 시스템( Apache Karaf를 사용하여 구현됨 )으로, 워크플로 운영에 따른 운영 부담을 크게 줄여줍니다. 사용자는 자신의 소스 코드 저장소에서 규칙을 작성하고 테스트한 다음 컴파일된 코드를 Plato 서버에 업로드하여 워크플로를 배포합니다.

개발자는 Groovy를 기반으로 구축된 도메인별 언어인 Emirax로 작성된 일련의 규칙으로 워크플로를 지정합니다. 각 규칙에는 4개의 섹션이 있습니다.

• match: 이 규칙이 트리거되기 위해 충족되어야 하는 조건을 지정합니다.
• action: 이 규칙이 트리거될 때 실행될 코드를 지정합니다. 여기에서 Stratum 함수를 호출하여 요청을 처리합니다.
• response: 액션 코드가 성공적으로 완료되었을 때 실행될 코드를 지정합니다.
• error: 오류가 발생했을 때 실행할 코드를 지정합니다.

이러한 각 섹션에서는 일반적으로 먼저 워크플로 상태의 변경 사항을 기록한 다음 Stratum 함수를 실행하거나 실행 결과를 반환하는 등 워크플로를 앞으로 이동하는 단계를 수행합니다.

 

지연 시간에 민감한 애플리케이션

Sagan과 같은 Cosmos 서비스는 사용자를 대상으로 하기 때문에 대기 시간에 민감합니다. 예를 들어, 소셜 미디어 게시물을 작업 중인 아티스트는 최신 Money Heist 시즌의 비디오를 클립할 때 오랜 시간을 기다리고 싶지 않습니다 . Stratum의 경우 대기 시간은 작업을 수행하는 시간 과 컴퓨팅 리소스를 얻는 데 걸리는 시간 의 함수입니다 . 작업량이 매우 많은 경우(종종 그런 경우) " 리소스를 확보하는 데 걸리는 시간 " 구성 요소가 중요한 요소가 됩니다. 예를 들어, 일반적으로 쇼핑할 때 구입하는 것 중 하나가 화장지라고 가정해 보겠습니다. 일반적으로 장바구니에 물건을 넣고 계산대를 통과하는 데 문제가 없으며 전체 과정에 30분이 소요됩니다.

자원 부족

 

그러던 어느 날 나쁜 바이러스 문제가 발생하고 모두가 동시에 화장지가 더 필요하다고 결정합니다. 전체 수요가 사용 가능한 용량을 초과하므로 화장지 대기 시간이 이제 30분에서 2주로 늘어 납니다 . Cosmos 애플리케이션(특히 Stratum 기능)은 수요가 급증하고 예측할 수 없는 상황에서 이와 동일한 문제를 안고 있습니다. Stratum은 다음과 같은 몇 가지 방법으로 함수 실행 대기 시간을 관리합니다.

1. Resource pools. 최종 사용자는 자신의 비즈니스 사용 사례를 위해 Stratum 컴퓨팅 리소스를 예약할 수 있으며, 리소스 풀은 사용자 그룹이 리소스를 공유할 수 있도록 계층적입니다.
2. Warm capacity. 최종 사용자는 Stratum의 시작 지연 시간을 줄이기 위해 수요에 앞서 컴퓨팅 리소스(예: 컨테이너)를 요청할 수 있습니다.
3. Micro-batches. Stratum은 또한 시작 대기 시간을 줄이기 위해 Apache Spark와 같은 플랫폼에서 발견되는 트릭인 마이크로 배치를 사용합니다. 아이디어는 많은 함수 호출에 시작 비용을 분산시키는 것입니다. 함수를 10,000번 호출하면 10,000개의 컨테이너에서 각각 한 번씩 실행되거나 1000개의 컨테이너에서 각각 10번 실행될 수 있습니다.
4. Priority. 낮은 대기 시간에 대한 요구와 비용의 균형을 맞출 때 Cosmos 서비스는 일반적으로 중간 위치에 위치합니다. 즉, 일반적인 버스트를 처리하기에 충분한 리소스가 있지만 가장 짧은 대기 시간으로 가장 큰 버스트를 처리하기에는 충분하지 않습니다. 작업 우선 순위를 지정함으로써 애플리케이션은 리소스가 부족한 경우에도 가장 중요한 작업이 짧은 대기 시간으로 처리되도록 할 수 있습니다. Cosmos 서비스 소유자는 최종 사용자가 우선 순위를 설정하도록 허용하거나 API 계층 또는 워크플로에서 직접 설정할 수 있습니다.

 

처리량에 민감한 애플리케이션

Tapas와 같은 서비스는 많은 양의 컴퓨팅 리소스(예: 하루에 수백만 시간의 CPU 시간)를 소비하고 개별 작업을 완료하는 데 걸리는 시간보다는 몇 시간 또는 며칠 동안 작업을 완료하는 데 더 관심이 있기 때문에 처리량에 민감합니다. . 즉, 서비스 수준 목표(SLO)는 초당 작업 이 아닌 일일 작업 과 작업당 비용 으로 측정됩니다 .

처리량에 민감한 워크로드의 경우 가장 중요한 SLO는 Stratum 서버리스 계층에서 제공되는 SLO입니다. Titus 컨테이너 플랫폼 위에 구축된 Stratum을 사용하면 처리량에 민감한 워크로드가 유연한 리소스 예약을 통해 "기회적" 컴퓨팅 리소스를 사용할 수 있습니다. 예를 들어, 실행을 위해 최대 1시간까지 기다릴 수 있는 경우 서버리스 함수 호출 비용이 더 낮을 수 있습니다.

 

마이크로서비스 + 워크플로 + 서버리스

우리는 " 서버리스 기능을 조율하는 워크플로를 트리거하는 마이크로서비스 " 의 프로그래밍 모델이 강력한 패러다임이라는 것을 발견했습니다. 대부분의 사용 사례에서 잘 작동하지만 일부 애플리케이션은 추가된 복잡성으로 인해 이점을 누릴 가치가 없을 정도로 단순합니다.