Netflix migra 30 mil jobs Flink para o autoscaler open source e corta custo em até 58%

A Netflix está migrando mais de 30 mil jobs de streaming, distribuídos em várias regiões da AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps →, para o Apache Flink Autoscaler open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) →. O motivo, segundo a empresa: o autoscaler interno que ela mantinha desde ~2019 escalava no nível do cluster, e isso deixou de fazer sentido para pipelines stateful complexos, onde diferentes operadores do mesmo job têm necessidades de processamento distintas.

O número que chama atenção no relato: um time reduziu em 58% o gasto anualizado com computação Flink, economizando cerca de US$ 1,1 milhão por ano. Não é um resultado global da migração, é o caso citado de uma equipe, mas ajuda a dimensionar por que a decisão foi tomada.

Por que o autoscaler antigo travou

A Netflix roda Apache Flink desde 2017 e construiu seu primeiro autoscaler por volta de 2019. Esse sistema rodava sobre o Mantis e consumia telemetria de nível de cluster vinda do Atlas: CPU, uso de rede, lag do Kafka, taxa de entrada e taxa de consumo. Com isso, ajustava o número total de TaskManagers e reduzia o consumo de recursos entre 25% e 45% ao longo de milhares de pipelines.

O problema estava na unidade de escala. Como o autoscaler raciocinava sobre o cluster inteiro, e não sobre operadores individuais, todos os operadores de um job compartilhavam a mesma decisão de scaling. Isso funciona mal para pipelines stateful com branches, joins e terabytes de estado, em que partes diferentes do dataflow processam volumes muito diferentes. Você acaba superprovisionando o job todo por causa de um único gargalo, ou o contrário.

Como o autoscaler open source pensa por operador

Em vez de olhar métricas de cluster, o Apache Flink Autoscaler usa métricas expostas pelo próprio job em execução para estimar a taxa real de processamento de cada operador, a partir do throughput e do busy time (tempo que o operador passa efetivamente ocupado). A partir daí, ele percorre o grafo do job e calcula a paralelização necessária para cada vértice separadamente.

A abordagem está descrita na FLIP-271, que trata justamente de autoscaling para jobs heterogêneos e do custo de reescalar aplicações stateful. Tecnicamente, ela se apoia em pesquisa do projeto DS2. Vasiliki Kalavri, pesquisadora de sistemas envolvida no trabalho, contou que o projeto começou explorando análise de caminho crítico antes de adotar a True Processing Rate como baseline mais simples.

It turned out that this very simple idea worked really well.

Vasiliki Kalavri, pesquisadora de sistemas

Essa ideia acabou incorporada ao trabalho de autoscaling do Flink.

O que a Netflix precisou adaptar

A Netflix não plugou o autoscaler direto via Flink Kubernetes Operator. Em vez disso, integrou-o ao seu control plane interno. Um serviço em Spring Boot usa workflows do Temporal para isolar as decisões de autoscaling de cada job individualmente.

No caminho, a engenharia precisou de várias mudanças que valem como aviso para quem for rodar isso em escala parecida:

• Modificou a coleta de métricas do JobManager para suportar jobs com até 3.000 subtasks;
• Adicionou filtragem de métricas no lado do servidor;
• Preservou subgrafos com conexões forward durante o scaling;
• Adicionou tratamento para backpressure de sink.

O ponto das conexões forward é sutil e já apareceu em discussões da comunidade Flink: mudar a paralelização atravessando uma conexão FORWARD pode exigir redistribuição de dados, então a implementação da Netflix mantém operadores conectados por forward juntos. Há ainda uma issue aberta, a FLINK-38538, sobre casos em que operadores ocupados podem ser afetados por decisões de scaling baseadas em razão de saída (output ratio).

Um detalhe de tuning que vale copiar

A Netflix opera com um alvo de utilização de 0,45, abaixo do padrão da comunidade Flink, que é 0,7. A escolha é deliberada: com um alvo mais conservador, o autoscaler reescala com menos agressividade jobs stateful grandes, evitando o custo alto de recuperar terabytes de estado a cada rescale.

Vale a comparação com autoscalers genéricos como o KEDA, que escalam workloads a partir de métricas ou eventos externos. O autoscaler do Flink faz algo diferente: raciocina sobre o grafo interno de dataflow e a capacidade de cada operador. São ferramentas para problemas distintos, e essa distinção importa na hora de escolher.

O que muda para quem constrói pipelines aqui

O ponto prático para o dev brasileiro é que nada disso é proprietário da Netflix. O autoscaler é parte do projeto Apache Flink; a FLIP-271 e a integração com o Flink Kubernetes Operator estão disponíveis para qualquer time. Quem já roda Flink em produção real-time (ingestão de eventos, ETL de streaming, feature stores para ML↳Machine learning39 conteúdosClassificador de Sentimentos – Azure MLData · abr 2019Inteligência Artificial e Machine Learning: O que você precisa saberAI · fev 2024Inteligência Artificial: seminário online da USP debate o futuro do aprendizado de máquinaGestão Dev & TI · jun 2021Ver tudo em AI →) pode adotar a mesma lógica de scaling por operador sem reconstruir control plane do zero.

A leitura que fica: o diferencial da Netflix aqui não foi inventar o autoscaler, foi a camada de integração e o tuning, o alvo de 0,45, o isolamento por job via Temporal, os ajustes de coleta de métricas para jobs enormes. Para times menores, o caminho mais direto é usar o autoscaler pelo Flink Kubernetes Operator e calibrar o alvo de utilização conforme o custo de estado dos seus jobs, começando conservador se houver pipelines stateful pesados.

O que ainda está em aberto: a própria Netflix diz que vai migrar os casos internos restantes e investigar a arquitetura de estado desagregado do Flink 2 para atacar o custo de recuperação de estado durante o rescale, um dos calcanhares de Aquiles de escalar jobs stateful. Quem depende de pipelines com muito estado deve acompanhar essa frente antes de assumir que o autoscaling resolve tudo sozinho.

Fonte: InfoQ