Fiabilité dans Azure Event Grid

Azure Event Grid est un service de messagerie entièrement managé qui permet une communication basée sur les événements entre les services et les applications. Il est couramment utilisé pour créer des architectures pilotées par les événements et intégrer des services Azure à des applications personnalisées.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre Event Grid résilient à diverses pannes et problèmes potentiels, notamment les erreurs temporaires, les défaillances de zone de disponibilité et les défaillances à l’échelle de la région. Il met également en évidence des informations clés sur le contrat de niveau de service Event Grid (SLA).

Recommandations concernant le déploiement de production

L’infrastructure Azure Well-Architected fournit des recommandations pour la fiabilité, la sécurité, le coût, les opérations et les performances. Pour comprendre comment ces domaines influencent les uns les autres et contribuent à une solution Event Grid fiable, consultez les meilleures pratiques Architecture pour Azure Event Grid.

Vue d’ensemble de l’architecture de fiabilité

Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.

Architecture logique

Event Grid achemine les événements des éditeurs d’événements vers les consommateurs d’événements. Il est utilisé par les applications clientes et les services Azure pour émettre et consommer des événements, tels que des notifications lorsque des ressources sont créées, mises à jour ou supprimées.

Event Grid prend en charge plusieurs types de ressources et modèles de déploiement :

• Les rubriques sont les entités principales qui reçoivent et stockent des événements.

  Les rubriques système sont créées automatiquement par les services Azure pour émettre des événements pour des types de ressources Azure spécifiques. Les rubriques personnalisées sont créées et gérées par vous.

  Les rubriques peuvent prendre en charge les livraisons push et pull.

• Les domaines d’événements regroupent plusieurs rubriques personnalisées sous un seul point de terminaison pour simplifier la publication d’événements. Pour plus d’informations, consultez Comprendre les domaines d’événements pour la gestion des rubriques Event Grid.

• Les espaces de noms sont utilisés avec le niveau Standard et fournissent un conteneur pour plusieurs ressources Event Grid. Pour plus d’informations, consultez les concepts de l’espace de noms Azure Event Grid.

Event Grid prend en charge plusieurs niveaux, notamment le niveau De base et le niveau Standard. Ces niveaux fournissent des fonctionnalités différentes et diffèrent dans la façon dont les ressources sont déployées et gérées. Pour plus d’informations, consultez Choisir le niveau Event Grid approprié pour votre solution.

Architecture physique

Event Grid est un service entièrement managé. Microsoft gère l’infrastructure sous-jacente, y compris les ressources de calcul et de stockage. Dans les régions prises en charge, Event Grid distribue automatiquement les ressources entre les zones de disponibilité pour fournir une redondance de zone intégrée.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Lorsque vous utilisez Event Grid, tenez compte des pratiques suivantes pour vous assurer que votre solution est résiliente aux erreurs temporaires :

• Éditeurs d’événements. Lorsqu’une application cliente publie des événements sur Event Grid, elle est responsable de la gestion des défaillances temporaires. Les applications doivent implémenter une logique de nouvelle tentative lorsqu’elles publient des événements. Pour plus d’informations, consultez Résoudre les problèmes de connectivité temporaires.

  Nous vous recommandons d’utiliser le SDK de la couche de données d'Event Grid, qui fournit automatiquement la gestion des erreurs temporaires.

• Consommateurs d’événements. Event Grid remet des événements aux destinations configurées. Pour ces connexions sortantes, vous configurez des politiques de réessai par le biais des abonnements aux évènements. Ces stratégies définissent la fréquence et la durée pendant laquelle Event Grid retente la remise en cas d’échecs, y compris les erreurs temporaires. Pour plus d’informations, consultez Remise push de messages et nouvelle tentative avec les rubriques d’espace de noms.

• Idempotence. Il est recommandé de concevoir votre architecture d’événements pour l’idempotency, ce qui signifie que votre application peut recevoir et traiter en toute sécurité le même événement plusieurs fois. Par exemple, si une erreur temporaire ou un autre problème se produit pendant que votre application traite un événement, avec une approche idempotente, votre application peut retraiter le message et récupérer.

  Vous êtes responsable de la conception de votre architecture d'événements et de votre application afin de prendre en charge l'idempotence. Pour obtenir des informations générales, consultez Idempotency.

• Gestion des messages non distribués. Event Grid prend en charge la mise en lettres mortes pour les événements non remis, ce qui permet de conserver des données pendant des erreurs durables dans les consommateurs d’événements. Pour plus d’informations, consultez la gestion des messages non distribués pour les abonnements aux rubriques des espaces de noms dans Event Grid.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Les ressources Event Grid sont redondantes interzone dans les régions qui prennent en charge les zones de disponibilité. La redondance de zone signifie que même lorsqu’une zone de disponibilité rencontre un problème, vos ressources Event Grid continuent de fonctionner à l’aide de l’infrastructure dans d’autres zones. Les données d’événement sont répliquées automatiquement sur trois zones de disponibilité pour la résilience intrarégion, et Event Grid se guérit automatiquement lors d’une panne à l’échelle de la zone. Vous n’avez pas besoin d’activer ou de configurer cette fonctionnalité.

Exigences

Prise en charge de la région : La redondance de zone est disponible dans toutes les régions Azure qui prennent en charge les zones de disponibilité.

Coûts

Il n’existe aucun coût supplémentaire pour la redondance de zone. Vous ne pouvez pas activer ou désactiver cette fonctionnalité. Elle est incluse par défaut dans les régions prises en charge.

Configurez la prise en charge des zones de disponibilité

Aucune configuration n’est requise. Toutes les ressources de Event Grid dans les régions prises en charge bénéficient d'une redondance zonale automatique.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsqu’une ressource Event Grid est redondante interzone et que toutes les zones sont opérationnelles.

• Opération interzone : Event Grid fonctionne dans un modèle actif-actif entre les zones de disponibilité. Les connexions clientes sont automatiquement réparties entre les zones, et le service achemine les opérations vers l'infrastructure de messagerie disponible, quelle que soit la zone.

• Réplication des données interzones : Event Grid réplique automatiquement les métadonnées et les données d’événement entre les zones de disponibilité pour maintenir la résilience.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsqu’une ressource Event Grid est redondante interzone et qu’il y a une panne dans l’une des zones.

• Détection et réponse : Event Grid détecte automatiquement les défaillances de zone et lance le basculement vers des zones saines. Vous n’avez rien à faire pour initier un failover de zone.

• Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

• Demandes actives : Lors d’une défaillance de zone, Event Grid peut supprimer les demandes actives. Si vos clients gèrent les erreurs temporaires de manière appropriée, par exemple en réessayant après une courte période de temps, ils évitent généralement un impact significatif.

• Perte de données attendue : Le modèle de redondance de zone Event Grid est conçu pour permettre la résilience aux défaillances de zone avec un impact minimal. Toutefois, lors d’une défaillance de zone, une perte de données est possible.

  Si vous devez vous assurer que votre application ne perd pas de données lors d’une défaillance de zone, vous devez :

  • Concevez vos producteurs et consommateurs d’événements pour suivre les recommandations de gestion des erreurs temporaires, notamment les nouvelles tentatives et l’idempotency.
  • Planifiez la durabilité des événements à la source ou dans un magasin d’événements durable.

• Temps d’arrêt attendu : Une défaillance de zone peut entraîner quelques secondes de temps d’arrêt. Si vos clients gèrent les erreurs temporaires de manière appropriée, par exemple en réessayant après une courte période de temps, ils évitent généralement un impact significatif.

• Réacheminement du trafic : Event Grid détecte la perte de la zone et redirige automatiquement les nouvelles demandes vers l’infrastructure dans l’une des zones de disponibilité saines.

Récupération de la zone

Lorsque la zone affectée récupère, Event Grid le réinscrit automatiquement dans le service sans nécessiter d’action du client. La zone récupérée accepte ensuite de nouvelles connexions et traite les messages en même temps que les autres zones. Les données répliquées dans des zones survivantes pendant la panne restent intactes et la réplication normale reprend dans toutes les zones. Vous n’avez pas besoin de prendre des mesures pour la récupération de zone ou la réintégration.

Tester les pannes de zone

Event Grid gère le routage du trafic, le basculement et la récupération de zone pour les défaillances de zone. Vous n’avez donc pas besoin de valider les processus d’échec de zone de disponibilité ou de fournir d’autres entrées.

Résilience aux défaillances à l’échelle de la région

Les ressources Event Grid sont déployées dans une seule région. En cas d’échec à l’échelle de la région, vos ressources Event Grid ne sont pas disponibles.

Dans les régions Azure jumelées, Event Grid fournit une récupération en cas de catastrophe limitée pour les métadonnées de vos ressources Event Grid. Vous pouvez également concevoir et créer votre propre solution multirégion, qui peut prendre en charge votre planification de la reprise d’activité après sinistre. Le tableau suivant montre comment différents types de ressources Event Grid prennent en charge chaque modèle.

Restauration après catastrophe géologique

La récupération en cas de catastrophe géographique réplique les métadonnées Event Grid dans la région jumelée de votre région primaire pour des ressources compatibles. Les données d'événements ne sont pas dupliquées.

La géo-reprise d’activité après sinistre est conçue comme une solution de secours gérée par Microsoft pour les pannes régionales graves et n’est pas destinée à fournir des temps de récupération rapides ou prévisibles. Le basculement initié par Microsoft n'est déclenché que par Microsoft dans de rares situations pour effectuer un basculement des ressources Event Grid d'une région affectée vers sa région géographiquement associée. Microsoft se réserve le droit de déterminer quand exercer cette option. Ce mécanisme n’implique pas le consentement du client avant le basculement du trafic.

Vous pouvez éventuellement désactiver la géorécupération d’urgence et utiliser votre propre solution multirégion personnalisée qui répond à vos besoins en matière de sélection de région, de temps de basculement et bien plus encore. Lorsque vous désactivez la géorécupération d'urgence, Microsoft ne réplique aucune donnée d'événement dans une autre région.

Cette fonctionnalité n’est pas disponible dans les régions qui n’ont pas de région jumelée.

Exigences

• Prise en charge de la région : La reprise après sinistre géographique n'est disponible que dans les régions Azure qui ont une région jumelée.

• Types de ressources : Les sujets et domaines personnalisés prennent en charge la reprise après sinistre géographique. Les rubriques système sont automatiquement activées pour la récupération géographique après sinistre. D’autres types de ressources, tels que les espaces de noms et les espaces de noms partenaires, ne sont pas pris en charge.

Coûts

Il n'y a pas de coût supplémentaire pour la reprise après sinistre géographique.

Configurer la prise en charge multirégion

Dans les régions prises en charge, les rubriques système sont automatiquement configurées pour la géorécupération d’urgence. Pour d’autres types de ressources Event Grid :

• Pour activer la géorécupération d’urgence : Mettez à jour la configuration de votre rubrique ou domaine, puis sélectionnez InterGéographique (par défaut).

• Pour désactiver la géorécupération d’urgence : Mettez à jour la configuration de votre rubrique ou domaine, puis sélectionnez Régional.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce qu’il faut attendre lorsqu’une ressource Event Grid est configurée pour la géorécupération d’urgence et que toutes les régions sont opérationnelles.

• Opération interrégion : Tout le trafic est acheminé vers la région primaire.

• Réplication des données interrégions : Les métadonnées sont répliquées de manière synchrone dans la région jumelée. Les données d'événements ne sont pas dupliquées.

Comportement lors d’une défaillance de région

Cette section décrit ce qu’il faut attendre lorsqu’une ressource Event Grid est configurée pour la récupération d’urgence géographique et qu’il existe une panne dans la région primaire.

• Détection et réponse : Microsoft détecte les défaillances de région et détermine si et quand lancer le basculement.

• Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de région, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

• Demandes actives : Les requêtes actives adressées à la région primaire sont arrêtées. Les applications clientes doivent réessayer ces demandes une fois le basculement terminé.

• Perte de données attendue :

  • Métadonnées. Event Grid conserve les métadonnées pendant le basculement. Étant donné que toutes les modifications de métadonnées sont répliquées de façon synchrone, aucune perte de métadonnées n’est attendue.

  • Données d’événement. Les données d’événement dans la région primaire ne sont pas disponibles et peuvent être perdues si la région n’est pas récupérable.

    Une fois le basculement effectué, de nouvelles données sont traitées à partir de la région jumelée. Les événements non traités sont distribués à partir de la région primaire dès que la panne est atténuée. Si la récupération de la région primaire nécessite plus de temps que la valeur de durée de vie définie sur les événements, les données de la région primaire peuvent être supprimées. Pour atténuer cette perte de données, nous vous recommandons de configurer une destination de lettres mortes pour un abonnement aux événements.

    Si la région affectée est perdue et irrécupérable, il y aura une perte de données. Dans le meilleur cas, le consommateur suit le taux de publication et seulement quelques secondes de données sont perdues. Le pire scénario se produit lorsque le consommateur ne traite pas activement les événements. Avec une durée maximale de vie de 24 heures, la perte de données peut atteindre jusqu’à 24 heures.

    Note

    Event Grid ne peut pas garantir la conservation des données lors d’une panne de région. Si vous avez besoin de rétention garantie, vous devez concevoir votre application pour stocker durablement des événements dans un autre magasin de données.

• Temps d’arrêt attendu : Le temps d’arrêt dépend de la gravité de la panne et du temps nécessaire à Microsoft pour évaluer et lancer le basculement. Vous devez vous attendre à un temps d’arrêt d’au moins une heure et peut-être plus longtemps.

  Event Grid commence à accepter le trafic pour les rubriques et les abonnements, notamment pour les opérations de création, de mise à jour et de suppression, dans les cinq minutes après le lancement du basculement.

• Redistribution: Une fois le basculement terminé, le trafic est automatiquement routé vers la région secondaire.

Récupération de région

Microsoft gère la récupération de région et le processus de récupération dépend du scénario de panne spécifique. En général, le basculement est traité comme une opération unidirectionnelle.

Tester les défaillances régionales

Event Grid gère le routage du trafic, le basculement et la récupération pour la reprise après sinistre géographique. Vous n’avez pas besoin de lancer quoi que ce soit. Étant donné que cette fonctionnalité est complètement gérée, vous n’avez pas besoin de valider les procédures de panne régionale.

Solutions multirégions personnalisées pour la résilience

Vous souhaiterez peut-être désactiver ou ne pas vous appuyer sur le basculement initié par Microsoft pour l’une des raisons suivantes :

• Vous avez besoin de données d’événement, et non seulement des métadonnées, pour être répliquées entre les régions.

• Vous devez garantir un temps de basculement ou une méthode spécifique. Le basculement initié par Microsoft se fait dans la mesure du possible.

• Votre région n’est pas associée à une autre région Azure.

• La paire de votre région ne répond pas aux exigences de résidence des données de votre organisation.

Pour des niveaux de contrôle et de prévisibilité plus élevés, vous pouvez implémenter des architectures multirégions personnalisées. Cette approche implique le déploiement de ressources Event Grid distinctes dans plusieurs régions et la gestion du basculement au niveau de l’application. Lorsque vous utilisez ce modèle, vous êtes responsable du déploiement et de la configuration des ressources et de leur synchronisation entre les régions.

Tenez compte des facteurs suivants lorsque vous concevez une solution multirégion :

• Réplication. Vous devez implémenter un processus personnalisé pour répliquer vos ressources Event Grid et leur configuration entre les régions primaires et secondaires. Veillez à répliquer les identités clientes, les certificats d'autorité, les groupes de clients, les espaces de rubriques et les liaisons de permissions, le cas échéant. Vous pouvez décider s’il faut implémenter une réplication manuelle ou automatisée.

• Approches de basculement. Vous pouvez choisir de créer une solution active-active ou active-passive :

  • Les solutions actives peuvent être obtenues en répliquant les métadonnées et en équilibrant la charge entre les espaces de noms.

  • Les solutions passives actives peuvent être obtenues en répliquant les métadonnées pour que l’espace de noms secondaire reste prêt afin que, lorsque l’espace de noms principal n’est pas disponible, le trafic peut être dirigé vers l’espace de noms secondaire.

• Surveillance de l'état. Vous pouvez utiliser les API d’intégrité intégrées fournies par Event Grid pour surveiller l’intégrité des rubriques.

  Vos applications clientes doivent détecter les défaillances d’une région et acheminer les événements vers une autre région appropriée.

  Vous pouvez également implémenter un service concierge qui dirige les clients vers les points de terminaison principaux ou secondaires de leurs rubriques ou espaces de noms en effectuant des vérifications d’intégrité sur ces points de terminaison. Le service concierge peut être une application web géorépliquée et accessible via des techniques de redirection DNS ou des services comme Azure Traffic Manager.

Pour plus d’informations sur une méthode, notamment l’exemple de code, consultez L’Implémentation de Basculement Côté Client dans Event Grid.

Sauvegarde et restauration

Event Grid est principalement un service de routage des événements et n’a pas de fonctionnalités de sauvegarde ou de restauration natives.

Si vous devez implémenter des fonctionnalités de sauvegarde ou si vous avez des besoins de rétention à long terme, nous vous recommandons d’effectuer l’archivage dans votre application. Pour ce faire, vous devez créer une logique pour acheminer ou copier vos événements dans un magasin durable, tel que Stockage Blob Azure, en parallèle avec le chemin de remise principal. Si les systèmes en aval ne sont pas disponibles, votre application peut utiliser l’archive pour relire les événements.

Résilience à la maintenance du service

Microsoft applique régulièrement des mises à jour de service et effectue d’autres maintenances. La plateforme Azure gère automatiquement ces activités, garantissant que la maintenance se déroule sans heurt et reste transparente pour vous. Aucun temps d’arrêt n’est attendu pendant les événements de maintenance, sauf si vous avez été informé par le biais de la maintenance planifiée d’Azure Service Health.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les SLA pour les services en ligne.

Le contrat SLA de disponibilité Event Grid couvre la publication d’événements.

Contenu connexe

• Fiabilité dans Azure
• Meilleures pratiques d’architecture pour Event Grid
• Documentation de Event Grid