Mise à l’échelle de l’application de traitement

Effectué

Pour mettre à l’échelle votre application de traitement des événements, vous pouvez exécuter plusieurs instances de l’application et faire en sorte que celle-ci équilibre la charge entre elles. Dans les versions plus anciennes, EventProcessorHost vous permettait d’équilibrer la charge entre plusieurs instances de votre programme et des événements de point de contrôle lors de la réception. Dans les versions plus récentes (à partir de 5.0), EventProcessorClient (.NET et Java) ou EventHubConsumerClient (Python et JavaScript) vous permet d’en faire de même.

Notes

La clé de la mise à l’échelle des instances Event Hubs réside dans la notion de consommateurs partitionnés. Contrairement au modèle de consommateurs concurrents, le modèle de consommateurs partitionnés permet de travailler à grande échelle en supprimant le goulot d’étranglement de contention et en facilitant le parallélisme de bout en bout.

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 capable de lire ces événements, de les consolider et de vider l’agrégat dans un objet blob de stockage, qui est ensuite projeté sur une page web conviviale.

Lorsque vous concevez le consommateur dans un environnement distribué, le scénario doit gérer les 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 des événements : alors que les trois points précédents concernent la gestion du consommateur, il doit y avoir du code pour consommer les événements et en faire quelque chose d’utile. Par exemple, l’agréger et le charger dans le stockage d’objets 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 les kits de développement logiciel (SDK, Software Development Kit) .NET et Java, on utilise un client de processeur d’événements (EventProcessorClient), contre EventHubConsumerClient dans les kits SDK Python et JavaScript.

Dans la plupart des scénarios de production, nous vous recommandons d’utiliser le client de processeur d’événements pour lire et traiter les événements. 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 des instances deviennent disponibles ou indisponibles pour le groupe.

Suivi de la 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. La propriété des partitions est répartie uniformément entre toutes les instances de processeur d’événements actives associées à une combinaison de hub d’événements et de 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 magasin pour mettre à jour leur propre état de traitement et pour en savoir plus sur les autres instances actives. Ces données sont ensuite utilisées pour équilibrer la charge entre les processeurs actifs.

Recevoir des messages

Quand vous créez un processeur d’événements, vous 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. Il vous incombe de gérer cet événement. Si vous souhaitez vous assurer que le consommateur traite chaque message au moins une fois, vous devez écrire votre propre code avec une nouvelle tentative. Méfiez-vous cependant des messages empoisonnés.

Nous vous recommandons d’opérer assez 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.

Points de contrôle

Le marquage de point de contrôle est un processus par lequel un processeur d’événements marque ou valide la position du dernier événement correctement traité 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 la partition au point de contrôle précédemment validé par le dernier processeur de cette partition dans ce groupe de consommateurs. 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. Il est possible de revenir à des données plus anciennes en spécifiant un décalage inférieur à partir de ce processus de vérification.

Cohérence de thread et instances de processeur

Par défaut, la fonction qui traite les événements est appelée séquentiellement 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 et tout état partagé accessible sur plusieurs partitions doit être synchronisé.