Escalado automático y dominios personalizados

El autoescalado ajusta automáticamente el número de instancias de App Service que ejecutan su aplicación en función de la demanda en tiempo real. Sin autoescalado, debe aprovisionar recursos para la carga máxima y pagar por capacidad inactiva durante las horas de menor demanda. Con autoescalado, Azure añade instancias cuando aumenta la carga y las elimina cuando disminuye, optimizando tanto el rendimiento como el coste. El autoescalado requiere el nivel Standard o superior.

Azure ofrece dos dimensiones de escalado. El escalado horizontal añade más instancias idénticas de su aplicación para repartir la carga; esto es lo que hace principalmente el autoescalado. El escalado vertical cambia a un tamaño de VM mayor, con más CPU y RAM, modificando la SKU del plan de App Service. El escalado horizontal se prefiere por su resiliencia, ya que varias instancias pueden sobrevivir a fallos individuales; el escalado vertical tiene límites de hardware.

El autoescalado de Azure se configura mediante configuraciones de autoescalado asociadas a un plan de App Service. Una configuración de autoescalado contiene uno o varios perfiles (regular, fecha fija o recurrencia), cada uno con sus propias reglas. Una regla de escalado horizontal se activa cuando una métrica supera un umbral (por ejemplo, CPU > 70 %); una regla de reducción horizontal se activa cuando cae por debajo de un umbral inferior (por ejemplo, CPU < 30 %). Defina siempre reglas tanto de escalado horizontal como de reducción horizontal para evitar un crecimiento descontrolado o costes excesivos.

El autoescalado basado en programación (perfiles de recurrencia) permite preescalar recursos para patrones de tráfico predecibles. Por ejemplo, puede escalar horizontalmente hasta 10 instancias todos los días laborables a las 08:00 y reducirlas a 2 a las 18:00. La combinación de perfiles basados en programación y perfiles basados en métricas ofrece lo mejor de ambos enfoques: capacidad preescalada para picos conocidos y una respuesta elástica ante aumentos inesperados.

Un periodo de enfriamiento es un retraso posterior a una acción de escalado durante el cual no se realizan más acciones de escalado. Evita el comportamiento oscilante: aumentos o reducciones horizontales rápidos y repetidos provocados por picos de métricas transitorios. El periodo de enfriamiento predeterminado es de 5 minutos para el escalado horizontal y de 5 minutos para la reducción horizontal. Configure un periodo más largo para la reducción horizontal (por ejemplo, de 10 a 15 minutos) para dar tiempo a las instancias a cerrar las conexiones activas antes de eliminarlas.

Las aplicaciones de App Service obtienen un nombre de host predeterminado azurewebsites.net. Para usar su propio dominio (por ejemplo, www.contoso.com), añada un dominio personalizado en la configuración de App Service y cree los registros DNS correspondientes en el registrador de su dominio. Debe demostrar la propiedad creando un registro CNAME o un registro TXT (denominado registro de verificación) en su zona DNS y, después, crear el registro CNAME o A de enrutamiento real.

Una vez asignado un dominio personalizado, necesita un certificado TLS para habilitar HTTPS. App Service ofrece tres opciones: App Service Managed Certificate (gratuito, con renovación automática y limitado a dominios estándar), App Service Certificate (adquirido mediante Azure y almacenado en Key Vault) o la carga de un certificado de terceros (su propio certificado de Let's Encrypt o de una CA). El modo de solo HTTPS redirige automáticamente todo el tráfico HTTP a HTTPS.

Aunque la CPU es una métrica habitual para el autoescalado, la longitud de la cola HTTP suele ser una señal mejor para las aplicaciones web. Cuando la longitud de la cola es elevada, hay solicitudes nuevas esperando porque las instancias están completamente ocupadas. El escalado basado en HttpQueueLength detecta la sobrecarga más rápido que la CPU, ya que esta puede fluctuar sin indicar necesariamente una latencia perceptible para el usuario. Use ambas métricas conjuntamente para obtener un comportamiento de autoescalado sólido.

Configure notificaciones de autoescalado para recibir alertas por correo electrónico o webhook cuando se produzcan eventos de escalado. Esto ayuda a los equipos a comprender los patrones de tráfico y verificar que el autoescalado funciona según lo esperado. Las notificaciones se configuran en la sección de notificaciones de la configuración de autoescalado y pueden dirigirse a varias direcciones de correo electrónico y puntos de conexión webhook (para integrarse con Slack, PagerDuty o herramientas personalizadas).

Para asignar un dominio apex (por ejemplo, contoso.com sin www) a App Service, se necesita un registro A que apunte a la dirección IP de App Service, además de un registro TXT de verificación. Como las direcciones IP de App Service pueden cambiar, Microsoft recomienda usar Azure Traffic Manager o Azure Front Door como intermediario: el equivalente de CNAME para el dominio apex (registro ALIAS/ANAME) apunta al perfil de Traffic Manager, que dirige el tráfico a App Service.

Después de configurar el escalado automático, compruebe que funciona correctamente generando carga artificial. Use herramientas como Apache JMeter, k6 o Azure Load Testing para simular usuarios simultáneos. Observe la métrica Instance count del plan de App Service en Azure Monitor para confirmar que el número de instancias aumenta cuando se incrementa la carga y disminuye cuando esta baja. Documente las RPS (solicitudes por segundo) observadas por instancia para validar los umbrales de escalado.

Compruebe su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que las reglas de escalado automático de los planes de App Service agregan o quitan instancias según el uso de CPU, la cola HTTP o los desencadenadores programados; los dominios personalizados requieren registros DNS CNAME/A y un registro TXT de verificación en la zona DNS; y los certificados TLS (incluidos los certificados administrados gratuitos) habilitan HTTPS en los dominios personalizados. A continuación, exploraremos la autenticación y las redes de App Service.