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 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 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: Utiliza proveedores de configuración de aplicaciones, que cuentan con capacidades integradas de reintento y almacenamiento en caché, así como otras características de resiliencia.

• SDK de Azure: Utilice los SDK de App Configuration si su aplicación necesita enviar solicitudes de escritura. Los SDK reintentan automáticamente ante respuestas con el código de estado HTTP 429 y otros errores transitorios.

• Lógica de reintento: Incluye lógica de reintento en los clientes personalizados si no puedes utilizar proveedores de configuración de aplicaciones o SDK. 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 mediante la distribución de cada almacén entre varias zonas de disponibilidad 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.

En el diagrama siguiente se muestra un ejemplo de cómo App Configuration podría proporcionar redundancia de zona en una región con tres zonas de disponibilidad:

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. Tu almacén se beneficia de la compatibilidad con zonas de disponibilidad que está disponible para los almacenes de configuración de aplicaciones en la región.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué cabe esperar cuando se dispone de un almacén de configuración de aplicaciones con redundancia por zonas 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é cabe esperar cuando se utiliza un almacén de configuración de aplicaciones con redundancia por zonas y se produce una interrupción del servicio 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 redirige automáticamente el tráfico de la zona afectada a zonas en buen estado sin necesidad de intervención por parte del cliente.

Recuperación de zona

Cuando se recupera una zona no disponible anteriormente, App Configuration restaura automáticamente las operaciones normales con redundancia de zona para el almacén. 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 replicación geográfica para garantizar la resiliencia durante las interrupciones en la región. 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. Se requieren orígenes configurados correctamente para que Azure Front Door realice el enrutamiento basado en el estado, el equilibrio de carga y la conmutación por error automática 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 regiones: 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 regiones: 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 utilizan 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 los fallos y realiza la conmutación por error a una réplica en buen estado.

  Si no se utilizan proveedores de App Configuration, el cliente es responsable de cambiar la aplicación a una réplica en buen estado.

• 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. Las demás réplicas siguen administrando 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 realice 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 se encargan automáticamente de la selección de réplicas y de la conmutación por error.

  Si coloca Azure Front Door delante de su almacén de datos y configura el grupo de origen con varias réplicas como orígenes para la conmutación por error, Azure Front Door redirige 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 es posible simular directamente una conmutación por error de una réplica en la configuración de la aplicación. Sin embargo, dado que las aplicaciones controlan la selección de réplicas, puedes probar el comportamiento de la conmutación por error forzando a la aplicación a un estado en el que deba cambiar de réplica.

Para validar el comportamiento de la conmutación por error de las réplicas de tu aplicación, puedes 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 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 ha realizado correctamente la conmutación por error para utilizar 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.

Las réplicas mejoran la disponibilidad, pero no proporcionan un punto de recuperación histórico para cambios o eliminaciones de configuración no deseados. Una exportación proporciona una copia independiente que puede restaurar. Para obtener más información, consulte Redundancia, replicación y 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 obtener más información, consulte Protección contra la eliminación temporal y la purga.

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