Intégrer Event Hubs avec des fonctions serverless sur Azure

Les solutions qui utilisent Azure Event Hubs avec Azure Functions tirent parti d’une architecture serverless évolutive, rentable et capable de traiter des volumes considérables de données en quasi-temps réel. Bien que ces services fonctionnent bien ensemble, il existe de nombreuses fonctionnalités, paramètres et subtilités qui rendent leur relation plus complexe. Cet article prodigue des conseils sur la façon de tirer parti efficacement de cette intégration en mettant en évidence les considérations et techniques clés en lien avec les performances, la résilience, la sécurité, l’observabilité et la mise à l’échelle.

Concepts de base d’Event Hubs

Event Hubs est un service de traitement des événements hautement évolutif, capable de recevoir des millions d’événements par seconde. Avant de plonger dans les modèles et les meilleures pratiques pour l’intégration d’Azure Functions, il est préférable de comprendre les composants fondamentaux d’Event Hubs.

Le diagramme suivante montre l’architecture de traitement de flux Event Hubs :

Événements

Un événement est une notification ou une modification d’état représentée comme un fait qui s’est produit dans le passé. Les événements sont immuables et conservés dans un hub d’événements, également appelé rubrique dans Kafka. Une hub d’événements est composé d’une ou plusieurs partitions.

Partitions

Quand une partition n’est pas spécifiée par l’expéditeur, les événements reçus sont répartis entre les partitions du hub d’événements. Chaque événement est écrit dans une seule partition et n’est pas multidiffusé dans plusieurs partitions. Chaque partition fonctionne comme un journal dans lequel des enregistrements sont écrits selon un modèle d’ajout uniquement. L’analogie du journal de validation est souvent utilisée pour décrire la façon dont les événements sont ajoutés à la fin d’une séquence dans une partition.

Quand plusieurs partitions sont utilisées, des journaux parallèles peuvent être utilisés dans le même hub d’événements. Ce comportement fournit plusieurs degrés de parallélisme et améliore le débit pour les consommateurs.

Consommateurs et groupes de consommateurs

Une partition peut être consommée par plusieurs personnes, chacune lisant et gérant ses propres décalages.

Event Hubs intègre le concept de groupes de consommateurs en vertu duquel plusieurs applications consommatrices peuvent avoir chacune une vue distincte du flux d’événements et lire le flux de manière indépendante à son propre rythme et avec ses propres décalages.

Pour plus d’informations, consultez Présentation approfondie des concepts et fonctionnalités d’Event hubs.

Consommation d’événements avec Azure Functions

Azure Functions prend en charge les liaisons de déclencheur et de sortie pour Event Hubs. Cette section explique comment Azure Functions répond aux événements envoyés à un flux d’événements de hub d’événements à l’aide de déclencheurs.

Chaque instance d’une fonction déclenchée par Event Hubs est adossée à une instance EventProcessorHost. Le déclencheur (alimenté par Event Hubs) garantit qu’une seule instance EventProcessorHost peut obtenir un bail sur une partition donnée.

Par exemple, considérez un hub d’événements présentant les caractéristiques suivantes :

• 10 partitions.
• 1 000 événements répartis uniformément sur toutes les partitions, avec un nombre variable de messages dans chaque partition.

Lorsque votre fonction est activée pour la première fois, il n’en existe qu’une seule instance. Nous appellerons la première instance de fonction Function_1. La fonction Function_1 a une seule instance d’EventProcessorHost qui détient un bail sur les 10 partitions. Cette instance lit les événements des partitions 1 à 10. À partir de là, l’un des événements suivants se produit :

• De nouvelles instances de fonction ne sont pas nécessaires : Function_1 est capable de traiter les 1 000 événements avant que la logique de mise à l’échelle de Functions prenne effet. Dans ce cas, l’intégralité des 1 000 messages sont traités par Function_1.

  

• Une instance de fonction supplémentaire est ajoutée : la mise à l’échelle basée sur des événements, ou toute autre logique automatisée ou manuelle, peut déterminer que le nombre de messages est supérieur à ce que Function_1 peut traiter, puis créer une instance d’application de fonction (Function_2). Cette nouvelle fonction a également une instance associée de EventProcessorHost. Quand le hub d’événements sous-jacent détecte qu’une nouvelle instance de l’hôte tente de lire des messages, il équilibre la charge des partitions entre les instances de l’hôte. Par exemple, les partitions 1 à 5 peuvent être attribuées à Function_1, et les partitions 6 à 10 à Function_2.

  

• N instances de fonction supplémentaires sont ajoutées : la mise à l’échelle basée sur des événements, ou toute autre logique automatisée ou manuelle, détermine que Function_1 et Function_2 ont plus de messages qu’elles ne peuvent en traiter, et de nouvelles instances d’application de fonction Function_N sont créées. Des instances sont créées jusqu’au point où N est égal ou supérieur au nombre de partitions de hub d’événements. Dans notre exemple, Event Hubs équilibre la charge des partitions, en l’occurrence, sur les instances Function_1...Function_10.

  

À mesure que la mise à l’échelle se produit, N instances peuvent être en nombre supérieur à celui des partitions de hub d’événements. Cette situation peut se produire lorsque la mise à l’échelle pilotée par les événements stabilise le nombre d’instances, ou parce qu’une autre logique automatisée ou manuelle a créé plus d’instances que de partitions. Dans ce cas, les instances EventProcessorHost n’obtiennent des verrous sur des partitions qu’à mesure que celles-ci sont libérées par d’autres instances, car, à un moment donné, une seule instance de fonction du même groupe de consommateurs peut accéder aux partitions sur lesquelles elle a des verrous pour les lire.

Quand toutes les exécutions de fonction se terminent (avec ou sans erreurs), des points de contrôle sont ajoutés au compte de stockage associé. Une fois les points de contrôle correctement créés, les 1 000 messages ne sont plus jamais récupérés.

Une mise à l’échelle dynamique basée sur les événements est possible avec des plans Azure Consommation et Premium. Les applications de fonction hébergées par Kubernetes peuvent également tirer parti de l’outil de mise à l’échelle KEDA pour Event Hubs. Une mise à l’échelle basée sur les événements n’étant pas possible actuellement quand l’application de fonction est hébergée dans un plan Dédié (App Service), vous devez obligatoirement déterminer le nombre approprié d’instances en fonction de votre charge de travail.

Pour plus d’informations, consultez Liaisons Azure Event Hubs pour Azure Functions et Déclencheur Azure Event Hubs pour Azure Functions.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• David Barkol | PSS (Principal Solution Specialist) (GBB)

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Ressources associées

• Supervision du traitement d’événements serverless fournit des conseils sur la supervision des architectures serverless basées sur les événements.
• Traitement d’événements sans serveur est une architecture de référence détaillant une architecture typique de ce type, avec des exemples de code et des informations importantes à prendre en compte.
• Dégroupement et filtrage dans le traitement d’événements sans serveur avec Event hubs décrit plus en détail la façon dont ces parties de l’architecture de référence fonctionnent.