Akka Cluster et l’Event Sourcing et le CQRS

Akka Clusters est une puissante librairie pour distribuer sa donnée et son traitement à travers des clusters d’acteurs. Mais que se passe-t-il quand il s’agit de la stocker ? C’est là qu’interviennent les principes d’Event Sourcing et de CQRS (Ségrégation de la lecture et l’écriture). Ces principes ont considérablement gagné en popularité avec l’augmentation de l’adoption des systèmes distribués. Akka les intègre nativement pour la gestion de la persistance des données.

Event Sourcing et CQRS

En gardant l’exemple précédent d’Akka Clusters et du sharding, sur la figure ci-dessus est ajouté un Event Log pour persister les états des acteurs selon les principes d’Event Sourcing. En cas de perte d’un noeud, il sera possible de retrouver l’état des acteurs recréés grâce à cet Event Log. L’Event Log peut être assimilé à une simple file de messages. Note : En CQRS, Ecriture et Lecture sont les noms des parties Command et Query en français. Ou requête de modification et requête de lecture.

Event Sourcing et CQRS

Quand une requête de modification (Command dans CQRS) est reçue, elle est routée grâce à l’entity ID et le sharding vers l’entité (Entity) correspondante. Quand le message est traité par l’acteur représentant cette entité et que celui-ci implémente Akka Persistence, son état est stocké dans l’Event Log. En reprenant l’exemple du compte bancaire où une consistance forte est nécessaire, Akka persistence peut persister le solde d’un compte au fur et à mesure de son évolution et stocker les événements. Par exemple : “voici un crédit sur le compte” ou “voici un débit sur le compte”.

A noter qu’une commande (Command dans CQRS) est une requête pour une action dans le futur, alors qu’un événement dans l’Event Log est dans le passé. Une commande dit “voici ce que j’aimerais effectuer” alors qu’un événement dit “voici ce qu’il s’est passé”. Des bases stockent et acceptent des événements qui se sont déroulés précédemment. Comme par exemple une opération de retrait d’argent validée et effectuée. Une fois l’événement persisté, l’entité met à jour son état et incrémente ou décrémente le solde bancaire en conséquence.

Sur la figure ci-dessus montre que l’“Akka Persistence Query” représente l’implémentation de la partie requête du CQRS. L’Event Log représente la partie écriture (Command). Un outil facilitant la lecture (base SQL, index de recherche) matérialise souvent la partie lecture (Query). Rechercher dans un log d’événements étant difficile, il sera mis en place dans la figure un système de stockage facilitant la lecture et synchronisé à chaque ajout d’évènement dans la queue de l’Event Log.

Ces actions ne sont pas transactionnelles (car rien ne garantit qu’aucun évènement ne sera perdu). Il est nécessaire de mettre en place un mécanisme assurant la qualité de la donnée. “Akka persistence query” met en place ce mécanisme, où la base de lecture (Query/read) s’abonne à la file d’événements pour en extraire les messages, plutôt que d’avoir un système en mode push depuis l’Event Log.

Publication et Souscription (Publish/Subscribe)

Des fonctionnalités intégrées nativement à Akka assurent que les commandes et les événements se réalisent correctement. De nouveaux acteurs viennent consolider ces actions : les acteurs médiateurs, les acteurs publicateurs et les acteurs souscripteurs.

La figure ci-dessus schématise sur chaque noeud du cluster un acteur médiateur, un acteur publicateur sur un des noeuds et N comme acteurs souscripteurs (un par noeud) qui se sont abonnés aux événements dont ils ont besoin. L’acteur publicateur envoie un message au médiateur local du noeud. Les médiateurs ont connaissance de l’existence d’un cluster ainsi que d’autres médiateurs sur les autres noeud. Ceci qui permet que lorsque l’un d’entre eux reçoit un message, il puisse le communiquer aux autres noeuds du cluster.

Ainsi, le premier médiateur dit aux autres : “j’ai un évènement qui vient d’être publié et quelqu’un doit gérer ce message”. Les médiateurs recevant le message renvoient celui-ci en mode round robin (comme décrit dans la section cluster sharding) aux acteurs souscripteurs disponibles. Les développeurs ne se soucient pas de la mécanique interne de gestion de la répartition des messages. Ce sont les médiateurs qui s’en occupent automatiquement.

Distribution de la donnée

“Akka persistence” maintient l’état stable pour une forte consistance. “Akka distributed Data” est un module permettant de distribuer cet état et ces messages à différents acteurs à travers le cluster sans coordination manuelle. Le concept utilisé pour réaliser cela est celui du CRDT (Conflict-Free Replicated Data Types). Le besoin est alors d’avoir une forte disponibilité en lecture et écriture avec une faible latence.

A noter qu’il y a certaines restrictions sur les types de données pour lesquelles “Akka Distributed Data” peut être utilisé. Par exemple, dans un système avec une éventuelle consistance (par opposition à une forte consistance), une requête en lecture peut renvoyer une valeur obsolète. Akka gère cela en utilisant d’autres types d’acteurs distribués dans le cluster. Sur la Figure ci-dessus chaque nœud du cluster représente des acteurs de réplication.

Cette figure représente un acteur par valeur K (K1, K2, K3) répliqué à travers le cluster avec un acteur de mise à jour (Updater) sur le noeud 2.  Si cet acteur a besoin de la valeur de K3, il effectue la requête à l’acteur réplicateur qui a son tour demande la valeur à K3 avant de la lui renvoyer. L’acteur “Updater” interagit uniquement avec le réplicateur et ne se préoccupe pas de son environnement.

Sur la figure ci-dessus, l’acteur de mise à jour effectue une requête de modification de la valeur de K3. Ensuite, on observe que la situation change. La nouvelle valeur doit être répliquée à travers le cluster et chacun des réplicas de K3. L’acteur réplicateur est conscient de l’existence du cluster (Cluster Aware). Il communique la nouvelle valeur aux autres acteurs réplicateurs sur les différents noeuds. Ceux-ci modifient à leur tour les K3 avec la nouvelle valeur.

Du point de vue du développeur, c’est simplement un message envoyé au réplicateur local. La réplication opère “automagiquement” au travers des actions des autres acteurs sans avoir été codée manuellement.

Event Sourcing en résumé

• Pour résumer, les éléments clés à retenir de cette section :
• Akka supporte les principes d’Event Sourcing et de CQRS pour les données distribuées dans les systèmes réactifs.
• Des modules comme “Akka Persistence” et “Akka distributed Data” fournissent des mécanismes pour réaliser une forte consistance ou une éventuelle consistance au choix.
• Akka Cluster implémente un paradigme de réplication permettant d’éviter
  le développement manuel de toutes les opérations bas niveau sur le système que requièrent les systèmes distribués.

Spécialiste de sujets liés aux Architecture Reactives, j’ai travaillé sur de nombreux projets stratégiques de refonte SI impliquant plusieurs métiers. Je suis également passionné par les sujets liés à l’Agile, je contribue d’ailleurs au blog Organisation Performante.

N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!

Nidhal