Architecture événementielle sur AWS, Partie I : les bases

Les composants d'un système événementiel communiquent en publiant des événements et en s'y abonnant. L'intégration asynchrone offre des avantages non fonctionnels considérables. Elle découple par exemple les cycles de vie des composants intégrés. Dans une certaine mesure, le système peut continuer à fonctionner même lorsque certains de ses services sont indisponibles, ce qui réduit aussi la coordination nécessaire pour déployer des composants mis à jour et faire évoluer l'ensemble.

Une intégration événementielle de base se compose de deux volets : un composant du système peut publier des événements décrivant les faits marquants de son cycle de vie, et il peut réagir (s'abonner) aux événements publiés par d'autres parties du système. Voyons quels services managés nous pouvons exploiter pour mettre cela en œuvre.

AWS Simple Notification Service (SNS) est un service entièrement managé qui permet d'envoyer des notifications destinées à être consommées par d'autres composants du système. Sa nature serverless et sa tarification réduite font de SNS un excellent candidat pour la publication d'événements. La figure 1 illustre un service nommé Producer qui publie ses événements via un topic SNS.

Figure 1 : le service Producer publie des événements vers un topic SNS.

Mais qu'en est-il du service Consumer à droite de la figure ? Comment peut-il s'abonner aux messages publiés par le Producer ?

SNS prend en charge la livraison des messages via plusieurs protocoles : HTTP, déclenchement de fonctions AWS Lambda, SMS, etc. Sur le papier, on pourrait imaginer que le Consumer expose un endpoint HTTP et l'utilise comme destination du topic SNS, comme illustré à la figure 2.

Figure 2 : un topic SNS peut transférer des messages vers des endpoints HTTP. Mais est-ce la solution optimale ?

Est-ce vraiment la meilleure approche ? Si les deux services, Producer et Consumer, appartiennent à des équipes différentes, qui est responsable du topic SNS ? L'équipe Producer doit veiller à ce que le topic soit correctement configuré pour recevoir ses messages, tandis que les équipes en charge des services consommateurs doivent s'assurer que les destinations restent toujours valides. Une telle responsabilité partagée est une source de friction garantie. Envisageons une autre option.

AWS SQS est une file d'attente d'événements entièrement managée qui conserve temporairement les messages (événements) générés par les producteurs jusqu'à ce qu'ils soient traités par les consommateurs. Elle permet une gestion distribuée des événements avec un équilibrage de charge entre plusieurs consommateurs, indispensable pour maintenir la tolérance aux pannes dans les workflows événementiels. À mon sens, elle offre aussi une bien meilleure visibilité sur les files d'attente que les topics SNS, ainsi qu'un contrôle pratique sur la manière dont les messages sont livrés aux consommateurs.

Puisque SQS fait partie des destinations prises en charge par les topics SNS, mettons en place une file d'attente pour les messages destinés aux services Consumer, comme illustré à la figure 3.

Figure 3 : utilisation de SQS comme mécanisme de consommation d'événements.

Avec cette configuration, les frontières de responsabilité sont nettes :

• Le topic SNS utilisé pour publier les messages appartient à l'équipe en charge du service d'origine (Producer).
• La file d'attente SQS utilisée pour consommer les messages appartient à l'équipe en charge du service abonné (Consumer).

Cette séparation des responsabilités entre les deux services doit se refléter dans l'architecture du système.

Il est largement admis qu'un microservice doit donner accès à ses données via une interface publique bien définie, sa base de données étant un détail d'implémentation à masquer aux consommateurs. Cette encapsulation stricte du mécanisme de persistance permet de tracer des frontières de responsabilité plus nettes, d'avoir davantage de souplesse pour faire évoluer les microservices et un bien meilleur contrôle sur les interfaces publiques.

Le bus de messages utilisé par le système n'est qu'un autre mécanisme de persistance — bien plus limité, certes — et doit être traité comme tel. Par conséquent, en plus d'une base de données, chaque (micro)service a besoin d'un topic SNS pour publier des événements et d'une file d'attente SQS pour les consommer, comme illustré à la figure 4 :

Figure 4 : une EDA exige de définir des frontières de responsabilité claires non seulement pour les bases de données, mais aussi pour leurs mécanismes de messagerie (SNS et SQS).

Les flèches entre les services — les abonnements reliant les topics aux files d'attente — relèvent d'un niveau d'abstraction architectural supérieur à celui des services eux-mêmes. On peut par exemple imaginer un template CloudFormation pour chaque service individuel et un template CloudFormation de plus haut niveau pour le système qui en résulte. C'est ce dernier qui définit les abonnements.

Il est important de noter qu'un abonnement ne signifie pas que tous les événements publiés sont déversés aveuglément sur les consommateurs : un abonnement peut spécifier un filtre pour ne transmettre que les événements pertinents à chaque consommateur.

Cette approche s'aligne sur le principe smart endpoints, dumb pipes, essentiel à la simplicité et à la flexibilité des systèmes distribués. Selon ce principe, l'intelligence — la logique — doit résider dans les services eux-mêmes (les endpoints), et non dans les composants d'infrastructure utilisés pour l'intégration (les pipes). Les pipes — l'infrastructure de messagerie et les canaux de communication — doivent se contenter de transporter les données entre les services de manière fiable. L'objectif est de réduire les dépendances entre services, ce qui facilite le scaling, le débogage et accélère le développement, tout en évitant les goulets d'étranglement et la complexité généralement associés aux middlewares sophistiqués.

Il est temps d'évoquer les autres options de messagerie disponibles sur AWS.

Comme indiqué en introduction, il existe de nombreuses autres solutions managées AWS dédiées à la messagerie. J'aborde ici brièvement ces alternatives et j'explique pourquoi, à mon sens, la solution décrite plus haut convient mieux dans 80 % des cas.

Le premier S de SNS et SQS signifie simple, et ce n'est pas un hasard. SNS et SQS sont des services simples. EventBridge, lui, offre bien plus de flexibilité en matière de filtrage et de règles de routage des messages. À mon sens, il se rapproche davantage du concept de bus de messages d'entreprise hérité de l'époque SOA. Au lieu de dumb pipes, vous obtenez un point central pour recevoir et router les événements à travers tous les composants du système, voire entre plusieurs systèmes. EventBridge a bien sûr ses cas d'usage — par exemple lorsqu'il faut s'intégrer à des systèmes tiers.

Kinesis et MSK sont tous deux des services dédiés au traitement de données en streaming. On peut considérer le streaming de données comme un sous-ensemble de l'architecture événementielle. Les deux impliquent de manipuler des messages publiés et consommés de manière asynchrone. Le mode d'utilisation diffère toutefois : alors que l'EDA traditionnelle se concentre sur des événements ou des messages individuels, le streaming consiste à traiter des flux continus d'événements liés, ce que les solutions classiques de bus de messages ne gèrent pas toujours efficacement. D'où l'existence d'outils comme Kinesis et MSK. Si vous n'avez pas besoin de traiter des flux continus de messages, des outils plus simples comme SNS et SQS donneront un système plus limpide.

Amazon MQ est un service de courtier de messages managé pour des protocoles comme ActiveMQ et RabbitMQ. Il est particulièrement utile pour migrer des systèmes legacy vers le cloud ou pour des systèmes qui doivent fonctionner sans modification dans plusieurs environnements cloud. Amazon MQ offre certes un courtier de messages complet, avec la prise en charge de patterns avancés, mais il implique une charge opérationnelle et une complexité supérieures à la simplicité de SNS et SQS.

1. Architecture événementielle sur AWS, Partie I : les bases (article actuel)
2. Architecture événementielle sur AWS, Partie II : les bases avancées
3. Architecture événementielle sur AWS, Partie III : les bases ardues

Publié initialement sur https://vladikk.com .