Équilibrage de charge de partition pour le traitement des événements

L’équilibrage de charge de partition est une technique dans Azure Event Hubs qui distribue les charges de travail de traitement des événements sur plusieurs instances de votre application. Le client du processeur d’événements gère automatiquement la propriété des partitions et coordonne la répartition du travail entre toutes les instances de consommateur actives.

Dans les versions plus récentes du SDK (versions 5.0), EventProcessorClient (.NET et Java) ou EventHubConsumerClient (Python et JavaScript) gère automatiquement l’équilibrage de charge. Vous vous abonnez aux événements qui vous intéressent en inscrivant un gestionnaire d’événements.

Cet article décrit un exemple de scénario d’utilisation de plusieurs instances d’applications clientes pour lire des événements à partir d’un hub d’événements. Il explique également les concepts clés tels que la propriété de partition, le point de contrôle et l’équilibrage de charge.

Exemple de scénario

Comme exemple de scénario, prenons une société de sécurité qui surveille 100 000 maisons. À chaque minute, elle reçoit des données de différents capteurs (détecteur de mouvement, capteur d’ouverture de porte/fenêtre, détecteur de bris de verre, etc.) installés dans chaque maison. La société fournit un site web sur lequel les résidents peuvent surveiller l’activité de la maison en temps quasi réel.

Chaque capteur envoie des données à un hub d’événements. Le hub d’événements est configuré avec 16 partitions. Côté consommation, vous avez besoin d’un mécanisme pouvant lire ces événements, les consolider (filtrage, agrégation, etc.) et sauvegarder l’agrégat dans un blob de stockage qui est ensuite projeté sur une page web conviviale.

Application consommateur

Lorsque vous concevez un consommateur dans un environnement distribué, le scénario doit répondre aux exigences suivantes :

• Mise à l’échelle : créez plusieurs consommateurs, chacun d’entre eux assurant la lecture à partir de quelques partitions Event Hubs.
• Équilibrage de charge : augmentez ou réduisez le nombre de consommateurs dynamiquement. Par exemple, lorsqu’un nouveau type de capteur (comme un détecteur de monoxyde de carbone) est ajouté à chaque maison, le nombre d’événements augmente. Dans ce cas, l’opérateur (un humain) augmente le nombre d’instances de consommateur. Ensuite, le pool de consommateurs peut rééquilibrer le nombre de partitions pour partager la charge avec les consommateurs qui viennent d’être ajoutés.
• Reprise transparente en cas d’échec : si un consommateur (consommateur A) échoue (par exemple, la machine virtuelle qui héberge le consommateur tombe soudainement en panne), d’autres consommateurs peuvent récupérer les partitions appartenant au consommateur A et continuer. En outre, le point de continuation, appelé point de contrôle ou décalage, doit se trouver exactement là où le consommateur A a échoué ou légèrement avant.
• Consommer les événements : les trois points précédents concernaient la gestion du consommateur, mais du code est nécessaire pour consommer les événements et en faire quelque chose d’utile. Par exemple, agrégrez-le et téléchargez-le dans le stockage Blob.

Processeur d’événements ou client consommateur

Vous n’avez pas besoin de créer votre propre solution pour répondre à ces exigences. Les kits de développement logiciel (SDK) Azure Event Hubs offrent cette fonctionnalité. Dans .NET ou Java SDK, utilisez un client de processeur d’événements (EventProcessorClient). Dans les sdk Python et JavaScript, utilisez EventHubConsumerClient. Dans l’ancienne version du SDK, l’hôte du processeur d’événements (EventProcessorHost) a pris en charge ces fonctionnalités.

Pour la plupart des scénarios de production, utilisez le client du processeur d’événements pour lire et traiter les événements. Le client de processeur offre une expérience robuste pour le traitement des événements sur toutes les partitions d’un hub d’événements de manière performante et tolérante aux pannes tout en fournissant un moyen de contrôler sa progression. Les clients de processeur d’événements peuvent travailler de façon coopérative dans le contexte d’un groupe de consommateurs pour un hub d’événements donné. Les clients gèrent automatiquement la distribution et l’équilibrage du travail à mesure que les instances deviennent disponibles ou indisponibles pour le groupe.

Propriété d’une partition

Une instance de processeur d’événements possède généralement et traite des événements d’une ou plusieurs partitions. Le système distribue uniformément la propriété des partitions entre toutes les instances de processeur d’événements actives associées à une combinaison event Hub et groupe de consommateurs.

Chaque processeur d’événements reçoit un identificateur unique et revendique la propriété des partitions en ajoutant ou en mettant à jour une entrée dans un magasin de point de contrôle. Toutes les instances de processeur d’événements communiquent régulièrement avec ce stockage pour mettre à jour leur propre état de traitement et pour prendre connaissance d’autres instances actives. Le système utilise ces données pour équilibrer la charge entre les processeurs actifs. De nouvelles instances peuvent rejoindre le pool de traitement pour le faire monter en puissance. Lorsque les instances tombent en panne, soit en raison d’échecs, soit en raison d’un scale-down, le système transfère normalement la propriété de partition à d’autres processeurs actifs.

Les enregistrements de propriété des partitions disponibles dans le magasin de points de contrôle permettent de suivre l’espace de noms Event Hubs, le nom du hub d’événements, le groupe de consommateurs, l’identificateur du processeur d’événements (également appelé propriétaire), l’ID de la partition et l’heure de la dernière modification.

Chaque instance de processeur d’événements acquiert la propriété d’une partition et commence à traiter celle-ci à partir du dernier point de contrôle connu. Si un processeur échoue (arrêt de machine virtuelle), d’autres instances détectent l’échec en examinant l’heure de dernière modification. D’autres instances tentent d’obtenir la propriété des partitions précédemment détenues par l’instance inactive. Le magasin de points de contrôle garantit qu’une seule des instances peut revendiquer la propriété d’une partition. Par conséquent, à un moment donné, il existe au plus un processeur qui reçoit des événements d’une partition.

Recevoir des messages

Lorsque vous créez un processeur d’événements, spécifiez les fonctions qui traitent les événements et les erreurs. Chaque appel de la fonction qui traite des événements remet un événement unique à partir d’une partition spécifique. Vous devez gérer cet événement. Si vous souhaitez vous assurer que le consommateur traite chaque message au moins une fois, écrivez votre propre code avec une logique de nouvelle tentative. Méfiez-vous cependant des messages empoisonnés.

Traiter les événements relativement rapidement. Autrement dit, effectuez le moins de traitement possible. Si vous avez besoin d’écrire dans le stockage et d’effectuer du routage, mieux vaut utiliser deux groupes de consommateurs et avoir deux processeurs d’événements.

Point de contrôle

Le Checkpointing est un processus par lequel un processeur d’événements marque ou valide la position du dernier événement traité avec succès dans une partition. Le marquage d’un point de contrôle est généralement effectué à l’intérieur de la fonction qui traite les événements et se produit par partition au sein d’un groupe de consommateurs.

Si un processeur d’événements se déconnecte d’une partition, une autre instance peut reprendre le traitement de cette partition à partir du point de contrôle que le dernier processeur de cette partition au sein de ce groupe de consommateurs avait précédemment validé. Lorsque le processeur se connecte, il transmet le décalage au hub d’événements pour spécifier l’emplacement où commencer la lecture. De cette façon, vous pouvez utiliser des points de contrôle pour marquer des événements comme « terminés » par des applications en aval et pour offrir une résilience en cas d’arrêt d’un processeur d’événements. Vous pouvez revenir à des données plus anciennes en spécifiant un décalage inférieur par rapport à ce processus de point de contrôle.

Lorsque le point de contrôle marque un événement comme traité, il ajoute ou met à jour une entrée dans le magasin de points de contrôle avec le décalage et le numéro de séquence de l’événement. Déterminez la fréquence de mise à jour du point de contrôle. Une mise à jour après chaque événement traité avec succès peut avoir une incidence sur les performances et le coût, car elle déclenche une opération d’écriture dans le magasin de points de contrôle sous-jacent. De plus, l’application d’un point de contrôle à chaque événement indique un profil de courrier mis en file d’attente pour lequel une file d’attente Service Bus pourrait être une meilleure option qu’un hub d’événements. L’idée derrière Event Hubs est que vous obtenez une livraison « au moins une fois » à grande échelle. En octroyant la même puissance à vos systèmes en aval, il est facile de récupérer après des pannes ou des redémarrages qui se traduisent par la réception répétée des mêmes événements.

Suivez ces recommandations lorsque vous utilisez le Stockage Blob Azure en tant que magasin de points de contrôle :

• Utilisez un conteneur distinct pour chaque groupe de consommateurs. Vous pouvez utiliser le même compte de stockage, mais utiliser un conteneur par groupe.
• N’utilisez pas le compte de stockage pour autre chose.
• N’utilisez pas le conteneur pour tout autre chose.
• Créez le compte de stockage dans la même région que l’application déployée. Si l’application est locale, essayez de choisir la région la plus proche possible.

Sur la page Compte de stockage du Portail Azure, dans la section Service BLOB, vérifiez que les paramètres suivants sont désactivés.

• Espace de noms hiérarchique
• Suppression réversible de blob
• Contrôle de version

Sécurité des threads et instances de processeurs

Par défaut, la fonction qui traite les événements est appelée de manière séquentielle pour une partition donnée. Les événements et appels subséquents adressés à cette fonction à partir de la même partition s'accumulent en coulisses alors que la pompe d'événements continue à s'exécuter en arrière-plan sur d'autres threads. Les événements provenant de différentes partitions peuvent être traités simultanément. Vous devez synchroniser tout état partagé accessible entre les partitions.

Contenu connexe

Consultez les guides de démarrage rapide suivants :

• .NET Core
• Java
• Python
• JavaScript