¿Cómo reduzco el costo de mi clúster de Flink sin romper los checkpoints?

La factura de un clúster de Flink no se mueve como la de un job batch: pagas por TaskManagers que están activos haya o no backpressure, y por checkpoints que se disparan por temporizador sin importar cuánto haya cambiado en realidad. Eso hace que esto sea menos sobre un job malo y más sobre ajustes que nadie ha revisado desde el lanzamiento.

1. El intervalo de checkpoint es la palanca de costo que nadie revisa

Cada checkpoint implica un pase completo por el state backend — con RocksDB, eso es I/O de disco más, en un despliegue en la nube, un lote de solicitudes PUT al almacenamiento de objetos que aloja state.checkpoints.dir. Un intervalo configurado de forma conservadora y corta durante el rollout inicial, cuando nadie quería arriesgar el progreso de un job aún no probado, sigue pagando ese costo indefinidamente incluso meses después de que el job esté estable. Ampliar execution.checkpointing.interval reduce ese costo recurrente directamente — el trade-off es más datos que reprocesar en el próximo fallo, así que conviene dimensionarlo según la tolerancia real de tiempo de recuperación, no solo según qué tan corto puede ser el número de forma segura.

2. Paralelismo dimensionado para el peor día, pagado todos los días

El número de slots de TaskManager normalmente se configura una vez, contra una estimación de carga pico, y se deja así — así que el tráfico en estado estable paga por capacidad que no usa la mayor parte del tiempo. Reactive Mode o un autoescalador a nivel de plataforma pueden cerrar esa brecha automáticamente; incluso sin eso, comparar el backpressure por subtask contra los slots aprovisionados detecta el caso obvio: paralelismo dimensionado para un pico que ocurre dos veces al año, pagado a precio completo todos los días de por medio.

3. El crecimiento ilimitado del estado infla los checkpoints silenciosamente

El estado con clave al que nunca se le aplicó un TTL crece mientras el job siga corriendo, y cada checkpoint tiene que serializarlo todo — así que la duración del checkpoint y el espacio de almacenamiento crecen mes a mes sin que un solo deploy sea el culpable. Nada se rompe, que es exactamente por qué pasa desapercibido. Aplicar un TTL que coincida con cuánto estado realmente necesita la lógica de negocio suele ser una victoria más grande de lo que parece, precisamente porque corrige una deriva lenta, no un valor mal configurado.

4. No todos los TaskManager son un candidato seguro para spot

Que un TaskManager pueda correr en capacidad spot depende de qué esté reteniendo: un job que se recupera limpiamente desde su último checkpoint, con tolerancia de tiempo de recuperación suficiente para absorber una interrupción, es un buen candidato — el mismo presupuesto de tiempo de recuperación de la palanca #1. Un job con un estado con clave grande que tarda minutos en reconstruirse desde cero es un candidato peor, ya que una interrupción ahí cuesta más que el cómputo que ahorró.