Análisis del modo de error para aplicaciones de Azure

El análisis del modo de error (FMA) es un proceso para crear confiabilidad en un sistema mediante la identificación de posibles puntos de error. La FMA debe formar parte de las fases de arquitectura y diseño, de modo que pueda crear resistencia (la capacidad de resistir errores) y capacidad de recuperación (la capacidad de restaurar la funcionalidad después de errores) en el sistema desde el principio.

Este es el proceso general para realizar un FMA:

1. Identifique todos los componentes del sistema. Incluya dependencias externas, como proveedores de identidades y servicios de terceros.

2. Para cada componente, identifique los posibles errores que se puedan producir. Un único componente puede tener más de un modo de error. Por ejemplo, debería considerar los errores de lectura y escritura por separado, ya que el impacto y los posibles pasos de mitigación serán diferentes.

3. Clasifique por orden de prioridad cada modo de error según su riesgo general. Tenga en cuenta estos factores:

   • ¿Cuál es la probabilidad de que se produzca el error? ¿Es relativamente frecuente? ¿Extremadamente poco común? No necesita números exactos, ya que la finalidad es realizar una clasificación por orden de prioridad.
   • ¿Cuál es el impacto en la aplicación, en términos de disponibilidad, pérdida de datos, costo económico e interrupción de la actividad comercial?

4. Para cada modo de error, determine cómo responderá y se recuperará la aplicación. Tenga en cuenta los inconvenientes en lo relativo al costo y a la complejidad de la aplicación.

Como punto de partida para el proceso FMA, este artículo contiene un catálogo de los posibles modos de error y los pasos de mitigación. El catálogo está organizado por tecnología o servicio de Azure, además de una categoría general para el diseño en el nivel de aplicación. El catálogo no es exhaustivo, pero cubre muchos de los servicios principales de Azure.

Microsoft Entra ID

Errores de autenticación de OpenID Connect.

Detección. Los posibles modos de error son:

1. Microsoft Entra ID no está disponible o no se puede acceder a él debido a un problema de red. Se produce un error en el redireccionamiento al punto de conexión de autenticación y el middleware de OpenID Connect genera una excepción.
2. El inquilino de Microsoft Entra no existe. El redireccionamiento al punto de conexión de autenticación devuelve un código de error HTTP y el middleware de OpenID Connect genera una excepción.
3. El usuario no se puede autenticar. No es necesaria ninguna estrategia de detección; Microsoft Entra ID controla los errores de inicio de sesión.

Recuperación:

1. Detecte las excepciones no controladas en el middleware.
2. Gestione eventos AuthenticationFailed.
3. Redireccione al usuario a una página de error.
4. El usuario lo reintenta.

Casandra

Se produce un error al leer o escribir en un nodo.

Detección. Detecte la excepción. Para clientes. NET, suele ser System.Web.HttpException. Otro cliente puede tener otros tipos de excepción. Para más información, consulte El manejo correcto de errores en Cassandra.

Recuperación:

• Cada cliente de Cassandra tiene sus propias directivas y funcionalidades de reintento. Para más información, consulte El manejo correcto de errores en Cassandra.
• Use una implementación en modo compatible con bastidor, con nodos de datos distribuidos a través de los dominios de error.
• Implemente en varias regiones con coherencia de cuórum local. Si se produce un error no transitorio, conmute por error a otra región.

Diagnóstico. Registros de aplicación

Almacenamiento en cola

Se produce un error al escribir un mensaje en Azure Queue Storage constantemente.

Detección. Después de N reintentos, todavía se produce un error en la operación de escritura.

Recuperación:

• Almacene los datos en una memoria caché local y reenvíe las escrituras al almacenamiento más adelante, cuando el servicio esté disponible.
• Cree una cola secundaria y escriba en esa cola si la cola principal no está disponible.

Diagnóstico. Use las métricas de almacenamiento.

La aplicación no puede procesar un mensaje concreto de la cola.

Detección. Específica de la aplicación. Por ejemplo, el mensaje contiene datos no válidos o se produce un error en la lógica de negocios por algún motivo.

Recuperación:

Mueva el mensaje a una cola independiente. Ejecute un proceso independiente para examinar los mensajes de dicha cola.

Considere la posibilidad de usar colas de mensajería de Azure Service Bus, lo que proporciona una funcionalidad de cola de mensajes fallidos con este fin.

Diagnóstico. Utilice el registro de aplicaciones.

Base de datos SQL

No se puede conectar a la base de datos en la región primaria.

Detección. Se produce un error de conexión.

Recuperación:

• Habilitación de la redundancia de zona. Al habilitar la redundancia de zona, Azure SQL Database replicará automáticamente las escrituras en varias zonas de disponibilidad de Azure dentro de las regiones admitidas. Para obtener más información, consulte Disponibilidad con redundancia de zona.

• Habilite la replicación geográfica. Si va a diseñar una solución de varias regiones, considere la posibilidad de habilitar la replicación geográfica activa de SQL Database.

  Requisito previo: la base de datos debe configurarse para una replicación geográfica activa. Consulte Replicación geográfica activa de SQL Database.

  • Para consultas, lea desde una réplica secundaria.
  • Para inserciones y actualizaciones, conmute por error manualmente a una réplica secundaria. Consulte Inicio de una conmutación por error planeada o no planeada para Azure SQL Database.

  La réplica usa una cadena de conexión diferente, por lo que deberá actualizar la cadena de conexión en la aplicación.

El cliente se ha quedado sin conexiones en el grupo de conexiones.

Detección. Detecte errores System.InvalidOperationException.

Recuperación:

• Vuelva a intentar la operación.
• Como plan de mitigación, aísle los grupos de conexiones para cada caso de uso, a fin de que un solo caso de uso no pueda dominar todas las conexiones.
• Aumente el número máximo de conexiones.

Diagnóstico. Registros de aplicaciones.

Se alcanzó el límite de conexiones de base de datos.

Detección. Azure SQL Database limita el número de trabajos, inicios de sesión y sesiones simultáneos. Los límites dependen del nivel de servicio. Para más información, consulte Límites de recursos de Azure SQL Database.

Para detectar estos errores, detecte System.Data.SqlClient.SqlException y compruebe el valor de SqlException.Number para el código de error SQL. Para obtener una lista de los códigos de error pertinentes, consulte Códigos de error de SQL para aplicaciones cliente de SQL Database: Errores de conexión de base de datos y otros problemas.

Recuperación. Estos errores se consideran transitorios, por lo que el reintento podría resolver el problema. Si se producen constantemente estos errores, considere la posibilidad de escalar la base de datos.

Diagnóstico. - La consulta sys.event_log devuelve las conexiones realizadas correctamente, los errores de conexión y los interbloqueos.

• Cree una regla de alertas para las conexiones erróneas.
• Habilite la auditoría de SQL Database y compruebe si hay inicios de sesión erróneos.

Mensajería de Service Bus

Se produce un error al leer un mensaje de una cola de Service Bus.

Detección. Detecte excepciones desde el cliente SDK. La clase base para las excepciones de Service Bus es MessagingException. Si el error es transitorio, la propiedad IsTransient es true.

Para más información, consulte Excepciones de mensajería de Service Bus.

Recuperación:

1. Reinténtelo con los errores transitorios.
2. Los mensajes que no se pueden entregar a ningún receptor se colocan en una cola de mensajes no entregados. Use esta cola para ver qué mensajes no se pudieron recibir. No hay limpieza automática de la cola de mensajes fallidos. Los mensajes permanecen allí hasta que los recupere explícitamente. Consulte la Información general de colas de mensajes fallidos de Service Bus.

Se produce un error al intentar escribir un mensaje en una cola de Service Bus.

Detección. Detecte excepciones desde el cliente SDK. La clase base para las excepciones de Service Bus es MessagingException. Si el error es transitorio, la propiedad IsTransient es true.

Para más información, consulte Excepciones de mensajería de Service Bus.

Recuperación:

• El cliente de Service Bus realiza reintentos automáticamente tras los errores transitorios. De forma predeterminada, usa el retroceso exponencial. Tras el período de tiempo de expiración máximo o el número máximo de reintentos, el cliente genera una excepción.

• Si se supera la cuota de la cola, el cliente devuelve una QuotaExceededException. El mensaje de excepción proporciona más detalles. Purgue algunos mensajes de la cola antes de reintentarlo y considere la posibilidad de usar el patrón Circuit Breaker para evitar reintentos continuos mientras se supera la cuota. Además, asegúrese de que la propiedad BrokeredMessage.TimeToLive no esté establecida demasiado alta.

• Dentro de una región, se puede mejorar la resistencia mediante temas o colas con particiones. Se asigna una cola o un tema sin particiones a un almacén de mensajería. Si este almacén de mensajería no está disponible, se producirá un error en todas las operaciones de esa cola o tema. Una cola o tema con particiones está particionado entre varios almacenes de mensajería.

• Use la redundancia de zona para replicar automáticamente los cambios entre varias zonas de disponibilidad. Si se produce un error en una zona de disponibilidad, la conmutación por error se producirá automáticamente. Para más información, consulte Procedimientos recomendados para aislar aplicaciones ante desastres e interrupciones de Service Bus.

• Si va a diseñar una solución multirregional, cree dos espacios de nombres de Service Bus en regiones diferentes y replique los mensajes. Puede usar una replicación activa o pasiva.

  • Replicación activa: el cliente envía todos los mensajes a ambas colas. El receptor escucha en ambas colas. Etiquete los mensajes con un identificador único, para que el cliente pueda descartar los mensajes duplicados.
  • Replicación pasiva: el cliente envía el mensaje a una cola. Si se produce un error, el cliente vuelve a la otra cola. El receptor escucha en ambas colas. Este enfoque reduce el número de mensajes duplicados que se envían. Sin embargo, el receptor todavía debe controlar los mensajes duplicados.

  Para más información, consulte el ejemplo de GeoReplication y los Procedimientos recomendados para aislar aplicaciones ante desastres e interrupciones de Service Bus.

Mensaje duplicado.

Detección. Examine las propiedades MessageId y DeliveryCount del mensaje.

Recuperación:

• Si es posible, diseñe las operaciones de procesamiento de mensajes para que sean idempotentes. En caso contrario, almacene identificadores de mensaje de los mensajes que ya se han procesado y compruebe el identificador antes de procesar un mensaje.

• Habilite la detección de duplicados, mediante la creación de la cola con RequiresDuplicateDetection establecido en true. Con este valor, Service Bus elimina automáticamente cualquier mensaje que se envíe con el mismo MessageId que un mensaje anterior. Tenga en cuenta los siguientes puntos:

  • Este valor impide que se pongan en la cola mensajes duplicados. No impide que un receptor procese el mismo mensaje más de una vez.
  • La detección de duplicados tiene un período de tiempo. Si se envía un duplicado más allá de este período, no se detectará.

Diagnóstico. Registre mensajes duplicados.

La aplicación no puede procesar un mensaje concreto de la cola.

Detección. Específica de la aplicación. Por ejemplo, el mensaje contiene datos no válidos o se produce un error en la lógica de negocios por algún motivo.

Recuperación:

Hay dos modos de error que se deben tener en cuenta.

• El receptor detecta el error. En este caso, mueva el mensaje a la cola de mensajes fallidos. Posteriormente, ejecute un proceso independiente para examinar los mensajes de la cola de mensajes fallidos.
• Se produce un error en el receptor en medio del procesamiento del mensaje; por ejemplo, debido a una excepción no controlada. Para controlar este caso, utilice el modo PeekLock. En este modo, si expira el bloqueo, el mensaje pasa a estar disponible para otros receptores. Si el mensaje supera el número máximo de entregas o el período de vida, el mensaje se mueve automáticamente a la cola de mensajes muertos.

Para más información, consulte Introducción a las colas de mensajes fallidos de Service Bus.

Diagnóstico. Siempre que la aplicación mueva un mensaje a la cola de mensajes fallidos, escribe un evento en los registros de aplicaciones.

Pasos siguientes

Consulte Identificación de dependencias en Azure Well-Architected Framework. Programar la recuperación de errores en el sistema debe formar parte de las fases de arquitectura y diseño desde el principio para evitar el riesgo de que se produzcan errores.