Dimensionamiento adecuado y escalado automático

El ajuste del tamaño es el proceso de adaptar los SKU de las máquinas virtuales o los servicios de Azure a los requisitos reales de recursos de la carga de trabajo, evitando tanto el sobredimensionamiento (desperdicio de dinero) como el infradimensionamiento (riesgo de degradación del rendimiento). Al migrar desde entornos locales, la mayoría de las organizaciones aprovisionan inicialmente entre un 30 y un 50 % más de capacidad por precaución. Un análisis periódico del tamaño, normalmente mensual, puede recuperar una parte significativa de ese gasto excesivo sin afectar al rendimiento de la aplicación.

Use las métricas de Azure Monitor y VM Insights para recopilar datos de CPU, memoria, IOPS de disco y rendimiento de red durante al menos 30 días. Examine el uso máximo (P95 o P99), no el promedio, para asegurarse de que la máquina virtual con el tamaño adecuado pueda gestionar los picos de tráfico. De forma predeterminada, la recomendación de ajuste del tamaño de Azure Advisor usa un periodo de análisis retrospectivo de 7 días, pero puede ampliarlo a 30 o 60 días en la configuración de Advisor para obtener datos más representativos.

Las máquinas virtuales de Azure se organizan en familias de SKU optimizadas para distintas cargas de trabajo: D-series (propósito general), E-series (optimizadas para memoria), F-series (optimizadas para proceso), N-series (GPU) y L-series (optimizadas para almacenamiento). Si el uso de CPU de una máquina virtual es bajo, pero el de memoria es alto, pasar de una D-series a una E-series con el mismo número de vCPU proporciona más RAM a un coste similar. Cambiar el tamaño de una máquina virtual en Azure normalmente requiere un breve reinicio de unos minutos.

El escalado automático programado es la opción adecuada cuando los patrones de carga de trabajo son predecibles. Una aplicación comercial que recibe mucho tráfico durante el horario laboral y casi ninguno durante la noche se puede configurar con un programa de escalado horizontal hacia fuera a las 07:00 y otro de escalado horizontal hacia dentro a las 22:00. Tanto Virtual Machine Scale Sets (VMSS) como App Service admiten reglas de escalado automático programado. Este enfoque es más sencillo y permite prever mejor los costes que el escalado automático basado en métricas cuando los patrones de carga son conocidos.

El escalado automático basado en métricas agrega o elimina instancias dinámicamente en respuesta a métricas en tiempo real, como el porcentaje de CPU, la longitud de la cola de solicitudes HTTP o las métricas personalizadas publicadas mediante Azure Monitor. Defina reglas de escalado horizontal hacia fuera (cuándo agregar instancias) y reglas de escalado horizontal hacia dentro (cuándo eliminar instancias), con periodos de espera para evitar cambios rápidos y repetidos. Como práctica recomendada, establezca un umbral de escalado hacia fuera inferior al umbral de escalado hacia dentro; por ejemplo, escalar hacia fuera con un uso de CPU superior al 70 % y hacia dentro con un uso inferior al 30 %, con un periodo de espera de 5 minutos.

Azure Spot VMs le permiten usar capacidad de Azure no utilizada con descuentos de hasta el 90 % en comparación con los precios de pago por uso. La contrapartida es que Azure puede evict las máquinas virtuales Spot con un aviso de 30 segundos cuando necesita recuperar la capacidad. Esto hace que las instancias Spot sean ideales para cargas de trabajo por lotes interrumpibles, como renderizado, computación científica y canalizaciones de procesamiento de datos. VMSS admite la combinación de máquinas virtuales normales (para una capacidad base) con máquinas virtuales Spot (para capacidad adicional) en el mismo conjunto de escalado mediante una directiva de combinación de prioridades.

El escalado automático de Azure App Service funciona en el nivel de App Service Plan: agrega o quita instancias de trabajador según las reglas que configure. Entre los desencadenadores de métricas disponibles se incluyen la longitud de la cola HTTP, el porcentaje de CPU y el porcentaje de memoria. El nivel Standard y los superiores admiten el escalado manual y el escalado automático; el nivel Basic solo admite el escalado manual. Para cargas de trabajo serverless, considere la posibilidad de usar Azure Functions en el Consumption Plan, que escala hasta cero y cobra únicamente por ejecución, eliminando por completo el coste de las instancias inactivas.

Errores habituales del escalado automático: — si la aplicación almacena el estado de sesión en la memoria de la máquina virtual, el escalado hacia dentro provocará la pérdida de sesiones; use Redis Cache o sesiones respaldadas por una base de datos. Tiempos de inicio prolongados — si las máquinas virtuales o los contenedores tardan 10 minutos en estar operativos, el escalado automático basado en métricas no puede responder con suficiente rapidez; anticípese a los picos previstos mediante un escalado programado hacia fuera. Escalado hacia dentro demasiado agresivo — terminar instancias mientras se procesan solicitudes en curso provoca errores; configure el connection draining y un periodo de enfriamiento amplio.

El dimensionamiento adecuado también se aplica a los servicios PaaS. Azure SQL Database con el modelo DTU puede reducirse de tamaño si el porcentaje de DTU se mantiene constantemente por debajo del 50 %. El modelo vCore permite escalar CPU y almacenamiento de forma independiente. Azure Cache for Redis puede reducirse del nivel Premium al nivel Standard si no se necesitan la persistencia ni la replicación geográfica. Los grupos de nodos de Azure Kubernetes Service pueden usar Cluster Autoscaler para escalar los nodos hacia dentro y hacia fuera según los estados de pods pendientes e inactivos.

El dimensionamiento adecuado no es una actividad puntual. Las cargas de trabajo cambian con el tiempo: cambian los patrones de tráfico, se agregan funcionalidades y las bases de usuarios crecen o disminuyen. Incorpore una revisión mensual del dimensionamiento a su proceso de FinOps: obtenga las recomendaciones de Advisor, revise las 10 máquinas virtuales menos utilizadas y los servicios PaaS sobredimensionados, y cree elementos de trabajo para los equipos responsables. Realice un seguimiento de los ahorros obtenidos frente a las recomendaciones generadas para demostrar el retorno de inversión de FinOps a la dirección.

La estrategia de costes óptima consiste en ajustar primero el tamaño y reservar después. Comprar una Reserved VM Instance para una máquina virtual sobredimensionada le compromete con la SKU incorrecta. Ajuste primero la máquina virtual a su tamaño adecuado, observe la nueva utilización durante 30 días para confirmar su estabilidad y, después, compre una reserva para esa SKU dimensionada correctamente. Este enfoque en dos pasos maximiza el descuento y evita desperdiciar capacidad reservada.

Compruebe sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) de esta lección.

En esta lección ha aprendido que el dimensionamiento adecuado adapta las SKU de las máquinas virtuales a los requisitos reales de la carga de trabajo mediante métricas de rendimiento, que el escalado automático programado y basado en métricas ajusta dinámicamente la capacidad para adaptarse a la demanda y que las máquinas virtuales Spot ofrecen descuentos de hasta el 90 % para cargas de trabajo por lotes interrumpibles. A continuación, exploraremos Azure Savings Plans y las reservas para cargas de trabajo con compromiso.