Qu'est-ce qu'une architecture basée sur les événements (EDA) ?
L'architecture basée sur les événements (EDA) est un modèle d'architecture moderne créé à partir de petits services découplés qui publient, consomment ou acheminent des événements.
Un événement représente un changement d'état ou une mise à jour. Par exemple : un article placé dans un panier d'achats, un fichier chargé vers un système de stockage ou une commande prête à être expédiée. Les événements peuvent porter l'état (tel que le nom, le prix ou la quantité d'un article dans une commande) ou simplement contenir des identifiants (par exemple « la commande n° 8942 a été expédiée ») nécessaires pour rechercher des informations connexes.
Contrairement aux modèles traditionnels axés sur les requêtes, EDA favorise un couplage faible entre les services producteurs et consommateurs. Il est ainsi plus facile de mettre à l'échelle, de mettre à jour et de déployer indépendamment des composants séparés d'un système.
Pourquoi une architecture découplée est-elle importante ?
De nombreuses entreprises estiment que les applications, bases de données et technologies monolithiques ont un impact négatif sur l'innovation et l'amélioration de l'expérience utilisateur. Les applications et bases de données héritées réduisent vos possibilités d'adopter des cadres technologiques modernes et limitent votre compétitivité et votre capacité d'innover. En revanche, lorsque vous modernisez les applications et leurs entrepôts de données, elles deviennent plus faciles à adapter et plus rapides à développer.
Une stratégie de données découplées améliore la tolérance aux pannes et la résilience, ce qui permet d'accélérer la mise sur le marché (TTM) des nouvelles fonctions de vos applications.
Pour en savoir plus sur les avantages de la modernisation des applications monolithiques, reportez-vous à Autoriser la persistance des données dans les microservices dans Recommandations AWS.
Quels sont les avantages de l'architecture basée sur les événements (EDA) ?
L'architecture basée sur les événements (EDA) favorise un couplage faible entre les composants d'un système, entraînant une plus grande agilité. Les microservices peuvent être mis à l'échelle de façon indépendante, échouer sans affecter les autres services et réduire la complexité des flux. Les événements peuvent être acheminés, mis en mémoire tampon et journalisés de façon flexible à des fins d'audit. Les flux d'événements à technologie Push peuvent opérer en temps réel, réduisant les coûts liés à la création et à l'exploitation du code qui interroge continuellement les systèmes pour détecter les changements.
Mise à l'échelle et panne indépendantes
En découplant les services, les composants d'une architecture basée sur les événements peuvent être mis à l'échelle et échouer de façon indépendante, augmentant la résilience d'une application. Cette propriété devient de plus en plus importante, face à la hausse du nombre d'intégrations entre les services. Si un service échoue, le reste peut continuer de fonctionner.
L'architecture basée sur les événements peut aussi simplifier la conception des systèmes quasi-temps réel, aidant ainsi les organisations à tourner le dos au traitement par lots. Les événements sont générés lorsque l'état d'une application change. Quand les événements augmentent, la couche qui les traite peut s'accroître.
Les événements sont généralement publiés vers les services de messagerie, qui se comportent comme une mémoire tampon élastique entre les microservices et aident à prendre en charge la mise à l'échelle. Les événements peuvent aussi être envoyés vers un service de routeur capable de filtrer et d'acheminer les messages en fonction du contenu de l'événement. Ainsi, les applications orientées événements peuvent être plus évolutives et offrir une plus grande redondance que les applications monolithiques.
Développement agile
Avec l'architecture basée sur les événements et les routeurs d'événements, les développeurs n'ont plus besoin d'écrire du code pour interroger, filtrer ou acheminer les événements. Un routeur d'événements filtre automatiquement les événements et les transfère aux consommateurs. Le routeur élimine également le besoin de coordination élevée entre les services de producteur et de consommateur, ce qui accroît l'agilité des développeurs.
Étant donné que l'architecture basée sur les événements repose sur la technologie Push, tout ce qui a lieu à la demande comme événement est envoyé vers le routeur et les systèmes en aval, sans nécessité d'informer les services dépendants. Ainsi, l'infrastructure et les ressources peuvent s'adapter au volume des événements, ce qui réduit les coûts liés au traitement des charges de travail et à l'exploitation des applications déployées.
Création de systèmes extensibles
L'architecture basée sur les événements est aussi hautement extensible. D'autres équipes peuvent étendre les fonctions et ajouter des fonctionnalités sans aucune incidence sur les microservices existants. En publiant les événements, une application peut s'intégrer avec les systèmes existants, et les applications futures peuvent s'intégrer facilement en tant que consommateur d'événements, le tout sans modifier la solution existante.
Les producteurs d'événements n'étant pas au fait des consommateurs d'événements, l'extension du système est plus harmonieuse, et de nouvelles fonctions ou intégrations n'ajoutent pas les dépendances qui ralentissent le développement à venir.
Réduction de la complexité
Les microservices permettent aux développeurs et aux architectes de décomposer les flux complexes. Par exemple, ils peuvent fragmenter un monolithe de e-commerce en processus d'acceptation des commandes et de paiement avec des services d'inventaire, de traitement et de comptabilité distincts.
Une charge de travail qui pourrait être complexe à gérer et à orchestrer dans un monolithe devient un ensemble de services simples et découplés qui sont gérés en toute indépendance et qui communiquent de façon asynchrone au moyen de messages d'événements.
Une approche orientée événements rend possible l'assemblage et l'orchestration des services qui traitent les données à différentes vitesses. Dans l'exemple suivant, un microservice d'acceptation de commandes interagit avec un système de traitement des paiements par le biais d'une file d'attente.
Dans cet exemple, le service d'acceptation de commandes peut stocker d'importants volumes de commandes entrantes en mettant en tampon les messages dans une file d'attente.
Le service de traitement des paiements, qui est généralement plus lent en raison de la complexité de la gestion des paiements, peut prendre un flux de messages stables dans la file d'attente. Le service de paiement passe par différents états de système du fait de la logique de traitement par essai-erreur. Le service de flux orchestre et gère les étapes du paiement d'après l'état du système, et à terme génère davantage d'événements d'intérêt pour les services d'inventaire, de traitement et de comptabilité.
Audit facile
Un routeur d'événements, dans une architecture basée sur les événements, joue le rôle d'emplacement centralisé pour auditer votre application et définir des politiques. Ces politiques permettent de restreindre qui peut publier sur un routeur et s'y abonner, et de contrôler quels utilisateurs et quelles ressources disposent d'une autorisation d'accès à vos données. Vous pouvez également chiffrer vos événements en transit et au repos.
Réduction des coûts
Les EDA sont basées sur la technologie Push. Ainsi, tout se déroule à la demande lorsque l'événement survient dans le routeur. Vous ne payez donc pas l'interrogation continue pour rechercher un événement. Cela permet de réduire la consommation de bande passante du réseau, l'utilisation du processeur, la capacité inactive de flotte et les liaisons SSL/TLS.
Comment fonctionne l'architecture basée sur les événements (EDA) ?
Voici un exemple d'architecture basée sur les événements (EDA) d'un site de e-commerce :
%20for%20an%20ecommerce%20site.88b2240905b1b6addd672871b98bcb17bd44d701.jpg)
Cet exemple de site montre trois composants de producteurs d'événements et les événements qu'ils génèrent. Dans ce scénario, un routeur d'événements ingère et filtre les événements, puis en envoie un ou plusieurs vers les consommateurs d'événements.
Cette architecture basée sur les événements permet au site de réagir aux modifications provenant d'un ensemble de sources lors des pics de demande, sans blocage de l'application ou surprovisionnement des ressources.
Quels sont les types de charges de travail adaptés à l'architecture basée sur les événements (EDA) ?
Les architectures basées sur les événements (EDA) peuvent constituer un moyen efficace de répondre aux exigences des charges de travail hautement évolutives et hautement disponibles. L'EDA s'applique également bien aux charges de travail présentant des schémas de trafic imprévisibles ou « en pointe ».
Comment l'architecture basée sur les événements (EDA) améliore-t-elle les applications ?
L'architecture basée sur les événements (EDA) favorise le couplage faible entre les composants, ce qui en fait une bonne approche pour créer des applications modernes et distribuées.
Les producteurs d'événements ne sont pas conscients de l'activité des consommateurs en aval des événements qu'ils produisent ; ils ne s'en soucient pas et n'en sont pas affectés. Les événements eux-mêmes représentent un changement d'état et peuvent ou non contenir des données. Les événements sont indépendants des conséquences de leur existence. Les consommateurs écoutent et traitent les événements qui les intéressent. Vous pouvez mettre en ligne de nouveaux consommateurs pour fournir de nouvelles fonctionnalités sans perturber les flux existants.
Les EDA favorisent la décomposition des systèmes monolithiques en modèles de domaine plus petits. Les développeurs peuvent aller plus vite avec une charge cognitive moindre et devenir plus rapidement productifs. Lorsque les fonctions stratégiques sont découplées, il y a également moins de risques à déployer des mises à jour et de nouvelles fonctions.
Quels sont les cas d'utilisation courants de l'architecture basée sur les événements (EDA) ?
Communication de microservices pour les backends web et mobiles
L'augmentation de la capacité des sites web de vente au détail ou de médias et de divertissement est souvent nécessaire pour gérer un trafic imprévisible. Les clients visitent un site de commerce électronique et passent une commande. L'événement de commande est envoyé à un routeur d'événements. Tous les microservices en aval peuvent récupérer l'événement de commande pour le traiter. Parmi les actions possibles, on peut citer : la soumission de la commande, l'autorisation du paiement et l'envoi des détails de la commande à un fournisseur de services d'expédition.
Comme chacun des microservices peut évoluer et échouer indépendamment, le processus peut évoluer pendant les périodes de pointe des commandes sans points de défaillance uniques.
Automatisation des flux commerciaux
De nombreux flux commerciaux, tels que les transactions de services financiers, nécessitent la répétition des mêmes étapes. Vous pouvez initier et automatiser ces étapes avec une architecture basée sur les événements (EDA).
Par exemple, lorsqu'un client demande l'ouverture d'un nouveau compte auprès d'une banque, celle-ci doit effectuer quelques contrôles de données (documents d'identité, adresse, etc.). Certains comptes nécessitent également une étape d'approbation humaine. Vous pouvez orchestrer toutes ces étapes par le biais d'un service de flux qui exécute les étapes automatiquement lorsque de nouvelles demandes d'ouverture de compte sont reçues.
Vous pourriez également ajouter un flux pour traiter les données des demandes des clients de manière asynchrone avec le machine learning pour extraire les données pertinentes, et ainsi, économiser potentiellement des heures de collecte et de validation manuelles des données.
Intégration des applications SaaS
L'un des principaux défis pour les environnements de logiciels en tant que service (SaaS) est le manque de visibilité sur l'activité et les données des utilisateurs. Pour débloquer les données cloisonnées, les architectures basées sur les événements peuvent ingérer les événements des applications SaaS ou envoyer des événements à leurs applications SaaS. Par exemple, vous pouvez créer un intergiciel pour ingérer les données des commandes entrantes des partenaires et envoyer les commandes directement à une application interne de traitement des commandes.
Automatisation de l'infrastructure
Lors de l'exécution des charges de travail à forte intensité de calcul (telles que les analyses financières, la recherche génomique ou le transcodage de médias), vous pouvez faire en sorte que les ressources de calcul réagissent en augmentant l'échelle pour un traitement hautement parallèle, puis en la réduisant une fois le travail terminé.
Par exemple, dans les secteurs très réglementés, les entreprises dotées d'une EDA peuvent augmenter les ressources de sécurité en réponse à un incident, ou prendre des mesures correctives dès qu'une politique de sécurité envoie un événement d'alerte.
Quand devriez-vous utiliser des architectures basées sur les événements (EDA) ?
Les architectures basées sur les événements (EDA) sont idéales pour améliorer l'agilité et déplacer rapidement. Elles se retrouvent généralement dans les applications modernes qui utilisent des microservices, ou dans toute application ayant des composants découplés.
Intégration de systèmes hétérogènes
Si vos systèmes s'exécutent sur des piles différentes, vous pouvez utiliser une EDA afin de partager les informations entre les systèmes, sans couplage. Le routeur d'événements établit l'indirection et l'interopérabilité entre les systèmes, afin qu'ils puissent s'échanger des messages et des données tout en restant indépendants.
Réplication de données entre régions et entre comptes
Vous pouvez utiliser une EDA pour coordonner les systèmes entre les équipes qui sont actives dans différentes régions et comptes AWS et y font des déploiements. En utilisant un routeur d'événements pour transférer des données entre les systèmes, vous pouvez développer, mettre à l'échelle et déployer des services indépendamment des autres équipes.
Surveillance et alerte de l'état des ressources
Plutôt que de vérifier continuellement vos ressources, vous pouvez utiliser une EDA pour surveiller les anomalies, les changements et les mises à jour et recevoir des alertes. Ces ressources comprennent des compartiments de stockage, des tableaux de bases de données, des fonctions sans serveur, des nœuds de calcul, etc.
Diffusion et traitement en parallèle
Si vous avez de nombreux systèmes qui doivent fonctionner en réponse à un événement, vous pouvez utiliser une EDA pour diffuser l'événement sans avoir à écrire du code personnalisé à envoyer à chaque consommateur. Le routeur envoie l'événement aux systèmes, chacun d'entre eux pouvant traiter l'événement en parallèle dans un but différent.
Quels sont les modèles courants d'architecture basée sur les événements (EDA) ?
Multiples fonctions courtes
Créez de nombreuses fonctions courtes sur des plus grandes. Qui dit fonctions hautement spécialisées pour vos charges de travail, dit concision de ces dernières et réduction globale du temps de réponse. Chaque fonction doit gérer l'événement envoyé à la fonction, sans aucune connaissance ou attente en ce qui concerne le flux global ou le volume des transactions. Cela rend la fonction agnostique de la source de l'événement avec un couplage minimal avec d'autres services.
Traitement à la demande plutôt que par lots
De nombreux systèmes sont conçus pour s'exécuter périodiquement et traiter des lots de transactions qui augmentent au fil du temps. Par exemple, une application bancaire peut s'exécuter de façon horaire pour traiter les transactions aux guichets automatiques dans des registres centraux.
Dans l'architecture basée sur les événements (EDA), le traitement personnalisé peut répondre à chaque événement. Cela permet au service d'augmenter la simultanéité selon les besoins pour traiter les transactions en temps quasi réel.
Récupération après des perturbations
En cas de perturbation, un service peut être automatiquement appelé pour essayer de nouveau de traiter un événement. Étant donné que le service peut recevoir le même événement plusieurs fois, les fonctions doivent être conçues pour être idempotentes. Cela garantit que le résultat ne change pas après la première réception par le service de l'événement.
Par exemple, si un détaillant essaie de traiter une carte de crédit deux fois en raison d'une nouvelle tentative, le service traite le paiement uniquement lors de la première tentative. Lors de la nouvelle tentative, le service vérifie le statut du paiement et annule l'événement.
Quels sont les défis de l'architecture basée sur les événements (EDA) ?
Lors de l'adoption d'une architecture basée sur les événements (EDA), vous devrez peut-être repenser votre manière d'envisager la conception de votre application.
Latence variable
Contrairement aux applications monolithiques, qui peuvent tout traiter dans le même espace mémoire dans un seul appareil, les applications orientées événements communiquent au sein des réseaux. Cette conception introduit la notion de latence variable. Bien que les applications monolithiques puissent avoir une latence variable faible ou plus faible, la capacité de mise à l'échelle et la disponibilité s'en trouvent généralement sacrifiées.
Les services AWS sans serveur sont hautement disponibles, ce qui signifie qu'ils opèrent dans plusieurs zones de disponibilité au sein d'une région AWS. En cas de perturbation de services, les services basculent automatiquement vers des zones de disponibilité alternatives et relancent les transactions. Par conséquent, plutôt que d'échouer, les transactions peuvent aller jusqu'à leur terme, mais avec une latence plus élevée.
Les charges de travail qui nécessitent des performances de latence faible ne constituent pas d'excellentes candidates pour l'EDA. Voici deux exemples en la matière : les applications de trading à haute fréquence des banques ou l'automatisation basée sur la robotique à latence inférieure à la milliseconde dans les entrepôts.
Cohérence à terme
Un événement représente un changement d'état. Étant donné les nombreux événements circulant entre les différents services d'une architecture à un moment donné, de telles charges de travail présentent souvent une cohérence à terme. Cela rend plus complexe le traitement des transactions, la gestion des doublons ou la détermination de l'état global exact d'un système.
Certaines charges de travail ne sont pas parfaitement adaptées pour l'EDA, en raison de la nécessité des propriétés ACID. Cependant, de multiples charges de travail comportent une combinaisons d'exigences qui ont une cohérence à terme (par exemple le nombre total de commandes durant l'heure en cours) ou forte (par exemple l'inventaire actuel). Pour ces fonctions nécessitant une cohérence des données forte, il existe des modèles d'architectures de soutien. Exemples :
- DynamoDB peut fournir des lectures fortement cohérentes, parfois à une latence plus élevée, et peut aussi prendre en charge les transactions pour aider à maintenir la cohérence des données.
- Vous pouvez utiliser les bases de données relationnelles pour les fonctionnalités nécessitant les propriétés ACID, bien que les bases de données relationnelles soient moins évolutives que les stockages de données NoSQL.
Renvoi de valeurs aux appelants
Dans de nombreux cas, les applications orientées événements sont asynchrones. Cela signifie que les services appelants n'attendent pas les demandes provenant d'autres services pour continuer avec d'autres tâches. Cette caractéristique fondamentale des EDA garantit capacité de mise à l'échelle et flexibilité. Cependant, elle rend la transmission des valeurs de retour ou des résultats des flux plus complexe que dans les flux asynchrones.
Dans bien des cas, le renvoi d'une valeur est moins important que le fait de s'assurer du succès ou de l'échec du traitement de l'événement. Les fonctions qui veillent au traitement des événements peuvent être plus importantes que le renvoi des valeurs à l'appelant.
Pour les charges de travail interactives, telles que les applications web et mobiles, l'utilisateur final s'attend généralement à recevoir une valeur de retour ou le statut actuel d'une transaction. Pour ces charges de travail, il existe plusieurs modèles de conception susceptibles de renvoyer des événements diversifiés à l'appelant. Cependant, ces implémentations dans une architecture basée sur les événements sont plus complexes que l'utilisation d'une valeur de retour asynchrone classique. Souvent, la plateforme peut atténuer cette complexité.
Débogage au sein des services et fonctions
Le débogage des systèmes orientés événements est différent de celui des applications monolithiques. Comme avec toutes les applications basées sur les microservices et les différents services et systèmes transférant des événements, il peut être difficile d'enregistrer et de reproduire l'état exact de multiples services lorsqu'une erreur se produit. Étant donné que chaque appel de service et de fonction comporte des fichiers journaux distincts, il peut être plus compliqué de déterminer ce qu'il est advenu à un événement spécifique à l'origine d'une erreur.
Orchestration
En règle générale, les flux simples deviennent plus complexes avec le temps. Dans un monolithe type, cela peut entraîner des groupes plus étroitement couplés de fonctions et services ainsi qu'un acheminement et des exceptions de gestion de code complexe.
Pour suivre l'état du système, les flux qui impliquent la logique de branchement, différents types de modèles de pannes et la logique de nouvelle tentative utilisent généralement un orchestrateur. Lors de la création d'une application sans serveur orientée événements, il convient d'identifier à quel moment cet événement se produit afin de pouvoir migrer cette logique vers une machine à états pour une orchestration adéquate.
Quels services AWS utilisent une architecture basée sur les événements (EDA) ?
Les services AWS produisent ou consomment généralement des événements, ce qui facilite la création de solutions avec une architecture basée sur les événements (EDA).
En outre, des services comme Amazon EventBridge, Amazon SNS, Amazon SQS et AWS Step Functions comprennent des fonctionnalités qui aident les clients à écrire moins de code passe-partout et à créer des EDA plus rapidement.
Amazon EventBridge
Vous pouvez utiliser Amazon EventBridge pour créer des bus d'événements pour des applications basées sur les événements à grande échelle en utilisant des événements provenant d'applications SaaS, d'autres services AWS ou d'applications personnalisées.
EventBridge applique des règles pour acheminer les événements des sources d'événements vers différentes cibles. Les cibles peuvent être des services AWS comme AWS Lambda, AWS Step Functions et Amazon Kinesis, ou tout point de terminaison HTTP dans les destinations API EventBridge.
Une intégration courante pour les cas d'utilisation EDA est Step Functions, dans laquelle les événements déclenchent des flux spécifiques.
AWS Step Functions
AWS Step Functions comprend Workflow Studio, un concepteur de flux visuel à faible code que les créateurs utilisent pour orchestrer différents services AWS. Vous pouvez utiliser Workflow Studio pour créer des applications distribuées, automatiser des processus informatiques et commerciaux, et créer des pipelines de données et de machine learning à l'aide de services AWS.
Amazon SNS
Nous vous recommandons d'utiliser Amazon Simple Notification Service (Amazon SNS) pour créer des applications qui réagissent à des événements à haut débit et faible latence publiés par d'autres applications, microservices ou services AWS. Vous pouvez également utiliser Amazon SNS pour les applications qui ont besoin d'un débit très élevé vers des milliers, voire des millions de points de terminaison.
Amazon SQS
Amazon Simple Queue Service (Amazon SQS) offre un service de file d'attente hébergé sécurisé, durable et disponible que vous pouvez utiliser pour intégrer et découpler des systèmes et des composants logiciels distribués. Amazon SQS offre des constructions communes telles que les files d'attente de lettres mortes et les étiquettes d'allocation de coûts.
Prochaines étapes : Architecture basée sur des événements AWS
