Nous voilà à la fin de cette série d'articles (disponibles ici, ici et ici) sur le circuit breaker.
Comment superviser le circuit breaker en production ?
Notre application a passé tous les tests et il est temps de passer en production.
Si l’on reste sur Hystrix, il existe beaucoup de métriques.
La liste est disponible sur le site officiel.
Une des difficultés d’une bonne supervision est de réussir à obtenir des tableaux de bord où, avec un simple coup d’oeil, on peut obtenir le maximum d’information.
La première étape est de choisir les bonnes métriques.
Notre sélection est :
Avec ces trois métriques, nous connaissons l’état de l’application rapidement.
Ce qui nous donne ce résultat :
Cette capture montre bien le fonctionnement d'un circuit breaker.
On y voit toutes les étapes.
On commence avec un service up et un circuit breaker fermé. Le ressenti utilisateur est bon.
Vers 12h55 le service tombe et nous commençons à avoir les premières erreurs côté utilisateur.
Le circuit breaker se déclenche (le temps d’avoir dépassé le seuil d’ouverture) et on passe en mode dégradé.
Vers 13h55 le service se met en nouveau en route, mais nous restons en mode dégradé le temps que le circuit breaker passe du mode ouvert à semi-ouvert et enfin fermé.
Une fois fermé, tout devient à nouveau normal comme nous le constatons.
Avant de vouloir en mettre partout, il faut connaître les limites et ce que cela implique.
Le but du circuit breaker est de gérer des problèmes de dépendances.
Et cerise sur le gâteau, il peut aussi dans certains cas gérer les pics de charge de notre application en désactivant (avec le passage en mode dégradé) les services qui ne supportent pas la charge.
Dans un premier temps, le circuit breaker ne peut pas s’appliquer à tous les cas, car une solution de repli est nécessaire. Par exemple un batch qui tourne toutes les nuits et qui doit générer des résultats fiables à partir de plusieurs services. Si un service n’est pas disponible, le calcul ne pourra pas être réalisé.
Une autre difficulté est la partie paramétrage du circuit breaker (condition pour ouvrir le circuit breaker, à partir de quand on passe dans l’état semi-ouvert….). Sans une bonne supervision de l’application et une bonne connaissance fonctionnelle, ce paramétrage peut devenir très fastidieux et compliqué à mettre en place.
Une préconisation pour le bon fonctionnement du circuit breaker est d’avoir une solution de repli (fallback) qui réponde rapidement et soit toujours disponible. Dans certains cas, une solution simple peut être de stocker la réponse alternative de manière statique sur un AWS S3.
Dernier point, avec la multiplication des couches (plusieurs circuit breaker, répartiteur de charge…), le timeout configuré dans le circuit breaker peut s’accumuler avec les autres timeout et donc ne pas être aussi réactif que voulu.
Après cette série d’articles se pose la question suivante “Est-ce qu’il faut utiliser le pattern circuit breaker, et si oui quand ?”.
Quelques questions à se poser avant son utilisation :
Une fois les réponses obtenues, nous pouvons nous demander si d’autres personnes l’utilisent et si on trouvera facilement de la documentation.
La réponse est oui pour ces deux questions : Netflix l’utilise sans problème depuis des années dans des conditions extrêmes et trouver de la documentation est trivial.
De plus, le circuit breaker est vraiment le couteau suisse d'une architecture cloud, car il permet d’implémenter d’autres patterns (timeout, graceful degradation, fail fast…).
Mais comme tout pattern, il induit de la complexité et il convient donc d’en peser le pour et le contre.
Pour aller plus loin, notre nouveau livre blanc sur le sujet vient de sortir :