Event Hubs et fiabilité

Article
11/14/2023

Azure Event Hubs est un service scalable de traitement d’événements qui ingère et traite de gros volumes de données et d’événements avec une faible latence et une haute fiabilité. Il peut recevoir et traiter des millions d’événements par seconde. Les données envoyées à un concentrateur d’événements peuvent être transformées et stockées à l’aide d’adaptateurs de traitement par lot et de stockage ou d’un fournisseur d’analyse en temps réel.

Pour plus d’informations sur l’utilisation d’Event Hubs, consultez la documentation Azure Event Hubs. Vous découvrirez comment utiliser Event Hubs pour ingérer des millions d’événements par seconde à partir d’appareils et d’applications connectés.

Pour comprendre comment Event Hubs contribue à créer une charge de travail plus fiable, consultez Azure Event Hubs - Géo-reprise d’activité après sinistre.

Les sections suivantes sont spécifiques à Azure Event Hubs et à la fiabilité :

Remarques relatives à la conception
Liste de contrôle de la configuration
Options de configuration recommandées
Artefacts sources

Remarques relatives à la conception

Azure Event Hubs fournit un contrat SLA relatif à la durée de bon fonctionnement. Pour plus d’informations, consultez SLA pour Event Hubs.

Check-list

Avez-vous configuré Azure Event Hubs en tenant compte de la fiabilité ?

Créez des stratégies SendOnly et ListenOnly pour l’éditeur et le consommateur d’événements, respectivement.
Quand vous utilisez le kit SDK pour envoyer des événements à Event Hubs, vérifiez que les exceptions levées par la stratégie de nouvelle tentative (EventHubsException ou OperationCancelledException) sont correctement interceptées.
Dans les scénarios à débit élevé, utilisez des événements par lot.
Chaque consommateur peut lire des événements provenant d’une à 32 partitions.
Quand vous développez de nouvelles applications, utilisez EventProcessorClient (.NET et Java) ou EventHubConsumerClient (Python et JavaScript) comme kit SDK client.
Dans le cadre de votre stratégie de disponibilité et de reprise d’activité après sinistre à l’échelle de la solution, envisagez d’activer l’option de géo-reprise d’activité après sinistre d’Event Hubs.
Quand une solution possède un grand nombre d’éditeurs d’événements indépendants, envisagez d’utiliser des éditeurs d’événements pour un contrôle d’accès affiné.
Ne publiez pas d’événements sur une partition spécifique.
Quand vous publiez fréquemment des événements, utilisez le protocole AMQP dans la mesure du possible.
Le nombre de partitions reflète le degré de parallélisme en aval que vous pouvez atteindre.
Vérifiez que chaque application consommatrice utilise un groupe de consommateurs distinct et qu’un seul récepteur actif par groupe de consommateurs est en place.
Quand vous utilisez la fonctionnalité de capture, tenez compte de la configuration de la fenêtre de temps et de la taille du fichier, en particulier si les volumes d’événements sont faibles.

Recommandations relatives à la configuration

Tenez compte des recommandations suivantes pour optimiser la fiabilité lors de la configuration d’Azure Event Hubs :

Recommandation	Description
Quand vous utilisez le kit SDK pour envoyer des événements à Event Hubs, vérifiez que les exceptions levées par la stratégie de nouvelle tentative (`EventHubsException` ou `OperationCancelledException`) sont correctement interceptées.	Si vous utilisez `HTTPS`, vérifiez qu’un modèle de nouvelle tentative approprié est implémenté.
Dans les scénarios à débit élevé, utilisez des événements par lot.	Le service fournira un tableau `json` avec plusieurs événements aux abonnés, au lieu d’un tableau avec un événement. L’application consommatrice doit traiter ces tableaux.
Chaque consommateur peut lire des événements provenant d’une à `32` partitions.	Pour obtenir une mise à l’échelle maximale du côté de l’application consommatrice, chaque consommateur doit lire dans une partition unique.
Quand vous développez de nouvelles applications, utilisez `EventProcessorClient` (.NET et Java) ou `EventHubConsumerClient` (Python et JavaScript) comme kit SDK client.	`EventProcessorHost` a été déprécié.
Dans le cadre de votre stratégie de disponibilité et de reprise d’activité après sinistre à l’échelle de la solution, envisagez d’activer l’option de géo-reprise d’activité après sinistre d’Event Hubs.	Cette option permet de créer un espace de noms secondaire dans une autre région. Seul l’espace de noms actif reçoit des messages à tout moment. Les messages et les événements ne sont pas répliqués dans la région secondaire. Le RTO du basculement régional peut atteindre 30 minutes. Confirmez que ce RTO répond aux exigences du client et s’inscrit dans la stratégie de disponibilité plus large. Si un RTO plus élevé est requis, envisagez d’implémenter un modèle de basculement côté client.
Quand une solution possède un grand nombre d’éditeurs d’événements indépendants, envisagez d’utiliser des éditeurs d’événements pour un contrôle d’accès affiné.	Les éditeurs d’événements attribuant automatiquement le nom de l’éditeur à la clé de partition, cette fonctionnalité ne doit être utilisée que si les événements proviennent uniformément de tous les éditeurs.
Ne publiez pas d’événements sur une partition spécifique.	Si le tri des événements est essentiel, implémentez le tri en aval ou utilisez un autre service de messagerie.
Quand vous publiez fréquemment des événements, utilisez le protocole AMQP dans la mesure du possible.	Le protocole AMQP présente des coûts de gestion réseau plus élevés lors de l’initialisation de la session, mais `HTTPS` nécessite un temps de traitement TLS supplémentaire pour chaque demande. Par ailleurs, AMQP propose des performances plus élevées pour les éditeurs courants.
Le nombre de partitions reflète le degré de parallélisme en aval que vous pouvez atteindre.	Pour un débit maximal, utilisez le nombre maximal de partitions (`32`) lors de la création du hub d’événements. Le nombre maximal de partitions vous permet d’effectuer un scale-up avec `32` entités de traitement simultanées et de bénéficier de la disponibilité en envoi/réception la plus élevée.
Quand vous utilisez la fonctionnalité de capture, tenez compte de la configuration de la fenêtre de temps et de la taille du fichier, en particulier si les volumes d’événements sont faibles.	Data Lake facture une taille de fichier minimale pour le stockage (Gen1) ou une taille de transaction minimale (Gen2). Si vous définissez une fenêtre de temps si basse que le fichier n’a pas atteint la taille minimale, vous encourrez des frais supplémentaires.

Artefacts sources

Pour trouver des espaces de noms Event Hubs avec la référence SKU De base, utilisez la requête suivante :

Resources 
| where type == 'microsoft.eventhub/namespaces'
| where sku.name == 'Basic'
| project resourceGroup, name, sku.name

Étape suivante

Event Hubs et excellence opérationnelle

Share via