En milieu professionnel, le besoin de créer des clusters est essentiel. Une des fonctionnalités les plus puissantes d’Akka est Akka Clusters. Contrairement aux applications Java classiques, Akka Clusters permet de dépasser les limites de l’unique JVM : les applications utilisant Akka clusters peuvent tourner dans un environnement distribué sur plusieurs JVMs tout en se comportant comme un seul applicatif.
Création d’un Cluster
Sur la Figure ci-dessus est représenté une collection de JVMs fonctionnant comme une unique instance d’Akka grâce à Akka Clusters. Les JVMs utilisent le protocole de “gossip” afin de communiquer entre elles et garder une transparence de localisation. Ici, la gestion des noeuds (JVM) au sein du cluster est opérée par Akka. Akka, au travers du protocol “Gossip”, est conscient de son environnement, de la création ou de la suppression de nouveaux noeuds dans le cluster. Des protocoles de gestion sont pré-définis au sein d’Akka pour déterminer les comportements à adopter à chaque changement du Cluster. Ainsi, les développeurs et architectes peuvent adapter et choisir parmi les stratégies à adopter.
Cluster sharding partie 1
Un pattern intéressant préconçu dans l’écosystème Akka est le Cluster Sharding. Il est utilisé lors de la distribution d’acteurs à travers divers noeuds d’un cluster. Il a pour but de communiquer entre les différents acteurs en utilisant leur identifiant logique sans se soucier de leur localisation physique (principe de transparence de la localisation).
Sur la Figure ci-dessus, on trouve une schématisation d’un exemple d’application Akka. Dans ce cas, imaginons une grande volumétrie d’entités fonctionnelles devant fonctionner de concert. Chacun entité représente un ou plusieurs acteurs représentés par les pastilles bleues sur le schéma. Supposons que la sollicitation se fasse simultanément sur plusieurs entités de telle façon qu’il ne soit plus possible de toutes les gérer en mémoire sur une seule JVM.
Sur la Figure ci-dessus, chaque rectangle représente un noeud/JVM sur lequel tournent des entités (ensembles d’acteurs représentant une unité fonctionnelle). Souvent, dans un souci de résilience et d’élasticité, il est préférable d’avoir plusieurs machines à disposition pour déployer les applicatifs. Ainsi, lorsqu’un noeud tombe, d’autres peuvent prendre sa charge en évitant d’arrêter le système dans sa globalité. Simultanément, les acteurs sur ce noeud se rétablissent pendant que le système global continue de fonctionner, évitant les crashs globaux qui surviennent généralement sur les systèmes monolithiques lorsque ce type d’erreur survient.
Cluster sharding partie 2
Comme schématisé sur la figure ci-dessus, le sharding des clusters permet à de larges collections d’acteurs d’être subdivisées en unités logiques appelées “shards”. Ces shards permettent d’identifier de manière unique les entités constituant le noeud. En prenant un exemple dans l’IoT (Internet des objets), supposons l’existence d’un identifiant depuis lequel un hash code est généré. Avec une opération modulo nous générons un shardID pour chacune des entités de notre système IoT. La stratégie de sharding est définie de manière à distribuer les collections d’entités de façon déterministe à travers le cluster.
Sur la figure ci-dessus est schématisé un cluster de 4 noeuds où chaque shard est distribué dans le cluster. Les acteurs, représentés en bleu et qui pourraient représenter un appareil électronique (IoT), voient leurs messages routés automatiquement à travers le cluster. Il est intéressant de se pencher sur le cas où l’un des noeuds tombe. Qu’arrive-t-il aux shards qui y étaient présents ? Akka Clusters sait quels shards étaient présents dans ce noeud. Il reconstruit automatiquement ceux qui ont été détruits en les distribuant sur les autres noeuds du cluster.
Akka clusters gère tout le sharding et la distribution des shards et soulage les développeur de ce poids. Cela leur permet de focaliser sur la résilience des états des acteurs, qui est à définir selon le cas d’utilisation. Par exemple, si chacun des acteur représente un compte bancaire, et dans le cas d’un noeud qui tombe, ces acteurs devraient être créés à nouveau dans un noeud fonctionnel avec l’état (par exemple le solde du compte) qu’ils possédaient. Cette partie est gérée grâce à Akka persistence, qui est couvert dans un autre article.
Cluster sharding partie 3
Sur la Figure ci-dessus est schématisé un exemple d’un cluster Akka. Akka Clusters implémente un “shard coordinator” qui coordonne le sharding pour l’ensemble du cluster. Celui-ci travaille de concert avec un “Shard Region Actor” qui existe sur chacun des noeuds du cluster. Cela augmente la transparence de la localisation et permet de ne pas se préoccuper de la localisation de l’acteur dans le cluster. Quand une requête parvient au cluster, il y a un load balancer qui envoie le message en round robin à travers le cluster.
Par exemple, sur la figure ci-dessus, quand un message est destiné à l’entité “123” et qu’il atterrit dans le noeud 2, l’acteur “Shard Region” de ce noeud répond au “Shard coordinator”: “je ne sais pas où est situé cet acteur. Où est-il dans le cluster?”. Le shard ID est alors utilisé pour déterminer l’endroit où est situé l’acteur en question. Ainsi, le “Shard Coordinator” détermine l’emplacement de l’entité 123 avec le résultat du calcul du shard ID et en informe le “Shard Region”. A partir de ce résultat, le Shard Coordinator répond que “l’entité 123 est dans la Region 3”. Ce qui permet à l’acteur “Shard Region” du noeud 2 de renvoyer le message vers la région/noeud correspondant.
Puis, l’acteur “Shard Region” du noeud 3 passe par le même processus, demandant au “Shard Coordinateur” où est situé l’entité 123. Le “Shard Coordinator” lui répond que l’acteur est situé dans son noeud (le 3) et le “shard Region” peut mettre à jour son index avec l’information que l’entité 123 est située dans son noeud afin d’éviter de répéter le processus. L’avantage de ce processus est que le développeur a seulement besoin d’envoyer le message au “Shard Region”. Le reste est automatiquement géré par Akka Clusters.
Comme schématisé sur la Figure ci-dessus, Akka Clusters gère intelligemment ce processus. Il permet à chacun des “Shard Region” de se souvenir de la localisation des shards. Ceci afin de soulager le “Shard Coordinator”. Au fur et à mesure, et grâce au protocole gossip, les “Shard Region” cartographient les acteurs et ne demandent plus au “Shard Coordinator” leurs emplacements. La complexité de toutes ces interactions est gérée par seulement quatre éléments : les acteurs, les Shards, les Shard Region et le Shard Coordinator. Ils représentent respectivement les acteurs “shardés” eux mêmes, l’acteur Noeud Singleton et l’acteur Cluster Singleton.
Akka Clusters en résumé
Pour résumer, les éléments clés à retenir de cette section : •
- Akka Cluster fournit des fonctionnalités pour mettre à l’échelle le système réactif de manière sécurisée et supervisée,
- Cluster Sharding est implémenté pour différents cas d’usage. Comme par exemple un moyen d’assurer le maintien de l’état lorsque des messages parcourent différentes frontières de manière asynchrone,
- Les développeurs n’ont plus à se soucier de l’implémentation à bas niveau de ces interactions car Akka les gère nativement.
Nous parlons dans un autre article d’Akka Cluster, l’Event Sourcing et le CQRS.
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
Laisser un commentaire