Netflix ejecuta 30.000+ jobs de Flink en múltiples regiones de AWS, la mayoría auto-generados por su plataforma Data Mesh. Mantener esos pipelines correctamente dimensionados exige autoscaling. Después de años ejecutando dos autoscalers separados en paralelo, Netflix aprendió que la fuente de métricas determina el modo de falla—los dos sistemas fallan en direcciones opuestas.

El primer autoscaler es casero, construido alrededor de 2019 en Mantis, la plataforma de streaming-job de Netflix. Funciona de afuera hacia adentro, consumiendo señales de nivel de cluster de Atlas, el sistema de telemetría de Netflix: CPU, red, lag de Kafka, tasa de entrada, tasa de consumo por job. Calcula el tiempo de catch-up a partir del lag, combina umbrales de CPU y red con historial de rendimiento, y usa regresión de tasa de entrada para decidir el escalado. Porque se ejecuta como un job Mantis independiente, las fallas de la plataforma Flink no lo afectan. Cada nodo Mantis maneja un fragmento de la flota Flink sin coordinación personalizada. En miles de pipelines, entregó ahorros de recursos del 25–45%.

La limitación es la granularidad de métricas. El autoscaler casero controla un botón: recuento total de TaskManager. Cada operador en un job escala junto. Funciona para pipelines de operador único moviendo registros entre tópicos de Kafka. Falla en DAGs con estado de múltiples operadores con branches, joins y terabytes de estado—los jobs que ejecutan los equipos de Ads, recomendaciones y live-events. Cada topología nueva requería lógica personalizada. No emergió ningún patrón general.

Peor: el sistema solo ve lo que muestran sus métricas. Un job completamente cargado podría reportar CPU normal, dejando ciego al autoscaler. Una migración de red cambió silenciosamente cómo Atlas contaba el tráfico. Algunas métricas subestimaban la carga. La brecha permaneció oculta hasta que la producción se rompió.

El autoscaler de la comunidad Apache Flink es el segundo sistema de Netflix. Funciona de adentro hacia afuera, razonando desde el job mismo. Su mecanismo: True Processing Rate (TPR). Para cada subtarea, Flink rastrea cuánto de cada segundo pasa trabajando versus bloqueado o inactivo. TPR divide el throughput observado por esa fracción ocupada para extrapolar capacidad en carga total. Un operador manejando 700 registros/seg mientras está ocupado el 70% del tiempo tiene un TPR de 1.000 registros/seg. Comenzando desde operadores de origen, el autoscaler recorre el DAG del job y usa el TPR de cada operador, ratios input/output y utilización objetivo para computar el paralelismo que cada vértice necesita—entonces ningún operador se convierte en el cuello de botella. Configuración por-job—ventanas de estabilización, umbrales, comportamientos de escalado—viaja con el job, no con la plataforma.

El trade-off: este autoscaler vive dentro del runtime de Flink. Los problemas de la plataforma Flink pueden afectarlo directamente de formas que un sistema externo no lo haría. El escalado es costoso de todas formas: Netflix toma un savepoint, detiene el job gracefully, y reinicia con el nuevo paralelismo. Para jobs con estado grande con terabytes de estado, ese ciclo toma varios minutos.

Netflix ejecuta ambos autoscalers en producción ahora. La migración hacia el autoscaler OSS está en marcha. La lección: los costos de mantenimiento de infraestructura personalizada se acumulan invisiblemente. El incidente de migración de red—donde las métricas de Atlas silenciosamente perdieron precisión—muestra cómo los autoscalers de observador externo acumulan dependencias ocultas en sistemas que no controlan.

Para equipos ejecutando pipelines de inferencia o workloads event-driven con gráficos de operador heterogéneos, la elección es la misma que enfrentó Netflix: señales externas gruesas escalan simplemente pero se limitan a control de botón único. Las métricas internas por-subtarea desbloquean precisión por-operador al costo de acoplamiento más estrecho con el runtime.