Confiabilidad en Azure Event Grid

Azure Event Grid es un servicio de mensajería totalmente administrado que permite la comunicación basada en eventos entre servicios y aplicaciones. Normalmente se usa para crear arquitecturas controladas por eventos e integrar servicios de Azure con aplicaciones personalizadas.

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 cómo hacer que Event Grid sea resistente a varias posibles interrupciones y problemas, incluidos errores transitorios, errores de zona de disponibilidad y errores en toda la región. También resalta información clave sobre el acuerdo de nivel de servicio (SLA) de Event Grid.

Recomendaciones de implementación de producción

El Azure Well-Architected Framework proporciona recomendaciones para la confiabilidad, seguridad, costo, operaciones y rendimiento. Para comprender cómo estas áreas influyen entre sí y contribuir a una solución confiable de Event Grid, consulte Architecture best practices for Azure Event Grid.

Introducción a la arquitectura de confiabilidad

En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.

Arquitectura lógica

Event Grid enruta eventos de publicadores de eventos a consumidores de eventos. Las aplicaciones de usuario y los servicios de Azure se usan para emitir y consumir eventos, como notificaciones cuando se crean, actualizan o eliminan recursos.

Event Grid admite varios tipos de recursos y modelos de implementación:

• Los temas son las entidades principales que reciben y almacenan eventos.

  Los servicios de Azure crean automáticamente los temas del sistema para emitir eventos para tipos de recursos específicos de Azure. Los temas personalizados son creados y administrados por usted.

  Los temas pueden admitir la entrega push y pull.

• Los dominios de eventos agrupan varios temas personalizados en un único punto de conexión para simplificar la publicación de eventos. Para más información, consulte Dominios de eventos para administrar temas de Event Grid.

• Los espacios de nombres se usan con el nivel Estándar y proporcionan un contenedor para varios recursos de Event Grid. Para más información, consulte Conceptos del espacio de nombres de Azure Event Grid.

Event Grid admite varios niveles, incluido el nivel Básico y el nivel Estándar. Estos niveles proporcionan diferentes funcionalidades y difieren en cómo se implementan y administran los recursos. Para obtener más información, consulte Elegir el nivel correcto de Event Grid para la solución.

Arquitectura física

Event Grid es un servicio totalmente administrado. Microsoft administra la infraestructura subyacente, incluidos los recursos de proceso y almacenamiento. En las regiones admitidas, Event Grid distribuye automáticamente los recursos entre zonas de disponibilidad para proporcionar redundancia de zona integrada.

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 Event Grid, tenga en cuenta los procedimientos siguientes para asegurarse de que la solución es resistente a errores transitorios:

• Publicadores de eventos. Cuando una aplicación cliente publica eventos en Event Grid, es responsable de controlar errores transitorios. Las aplicaciones deben implementar la lógica de reintento cuando publican eventos. Para obtener más información, consulte Solución de problemas de conectividad transitorios.

  Se recomienda usar los SDK del plano de datos de Event Grid, que proporcionan automáticamente el control de errores transitorios.

• Consumidores de eventos. Event Grid entrega eventos a destinos configurados. Para estas conexiones salientes, puede configurar políticas de reintento en las suscripciones de eventos. Estas directivas definen la frecuencia y el tiempo durante el que Event Grid reintenta la entrega cuando se producen errores, incluidos los errores transitorios. Para obtener más información, consulte Entrega push de mensajes y reintento con tópicos de espacio de nombres.

• Idempotencia. Es una buena práctica diseñar la arquitectura de eventos para la idempotencia, lo que significa que tu aplicación puede recibir y procesar de forma segura el mismo evento varias veces. Por ejemplo, si se produce un error transitorio u otro problema mientras la aplicación procesa un evento, con un enfoque idempotente, la aplicación puede volver a procesar el mensaje y recuperarse.

  Usted es responsable de diseñar la arquitectura de eventos y la aplicación para admitir la idempotencia. Para obtener información general, consulte Idempotency.

• Mensajes fallidos. Event Grid admite mensajes fallidos para eventos que no se pueden entregar, lo que ayuda a conservar los datos durante errores más duraderos en los consumidores de eventos. Para obtener más información, consulte Dead lettering para suscripciones de eventos a temas de namespaces en Event Grid.

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.

Los recursos de Event Grid tienen redundancia de zona en regiones que admiten zonas de disponibilidad. La redundancia de zona significa que incluso cuando una zona de disponibilidad tiene un problema, los recursos de Event Grid siguen funcionando mediante la infraestructura de otras zonas. Los datos de eventos se replican automáticamente en tres zonas de disponibilidad para garantizar la resiliencia dentro de la región, y Event Grid se restaura automáticamente durante una interrupción a nivel de zona. No es necesario habilitar ni configurar esta funcionalidad.

Requisitos

Compatibilidad con regiones: La redundancia de zona está disponible en todas las regiones de Azure que admiten zonas de disponibilidad.

Costo

No hay ningún costo adicional para la redundancia de zona. No se puede habilitar ni deshabilitar esta característica. Se incluye de forma predeterminada en las regiones admitidas.

Configurar soporte de zonas de disponibilidad

No se requiere ninguna configuración. Todos los recursos de Event Grid en las regiones admitidas son automáticamente con redundancia de zona.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué se puede esperar cuando un recurso de Event Grid tiene redundancia de zona y todas las zonas están operativas.

• Operación entre zonas: Event Grid funciona en un modelo activo-activo entre zonas de disponibilidad. Las conexiones de cliente se equilibran automáticamente entre zonas y el servicio enruta las operaciones a la infraestructura de mensajería disponible independientemente de la zona.

• Replicación de datos entre zonas: Event Grid replica automáticamente los metadatos y los datos de eventos en las zonas de disponibilidad para mantener la resistencia.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando un recurso de Event Grid tiene redundancia de zona y hay una interrupción en una de las zonas.

• Detección y respuesta: Event Grid detecta automáticamente errores de zona e inicia la conmutación por error a zonas correctas. No es necesario hacer nada para iniciar una conmutación por error de la 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, Event Grid podría quitar las solicitudes activas. Si los clientes controlan correctamente los errores transitorios, siempre y cuando reintenten tras un breve intervalo, normalmente evitan un impacto significativo.

• Pérdida de datos esperada: El modelo de redundancia de zona de Event Grid está diseñado para permitir la resistencia a los errores de zona con un impacto mínimo. Sin embargo, durante un error de zona, es posible una pérdida de datos.

  Si necesita asegurarse de que la aplicación no pierde datos durante un error de zona, debe:

  • Diseñe sus productores y consumidores de eventos para que sigan las recomendaciones de control de errores transitorios, incluidos los reintentos y la idempotencia.
  • Planee la durabilidad de eventos en el origen o en un almacén de eventos duradero.

• Tiempo de inactividad esperado: Un error de zona puede provocar unos segundos de tiempo de inactividad. Si los clientes controlan correctamente los errores transitorios, siempre y cuando reintenten tras un breve intervalo, normalmente evitan un impacto significativo.

• Reenrutamiento del tráfico: Event Grid detecta la pérdida de la zona y redirige automáticamente las nuevas solicitudes a la infraestructura en una de las zonas de disponibilidad correctas.

Recuperación de zona

Cuando se recupera la zona afectada, Event Grid lo vuelve a reinsertar automáticamente en el servicio sin necesidad de la acción del cliente. A continuación, la zona recuperada acepta nuevas conexiones y procesa mensajes junto con las demás zonas. Los datos que se replican en zonas supervivientes durante la interrupción permanecen intactos y la replicación normal se reanuda en todas las zonas. No es necesario tomar medidas para la recuperación o la reintegración de zonas.

Prueba de fallos de zona

Event Grid administra el enrutamiento de tráfico, la conmutación por error y la recuperación de zona para los fallos de zona, por lo que no es necesario validar los procesos de fallos de zona de disponibilidad ni proporcionar más información adicional.

Resistencia a errores en toda la región

Los recursos de Event Grid se implementan en una sola región. Si se produce un error en toda la región, los recursos de Event Grid no están disponibles.

En regiones de Azure emparejadas, Event Grid proporciona una recuperación ante desastres geográfica limitada para los metadatos de los recursos de Event Grid. También puede diseñar y crear su propia solución multi-región, que puede respaldar la planificación de la recuperación ante desastres. En la tabla siguiente se muestra cómo los distintos tipos de recursos de Event Grid admiten cada modelo.

Recuperación de desastres geográficos

La recuperación ante desastres geográfica replica los metadatos del Event Grid en la región emparejada de la región primaria para los recursos compatibles. Los datos de eventos no se replican.

La recuperación ante desastres geográficas está diseñada como una reserva administrada por Microsoft para interrupciones regionales graves y no está diseñada para proporcionar tiempos de recuperación rápidos o predecibles. La conmutación por error iniciada por Microsoft la ejecuta Microsoft en situaciones poco frecuentes para conmutar por error recursos de Event Grid de una región afectada a la región emparejada geográficamente correspondiente. Microsoft se reserva el derecho de determinar cuándo ejercer esta opción. Este mecanismo no implica el consentimiento del cliente antes de que se redirija el tráfico.

Opcionalmente, puede deshabilitar la recuperación ante desastres geográfica y usar su propia solución personalizada de varias regiones que cumpla sus requisitos para la selección de regiones, el tiempo de conmutación por error, etc. Al deshabilitar la geo-recuperación ante desastres, Microsoft deja de replicar los datos de eventos a otra región.

Esta característica no está disponible en regiones que no tienen una región emparejada.

Requisitos

• Compatibilidad con regiones: La recuperación ante desastres geográfica solo está disponible en regiones de Azure que tienen una región emparejada.

• Tipos de recursos: Los temas y dominios personalizados admiten la recuperación ante desastres geográfica. Los temas del sistema están habilitados automáticamente para la recuperación ante desastres geográficos. No se admiten otros tipos de recursos, como espacios de nombres y espacios de nombres asociados.

Costo

No hay ningún costo adicional para la recuperación ante desastres geográfica.

Configuración de la compatibilidad con varias regiones

En las regiones admitidas, los temas del sistema se configuran automáticamente para la recuperación ante desastres geográficos. Para otros tipos de recursos de Event Grid:

• Para habilitar la recuperación ante desastres geográfica: Actualice la configuración del tema o dominio y seleccione Cross-Geo (valor predeterminado).

• Para deshabilitar la recuperación ante desastres geográfica: Actualice la configuración del tema o dominio y seleccione Regional.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar cuando un recurso de Event Grid está configurado para la recuperación ante desastres geográfica y todas las regiones están operativas.

• Operación entre regiones: Todo el tráfico se enruta a la región primaria.

• Replicación de datos entre regiones: Los metadatos se replican sincrónicamente en la región emparejada. Los datos de eventos no se replican.

Comportamiento durante una falla de región

En esta sección se describe qué esperar cuando un recurso de Event Grid está configurado para la recuperación ante desastres geográfica y hay una interrupción en la región primaria.

• Detección y respuesta: Microsoft detecta errores de región y determina si y cuándo iniciar la conmutación por error.

• 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: Se finalizan las solicitudes activas a la región primaria. Las aplicaciones cliente deben reintentar estas solicitudes una vez completada la conmutación por error.

• Pérdida de datos esperada:

  • Metadatos. Event Grid conserva los metadatos durante la conmutación por error. Dado que todos los cambios de metadatos se replican sincrónicamente, no se espera ninguna pérdida de metadatos.

  • Datos de evento Los datos de eventos de la región primaria no están disponibles y podrían perderse si la región es irrecuperable.

    Una vez que se produce una conmutación por error, los nuevos datos se procesan desde la región emparejada. Los eventos no procesados se envían desde la región primaria en cuanto se mitiga la interrupción. Si la recuperación de la región primaria requiere un tiempo mayor que el valor de período de vida establecido en eventos, es posible que se quiten los datos de la región primaria. Para mitigar esta pérdida de datos, se recomienda configurar un destino de mensajes fallidos para una suscripción de eventos.

    Si la región afectada se pierde y no se puede recuperar, habrá alguna pérdida de datos. En el mejor de los casos, el consumidor se actualiza conforme al ritmo de publicación y solo se pierden unos segundos de datos. El peor de los casos se produce cuando el consumidor no procesa activamente eventos. Con un tiempo máximo de vida de 24 horas, la pérdida de datos puede ser de hasta 24 horas.

    Nota:

    Event Grid no puede garantizar la retención de datos durante una interrupción en la región. Si necesita una retención garantizada, debe diseñar la aplicación para almacenar eventos de forma duradera en otro almacén de datos.

• Tiempo de inactividad esperado: La cantidad de tiempo de inactividad depende de la gravedad de la interrupción y del tiempo necesario para que Microsoft evalúe e inicie la conmutación por error. Debe esperar que el tiempo de inactividad sea al menos una hora y quizás más tiempo.

  Event Grid comienza a aceptar tráfico para temas y suscripciones, incluidas las operaciones de creación, actualización y eliminación, dentro de cinco minutos después de iniciar el failover.

• Redistribución: Una vez completada la conmutación por error, el tráfico se enruta automáticamente a la región secundaria.

Recuperación de regiones

Microsoft administra la recuperación de regiones y el proceso de recuperación depende del escenario de interrupción específico. Generalmente, la conmutación por error se considera una operación unidireccional.

Prueba de fallos de región

Event Grid administra el enrutamiento del tráfico, la conmutación por error y la recuperación ante desastres geográficos. No es necesario iniciar nada. Dado que esta característica está totalmente administrada, no es necesario validar los procesos de error de región.

Soluciones personalizadas de varias regiones para la resistencia

Es posible que desee deshabilitar o no confiar en la conmutación por error iniciada por Microsoft por cualquiera de estos motivos:

• Necesita que los datos de eventos, no solo los metadatos, se repliquen entre regiones.

• Debe garantizar un enfoque o un tiempo de conmutación por error específicos. La conmutación por error iniciada por Microsoft se realiza de la mejor manera posible.

• La región no está emparejada con otra región de Azure.

• El emparejamiento de tu región no cumple los requisitos de localización de datos de tu organización.

Para obtener niveles más altos de control y previsibilidad, puede implementar arquitecturas personalizadas de varias regiones. Este enfoque implica implementar recursos independientes de Event Grid en varias regiones y administrar la conmutación por error en el nivel de aplicación. Al usar este modelo, es responsable de implementar y configurar recursos y mantenerlos sincronizados entre regiones.

Tenga en cuenta los siguientes factores al diseñar una solución de varias regiones:

• Replicación. Debe implementar un proceso personalizado para replicar los recursos de Event Grid y su configuración entre las regiones primarias y secundarias. Recuerde replicar identidades de cliente, certificados de autoridad de certificación, grupos de clientes, espacios de temas y vinculaciones de permisos, si procede. Puede decidir si implementar la replicación manual o automatizada.

• Enfoques de conmutación por error. Puede elegir si desea crear una solución activa-activa o activa-pasiva:

  • Las soluciones activa-activa se pueden lograr mediante la replicación de los metadatos y el equilibrio de carga entre los espacios de nombres.

  • Las soluciones activas-pasivas se pueden lograr mediante la replicación de los metadatos para mantener el espacio de nombres secundario listo para que, cuando el espacio de nombres principal no esté disponible, el tráfico se puede dirigir al espacio de nombres secundario.

• Monitoreo de salud. Puede usar las API de mantenimiento integradas proporcionadas por Event Grid para supervisar el estado de los temas.

  Las aplicaciones cliente deben detectar errores de una región y enrutar eventos a otra región adecuada.

  Como alternativa, puede implementar un servicio de conserjería que dirija a los clientes a los puntos de conexión principales o secundarios para sus temas o espacios de nombres realizando comprobaciones de estado en esos puntos de conexión. El servicio de conserjería puede ser una aplicación web que se replica geográficamente y se mantiene accesible a través de técnicas de redirección de DNS o servicios como Azure Traffic Manager.

Para obtener más información sobre un enfoque, incluido el código de ejemplo, consulte Implementación de conmutación por error del lado cliente en Event Grid.

Copias de seguridad y restauración

Event Grid es principalmente un servicio de enrutamiento de eventos y no tiene características nativas de copia de seguridad o restauración.

Si necesita implementar funcionalidades de copia de seguridad o si tiene necesidades de retención a largo plazo, se recomienda realizar el archivado en la aplicación. Para ello, ha de crear lógica para enrutar o copiar sus eventos en un almacén duradero, como Azure Blob Storage, en paralelo con la ruta principal de entrega. Si los sistemas posteriores no están disponibles, su aplicación puede usar el archivo para reproducir los eventos.

Resistencia al mantenimiento del servicio

Microsoft aplica periódicamente actualizaciones de servicio y realiza otro mantenimiento. La plataforma Azure controla estas actividades automáticamente, lo que garantiza que el mantenimiento sea transparente y sin problemas. 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.

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, consulte Acuerdos de Nivel de Servicio para servicios en línea.

El Acuerdo de Nivel de Servicio de disponibilidad de Event Grid cubre la publicación de eventos.

Contenido relacionado

• Confiabilidad en Azure
• Procedimientos recomendados de arquitectura para Event Grid
• Documentación de Event Grid