Prime Video: de microsserviços serverless a monólito (custo 90% menor)

01 · CONTEXTO

Uma ferramenta que vigia cada stream

O Prime Video oferece milhares de streams ao vivo e montou uma ferramenta para monitorar cada stream assistido pelos clientes. Ela identifica automaticamente problemas de qualidade perceptual, como corrupção de blocos ou falta de sincronia entre áudio e vídeo, e dispara um processo de correção.

A equipe de análise de qualidade já tinha uma ferramenta de inspeção de áudio e vídeo, mas ela nunca foi desenhada para alta escala: a meta era monitorar milhares de streams simultâneos. Ao incluir mais streams, a equipe viu que rodar a infraestrutura em alta escala era muito caro e que havia gargalos que impediam chegar a esse número. O relato é de Marcin Kolny, publicado em 22 de março de 2023.

O serviço tem três peças: um conversor de mídia, os detectores de defeitos e a orquestração que controla o fluxo.

02 · A VERSÃO SERVERLESS

Rápida de construir, cara de escalar

A primeira versão foi um sistema distribuído com componentes serverless, orquestrados pelo AWS Step Functions e com detectores em AWS Lambda. Segundo a equipe, foi uma boa escolha para construir o serviço rapidamente. Na prática, o modo como alguns componentes foram usados levou a um limite rígido de escala em cerca de 5% da carga esperada.

1. O conversor de mídia recebe o stream e o transforma em quadros ou buffers de áudio descriptografados que seguem para os detectores.

2. O conversor envia as imagens, temporariamente, a um armazenamento de objetos.

3. Cada detector é um microsserviço separado: baixa as imagens e as processa em paralelo com Lambda. O grande número de chamadas ao armazenamento era caro.

4. A orquestração fazia várias transições de estado a cada segundo de stream, por isso atingiu limites da conta, e o Step Functions cobra por transição.

5. Quando um detector acha um defeito, envia uma notificação em tempo real.

Os dois pontos de dor eram a orquestração e a passagem de dados entre componentes.

Ao ler um diagrama de caixas e setas, vale perguntar o que cada seta custa.

03 · O MONÓLITO

Tudo em um único processo

A equipe primeiro considerou corrigir os problemas separadamente, fez experimentos e decidiu reestruturar a infraestrutura. Percebeu que a abordagem distribuída não trazia muitos benefícios neste caso e juntou todos os componentes em um único processo. A transferência de dados passou a ser em memória, o que eliminou o armazenamento de objetos como intermediário e simplificou a orquestração.

1. Conversor, detectores e orquestração passam a rodar dentro do mesmo processo.

2. Os quadros vão do conversor aos detectores pela memória do processo, sem armazenamento intermediário de objetos.

3. A orquestração passa a controlar os componentes dentro de uma só instância, com lógica mais simples.

4. Os componentes são os mesmos do desenho anterior, e por isso a equipe reaproveitou muito código e migrou rápido.

5. Os detectores continuam enviando notificações quando acham defeitos.

04 · O PREÇO DA ESCOLHA

Escalar na vertical e clonar o serviço

O monólito trouxe uma limitação: como todos os detectores rodam na mesma instância, eles só escalam verticalmente. A equipe adiciona detectores com frequência e já excedeu a capacidade de uma única instância.

A saída foi clonar o serviço várias vezes, cada cópia com um subconjunto de detectores, e criar uma camada leve de orquestração para distribuir as requisições dos clientes.

1. As requisições dos clientes chegam a uma camada leve de orquestração, que as distribui.

2. Cada cópia do serviço é parametrizada com um subconjunto diferente de detectores.

3. Os detectores de uma mesma instância só escalam na vertical; a saída foi clonar o serviço.

4. Os detectores de cada cópia enviam notificações ao achar defeitos.

Outra decisão que o post descreve como pouco óbvia: a equipe replicou o processo caro de conversão de mídia e o colocou perto dos detectores. Converter uma vez e guardar o resultado em cache poderia parecer mais barato, mas ela não o achou custo-efetivo.

05 · RESULTADOS E LIÇÕES

O que mudou e o que levar para a entrevista

Segundo o post, mover o serviço para um monólito reduziu o custo de infraestrutura em mais de 90% e aumentou a capacidade de escala. Hoje o serviço trata milhares de streams e ainda tem capacidade para crescer. Rodar em Amazon EC2 e Amazon ECS também permitiu usar os planos de economia de computação do EC2.

As mudanças permitem monitorar todos os streams vistos pelos clientes, e não só os de maior audiência.

Em entrevista, antes de dividir um sistema em serviços, pergunte onde estarão as setas entre os componentes e o que cada uma custa em preço, em limite e em dados movidos. Se o ponto de escala e de custo está justamente na comunicação entre as peças, juntar essas peças pode ser a resposta; se as peças têm cargas muito diferentes, a divisão continua fazendo sentido.