MARGO

Actualité

Introduction aux systèmes réactifs

Un modèle d’architecture pertinent pour les applications interagissant en temps réel avec les utilisateurs

Par Monssef El Faghloumi Software Engineer @mfaghloumi

04/05/2018

« It’s increasingly obvious that the old, linear, three-tier architecture model is obsolete. »
(A Gartner Summit track description)

« Il est de plus en plus évident que l’ancien modèle d’architecture à trois niveaux est obsolète. »

Les Consultants Margo ont participé à Devoxx France 2018, la conférence pour les Développeurs Passionnés, organisée du 18 au 20 avril 2018 à Paris. Découvrez ci-dessous une synthèse sur les systèmes réactifs illustrée par un use case concret.

Qu’est-ce qu’un système réactif ?

Les systèmes réactifs sont un style d’architecture permettant à de multiples applications individuelles de se fondre en une seule unité, en réagissant à leur environnement, tout en restant conscientes les unes des autres.

La première formalisation de ce terme a vu le jour avec la création du « Reactive Manifesto » en 2013 par Jonas Boner qui, en rassemblant certains des esprits les plus brillants dans l’industrie des systèmes distribués, souhaitait clarifier la confusion autour de la réactivité (qui est devenu un « buzz-word ») et construire une base solide pour un style de développement viable. Ainsi « Reactive Manifesto » décrit un ensemble de principes nécessaires pour construire des systèmes capables de répondre à des requêtes très rapidement et ceci même en cas de panne ou de surcharge.

Pourquoi construire des systèmes réactifs ?

Supposons que nous souhaitions construire un système qui :

  • Réduit la latence
  • Gère les pannes et s’en remet
  • Gère les pics de charge
  • Est capable d’envoyer, de recevoir et d’acheminer des messages dans un réseau non fiable

Ces réponses véhiculent en réalité les caractéristiques de base telles que définies dans le « Reactive Manifesto ».

Comment construire un système réactif ?

Les systèmes réactifs adoptent l’approche « Message driven ». Tous les composants interagissent par le biais de messages envoyés et reçus de manière asynchrone. Cette communication par passage de messages crée une limite temporelle entre les composants, rendant possible le découplage dans le temps (ce qui permet la concurrence) et dans l’espace (ce qui permet la distribution et la mobilité). Ce découplage est une exigence pour une isolation complète entre les composants et constitue la base de la résilience (la capacité à gérer les pannes et s’en remettre) et de l’élasticité (la capacité à « scaler » horizontalement).

elasticité des systèmes réactifs

L’élasticité nous vient du découplage dans l’espace. En effet les producteurs envoient les données vers une adresse virtuelle et les consommateurs consomment depuis une autre. Ainsi, les messages envoyés seront traités par un ensemble de consommateurs moyennant une stratégie de « load balancing ». Et quand le système fera face à un pic de charge, il lui suffira de lancer de nouvelles instances et de s’en débarrasser par la suite.

Quant à la résilience, elle nous est fournie par la capacité à gérer les défaillances sans blocage ainsi que la possibilité de répliquer les composants. En premier lieu, les interactions par messages permettent aux composants de gérer l’échec localement. Grâce à l’aspect asynchrone, les composants n’attendent pas activement les réponses, donc une défaillance se produisant dans un composant n’affectera pas les autres composants. La réplication est également une capacité clé pour gérer la résilience. Lorsqu’un message de traitement de nœud échoue, le message peut être traité par un autre nœud enregistré sur la même adresse.

Grâce à ces deux caractéristiques, le système devient réactif. Il peut s’adapter à des charges plus élevées ou plus faibles et continuer à répondre aux demandes en cas de fortes charges ou de défaillances. Cet ensemble de principes est primordial lors de la création de systèmes de microservices hautement distribués et lors de l’interaction avec des services hors du contrôle de l’appelant. Il est nécessaire d’exécuter plusieurs instances de chaque service pour équilibrer la charge et gérer les pannes sans interrompre la disponibilité.

Un système réactif est fait pour qui ?

Ce modèle d’architecture est très pertinent pour les applications interagissant en temps réel avec les utilisateurs. Cela comprend :

  • Les documents partagés (Google docs)
  • Les réseaux sociaux (Diffusion de flux)
  • Les analyses financières (Flux du marché)
  • La gestion plus efficace des algorithmes complexes (Gestion de graphes, Web sémantique…)

Un cas d’usage concret : LinkedIn

LinkedIn offre un système de messagerie instantanée, qui décrit en temps réel le statut de 500 millions de membres. Pour cela ils ont utilisé Play Framework et Akka Actor Model, des outils permettant de mettre en place un système réactif.

Ainsi, afin de distribuer les changements de statut de présence d’un membre à un nombre potentiellement énorme de relations, ils ont mis en place un système de publication / souscription (Message driven) qui permet aux données d’être diffusées du serveur, vers des clients mobiles ou Web, via une connexion persistante.

Lorsque le membre Alice ouvre LinkedIn sur son appareil mobile ou un navigateur, une connexion permanente est établie avec la plateforme temps réel. L’existence de cette connexion est une indication claire qu’Alice est actuellement en ligne. Par la suite Alice peut être intéressée de voir si Bob est actuellement en ligne. Pour cela, la plateforme permet à Alice de s’abonner à un topic « statut de Bob » (consommé à partir d’une adresse virtuelle, Découplage dans l’espace) pour suivre le statut de présence de Bob. Une fois que Bob ouvre son application, la plateforme saura que Bob est en ligne et pourra publier cet événement sur le topic « statut de Bob ». Par la suite la plateforme de présence enverra en temps réel cet événement à tous les abonnés à ce topic, y compris Alice. Ainsi, Alice verrait l’indicateur de présence de Bob devenir vert.

persistent connection

Cependant, il y a un autre problème auquel il faut remédier, le réseau ! (Le réseau sur votre mobile n’est pas ce qu’il y a de plus fiable – Résilience).

Alice et Bob sont sur leurs mobiles, et le réseau sur les téléphones n’est pas fiable. En l’état, les micros coupures du réseau vont inonder le système avec de “faux” changements de statut et causeront une mauvaise expérience utilisateur à Alice et Bob, dont le statut, ainsi que celui de leurs relations, n’arrêtera pas de « switcher » entre enligne / hors ligne.

Pour remédier à cela, LinkedIn a mis en place un système de « heartbeat ».

Une fois que la connexion persistante est établie, la plateforme temps réel commence à émettre des « heartbeats » avec l’ID du membre chaque d secondes. Cette durée sert de garde contre les fluctuations dans le statut de présence d’un membre. Tant qu’un « heartbeat » est reçu toutes les d secondes, la plateforme de présence considérera que le membre est toujours en ligne. Ainsi, si un membre abandonne sa connexion, dû à un problème de réseau, et se reconnecte dans les d secondes, il sera considéré comme en ligne. Ceci n’aurait pas été possible sans le découplage dans le temps.

presence cache

À chaque réception de « heartbeat », le « hearbeat process » vérifie s’il existe une entrée non expirée pour cet ID dans le cache distribué « presence cache ».

Si aucune entrée n’existe ou si les entrées précédentes ont expiré, on en conclut que le membre vient de se connecter.

  • Un événement en ligne sur le sujet de statut de présence pour ce membre est publié sur la plateforme temps réel afin de distribuer cet événement aux connexions du membre.
  • Une entrée est ajoutée au cache avec une durée d’expiration légèrement supérieure à d secondes (d + ε) pour garder l’enregistrement en vie jusqu’à au prochain « heartbeat ».

Si une entrée non expirée existe

  • Le membre est déjà en ligne, il suffit alors de mettre à jour le « lastHeartbeatTS » pour cet ID de membre.

Conclusion

Pour construire des systèmes réactifs, il faut repenser nos architectures ainsi que les concepts utilisés jusqu’à présent, et ce dans les différentes couches logicielles, des systèmes d’exploitation aux langages de développement en passant par les frameworks, les drivers ou les bases de données. Cette migration est un chantier en cours et plusieurs acteurs s’y attèlent déjà : Couchbase (SDK Java basé sur JavaRx 2), Play (Systèmes d’acteurs, solution utilisée par LinkedIn), Vert.x (Concept des Verticles & de l’Eventloop).

Au fil de cet article, nous avons décrit les principes des systèmes réactifs et nous les avons illustrés par le « use case » de LinkedIn. Mais les systèmes réactifs ne se résument pas uniquement à l’aspect technique, il faut penser au fonctionnel également.. Ils permettent notamment de découpler l’utilisateur de l’application par l’aspect asynchrone, quand le processus le rend possible.

Sources :

Bibliographie

  • Why Reactive – Konrad Malawski
  • Building Reactive Microservices in Java – Clement Escoffier

Webographie :

Conférence :

Session University « Introduction to Data Streaming« , animée par Clement Escoffier et Galder Zamarreño le mercredi 18 avril.


Par Monssef El Faghloumi Software Engineer @mfaghloumi
Cloud
Data
Haute Performance IT
Java
Actualité

Mener à bien un projet data : une route encore semée d'embûches

En 2020, les investissements des entreprises dans les projets data devraient dépasser les 203 milliards de dollars au niveau mondial. Mais à l'heure où beaucoup se revendiquent être des Data Driven Companies, nombre de projets data se soldent encore par un échec.

15/10/2018 Découvrir 
Communiqué de presse

Margo prévoit 200 recrutements d’ici fin 2019

Margo, société de conseil française créée en 2005, annonce l’ouverture au recrutement de 40 postes supplémentaires d’ici la fin de l’année 2018. Historiquement spécialisée en IT et finance de marché, l’entreprise, qui a fait évoluer son business model afin d’adresser désormais tous les secteurs d’activité concernés par les avantages concurrentiels portés par la transformation digitale, compte déjà plus de 300 collaborateurs en France, mais aussi en Pologne et en Angleterre. Poursuivant sa forte dynamique de croissance, elle ambitionne également d’augmenter ses effectifs sur l’année 2019 grâce au recrutement de 160 nouveaux collaborateurs.

10/09/2018 Découvrir 
Actualité

Kaggle Challenge : Ad Tracking fraud detection pour TalkingData

TalkingData est la plus grande plateforme indépendante de services Big Data en Chine, couvrant plus de 70% des appareils mobiles actifs dans tout le pays. Ils traitent 3 milliards de clics par jour, dont 90% sont potentiellement frauduleux. Afin de garder une longueur d'avance sur les fraudeurs, ils se sont tournés vers la communauté Kaggle pour obtenir de l'aide dans le développement de leur solution. Le sujet du challenge : créer un algorithme qui prédit si un utilisateur va télécharger une application après avoir cliqué sur une annonce d'application mobile.

31/05/2018 Découvrir 
Actualité

Les clés pour recruter dans l'IT

Emilia Kabak-Wołk, HR Manager chez Margo en Pologne témoigne des défis que représente le recrutement de profils rares tels que les Software Engineers, lors d'une interview menée par le magazine polonais Rekruter. 

18/05/2018 Découvrir 
Actualité

La Data Science appliquée au monde du retail : les 10 use-cases incontournables

La Data Science impacte de plus en plus les business model dans toutes les industries, et notamment dans la vente de détail. Selon IBM, 62% des détaillants déclarent que l'utilisation de techniques relatives au Big Data leur donne un sérieux avantage compétitif. Savoir ce que veut votre client et à quel moment est aujourd’hui à portée de main grâce à la data science. Pour cela il suffit d’avoir les bons outils et les bons processus en place pour les utiliser. Nous présentons dans cet article 10 applications essentielles de la data science au domaine du retail.

18/05/2018 Découvrir 
Actualité

Le e-trading de A à Z

Le 24 avril dernier, Wissam Benhmida, Business Analyst chez Margo, a animé un Meetup sur le e-trading à #LaPiscine. En l'espace d'une heure, il a pris le temps de revenir sur la définition du trading, pour ensuite détailler le mode le fonctionnement, les enjeux et les risques du trading électronique.

17/05/2018 Découvrir