Compartir a través de

Confiabilidad en Azure App Service

  • Artículo

Este artículo describe el soporte de fiabilidad en Azure App Service, que cubre tanto la resistencia intrarregional con zonas de disponibilidad como la información sobre implementaciones multirregión.

La resistencia es una responsabilidad compartida entre usted y Microsoft, por lo que este artículo también cubre las formas en que usted puede crear una solución resistente que satisfaga sus necesidades.

Azure App Service es un servicio basado en HTTP para hospedar aplicaciones web, API REST y back-ends para dispositivos móviles. Azure App Service agrega a su aplicación capacidades potentes de Microsoft Azure, con funcionalidades de seguridad, equilibrio de carga, escalado automático y administración automatizada. Para explorar la manera en que Azure App Service puede aumentar la confiabilidad y la resistencia de la carga de trabajo de una aplicación, consulte ¿Por qué usar App Service?

Al implementar Azure App Service, puede crear varias instancias de un plan de App Service, que representa los trabajos de proceso que ejecutan el código de la aplicación. Aunque la plataforma realiza un esfuerzo para implementar las instancias en distintos dominios de error, no distribuye automáticamente las instancias entre zonas de disponibilidad.

Recomendaciones de implementación de producción

En el caso de las implementaciones de producción, debe:

Errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Se corrigen después de un breve período de tiempo. Es importante que las aplicaciones controlen errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure al comunicarse con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información sobre el control de errores transitorios, consulte Recomendaciones para el control de errores transitorios.

Aunque los SDK proporcionados por Microsoft suelen controlar los errores transitorios, dado que hospeda sus propias aplicaciones en Azure App Service, debe tener en cuenta cómo evitar causar errores transitorios asegurándose de que:

  • Implementar varias instancias del plan. Azure App Service realiza actualizaciones automatizadas y otras formas de mantenimiento en instancias del plan. Si una instancia se vuelve incorrecta, el servicio puede reemplazar automáticamente esa instancia por una nueva instancia correcta. Durante el proceso de reemplazo, puede haber un breve período de tiempo en el que la instancia anterior no esté disponible y la nueva instancia aún no esté lista para atender el tráfico. Puede mitigar el impacto de este comportamiento mediante la implementación de varias instancias del plan de App Service.

  • Uso de ranuras de implementación. Las ranuras de implementación de Azure App Service permiten implementaciones sin tiempo de inactividad de las aplicaciones. Use ranuras de implementación para minimizar el impacto de las implementaciones y los cambios de configuración en los usuarios. El uso de ranuras de implementación también reduce la probabilidad de que la aplicación se reinicie, lo que provoca un error transitorio.

  • Evite el escalado o la reducción verticales. En su lugar, seleccione un nivel y un tamaño de instancia que cumplan los requisitos de rendimiento bajo una carga típica. Solo las instancias de escalado horizontal para controlar los cambios en el volumen de tráfico. Tenga en cuenta que el escalado y la reducción verticales pueden desencadenar un reinicio de la aplicación.

Compatibilidad de zonas de disponibilidad

Las zonas de disponibilidad son grupos físicamente separados de centros de datos dentro de cada región de Azure. Cuando se produce un error en una zona, los servicios pueden conmutar por error a una de las zonas restantes.

Para más información sobre las zonas de disponibilidad en Azure, consulte ¿Qué son las zonas de disponibilidad?.

Azure App Service se puede configurar como redundante de zona, lo que significa que los recursos se distribuyen entre varias zonas de disponibilidad. La propagación entre varias zonas ayuda a las cargas de trabajo de producción a lograr resistencia y confiabilidad. El soporte de la zona de disponibilidad es una propiedad del plan de App Service.

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.

Cuando la plataforma App Service asigna instancias para un plan de App Service con redundancia de zona, usa el mejor esfuerzo de equilibrio de zona que ofrece la instancia de Azure Virtual Machine Scale Sets subyacente. Un plan de App Service se "equilibra" si cada zona tiene el mismo número de máquinas virtuales o +/- una máquina virtual en todas las demás zonas usadas por el plan de App Service.

En el caso de los planes de App Service que no están configurados como redundantes de zona, las instancias de máquina virtual no son resistentes a los errores de zona de disponibilidad. Pueden experimentar tiempo de inactividad durante una interrupción en cualquier zona de esa región.

Regiones admitidas

Debe usar los tipos de plan Premium v2 o Premium v3 para configurar la redundancia de zona.

  • Las zonas de disponibilidad solo se admiten en la superficie más reciente de App Service. Incluso si usa una de las regiones admitidas, recibirá un error si no se admiten zonas de disponibilidad para el grupo de recursos. Para asegurarse de que las cargas de trabajo se encuentren en una unidad de escalado que admita zonas de disponibilidad, es posible que tenga que crear un nuevo grupo de recursos, un plan de App Service y App Service.
  • Debe implementar un mínimo de tres instancias del plan.

Para ver qué regiones son compatibles con las zonas de disponibilidad de App Service Environment v3, consulta Regiones.

Requisitos

::: zone-end

  • Las zonas de disponibilidad solo se admiten en la superficie más reciente de App Service. Incluso si usa una de las regiones admitidas, recibirá un error si no se admiten zonas de disponibilidad para el grupo de recursos. Para asegurarse de que las cargas de trabajo se encuentren en una unidad de escalado que admita zonas de disponibilidad, es posible que tenga que crear un nuevo grupo de recursos, un plan de App Service y App Service.
  • Debe implementar un mínimo de tres instancias del plan.

Consideraciones

Las aplicaciones que se implementan en un plan de App Service con redundancia de zona siguen ejecutándose y atendiendo el tráfico incluso si varias zonas de la región sufren una interrupción. Pero es posible que los comportamientos que no sean de tiempo de ejecución, incluidos el escalado del plan de App Service y la creación, configuración y publicación de aplicaciones, se puedan ver afectados durante una interrupción de la zona de disponibilidad. La redundancia de zona para los planes de App Service solo garantiza un tiempo de actividad continuado para las aplicaciones implementadas.

Costos

Al usar planes de App Service Premium v2 o Premium v3, no hay ningún costo adicional asociado a la habilitación de zonas de disponibilidad siempre que tenga tres o más instancias en el plan de App Service. Se le cobrará en función de la SKU del plan de App Service, la capacidad que especifique y las instancias a las que escale en función de los criterios de escalado automático. Si habilita la disponibilidad de zonas, pero especifica una capacidad inferior a tres, la plataforma aplica un mínimo de tres instancias y le realiza un cargo por ellas.

App Service Environment v3 tiene un modelo de precios específico para la redundancia de zona. Para obtener información sobre los precios de App Service Environment v3, consulta Precios.

Configuración de la compatibilidad con zonas de disponibilidad

Para implementar un nuevo plan de Azure App Service con redundancia de zona, seleccione la opción Redundancia de zona al implementar el plan.

Para implementar una nueva instancia de Azure App Service Environment con redundancia de zona, consulte Crear una instancia de App Service Environment.

La redundancia de zona solo se puede configurar al crear un nuevo plan de App Service. Si tiene un plan de App Service existente que no es con redundancia de zona, debe reemplazarlo por un nuevo plan con redundancia de zona. No se puede convertir un plan de App Service existente para usar zonas de disponibilidad. Del mismo modo, no se puede deshabilitar la redundancia de zona en un plan de App Service existente.

Planeamiento y administración de capacidad

Para prepararse para los errores de zona de disponibilidad, debe sobreaprovisionar la capacidad del servicio para asegurarse de que la solución puede tolerar la pérdida de capacidad 1/3 y seguir funcionando sin degradar el rendimiento durante interrupciones en toda la zona. Como la plataforma distribuye las máquinas virtuales entre tres zonas y debe tener en cuenta al menos el error de una de ellas, multiplique el número máximo de instancias de carga de trabajo por un factor de zonas/(zonas-1) o 3/2. Por ejemplo, si la carga de trabajo máxima típica necesita cuatro instancias, debería aprovisionar seis instancias: (2/3 * 6 instancias) = 4 instancias.

Enrutamiento de tráfico entre zonas

Durante las operaciones normales, el tráfico se enruta entre todas las instancias de plan de App Service disponibles en todas las zonas de disponibilidad.

Experiencia de nivel de zona

Detección y respuesta: la plataforma de App Service es responsable de detectar un error en una zona de disponibilidad y responder. No es necesario hacer nada para iniciar una conmutación por error de zona.

Solicitudes activas: cuando una zona de disponibilidad no está disponible, cualquier solicitud en curso que esté conectada a una instancia de plan de App Service en la zona de disponibilidad defectuosa se cancela y debe volver a iniciarse.

Redireccionar tráfico: cuando una zona no está disponible, Azure App Service detecta las instancias perdidas de esa zona. Intenta buscar automáticamente nuevas instancias de reemplazo. A continuación, distribuye el tráfico entre las nuevas instancias según sea necesario.

Si tiene configurada la escalabilidad automática y esta determina que se necesitan más instancias, emite una solicitud a App Service para que agregue más instancias.

Nota:

El comportamiento de escalabilidad automática es independiente del comportamiento de la plataforma App Service. La especificación de recuento de instancias de escalado automático no necesita ser un múltiplo de tres.

Importante

No hay ninguna garantía de que las solicitudes de instancias adicionales en un escenario de zona descendente se realicen correctamente. El relleno de las instancias perdidas se produce de la mejor manera posible. Si necesita capacidad garantizada cuando se pierde una zona de disponibilidad, debe crear y configurar los planes de App Service para tener en cuenta la pérdida de una zona. Para ello, puede sobreaprovisionar la capacidad del plan de App Service.

Conmutación por recuperación

Cuando se recupera la zona de disponibilidad, Azure App Service crea automáticamente instancias en la zona de disponibilidad recuperada, quita las instancias temporales creadas en las otras zonas de disponibilidad y enruta el tráfico entre las instancias con normalidad.

Pruebas de errores de zona

La plataforma de Azure App Service administra el enrutamiento del tráfico, la conmutación por error y la conmutación por recuperación para planes de App Service con redundancia de zona. Dado que esta característica está totalmente administrada, no es necesario iniciar ni validar los procesos de error de zona de disponibilidad.

Compatibilidad con varias regiones

Azure App Service es un servicio de una sola región. Si la región deja de estar disponible, la aplicación tampoco está disponible.

Soluciones alternativas de varias regiones

Para garantizar que su aplicación sea menos susceptible a un error en una sola región, tendrá que implementar su aplicación en varias regiones. Para ello, siga estos pasos:

  • Implemente la aplicación en las instancias de cada región.
  • Configure directivas de equilibrio de carga y conmutación por error.
  • Replique los datos en las regiones para poder recuperar el último estado de la aplicación.

Para ver arquitecturas de ejemplo que ilustran este enfoque, consulte:

Para seguir un tutorial que crea una aplicación de varias regiones, consulte Tutorial: Crear una aplicación de varias regiones de alta disponibilidad en Azure App Service.

Para obtener un enfoque de ejemplo que ilustra esta arquitectura, consulte Implementación empresarial de alta disponibilidad mediante App Service Environment.

Copias de seguridad

Al usar el nivel Básico o superior, puede realizar una copia de seguridad de la aplicación de App Service en un archivo mediante las funcionalidades de copia de seguridad y restauración de App Service. Esta característica es útil si es difícil volver a implementar el código o si almacena el estado en el disco. Sin embargo, para la mayoría de las soluciones, no debe basarse en las copias de seguridad de App Service y, en su lugar, debe usar los otros métodos descritos en este artículo para admitir los requisitos de resistencia.

Acuerdo de Nivel de Servicio (SLA)

El acuerdo de nivel de servicio (SLA) para Azure App Service describe la disponibilidad esperada del servicio. También se describen las condiciones que se deben cumplir para lograr esa expectativa de disponibilidad. Para entender esas condiciones, es importante que revise los Acuerdos de Nivel de Servicio (SLA) para Servicios en Línea.

Al implementar un plan de App Service con redundancia de zona, aumenta el porcentaje de tiempo de actividad definido en el Acuerdo de Nivel de Servicio.

Contenido relacionado