Modèle de vérification des revendications

Stockez une charge utile de message volumineuse dans un magasin de données externe et envoyez uniquement une référence à la charge utile stockée via le système de messagerie. Les applications réceptrices utilisent le jeton de référence, appelé claim check, pour récupérer la charge utile de grande taille lorsqu’elles doivent la traiter. Cette approche permet aux charges de travail de transférer des charges utiles volumineuses sans les stocker dans le système de messagerie.

Contexte et problème

Les systèmes de messagerie traditionnels sont optimisés pour gérer un volume élevé de petits messages et limitent souvent la taille des messages qu’ils peuvent gérer. Les messages volumineux risquent non seulement de dépasser les limites de taille, mais peuvent également dégrader les performances système lorsque le système de messagerie les stocke.

Les contraintes suivantes rendent la transmission de charge utile inline par le biais du système de messagerie insuffisant :

  • Rejet pour dépassement de la limite de taille. Les systèmes de messagerie rejettent les messages qui dépassent un maximum configuré.

  • Pression sur les ressources du broker. Le stockage de charges utiles volumineuses dans le répartiteur consomme une mémoire et un disque disproportionnés par rapport aux métadonnées dont le répartiteur a besoin pour acheminer et remettre le message. Cette consommation concurrence les ressources nécessaires pour d’autres messages dans le système.

  • Dégradation du débit. Les messages plus volumineux augmentent la sérialisation, le transfert et le temps de désérialisation par opération.

  • Escalade des coûts. Certains systèmes de messagerie sont facturés par taille de message, niveau ou unité de capacité. La transmission de charges utiles volumineuses en ligne peut envoyer des charges de travail vers des niveaux de coût plus élevés ou des allocations de capacité.

Solution

Le modèle Claim Check sépare le stockage de la charge utile de la transmission des messages. Une application d’envoi écrit la charge utile complète dans un magasin de données externe et envoie une référence à cette charge utile via le système de messagerie. Le système de messagerie ne voit et ne stocke jamais la charge utile. Les applications réceptrices utilisent la référence pour récupérer directement le contenu depuis le magasin de données. La référence est un identificateur que l’application de réception doit résoudre.

Diagramme illustrant le modèle Claim Check.

Le modèle suit cette séquence :

  1. L’application d’envoi génère la charge utile.
  2. L’application d’envoi enregistre la charge utile dans le magasin de données externe.
  3. Une fois l’enregistrement réussi, l’application envoyée génère une référence à la charge utile stockée et la publie dans le système de messagerie en tant que message de vérification de revendication.
  4. Une application réceptrice récupère le message et lit le jeton claim-check.
  5. L’application de réception utilise le jeton pour récupérer la charge utile à partir du magasin de données.
  6. L’application réceptrice traite la charge utile.

Le système de messagerie gère uniquement le petit message de vérification des revendications, ce qui évite le rejet de taille du message et la nécessité d’utiliser des ressources pour transférer et conserver de grandes charges utiles de message. Le magasin de données externe applique des contrôles d’accès et des stratégies de cycle de vie à la charge utile indépendamment du système de messagerie.

Problèmes et considérations

Prenez en compte les points suivants lorsque vous choisissez comment implémenter ce modèle :

  • Responsabilité du cycle de vie de la charge utile. Définissez le composant propriétaire de la suppression de charge utile et la façon dont le composant détermine que la charge utile n’est pas nécessaire. Coordonner l’expiration des messages et la rétention de charge utile afin qu’une vérification de revendication valide ne pointe pas vers les données supprimées.

  • Application conditionnelle. Déterminez s’il faut effectuer toutes les vérifications de réclamation de messages ou prendre la décision de vérification des réclamations par message. S’il est conditionnel, assurez-vous que le schéma définit si la charge utile est incluse ou externe.

  • Sécurité des jetons et du stockage. N’incorporez pas de jetons de sécurité dans le cadre de la vérification de revendication. Conservez l’autorisation comme interaction distincte entre les systèmes producteurs ou consommateurs et le stockage de données. Si votre solution exige que les consommateurs se voient explicitement accorder un accès temporaire, utilisez plutôt le modèle de clé de valet.

  • Cohérence de charge utile et de jeton. L’écriture de la charge utile et la publication du jeton ont lieu dans des systèmes distincts et ne font pas partie d’une même transaction atomique. Un échec après l’écriture de la charge utile mais avant la publication du jeton peut laisser la charge utile à l’état orphelin. Un jeton publié avant que sa charge utile soit récupérable peut faire que les consommateurs reçoivent des références qu’ils ne peuvent pas résoudre. Publiez le jeton uniquement une fois l’écriture de charge utile réussie. Étant donné que les nouvelles tentatives peuvent fournir la même vérification de revendication plusieurs fois, utilisez le modèle consommateur Idempotent pour traiter les doublons en toute sécurité.

  • Intégrité de la charge utile. Lorsque les consommateurs doivent vérifier l’intégrité de la charge utile, incluez un hachage de contenu ou une signature numérique dans le message. Définissez un protocole pour les incompatibilités, telles que le rejet de la charge utile, la nouvelle tentative de récupération ou le routage du message à des fins d’investigation.

  • Disponibilité et durabilité de la charge utile. Le stockage de données externe doit rester disponible et pérenne pendant toute la durée durant laquelle les applications réceptrices doivent récupérer la charge utile. Si le magasin subit une panne ou une perte de données, les consommateurs qui détiennent des jetons valides ne peuvent pas récupérer leurs charges, et le traitement de leurs messages est interrompu.

  • Latence du saut de récupération. Le modèle ajoute des trajets réseau supplémentaires par rapport à la remise de messages inline. Les applications réceptrices doivent appeler le stockage de données externe pour récupérer les données utiles avant de pouvoir commencer le traitement.

  • Prise en charge de la vérification de réclamation fournie par le framework. Utilisez les fonctionnalités proposées par votre Kit de développement logiciel (SDK) De bus de messages. Par exemple, NServiceBus dispose d’une fonctionnalité DataBus qui peut automatiser le stockage et la récupération de charge utile.

Quand utiliser ce modèle

Utilisez ce modèle dans les situations suivantes :

  • Les charges utiles des messages dépassent régulièrement la taille maximale du message prise en charge par le système de messagerie. Déporter la charge utile vers un système de stockage de données externe et ne transmettre qu’un jeton de référence léger permet d’éviter les rejets dus au dépassement de la taille maximale.

  • Les messages volumineux consomment des ressources broker disproportionnées. Les messages volumineux affectent les performances du système de messagerie en augmentant la sérialisation et le temps de transfert ou en dégradant le débit pour tous les producteurs et consommateurs qui partagent le système de messagerie.

  • Les charges utiles contiennent des informations sensibles qui ne doivent pas être visibles par le système de messagerie ou par des composants intermédiaires tels que les outils de surveillance de file d’attente. Appliquez le modèle à la charge utile entière ou uniquement à ses parties sensibles. Stockez le contenu sensible dans un magasin de données sécurisé avec des contrôles d’accès dédiés pour le conserver hors du chemin de messagerie.

  • Les messages ont un routage complexe avec sérialisation répétée. Les messages parcourent plusieurs composants de routage qui effectuent la sérialisation, la désérialisation, le chiffrement ou le déchiffrement. Transmettez uniquement un petit jeton par le biais d’intermédiaires pour éliminer le traitement répété de la charge utile complète à chaque tronçon et réduire la latence cumulative.

Ce modèle peut ne pas convenir lorsque :

  • La sensibilité à la latence dépasse les problèmes de taille de charge utile. Les charges de travail qui nécessitent la latence de bout en bout la plus faible possible entre le producteur et le consommateur peuvent ne pas tolérer les tronçons réseau ajoutés pour le stockage et la récupération de charge utile. Si les messages peuvent être remis en ligne sans dépasser la taille ou les limites de performances, la remise directe est plus simple et plus rapide.

  • Vous pouvez choisir un transport ou un niveau qui prend en charge la taille de charge utile. Lorsque les charges utiles restent dans la limite prise en charge d’un transport et ne créent pas de débit ou de latence inacceptables, envoyez-les en ligne pour éviter la dépendance de magasin externe. Par exemple, Azure Service Bus niveau Premium prend en charge les messages AMQP (Advanced Message Queuing Protocol) jusqu’à 100 Mo. Conservez les messages aussi petits que possible, car les messages volumineux réduisent le débit et augmentent la latence.

  • La coordination entre deux systèmes n’est pas possible. Le modèle nécessite une coordination entre deux systèmes indépendants. La valeur du claim check doit être rédigée de manière à ce que le système récepteur puisse la comprendre, et son format pourrait devoir être ajusté au fil du temps.

Autres solutions

Considérez ces approches comme alternatives à ce modèle :

  • Réduisez la taille de la charge utile intégrée. La compression peut réduire les charges utiles textuelles ou binaires répétitives, et un sérialiseur plus compact peut réduire la surcharge des messages. Choisissez cette approche lorsque la charge utile réduite s’adapte confortablement à la limite de transport, et chaque producteur et consommateur peut utiliser le même format de compression et de sérialisation.

  • Fractionnez et agrégez naturellement la charge utile. Divisez une charge utile importante en une séquence de messages plus petits lorsque les consommateurs peuvent traiter des blocs indépendamment ou les réassembler après la remise. Cette approche conserve les données dans le système de messagerie, mais ajoute des exigences de séquencement, de corrélation, de gestion des doublons et de réassemblage. Pour plus d’informations, consultez les modèles Splitter et Aggregator à partir de modèles d’intégration d’entreprise.

Conception de la charge de travail

Évaluez la manière d’utiliser le modèle Claim Check dans la conception d’une charge de travail afin de répondre aux objectifs et principes présentés dans les piliers du cadre Azure Well-Architected. Le tableau suivant fournit des conseils sur la façon dont ce modèle prend en charge les objectifs des piliers.

Pilier Comment ce modèle soutient les objectifs des piliers.
Les décisions concernant la conception de la fiabilité contribuent à rendre votre charge de travail résiliente aux dysfonctionnements et à garantir qu’elle se récupère complètement après une défaillance. Les systèmes de messagerie peuvent fournir une livraison durable, une haute disponibilité et une reprise d’activité après sinistre, mais ils ne fournissent généralement pas les fonctionnalités de protection et de récupération des données au niveau de la charge utile d’un magasin de données dédié, comme le contrôle de version, la sauvegarde, la restauration à un point dans le temps ou une réplication indépendante. Le stockage de la charge utile séparément vous permet de sélectionner et de configurer ces fonctionnalités en fonction des exigences de récupération de charge utile.

- RE:03 Analyse des modes de défaillance
- RE :09 reprise d’activité après sinistre
Les décisions relatives à la conception de la sécurité permettent de garantir la confidentialité, l’intégrité et la disponibilité des données et des systèmes de votre charge de travail. Le modèle Vérification des revendications peut extraire des données sensibles à partir de messages et les stocker dans un magasin de données sécurisé. Cette configuration permet des contrôles d’accès plus stricts afin que seuls les services destinés à utiliser les données sensibles puissent y accéder. Le modèle masque également ces données des services non liés, tels que ceux utilisés pour la surveillance de la file d’attente.

- SE :03 Classification des données
- SE:04 Segmentation
L’optimisation des coûts est axée sur le maintien et l’amélioration du retour sur investissement de votre charge de travail. Les systèmes de messagerie imposent souvent des limites sur la taille des messages et des limites de taille accrues sont souvent une fonctionnalité Premium. La réduction de la taille des corps de messages peut vous permettre d’utiliser une solution de messagerie moins coûteuse. Tenez compte des coûts supplémentaires liés au stockage des données utiles, aux transferts sur le réseau et aux opérations de nettoyage.

- CO :07 Coûts composants
- CO :09 Coûts des flux
L’efficacité des performances permet à votre charge de travail de répondre efficacement aux demandes grâce à l’optimisation de la mise à l’échelle, du transfert des données et de l’exécution du code. Le modèle Vérification des revendications améliore l’efficacité de l’envoi, de la réception et du système de messagerie en gérant plus efficacement les messages volumineux. Elle réduit la taille des messages envoyés au système de messagerie et garantit que la réception des applications accède aux messages volumineux uniquement si nécessaire.

- PE :05 Mise à l’échelle et partitionnement
- PE :12 Optimisation continue des performances

Si ce modèle introduit des compromis au sein d’un pilier, considérez-les contre les objectifs des autres piliers.

Examples

Cette section renvoie vers GitHub des exemples du modèle cloud Claim Check qui montrent comment les services Azure mettent en œuvre le modèle Claim Check. Chaque exemple utilise Stockage Blob Azure comme magasin de données externe et l’associe à un autre système de messagerie Azure. Les exemples 1 à 3 utilisent l’URL du blob dans une notification d’Azure Event Grid comme claim check. L’exemple 4 utilise une vérification de réclamation personnalisée que l’application d’envoi publie.

Dans les exemples 1 à 3 :

  1. Une application d’envoi charge une charge utile importante pour Stockage Blob.
  2. Le chargement déclenche un Microsoft.Storage.BlobCreated événement via une rubrique système Event Grid.
  3. Event Grid achemine la notification, qui contient une URL directe du blob que les exemples utilisent comme claim check, vers le système de messagerie configuré.
  4. Une application de réception, implémentée en tant qu’application de fonction Azure Functions ou client en ligne de commande, récupère la notification, extrait l’URL de l’objet blob et télécharge la charge utile directement à partir de Stockage Blob pour traitement.

Dans une implémentation de production, vous filtrez l’abonnement aux événements en fonction des opérations qui indiquent un blob de blocs entièrement validé, et concevez le récepteur de façon à gérer les événements différés, dupliqués et dans le désordre.

L’exemple 4 utilise une approche différente. Au lieu de router une notification de stockage Blob via Event Grid, l’application d’envoi construit la vérification de la réclamation après avoir chargé la charge utile sur le stockage Blob. L’application d’envoi publie ensuite la vérification des revendications sur le point de terminaison Azure Event Hubs Kafka à l’aide du protocole Apache Kafka. Cette approche convient aux environnements qui utilisent déjà des producteurs compatibles Kafka ou nécessitent des formats de jeton personnalisés.

Le tableau suivant répertorie chaque exemple avec son système de messagerie, son émetteur Claim Check, son application réceptrice et ses dépendances de stockage. Sélectionnez chaque lien pour afficher l’exemple de code sur GitHub.

Exemple de code Système de messagerie Éditeur de vérification des réclamations Application de réception de données Dépendances de stockage
Exemple de code 1 Stockage File d'attente Azure (Stockage de files d'attente Azure) Grid d'événements Functions Stockage de données Blob
Exemple de code 2 Event Hubs (Kit de développement logiciel (SDK) Azure sur AMQP) Grid d'événements Client de ligne de commande exécutable Stockage Blob pour les données de charge utile et un stockage Blob distinct pour les points de contrôle
Exemple de code 3 Service Bus Grid d'événements Functions Stockage de données Blob
Exemple de code 4 Event Hubs (protocole Apache Kafka) Client de ligne de commande exécutable Functions Stockage de données Blob

Étapes suivantes

  • Last updated on