Orientation sur la messagerie asynchrone

Sur cette page

1. Concevoir des points d’extrémité intelligents et des canaux simples
2. Rechercher la messagerie atomique
3. Renforcer la résilience
4. Sécuriser le canal
5. Découpler à l’échelle de toutes les couches
6. Améliorer et appuyer l’interface tout au long de son cycle de vie

La messagerie asynchrone permet l’échange de données entre les systèmes et est largement utilisée dans l’ensemble du gouvernement du Canada (GC). Le présent document d’orientation vise à guider les spécialistes techniques (p. ex., les développeurs et les architectes de l’intégration) dans l’élaboration de messages asynchrones à l’échelle du GC afin de mieux appuyer les processus numériques intégrés dans les ministères et organismes.

• Qu’est-ce que la messagerie asynchrone? La messagerie asynchrone est une forme de messagerie « send-and-forget » (envoi-oubli) où les messages sont envoyés et où aucune réponse immédiate n’est requise pour le traitement.
• Pourquoi est-ce important? L’utilisation de files d’attente pour transmettre des messages sans attendre de réponse peut être extrêmement efficace pour communiquer de grandes quantités de données tout en réduisant les dépendances entre les systèmes. Il convient de prendre soin de concevoir des systèmes de messagerie, car leur utilisation peut devenir extrêmement difficile et coûteuse lorsque trop de complexité est introduite.
• Quand devrais-je utiliser ce type de messagerie? Les cas d’utilisation idéale pour la messagerie asynchrone incluent des notifications pour plusieurs systèmes consommateurs. Souvent, ces notifications indiquent que de nouvelles données sont disponibles ou que les données existantes ont changé. Les consommateurs décident ensuite si la notification exige d’autres mesures et un suivi en conséquence, peut-être en demandant des renseignements à jour à partir d’une API ou en modifiant simplement un enregistrement local pour tenir compte des nouveaux renseignements.
• Comment mettre en œuvre la messagerie asynchrone? Le présent document d’orientation fournit les pratiques exemplaires à suivre lors de la conception et de la mise en œuvre de solutions de messagerie asynchrone afin de réduire au minimum la complexité opérationnelle et les coûts tout en maximisant la souplesse de l’intégration entre les systèmes. Ces mises en œuvre peuvent être effectuées à l’aide du courtier d’événements ou des solutions du bus de service.
• Dois-je utiliser la messagerie asynchrone pour tous mes échanges de données? Vous ne devez pas utiliser la messagerie asynchrone pour tous vos échanges de données. Utilisez-la plutôt pour les cas où vous avez de petits événements et des données contenus qui n’exigent pas de réponse immédiate, comme une notification d’événement ou un petit paquet de données de capteurs. Le GC reconnaît le besoin de nombreux styles d’intégration, allant des interfaces de programmation d’applications (API) au transfert de fichiers en bloc. Veuillez également consulter les Normes du gouvernement du Canada sur les API pour en savoir plus sur la mise en œuvre des API.

1. Concevoir des points d’extrémité intelligents et des canaux simples

La complexité et la logique doivent être poussées vers les applications sur les bords et ne doivent pas être encapsulées dans l’infrastructure de file d’attente ou de messagerie. Cette conception garantit que la logique reste dans la couche d’application et réduit au minimum le nombre de parties impliquées dans le dépannage des erreurs de traitement. En particulier :

• Mettre en œuvre le routage basé sur les paramètres – Les expéditeurs de messages doivent définir les paramètres nécessaires (p. ex., le type d’événement, les en-têtes de routage) pour déterminer comment le message doit être acheminé. Le routage dans la plate-forme de messagerie doit être basé sur ces paramètres plutôt que sur une logique codée en dur dans l’infrastructure de messagerie.
• Translater et transformer les données aux points d’extrémité – Toute transformation ou translation de données doit être effectuée par les points d’extrémité d’envoi et de réception et non dans l’infrastructure de messagerie elle-même. Si la logique de transformation ou de translation doit être externe au code d’application d’envoi ou de réception, elle doit être mise en œuvre en tant qu’application indépendante gérée séparément de l’infrastructure de messagerie.
• Éviter les transactions distribuées – Les transactions distribuées (p. ex., les transactions XA) sont puissantes lorsqu’elles tentent de coordonner des mises à jour simultanées ou connexes sur plusieurs systèmes, mais sont extrêmement difficiles à résoudre en cas de défaillance. La préférence est de concevoir des systèmes qui n’exigent pas de transactions distribuées et qui peuvent tolérer une cohérence éventuelle.
• Éviter la logique dans la couche de messagerie – La couche de messagerie (c’est-à-dire, l’infrastructure de messagerie) ne devrait être responsable que du routage et de la livraison des messages. Toute logique opérationnelle comme la validation des données ou le traitement conditionnel (p. ex., la vérification des charges utiles pour les valeurs Null) doit être mise en œuvre par l’expéditeur ou le destinataire. Voir aussi la note de traduction ci-dessus.

2. Rechercher la messagerie atomique

L’interaction de messagerie doit être aussi atomique que possible. L’assemblage d’une transaction entre les messages et les files d’attente crée une complexité et un risque plus élevé d’échec. Les pratiques suivantes doivent être appliquées :

• Ne pas orchestrer le traitement entre des files d’attente – Si un processus exige l’envoi de messages entre plusieurs files d’attente, puis le réassemblage par le récepteur, il doit être restructuré pour utiliser une seule file d’attente. La coordination des interdépendances entre files d’attente devient exponentiellement complexe lorsque des défaillances se produisent et qu’une seule file d’attente indisponible peut sauvegarder toutes les autres files d’attente liées au même processus.
• Limiter l’utilisation de la livraison chronologique – Même si la plupart des solutions d’infrastructure de messagerie offrent des capacités de livraison chronologique, la possibilité de garantir à 100 % la livraison chronologique de bout en bout est presque impossible. Cette difficulté est due aux nombreux parcours que peuvent emprunter les messages entre l’expéditeur et le destinataire (p. ex., équilibrage de charge, chemins réseau). Par conséquent, il faut éviter de dépendre de la livraison chronologique, sauf si cela est absolument nécessaire. Si la livraison chronologique ne peut pas être évitée, assurez-vous toujours que les ID de regroupement et d’ordre de message sont attribués à ces messages afin que le destinataire puisse les réassembler correctement sans se fier uniquement à l’infrastructure de messagerie pour gérer l’ordre. Les regroupements de messages doivent également être gardés aussi petits que possible, et l’on doit éviter les groupes illimités, car les messages non chronologiques provoqueront la conservation en mémoire de tous les autres messages jusqu’à la restauration de l’ordre.
• Éviter les files d’attente ou les sujets génériques – Les files d’attente ou les sujets doivent être mappés à un type d’événement unique ou à une seule entité professionnelle pour permettre un contrôle granulaire des flux de routage. Les files d’attente ou les rubriques génériques qui transportent plusieurs types d’événements ou d’entités entraînent une logique de routage plus complexe qui crée une charge opérationnelle excessive.

3. Renforcer la résilience

Les points d’extrémité, en particulier les expéditeurs, doivent supposer que l’infrastructure de messagerie ou de file d’attente échouera à un moment donné. La résilience doit donc être intégrée aux paramètres pour faire face à des scénarios de défaillance potentiels et ne doit pas assumer la fiabilité absolue de l’infrastructure de messagerie ou de file d’attente. Les considérations suivantes doivent être prises en considération :

• Mettre en œuvre une nouvelle tentative à l’expéditeur – Les expéditeurs de messages doivent mettre en œuvre une logique appropriée au cas où l’infrastructure de messagerie n’est pas disponible.
• Mettre en œuvre des récepteurs idempotents – La prestation unique de bout en bout (c’est-à-dire, la livraison unique) est impossible à garantir comme telle. Une approche plus résiliente consiste à mettre en œuvre les récepteurs de messages de manière à ce que les messages en double (c’est-à-dire, les renvois) ne nuisent pas au système. Les files d’attente doivent donc être configurées pour effectuer une livraison au moins une fois.
• Mettre en œuvre des files d’attente ou sujets durables et persistantes – Les files d’attente persistantes assurent le stockage temporaire des messages jusqu’à ce qu’ils soient livrés correctement. Des files d’attente durables garantissent que ces messages survivraient à un redémarrage de l’infrastructure de file d’attente. À moins que les messages ne soient jetables, il est recommandé que toutes les files d’attente et les sujets soient configurés de façon à être persistants et durables.
• Attribuer des magasins de persistance en fonction des volumes de pointe et des périodes d’interruption – Les files d’attente qui exigent une livraison garantie des messages doivent être configurées comme persistantes. Le stockage persistant de ces files d’attente doit être dimensionné en fonction de la formule suivante afin de réduire au minimum le risque de perte de messages en cas d’interruptions possibles :
  • Taille maximale du message x Nombre maximal de messages/heure x Période maximale d’interruption prévue (en heures)
• Mettre en œuvre les files d’attente de remise et de lettres mortes de façon appropriée – Toutes les files d’attente persistantes doivent également être mises en œuvre avec les files d’attente de remise et de lettres mortes pour décharger les messages ayant échoué de la file d’attente principale. Cette configuration garantit que les échecs propres à un message n’arrêtent pas la file d’attente.
• Mettre en œuvre des processus opérationnels pour les échecs de messages – Les échecs de messages se produiront certainement. L’expéditeur et les destinataires de messages doivent s’entendre sur des processus opérationnels pour surveiller, cerner et traiter les messages ayant échoué avant le déploiement des intégrations.

4. Sécuriser le canal

La sécurité doit être une priorité lorsque l’on conçoit et met en œuvre des interfaces. Les pratiques suivantes doivent être suivies pour toute intégration de messagerie asynchrone autre que celles qui exposent des données publiques (p. ex., des données ouvertes). Il est important de prendre note que ces pratiques doivent fournir un ensemble de mesures de sécurité de base. D’autres mesures (p. ex., le chiffrement au niveau du message, l’authentification mutuelle et les signatures numériques) peuvent être requises en fonction du niveau de sensibilité des données et de vos propres exigences ministérielles.

• Appliquer le chiffrement de transport – Le protocole TCP non chiffré est interdit dans le GC. Toutes les pratiques de chiffrement doivent respecter la Mise en œuvre de HTTPS pour les connexions Web sécurisées : Avis de mise en œuvre de la Politique sur la technologie de l’information (AMPTI) et l’Orientation sur l’utilisation sécurisée des services commerciaux d’informatique en nuage : Avis de mise en œuvre de la Politique sur la sécurité (AMOPS).
• Protéger les points d’extrémité – L’authentification des expéditeurs de messages et des destinataires doit être utilisée, avec au moins l’authentification de l’expéditeur pour les données ouvertes et les files d’attente non classifiées. Le chiffrement des messages et la signature au niveau de l’application en dehors de l’infrastructure de file d’attente sont également encouragés.
• Mettre en œuvre l’authentification fondée sur les certificats dans la mesure du possible – La messagerie asynchrone est principalement utilisée pour les intégrations principales entre les machines et n’implique pas les utilisateurs. Les certificats fournissent une meilleure façon de gérer l’authentification entre des machines au lieu du nom d’utilisateur et des mots de passe, et doivent donc être mis en œuvre chaque fois que le protocole ou l’infrastructure de file d’attente le prend en charge.

5. Découpler à l’échelle de toutes les couches

La messagerie asynchrone ne fournit pas automatiquement un couplage faible. Au lieu de cela, le couplage faible est réalisé grâce à une conception et une mise en œuvre adéquates dans tous les niveaux d’application et de données. Les pratiques suivantes doivent être suivies lors de la définition de votre intégration :

• Mettre en œuvre une couche de translation de protocole si possible – Les protocoles de file d’attente de messages sont moins normalisés que ceux utilisés par les API. Par conséquent, la nécessité de prendre en charge plusieurs protocoles est nécessaire pour assurer une souplesse et une compatibilité futures. Les expéditeurs et les récepteurs doivent mettre en œuvre une forme quelconque de couche de translation ou utiliser des connecteurs technologiques de sorte que le code d’application ne soit pas étroitement couplé au protocole de messagerie. Cela permet également de veiller à ce que les systèmes de l’ensemble du GC puissent interagir sur la messagerie sans qu’il soit nécessaire de s’entendre sur un protocole commun unique, et que les changements de protocole n’exigent pas de modifications aux applications connectées.
• Utiliser les notifications et les événements – La messagerie est plus efficace lorsque les charges utiles de données sont petites et atomiques. Par conséquent, il est préférable d’envoyer des notifications et des événements (p. ex., nouvel employé) plutôt que des jeux de données complexes (p. ex., nouveau dossier d’emploi avec nouveau dossier d’employé). Ce principe est particulièrement vrai lorsque des jeux de données différents sont générés en fonction du contexte d’un événement donné (p. ex., l’employé qui rejoint un poste existant plutôt qu’un nouveau poste). Les destinataires de notifications ou d’événements peuvent alors faire des appels d’API au besoin pour que l’expéditeur récupère le jeu de données approprié en fonction du contexte précis de l’événement. Cette conception est beaucoup plus efficace que celle où l’expéditeur de message tente d’anticiper toutes les permutations du jeu de données qui pourraient être nécessaires et qui découple véritablement les responsabilités de l’expéditeur des exigences de traitement du destinataire.
• Exploiter le courtier d’événements du GC – Utiliser l’infrastructure du courtier d’événements du GC pour la messagerie asynchrone entre les ministères et organismes du GC, dans la mesure du possible.

6. Améliorer et appuyer l’interface tout au long de son cycle de vie

Les interfaces de messagerie changeront au fil du temps en fonction de l’évolution des besoins du système et des utilisateurs. À titre de pratique exemplaire, ce changement devrait être appuyé et géré de façon appropriée au moyen des pratiques suivantes :

• Messages de version et files d’attente – Il faut établir une version à toutes extensions du schéma de message. Toute modification du schéma de message qui ne peut pas être mise en œuvre en tant qu’extension (c’est-à-dire, non rétrocompatible) doit aboutir à un tout nouveau type de message. Toute modification du comportement de file d’attente associée à une modification de schéma (p. ex., routage, niveau de validation, paramètres de persistance, gestion des erreurs) doit donner lieu à une nouvelle version de file d’attente. Les versions doivent être un seul numéro (p. ex., v1).
• Respecter les dépendances actuelles des consommateurs – Appuyer au moins une version principale précédente (c’est-à-dire, N-1) pendant plusieurs mois afin de veiller à ce que les systèmes destinataires aient le temps de migrer vers la dernière version du message ou de la file d’attente. Communiquez votre feuille de route de développement aux équipes destinataires et travaillez avec elles pour comprendre l’incidence de tout changement majeur. Établissez des politiques de dépréciation et des calendriers clairs dès le départ afin que les destinataires comprennent combien de temps ils doivent passer à chaque nouveau lancement avant que l’ancienne version ne soit hors ligne. Coordonnez les essais nécessaires sur tous les lancements.
• Fournir un point de contact – Fournissez un point de contact désigné à toutes les équipes recevant des messages de votre file d’attente. Si la file d’attente est disponible pour une utilisation pangouvernementale, fournissez un compte de courriel de soutien. Un numéro de téléphone doit également être fourni pour les files d’attente critiques.
• Définissez un ANS dès le départ – Chaque file d’attente doit être accompagnée d’un accord sur les niveaux de service (ANS) clairement définie. À tout le moins, l’ANS doit définir ce qui suit :
  • Heures de soutien (p. ex., 24 heures sur 24, de 9 h à 17 h, heures de bureau d’un océan à l’autre)
  • Disponibilité du service (p. ex., 99 %)
  • Temps de réponse du soutien (p. ex., dans l’heure, 24 heures, meilleur effort)
  • Pannes prévues (p. ex., nuit, semaine, tous les deux dimanches en soirée)
  • Limite du débit de traitement (p. ex., 100 demandes par seconde par destinataire)
  • Limite de la taille du message (p. ex., < 500 Ko par message)