La lección anterior terminó con un diagnóstico incómodo: vm-motor-disponibilidad-dev funciona, pero es una sola máquina. Si el host físico falla, si Azure aplica mantenimiento a la plataforma o si el tráfico se multiplica por diez, no hay plan B. Y a Contoso Airlines le va a pasar lo tercero con fecha marcada en el calendario.

Cada año, a mediados de febrero, Contoso abre la venta de la temporada de verano. El primer día se concentra alrededor del 60 % del tráfico del mes, con un pico de tres horas por la mañana en el que la API de Disponibilidad recibe unas quince veces las peticiones de un día normal. Con servidores propios en Barcelona y Palma, la respuesta histórica fue comprar hardware para el pico y tenerlo al 6 % de uso los otros 364 días. Ese es, literalmente, el problema que la nube resuelve.

En esta lección aprenderás a escalar el cómputo y a darle alta disponibilidad: qué diferencia hay entre crecer hacia arriba y crecer hacia los lados, cómo funcionan los conjuntos de escalado de máquinas virtuales, cómo se reparten las instancias en zonas de disponibilidad, qué balanceador elegir entre los cuatro que ofrece Azure, y qué requisito de diseño impone todo esto a tu aplicación: no tener estado.

Aviso de coste: un conjunto de escalado con dos instancias factura dos VM, y un Load Balancer Standard tiene coste por hora y por reglas. Todo lo de esta lección se elimina al final con un único borrado del grupo de recursos de laboratorio.

1. Escalado vertical frente a escalado horizontal
2. El caso de Contoso: el pico de apertura de temporada
3. Conjuntos de escalado de máquinas virtuales (VMSS)
4. Escalado manual, automático por métrica y programado
5. Zonas de disponibilidad y conjuntos de disponibilidad
6. Balanceo de carga en Azure: las cuatro opciones
7. Sondas de estado
8. Desplegar la API de Disponibilidad tras un Load Balancer
9. Aplicaciones sin estado: el requisito escondido
10. Arquitectura resultante y limpieza
11. Errores Comunes y Consejos
12. Ejercicios
13. Conclusión

Hay dos maneras de dar más capacidad a un sistema.

El escalado vertical es simple y a veces la respuesta correcta: una base de datos relacional monolítica suele escalar mejor hacia arriba. Pero para el cómputo de una aplicación web, el modelo de la nube es el horizontal, por tres razones:

1. Elasticidad real: puedes pasar de 2 a 20 instancias en minutos y volver a 2 cuando el pico termine. Pagas por lo que usas, cuando lo usas.
2. Disponibilidad: N instancias repartidas soportan la pérdida de una sin que el servicio caiga.
3. Sin techo abrupto: no llegas un día al tamaño máximo de la familia y te quedas sin salida.

La contrapartida es la de la última fila de la tabla, y no es menor: si tu aplicación guarda la sesión del usuario en la memoria del servidor o escribe ficheros en su disco local, el escalado horizontal la rompe. Lo tratamos en el apartado 9.

Los números que Marta Ríos ha medido en el sistema actual:

La conclusión es doble: se necesita capacidad muy superior durante unas horas al año y capacidad mínima el resto del tiempo. Dimensionar para el pico con máquinas fijas significa pagar quince veces lo necesario durante 360 días. Dimensionar para el día normal significa perder ventas el día que más se vende.

La solución que construimos en esta lección: la API de Disponibilidad se despliega en un conjunto de escalado con un mínimo de 2 instancias repartidas en dos zonas, una regla de escalado automático por CPU y una regla programada que eleva el mínimo la mañana de la apertura, todo detrás de un Load Balancer.

Un conjunto de escalado de máquinas virtuales (Virtual Machine Scale Set, VMSS) es un recurso que gestiona un grupo de VM idénticas como una sola unidad: se crean a partir del mismo modelo, se actualizan juntas y crecen o menguan según reglas.

Qué te da un VMSS que no te da crear VM a mano:

• Un solo modelo: cambias la imagen o el tamaño en el modelo y se aplica a todas.
• Escalado automático por métrica, por horario o manual.
• Reparación automática de instancias: si una instancia falla la sonda de estado durante un tiempo, el conjunto la reemplaza.
• Distribución automática entre zonas y dominios de error.
• Actualizaciones por lotes (rolling upgrades) sin caída del servicio.

Flexible es hoy el modo recomendado por defecto: te da la gestión del conjunto sin perder el control individual de cada VM, y permite mezclar instancias de precio esporádico (spot) con instancias normales para abaratar los picos. Es el que usaremos.

El escalado automático observa una métrica y actúa. Una regla completa tiene siempre estas piezas:

Fíjate en la asimetría deliberada entre las dos reglas, que es una buena práctica y no un descuido:

• Se sube rápido y en bloques grandes (+2 con ventana de 5 minutos): quedarse corto cuesta ventas.
• Se baja despacio y de una en una (−1 con ventana de 10 minutos): reducir demasiado pronto provoca el efecto sierra, en el que el sistema añade y quita instancias sin parar, y cada arranque tarda minutos y cuesta dinero.

Si las reglas de subida y bajada tienen el mismo umbral, tendrás oscilación garantizada. Deja siempre una banda muerta amplia entre ambas (aquí, entre 30 % y 70 %).

Cuando sabes cuándo llega el pico, no esperes a que la CPU lo demuestre: la reacción por métrica siempre llega tarde, porque una instancia nueva tarda unos minutos en arrancar y estar lista.

Durante ese perfil, el conjunto nunca baja de 10 instancias y puede llegar a 30 si la CPU lo pide. Fuera de la ventana, vuelve al perfil normal (2–20). Esta combinación —programado para lo previsible, por métrica para lo imprevisible— es el patrón que usan la mayoría de plataformas de venta con estacionalidad.

Tener varias instancias no sirve de nada si están todas en el mismo bastidor y ese bastidor se queda sin corriente. Azure ofrece dos mecanismos de reparto, y protegen de cosas distintas.

Reparte las VM entre:

• Dominios de error (fault domains): grupos de servidores que comparten alimentación eléctrica y conmutador de red. Si falla el bastidor, cae un dominio de error. Hasta 3 por región.
• Dominios de actualización (update domains): grupos que Azure reinicia por separado durante el mantenimiento de la plataforma. Hasta 20.

Protege de: fallo de bastidor y reinicios de mantenimiento. No protege de la caída completa del centro de datos.

Como viste en 01-02, una zona es un centro de datos físicamente separado dentro de la misma región, con alimentación, refrigeración y red independientes. Repartir instancias entre zonas protege del fallo de un centro de datos entero.

Decisión de Contoso, coherente con la del módulo 1: componentes críticos en al menos dos zonas de West Europe, sin activo-activo multirregión (decisión consciente por coste). La API de Disponibilidad se despliega en las zonas 1 y 2.

Con --zones 1 2, Azure reparte las instancias de forma equilibrada entre ambas zonas y mantiene ese equilibrio al escalar. Importante: las zonas se eligen al crear el conjunto y no se pueden añadir después. Si crees que algún día lo necesitarás, créalo con zonas desde el principio.

Tener varias instancias exige algo delante que reparta el tráfico. Azure ofrece cuatro servicios y la confusión entre ellos es uno de los temas favoritos de los exámenes de certificación (y de las arquitecturas mal hechas).

Criterios de elección, en forma de preguntas:

1. ¿Es tráfico HTTP/S? Si no lo es (por ejemplo, un protocolo propio del motor heredado), tu opción es Load Balancer o Traffic Manager.
2. ¿Necesitas decidir por la URL (/api/* a un grupo, / a otro), reescribir cabeceras o descargar TLS? Entonces necesitas capa 7: Application Gateway o Front Door.
3. ¿El tráfico llega de todo el mundo y quieres caché y presencia en el borde? Front Door.
4. ¿Solo quieres conmutar entre regiones a nivel DNS, con cualquier protocolo? Traffic Manager.

Dos avisos de alcance, para no invadir otras lecciones:

• Lo global —Front Door, Traffic Manager, CDN— se desarrolla en la lección 02-06, con el caso del cliente que compra desde Sudamérica.
• El firewall de aplicaciones web (WAF), que se acopla a Application Gateway o a Front Door, se trata en la lección 04-04.

Aquí nos quedamos en lo regional y de capa 4: Azure Load Balancer delante del conjunto de escalado.

Las SKU: Standard (la actual: admite zonas, hasta 1.000 instancias, seguro por defecto) y Basic, ya retirada. Usa siempre Standard.

Una sonda de estado es lo que separa un balanceador de un repartidor ciego. Cada pocos segundos, el balanceador pregunta a cada instancia si está viva; si no responde correctamente un número de veces seguidas, deja de enviarle tráfico.

Buenas prácticas para el punto de salud, que valen para todo el curso:

• Que sea significativo: debe comprobar lo que hace falta para servir (¿hay conexión con la base de datos?), no devolver 200 siempre.
• Que sea barato: se ejecuta cada pocos segundos por instancia. Nada de consultas pesadas.
• Que no exija autenticación desde la red interna, o la sonda fallará siempre.
• Separa vivacidad de preparación: «el proceso está vivo» no es lo mismo que «puedo atender peticiones ya».

Una sonda mal hecha causa dos averías clásicas y opuestas: instancias rotas recibiendo tráfico (sonda demasiado indulgente) o instancias sanas retiradas del servicio en cascada (sonda demasiado estricta o con tiempo de espera corto).

Montamos la pieza completa. Para no tocar producción mientras aprendes, usa el grupo de desarrollo; el ejemplo indica producción porque es la arquitectura objetivo, pero puedes sustituir pro por dev en todas las variables.

El fichero init-api.yaml que instala la API en cada instancia (el mismo mecanismo de cloud-init de la lección anterior, ahora sirviendo la identidad de la instancia para que puedas ver el balanceo funcionando):

Comprobación del balanceo: varias llamadas seguidas deben devolver nombres de instancia distintos.

Si siempre responde la misma instancia, revisa la persistencia de sesión de la regla: por defecto el Load Balancer usa una tupla de cinco campos (IP y puerto de origen y destino, protocolo), y como tu puerto de origen cambia en cada petición, deberías ver reparto. Si configuras persistencia por IP de origen (--load-distribution SourceIP), todas tus peticiones irán a la misma instancia, que es justo lo que no queremos por el motivo del siguiente apartado.

El escalado horizontal impone una condición a la aplicación: cualquier instancia debe poder atender cualquier petición. Eso significa que la instancia no puede guardar nada que las demás necesiten.

Los tres estados que rompen el escalado y dónde deben ir en su lugar:

La tentación fácil es activar la persistencia de sesión en el balanceador para que cada cliente vaya siempre a la misma instancia. Es un parche con tres efectos secundarios serios: el reparto se desequilibra, la caída de una instancia expulsa a sus usuarios, y al reducir instancias se pierden sesiones activas. Sirve como solución temporal durante una migración, nunca como diseño.

Por eso el orden de este módulo no es casual: primero el cómputo escalable, después el almacenamiento donde vive lo que el cómputo no puede guardar (02-04) y en el módulo 3, la base de datos. La API de Disponibilidad de Contoso se diseña sin estado desde el primer día: lee de la base de datos, escribe las tarjetas en Storage y no guarda nada en local.

Limpieza (recuerda que el grupo de producción tiene el bloqueo no-borrar-produccion; en laboratorio trabaja sobre el grupo de desarrollo):

Y una comprobación que ya deberías hacer por reflejo: az disk list --query "[?diskState=='Unattached']" -o table.

• Poner el mismo umbral para subir y bajar. Produce el efecto sierra: el sistema añade y quita instancias sin parar. Deja una banda muerta amplia (30 %–70 %).
• Bajar tan agresivamente como se sube. Reducir de dos en dos con ventana de 5 minutos deja el servicio corto justo cuando el pico rebota. Sube rápido, baja despacio.
• Confiar solo en el escalado por métrica para un pico conocido. Arrancar instancias tarda minutos; el pico de la apertura llega en segundos. Usa un perfil programado.
• Confundir conjunto de disponibilidad con zona de disponibilidad. El primero protege del fallo de bastidor dentro de un centro de datos; el segundo, de la caída del centro de datos entero.
• Olvidar que las zonas se fijan al crear el conjunto de escalado. No se añaden después. Créalo zonal desde el principio.
• Usar Application Gateway donde basta un Load Balancer (o al revés). Si no necesitas decisiones por URL ni terminación TLS, la capa 4 es más simple y mucho más barata.
• Sondas que devuelven 200 pase lo que pase. Un punto de salud que no comprueba nada garantiza que el balanceador envíe tráfico a instancias rotas.
• Escalar horizontalmente una aplicación con estado en memoria. Aparecen errores intermitentes imposibles de reproducir. Saca el estado antes de escalar.
• Consejo de cuota: el máximo de vCPU por familia y región es una cuota, no un límite físico (lección 01-05). Si tu regla puede llegar a 20 instancias de 4 vCPU, comprueba que tienes 80 vCPU de cuota antes del día de la apertura.
• Consejo de coste: para los picos, considera instancias de precio esporádico (spot) dentro del conjunto flexible. Son mucho más baratas a cambio de poder ser desalojadas; sirven para capacidad extra, nunca para el mínimo.

Con los datos medidos por Marta Ríos (15 peticiones por segundo de madrugada, 120 en hora punta normal, 1.800 en el pico de apertura), y sabiendo que una instancia Standard_B2s de la API atiende cómodamente unas 100 peticiones por segundo:

1. ¿Cuántas instancias hacen falta como mínimo en un día normal en hora punta, con margen para perder una?
2. ¿Cuántas en el pico de apertura?
3. Define los valores de mínimo, máximo y perfil programado que configurarías.
4. Explica por qué no basta con la regla por CPU para ese día.

Para cada necesidad de Contoso, indica qué servicio de balanceo usarías y por qué:

1. Repartir el tráfico del protocolo binario del motor de disponibilidad heredado (TCP 8500) entre tres VM en West Europe.
2. Enviar /api/* a la API de Disponibilidad y el resto a la web de reservas, dentro de la misma región, con terminación TLS.
3. Servir la web pública a clientes de Sudamérica con la menor latencia posible y caché de imágenes.
4. Conmutar a North Europe si West Europe deja de responder, para un servicio que no es HTTP.

En un grupo de laboratorio:

1. Crea un conjunto de escalado flexible con 2 instancias en las zonas 1 y 2, con cloud-init que publique el nombre de la instancia en /salud.json.
2. Ponlo detrás de un Load Balancer Standard con sonda HTTP a /salud.json.
3. Demuestra con curl que el tráfico se reparte entre las dos instancias.
4. Detén una instancia y demuestra que el servicio sigue respondiendo y que la sonda la ha retirado del grupo.

Solución 1:

1. Hora punta normal: 120 ÷ 100 = 1,2 → 2 instancias, y con margen para perder una (patrón N+1), 3. Como el mínimo también debe cubrir la zona que pueda caer, 2 es el suelo absoluto y 3 lo prudente.
2. Pico de apertura: 1.800 ÷ 100 = 18 → 18 instancias, más margen N+1 → 20.
3. Configuración propuesta:

4. Porque el escalado por métrica es reactivo: necesita 5 minutos de CPU alta para disparar y varios minutos más para que las instancias arranquen y pasen la sonda. El pico de la apertura llega en menos de un minuto, así que durante los primeros 10 minutos —los de más ventas del año— el servicio estaría saturado. El perfil programado deja la capacidad ya caliente antes de que abra la venta.

Solución 2:

Solución 3:

Tras detener la instancia, la sonda falla varias veces seguidas y el balanceador la retira del grupo: puedes tardar unos 15-20 segundos en ver el efecto (intervalo de sonda por número de fallos tolerados). Ese retardo es exactamente el tiempo de indisponibilidad parcial que sufrirían algunos clientes en un fallo real, y es el argumento para no poner intervalos de sonda largos.

Ya sabes escalar y dar alta disponibilidad al cómputo en Azure. Distingues el escalado vertical del horizontal y entiendes por qué la nube apuesta por el segundo: elasticidad real, disponibilidad intrínseca y ausencia de techo. Sabes qué es un conjunto de escalado de máquinas virtuales, la diferencia entre orquestación uniforme y flexible, y cómo definir escalado manual, automático por métrica —con umbrales asimétricos y banda muerta para evitar el efecto sierra— y programado, que es la única respuesta razonable a un pico con fecha conocida como la apertura de la temporada de verano de Contoso. Conoces la diferencia entre conjuntos de disponibilidad (dominios de error y actualización dentro de un centro de datos) y zonas de disponibilidad (centros de datos independientes), con su efecto directo en el SLA: 99,9 %, 99,95 % y 99,99 %. Has comparado los cuatro servicios de balanceo con criterios claros y has desplegado un Load Balancer Standard con sonda de estado sobre un conjunto de escalado repartido en dos zonas. Y has interiorizado el requisito escondido de todo esto: la aplicación no puede tener estado local.

Ahora bien, mira lo que ha costado: un conjunto de escalado, un balanceador, una sonda, reglas de autoescalado, y todavía tienes que parchear el sistema operativo de cada instancia, actualizar la imagen, gestionar certificados TLS a mano y montar tú mismo el despliegue sin caídas. Para el motor heredado no hay alternativa. Pero para una aplicación web moderna como Contoso Reservas o para la nueva API de Disponibilidad, Azure ofrece un servicio que hace todo eso por ti.

En la siguiente lección, Azure App Service, verás por qué Contoso publica ahí sus aplicaciones en lugar de mantener VM: planes y niveles con lo que desbloquea cada uno, pilas de tiempo de ejecución, despliegue del código con ZIP y Git, ajustes de aplicación y cadenas de conexión, dominios propios con certificados gestionados, escalado automático sin conjuntos que administrar y, sobre todo, ranuras de despliegue con intercambio y calentamiento previo para publicar versiones nuevas sin que ningún cliente deje de comprar su billete.