A Netflix informou que está migrando para o Apache Flink Autoscaler open source em mais de 30 mil jobs de streaming distribuídos por várias regiões da AWS. Uma equipe interna reduziu o gasto anual com Flink compute em 58%, cerca de US$ 1,1 milhão por ano.
- Netflix migra para o Apache Flink Autoscaler em mais de 30 mil jobs.
- Redução de 58% no custo anual de Flink compute de uma equipe.
- Autoscaler por operador substitui a abordagem por cluster.
- FLIP-271 propõe autoscaling para jobs heterogêneos e stateful.
- Alvo de utilização de 0.45, abaixo do padrão da comunidade.
- Flink 2 com estado desagregado é aposta para reduzir custo de recovery.
Por que a netflix abandonou a escala por cluster
A Netflix roda Apache Flink desde 2017 e construiu seu primeiro autoscaler por volta de 2019. O sistema antigo, baseado em Mantis, consumia telemetria do cluster via Atlas, como CPU, utilização de rede, lag de Kafka, taxa de entrada e taxa de consumo.
Ele ajustava o número total de TaskManagers e reduzia o uso de recursos entre 25% e 45% em milhares de pipelines. O problema era a unidade de escala. Como o autoscaler raciocinava sobre o cluster e não sobre operadores individuais, todos os operadores de um job compartilhavam a mesma decisão de escala.
Isso se tornou inadequado para pipelines stateful com branches, joins e terabytes de estado, onde partes diferentes do dataflow têm requisitos diferentes. Por isso, a Netflix passou a avaliar o autoscaler open source do Flink.
Como o autoscaler do flink funciona
O Apache Flink Autoscaler usa métricas expostas pelo job em execução para estimar a taxa real de processamento de cada operador. Ele calcula a taxa a partir de throughput e busy time e depois percorre o grafo do job para determinar o paralelismo necessário por vértice.
# publicidade
Essa abordagem é descrita no FLIP-271, que aborda autoscaling para jobs heterogêneos e o custo de rescaling em aplicações stateful. A técnica também se baseia no projeto DS2.
Vasiliki Kalavri, pesquisadora envolvida no trabalho, disse que o projeto explorou inicialmente análise de caminho crítico antes de adotar o True Processing Rate como baseline. Segundo ela, a ideia simples funcionou muito bem e depois se tornou parte do trabalho de autoscaling do Flink.
Como a Netflix integrou o autoscaler no control plane
A Netflix integrou o autoscaler ao seu control plane interno, sem usar diretamente o Flink Kubernetes Operator. Um serviço Spring Boot usa Temporal workflows para isolar as decisões de autoscaling por job.
A empresa também modificou a coleta de métricas do JobManager para suportar jobs com até 3 mil subtasks. Além disso, adicionou filtragem de métricas no lado do servidor, preservou subgrafos conectados forward durante o scaling e tratou o backpressure de sinks.
O problema de forward connections também apareceu nas discussões de desenvolvedores do Apache Flink. Alterar paralelismo em uma conexão FORWARD pode exigir redistribuição, enquanto a implementação da Netflix mantém os operadores conectados forward juntos.
Há ainda uma issue aberta, FLINK-38538, que destaca casos onde operadores ocupados podem ser afetados por decisões de scaling baseadas em output ratio.
Diferença para autoscalers como keda
Autoscalers genéricos como KEDA escalam workloads a partir de métricas ou eventos externos. Já o autoscaler do Flink raciocina sobre o grafo interno do dataflow e a capacidade dos operadores.
A Netflix usa atualmente um alvo de utilização de 0.45, abaixo do padrão da comunidade Flink de 0.7, para reduzir rescaling agressivo em jobs stateful grandes.
| Critério | Autoscaler antigo (cluster) | Apache Flink Autoscaler |
|---|---|---|
| Unidade de escala | Cluster/TaskManagers | Operadores individuais |
| Métricas usadas | Telemetria do cluster (CPU, Kafka lag) | Throughput e busy time por operador |
| Adequação | Pipelines simples | Pipelines stateful e heterogêneos |
| Redução de recursos | 25% a 45% | 58% em um caso (US$ 1,1 mi/ano) |
| Integração | Mantis e Atlas | Control plane interno com Temporal |
| Alvo de utilização | Não informado | 0.45 vs 0.7 da comunidade |
Arraste para o lado para ver toda a tabela.
A empresa planeja migrar os casos de uso restantes de autoscaling interno para a implementação open source. Também está investigando a arquitetura de estado desagregado do Flink 2 para reduzir o custo de recuperação de estado durante rescaling.
Fonte: Infoq
