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

Pour mettre à l’échelle votre application de traitement des événements, vous pouvez exécuter plusieurs instances de l’application et équilibrer la charge entre elles. Dans les versions antérieures, EventProcessorHost vous a permis 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 (version 5.0), EventProcessorClient (.NET et Java) ou EventHubConsumerClient (Python et JavaScript) vous permet de faire de même.

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. Du côté consommateur, vous avez besoin d’un mécanisme capable de lire ces événements, de les consolider et de déverser l’agrégat dans un objet blob de stockage, qui est ensuite présenté sur une page web conviviale.

Lors de la conception du 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 dynamiquement les utilisateurs. 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 sans interruption en cas de défaillance : Si un consommateur (consommateur A) échoue (par exemple, si la machine virtuelle hébergeant le consommateur se bloque soudainement), d’autres consommateurs peuvent récupérer les partitions détenues par le consommateur A et poursuivre le processus. En outre, le point de continuation, appelé point de contrôle ou décalage, doit être au point exact auquel le consommateur A a échoué, ou légèrement avant cela.
• Consommer des événements : Bien que les trois points précédents traitent de 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 du processeur d’événements peuvent fonctionner de manière 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 son propre état de traitement et pour en savoir plus sur d’autres instances actives. Ces données sont ensuite utilisées pour équilibrer la charge entre les processeurs actifs.

Recevoir des messages

Lorsque 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 logique de 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 point de contrôle 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 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 de ce processus de point de contrôle.

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 que tout état partagé accessible sur plusieurs partitions doit être synchronisé.