Lors de l'article précédent, nous avons vu quelques solutions possibles pour résoudre la gestion des dépendances (externe ou interne) qui peuvent (et le seront tôt ou tard) défaillantes lors de l’exécution de notre application.
Regardons d'un peu plus près le design pattern circuit breaker.
Le circuit breaker permet de contrôler la collaboration entre différents services afin d’offrir une grande tolérance à la latence et à l'échec.
Pour cela, en fonction d’un certain nombre de critères d’erreur (timeout, nombre d’erreurs, élément dans la réponse), ce pattern permet de désactiver l’envoi de requêtes au service appelé et de renvoyer plus rapidement une réponse alternative de repli (fallback), aussi appelé graceful degradation.
Il agit comme un proxy implémentant une machine à états (Ouvert, Passant (fermé), Semi-ouvert) pour l’apprentissage de l’état du service.
On peut aussi le voir comme un feu tricolore de signalisation.
Comme nous pouvons le voir sur le schéma ci-dessus, en temps normal le circuit breaker est en mode passant.
Lorsque le nombre d’échecs successifs (ou toute autre métrique) dépasse un seuil, le circuit s’ouvre pour ne plus laisser passer de requêtes. À ce moment-là, deux mécanismes se déclenchent :
Une fois le seuil de passage à l’état semi-ouvert atteint (ici seuil du temps d’attente), le circuit breaker laisse à nouveau passer quelques requêtes et passe dans l’état passant si tout se déroule bien.
Avec un peu d’imagination, nous pouvons envisager une infinité de possibilités :
Toutes ces possibilités nous permettent d’implémenter d’autres patterns tels que :
Charge à l'architecte de faire preuve de discernement : le plus dur c'est de faire KISS, malgré tout ces beaux patterns qui nous font de l'oeil.
Bon, c’est bien beau tout ça, mais cela reste de la théorie. Dans ce cas, passons à des cas concrets.
Mais avant d’aller plus loin il est important de rappeler qu’il faut bien connaître le fonctionnel pour implémenter et paramétrer le circuit breaker.
Vous êtes aux commandes d’un site d’e-commerce de vente de modèles réduits de planeurs. Tout se passe bien jusqu’au jour où la fonctionnalité de recherche tombe en panne.
Sans circuit breaker et le passage en mode dégradé, point de salut et une course contre la montre commence pour restaurer au plus vite le service coupable. Pendant ce temps vos clients ne peuvent plus faire de recherche et s’en vont chez les concurrents.
Cette fois-ci vous êtes aux commandes d’un site de gestion de carte de fidélité. Les clients peuvent :
Pas de chance, le service de récupération du dernier montant de la carte de fidélité tombe en panne.
Sans circuit breaker, le client n’a plus l’information et appelle le support.
Avec le circuit breaker, on affiche la dernière valeur que l’on a mise en cache (par exemple toutes les nuits ou un peu avant le pic de consultation si l’on connaît l’heure...) avec la date de la valeur. Solution qui a été trouvée avec le métier après avoir hésité entre cette solution qui demande un effort d’implémentation et une solution beaucoup plus basique (affichage d’un petit message d’erreur compréhensible par le client).
Supposons que nous ayons deux services.
Le service 1 appelle le service 2 qui fait de lourds traitements (calcul mathématique, appel de traitement PL/SQL lourd...) qui finissent tous en erreur à cause d’un bug sur la nouvelle version.
Sans circuit breaker, le service 2 va passer son temps à faire de lourds traitements inutilement et donc consommer des ressources pour rien. Le service 1 va aussi consommer plus de ressources que nécessaire, car il va devoir maintenir des connexions/threads/objets en mémoire le temps d’avoir la réponse négative du service 2.
Si, de plus, l'hébergement est dans le cloud avec un prix à la consommation et qu’on a utilisé des Auto Scaling, la facture risque d’être salée.
Avec le circuit breaker, une fois déclenché, cette surconsommation aurait été évitée en passant en mode dégradé et en désactivant le service 2.
L’affichage d’une page de notre application fait appel à plusieurs services.
Pas de chance le service en bout de chaîne (service 4) tombe.
Le service 3 tombe à son tour, car dépendant des réponses du service 4. Les raisons du crash peuvent être nombreuses et diverses :
Et ainsi de suite, jusqu’à l’affichage d’une erreur incompréhensible au client.
Le circuit breaker aurait évité la propagation et seul le service 4 aurait été impacté.
Dans cet exemple, nous constatons bien l’avantage par rapport aux patterns timeout et retry qui auraient été inutiles, voir auraient empiré la situation.
Un autre pattern intéressant dans ce cas est le bulkhead, voire notre livre blanc pour plus de détails.
Toujours avec la même application, une autre fonctionnalité dépend de plusieurs services.
En temps normal tous les services répondent en moins de 500ms et donc notre fonctionnalité à un temps de réponse en dessous de la seconde (l’application met 500ms pour traiter tous les résultats des services).
Un problème intervient sur notre service catalogue qui ne répond plus. La réponse arrive 2s après (réglage du timeout).
Notre temps de réponse est donc maintenant égal au maximum des temps de réponse des services et du temps de traitement.
Ce qui nous donne 2s + 500ms = 2,5s
Sans circuit breaker notre fonctionnalité prendra toujours 2,5s pour répondre le temps que le service catalogue soit réparé.
Avec le circuit breaker, une fois ouvert et donc passage en mode dégradé, le temps de réponse descendra à nouveau à 1s. Ici le choix a été fait d’avoir un bon temps de réponse avec un mode dégradé, plutôt qu’un temps de réponse très mauvais avec la bonne réponse.
Maintenant que nous savons comment le design pattern marche et dans quelles situations il peut être utilisé, il nous reste à regarder comment le mettre en oeuvre.
Pour aller plus loin, notre nouveau livre blanc sur le sujet vient de sortir :