Volver al curso: Azure Professional Training 2024: Fundamentos
Escalabilidad y disponibilidad no son lo mismo: ya hemos estudiado estos conceptos en secciones anteriores de este curso. Llegó el momento de implementarlos en Azure App Service.
Escalabilidad en Azure App Service Plans
Un Azure App Service Plan se puede escalar de dos maneras:
- Verticalmente: en este tipo de escalabilidad, se aumenta la capacidad de la instancia de la máquina virtual subyacente en términos de CPU, RAM, o potencia de procesamiento. Es como mejorar el rendimiento de una sola máquina. Esta opción es adecuada cuando se necesita un aumento inmediato en los recursos disponibles, pero puede resultar costosa a largo plazo..
- Horizontalmente: aquí, en lugar de aumentar los recursos de una sola instancia, se agregan instancias adicionales del App Service Plan. Cada instancia adicional trabaja en paralelo con las otras, distribuyendo la carga de trabajo y mejorando la capacidad de manejar un mayor número de solicitudes simultáneas. Este enfoque es más escalable y económico a largo plazo, ya que permite adaptarse fácilmente a picos de tráfico sin comprometer el rendimiento..
Es importante mencionar que cuando se escala un App Service Plan de manera vertical, se incrementa su precio, ya que se pagan tarifas más altas por recursos adicionales. En cambio, cuando se escala horizontalmente, se paga por cada instancia adicional, y este escalado afecta a TODAS las aplicaciones web dentro del mismo plan.
Compatibilidad con Zonas de Disponibilidad
Las zonas de disponibilidad de Azure son al menos tres grupos de centros de datos físicamente independientes dentro de cada región de Azure. Los centros de datos de cada zona están equipados con infraestructura de alimentación, refrigeración y red independientes. En el caso de un error en la zona local, las zonas de disponibilidad están diseñadas de manera que, si se ve afectada una zona, los servicios, la capacidad y la alta disponibilidad regionales serán proporcionadas por las dos zonas restantes.
Azure App Service se puede implementar en zonas de disponibilidad (AZ) para poder lograr resistencia y confiabilidad en las cargas de trabajo críticas para la empresa. Esta arquitectura también se conoce como redundancia de zona.
Al configurar App Service para que tenga redundancia de zona, la plataforma propaga automáticamente las instancias del plan de Azure App Service entre las tres zonas de la región seleccionada.
La propagación de instancias con una implementación con redundancia de zona se determina dentro de las reglas siguientes, incluso cuando la aplicación se escala y se reduce horizontalmente:
- El recuento mínimo de instancias del plan de App Service es tres.
- Si se especifica una capacidad superior a tres y el número de instancias es divisible entre tres, las instancias se distribuyen de manera uniforme.
- Cualquier recuento de instancias más allá de 3*N se distribuye entre las dos zonas restantes.
- El soporte de la zona de disponibilidad es una propiedad del plan de App Service. Los planes de App Service se pueden crear en un entorno multiinquilino administrado o en un entorno dedicado mediante App Service Environment v3.
En el caso de App Services que no están configurados para que sean redundantes de zona, las instancias de máquina virtual no son resistentes a la zona y pueden experimentar tiempo de inactividad durante una interrupción en cualquier zona de esa región.
IMPORTANTE: Las zonas de disponibilidad en un App Service Plan solo se pueden especificar al crear un nuevo plan de App Service. Un plan de App Service existente no se puede convertir para que use zonas de disponibilidad.
Disponibilidad de Azure App Service
Sobre los niveles de servicio, Microsoft actualmente no hace una distinción si el plan es redundante en zona o no:
- Microsoft garantiza que Azure App Service estará disponible un 99.95% del tiempo, lo que significa que el servicio experimentará un tiempo de inactividad máximo de solo 22 minutos al mes.
- Este Acuerdo de Nivel de Servicio (SLA) se respalda tanto cuando se ejecuta en una sola instancia como cuando se utiliza con múltiples instancias para proporcionar redundancia y tolerancia a fallos.
Sin embargo, es importante tener en cuenta que no se proporciona ningún Acuerdo de Nivel de Servicio en los niveles Gratis ni Compartido. Esos niveles pueden ser útiles para entornos de desarrollo y pruebas, pero no ofrecen garantías de disponibilidad para aplicaciones en producción.
