Traitement d’événements fiable avec Azure Functions et Event Hubs

Apprenez à construire des solutions serverless robustes et fiables en utilisant Azure Functions avec des déclencheurs Azure Event Hubs. Cet article traite des meilleures pratiques pour les points de contrôle, la gestion des erreurs et la mise en œuvre de schémas de disjoncteurs afin de vous assurer de ne perdre aucun événement et que vos applications pilotées par événements restent stables et résilientes.

Défis liés aux flux d’événements dans les systèmes distribués

Considérez un système qui envoie des événements à un taux constant de 100 événements par seconde. À ce rythme, plusieurs instances parallèles peuvent consommer les 100 événements entrants chaque seconde.

Toutefois, tenez compte de ces défis liés à l’utilisation d’un flux d’événements :

  • Un éditeur d’événements envoie un événement endommagé.
  • Votre code de fonction rencontre une exception non gérée.
  • Un système en aval est hors connexion et bloque le traitement des événements.

Contrairement à un déclencheur de stockage file d’attente Azure, qui verrouille les messages pendant le traitement, Azure Event Hubs lit, par partition, à partir d’un point unique dans le flux. Ce comportement de lecture, plus semblable à un lecteur vidéo, offre les avantages souhaités d’un débit élevé, de plusieurs groupes de consommateurs et de la capacité de relecture. Les événements sont lus, vers l’avant ou vers l’arrière, à partir d’un point de contrôle, mais vous devez déplacer le pointeur pour traiter de nouveaux événements. Pour plus d’informations, consultez Point de contrôle dans la documentation Event Hubs.

Lorsque des erreurs se produisent dans un flux et que vous choisissez de ne pas avancer le pointeur, le traitement des événements supplémentaire est bloqué. En d’autres termes, si vous arrêtez le pointeur pour traiter un problème traitant un seul événement, les événements non traités commencent à s’accumuler.

Les fonctions évitent les blocages en faisant toujours avancer le pointeur du flux, quel que soit le succès ou l’échec. Étant donné que le pointeur continue de progresser, vos fonctions doivent gérer les défaillances de manière appropriée.

Comment le déclencheur Event Hubs consomme les événements

Azure Functions consomme des événements à partir d’un hub d’événements en effectuant des étapes suivantes :

  1. Le déclencheur crée et fait persister un pointeur dans stockage Azure pour chaque partition du hub d’événements.
  2. Le déclencheur reçoit de nouveaux événements en lot (par défaut), et l’hôte tente de déclencher la fonction, fournissant le lot d’événements pour le traitement.
  3. Lorsque la fonction termine son exécution, avec ou sans exceptions, le déclencheur avance le pointeur et enregistre un point de contrôle vers le compte de stockage hôte par défaut.
  4. Si des conditions empêchent l’exécution de la fonction, l’hôte ne peut pas faire avancer le pointeur. Lorsque le pointeur ne peut pas avancer, les exécutions suivantes retraitent les mêmes événements.

Ce comportement révèle quelques points importants :

  • Les exceptions non gérées peuvent entraîner la perte d’événements :

    Les exécutions de fonctions qui déclenchent une exception continuent à faire progresser le pointeur. La définition d’une stratégie de nouvelle tentative ou d’une autre logique de nouvelle tentative retarde l’avancement du pointeur jusqu’à la fin de la nouvelle tentative.

  • Functions garantit au moins une livraison :

    Votre code et vos systèmes dépendants peuvent avoir besoin de tenir compte du fait que le même événement peut être traité deux fois. Pour plus d’informations, consultez Designing Azure Functions pour obtenir une entrée identique.

  • L’état du checkpoint est stocké dans stockage Azure :

    Le déclencheur fait persister le point de contrôle (pointeur de traitement) dans le compte de stockage configuré par le AzureWebJobsStorage réglage de l’application de fonction. Cette référence stockée du point de contrôle signifie :

    • Lorsque vous changez AzureWebJobsStorage de référence pour un autre compte de stockage, la fonction commence à être traitée depuis une nouvelle position, ce qui peut entraîner un retraitement des événements.
    • Lorsqu’un hub d’événements est supprimé et recréé, la position du flux d’événements (comme les numéros de séquence et les décalages) est réinitialisée tandis que les références stockées au point de contrôle restent inchangées. Dans ce cas, la fonction peut ne pas traiter les nouveaux événements tant que le point de contrôle n’est pas supprimé manuellement.

Gestion des exceptions

Bien que tout code de fonction doive inclure un bloc try/catch au niveau le plus élevé, il est encore plus important d'avoir un catch bloc pour les fonctions qui consomment des événements Event Hubs. De cette façon, lorsqu’une exception est levée, le bloc de traitement des exceptions gère l’erreur avant que le pointeur ne progresse.

Mécanismes et stratégies de nouvelle tentative

Étant donné que de nombreuses exceptions dans le cloud sont temporaires, la première étape de la gestion des erreurs consiste toujours à réessayer l’opération. Vous pouvez appliquer des stratégies de nouvelle tentative intégrées ou définir votre propre logique de nouvelle tentative.

Stratégies de nouvelle tentative

Functions fournit des stratégies de nouvelle tentative intégrées pour Event Hubs. Lors de l’utilisation des politiques de réessayage, il suffit de lever une nouvelle exception et l’hôte tente de traiter à nouveau l’événement selon la politique définie. Ce comportement de nouvelle tentative nécessite la version 5.x ou ultérieure de l’extension Event Hubs. Pour plus d’informations, consultez Stratégies de relance.

Logique de nouvelle tentative personnalisée

Vous pouvez également définir votre propre logique de nouvelle tentative dans la fonction elle-même. Par exemple, vous pouvez implémenter une stratégie qui suit un flux de travail illustré par les règles suivantes :

  • Essayez de traiter un événement trois fois (potentiellement avec un délai entre les nouvelles tentatives).
  • Si le résultat final de toutes les nouvelles tentatives est un échec, ajoutez un événement à une file d’attente afin que le traitement puisse continuer sur le flux.
  • Les événements corrompus ou non traités sont alors pris en charge ultérieurement.

Remarque

Polly est un exemple de bibliothèque de résilience et de gestion des erreurs temporaires pour les applications C#.

Erreurs non liées aux exceptions

Certains problèmes peuvent se produire sans qu’une exception soit levée. Par exemple, considérez un cas où une requête expire ou si l’instance exécutant la fonction se bloque. Lorsqu’une fonction ne parvient pas à se terminer sans exception, le pointeur de décalage n’est jamais avancé. Si le pointeur n’avance pas, alors toute instance qui s’exécute après l’échec d’exécution continue à lire les mêmes événements. Cette situation offre une garantie de remise au moins une fois.

L’assurance que chaque événement est traité au moins une fois implique que certains événements peuvent être traités plusieurs fois. Vos applications de fonction doivent être conscientes de cette possibilité et doivent être construites autour des principes d’idempotency.

Gestion des états d’échec

Votre application peut être en mesure de gérer de manière acceptable quelques erreurs dans le traitement des événements. Toutefois, vous devez également être prêt à gérer l’état d’échec persistant, ce qui peut se produire en raison d’échecs dans le traitement en aval. Dans un tel état de défaillance, telle qu’une banque de données en aval hors ligne, votre fonction doit cesser de se déclencher sur les événements jusqu’à ce que le système retrouve un état sain.

Modèle Disjoncteur

Lorsque vous implémentez le modèle disjoncteur , votre application peut interrompre efficacement le traitement des événements, puis la reprendre ultérieurement une fois les problèmes résolus.

Il existe deux composants requis pour implémenter un disjoncteur dans un processus de flux d’événements :

  • État partagé entre toutes les instances pour suivre et surveiller l’état de santé du circuit.
  • Processus principal qui peut gérer l’état du circuit, soit open soit closed.

Les détails de l'implémentation peuvent varier, mais pour partager l'état entre les instances, vous avez besoin d'un mécanisme de stockage. Vous pouvez stocker l’état dans stockage Azure, un cache Redis ou tout autre service persistant accessible par vos instances d’application de fonction.

Les deux Durable Functions et Azure Logic Apps fournissent une infrastructure pour gérer les flux de travail et les états du circuit. Cet article décrit l’utilisation de Logic Apps pour suspendre et redémarrer les exécutions de fonction, ce qui vous donne le contrôle nécessaire pour implémenter le modèle disjoncteur.

Définir un seuil d’échec entre les instances

L’état externe partagé persistant est nécessaire pour surveiller l’intégrité du circuit lorsque plusieurs instances traitent simultanément des événements. Vous pouvez ensuite surveiller cet état persistant en fonction des règles qui indiquent un état d’échec, par exemple :

Lorsqu’il y a plus de 100 échecs d’événements au cours d’une période de 30 secondes sur toutes les instances, arrêtez le circuit pour arrêter le déclenchement de nouveaux événements.

Les détails de l’implémentation de cette logique de supervision varient en fonction des besoins de votre application, mais en général, vous devez créer un système qui :

  1. Journalise les échecs dans une mémoire persistante.
  2. Vérifiez le compte cumulatif lorsque de nouveaux échecs sont enregistrés pour déterminer si le seuil d'échec de l'événement est atteint.
  3. Lorsque ce seuil est atteint, émettez un événement indiquant au système de rompre le circuit.

Gestion de l’état du circuit avec Azure Logic Apps

Azure Logic Apps inclut des connecteurs intégrés pour différents services, fonctionnalités et orchestrations avec état. C’est un choix naturel de gérer l’état du circuit. Après avoir détecté quand un circuit doit s’arrêter, vous pouvez créer une application logique pour implémenter ce flux de travail :

  1. Déclenchez un flux de travail Event Grid qui arrête le traitement de la fonction.
  2. Envoyez un e-mail de notification qui inclut une option permettant de redémarrer le flux de travail.

Pour apprendre à désactiver et réactiver certaines fonctions en utilisant les paramètres de l’application, voir Comment désactiver les fonctions dans Azure Functions.

Le destinataire de l’email peut enquêter sur l’état du circuit et, lorsque cela est approprié, le redémarrer via un lien dans l’email de notification. Lorsque le workflow redémarre la fonction, il traite les événements à partir du dernier point de contrôle de l’Event Hub.

En utilisant cette approche, vous ne perdez aucun événement, vous traitez les événements dans l’ordre, et vous pouvez casser le circuit aussi longtemps que nécessaire.

Stratégies de migration pour les déclencheurs Event Grid

Lorsque vous migrez une application de fonction existante entre des régions ou entre certains plans, vous devez recréer l’application pendant le processus de migration. Dans ce cas, lors du processus de migration, il se peut que deux applications puissent toutes deux consommer à partir du même flux d’événements et écrire sur la même destination de sortie.

Pour éviter la perte ou la duplication des données d’événements lors du processus de migration, envisagez d’utiliser des groupes de consommateurs :

  1. Créez un groupe de consommateurs pour la nouvelle application cible.

  2. Configurez le déclencheur dans la nouvelle application pour utiliser ce nouveau groupe de consommateurs.

    En utilisant cette approche, les deux applications peuvent traiter les événements indépendamment pendant la validation.

  3. Vérifiez que la nouvelle application traite correctement les événements.

  4. Arrêtez l’application originale ou supprimez son abonnement ou son groupe de consommateurs.

  • Last updated on