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

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

Les architectures dans lesquelles une file d’attente de messages est un élément 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. Ça rend ces systèmes bien moins sujets aux pannes. De plus, faire évoluer une architecture est plus simple, car il suffit de mettre à niveau la file d’attente de messages et le producteur ou consommateur concerné. Il n’y a ni goulots d’étranglement ni maillons faibles.

Dans cet article, tu découvriras les tenants et aboutissants des files d’attente de messages, les technologies les plus courantes et divers cas d’utilisation pour te lancer.

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

En gros, une file d’attente de messages, c’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 récupéré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 fait office de tampon : elle stocke les messages jusqu’à ce que le destinataire soit prêt à les recevoir.

Éditeur

L’éditeur (ou producteur) crée et envoie des messages. Ça peut être n’importe quoi : un serveur qui génère des journaux, une application qui envoie des données à une base de données, et même un compartiment de stockage cloud qui envoie des fichiers CSV ligne par ligne. Dans un système découplé, l’éditeur fonctionne de manière indépendante, sans se soucier de savoir qui va consommer les messages.

Message

Le message contient les données réelles transmises de l’éditeur à l’abonné. Ça peut être n’importe quoi, d’une simple chaîne de texte ou d’un objet JSON à un document XML, voire du code sérialisé. Un message contient généralement des en-têtes avec des métadonnées. Celles-ci fournissent du 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 de messages

La file d’attente de messages stocke temporairement les messages et est chargée de les acheminer vers un ou plusieurs abonnés. Certaines files d’attente prennent en charge le respect d’un ordre spécifique des messages, comme le principe « premier entré, premier sorti » (First-In-First-Out). Cependant, la livraison ordonnée peut impliquer certains compromis, notamment en termes de complexité et de débit. Par exemple, si un message spécifique est retardé en attendant d’être consommé, il peut bloquer tous les messages suivants dans la file d’attente, ce qui fait grossir celle-ci très vite.

Abonné

L’abonné (ou consommateur) écoute la file d’attente et récupère les messages (pertinents) pour les traiter. Tout comme un éditeur, un abonné peut être n’importe quoi : une autre application, un service chargé de mettre à jour une base de données, ou n’importe quel autre composant qui a besoin de ces informations.

Sujet

Certaines files d’attente de messages intègrent un système d’échange ou de courtage, c’est-à-dire un système de routage qui agit comme un régulateur de trafic pour les messages. L’échange décide quelle file d’attente ou quel abonné doit recevoir un message en fonction de règles prédéfinies. Un type courant d’échange est l’échange par sujet. Cette approche consiste à marquer 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 des 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 scores finaux des matchs de toutes les disciplines et de toutes les ligues du monde entier avec des clés de routage comme « cricket.india.ipl » et « soccer.uk.premierleague ». Un sujet utilise la clé de liaison « soccer » pour regrouper tous les messages sur le foot, que les abonnés peuvent consulter pour recevoir tous les résultats de foot du monde entier.

Accusé de réception

Certains systèmes prennent en charge l’accusé de réception (ou « ac ») des messages pour garantir une livraison fiable. Il s’agit essentiellement d’un signal envoyé par le consommateur à la file d’attente de messages pour indiquer qu’un message a bien été reçu et consommé. Ça garantit la livraison (en évitant la perte de messages) et empêche le traitement en double des messages. Il existe différentes stratégies de garantie de livraison :

• Au plus une fois. Aucune garantie de livraison.
• Au moins une fois. Les messages sont livrés au moins une fois, mais peuvent aussi être dupliqués.
• Exactement une fois. Les messages sont livrés exactement une fois. C’est le système le plus complexe à mettre en place, car il faut configurer un sujet distinct pour chaque liaison entre les deux systèmes.

Modèles de messagerie

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

• Un-à-un. Les messages sont transmis via un seul sujet par un seul éditeur à un seul abonné prédéfini.
• Un-à-plusieurs (fan-out). Les messages sont transmis via un sujet par un seul éditeur à plusieurs consommateurs. Pour garantir qu’au moins un consommateur lise le message, on peut utiliser une stratégie de garantie de transmission « au moins une fois ». Par contre, pour s’assurer que tous les abonnés reçoivent et traitent le message (atomicité), il faut suivre des étapes supplémentaires, appelées modèle en deux phases (2PC) ou modèle « saga ».
• De plusieurs vers un (fan-in). Dans un modèle « de plusieurs vers un », les messages sont envoyés via un sujet par plusieurs éditeurs à un seul consommateur. 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 seul système.
• De plusieurs à plusieurs (avec équilibrage de charge). Enfin, dans un modèle « de plusieurs à plusieurs », les messages sont envoyés sur un sujet par plusieurs éditeurs à plusieurs consommateurs. Comme pour le modèle « d’un à plusieurs », garantir l’atomicité nécessite un peu de travail d’ingénierie supplémentaire.

Technologies de files d’attente de messages courantes

Avant de passer aux cas d’utilisation concrets, parlons un peu des technologies de files d’attente de messages les plus courantes.

RabbitMQ

RabbitMQ est un produit abouti, largement utilisé dans les environnements IoT. Même s’il ne faut que quelques minutes pour le configurer, il est réputé pour sa très faible latence. De plus, 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

Tout comme RabbitMQ, ActiveMQ est un produit abouti et très répandu. Il est entièrement développé 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 fonctionnalités de routage, il est plus adapté aux cas nécessitant un débit élevé grâce à ses capacités d’évolutivité horizontale. Il est également open source et pris en charge par de nombreux langages de programmation.

Apache Kafka

Kafka est un système de file d’attente moderne permettant le traitement et la manipulation des données en temps réel. Il s’est imposé ces dernières années comme la solution incontournable pour les applications de streaming. Grâce à son architecture distribuée, il offre une faible latence, prend en charge un débit élevé et est tolérant aux pannes. L’inconvénient, c’est qu’il est plus difficile à mettre en place et plus coûteux à entretenir à cause de sa nature distribuée. Même si Kafka est open source, de nombreux fournisseurs le proposent en tant que service, y compris son développeur d’origine chez Confluent.

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

Ça nous amène aux services gérés. Chacun des trois plus grands fournisseurs de services cloud dispose de sa propre technologie de file d’attente de messages. Ce qu’ils ont tous en commun, c’est qu’ils s’intègrent parfaitement à des dizaines d’autres services cloud de leur fournisseur respectif. Cependant, ils excellent tous dans un aspect spécifique. Azure Service Bus est riche en fonctionnalités et prend en charge des cas d’utilisation complexes. Amazon SQS est économique. Il n’excelle ni en vitesse ni en débit, 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 imprévus.

Les files d'attente de messages en action

Maintenant qu'on a fait le point sur les files d'attente de messages et leurs fonctionnalités, c'est le moment de présenter différents cas d'utilisation dans divers secteurs.

Cas d'utilisation n° 1 : le traitement des paiements

Les systèmes de traitement des paiements, comme 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 lance un paiement, l’application web publie un message « payment_request » dans la file d’attente. Ce message contient des informations essentielles comme l’identifiant du client, le numéro de commande, le montant et le mode de paiement.

Une clé de routage adaptée à ce scénario pourrait être « payment.process », ce qui permettrait de filtrer et de hiérarchiser les messages si besoin. Comme plusieurs services peuvent devoir réagir à un paiement réussi (par exemple, la gestion des stocks, l’expédition et la comptabilité), un modèle de messagerie « un-à-plusieurs » est approprié, éventuellement avec un courtier, pour garantir la cohérence des données. Un modèle de saga permet d’annuler toutes les modifications en cas de défaillance des services en aval. Enfin, le système a besoin d’une garantie de livraison « au moins une fois » pour s’assurer qu’aucune demande de paiement ne soit perdue, même en cas de défaillances temporaires.

Cas d’utilisation n° 2 : jeux multijoueurs sur mobile

Dans les jeux mobiles, chaque serveur de jeu publie généralement des événements du jeu — comme les actions des joueurs, les mises à jour de l’état du jeu et les messages de chat — dans la file d’attente de messages en utilisant des clés de routage appropriées, comme "game.{game_id}.event" or "player.{player_id}.action"

Voici comment ça fonctionnerait :

• Quand 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 en particulier.
• Chaque fois que les joueurs interagissent, que ce soit en se croisant sur la même carte, en s’envoyant des messages ou en s’affrontant au combat, ils s’abonnent aux événements les uns des autres.
• Un « notification_service » s’abonnerait aux sujets pertinents pour collecter les événements qui déclenchent des notifications, comme réaliser un meilleur score, recevoir une demande d’ami ou démarrer une nouvelle partie. Ce service générerait ensuite des notifications et les transmettrait aux appareils des joueurs via un service de notifications push.

Dans ce scénario, une garantie de livraison « au moins une fois » est essentielle pour s’assurer qu’aucun événement de jeu critique ni aucune notification ne soit perdu. Le modèle de messagerie serait de type « plusieurs-à-plusieurs », car plusieurs joueurs interagissent entre eux et avec le serveur de jeu. Dans le domaine du jeu vidéo, la latence est très importante, donc un modèle 2PC n’est pas adapté. Un modèle « saga », en revanche, peut garantir la cohérence des données entre les différents services de jeu.

Cas d’utilisation n° 3 : Équilibrage de charge

Un équilibreur de charge recevrait dans un premier temps toutes les requêtes entrantes. Au lieu de les transférer directement vers les serveurs backend, l’équilibreur de charge publierait chaque requête sous forme de message dans la file d’attente de messages. Plusieurs instances de travailleurs s’abonneraient à cette file d’attente, consommant les messages et traitant les requêtes. La file d’attente de messages répartit efficacement la charge de travail entre les travailleurs disponibles, garantissant qu’aucun serveur ne soit surchargé. Cette approche offre également une résilience : si un travailleur tombe en panne, le message reste dans la file d’attente pour qu’un autre travailleur puisse le prendre en charge.

Une clé de routage adaptée à ce scénario pourrait être « request.process », ce qui permettrait à l’avenir de prioriser ou de filtrer les requêtes. Une garantie de livraison « au moins une fois » est nécessaire pour s’assurer qu’aucune requête ne soit perdue à cause d’une défaillance d’un worker. Il est clair que le modèle de messagerie utilisé ici est de type « un-à-plusieurs », puisqu’un seul message de requête est traité par l’un des nombreux workers disponibles.

Cas d’utilisation n° 4 : flux de données

Imaginons que tu veuilles suivre toutes les modifications de la base de données : un connecteur Debezium est déployé à côté d’une base de données pour capturer ses modifications. Ces modifications sont transformées en événements et publiées dans une file d’attente de messages. La file d’attente de messages sert de plaque tournante centrale pour distribuer ces événements de modification à 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 en vue d’analyses en temps réel.

Une stratégie de clé de routage adaptée pourrait être « database.{db_name}.{table_name}.{operation} », ce qui permet aux abonnés de filtrer les événements en fonction de la base de données, de la table ou du type d’opération (création, mise à jour, suppression) spécifiques.  Une garantie de livraison « au moins une fois » est importante pour s’assurer qu’aucune modification de la base de données ne passe inaperçue dans l’entrepôt de données. Le modèle de messagerie est ici généralement de type « un-à-plusieurs », car un seul événement de modification de la base de données peut concerner 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 l’exploitation des files d’attente de messages ne devraient pas nécessiter une équipe DevOps dédiée. Upsun transforme les opérations complexes liées aux files d’attente de messages en processus simples et conviviaux pour les développeurs, ce qui te permet de te concentrer sur le développement de fonctionnalités plutôt que sur la gestion de l’infrastructure.

Déploiement en quelques minutes

La mise en place 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. Tu passeras des jours à installer des logiciels, à configurer les autorisations des utilisateurs, à mettre en place des certificats SSL, à configurer le clustering pour la haute disponibilité, à configurer la surveillance et les alertes, à mettre en place des sauvegardes automatisées et à renforcer la sécurité.

Avec Upsun, il te suffit de définir tes besoins dans un fichier de configuration, et on s’occupe de tout le reste. En quelques minutes, tu disposes d’une file d’attente de messages prête à l’emploi, avec mise en cluster automatique, chiffrement SSL, surveillance, sauvegardes et correctifs de sécurité déjà configurés.

Teste avec de vraies données de production

Le plus gros défi avec les files d’attente de messages, c’est que les environnements de développement locaux ne peuvent pas reproduire le comportement en production. Des messages qui fonctionnent parfaitement sur ton ordinateur portable peuvent échouer de manière spectaculaire avec des volumes et des schémas de données réels.

Upsun résout ce problème grâce à un clonage parfait de l’environnement. Tu peux créer instantanément une copie complète de ton 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, ainsi que des données identiques à celles de production qui peuvent être anonymisées si tu le souhaites.

Exemple : une entreprise de e-commerce devait tester un nouveau système de traitement des commandes pendant sa période de forte activité. Au lieu d’essayer de deviner comment il fonctionnerait, elle a cloné son environnement de production avec les volumes de messages réels du Black Friday. Elle a ainsi découvert et corrigé trois goulots d’étranglement avant le déploiement, évitant ainsi un éventuel temps d’arrêt lors de sa journée la plus lucrative.

Surveillance intelligente 

La plupart des outils de surveillance t’indiquent qu’il y a un problème, mais ne te disent pas comment y remédier. Une surveillance traditionnelle pourrait t’indiquer « Profondeur de la file d’attente : 10 000 messages » ou « Retard du consommateur : 5 minutes » sans expliquer ce que cela signifie ni comment y remédier.

L’observabilité intégrée d’Upsun fournit des informations exploitables. Au lieu de métriques obscures, tu obtiens des descriptions claires des problèmes, comme « Les messages de paiement sont traités dans le désordre », accompagnées de solutions suggérées telles que « Activer le mode consommateur unique actif » et d’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 saturer ton système. Upsun adapte automatiquement la capacité de tes files d’attente de messages en fonction de la demande en temps réel.

En temps normal, tes files d’attente fonctionnent avec un minimum de ressources pour réduire les coûts. En cas de pics de trafic, le système s’adapte instantanément pour gérer la charge. Une fois le pic passé, les ressources sont automatiquement réduites. Tu ne paies que ce que tu utilises.

Intégration à ton processus de développement

Les files d’attente de messages Upsun s’intègrent parfaitement à tes outils et processus existants.

Chaque modification apportée à la configuration de ta file d’attente de messages passe par ton processus habituel de révision du code grâce à une configuration basée sur Git, ce qui élimine les « divergences de configuration » entre les environnements. Les détails de connexion aux files d’attente sont automatiquement injectés dans tes applications sous forme de variables d’environnement, ce qui évite d’avoir à coder en dur les identifiants ou à mettre à jour manuellement la configuration.

Tu peux consulter les métriques de ton application, les performances de ta base de données et l’état de santé de ta file d’attente de messages dans un tableau de bord unique, ce qui t’évite de jongler entre plusieurs outils de surveillance.

Conclusion

Les files d’attente de messages sont devenues la colonne vertébrale des applications modernes et évolutives, mais leur mise en œuvre et leur gestion ne devraient pas ralentir ton processus de développement. Si les concepts sont simples, la complexité opérationnelle liée à l’exploitation des files d’attente de messages en production peut rapidement devenir écrasante.

Gérer les garanties de livraison, la durabilité, la persistance et l’ordre de traitement entre différentes technologies de files d’attente de messages est complexe et source d’erreurs. Chaque broker a ses propres subtilités 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’Upsun entre en jeu. En tant que plateforme d’applications cloud axée sur les développeurs, Upsun te libère de ce fardeau opérationnel en fournissant des configurations préconfigurées et éprouvées en production, tant pour RabbitMQ que pour Kafka, qui gèrent d’emblée les problèmes de durabilité, de persistance et d’ordre des messages. Que tu aies besoin de RabbitMQ pour des scénarios de routage complexes ou de Kafka pour un streaming à haut débit, Upsun fournit des services entièrement gérés avec mise à l’échelle, surveillance et maintenance automatiques.

La surveillance intégrée d’Upsun va au-delà des simples métriques : elle t’indique exactement quand les messages sont traités dans le désordre ou quand les garanties de durabilité ne sont pas respectées, avant même que tes clients ne s’en aperçoivent. Grâce au processus basé sur Git et au clonage instantané d’environnements d’Upsun, tu peux tester tes configurations de files d’attente de messages avec des données proches de celles de production avant le déploiement, ce qui élimine les approximations qui mènent souvent à des problèmes en production.

Prêt à mettre en place des files d’attente de messages sans te prendre la tête avec l’exploitation ? Commence dès aujourd’hui à développer avec Upsun et concentre-toi sur ce qui compte le plus : la logique de ton application, pas la gestion de l’infrastructure.