Introduction aux files d'attente de messages et à leurs cas d'utilisation

En raison de la complexité croissante des piles numériques de nombreuses organisations, les files de messages sont devenues un élément essentiel de leurs architectures logicielles. Au lieu de maintenir des intégrations point à point de tous les composants, les files de messages permettent une communication asynchrone entre les différentes parties d'une architecture.

Les architectures dans lesquelles une file de messages est un composant central sont souvent appelées systèmes découplés. Même lorsque le système consommateur est temporairement hors service, les messages créés par les systèmes producteurs sont stockés dans la file d'attente. Ces systèmes sont donc beaucoup moins sujets aux pannes. En outre, la mise à l'échelle d'une architecture est moins gênante, car il suffit de mettre à niveau la file d'attente de messages et le producteur ou le consommateur concerné. Il n'y a pas de goulot d'étranglement ni de maillon faible.

Dans cet article, vous découvrirez les tenants et les aboutissants des files d'attente de messages, les technologies les plus populaires et divers cas d'utilisation pour commencer.

Qu'est-ce qu'une file d'attente de messages ?

En gros, une file d'attente de messages est comme une boîte aux lettres. Quelqu'un (l'éditeur) dépose une lettre (le message) dans une boîte aux lettres (la file d'attente de messages), qui est ensuite relevée par le destinataire (l'abonné). Il y a toutefois une différence : dans une file d'attente de messages, plusieurs consommateurs peuvent recevoir le message.

L'expéditeur et le destinataire n'ont pas besoin d'être actifs en même temps. La file d'attente est comme une mémoire tampon ; elle stocke les messages jusqu'à ce que le consommateur soit prêt à les recevoir.

L'éditeur

L'éditeur (ou producteur) crée et envoie les messages. Il peut s'agir de n'importe quoi : un serveur produisant des journaux, une application envoyant des données à une base de données, et même un espace de stockage cloud envoyant des fichiers CSV ligne par ligne. Dans un système découplé, l'éditeur fonctionne de manière indépendante, sans se préoccuper de savoir qui consommera les messages.

Le message

Le message contient les données réelles transmises de l'éditeur à l'abonné. Il peut s'agir de n'importe quoi, d'une simple chaîne de texte ou d'un objet JSON, d'un document XML ou même d'un code sérialisé. Un message contient généralement des en-têtes avec des métadonnées. Celles-ci fournissent un contexte et des instructions sur le message lui-même, par exemple l'identifiant de l'expéditeur, l'horodatage, la priorité ou, dans certains systèmes, des informations sur le destinataire prévu.

File d'attente des messages

La file d'attente des messages stocke temporairement les messages et est responsable de la livraison du message à un ou plusieurs abonnés. Certaines files d'attente de messages permettent de maintenir un ordre spécifique des messages, comme le premier entré premier sorti. Cependant, la livraison ordonnée peut impliquer certains compromis, tels que la complexité et le débit. Par exemple, si un message spécifique est retardé alors qu'il attend d'être consommé, il peut bloquer tous les messages suivants dans la file d'attente, ce qui entraîne une croissance rapide de cette dernière.

Abonné

L'abonné (ou consommateur) écoute la file d'attente et prend les messages (pertinents) pour les traiter. Comme l'éditeur, l'abonné peut être n'importe quoi, une autre application, un service de mise à jour d'une base de données ou tout autre composant qui a besoin de l'information.

Sujet

Certaines files d'attente de messages comprennent un système d'échange ou de courtage, un système de routage qui agit comme un contrôleur de trafic pour les messages. L'échange décide de la file d'attente ou de l'abonné qui doit recevoir un message en fonction de règles prédéfinies. Un type d'échange courant est l'échange de sujets. Cette approche consiste à étiqueter les messages avec une clé de routage, une chaîne de caractères séparée par des points. Les abonnés ou les files d'attente utilisent les clés de liaison pour filtrer et s'abonner aux messages qui correspondent à des modèles de routage spécifiques.

Voici un exemple tiré d'un site web sportif :

Un éditeur envoie les résultats finaux des matchs de tous les sports et de toutes les ligues du monde avec des clés de routage telles que "cricket.india.ipl" et "soccer.uk.premierleague". Un sujet utilise la clé de liaison "soccer" pour contenir tous les messages relatifs au football, que les abonnés peuvent consommer pour recevoir tous les résultats des matchs de football du monde entier.

Accusé de réception

Certains systèmes prennent en charge l'accusé de réception (ou "ack") des messages afin de garantir la fiabilité de la livraison des messages. Il s'agit essentiellement d'un signal envoyé par le consommateur à la file d'attente des messages, indiquant qu'un message a été reçu et consommé avec succès. Cela permet de garantir la livraison (prévention de la perte de messages) et d'éviter le traitement en double des messages. Il existe plusieurs stratégies de garantie de livraison :

• Le plus souvent une fois. Aucune garantie de livraison.
• Au moins une fois. Les messages sont livrés au moins une fois, mais peuvent également être dupliqués.
• Exactly-once. Les messages sont livrés exactement une fois. Il s'agit du système le plus complexe à mettre en œuvre, car il faut configurer une rubrique distincte pour chaque lien entre les deux systèmes.

Modèles de messagerie

Les systèmes de messagerie suivent une série de modèles de communication, chaque modèle prenant en charge différents types de cas d'utilisation.

• Un à un. Les messages sont transmis par un seul sujet par un seul éditeur à un seul abonné prédéfini.
• Un à plusieurs (en éventail). Les messages sont diffusés sur un sujet par un éditeur unique à plusieurs consommateurs. Il est possible de s'assurer qu'au moins un consommateur lit le message grâce à une stratégie de garantie de livraison au moins une fois. Cependant, s'assurer que tous les abonnés reçoivent et traitent le message (atomicité) nécessite quelques étapes supplémentaires connues sous le nom de modèle à deux phases (2PC ) ou de modèle saga.
• Plusieurs à un (en éventail). Dans un modèle "plusieurs à un", les messages sont délivrés par plusieurs éditeurs à un seul consommateur sur un sujet. Ce modèle est généralement utilisé lorsque plusieurs systèmes produisent des flux de données, comme des journaux ou des modifications de base de données, qui sont collectés et stockés dans un système unique.
• Plusieurs à plusieurs (charge équilibrée). Enfin, dans un modèle many-to-many, les messages sont délivrés sur un sujet par plusieurs éditeurs à plusieurs consommateurs. Comme dans le cas du modèle un-à-plusieurs, la garantie de l'atomicité nécessite une certaine ingénierie supplémentaire.

Technologies populaires de file d'attente de messages

Avant de passer aux cas d'utilisation réels, examinons quelques technologies populaires de mise en file d'attente de messages.

RabbitMQ

RabbitMQ est un produit mature et largement utilisé dans les environnements IoT. Bien que son installation ne prenne que quelques minutes, il est réputé pour sa très faible latence. En outre, il prend en charge des cas d'utilisation complexes en matière de routage. RabbitMQ est open source et, bien qu'il soit écrit en Erlang, il est pris en charge par la plupart des langages de programmation.

ActiveMQ

Comme RabbitMQ, ActiveMQ est un produit mature et largement utilisé. Il est entièrement conçu en Java et excelle dans les environnements d'entreprise basés sur Java. Bien qu'il n'atteigne pas la faible latence de RabbitMQ et qu'il ne soit pas aussi avancé en termes de fonctions de routage, il est mieux adapté aux cas à haut débit grâce à ses fonctions d'extensibilité horizontale. Il est également open source et pris en charge par de nombreux langages de programmation.

Apache Kafka

Kafka est un système moderne de file d'attente avec traitement et manipulation de données en temps réel. Il s'est imposé ces dernières années comme la solution de choix pour les applications de streaming. Grâce à son architecture distribuée, il présente une faible latence, prend en charge un débit élevé et est tolérant aux pannes. L'inconvénient est qu'il est plus difficile à mettre en place et plus coûteux à maintenir en raison de sa nature distribuée. Bien que Kafka soit une source ouverte, de nombreux fournisseurs l'offrent en tant que service, y compris son développeur d'origine chez Confluent.

Files d'attente de messages en tant que service : Amazon SQS, Azure Service Bus et GCP Pub/Sub

Cela nous amène aux services gérés. Chacun des trois plus grands fournisseurs de services cloud possède sa propre technologie de file d'attente de messages. Ce qu'elles ont en commun, c'est qu'elles s'intègrent parfaitement à des dizaines d'autres services cloud de leur fournisseur respectif. Cependant, ils excellent tous dans un domaine spécifique. Le Service Bus d'Azure est riche en fonctionnalités et prend en charge des cas d'utilisation complexes. Amazon SQS est rentable. Il n'excelle pas en termes de vitesse et d'étendue, ni en termes de fonctionnalités, mais il offre le meilleur rapport qualité-prix. Enfin, GCP Pub/Sub présente la latence la plus faible et le débit le plus élevé, mais son modèle de tarification est complexe et peut entraîner des coûts inattendus.

Les files d'attente de messages en action

Maintenant que nous avons établi une vue d'ensemble des files d'attente de messages et de leurs caractéristiques, il est temps de présenter une série de cas d'utilisation dans différents secteurs.

Cas d'utilisation 1 : Traitement des paiements

Les systèmes de traitement des paiements, tels que Stripe, utilisent une file d'attente de messages pour gérer la communication asynchrone entre les différents composants du pipeline de traitement des paiements. Lorsqu'un client effectue un paiement, l'application web publie un message "payment_request" dans la file d'attente. Ce message contient des informations essentielles telles que l'identifiant du client, l'identifiant de la commande, le montant et la méthode de paiement.

Une clé de routage adaptée à ce scénario pourrait être "payment.process", ce qui permettrait de filtrer et d'établir des priorités si nécessaire. Étant donné que plusieurs services peuvent être amenés à réagir à un paiement réussi (par exemple, l'inventaire, l'expédition et la comptabilité), un modèle de messagerie un-à-plusieurs est approprié, éventuellement avec un courtier, pour assurer la cohérence des données. Un modèle de saga peut annuler tout changement en cas de défaillance des services en aval. Enfin, le système nécessite une garantie de livraison "au moins une fois" pour s'assurer qu'aucune demande de paiement n'est perdue, même en cas de défaillance temporaire.

Cas d'utilisation 2 : jeux mobiles multijoueurs

Dans les jeux mobiles, chaque serveur de jeu publie généralement les événements du jeu, tels que les actions des joueurs, les mises à jour de l'état du jeu et les messages de discussion, dans la file d'attente des messages à l'aide de clés de routage appropriées telles que "game.{game_id}.event" ou "player.{player_id}.action"

Voici comment cela fonctionnerait :

• Lorsque les joueurs participent à un événement en ligne, comme un raid dans un donjon, ils s'abonnent aux événements de cette instance de donjon particulière.
• Chaque fois que les joueurs interagissent, qu'ils se rencontrent sur la même carte, qu'ils s'envoient des messages textuels ou qu'ils participent à un combat, ils s'abonnent aux événements de l'autre.
• Un "service de notification" s'abonne aux sujets pertinents pour recueillir les événements qui déclenchent des notifications, comme l'obtention d'un score élevé, la réception d'une demande d'ami ou le début d'un nouveau match. Ce service génère ensuite des notifications et les transmet aux appareils des joueurs par l'intermédiaire d'un service de notification push.

Pour ce scénario, une garantie de livraison "au moins une fois" est cruciale pour s'assurer que les événements et les notifications critiques du jeu ne sont pas perdus. Le modèle de messagerie serait de type "plusieurs à plusieurs", car plusieurs joueurs interagissent les uns avec les autres et avec le serveur de jeu. Dans le domaine des jeux, la latence est très importante, et un modèle 2PC n'est donc pas adapté. En revanche, un modèle saga peut garantir la cohérence des données entre les différents services de jeu.

Cas d'utilisation 3 : équilibrage de la charge

Un équilibreur de charge reçoit initialement toutes les demandes entrantes. Au lieu de les transmettre directement aux serveurs dorsaux, l'équilibreur de charge publie chaque demande sous la forme d'un message dans la file d'attente. Plusieurs instances de travailleurs s'abonneront à cette file d'attente, consommeront les messages et traiteront les demandes. La file d'attente des messages répartit efficacement la charge de travail entre les travailleurs disponibles, de sorte qu'aucun serveur n'est submergé. Cette approche offre également une certaine résilience : si un collaborateur tombe en panne, le message reste dans la file d'attente pour qu'un autre collaborateur le prenne en charge.

Une clé de routage appropriée pour ce scénario pourrait être "request.process", ce qui permettrait de hiérarchiser ou de filtrer les demandes à l'avenir. Une garantie de livraison "au moins une fois" est nécessaire pour s'assurer qu'aucune demande n'est perdue en raison de la défaillance d'un travailleur. Il est clair que le modèle de messagerie est ici un à plusieurs, puisqu'une demande unique est traitée par l'un des nombreux travailleurs disponibles.

Cas d'utilisation 4 : flux de données

Supposons que vous souhaitiez suivre toutes les modifications apportées à la base de données : Un connecteur Debezium est déployé à côté d'une base de données pour capturer ses changements. Ces changements sont transformés en événements et publiés dans une file d'attente de messages. La file d'attente de messages sert de plaque tournante pour la distribution de ces événements de changement à divers consommateurs. Une plateforme de streaming, comme Kafka, peut être utilisée pour transformer les événements en temps réel et les charger dans l'entrepôt de données à des fins d'analyse en temps réel.

Une stratégie de clé de routage appropriée pourrait être "database.{db_name}.{table_name}.{operation}", permettant aux abonnés de filtrer les événements en fonction de la base de données spécifique, de la table ou du type d'opération (création, mise à jour, suppression). Une garantie de livraison "au moins une fois" est importante pour s'assurer qu'aucune modification de la base de données n'est manquée par l'entrepôt de données. Le modèle de messagerie ici est typiquement one-to-many, car un seul événement de changement de base de données peut être pertinent pour plusieurs consommateurs en plus de l'entrepôt de données.

Comment Upsun simplifie la gestion des files d'attente de messages

La mise en place et le fonctionnement des files d'attente de messages ne devraient pas nécessiter une équipe DevOps dédiée. Upsun transforme les opérations complexes des files d'attente de messages en flux de travail simples et conviviaux pour les développeurs, ce qui vous permet de vous concentrer sur la création de fonctionnalités plutôt que sur la gestion de l'infrastructure.

Déploiement en quelques minutes

L'installation traditionnelle d'une file d'attente de messages implique des dizaines d'étapes de configuration, un renforcement de la sécurité et des tests approfondis. Vous passerez des jours à installer des logiciels, à configurer les autorisations des utilisateurs, à mettre en place des certificats SSL, à établir des clusters pour la haute disponibilité, à configurer la surveillance et l'alerte, à mettre en place des sauvegardes automatisées et à effectuer un renforcement de la sécurité.

Avec Upsun, vous définissez simplement vos besoins dans un fichier de configuration, et nous nous occupons de tout le reste. En quelques minutes, vous disposez d'une file d'attente de messages prête pour la production, avec une mise en cluster automatique, un cryptage SSL, une surveillance, des sauvegardes et des correctifs de sécurité déjà configurés.

Test avec des données de production réelles

Le plus grand défi des files d'attente de messages est que les environnements de développement locaux ne peuvent pas reproduire le comportement de la production. Les messages qui fonctionnent parfaitement sur votre ordinateur portable peuvent échouer de façon spectaculaire avec des volumes et des modèles de données réels.

Upsun résout ce problème grâce à un clonage parfait de l'environnement. Vous pouvez créer instantanément une copie complète de votre environnement de production, y compris les configurations exactes des files d'attente, les modèles et volumes de messages réels, les mêmes caractéristiques de performance et les données de type production qui peuvent être anonymisées en option.

Exemple : Une entreprise de commerce électronique devait tester un nouveau système de traitement des commandes pendant la période de pointe. Au lieu de deviner ses performances, elle a cloné son environnement de production avec les volumes de messages réels du Black Friday. Elle a découvert et corrigé trois goulets d'étranglement avant le déploiement, évitant ainsi une indisponibilité potentielle au cours de la journée la plus lucrative.

Une surveillance intelligente

La plupart des outils de surveillance vous indiquent que quelque chose ne va pas, mais pas ce qu'il faut faire. La surveillance traditionnelle peut vous dire "Profondeur de la file d'attente : 10 000 messages" ou "Délai de consommation : 5 minutes" sans vous expliquer ce que cela signifie ou comment y remédier.

L'observabilité intégrée d'Upsun fournit des informations exploitables. Au lieu de mesures cryptiques, vous obtenez des descriptions de problèmes claires comme "Les messages de paiement sont traités dans le désordre" avec des suggestions de correction comme "Activer le mode consommateur unique-actif" et des options de résolution en un clic.

Mise à l'échelle automatique

Le trafic des files d'attente de messages est imprévisible. Une publication virale sur les réseaux sociaux ou une vente flash peut instantanément submerger votre système. Upsun met automatiquement à l'échelle vos files d'attente de messages en fonction de la demande en temps réel.

Lorsque le trafic est normal, vos files d'attente fonctionnent avec des ressources minimales afin de maintenir les coûts à un niveau bas. En cas de pic de trafic, le système s'adapte instantanément pour gérer la charge. Une fois la pointe passée, les ressources sont automatiquement réduites. Vous ne payez que ce que vous utilisez.

Intégration à votre flux de développement

Les files d'attente de messages d'Upsun fonctionnent de manière transparente avec vos outils et processus existants.

Chaque modification apportée à la configuration de votre file d'attente passe par votre processus normal de révision du code en utilisant la configuration basée sur git, ce qui élimine la "dérive de la configuration" entre les environnements. Les détails de la connexion à la file d'attente sont automatiquement injectés dans vos applications en tant que variables d'environnement, ce qui élimine le besoin d'informations d'identification codées en dur ou de mises à jour manuelles de la configuration.

Vous pouvez visualiser les métriques de votre application, les performances de la base de données et la santé de la file d'attente de messages dans un tableau de bord unifié, ce qui vous évite de devoir jongler entre plusieurs outils de surveillance.

Conclusion

Les files de messages sont devenues l'épine dorsale des applications modernes et évolutives, mais leur mise en œuvre et leur gestion ne doivent pas ralentir votre processus de développement. Bien que les concepts soient simples, la complexité opérationnelle de l'exploitation des files de messages en production peut rapidement devenir insurmontable.

La gestion des garanties de livraison, de la durabilité, de la persistance et de l'ordonnancement entre les différentes technologies de files d'attente de messages est complexe et sujette aux erreurs. Chaque courtier a ses propres nuances de configuration, ses exigences de surveillance et ses modes de défaillance qui nécessitent une expertise spécialisée pour être gérés correctement.

C'est là qu'intervient Upsun. En tant que plateforme d'application cloud axée sur les développeurs, Upsun vous décharge du fardeau opérationnel en vous fournissant des configurations préconfigurées et testées pour RabbitMQ et Kafka qui gèrent les problèmes de durabilité, de persistance et d'ordonnancement dès la sortie de la boîte. Que vous ayez besoin de RabbitMQ pour des scénarios de routage complexes ou de Kafka pour des flux à haut débit, Upsun fournit des services entièrement gérés avec une mise à l'échelle, une surveillance et une maintenance automatiques.

La surveillance intégrée d'Upsun va au-delà de la métrique de base, elle vous montre exactement quand les messages sont traités dans le désordre ou quand les garanties de durabilité sont violées, avant que vos clients ne s'en aperçoivent. Avec le workflow basé sur git d'Upsun et le clonage instantané de l'environnement, vous pouvez tester vos configurations de file d'attente de messages avec des données similaires à celles de la production avant le déploiement, éliminant ainsi les conjectures qui conduisent souvent à des problèmes de production.

Prêt à mettre en œuvre des files d'attente de messages sans les maux de tête opérationnels ? Commencez à construire avec Upsun dès aujourd'hui et concentrez-vous sur ce qui compte le plus : la logique de votre application, et non la gestion de l'infrastructure.