Compartir a través de

Confiabilidad en Azure App Service

  • Artículo

En este artículo se describe la compatibilidad con la confiabilidad en Azure App Service. Abarca tanto la resistencia intrarregional con zonas de disponibilidad e información sobre las implementaciones de varias regiones.

La resistencia es una responsabilidad compartida entre usted y Microsoft. En este artículo también se tratan las formas de 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. Para más información, consulte Plan de Azure App Service. 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.

Los SDK proporcionados por Microsoft suelen controlar errores transitorios. Dado que hospeda sus propias aplicaciones en Azure App Service, considere cómo evitar la causa de 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 cuando la instancia anterior no está disponible y una 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 para los usuarios. El uso de ranuras de implementación también reduce la probabilidad de que se reinicie la aplicación. El reinicio 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. El escalado y la reducción vertical 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. Soporte con 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 mediante las siguientes reglas. Estas reglas se aplican incluso cuando la aplicación se escala y se reduce horizontalmente:

  • El recuento mínimo de instancias del plan de App Service es tres.
  • Las instancias se distribuyen uniformemente si especifica una capacidad mayor que tres y el número de instancias se puede dividir en tres.
  • 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 equilibrado si cada zona tiene el mismo número de máquinas virtuales, o más o menos una, en todas las demás zonas. Para obtener más información, consulte Equilibrio de zona.

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

Los planes de App Service con redundancia de zona se pueden implementar en cualquier región que admita zonas de disponibilidad.

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

Requisitos

  • Debe usar los tipos de plan Premium v2 o Premium v3.

  • Las zonas de disponibilidad solo se admiten en la superficie más reciente de App Service. Incluso si usa una de las regiones admitidas, si no se admiten zonas de disponibilidad para el grupo de recursos, recibirá un error. Para asegurarse de que las cargas de trabajo llegan a una marca 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. Es posible que los comportamientos que no se ejecuten se vean afectados durante una interrupción de zona de disponibilidad. Estos comportamientos incluyen el escalado del plan de App Service, la creación de aplicaciones, la configuración de la aplicación y la publicación de aplicaciones. 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 según los criterios de escalado automático.

Si habilita zonas de disponibilidad pero especifica una capacidad inferior a tres, la plataforma aplica un número mínimo de instancias de tres. La plataforma le cobra por esas tres instancias.

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, reemplácelo 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 el error de zona de disponibilidad, debe sobreaprovisionar la capacidad del servicio. Este enfoque garantiza que la solución puede tolerar una pérdida de capacidad de 1/3 y seguir funcionando sin degradar el rendimiento durante las interrupciones de toda la zona. Dado que la plataforma distribuye las máquinas virtuales entre tres zonas y debe tener en cuenta al menos el error de una zona, multiplique el número máximo de instancias de carga de trabajo por un factor de zones/(zones-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, se finalizan las solicitudes en curso conectadas a una instancia del plan de App Service en la zona de disponibilidad errónea. Deben reintentarse.

Redireccionar el 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. Para más información, consulte Escalado vertical de una aplicación en Azure App Service.

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 más instancias en un escenario de zona inactiva 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 asegurarse de que la aplicación sea menos susceptible a un error de una sola región, debe implementar la aplicación en varias regiones:

  • 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. Para obtener más información, consulte Copia de seguridad y restauración de la aplicación en Azure 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. Para la mayoría de las soluciones, no debe confiar en las copias de seguridad de App Service. Use 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 comprender esas condiciones, revise los Acuerdos de Nivel de Servicio (SLA) para Online Services.

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