Confiabilidad en Azure App Configuration

Azure App Configuration almacena y administra centralmente las opciones de configuración de la aplicación y las marcas de características, que reemplazan los archivos de configuración incrustados directamente dentro de las aplicaciones. Con este enfoque, puede actualizar dinámicamente los valores de configuración, realizar un seguimiento del historial de versiones y mantener un registro 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.

Al usar Azure, relibilidad es una responsabilidad compartida. Microsoft proporciona una variedad de capacidades para admitir resiliencia 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 App Configuration y cómo el servicio está diseñado para permanecer disponible durante errores transitorios, errores de zona de disponibilidad y interrupciones de región.

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:

Para obtener una lista de los procedimientos recomendados y la configuración de las cargas de trabajo de producción, consulte Compilación de aplicaciones que tienen 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 obtener más información, consulte ¿Qué es App Configuration?

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

Al crear aplicaciones cliente que se conectan a App Configuration, opcionalmente puede usar App Configuration con Azure Front Door (versión preliminar) para habilitar el 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 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 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 las rutas de acceso de código críticas.

• Proveedores de configuración: Use proveedores de App Configuration, que tienen integradas funcionalidades de reintento, almacenamiento en caché y otras capacidades de resiliencia.

• SDK de Azure: Utilice los SDK de App Configuration si su 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 utilizar proveedores o SDK de App Configuration. El retry-after-ms encabezado de la respuesta proporciona un tiempo de espera sugerido en milisegundos antes de que el cliente vuelva 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 App Configuration.

Resistencia a errores de zona de disponibilidad

Availability zones son grupos de centros de datos físicamente independientes 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 redundantes de zona.

Cost

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

Configurar soporte de zonas de disponibilidad

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

Si App Configuration agrega compatibilidad con zonas de disponibilidad a una región existente, no es necesario realizar ninguna acción para beneficiarse de la compatibilidad con la zona de disponibilidad. La tienda se beneficia de la compatibilidad con la zona de disponibilidad que está disponible para los almacenes de App Configuration en la región.

Comportamiento cuando todas las zonas están en buen estado

En esta sección describimos lo que puede esperar cuando tiene un almacén de App Configuration con redundancia de zona y todas las zonas están operativas.

• 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 dispone de un almacén de configuración de aplicaciones con redundancia de zona y se produce una interrupción en una de las zonas.

• 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.

• Notification: 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 no disponible anteriormente, 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 App Configuration gestiona el enrutamiento del tráfico, la conmutación ante fallos y la recuperación de zona para almacenes con redundancia de zona. Microsoft administra completamente este proceso, por lo que no es necesario validar los procesos de error de zona de disponibilidad.

Resistencia a errores en toda la región

App Configuration proporciona capacidades nativas de geo-replicación para admitir la resiliencia durante interrupciones regionales. La replicación geográfica permite que los datos de configuración se repliquen entre regiones como una característica de servicio administrado.

Replicación geográfica

Con la replicación geográfica, puede 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

• Region support: Puede crear réplicas en cualquier región de Azure compatible con 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 redundantes por zona: Cualquier réplica creada en una región donde App Configuration admita zonas de disponibilidad será automáticamente redundante por zona.

• 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. Los orígenes configurados correctamente son necesarios para que Azure Front Door realice el enrutamiento basado en la salud, 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 obtener más información sobre los precios, consulte Precios de 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 del sistema de nombres de dominio (DNS). Todas las réplicas pueden aceptar operaciones de lectura y escritura.

  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. Este enfoque 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 con detección automática de réplicas o una lista de varias réplicas, la aplicación detecta automáticamente errores y realiza una conmutación en caso de error a una réplica sana.

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

• Notification: 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: Las solicitudes activas contra una réplica en la región pueden fallar. 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 recupera 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 almacenamiento de datos y configura el grupo de origen con varias réplicas como orígenes para la conmutación por error, Azure Front Door vuelve a enrutar automáticamente las solicitudes a una réplica en buen estado.

Recuperación de regiones

Una vez que la región se recupera, App Configuration sincroniza la réplica con las demás réplicas sin intervención del usuario.

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 utilizan App Configuration reanudan automáticamente el uso de la réplica.

Prueba de fallos de región

No se puede simular una conmutación por error de réplica directamente 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 failover de réplica de su aplicación, puede introducir un error de conectividad controlado en un entorno de no producción y observar la respuesta de 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 exhaustivo para el SDK de Azure. En .NET, use la clase AzureEventSourceListener para configurar un registrador. Para obtener más información, vea el documento sobre supervisión y registro.

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 ejemplo 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

Puede usar App Configuration para 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: Al activar la eliminación temporal, puede recuperar almacenes y configuraciones eliminados durante un período de retención configurable. Las funciones de borrado suave actúan como una papelera de reciclaje para los recursos de App Configuration.

• Protección de purga: Al activar la protección de purga, el servicio 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 hace que el mantenimiento sea transparente y sin problemas. No se espera ningún tiempo de inactividad durante los eventos de mantenimiento a menos que Azure Service Health proporcione un aviso de mantenimiento planeado.

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 después de cualquier cambio 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 acuerdo de nivel de servicio (SLA) para Azure servicios describe la disponibilidad esperada de cada servicio y las condiciones que la solución debe cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, vea SLAs for servicios en línea.

Contenido relacionado

• Confiabilidad en Azure
• Documentación de Configuración de la aplicación