¿Cómo decide realmente el auto-escalado cuándo añadir o quitar instancias? ¿Qué métricas y políticas importan?
La utilización de CPU es la métrica de escalado por defecto, pero a menudo es la equivocada: la pregunta real es qué señal predice de verdad el dolor del usuario antes de que ocurra.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cómo decide realmente el auto-escalado cuándo añadir o quitar instancias? ¿Qué métricas y políticas importan?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#Lo que el auto-escalado realmente está decidiendo
El auto-escalado existe para ajustar la capacidad a la demanda sin que una persona esté mirando un dashboard: añadir instancias antes de que la latencia se degrade, quitarlas cuando están ociosas, y hacer ambas cosas automáticamente en cuestión de minutos. La parte interesante no es el mecanismo de añadir o quitar un servidor —eso ya lo resuelven los proveedores de nube y los orquestadores—, sino elegir la señal correcta a la cual reaccionar y la política correcta con la cual reaccionar, porque ambas deciden si el escalado realmente protege a los usuarios o simplemente añade costo e inestabilidad.
#Métricas: no todas miden lo correcto
La utilización de CPU es la opción por defecto porque es barata de recolectar y está disponible universalmente, pero es una señal rezagada e indirecta para muchos servicios reales. Un servicio que pasa la mayor parte de su tiempo esperando a una base de datos corriente abajo o a una API de terceros lenta puede verse casi ocioso en CPU mientras las peticiones se encolan y los usuarios sufren latencia real — la CPU nunca cruza el umbral de escalado porque el cuello de botella no es la CPU en absoluto.
La utilización de memoria importa para servicios con costo de memoria por petición o cachés que crecen, pero la presión de memoria suele manifestarse como muertes por OOM en lugar de una señal de escalado suave, así que se usa a menudo como disparador de escalado hacia arriba, pero rara vez para escalar hacia abajo.
La latencia de las peticiones, y en particular un percentil alto como el p99, es un proxy mucho más directo del dolor del usuario: captura el retraso por encolamiento causado por cualquier cuello de botella, no solo la CPU. Para servicios que procesan trabajo desde una cola en lugar de atender peticiones síncronas, la profundidad de la cola (o la edad del backlog: qué tan viejo es el elemento sin procesar más antiguo) suele ser la señal más honesta de todas, porque la relación entre el backlog y la cantidad de workers necesarios es casi lineal y fácil de razonar directamente.
#Tipos de política
El target tracking (seguimiento de objetivo) se comporta como un termostato: declaras un valor objetivo para una métrica (digamos, 60% de CPU promedio, o 1.000 peticiones por segundo por instancia), y un controlador calcula continuamente cuánta capacidad se necesita para mantener la métrica en ese objetivo, escalando hacia arriba o hacia abajo para ajustarse. Este es el modo por defecto tanto de las políticas de target tracking de AWS Auto Scaling como del Horizontal Pod Autoscaler de Kubernetes.
El step scaling (escalado por pasos) reacciona con magnitudes distintas según qué tan lejos esté la métrica de un umbral — CPU entre 70-85% podría añadir 2 instancias, CPU por encima de 85% podría añadir 5. Esto reacciona más rápido ante un pico severo que el ajuste más suave del target tracking, a costa de más ajuste manual de los propios escalones.
El scheduled scaling (escalado programado) pre-escala antes de patrones conocidos y predecibles — un sitio de retail escalando antes de una oferta relámpago, o un servicio B2B escalando antes de la hora pico de inicio de sesión a las 9am — evitando por completo el retraso de reacción de cualquier política basada en métricas para eventos que ya sabes que van a ocurrir.
El predictive scaling (escalado predictivo) pronostica la demanda a partir de patrones históricos y escala de forma proactiva adelantándose a la tendencia, en lugar de reaccionar solo después de que la métrica ya se movió. Es más valioso cuando el tiempo de arranque de una instancia es lo bastante largo como para que un escalado puramente reactivo llegue después de que el pico ya causó dolor.
#La fórmula central detrás del target tracking
Tanto el target tracking de AWS como el HPA de Kubernetes calculan la capacidad deseada con una versión de la misma fórmula:
réplicasDeseadas = techo( réplicasActuales × ( valorMétricaActual / valorMétricaObjetivo ) )
Si estás corriendo 4 instancias al 90% de CPU contra un objetivo de 60%, el controlador calcula techo(4 × (90/60)) = techo(6) = 6 instancias. Por eso el valor objetivo que elijas importa enormemente: un objetivo fijado demasiado cerca del 100% no deja margen para absorber el tiempo que tarda la nueva capacidad en realmente entrar en línea, mientras que un objetivo demasiado bajo sobreaprovisiona y desperdicia costo.
#Amortiguación: cooldowns, ventanas de estabilización y asimetría
Un controlador ingenuo que reacciona a cada muestra de métrica oscila: escala hacia arriba, la métrica baja del objetivo, escala hacia abajo, la carga vuelve, escala hacia arriba de nuevo — un aleteo (flapping) que desperdicia costo en rotación rápida de instancias y añade inestabilidad por capacidad que se reinicia constantemente. Los períodos de cooldown imponen un espacio mínimo entre acciones de escalado consecutivas. Las ventanas de estabilización van más allá: en lugar de reaccionar a la última muestra, el controlador observa una ventana móvil de recomendaciones recientes y elige la más conservadora — el máximo de la ventana para decisiones de escalado hacia arriba (así un pico breve no se deshace antes de ser absorbido), y el mínimo de la ventana para decisiones de escalado hacia abajo (así una caída breve no dispara un recorte de capacidad que se revierte de inmediato).
Esa asimetría es deliberada y vale la pena mencionarla explícitamente en una entrevista: el escalado hacia arriba debe ser rápido y agresivo, porque el sub-aprovisionamiento perjudica directamente a los usuarios, mientras que el escalado hacia abajo debe ser lento y conservador, porque el sobre-aprovisionamiento solo cuesta dinero — un error mucho más barato que un pico de latencia.
#El HPA v2 de Kubernetes en la práctica
apiVersion: autoscaling/v2kind: HorizontalPodAutoscalermetadata:name: checkout-service-hpanamespace: productionspec:scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: checkout-serviceminReplicas: 4maxReplicas: 60metrics:- type: Resourceresource:name: cputarget:type: UtilizationaverageUtilization: 60- type: Podspods:metric:name: requests_per_secondtarget:type: AverageValueaverageValue: "150"behavior:scaleUp:stabilizationWindowSeconds: 0policies:- type: Percentvalue: 100periodSeconds: 30- type: Podsvalue: 8periodSeconds: 30selectPolicy: MaxscaleDown:stabilizationWindowSeconds: 300policies:- type: Percentvalue: 10periodSeconds: 60selectPolicy: Min
Esta configuración sigue dos métricas a la vez (CPU y una métrica personalizada requests_per_second obtenida de un adaptador de métricas) — el HPA calcula las réplicas deseadas para cada una y toma el resultado mayor, así que gana cualquier señal que diga "escala más". El bloque behavior es donde vive la asimetría: el escalado hacia arriba no tiene retraso de estabilización y puede duplicar la capacidad (o añadir 8 pods, lo que sea mayor) cada 30 segundos, mientras que el escalado hacia abajo espera una ventana completa de 5 minutos y elimina como máximo el 10% de los pods por minuto — rápido para reaccionar a la carga, lento y cauteloso para devolverla.
#Callouts
🧠 Check your understanding
0/3 · 0/3 answered1. Un servicio tiene un cuello de botella en una llamada lenta a una base de datos corriente abajo, no en la CPU. ¿Cuál es el riesgo de escalar únicamente por utilización de CPU?
2. En la fórmula del HPA réplicasDeseadas = techo(réplicasActuales × (valorMétricaActual / valorMétricaObjetivo)), ¿qué pasa si el objetivo (valorMétricaObjetivo) se fija muy cerca del máximo práctico de la métrica?
3. ¿Por qué las configuraciones de HPA en producción suelen usar un stabilizationWindowSeconds mucho más largo para scaleDown que para scaleUp?