Stratégie de migration d’un bus maison vers RabbitMQ
- Mise en place de projets de migrations
- L’existant
- Les raisons de la migration vers RabbitMQ
- Les défis
- Stratégie de migration vers RabbitMQ
- Conclusion
Mise en place de projets de migrations vers RabbitMQ
Les projets de migration sont critiques et font face à de nombreux défis. Pour les relever, il ne suffit pas juste d’être expert. Il faut bien les préparer par une étude afin de définir la meilleure stratégie de mise en place, et à moindre coût.
Dans cet article, je vais vous présenter la stratégie de migration d’un bus de messages maison (“agent de messages” ou “message broker”) vers RabbitMQ, à laquelle j’ai contribué chez mon client.
L’existant
La communication entre les différentes applications se fait en mode asynchrone où les messages échangés entre le producteur et le consommateur passent par un bus applicatif fait maison.
Les raisons de la migration vers RabbitMQ
Trois raisons principales ont favorisé ce projet :
- L’absence d’interface homme-machine
La présence d’une interface homme-machine pour administrer le bus de messages est très utile dans une architecture micro-service avec une communication asynchrone.
Elle permet de suivre la charge sur les différentes queues et de vérifier la consommation des messages. L’ancien bus est dépourvu de cette fonctionnalité et le coût de la mise en place de cette dernière est très élevé.
- La maintenabilité
Le bus maison nécessite des évolutions à chaque introduction d’une nouvelle queue de données.
Dans un contexte où il faut être productif sur l’aspect fonctionnel, les tâches techniques de maintenance représentent un surcoût, non seulement en matière de développement, mais aussi en matière de nombre de mises en production.
- La robustesse et la performance
Pour transporter les messages, le bus maison utilise le protocole HTTP (Hyper Text Transfer Protocol).
Ce protocole n’est pas capable de réagir au problème de panne serveur et n’a aucune garantie pour livrer les données, ce qui augmente le risque de perte de messages.
De plus, le protocole HTTP est n’est pas capable segmenter les données envoyées. En cas de forte charge, ce protocole met plus de temps à transporter les messages par rapport à d’autres protocoles connus par la segmentation comme AMQP (“Advanced Message Queuing Protocol”).
Les défis
Avant de définir le plan de migration vers RabbitMQ, plusieurs challenges sont à surmonter :
- Eviter la perte de productivité :
Les utilisateurs sont de plus en plus pointilleux, il faut limiter les indisponibilités. L’entreprise ne peut pas se permettre de mettre en standby ses opérations trop longtemps à cause d’une migration.
- Pallier le risque de perte de messages
La migration vers RabbitMQ ne doit pas être à l’origine d’une perte de messages. La stratégie à concevoir doit anticiper l’arrivée de messages au moment de la mise en production et doit être capable de les transporter du producteur au consommateur une fois la bascule terminée.
- Migration fractionnée :
Cette migration doit être progressive afin de contrôler le périmètre des mises en production. Ainsi, le plan de migration vers RabbitMQ doit faire cohabiter l’ancien et le nouvel agent de messages.
Stratégie de migration vers RabbitMQ
Voici les étapes qui nous ont permis de faire la transition entre notre message broker maison et RabbitMQ :
- Développer une sortie dans l’ancien bus de messages dirigé vers RabbitMQ
Cette étape consiste à développer un nouveau point de sortie dans l’ancien bus de messages adapté à RabbitMQ afin d’assurer la communication entre eux et ainsi pouvoir rediriger les messages vers le broker cible (RabbitMQ).
Quand un message est envoyé par une application émettrice, il est intercepté par l’ancien bus de messages et transmis vers l’application réceptrice et RabbitMQ.
Les messages reçus par RabbitMQ ne sont pas persistés : une queue ne se crée qu’après avoir une application réceptrice ayant une entrée adaptée à RabbitMQ. Cela permet d’éviter la double consommation d’un message.
- Migrer les deux applications (émettrice et réceptrice) vers RabbitMQ
Cette épate consiste à adapter la sortie de l’application émettrice et l’entrée de l’application réceptrice afin de communiquer à travers RabbitMQ.
- Mettre en production l’application réceptrice puis émettrice
Cette étape est critique pour déterminer le succès de la migration vers RabbitMQ. Avant de faire la mise en production, il faut bien vérifier que les messages émis par l’application émettrice sont bien consommés par l’application réceptrice.
À ce moment, il faut d’abord commencer par mettre en production l’application réceptrice puis l’application productrice.
“Mais pourquoi ?” : Si un message est envoyé par l’application émettrice au moment de la mise en production de l’application réceptrice, il sera intercepté par l’ancien agent de messages qui le redirige vers RabbitMQ, et ce dernier le transfère vers l’application réceptrice.
Conclusion
Ce projet est actuellement dans ses dernières phases. Il a montré des signes de succès pour les micro-services qui ont déjà effectué leur migration vers RabbitMQ.
Cette réussite est due non seulement à la stratégie mise en place en amont, mais aussi à l’implication des développeurs et des POs dans le choix des applications à migrer dans chaque lot de ce projet.
Malgré la préparation, l’équipe était tout de même face à quelques imprévus : nombreuses était les mises en production reportées à cause de la quantité de messages non consommés sur l’ancien bus afin d’éviter leur perte.
Les migrations des agents de messages sont très connues pour leurs risques de perte de données, de dépassements de budget et de délai. La mise en place d’une stratégie efficace en amont réduit fortement ces risques et constitue une feuille de route pour cadrer ce type de projet.