AZ-104

Deep Dive

D3 · Cómputo

Autoscaling y Virtual Machine Scale Sets

VMSS permite desplegar y gestionar conjuntos de VMs idénticas que escalan automáticamente. El AZ-104 evalúa los modos de escalado, reglas de autoscale, update policies y el modelo Flexible vs Uniform.

Icon-compute-34

Virtual Machine Scale Sets (VMSS)

Un Virtual Machine Scale Set es un recurso que crea y gestiona un grupo de VMs idénticas (misma imagen, mismo tamaño). Permite escalar el número de instancias manualmente o automáticamente según demanda, con balanceo de carga integrado.

VMSS es la base de AKS node pools, App Service, y muchos servicios de Azure internamente. Para el AZ-104, el foco está en crear y gestionar VMSS directamente.

Cuándo usar VMSS

  • Workloads que necesitan escalar en y out horizontalmente
  • Carga variable predecible o impredecible
  • Alta disponibilidad multi-instancia
  • Tier web/app de arquitecturas de N capas

Cuándo usar VMs individuales

  • Una sola instancia (DB, bastion, jump box)
  • VM con configuración muy específica no replicable
  • Apps stateful que no soportan múltiples instancias
  • Cargas de trabajo de dominio único (AD DS, etc.)

Límites de VMSS

  • Uniform: hasta 1.000 instancias por VMSS
  • Flexible: hasta 1.000 instancias
  • Mínimo: 0 instancias (se puede escalar a cero)
  • Múltiples VMSS en un Availability Set o Zones

Modos de escalado en VMSS

Manual Scaling

Defines un número fijo de instancias. Cambias el número manualmente cuando necesitas más o menos capacidad.

Pros

Simple, predecible, sin sorpresas de costo.

Cons

Requiere intervención manual. Puede desperdiciar recursos o quedarse corto en picos.

Autoscale (métrica)

Reglas que aumentan o reducen instancias basadas en métricas (CPU, memoria, Custom Metrics, Service Bus queue length, etc.).

Pros

Reactivo a demanda real. Optimiza costos automáticamente.

Cons

Lag entre el trigger y las instancias activas. Configuración más compleja.

Schedule-based

Configura el número de instancias basado en días/horas. Ej: 10 instancias de 8h a 20h (horario laboral), 2 instancias el resto.

Pros

Para cargas muy predecibles. Sin lag de warmup.

Cons

No reacciona a demanda inesperada fuera del horario.

Azure Autoscale — reglas y condiciones

Anatomía de una regla de autoscale

Metric source

De dónde viene la métrica: el propio VMSS, una Storage Account, Service Bus, Application Insights. Lo más común: % CPU del VMSS.

Condición

Métrica, operador (>, <, >=, <=, ==), umbral y ventana de tiempo. Ej: "CPU media > 70% durante los últimos 10 minutos".

Acción

Qué hacer si se cumple la condición: aumentar/reducir el conteo en N instancias, o establecer un conteo absoluto. Con cooldown period.

Cooldown

Tiempo de espera después de un scaling event antes de evaluar de nuevo. Evita thrashing (escalar y desescalar continuamente). Default 5 min.

Ejemplo: reglas scale out + scale in

Scale Out (agregar instancias)

Cuando CPU media > 70% en los últimos 10 min

→ Aumentar en 2 instancias | Cooldown: 5 min

Scale In (eliminar instancias)

Cuando CPU media < 30% en los últimos 15 min

→ Reducir en 1 instancia | Cooldown: 10 min

Límites siempre

Mínimo: 2 instancias | Máximo: 20 instancias

Buenas prácticas de autoscale

  • → Scale out agresivo (añadir varias), scale in conservador (quitar pocas)
  • → Scale in cooldown mayor que scale out para evitar thrashing
  • → Configura notificaciones de email/webhook cuando se escala
  • → Usa métricas de aplicación (no solo CPU) si tienes Application Insights
  • → Siempre define un mínimo de >1 instancia en producción para HA

Update Policy — aplicar cambios a instancias

Cuando cambias la imagen o la configuración del VMSS, la update policy define cómo y cuándo se propaga el cambio a las instancias existentes.

Automatic

Azure actualiza automáticamente todas las instancias lo antes posible, en batches. Sin intervención manual.

Puede causar downtime si la app no tolera instancias mixtas durante el rollout.

Rolling

Actualiza por batches (% configurable del total). Espera que el batch anterior esté saludable antes de continuar. Acepta configuración de pausa.

Más seguro. Puede combinarse con health probes para validar cada batch.

Manual

Las instancias nuevas usan la nueva imagen. Las existentes NO se actualizan automáticamente — debes actualizar cada instancia manualmente (upgrade instance).

Máximo control. Instancias en distintas versiones hasta que las actualices.

Automatic Instance Repair

Cómo funciona

Si una instancia del VMSS se vuelve insalubre (health probe falla o la app dentro de la VM reporta unhealthy), Azure la elimina automáticamente y crea una nueva instancia en su lugar.

• Requiere configurar un Application Health Extension o un Load Balancer health probe

Grace period: tiempo que espera antes de reparar (default 30 min) — para que la app tenga tiempo de iniciarse

• La instancia defectuosa se elimina y se crea una nueva desde la imagen base

• Combinado con update policy Rolling: deploy + self-healing automático

Application Health Extension

Extension que se instala en cada instancia del VMSS. Envía un HTTP request al endpoint de salud de la app (ej: /health) y reporta el estado al VMSS.

• Configuras: protocolo (HTTP/HTTPS/TCP), puerto y ruta del health endpoint

• La app responde 200 OK = Healthy. Cualquier otro código o timeout = Unhealthy

• También sirve para que Rolling Updates esperen a que el batch esté healthy antes de continuar

Flexible vs Uniform — dos modos de VMSS

DimensiónUniform (clásico)Flexible (recomendado)
Identidad de instanciasInstance ID numérico (0, 1, 2...)VM ID completo de Azure — cada instancia es una VM real
APIs de gestiónAPIs específicas de VMSSMismas APIs de VMs individuales + VMSS
Spot mixingTodo Spot o todo regularMezclar Spot + regular en el mismo VMSS
VM sizes mixingUn solo tamañoMúltiples tamaños en el mismo VMSS
Availability ZonesSoportadoSoportado + mejor distribución (zone balancing)
Integración serviciosLimitada a VMSS APIsTotal — aparecen como VMs normales en el portal
Recomendado paraAKS node pools internamente, escenarios legacyNuevos workloads, reemplaza Availability Sets

Recomendación de Microsoft

Para nuevos despliegues: usar VMSS Flexible. Reemplaza tanto los VMSS Uniform clásicos como los Availability Sets (que ya no reciben nuevas features). El modo Flexible da las ventajas de escala de VMSS con la flexibilidad de VMs individuales.

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Un VMSS está configurado con Autoscale: escala out cuando CPU > 75% por 10 minutos, y escala in cuando CPU < 25% por 5 minutos. El cooldown de scale-out es 3 minutos y el de scale-in es 5 minutos. La CPU sube a 80% y se añaden 2 instancias. Dos minutos después la CPU baja a 20%. ¿Qué ocurre?