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é

Enjeux de l'adaptation du référentiel de données de marchés d’une grande banque française aux exigences réglementaires

Sous la pression réglementaire, l’enjeu d’un référentiel commun de données de marché comme celui d’un historique de prix de produits fiable est au cœur des préoccupations des grandes banques. Toutes doivent relever les mêmes défis : gérer des volumes de données de plus en plus importants, implémenter et automatiser des contrôles de plus en plus complexes. Ce contexte les force à une restructuration des moyens de récupération, traitement, stockage et diffusion des données, dans un souci toujours plus pressant de transparence et d’encadrement des risques marchés.

Découvrir 
Actualité

RPA : de la robotisation des processus à l’automatisation intelligente

Dans cet article nous vous proposons de revenir sur les concepts adossés à l’acronyme RPA (Robotic Process Automation) et ses cas d’usage.

10/10/2019 Découvrir 
Success Story

Le Machine Learning source de ROI commercial pour un acteur bancaire majeur

Margo accompagne l'un des acteurs majeurs de la banque dans la réalisation d'un projet de développement et d'industrialisation d'un modèle de Machine Learning. Nous vous proposons notre retour d'expérience sur la mise en oeuvre de ce projet afin de mieux comprendre comment la datascience peut rapidement devenir génératrice de ROI pour nos clients.

04/07/2019 Découvrir 
Tribune

Des statistiques traditionnelles à la Data Science

« Datascience is statistics on a Mac ». Au-delà de la caricature portée par cette affirmation, l’idée que la « data science » se veut ni plus ni moins qu’un « rebranding » des statistiques est aujourd’hui partagée par de nombreux ingénieurs en statistiques, jusque-là simplement présentés comme tels...

Découvrir 
Témoignage

Rencontre avec Gaël, Software Engineer Haute Performance IT chez Margo

En débutant chez Margo, j’ai eu envie de sortir de ma zone de confort et de me former sur un langage plus poussé techniquement. Mon projet me permet de travailler en Java 8, ce qui m’a donné l’opportunité d’approfondir mes connaissances en langage orienté objet.

Découvrir 
Actualité

FinOps, de la nécessité d’optimiser les coûts en mode DevOps

Lors de l'AWS Summit Paris, Thomas Barandon, Senior Technical Account Manager AWS, et Fouad Maach, Head of Group MoveToCloud Veolia, nous ont partagé les bénéfices de la mise en place d'une démarche FinOps lors du passage de tout ou une partie de votre infrastructure vers le cloud. Sébastien Bourguignon, Principal & Lead Digital Influencer chez Margo, revient sur cette session.

15/04/2019 Découvrir