29. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 29
POURQUOI LE RÉACTIF
Agenda du petit-déjeuner
LES DÉFIS DU RÉACTIF2
1
LES TYPES D’ARCHITECTURE RÉACTIVE4
3 CEUX QUI ONT DÉJÀ FRANCHI LE PAS
5 RETOUR D’EXPÉRIENCE PROJET
6 COMMENT ABORDER LA TRANSITION
31. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 31
Les SI vont subir des sollicitations exponentielles…
Source: Cisco VNI Global IP Traffic Forecast, 2014–2019
32. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 33
Nous approchons des limites physiques
CPU Mémoire de masse
RAM Réseau
33. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 34
Requêtes HTTP
Pools de
threads
Pools de
serveurs
Pools de
requêtes SQL
Nombre de serveurs limité
Appels synchrones bloquants
Utilisation de pools limités de ressources
SPOF sur la base de données
Mauvaise exploitation des ressources
Et pourtant, limitation physique à tous les étages
Utilisation de verrous
Evènements
HTTP/2
Serveurs
Requêtes
asynchrones
NoSQL
Nombre de serveurs illimité
Appels asynchrones non bloquants
Pas de pool de ressources
Pas de SPOF
Utilisation optimisée des ressources
Aucune limite physique
Pas ou peu de verrous
Architecture Classique Architecture Réactive
35. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 36
Les piliers du réactif
Responsive
ResilientElastic
Message-driven
Réactions en
temps réel à
toutes
sollicitations
Instantanéité et
réactivité sur tous
les médias
Résister à des
sollicitations fortes
Toujours en
fonctionnement
www.reactivemanifesto.org
36. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 37
Orienté évènements – Message-Driven
https://en.wikipedia.org/wiki/Hollywood_principle
Don't call us,
we'll call you
37. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 38
Au plus vite - Responsive
Instantané
Léthargique
La machine
travaille
Switch mental Je reviens
Temps
42. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 43
Dans différents secteurs
L’approche réactive est utilisée opérationnellement par de nombreux acteurs
pour répondre aux problématiques de scalabilité et de tenue de charge.
Scalabilité, fiabilité et haute
performance
Imprédictibles et très importants pics
de charge
Problématique : adresser le marché
des « Places réservées »
Solution : Stack Scala, Akka
Solution classique : déporter les systèmes de
gestion d’état dans des procédures stockées
Solution retenue : Implémenter les
traitements métiers dans la couche
applicative grâce au pattern CQRS* et une
architecture évènementielle
Moy. entreprise
* http://martinfowler.com/bliki/CQRS.html
43. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 44
Dans différents secteurs
Délivrer une expérience
immersive, responsive à travers
n’importe quel device.
Réduire les coûts de l’infrastructure en
gagnant en flexibilité et en scalabilité
Un environnement de développement
plus flexible et itératif
Une architecture message-driven
pour supporter beaucoup plus
d’utilisateurs par serveur
Downtime minimal
Solution : Stack Scala, Akka, Play
+20% de conversions sur le trafic Web, +98% des
commandes mobiles.
Réduction de 36% des temps de chargement.
Diminution de 20% à 50% des coûts de
l’infrastructure
« We needed to switch to a Reactive development
environment and decouple critical
components in order to allow for faster
development and better scalability. […] We
dramatically improved our performance on mobile
devices and saved money by moving to commodity
hardware that allowed to scale on demand and
stop building for peak loads.. »
Simon Rodrigue VP eCommerce Walmart Canada.
Très grand
groupe
44. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 45
Dans différents secteurs
Analyse du comportement utilisateur
Pipeline de traitement reposant sur Scala et Mesos / ZooKeeper permettant d’organiser et d’orchestrer
les traitements (scalabilité horizontale, tolérance à la panne…)
Ouverture internationale : scalabilité
horizontale
Enjeux de la plateforme :
Haute performance
Déploiement automatique des clusters
Multiples systèmes de persistance
Faiblement couplé et massivement
parallèle
Stack technique
Scala / Akka, Zookeeper, Storm, Tomcat /
Jersey, Neo4j, MongoDB, Kafka, Hadoop
Très importants pics de charge.
Gérés de manière élastique et automatisée.
« Our traffic can increase by as much as 100x
for 15 minutes each day. Until a couple of
years ago, noon was a stressful time. Nowadays,
it's usually a non-event. »
Eric Bowman VP Architecture
Moy. entreprise
Grande entreprise
Très grand
groupe
47. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 48
Mais la distribution modifie les modèles habituels
Pas d’inter-blocage entre les traitements
Donc pas de transaction
Cohérence à terme en base de données
Nécessite de définir une stratégie de distribution
Par client
Par commande
Par entreprise
Par famille de produits
Etc.
48. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 49
Un message est destiné à un composant
spécifique
Nécessite de connaître la cible
Un événement est destiné à tout le monde
Sans avoir à préciser les composants cibles
Message ou événement ?
49. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 51
Modèle événementiel asynchrone
Evènements Base de
données
Lectures /
Ecritures
API
Traitements
Synchrone
API
Traitements
Synchrones
Tampon
API
Traitements
Synchrone
Traitements
Asynchrones
Lectures /
Ecritures
HTTP/2.0 SOA IoT Mobile
HTML
Service Web
Sourcedes
événements
Architectureréactive
50. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 52
Modèle événementiel asynchrone avec séparation des flux R/W
Evènements Base de
données
Lectures
API
Traitements
Synchrone
HTTP/2.0 SOA IoT
API
Traitements
Synchrones
Tampon
API
Traitements
Synchrone
Traitements
Asynchrones
Ecritures
Messages d’écritures
Mobile
HTML
Service Web
Sourcedes
événements
Architectureréactive
Historique
Analyses
PRA
Modèle CQRS
http://goo.gl/Xl73zikappa-
architecture.com
51. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 53
Modèle événementiel asynchrone avec séparation des flux R/W
Evènements Base de
données
Lectures
API
Traitements
Synchrone
HTTP/2.0 SOA IoT
API
Traitements
Synchrones
Tampon
API
Traitements
Synchrone
Traitements
Asynchrones
Ecritures
Messages d’écritures
Mobile
HTML
Service Web
Sourcedes
événements
Architectureréactive
Historique
52. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 54
Stack technique S.M.A.C.K.
Evènements Base de
données
API
Traitements
Synchrone
HTTP/2.0 SOA IoT
API
Traitements
Synchrones
Tampon
API
Traitements
Synchrone
Traitements
Asynchrones
Messages d’écritures
Mobile
HTML
Service Web
Sourcedes
événements
53. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 55
L’approche Réactive au service des Microservices
Microservice
Acteur
Microservice
Acteur
Microservice
Acteur
Microservice
Acteur
Microservice
Acteur
Microservice
Acteur
Microservice
Acteur
Microservice
Acteur
56. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 59
Les 4 piliers du réactif
Responsive
ResilientElastic
Message-driven
Valeur
Aspect
Approche
Résister
à la panneRésister à
la charge
57. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 60
Application de Streaming permettant:
D’absorber des flux d’événements d’exploitation d’un service de
livraison
D’agréger ces éléments pour produire une synthèse
De détecter l’absence d’évènement sur une durée
De calculer des indicateurs en quasi temps réels
Cas d’école
58. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 61
Clés de lecture
Evènements et traitements
F
Contenu
Évènement
+
Traitement
F F
F
Client
Client
François
Etat commande
# Notification
…
Synthèse
Nouvelle commande
Retard livraison
Annulation
…
59. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 62
Partie
Lecture
Partie
Ecriture
Architecture simplifié
Distribution
(Kafka)
Traitement
(Spark)
Stockage
(Cassandra)
Direct Producers
Websites
Websites
EAI / ESB
Websites
Websites
Interne
API
(Play)
Datalake
API Consumers
Mobile
Web
Partenaires
60. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 63
Le sharding / partitionning permet d’avoir une scalabilité linéaire
Partitionner pour distribuer la charge
B F F
FB
Client
Bernard B F F
FB
Instance
Traitement
pour B
Instance
Traitement
pour F
Distribution
Instance
Traitement
Avant Après
61. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 64
Cas d’école
Partie distribution
B F F
A B C D E F Z
Topic Client
B
F
F
Client
64. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 67
A B C D E F
Des chaînes de traitement indépendantes
Pour une scalabilité linéaire
65. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 68
Prendre le pouls du système
Eviter la perte de message !
Pression
en entrée
Throughput
Traitement
(Spark)
Traitement
(Spark)
Distribution
(Kafka)
Distribution
(Kafka)
Distribution
(Kafka)
Traitement
(Spark)
Traitement
(Spark)
Traitement
(Spark)
Distribution
(Kafka)
Distribution
(Kafka)
Distribution
(Kafka)
Traitement
(Spark)
Traitement
(Spark)
Traitement
(Spark)
Distribution
(Kafka)
Distribution
(Kafka)
Distribution
(Kafka)
Traitement
(Spark)
F
67. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 70
Faciliter l’écriture des tests
Tests d’intégration
Injecteurs
Tests Unitaires
Packaging Api
Packaging Traitement
Code commun
Génération objets
Documentation API
Scripts
déploiement
Scripts
environnement
68. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 71
Traitement
(Spark)
Lecture
Ecriture
Distribution
(Kafka)
Traitement
(Spark)
Stockage
(Cassandra)
API
(Play)
Architecture Test d’intégration
Produit
Vérifie
Usine de
développement
+
Scripts
Déploiement et
plateforme
Tests
intégration
+
70. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 73
Technologie avec quorum
Quorum à majorité absolue = nombre de nœud / 2 + 1
Avec des nombres impairs c’est mieux !
Ticket d’entrée = 3
71. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 74HAproxy
(Loadbalancer)
Partie
Lecture
Partie
Ecriture
HAproxy
(Loadbalancer)
Traitement
(Spark)
Distribution
(Kafka)
Distribution
(Kafka)
Architecture Haute dispo
3 fois plus de machine
Distribution
(Kafka)
Traitement
(Spark)
Stockage
(Cassandra)
Stockage
(Cassandra)
Stockage
(Cassandra)
API
(Play)
API
(Play)
2+
2+
3+
2+ 2+
11Machines
Architecture
Simplifiée
23Machines
Architecture
Complète
72. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 75
Architecture Test Haute Disponibilité
Produit
Vérifie
(compareetcompte)
Usine de
développement
+
Scripts
Déploiement et
plateforme
Lecture
APIHA*
(Play)
Loadbalancer
(HAroxy)
Ecriture
Traitement
(Spark)
Traitement
(Spark)
Stockage
(Cassandra)
Stockage
(Cassandra)
Stockage
(Cassandra) APIHautedispo*
(Play)
Traitement
(Spark)
Traitement
(Spark)
Distribution
(Kafka)
Loadbalancer
(HAroxy)
Tests HA
+
73. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 76
Quels tests réaliser ?
Ajout d’un nœud
Suppression d’un nœud
Redéployer le traitement à chaud
Crash d’un nœud / technologie
Réparation d’un nœud
Haute
Dispo
Elasticité
74. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 77
Exemple de Test Haute Dispo
Chronogramme d’un crash / reconstruction
Détection premières
insertion dans
Cassandra
Tests de recette
Requêtage API
Injection
Attente x minutes
Durée du test
t0 t1 t2 t3 t6t5t4
Crash
serveur
Reconstruction
serveur
Cluster en
état nominal
75. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 78
Généraliser à tous les composants
Tuer chacun des composants
C*
Spark
KafkaApi
… Spark
KafkaApi
…
C*
77. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 80
Des boutons pour tout
Lancer test
unitaires
Lancer tests
intégration
Lancer tests
haute dispo
Destruction
Cluster
Stopper Cluster
Déploiement
Création cluster
Ajout machine
Vérification
plateforme
78. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 81
Automatisation, actions manuelles ou programmées ?
+ +
Recette
Intégration
Développement
Production
+
79. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 82
Cycle de vie des membres des clusters
Cluster
Développement
Intégration
Recette
Production
Fréquence des opérations sur les clusters
Fréquence
Création / Destruction
Actuel Cible
3h 30 min
24h 24h
10j 24h
Non 24h
Destruction
automatique ?
Actuel Cible
Oui Oui
Oui Oui
Non Oui
Non Oui
80. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 83
SVN
Java
Maven
PL
SQL
PHP
Quoi de neuf chez notre client ?
Kafka
Git
Scala
Infra as
code
DevOps
Spark
Confluent
IO
81. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 84
Conclusion
Les clés de répartition ont un rôle crucial
Beaucoup de DevOps
Automatisation obligatoire
Tester la haute dispo et l’élasticité de manière industrielle
83. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 86
Continuer
à produire
Produire
rapidement
de la
nouvelle
valeur
Ne pas rompre
la mécanique du
SI
Les enjeux du changement
84. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 87
Quelques éléments clé de la transition
Gestion du changement
Technique, Organisation, Process
Progressivité
Priorisation des fonctions à valeur ajoutée rapide
Découpage fonctionnel et technique ciblé
Mentalité
La résilience ne vaut pas que pour l’architecture
Détruire au lieu de réparer
Tout mesurer
Expérimentation
Les POCs ne sont pas que techniques
Privilégier le Fail-Fast
85. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 89
Exploiter les potentialités du cloud
Nettement plus de souplesse pour se préparer et avancer
Impact élevé, projet en soi
Servira laboratoire le cas échéant (labs, expérimentations, …)
Voire de débord en Run
Approches
Micro service plutôt que refaire du monolithe
Design By Request
Périmètre
Restreindre aux périmètres à faible risque métier pour commencer
Décommissionner progressivement
La transition architecturale trouvera écho dans les principes de l’agile
La transition comment ? Architecture
86. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 90
Buy vs Build ? Build !
Pas de solution sur étagère
Do It Yourself
Formation, auto formation, temps dédié et institué pour exploration
Avec qui ?
Embarquer les prestataires dans cette démarche
Accompagnement par des éditeurs
Adopter des pratiques et méthodologies éprouvées
En résonnance avec la démarche agile
Code review, Peer programming, TDD
Feature Flipping
Automatisation systématique des tests
La transition comment ? Développement
87. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 91
La transition comment ? DevOps
Cultiver les compétences DevOps
Le moins de mono compétences possibles dans les équipes
Pour chaque équipe, compétences au minimum de niveau 2 sur
tous les sujets
Automatisation à tous les niveaux
Automatisation la construction / destruction des environnements de
test
Automatiser la configuration des applicatifs en amont
Automatisation du poste de développement
Eviter la virtualisation des postes de développement (95 % du temps)
Virtualiser les conteneurs
88. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 92
La transition comment ? Industrialisation
Usine de développement
Destruction régulière des environnements : procure stabilité et
maîtrise
Quels moyens y mettre ?
Opter pour les environnements jetables
Cloud privé ou externe
90. www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 94
• Y aller
progressivement
• Apporter de la
valeur métier au
plus tôt
Ce qu’il faut retenir
• Performance
par la
distribution
• Evènements
traités en
asynchrone
• Elasticité à tous
les étages
• Tolérance aux
pannes
• Automatisation,
automatisation,
automatisation
Pour commencer, laissez moi vous raconter une histoire.
Cet homme s’appelle George.
« C’est le maire d’ SI ville »
C’est une belle ville…
…avec son lot d’embouteillages. Surtout en centre ville.
La ville possède de grands buildings.
Beaux et chers.
Dans les buildings, il y a bien des ascenseurs…
…mais ils n’y en a jamais assez.
Il faut attendre et attendre.
Et la population augmente,…
… augmente,…
…de plus en plus.
C’est pour cela qu’il a été élue.
Pour changer sa ville.
Et il a des idées !
Au lieu d’avoir une route par destination…
Il préfère que chacun puisse choisir sa voie.
Au lieu d’un guichet unique…
…il préfère multiplier les accès.
À la place d’immeubles immenses, avec un nombre limité d’ascenseurs…
… il préfère plein de petites maisons pas trop chères…
…sans ascenseur.
En cas de problème…
… c’est toujours moins grave qu’auparavant.
La vie est plus tranquille maintenant.
Tout va plus vite…
… MAIS tout le monde est plus heureux.
Tout cela, parce George a osé changer de perspective
Je m’appelle Philippe Prados, je suis le leader de la Tribu Reactive chez OCTO, et je suis accompagné ce matin de …
Questions à la fin de chaque session
Les nouveaux usages entraînent une explosion des sollicitations des SI : tout le monde est connecté partout, tout le temps avec n’importe quel terminal et s’attend à une réactivité accrue :
Les systèmes doivent donc être capables de gérer « des milliards de petites requêtes », en opposition avec « des milliers de grosses requêtes »
Dans un contexte de démultiplication des devices (Tablette, smartphone, montre, lunettes, voiture, capteurs, etc.)
Cela nécessite une remise en cause des architectures logicielles « classiques » notamment sur les volets de :
Performances
Et montée en charge
Gestion de la latence
Cloud and Mobile Network Traffic Forecast
* Pour les processeurs, on augmente le nombre de cœurs physiques et virtuels, mais plus la fréquence depuis longtemps
Les programmes ont du mal à en bénéficier
Pour les disques durs, nous avons maintenant des disques à 10 To, mais les temps d’accès n’augmentent pas dans les mêmes proportions.
Il n’est plus possible de faire un checkdisk. Cela prend plusieurs jours !
La RAM augmente rapidement, mais au-delà de 8Go, il ne devient difficile d’utiliser un Garbage-Collector
La vitesse du réseau est très rapide, mais ne pourra jamais dépasser la vitesse de la lumière.Un aller – retour Europe-USA ne pourra pas prendre moins de 40ms (Paris – New York en ligne droite)
Si vous en êtes loin, pour des applications Intranet par exemple, les architectures réactives ne sont pas pour vous.
Sinon, il existe de nouvelles approches permettant de les dépasser pratiquement toutes.
Les modèles classiques consomment généralement moins de 20% de CPU.
Pourtant, on ajoute de plus en plus de serveurs.
Les serveurs de bases de données sont souvent les premières limites atteintes
On peut compenser par l’utilisation de base de données NoSQL, mais cela n’est pas généralisé à toute l’architecture.
Le modèle réactif consiste à généraliser les approches performantes des bases NoSQL sur toute la stack technique
Quatre piliers, conceptualisés dans le Réactive Manifesto.
Des fondations : le message-driiven
Deux piliers : Elastic et Résilent
Et un toi comme objectif : responsive
Quelques dizaines de milliers d’événements par secondes
A la grande époque d’Hollywood, les producteurs avaient l’habitude de répondre, aux jeunes et jolies vedettes en mal de contrat : « Ne m’appelez-pas, je vous appelle ». Cette réponse standard est devenu un principe, honoré d’une page sur Wikipédia, « l’Hollywood principe ».
Le modèle événementiel est exactement l’application de ce principe. Ne venez pas consulter régulièrement l’état du client, je vous préviendrai dès qu’une modification arrive. Qu’il change d’adresse ou qu’il ajoute une commande.
Sur le gros projet Réactif auquel nous participons, nous avons 1 million de messages par jour. En période forte 10 millions par jours. Le volume a vocation a être multiplié par 10, après intégration des flux d’une autre entité du groupe.
Depuis l’invention de la souris, ce modèle de développement existe dans les OS pour tout ce qui concerne les interfaces utilisateurs. L’idée du modèle réactif est de généraliser ce modèle à l’ensemble du SI.
Nous voulons une « Réaction en temps réel à toutes sollicitations, être REACTIF »
Nous voulons :- une mise à jour immédiate des documents partagés
Voir immédiatement les tweets de nos amis
Savoir instantanément quand le solde de notre compte bancaire est sous le seuil critique
L’approche événementiel est le pilier principal des architectures réactives
L’objectif est d’avoir des applications suffisamment rapides pour satisfaire nos clients. Tous nos clients, quelque soit leur nombre, et à chaque instant. Mais qu’est-ce qu’être « rapide » ?
Google a publié une étude sur le ressenti des utilisateurs. En dessus de 300 ms, c’est trop lent.
Sachant que la latence moyenne en 3G et de 150ms (65ms en 4G), il ne reste pas grand-chose pour réponde aux exigences des clients.
N’oubliez pas que vos concurrents sont à un clic !
Une étude Wallmart indique une augmentation d’1% du CA pour chaque 100 ms gagnées.
Les moteurs de recherches intègrent également ce paramètre lors de l’indexation.
Internet étant mondial, il est difficile de trouver une plage horaire d’interruption. Il faut toujours être disponible, même en cas de succès (ce que l’on vous souhaite) !
Pour cela, il ne faut pas qu’un crash serveur, voir un crash d’un datacenter soit un événement.
Une maison peut bruler, mais pas la ville.
En multipliant les serveurs, on multiplie les risques de crashs. Cela arrivera donc plusieurs fois par an.
Le système doit encaisser cela sans broncher.
Comment s’en assurer ? En détruisant tous les jours vos serveurs, volontairement. Une armée de singe se charge de tuer vos machines, sans prévenir.
C’est une pratique des Géants du Web. Dans une architecture Reactive, c’est indispensable, du fait de la multiplication des serveurs.
Le crash est la norme, pas l’exception.
Une architecture réactive doit bénéficier d’une scalabilité horizontale linéaire. J’ajoute un onzième serveur ? Je bénéficie de 10% de capacité en plus.
Si de plus, vous ajouter des serveurs venant du Cloud, vous pouvez gérer les pics de charge à moindres coûts.
Une architecture réactive résiste à des sollicitations fortes
* Combien avez-vous de serveurs maximum pour une seule application ? 4 ? 5 ? Une architecture réactive c’est au minimum une vingtaine de serveurs
* Pouvez-vous gérer 100 serveurs ?
Pour répondre à tous ces enjeux, il faut intégrer dans les architectures des nouveaux concepts. On retrouve les notions d’événements ou de messages, mais il faut également intégrer des notions comme
L’asynchronisme, bien évidemment
l’immuabilité (les données ne bougent plus une fois crées),
l’idempotence (pour pouvoir rejouer les événements sans impact sur la stabilité du SI)
Ou les coupes-circuits pour éviter les effets « boule de neige » en cas d’instabilité
Et bien d’autres concepts encore
TicketFly est un vendeur de tickets pour des grands événements. Un très fort trafic est concentré sur un petite période, lors de l’ouverture de la billetterie.
Néanmoins, il faut s’assurer qu’une même place ne sera pas vendue plusieurs fois.
Les procédures stockées classiques ne sont pas la solution : Système rigide et faiblement scalable
Ils ont fait le choix d’un modèle événementiel, avec une séparation des flux de consultations des flux de modification.
C’est ce qu’on appelle le pattern CQRS pour Command Request Response Segregation.
Source : https://www.typesafe.com/resources/case-studies-and-stories/typesafe-helps-ticket-sales-soar-at-ticketfly
Walmart est l’une des plus grosse entreprise de distribution au monde. La filiale du Canada est le plus gros site de commerce en ligne du pays. Elle devait faire face à une augmentation importante du trafic, entre autres, via les mobiles.
Avec une architecture réactive, ils bénéficient d’une scalabilité horizontale, avec du hardware classique (au lieu de ceux spécialisés pour Oracle).
Ils ont réduit leurs coûts en dimensionnant dynamiquement leurs infrastructures pour les heures de pointes.
Source : https://www.typesafe.com/resources/case-studies-and-stories/walmart-boosts-conversions-by-20-with-typesafe-reactive-platform
HolidayCheck est une agrégateur d’opinions dans l’Hôtellerie
GILT est un E-commerçant spécialisé dans les ventes flash – Utilise Akka
Airbnb, un e-commerçant spécialisé dans la location saisonnière
Ils ont tous fait le choix d’une architecture réactive.
Références :
https://www.typesafe.com/resources/case-studies-and-stories/holidaychecks-journey-with-typesafe
https://www.typesafe.com/resources/case-studies-and-stories/the-typesafe-reactive-platform-at-gilt-groupe
https://www.typesafe.com/resources/case-studies-and-stories/replacing-cron--building-scalable-data-pipelines-at-airbnb
Notre conviction est que la distribution (le sharding) est une excellente approche pour permettre l’élasticité avec une scalabilité linéaire. Il faut distribuer les traitements suivant un critère arbitraire métier.
« A la tête du client » comme dans l’exemple.
Il y a des solutions cela. Il faut juste un peu plus réfléchir.
Il faut éviter au maximum de devoir synchroniser les serveurs, sous peine de perdre tous les avantages de ce modèle de répartition.
Un message est déposé dans une Queue JMS en architecture SOA. Comme il faut connaitre la cible, l’architecture est difficile à faire évoluer. L’adhérence entre les composants est forte.
Un événement est déposé dans un Topic dans une architecture SOA. Le modèle est bien plus souple, car il n’est pas nécessaire de connaitre les cibles. Elles peuvent évoluer suivant l’évolution du système.
Dans les architectures micro-service, il est préconisé d’utiliser une approche événement, via un modèle « chorégraphie ». Ainsi, chaque micro-service est responsable de s’abonner aux messages qui lui sont nécessaires.
Ce modèle est à opposer à l’approche « orchestration » que l’on retrouve beaucoup dans les architectures SOA, où un composant central joue le rôle de chef d’orchestre pour gérer les flux de différents messages entre les composants. Ce modèle est moins agile, car il est centralisé.
Un modèle classique d’architecture est représenté sur ce schéma
Des messages ou des événements sont produit par tout un ensemble de sources. CLICK
Les événements arrivent dans une file très rapide. CLICK
Ils sont consommés par de nombreux serveurs pour alimenter une base de données NoSQL
CLICK : Ils peuvent également remonter de l’information aux différents clients. HTTP/2.0 ou les WebSocket aident à implémenter ce modèle.
CLICK : La consultation des données s’effectue via des services WEB classiques, synchrones dans leurs accès.
Ce modèle est une évolution du précédant.
Nous séparons le flux de lecture du flux d’écriture. CLICK
Les écritures sont portées par un message injecté dans le bus. CLICK
Les données ne peuvent plus être modifiées sans qu’un message décrive la mutation. Et cela pour chaque modification : d’un taux de TVA à l’ajout d’un nouveau client.
En séparant complètement la chaine de traitement pour la lecture des données, de la chaine de traitement pour leurs écritures, nous pouvons bénéficier de nombreux avantages.
Il est alors possible d’historiser tous les messages de mutations.
Avec une architecture Kappa.
CLICK Cela permet de l’analyse comportementale sur un historique de quelques jours, ou si votre activité est saisonnière, sur toute une année, voir plus.
Vous pouvez analyser toutes les modifications dans une architecture Big-Data, dans un Datalake.
CLICK Il est envisageable de reconstruire l’intégralité du système en rejouant les messages. Vous avez ainsi un Plan de Reprise d’Activité (PRA) à peu de frais.
Vous avez enfin une vue complète de l’historique de vos données.
Cet historique peut devenir une vraie mine d’or
Notre conviction : « Un SI sans historique n’a pas d’avenir »
C’est cette architecture que nous avons mise en place chez notre client.
De nombreuses technologies modernes accompagnent ces architectures.
Play ou Node.JS pour la partie Front
Kafka pour gérer les files de messages
AKKA ou RxJava pour gérer les files de messages et la distribution des traitements en mode asynchrone
Spark et son extension Spark Streaming pour gérer des flux d’événements et de messages dans un cluster
Enfin, Couchbase, Cassandra ou MongoDB pour ne citer que quelques bases de données NoSQL
Une stack logicielle qui monte est la stack « SMACK »
Les microservices ou les acteurs doivent communiquer entre eux en mode asynchrone pour être efficaces.
Les architectures réactives y contribuent par le modèle asynchrone à base de messages.
De plus, les microservices doivent tolérer l’absence d’un service, à l’aide d’un coupe circuit.
Si le service sert à la lecture, une valeur par défaut est utilisée.
Si le service sert à l’écriture, un contournement simplifié est proposé, ou bien une fonctionnalité est déclarée comme indisponible.
Le SI doit régulièrement vérifier si le service est revenu à un état nominal, pour pourvoir le reprendre.
Les vrais traitements parallèles s’effectues dans des cœurs différents des microprocesseurs. Il y a en générale, 4 à 8 cœurs par CPU. Au-delà, c’est l’OS qui simule des traitements parallèles en partageant chaque cœurs avec plusieurs threads.
L’approche Réactive peut s’appliquer jusqu’au code. Les technologies le supportent.
C’est pour cela qu’il y a rarement plus de 15% de CPU utilisées, alors qu’on n’hésite pas à multiplier les serveurs. Les ascenseurs sont vides car ils rejoignent d’autres étages.
Nous utilisons des API asynchrones depuis très longtemps pour les interfaces utilisateurs, mais pas pour le reste.
CLICK Dans ce schéma, on compare deux situations.
L’objectif économique est de densifier la consommation des ressources sur les mêmes serveurs pour d’une part, optimiser les traitements, et d’autre part, réduire les OPEX (les dépenses d’exploitation – coûts énergétiques par exemple)
Approcher de 60/70% de CPU par serveur.
CLICK De nombreux frameworks portent ces nouvelles approches de développement. Oubliez J2EE et JDBC. Les API sont essentiellement synchrones à base de pool.
TODO: Apparition progressive. Vous etes ici.
Ce schéma simplifié montre qu’il y a souvent des révolutions dans les systèmes d’informations.
Régulièrement, de nouveaux paradigmes émergent. Il faut un peu de temps pour qu’ils se généralisent. Ensuite, il n’est plus possible de faire marche arrière.
Nous pensons que les architectures réactives vont suivre ce chemin. Dans quelques années, il sera difficile de ne pas proposer ces modèles pour les nouveaux projets.
Eviter big data
La valeur c’est reponsive, qu’importe l’état du système sous jacent (panne, crash), le système répond
Pour faire ca, on va travailler pour rendre notre système élastique et résilient
Et l’approche que l’on va choisir, c’est d’être Message-driven, une communication asynchrone entre les composants du système à l’aide de message
C’est l’aspect et l’approche qui permettra de rendre notre système responsive et de manière plus globale réactif
D’autre cas sont possibles
Evènement: objet portant des informations relative aux commandes d’un client (ici Francois)
Commande: ici les informations de la commande peuvent être des changement de statut, une création, un suppression…
Traitement: Agrégation des différents évènement pour former une synthèse
Le traitement peut s’arrêter ou pas, le traitement peut être actif plusieurs minutes, heures, jours
On ne traite que la partie bleue
Distribution:
C’est le point d’entrée du système, la ou les évènements arrivent
Réservé aux systèmes internes ou ayant un accès réseau (VPN) permettant de contacter directement la couche distribution
Traitement
La ou l’agrégation va se faire
Stockage
La où l’agrégation est persisté durablement, elle peut vivre un certain temps dans le traitement mais attention requêtage par l’API
Api
LectureLe point entrée de lecture pour tout le monde, sécurise l’accès aux données. Deux format retenus: JSON et binaire.Binaire pour le machine 2 machine et json pour les autres
EcritureProxy sur la couche distribution pour ouvrir les services aux producteurs ne pouvant le faire techniquement sur Kafka
Animation
Partie Write, c’est ici que tout les modifications vont être traités.
Animation
Partie Read, c’est ici que toutes les lectures vont se faire, pas d’exposition directe du stockage
Un mot sur le sharding, partitionning:
Ces systèmes utilisent du partitionnement pour pouvoir supporter convenablement le changement d’échelle
On souhaite que celui-ci soit linéaire: je double le nombre d’instance => je double ma capacité de traitement
Partie gauche:
Classiquement, je viens d’une architecture classique (scalabilité verticale), je ne partitionne pas mon seul moyen est d’augmenter la puissance de mon système (CPU, RAM…)
Animation
Partie de droite:
Je vais partitionner mes données avec une clé (ici la premiere lettre du prenom)
Animation:
C’est à l’aide d’une couche de distribution qu’on vais faire cela
Idéalement, on distribue aussi le traitement
Kafka pour la couche distribution
Kafka utilise la notion de topic (une file)
Cette file est découpé en partition
Ici, on choisira 26 partitions pour le topic client
Pour des raisons pédagogique, on prend l’alphabet=> on pourra changer et mettre le prénom, l’identifiant client…
Ensuite, on propage les règles de distribution sur les traitements
Et enfin, on propage les règles de distribution sur la partie stockage
Parler des possibilité de reporter les sharding sur cassandra et/ou de colocaliser les spark et les cassandra
Idéalement on a des chaine de traitement indépendante les une des autres
Et cela qui va nous permettre d’avoir permet la scalabilité lineaire
Cas 1: pression légère
on traite au fil de l’eau
le système est en capacité de traité le volume
Cas 2: pic de charge
La couche distribution joue le rôle de tampon le système accumule un léger retard
Le retard sera rattrapé en période plus calme
Mettre en place des indicateur pour calculer le retard et agir si cela s’intensifie
Cas 3
pression continue trop forte et trop longtemps le système ne tombera pas
mais il y aura risque de perte de message
Kafka utilisant un stockage tournant
Intégrer dans votre architecture des mécanismes
Déport cloud ou de scaling automatique (élasticité)
En utilisant de la régulation ou back pressure: ralentir les producteurs
Des mécanismes de court-circuit (circuit breaker)
Le risque c’est de perdre des messages
Des que les indicateurs commencent a virer au rouge, il faut réagir
Dans tous les cas le système ne tombe pas!
Faire des tests c’est:
Garantir la qualité mais ca on le sait
S’approprier le fonctionnement global de la plateforme
Passer progressivement d’une petite plateforme à une grande
Valider des montées techniques de composant
Ces architectures demandent plus de tests:
Plus de composants
Programmation distribuées
Technologies récentes
Animation 1
On va avoir besoin d’un cluster avec nos 4 couches
Animation 2
Et puis de test réalisés avec notre framework
De scripts ansible pour déployer notre traitement
Et d’un UDD pour orchestrer le tout
Animation 3
On va produire des messages (écriture)
Et vérifier le résultat en utilisant notre API (lecture)
S’assurer de la haute disponibilité de la plateforme
Associer des technos haute dispo ne rend pas le système haute dispo
Il faut s’en assurer et l’automatiser
Vous devez le tester
La plupart des technologies utilise la notion de quorum
C’est notamment pour garantir une cohérence
- Le ticket d’entrée est minimum 3
Parler scalabilité linéaire
Insister sur le fait d’automatiser la création / maj des nœuds
Ici on est passé de 4 nœuds à 12 nœuds (animation 4 vers 12)
Dans l’architecture réelles c’est 23 nœuds minimal et uniquement pour la Haute dispo
On reprends les mêmes éléments et on avec:
Un traitement simplifié mais proche de la réalité en terme d’utilisation de la plateforme
Faire transité un marqueur pour identifier les messages injectés
Un api spécifique pour les test de HA pour:
Compter le nombre de message recu
Vérifier le marqueur du message en entrée
Aucun doublon
Le bon message en sortie (marqueur)
T4 à t5 => il faut que ca aille vite
On peut détruire 1 nœud dans l’exemple d’après les règles de calcul du quorum
restructer fleches
fonctionner sans interruption de service
a chaud
Etes vous capable de mettre votre application
Descendre
Au moins par jour
Négocier dès le début les reset automatique sur les environnement de recette et integration
Ajouter Cassandra
Mettre jenkins en gris vert (c’est a peu pres le seul element commun)
Eviter big data
Questions :
Comment aborder la transition de manière progressive et industrielle ?
Sur la base de retours d’expérience, nous vous donnerons des pistes d’actions très concrètes à expérimenter dès demain. Elles permettent notamment, accompagnées d’une approche fortement industrialisée, une mise en place progressive des nouveaux patterns architecturaux pour dégager rapidement de la valeur ajoutée tout en procédant à une migration du SI rationnelle et sereine.
Les enjeux du changement
Ne pas rompre la mécanique du SI dans la transformation
Continuer à produire
Tout en produisant rapidement de la nouvelle valeur
La clef d’un changement réussi réside dans la conjugaison de ces 3 enjeux
La transition vers une architecture réactive
Un changement global du SI à terme, mais non instantané
Chaque pan du SI est impacté à terme
Tech
Orga
Process
Mais également un changement de mentalité à opérer : détruire au lieu de réparer
Effectuer le changement progressivement
En crantant de la valeur ajoutée
Priorisation des fonctions à rapide valeur ajoutée
Wording : un de nos client a fait le choix de commencer par une fonctionnalité à forte valeur ajoutée qu’il ne peut réaliser avec son legacy
Découpage technique et fonctionnel approprié
Décommissionnement progressif
Privilégier les environnements démonstratifs (adhésion)
Obsession de la mesure
Systématisation de l’expérimentation à échelle très réduite : POC et fail-fast
Les POCS ne sont pas que techniques (tech, fonc et orga)
La tolérance à la panne ne vaut pas que pour l’architecture : le droit à l’échec doit être intégré à tous les niveaux
Privilégier le fail-fast
Ambition :
Exemple : Le POC finit en Production, ne doit pas échouer
Exemple : Un produit trop vite (sous estimer la complexité)
Résultat : accumulation des retards
Résultat : Production instable, non exploitable, beaucoup de sujets structurants éludés
Voilure :
Exemple : Beaucoup d’équipes en même temps que le POC
Résultat :
DOD du POC obtenu au bout de 9 mois au lieu de 3
Code métier encore instable, faiblement testé, maturité faible
Pistes non explorées
Fausse Production :
Exemple : La mise en production ne veut pas dire mise en service
Résultat : où sont les utilisateurs ? Intérêt de l’effet de com ?
Comment ? Architecture
Utiliser des flux dupliqués
Favoriser le cloud, nettement lus de souplesse pour se préparer et avancer , cloud = attention « projet à part entière !! »
Approche micro service plutôt que monolythe
Adopter l’approche Design By Request
Restreindre aux périmètres à faible risque pour commencer
Décommissionner progressivement
Utiliser le cloud comme laboratoire le cas échéant (labs, expréimentation, …)
De nombreusue réposnse dans les principes de l’agile
Comment ? Dév
Aller du Buy vers le Build
Idéalement, notre conviction
Le nouveaux langages réactifs, comment les aborder ?
S’engager davantage dans le Do-It-Yourself
Formation, avec accent sur les possibilités poussées (prog. fonctionnelle, prog. réactive)
Auto formation, laisser du temps dédié, idéalement fixe, aux gens pour explorer
Embraquer de la prestation de qualité : des vélocités, qualité meilleures, … lieu commun ? Non, un projet mal développé est moins cher au TJM, mais tellement plus cher à terme (retards, itérations, avenants, qualité, …)
Embarquer les prestataires dans cette démarche
Des pratiques et méthodologies éprouvées
En résonnance avec la démarche agile
Code review
Peer programming
TDD : les tests avant tout (tendre vers, les test par le développeur)
Automatisation des tests à outrance
Feature flipping : pour les développements non matures, pour les tests de fonctionnalités avec mesure
Ces méthodes se sont révélées être de véritables différenciants
Comment ? Devops
Evite l’escalade systématique à chaque problème
Ansble : facile d’accès de l’ops au dév
Autom des le depart du POC
Les devops doivent permettre aux dévs de se mettre dans les conditions de la PRODUTIOCN
Poste de dév :
Structurant : tâche à tiroirs
Virtualiser plutôt les applicatifs périphériques « corporate »
Comment ? Industrialisation
L’industrialisation dès le début, même au niveau POC
Les tests automatisés à tous les niveaux : TU, TI, TF, en respectant la répartition de l’effort investi selon le type de Tests selon les standards
Un outillage de bootstrap significatif est cependant nécessaire sur ces technos
Les tests de déploiement
Les tests de scripts
Les tests de PRA : facilités par le caractère HA de l’architecture et ses briques
Les tests de performance automatisés
Faire tableau Must have, nice to have, Im a mack!
Le tout progressivement
Pour chaque projet initial
Rejouer mêmes les scripts régulièrement pout identifier les erreurs au plus tôt
Destruction régulière des environnements pour les recréer : procure stabilité et maîtrise
S’assure de la Haute Disponibilité
Quels moyens y mettre ?
Opter pour les environnements jetables : Cloud privé ou externe, en ayant validé sa fiabilité, adaptation aux besoins et sa performance globale (qualité d’APIs, vitesse de reconstruction, délai d’allocation de machines, constance des ressources annoncées, stabilité, …)