Escalado automático y los límites que no se ven

Un grupo de escalado tiene tres números: el mínimo (por debajo no baja), el deseado (lo que intenta mantener hoy) y el máximo (por encima no sube). El mínimo protege la disponibilidad. El máximo parece un detalle de costos, y es también un control de seguridad: un pico de peticiones, legítimo o hostil, hace subir la capacidad hasta ese tope. Sin tope, el pico se convierte en una factura sin techo y en un consumo de la cuota de la cuenta que deja sin sitio a las demás cargas.

Por eso el máximo se fija contra tres cosas a la vez: lo que soporta la base de datos que hay detrás, lo que cuesta, y lo que queda de cuota.

Cada cuenta tiene una cuota de vCPU por región y por tipo de uso. Es un límite de la cuenta, no del grupo: todas las cargas de la cuenta de producción lo comparten. Cuando el escalado pide más capacidad de la que la cuota permite, el servicio responde con un error y el grupo se queda por debajo de lo que pidió, sin que nadie lo avise si no hay una alarma sobre ese error.

Abre las tablas cuotas y grupos. El grupo de liquidación lanza instancias de un tamaño fijo, y la cuota ya tiene una parte en uso.

Los eventos de escalado dicen más que las métricas. Un lanzamiento fallido tiene un código de error, y el código distingue problemas con remedios muy distintos: un error de capacidad en una zona se resuelve lanzando en otra, y el servicio suele hacerlo solo; un error de cuota no se resuelve solo, porque el límite es de la cuenta y alguien tiene que pedir más o liberar lo que no se usa.

Lee la tabla eventos_de_escalado. Hay dos grupos con lanzamientos fallidos, por causas distintas.

Un grupo de escalado vigila la salud de sus instancias y reemplaza las que dejan de estar sanas. Para no matar instancias que aún están arrancando, existe un periodo de gracia: el tiempo que espera antes de empezar a mirar su salud. Si el periodo de gracia es menor que lo que tarda en arrancar la aplicación, cada instancia nueva se marca como no sana antes de estar lista y el grupo entra en un ciclo de lanzar y terminar que consume cuota y nunca llega a servir.

Compara en las tablas arranque y eventos_de_escalado: hay un grupo en que las instancias se terminan por salud a los pocos segundos de lanzarse.

Escalar y reemplazar instancias solo es seguro si las instancias son prescindibles. Una instancia que guarda sesiones de usuarios o archivos subidos en su disco local pierde esos datos cada vez que el grupo la termina, ya sea por una bajada de carga, un chequeo de salud o la caída de una zona. La carga ideal para un grupo de escalado no guarda estado en la instancia: sesiones, archivos y colas viven en servicios aparte que no dependen de ella.