Autoscaling de Rails por CPU y tiempo de respuesta, no por intuición

La mayoría de las guías de autoscaling asumen que ya tienes un pipeline de métricas, un panel y una idea clara de qué significa “carga alta” para tu aplicación en particular. La mayoría de las apps pequeñas de Rails no tienen nada de eso, y por eso el autoscaling termina descartado por completo a favor de simplemente correr un servidor más grande de lo necesario, todo el tiempo, por si acaso.

La versión simple: define un mínimo y un máximo, y deja que los dos números que de verdad se correlacionan con un proceso de Rails en problemas — CPU y el tiempo de respuesta p95 — decidan qué pasa entre esos límites.

Cómo decide en realidad

App → Settings → General → Autoscaling recibe un número mínimo y uno máximo de réplicas. Railyard agrega o quita réplicas web dentro de esos dos límites según:

• CPU objetivo por réplica (%) — el promedio de CPU que se le permite alcanzar a una réplica antes de agregar otra.
• Tiempo de respuesta p95 — el objetivo de tiempo de respuesta en el percentil 95; un proceso de Rails que encola requests detrás de una consulta lenta o un hilo bloqueado aparece aquí antes de aparecer como una caída.

Dejas Max en blanco y no pasa nada reactivo — la app simplemente corre con un número fijo de réplicas, que es el valor por defecto correcto para cualquier app que no vea carga variable de verdad.

Una restricción real que conviene conocer de entrada: las réplicas comparten el mismo servidor de la app, así que esto ayuda específicamente con carga atada a CPU o requests lentas, no con un servidor que de verdad se quedó sin capacidad — y nunca escala hacia arriba mientras la memoria del servidor ya está alta, porque agregar una réplica a una máquina sin memoria empeora las cosas, no las mejora.

PATCH /api/applications/:id/autoscale
{ "min": 1, "max": 4, "cpu": 70, "p95_ms": 400 }

Precalentar para un pico que de verdad puedes predecir

El escalado reactivo responde bien a la carga; no responde bien a la carga que está por llegar en los próximos sesenta segundos, porque para cuando la CPU sube lo suficiente como para disparar un escalado, el pico ya empezó a dañar los tiempos de respuesta. Las ventanas programadas resuelven el caso específico donde ya sabes cuándo va a llegar el pico — un lanzamiento de producto a una hora fija, un patrón de tráfico diario, un job por lotes semanal que siempre corre a la misma hora.

mon,tue,wed,thu,fri 08:00-18:00 3

Días, un rango de inicio y fin, y un número mínimo de réplicas, en la zona horaria de la propia app. La ventana solo eleva el piso — las reglas habituales de CPU/p95 siguen decidiendo todo por encima de ese mínimo, así que un pico más grande de lo esperado dentro de la ventana sigue escalando más allá. Precalienta; no reemplaza el escalado reactivo.

Qué reemplaza esto

La alternativa que la mayoría de los equipos corre hoy en la práctica es un número fijo y sobredimensionado de servidores, elegido una vez y revisado casi nunca, porque construir una señal real de autoscaling desde cero es un proyecto en sí mismo. Dos números que ya se correlacionan con el desgaste específico de Rails — CPU y p95 — resultan ser suficientes para automatizar el caso común sin necesitar antes todo un stack de métricas.

Referencia completa, incluyendo cómo interactúa esto con el failover automático: Autoscaling y failover.