Aller à la navigation

Blog

Retour à l’accueil

17 Fév 2020

[DEV’] Développer des applications réactives, distribuées et résilientes avec AKKA

Retour d’expérience du Scala IO 2019 par Julien Remy, Ingénieur Big Data FINAXYS

Akka est un toolkit permettant de développer des applications orientées message de manières simultanées, distribuées et résilientes pour Java et Scala (écrit en Scala).

Il repose en fait sur le design pattern Acteur / Modèle, optimisé pour la JVM (Java Virtual Machine).

Ce modèle est connu pour gérer de grandes charges de données de traitements parallèles et concurrentes sur un réseau. Akka permet de marier ce paradigme efficace avec la POO (Programmation Orientée Objet).

Dans un modèle Acteur, tout processus est acteur (de la même manière que tout objet est objet dans la POO) et ils communiquent en s’échangeant des messages. Toute la complexité, la planification des threads, l’échange des messages, la concurrence et la synchronisation est totalement transparente : c’est le framework Akka qui abstrait cette complexité de notre programme.

Akka répond en tout point au Reactive Manifesto :

  • Répondant : réagit au plus vite et en toute conformité ;
  • Résilient : toujours répondant, même en cas d’erreur ;
  • Elastique : adaptabilité à la charge des traitements ;
  • Orienté Message : basé sur l’échange de messages asynchrones.

Comme pour la plupart des problèmes complexes, l’organisation du programme et des acteurs doit respecter le principe de responsabilité unique, chaque acteur doit donc réaliser une unique tâche. Cela rend l’exécution plus propre, compréhensible, et c’est plus simple à maintenir.

Un acteur Akka correspond à un objet qui va recevoir des messages et va réaliser des actions en fonction de ces messages. Il peut en outre :

  • Réaliser des calculs, appeler des web services, faire des appels I/O
  • Instancier un nouvel acteur
  • Rediriger le message vers un autre acteur

Les acteurs s’organisent de manière hiérarchique, on dispose d’un acteur « Root » qui instancie des acteurs fils et redirige les messages et ainsi de suite. Il est possible d’envoyer un message avec un retour direct, ou alors d’envoyer une future (message dans l’attente d’une réponse).

Himanshu Arora a présenté son expérience sur Akka lors de la conférence Scala IO 2019 sur le thème « So long untyped actors, make way for Akka-Typed ». Ce talk a présenté Akka de manière générale et les technicités apportées au fur et à mesure du développement du framework. Il évoque en outre les acteurs typés d’Akka qui leur permettent de s’envoyer des messages typés. Cela permet d’assurer la conformité d’échange des messages, et de pouvoir anticiper les problèmes de messages à la compilation.

Maintenant que nous connaissons un peu plus en détails le fonctionnement d’Akka, voici une implémentation originale de ce framework pour aborder tous les aspects de modélisation et l’architecture qui gravite autour.

       

Tame Crypto Events with Scala and Akka Streams (Saca IO 2019)

Par Fabio Tiriticco (Freelance)

Fabio présente un projet très intéressant concernant les crypto-monnaies. Son objectif est le suivant : Est-il possible de mesurer et étudier l’ensemble des événements des crypto-monnaies et ainsi en déduire un modèle d’évolution par rapport au cours de la monnaie ? Le but est donc in fine d’investir dans les crypto-monnaies pour capitaliser.

 

Introduction

Selon Fabio, le métier de développeur est plein de FRUSTRATIONS. Pourquoi ?

Et bien un ingénieur informatique, au quotidien, doit développer des applications avec les contraintes d’un cahier des charges déjà défini. C’est-à-dire qu’il sera imposé au niveau des technologies utilisées, qu’il ne pourra pas optimiser son application (car elle fonctionne déjà, pourquoi l’améliorer ?), et qu’enfin il fait partie d’un petit rouage mécanique de l’ensemble du fonctionnement applicatif et fonctionnel du système. En plus de cela, il est souvent amené à effectuer d’autres tâches (management, gestion de projet, etc.)

C’est pour ces raisons que Fabio s’est lancé dans l’élaboration de projet personnel, pour allier passions et connaissances : les crypto-monnaies.

Il présente tout d’abord CoinMarketCap, un site web répertoriant l’ensemble des crypto-monnaies et tous leurs indicateurs. Ce site propose également une API qui va lui permettre de récupérer une multitude d’informations sur les monnaies :

  • Le cours (évolution de la valeur) ;
  • Les releases (sortie d’une nouvelle version) ;
  • Les fork (copie du code de fonctionnement de la monnaie) ;
  • Les congrès et les présentations.

Grâce à toutes ces données, son objectif est de trouver un pattern ou modèle, qui pour un type d’événement autour de la monnaie associe une élévation de son prix, avec un indice de confiance. Ce qui nous donne pour les matheux une fonction comme suit :

F(Monnaie, Type d’évènement) -> (Variation du prix, Indice de confiance)

Il ressort deux objectifs de ce projet :

  • Appliquer une architecture reactive ; cela va permettre de gérer facilement l’ensemble de flux de données disparates et pour toutes les raisons qui sont citées plus haut.
  • En apprendre davantage sur la manipulation de la donnée et le traitement Big Data.

 

La donnée

Entre les requêtes des données, et le modèle que l’on cherche à obtenir, plusieurs traitements sont à prévoir et à mettre en place pour que la donnée soit qualitative. Ci-dessous un schéma qui présente ces étapes :

 

Il est très important d’identifier et de modéliser le parcours de la donnée, plus particulièrement sur un projet orienté data.

 

Event Storming : Tempête événements

L’event storming est un processus de modélisation du code réalisé en équipe. Fabio a profité de l’application de cette méthode pour appréhender les flux et les processus à mettre en place dans son projet. C’est une approche qui s’apparente au DDD (Domain Driven Design), philosophie qui vise à établir des liens entre le monde réel (fonctionnel) et le monde technique (code).

L’objectif repose en fait sur la schématisation d’un « graphe » entre les évènements, les règles qui leurs sont associés et aussi les actions à réaliser, qui peuvent à leur tour générer de nouveaux évènements.

Cela permet ensuite de regrouper les actions par similarité. Fabio présente une partie Crypto Service qui aura comme but de réaliser les appels API vers les sources de données et une partie Prediction Service qui s’occupera de générer, produire les patterns de prédiction.

Cette modélisation permet dans notre cas de se rapprocher très facilement de l’architecture Event Sourcing de l’application. En effet, on peut ensuite très bien définir les deux acteurs Akka parents correspondant aux services précédemment énoncés, et l’ensemble de leurs sous-acteurs qui effectueront les actions unitaires pour respecter la granularité et le principe de responsabilité unique. Ces deux services communiqueront également via des streams.

 

Streaming : Flux de données

Quelle est le point commun entre :
Une volée d’oiseaux, des voitures qui roulent, des clients à la caisse d’un supermarché, leurs achats sur le tapis ?

Aussi étrange que celui puisse paraître, nos actions quotidiennes et notre environnement sont en fait pleins de flux. Fabio présente en effet notre vie de tous les jours sous un angle différent et pas toujours intuitif : Beaucoup d’évènements sont flux dans la vie réelle. Un flux correspond à un mouvement d’entités entre un point de départ et un point d’arrivée avec des fluctuations.

Il a donc logiquement choisi de mettre en place du streaming dans son application pour coller au modèle fonctionnel. Ce système est très puissant car il modélise parfaitement le traitement des flux de messages et il permet également d’avoir une instantanéité dans le traitement.

Effectivement, les messages que se transmettent les acteurs Akka s’apparentent à du traitement streaming mais Fabio va plus loin en utilisant Akka Streams.

Pour présenter cela plus en détails, il se penche sur son acteur Akka CryptoEvent qui est responsable de récupérer les évènements des crypto-monnaies. Pour faire court, il présente les traitements informatiques comme des flux, qui engendrent des actions particulières selon leur status. Pour exemple, l’appel HTTP en lui-même passe par différentes étapes de traitement et peut renvoyer plusieurs codes selon le status:

  • 0 : OK– L’appel HTTP s’est bien déroulé et la chaîne continue son exécution
  • 1 : Unauthorized – Le token était mauvais et l’acteur va donc en récupérer un nouveau avant de réitérer l’appel.
  • 2 : Error– Arrêt de l’acteur

Ce type d’implémentation avec un système de design réactive demande deux conditions impératives : avoir une vision globale du projet ET ne pas plonger mécaniquement dans le code.

Même si les acteurs et les flux sont indépendants entre eux, c’est eux qui régissent les différents traitements appliqués à la donnée. Il faut nécessairement que l’entièreté du projet soit cohérente sur le découpage des processus. D’autant plus qu’un projet personnel nous pousse à tout de suite vouloir développer, mais l’architecture ici appliquée nous oblige à prendre du recul.

Le code sera donc mieux organisé, plus maintenable et il aura par la même occasion plus de chance d’aboutir (on sait tous que les projets personnels ne sont pas toujours finalisés !).

 

Les limites

Tout d’abord, comme tout projet orienté donnée, il est difficile que les données soient partout homogène. Petit exemple : une crypto-monnaie avait une appellation différente entre son indexé d’API et le nom avec laquelle on la désigne en général. Ces petites erreurs de qualité de la donnée sont pour autant facilement détectable, à condition de réaliser des tests.

En ce qui concerne les données récupérées, voici les chiffres phares de l’application :

  • 6 mois d’exécution ;
  • 500 monnaies suivies ;
  • 2000 évènements répertoriés ;
  • 20 différentes catégories d’évènements ;
  • 500 000 taux relevés.

Il explique ensuite comment il a étudié les différentes données par rapport à l’évolution du taux : moyenne, variance et spread.

La moyenne et la variance n’apportent pas directement de connaissances fiables quant à l’augmentation du taux sur une période en relation avec les événements. Il va finir par se pencher sur le spread. Cet indice mesure l’écart entre deux taux. Il va donc conserver tous les spreads très positifs, et regarder quels événements se sont déroulés avant et pendant.

Finalement, il va pouvoir obtenir les monnaies qui suivent cette règle et qui s’élève au nombre de…. 1.

En effet, une seule monnaie subit un pic de son cours suite à des événements, et ces événements sont en fait des meet-up à deux endroits du monde qui ne sont d’ailleurs pas du tout populaires. Il admet alors qu’il s’agirait a priori plutôt d’une simple coïncidence.

Ils relèvent trois problèmes difficile à surmonter :

  • Les liens entre les événements et les hausses de taux ne sont pas forcément avérés ;
  • Il ne dispose pas d’assez événements, et qui sont trop éparses dans le temps ;
  • Les cours bougent trop rapidement et sont difficilement interprétables.

Pour conclure, Fabio fait le bilan de ce qu’il a appris et remarqué après l’élaboration de ce projet.

Tout d’abord, les architectures réactives comme Akka sont puissantes. Elles sont peut-être un peu plus complexes à appréhender et à mettre en place mais les nombreux atouts qu’elles apportent (si la conception est bien faite !) en fait une très bonne architecture, notamment pour traiter de nombreuses données.

Le nombre de données utilisés pour étudier un comportement n’est jamais suffisant. C’est toujours aujourd’hui le nerf de la guerre avec le développement du Big Data ces dix dernières années : la data est au cœur de nos systèmes d’informations et c’est elle qui détient toute la valeur.

La modélisation et la conception de l’architecture du code sont primordiales, surtout avec les systèmes réactifs. Il ne sert à rien de se plonger directement dans le code, car il sera forcément revu par la suite car trop généraliste et pas correctement implémenté par rapport à l’architecture.  

 

Etalé sur 3 jours, le salon Scala.IO accueille près de 60 speakers pour présenter leurs expériences, leurs conseils et les dernières tendances technologiques autour de la programmation fonctionnelle. 

 

 

 

Share our news :

-