La résilience

Le mode de défaillance le plus courant d’un système distribué n’est pas la panne franche, c’est la lenteur qui se propage : un service dégradé retient ses appelants, qui saturent leurs files et retiennent les leurs. Quatre mécanismes s’y opposent. Leur application à la gateway relève du pilier médiation. Leur conception est une affaire d’architecture, et les réglages ci-dessous en sont l’essentiel.

Les timeouts

Tout appel sortant porte un délai maximal. Sans lui, les autres mécanismes ne servent à rien : un appel qui attend indéfiniment occupe une ressource indéfiniment.

La règle de réglage : décroissants de l’extérieur vers l’intérieur. Si l’appelant accorde deux secondes au total, l’appel interne n’en reçoit pas trois. Chaque étage attend moins que son amont, sinon les attentes s’empilent au lieu d’échouer proprement, et l’appelant abandonne pendant que la chaîne continue de travailler pour personne.

Les retries

Un retry ne se justifie que si trois conditions tiennent : l’opération est idempotente, l’erreur est de celles qui peuvent disparaître, un délai dépassé ou un 503, jamais un 400, et le volume total est borné. Réessayer une création fabrique des doublons, réessayer sans borne transforme un incident en attaque involontaire contre son propre backend.

Les réglages qui tiennent : un ou deux retries au plus, espacés avec une part d’aléatoire pour que les clients ne reviennent pas tous au même instant. Plus un budget global, la part du trafic autorisée à être des retries, au-delà de laquelle on cesse. Côté API, fournir une clé d’idempotence dans le contrat rend les retries sûrs, y compris sur les créations.

Le circuit breaker

Le circuit breaker cesse d’appeler un service qui échoue, pendant un délai, puis retente prudemment. Trois états : fermé, le trafic passe et les échecs se comptent sur une fenêtre glissante. Ouvert, les appels sont refusés immédiatement sans toucher au service. Entrouvert, quelques appels d’essai décident de la suite.

La seule décision difficile n’est pas le mécanisme, c’est la réponse pendant l’ouverture : un 503 immédiat, une valeur en cache assumée, une réponse partielle explicite. Ce choix est métier, le solde de la veille convient à une banque de détail et pas à une salle de marché, et il se prend à la conception, pas dans la configuration pendant l’incident.

Le cloisonnement

Le cloisonnement isole les ressources par destination ou par consommateur : des enveloppes de connexions séparées, des files distinctes, pour qu’une destination lente n’épuise pas les ressources communes. À la gateway, il prend la forme de limites par consommateur : sans elles, un seul client en boucle dégrade le service de tous les autres, ce qui transforme un bug chez un partenaire en incident de plateforme.

Où tout cela se place, et comment le vérifier

L’appelant se protège, l’appelé ne peut pas le faire pour lui : circuit breaker et délais vivent du côté de qui appelle. La gateway en porte vers chaque backend et protège ainsi l’ensemble des consommateurs, les services en portent entre eux, et le service mesh peut fournir délais et retries sans toucher au code, ce qui uniformise les réglages.

Aucun de ces mécanismes ne se règle une fois pour toutes : les seuils calibrés pour un trafic dix fois moindre ouvrent trop tôt ou trop tard. Et aucun ne se croit sur parole : couper réellement un backend sur un environnement d’essai, et regarder ce que reçoivent les consommateurs, est le seul test qui compte. Un circuit breaker jamais déclenché avant son premier incident se découvre pendant l’incident.