La Duck Conf : "Microservices et transactions distribuées"

OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable
29.01
2019
ESPACE ST
MARTIN - PARIS
#LaDuckConf

Transactions distribuées
Avenue Mon-Repos 14 > 1005 LAUSANNE > SUISSE > WWW.OCTO.COM

Bertrand
LE FOULGOC
Consultant
@OCTOSuisse
+41 79 138 01 22
blefoulgoc@octo.com
Julien
STAINER
Consultant
@OCTOSuisse
+41 75 418 79 34
jstainer@octo.com

Sommaire
◉ Définition
◉ Tolérance aux fautes
< Idempotence
< Files persistantes
◉ Patterns
< Chorégraphie
< Orchestration
◉ Tests
< Chaos
< Robustesse

THERE IS A BETTER WAY
Définition
6

Transaction distribuée (dans une architecture microservice)
< Un événement unique entraîne la mutation de deux ou
plusieurs sources de données distinctes qui ne peuvent
pas être validées atomiquement.
< Les transactions distribuées dans les microservices sont à
éviter autant que possible.
< L'atomicité cède la place à la cohérence éventuelle
Une définition
http://www.grahamlea.com/2016/08/distributed-transactions-microservices-icebergs/

Théorème de CAP (Brewer)
Chaque lecture reçoit la donnée
la plus récente ou une erreur
Chaque requête reçoit une réponse (non-erreur)
Le système fonctionne malgré la chute ou
le retard des messages

CALM Theorem
◉ Consistency and logical monotonicity
◉ Bloom language
◉ Disorderly distributed programming

Tolérance
aux fautes
10

< Prenons le cas d’un système de réservation de voyages
en Suisse, composé de trois services :
+ Un service permet la réservation de billets d’avion
+ Un autre la location de voitures
+ Le dernier permet de choisir un chalet et des skis
11
Problèmes – un cas concret
SCA

Problèmes – concentrons-nous sur un service
S
< Avec une approche naïve, sans file persistante

S
< Avec une approche naïve, sans file persistante
< Si le service tombe en vol, on perd la transaction, l’utilisateur attend, et reçoit un message
d’erreur
S

< Avec une file persistante
S

< Si le service tombe entre deux messages, pas de problème
S
S

< Si le service tombe entre deux messages, pas de problème
< Si le service tombe pendant le traitement d’un message, on perd la transaction
S
S

< Avec une file persistante, en supprimant uniquement une fois le message traité
< Si le service tombe pendant le traitement, pas de problème ?
S
S

< Avec une file persistante, en supprimant uniquement une fois le message traité
< Si le service tombe pendant le traitement, pas de problème ?
< Uniquement si le fait de rejouer la transaction n’est pas risqué, on parle d’idempotence
S
S

Problèmes – avec deux services
< Nous choisissons le fonctionnement en série
S

S

C

< Que se passe-t-il si mon deuxième service ne peut pas effectuer la réservation ?
C

< Que se passe-t-il si mon deuxième service ne peut pas effectuer la réservation ?
< Il faut traiter le cas, soit manuellement, soit automatiquement.
C

Patterns
24

< Pour chaque sous-transaction, nous définissons une
sous-compensation associée.
< Les sous-transactions et sous-compensations sont
idempotentes
< Attention aux transactions sans compensations
25
Patterns - Chorégraphie
SCA

C AS

S
C AS
C

C-1
C AS
S

Naturel, instinctif
Simple, facile à comprendre
Effort minimal
Aucun couplage à d'autres composants
Idempotent
Robuste
Complexité potentiellement exponentielle
Les dépendances cycliques sont difficiles à
diagnostiquer
Les tests de bout en bout sont difficiles
30

< Si le service en amont ne gère pas le séquencement et
que l’on lance tout en parallèle:
+ Comment compenser une transaction qui n’a pas eu lieu ?
+ Combien de temps garde-t-on le message ?
+ …
31
Patterns – passage en parallèle, montée à l’échelle
SCA

< Un journal des transactions est maintenu
32
Patterns - Orchestrateur
C AS

< Les compensations sont jouées en cas d’erreur
33
C AS C C-1
S

< Les compensations sont jouées en cas d’erreur
34
C AS C C-1
S
< L’introduction de parallélisme doit être justifiée, car ce choix augmente fortement la complexité

◉ « Smart end-points, dumb pipes »
C’est juste un service
il est idéalement interne à l'équipe
35
◉ « Smart pipes »
◉ Découpe un message en sous-messages
Un service pour les gouverner tous...
Géré par une équipe, implique les autres
On dirait un ESB !?

◉ « Smart end-points, dumb pipes »
C’est juste un service
Il est idéalement interne à l'équipe
36
◉ « Smart pipes »
◉ Découpe un message en sous-messages
Un service pour les gouverner tous...
Géré par une équipe, implique les autres
On dirait un ESB !?

Pas de dépendances cycliques
Simplifie les services
Plus facile à tester
Complexité linéaire
Idempotence
Résistance aux fautes
Logique décentralisée (! ESB)
Point de défaillance unique (redondance)
Couplage plus fort
37

Patterns – Chorégraphie vs Orchestrateur

Des
défis ?

◉ La disponibilité du système est le produit des disponibilités
des services
< 99.99% disponible signifie 53 minutes d'arrêt
< Devient 8 à 9 heures par an une fois combiné
◉ Les arrêts vont arriver, faites-en un non-événement
(design for failure)
< Hystrix
< Resilient4j
< …
◉ Le Monitoring devient plus critique que jamais
< Configurez des alertes
< Affichez les métriques système importantes
Défis techniques – Monitoring
https://www.youtube.com/watch?v=SmRcSezrsZM
Josh Evans QCon San Fransisco 2016
40

◉ Définition de SLAs pour chaque service
< RPObjective
< RTObjective
< Temps de réponse
< Charge maximale
< Disponibilité garantie
etc…
◉ Utilisez les indicateurs actuels pour commencer
< Empêche la régression
Informe les utilisateurs potentiels
Défis techniques – La Mesure
41

Tests
42

◉ Définir un état stable, à l'aide d'un groupe de contrôle
◉ Introduire des variations dans le groupe expérimental
◉ Mesurer les différences et agir en conséquence
https://principlesofchaos.org
Groupe de contrôle
Groupe expérimental
Tests – Chaos engineering
1%
1%
1%
99%

◉ Maturation rapide
◉ Beaucoup de bibliothèques et d'outils à choisir
◉ Ne commencez pas par les tests en prod
Chaos Monkey for Spring Boot
Tests – Chaos engineering
https://github.com/dastergon/awesome-chaos-engineering
Tests de sécurité dans AWS
https://openchaos.io
http://principlesofchaos.org

Tests – maîtrisez vos classiques
VS.
Manual
User Interface
Integration
Unit
Unit
Integration
End to end
Component
Exploratory

Impact d'un changement d'API a augmenté
< Déploiements indépendants
Dépendances entre services multipliées
Travailler avec des équipes séparées
< Release management
< Version management
RESTful API design
< Harmonisez
< Utilisez des guides clairs
Consumer driven contract
46
Tests – interactions des services

Tests – Cibler les tests de tolérance aux fautes
◉ Tests de résilience aveugles :
< les erreurs sont à corriger
< l’absence d’erreur ne garantit rien
◉ Tests unitaires et composants :
< permettent de valider le composant
< ne couvrent pas la configuration de l’environnement
< ne permettent pas de tester une chaîne de défaillances impliquant plusieurs composants
◉ Tests ciblés de défaillance :
< utilisation d’un debugger pour instrumenter les composants de façon peu intrusive
< scripting pour déclencher les défaillances au moments critiques
< possibilité de scénarios impliquant des chaînes de défaillances
< capacité à vérifier les comportements en situation critique dans une situation réaliste
47

Conclusion
Les transactions distribuées, c’est dur
Pourquoi
< Attention à l’over-engineering
Comment
< Prenez le temps de valider vos choix quant au théorème de CAP
Quoi
< Implémentation et tests des limites

Nous réalisons des missions de conseil IT et nous développons vos applications stratégiques… Différement.

La Duck Conf : "Microservices et transactions distribuées"

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à La Duck Conf : "Microservices et transactions distribuées"

Similaire à La Duck Conf : "Microservices et transactions distribuées" (15)

Plus de OCTO Technology

Plus de OCTO Technology (20)

Dernier

Dernier (6)

La Duck Conf : "Microservices et transactions distribuées"