Netflix executa 30.000+ jobs Flink em múltiplas regiões AWS, a maioria auto-gerada pela plataforma Data Mesh. Manter esses pipelines corretamente dimensionados exige autoscaling. Após anos executando dois autoscalers separados em paralelo, Netflix aprendeu que a fonte de métricas determina o modo de falha—os dois sistemas falham em direções opostas.

O primeiro autoscaler é caseiro, construído por volta de 2019 em Mantis, a plataforma de streaming-job da Netflix. Funciona de fora para dentro, consumindo sinais em nível de cluster do Atlas, o sistema de telemetria da Netflix: CPU, rede, lag Kafka, taxa de entrada, taxa de consumo por job. Calcula o tempo de catch-up a partir do lag, combina limites de CPU e rede com histórico de performance, e usa regressão de taxa de entrada para decidir scaling. Porque executa como um job Mantis independente, falhas da plataforma Flink não o afetam. Cada nó Mantis manipula um fragmento da frota Flink sem coordenação customizada. Em milhares de pipelines, entregou 25–45% de economia de recursos.

A limitação é a granularidade das métricas. O autoscaler caseiro controla um botão: contagem total de TaskManager. Cada operador em um job escala junto. Funciona para pipelines de operador único movendo records entre tópicos Kafka. Falha em DAGs stateful de múltiplos operadores com branches, joins e terabytes de estado—os jobs que os times de Ads, recomendações e live-events executam. Cada nova topologia requeria lógica customizada. Nenhum padrão geral emergiu.

Pior: o sistema apenas vê o que suas métricas mostram. Um job totalmente carregado pode reportar CPU normal, deixando o autoscaler cego. Uma migração de rede silenciosamente mudou como o Atlas contava tráfego. Algumas métricas subestimavam carga. A lacuna permaneceu oculta até a produção quebrar.

O autoscaler da comunidade Apache Flink é o segundo sistema da Netflix. Funciona de dentro para fora, raciocinando a partir do próprio job. Seu mecanismo: True Processing Rate (TPR). Para cada subtask, Flink rastreia quanto de cada segundo gasta trabalhando versus bloqueado ou inativo. TPR divide a taxa de transferência observada pela fração ocupada para extrapolar capacidade em carga total. Um operador manipulando 700 records/sec enquanto ocupado 70% do tempo tem um TPR de 1.000 records/sec. Começando dos operadores de origem, o autoscaler percorre o DAG do job e usa o TPR de cada operador, razões input/output e utilização alvo para computar o paralelismo que cada vértice precisa—então nenhum operador se torna o gargalo. Configuração por-job—janelas de estabilização, limiares, comportamentos de scaling—viaja com o job, não com a plataforma.

O trade-off: este autoscaler vive dentro do runtime Flink. Problemas da plataforma Flink podem afetá-lo diretamente de formas que um sistema externo não afetaria. Scaling é caro independentemente: Netflix tira um savepoint, para o job graciosamente, e reinicia no novo paralelismo. Para jobs stateful grandes com terabytes de estado, esse ciclo leva vários minutos.

Netflix executa ambos autoscalers em produção agora. Migração em direção ao autoscaler OSS está em andamento. A lição: custos de manutenção de infraestrutura customizada se acumulam invisívelmente. O incidente de migração de rede—onde métricas Atlas silenciosamente perderam precisão—mostra como autoscalers de observador externo acumulam dependências ocultas em sistemas que não controlam.

Para times executando pipelines de inferência ou workloads event-driven com gráficos de operador heterogêneos, a escolha é a mesma que Netflix enfrentou: sinais externos grosseiros escalam simplesmente mas limitam em controle de botão único. Métricas internas por-subtask desbloqueiam precisão por-operador ao custo de acoplamento mais apertado com o runtime.