Petit-déjeuner OCTO - Le Réactif

www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 1PARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY
PETIT- DÉJEUNER
ARCHITECTURE
LOGICIELLE DU
FUTUR

www.octo.com - www.usievents.comPARIS - SAO PAULO - RABAT – LAUSANNE - SYDNEY 2
Pour commencer…

SI Ville

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

Nouvelles sollicitations pour nouveaux usages

Les SI vont subir des sollicitations exponentielles…
Source: Cisco VNI Global IP Traffic Forecast, 2014–2019

Nous approchons des limites physiques
CPU Mémoire de masse
RAM Réseau

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

Les défis du réactif

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

Orienté évènements – Message-Driven
https://en.wikipedia.org/wiki/Hollywood_principle
Don't call us,
we'll call you

Au plus vite - Responsive
Instantané
Léthargique
La machine
travaille
Switch mental Je reviens
Temps

Toujours en fonctionnement - Resilient

Scalabilité à tous les étages - Elastic
3000
utilisateurs
6000
utilisateurs
9000
utilisateurs
12000
utilisateurs

De nombreux concepts
BACK PRESSURE
ASYNCHRONE
CIRCUIT-BREAKER
MICROSERVICES
NOSQL
DISTRIBUTION
SHARDING
FLUX IMMUABLE
IDEMPOTENT
HTTP/2.0
MESSAGE
EVENT

Ceux qui ont déjà franchi le pas

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

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

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

Les types d’architecture réactive

La performance par la distribution

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.

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 ?

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

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
Historique
Analyses
PRA
Modèle CQRS
http://goo.gl/Xl73zikappa-
architecture.com

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
Mobile
HTML
Service Web
Sourcedes
événements
Historique

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
Mobile
HTML
Service Web
Sourcedes
événements

L’approche Réactive au service des Microservices
Microservice
Acteur
Microservice
Acteur
Microservice
Acteur
Microservice
Acteur
Microservice
Acteur
Microservice
Acteur
Microservice
Acteur
Microservice
Acteur

Réactif jusqu’au bout : Utiliser des API asynchrones
A2 A3
B1 B2
Thread 1
Thread 2
Concurrence
Attente I/O
Approche « probabiliste » (actuelle)
Calcul
C1 B2
Thread
Unique
No blocking IO
B1 A2
A1 B1 C1 A2 B2
C2
C2A3
A3
C2C1
A1
A1
Approche Réactive (Optimise la CPU)
Attente I/O

Retour d’expérience projet

Les 4 piliers du réactif
Responsive
ResilientElastic
Message-driven
Valeur
Aspect
Approche
Résister
à la panneRésister à
la charge

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

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
…

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

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

Cas d’école
Partie distribution
B F F
A B C D E F Z
Topic Client
B
F
F
Client

B F
F
FB
A B C D E F Z
Cas d’école
Partie traitement

B F
A B C D E F Z
Cas d’école
Partie stockage

A B C D E F
Des chaînes de traitement indépendantes
Pour une scalabilité linéaire

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

TESTS
Réglages

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

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
+

Haute disponibilité et élasticité

Technologie avec quorum
Quorum à majorité absolue = nombre de nœud / 2 + 1
Avec des nombres impairs c’est mieux !
Ticket d’entrée = 3

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

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
+

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é

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

Généraliser à tous les composants
Tuer chacun des composants
C*
Spark
KafkaApi
… Spark
KafkaApi
…
C*

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

Automatisation, actions manuelles ou programmées ?
+ +
Recette
Intégration
Développement
Production
+

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

SVN
Java
Maven
PL
SQL
PHP
Quoi de neuf chez notre client ?
Kafka
Git
Scala
Infra as
code
DevOps
Spark
Confluent
IO

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

Comment aborder la transition

Continuer
à produire
Produire
rapidement
de la
nouvelle
valeur
Ne pas rompre
la mécanique du
SI
Les enjeux du changement

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

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

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

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

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

• 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

Sources d’informations
http://blog.octo.com/tag/reactive/

Petit-déjeuner OCTO - Le Réactif

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (19)

Similar a Petit-déjeuner OCTO - Le Réactif

Similar a Petit-déjeuner OCTO - Le Réactif (13)

Más de OCTO Technology

Más de OCTO Technology (20)

Petit-déjeuner OCTO - Le Réactif

Notas del editor