Infraestructura
Senior¿Cuál es el tamaño de clúster y la política de autoescalado correctos para esta carga de trabajo?
El tamaño correcto de clúster no es un número que eliges una vez — es una política que defines según cómo se comporta realmente la carga de trabajo, y que revisas conforme ese comportamiento cambia.
"¿Qué tan grande debe ser mi clúster?" es la pregunta equivocada. La correcta es "¿cuál es la curva de utilización que realmente produce esta carga de trabajo, y qué política encaja con esa curva?" — un job batch con un pico horario marcado necesita una respuesta completamente distinta a un job de streaming en estado estable.
Define el piso según la carga en estado estable, no el pico
Tu mínimo de autoescalado debe cubrir la carga base con margen para variación normal — no el pico que ves ocasionalmente. Fijar el piso según la carga pico significa pagar capacidad que usas solo una fracción del tiempo; ese es exactamente el problema de costo del "tamaño de clúster fijo" que el autoescalado existe para resolver, solo que recreado con pasos extra.
Define el techo según una conversación real de costo, no "lo que sea necesario"
Un máximo de autoescalado sin límite protege la disponibilidad pero elimina cualquier techo de costo — una consulta descontrolada, una tormenta de reintentos o un pico de tráfico inesperado pueden escalar un clúster (y su factura) mucho más allá de lo previsto. Define el máximo desde un número explícito de "cuál es el peor caso que estamos dispuestos a pagar", no solo desde la capacidad técnica.
Ajusta la sensibilidad de escalado a la forma de tu job
Una carga batch con un pico marcado y predecible (un job de ETL por hora, digamos) se beneficia de un escalado hacia arriba agresivo — es mejor sobreaprovisionar brevemente que dejar que el job haga cola detrás de un escalado lento. Un job de streaming en estado estable se beneficia de lo contrario: un escalado hacia arriba más lento y conservador evita el "thrashing" (escalar hacia arriba y de inmediato hacia abajo) ante la variación normal minuto a minuto, que en sí misma tiene un costo de overhead de aprovisionamiento/desaprovisionamiento.
El número que realmente debería guiar esta decisión: la utilización promedio de CPU/memoria entre executors durante corridas reales, no durante una prueba de carga sintética. La regla de número de instancias de opti-pipe compara el número de executors configurado contra la utilización realmente observada en tu event log, y se vuelve a activar con un número ajustado si una carga posterior muestra que la utilización cambió desde la última vez que aprobaste un cambio — no asume que la forma de tu carga de trabajo es más estática de lo que debería.
Mira cómo se ve esto en tu propio pipeline.
Sube un event log real de Spark, un run_results.json de dbt, o una exportación de métricas de Flink, y recibe recomendaciones concretas para aprobar — no otra regla general más.