Confiabilidad en Azure App Configuration

Azure App Configuration almacena y administra de forma centralizada las opciones de configuración de la aplicación y las marcas de características, reemplazando los archivos de configuración incrustados directamente dentro de las aplicaciones. Este enfoque permite las actualizaciones dinámicas, el control de versiones de los valores de configuración y el seguimiento histórico de los cambios de configuración a lo largo del tiempo. La disponibilidad y confiabilidad de App Configuration son consideraciones importantes porque el comportamiento de la aplicación puede depender directamente del acceso a los datos de configuración en tiempo de ejecución.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe la arquitectura de confiabilidad de Azure App Configuration y se explica cómo el servicio está diseñado para permanecer disponible durante errores transitorios, errores de zona de disponibilidad y interrupciones de regiones.

Recomendaciones de implementación de producción para la confiabilidad

Para la mayoría de las implementaciones de producción de App Configuration, tenga en cuenta las siguientes recomendaciones:

• SKU: Use la SKU Estándar o Premium.
• Eliminación temporal y protección de purga: Habilite la eliminación temporal y la protección de purga para protegerse contra la eliminación de datos.
• Para escenarios críticos: Use la SKU Premium y configure la réplica incluida para habilitar la replicación en varias regiones para mejorar la alta disponibilidad y la resistencia a las interrupciones de la región.

Para obtener una lista de los procedimientos recomendados y la configuración de las cargas de trabajo de producción, consulte Creación de aplicaciones con alta resistencia.

Introducción a la arquitectura de confiabilidad

Al implementar App Configuration, se implementa una tienda. Tu tienda contiene varios tipos de configuración que la aplicación puede usar, incluidas las claves y los valores, y las banderas de características. El servicio también incluye funcionalidades integradas para organizar, proteger, control de versiones y implementar de forma segura los cambios de configuración en todos los entornos. Para más información, consulte ¿Qué es Azure App Configuration?

App Configuration es un servicio totalmente administrado. Microsoft es responsable de almacenar y administrar la configuración, así como realizar el mantenimiento en el servicio.

Al desarrollar aplicaciones cliente que se conectan a Azure App Configuration, puede opcionalmente usar App Configuration con Azure Front Door (previa) para habilitar el almacenamiento en caché y la aceleración global del tráfico. Esta configuración presenta otras consideraciones para la replicación geográfica, que se resaltan en este artículo cuando corresponda.

Resistencia a 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. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar 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 cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Al usar Azure App Configuration, tenga en cuenta los siguientes procedimientos recomendados para minimizar el efecto de los errores transitorios en el acceso a la configuración, especialmente dentro de rutas de acceso de código críticas.

• Proveedores de configuración: Use los proveedores de configuración de App Configuration, que tienen funcionalidades integradas de reintentos y almacenamiento en caché, junto con muchas otras características de resistencia.
• SDKs de Azure: Utiliza los SDKs de App Configuration si la aplicación necesita enviar solicitudes de escritura. Los SDKs reintentan automáticamente en las respuestas de código de estado HTTP 429 y otros errores transitorios.
• Lógica de reintento: Incluya lógica de reintento en clientes personalizados si no puede usar App Configuration Providers o SDKs. El retry-after-ms encabezado de la respuesta proporciona un tiempo de espera sugerido en milisegundos antes de volver a intentar la solicitud.
• Almacenamiento en caché: Configure los ajustes de caché en la memoria cuando sea posible para reducir las solicitudes directas a su tienda.

Para obtener otras instrucciones de configuración de aplicaciones, consulte Preguntas más frecuentes sobre Azure App Configuration.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

App Configuration proporciona automáticamente redundancia de zona en regiones que admiten zonas de disponibilidad. Esta redundancia proporciona alta disponibilidad dentro de una región sin necesidad de ninguna configuración específica.

Cuando una zona de disponibilidad deja de estar disponible, App Configuration redirige automáticamente las solicitudes a otras zonas de disponibilidad correctas para garantizar una alta disponibilidad.

Requisitos

Compatibilidad con regiones: Los almacenes implementados en las siguientes regiones son automáticamente con redundancia de zona:

Americas	Europa	Oriente Medio	África	Asia Pacífico
Sur de Brasil	Centro de Francia	Israel Central		Australia East
Canada Central	Centro-oeste de Alemania	Qatar Central		Centro de la India
Central US	Norte de Italia	Norte de Emiratos Árabes Unidos		Norte de China 3
East US	Norte de Europa			Este de Asia
Este de EE. UU. 2	Norway East			Japón Oriental
Centro de México	Centro de Polonia			Centro de Corea del Sur
Centro-sur de EE. UU.	Centro de España			Sudeste de Asia
Gobierno de EE. UU. - Virginia	Centro de Suecia
Oeste de EE. UU. 2	Norte de Suiza
Oeste de EE. UU. 3	Sur de Reino Unido
	Oeste de Europa

Cost

No hay ningún costo adicional para la redundancia de zona para Azure App Configuration.

Configurar soporte de zonas de disponibilidad

Microsoft habilita automáticamente la redundancia de zona para un almacén cuando se encuentra en una región que admite zonas de disponibilidad.

Si App Configuration agrega compatibilidad con zonas de disponibilidad a una región existente, no es necesario hacer nada para empezar a beneficiarse de la compatibilidad con la zona de disponibilidad. Su tienda se beneficiará de la compatibilidad con las zonas de disponibilidad que se ha puesto a disposición para las tiendas de App Configuration en la región.

Comportamiento cuando todas las zonas están en buen estado

Cuando un almacén está en una región que admite redundancia de zona y todas las zonas de disponibilidad están operativas, puede esperar el siguiente comportamiento:

• Operación entre zonas: App Configuration administra automáticamente el enrutamiento de tráfico entre zonas de disponibilidad. Durante las operaciones normales, distribuye de forma transparente las solicitudes entre zonas.

• Replicación de datos entre zonas: En las regiones que admiten zonas, App Configuration replica de forma sincrónica los datos entre zonas de disponibilidad. Esta replicación garantiza que la configuración siga siendo coherente y disponible incluso si una zona deja de estar disponible.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando un almacén está en una región que admite redundancia de zona y una zona de disponibilidad no está disponible:

• Detección y respuesta: El servicio App Configuration detecta errores de zona y responde automáticamente a ellos. No es necesario realizar ninguna acción ante un fallo de zona.

• Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

• Solicitudes activas: durante un error de zona, es posible que la zona afectada no controle las solicitudes en curso, lo que requiere que las aplicaciones cliente vuelvan a intentarlas. Las aplicaciones cliente deben seguir los procedimientos transitorios de control de errores para asegurarse de que pueden reintentar solicitudes si se produce un error de zona.

• Pérdida de datos esperada: No se espera ninguna pérdida de datos durante un error de zona debido a la replicación sincrónica entre zonas.

• Tiempo de inactividad esperado: No se espera ningún tiempo de inactividad.

• Redistribución: App Configuration vuelve a enrutar automáticamente el tráfico de la zona afectada a zonas correctas sin necesidad de intervención del cliente.

Recuperación de zona

Cuando se recupera una zona que antes no estaba disponible, App Configuration restaura automáticamente las operaciones normales en todas las zonas de disponibilidad. No es necesario realizar ninguna acción para recuperar de una falla de zona.

Prueba de fallos de zona

La plataforma Azure App Configuration administra el enrutamiento del tráfico, la conmutación por error y la recuperación de zona para almacenes con redundancia de zona. Dado que Microsoft administra completamente este proceso, no es necesario validar los procesos de error de zona de disponibilidad.

Resistencia a errores en toda la región

Azure App Configuration proporciona funcionalidades nativas de replicación geográfica para admitir la resiliencia durante interrupciones regionales. La replicación geográfica permite replicar los datos de configuración entre regiones como una característica de servicio administrado.

Replicación geográfica

La replicación geográfica permite replicar un almacén en varias regiones de Azure. Cada almacén puede tener varias réplicas en regiones diferentes. El almacén original también es una réplica. Esta funcionalidad ayuda a proteger las aplicaciones frente a interrupciones en toda la región.

Requisitos

• Compatibilidad con regiones: Puede crear réplicas en cualquier región de Azure compatible con Azure App Configuration, incluso si las regiones no son regiones emparejadas de Azure.

• Nivel: El almacén de configuración debe usar un nivel admitido para habilitar la replicación geográfica. Para obtener más información, consulte Habilitación de la replicación geográfica.

Consideraciones

Al habilitar la replicación geográfica, tenga en cuenta los siguientes factores:

• Réplicas con redundancia de zona: Cualquier réplica que cree en una región en la que App Configuration admita zonas de disponibilidad es automáticamente redundante por zonas.

• Azure Front Door: Para habilitar la entrega de configuración con redundancia geográfica con Azure Front Door, configure réplicas de App Configuration como orígenes dentro de un grupo de origen. La configuración de origen correcta permite a Azure Front Door administrar el enrutamiento basado en el estado, el equilibrio de carga y la conmutación automática por error entre regiones. Para obtener más información, consulte Métodos de enrutamiento del tráfico al origen.

Cost

Cada región con replicación geográfica se factura por separado según los precios del plan y la región correspondientes. No se aplican cargos de salida de datos para la replicación entre regiones. Para más información sobre los precios, consulte Precios de Azure App Configuration.

Configuración de la compatibilidad con varias regiones

Para configurar la replicación para un almacén de configuración recién creado, consulte Habilitación de la replicación geográfica.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar al configurar un almacén de App Configuration para la replicación geográfica y todas las regiones están operativas.

• Operación entre zonas: Cada réplica es direccionable individualmente y tiene su propio nombre DNS. Todas las réplicas pueden aceptar operaciones de lectura y escritura.

  Azure App Configuration no enruta automáticamente el tráfico entre regiones. Cuando se usan proveedores de configuración de App Configuration, la aplicación puede usar opcionalmente la detección automática de réplicas. Alternativamente, puede especificar una lista priorizada de réplicas, y App Configuration selecciona la primera réplica saludable. Esto permite a la aplicación controlar qué réplica usa.

  Nota:

  Si usa Azure Front Door, el comportamiento del enrutamiento del tráfico es diferente. Para obtener más información, consulte Conmutación por error y equilibrio de carga.

• Replicación de datos entre zonas: Los datos se replican de forma asincrónica y finalmente son coherentes. Puede usar la métrica de latencia de replicación en Azure Monitor para supervisar la latencia de replicación actual entre réplicas.

Comportamiento durante una falla de región

En esta sección se describe qué se puede esperar al configurar una tienda de configuración de aplicaciones para la replicación geográfica, y cuando se produce una interrupción en una de las regiones de réplica.

• Detección y respuesta: Microsoft es responsable de detectar errores de región o réplica e iniciar procesos de recuperación.

  Cuando se usan proveedores de configuración de App Configuration y se realiza la detección automática de réplicas o con una lista de varias réplicas, la aplicación conmuta automáticamente por error a otra réplica correcta.

  Si no usa proveedores de App Configuration, es responsable de cambiar su aplicación a una réplica saludable.

• Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.

• Solicitudes activas: Es posible que las solicitudes activas contra una réplica en la región se descarten. Las aplicaciones cliente deben reintentar las solicitudes en una réplica diferente.

• Pérdida de datos esperada: Si se produce un error en una réplica, es posible que los cambios recientes realizados en esa réplica aún no se repliquen en otras réplicas. Esos cambios pueden permanecer no disponibles hasta que se recupere la réplica. Para calcular la posible pérdida de datos, supervise la métrica de latencia de replicación en Azure Monitor.

• Tiempo de inactividad esperado: Cuando una réplica deja de estar disponible, permanece sin conexión hasta que se recupere su región. Otras réplicas siguen gestionando las solicitudes. Las aplicaciones pueden experimentar un breve tiempo de inactividad mientras detectan el error y cambian a una réplica correcta. La duración depende de la rapidez con la que cada aplicación realiza esta detección y conmutación por error.

• Redistribución: Las aplicaciones deben enrutar el tráfico a una réplica saludable cuando se produce un error.

  Si utiliza proveedores de configuración de App Configuration, estos gestionan automáticamente la selección de réplica y la conmutación por error.

  Si coloca Azure Front Door delante del almacén de datos y configura el grupo de origen con varias réplicas como orígenes para la conmutación de fallos, Azure Front Door redirige automáticamente las solicitudes a una réplica saludable.

Recuperación de regiones

Una vez recuperada la región, App Configuration sincroniza de nuevo las réplicas con las otras, sin su intervención.

Usted es responsable de volver a configurar su aplicación para enrutar el tráfico de regreso a la instancia de la región recuperada. Las aplicaciones que usan proveedores de App Configuration empiezan a usar automáticamente la réplica de nuevo.

Prueba de fallos de región

Actualmente no se puede simular directamente una conmutación por error de réplica en App Configuration. Sin embargo, dado que las aplicaciones controlan la selección de réplica, puede probar el comportamiento de la conmutación por error forzando la aplicación a un estado en el que debe cambiar las réplicas.

Para validar el comportamiento de conmutación por error de la réplica de su aplicación, puede provocar un fallo de conectividad controlado en un entorno que no sea de producción y observar cómo responde la aplicación.

Un enfoque consiste en usar la máquina local u otro entorno en el que tenga acceso administrativo. Siga estos pasos:

1. Active el registro detallado para el SDK de Azure. En .NET, use la AzureEventSourceListener clase para configurar un registrador. Para obtener más información, consulte Tutorial: Uso de la configuración dinámica en una aplicación .NET: registro y supervisión.

2. Configure manualmente el hosts archivo para que las solicitudes al almacén de App Configuration se enruten a una dirección IP que no pueda recibirlos, como 127.0.0.1 (localhost).

   Advertencia

   Este paso bloquea eficazmente el acceso desde tu equipo a tu almacén de Configuración de la Aplicación. Siga estos pasos solo en un entorno que no sea de producción.

3. Supervise los registros de un mensaje similar al siguiente:

   [Warning] Microsoft-Extensions-Configuration-AzureAppConfiguration-Refresh:
   Failed to get configuration settings from endpoint 'https://myappconfigstore.azconfig.io'. Failing over to endpoint https://myappconfigstore-eus.azconfig.io'.
   

   Este mensaje indica que la aplicación conmutó con éxito para usar otra réplica de su almacén.

4. Después de completar la prueba, deshaga los cambios en el archivo hosts.

Copias de seguridad y restauración

Azure App Configuration permite exportar datos de configuración desde un almacén y usarlos como parte de una estrategia de copia de seguridad más amplia.

Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para más información, consulte ¿Qué son la redundancia, la replicación y la copia de seguridad?.

Resistencia a la eliminación accidental

App Configuration proporciona dos características clave de recuperación para evitar la eliminación accidental o malintencionada:

• Eliminación temporal: Cuando se habilita, la eliminación temporal permite recuperar almacenes y configuraciones eliminados durante un período de retención configurable. Piensa en la eliminación reversible como una papelera de reciclaje para los recursos de App Configuration.

• Protección de purga: Cuando está habilitada, la protección de purga evita la eliminación permanente del almacén y su configuración hasta que transcurre el período de retención. Esta protección evita que los actores malintencionados destruyan permanentemente la configuración.

Use ambas características para entornos de producción. Para más información, consulte Eliminación temporal y protección contra purgas.

Resistencia al mantenimiento del servicio

Microsoft realiza periódicamente actualizaciones de servicio y otro mantenimiento. El servicio controla estas actividades automáticamente, lo que garantiza que el mantenimiento sea sin problemas y transparente para usted. No se espera ningún tiempo de inactividad durante los eventos de mantenimiento a menos que se le haya informado a través del mantenimiento planeado de Azure Service Health.

Resistencia a problemas de configuración

Los cambios de configuración incorrectos o accidentales pueden provocar tiempo de inactividad de la aplicación. Utiliza instantáneas de configuración para desplegar los cambios en la configuración de forma segura. Supervise el estado de la aplicación siguiendo los cambios de configuración y vuelva a la última instantánea de configuración correcta conocida si los cambios presentan un problema.

Acuerdo de nivel de servicio

El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Contenido relacionado

• Confiabilidad en Azure
• Documentación de Azure App Configuration