Délais d’expiration, nouvelles tentatives, disjoncteurs, cloisonnement et dégradation gracieuse

La défaillance est normale ; sa propagation est facultative

Dans un système distribué, il y a toujours une dépendance lente ou défaillante : un prestataire de paiement passe une mauvaise minute, une base de données bascule sur une autre, un lien réseau perd des paquets, un déploiement tourne mal. La section 6.1 a montré pourquoi ces défaillances partielles ne peuvent pas être évitées et pourquoi un appelant ne peut souvent même pas savoir ce qui s’est passé. La question architecturale n’est donc pas de savoir comment éviter la défaillance, mais comment empêcher une défaillance locale de devenir globale. Une défaillance en cascade est la façon typique dont les systèmes meurent : une dépendance lente ralentit ses appelants, leurs ressources se remplissent de requêtes en attente, ils deviennent à leur tour lents pour leurs propres appelants, et en quelques secondes un problème dans un composant mineur a fait tomber toute la plateforme.

Michael Nygard a catalogué les patrons qui interrompent de telles chaînes dans Release It! (2007 ; deuxième édition 2018), en s’appuyant sur des pannes qu’il avait étudiées. Son observation centrale est que les points d’intégration, tous les endroits où un système en appelle un autre, sont la principale source d’instabilité, et que chacun a besoin d’une protection délibérée. Les patrons de cette section (délais d’expiration, échéances, nouvelles tentatives avec backoff, disjoncteurs, cloisonnement, solutions de repli, idempotence et couverture) constituent la boîte à outils standard. Ce sont des tactiques au sens de la section 2.5 : chacune est une décision unique visant la disponibilité, et chacune a un coût.

Délais d’expiration : le premier et le plus important des patrons

Un délai d’expiration (timeout) borne la durée d’attente d’un appelant. Sans lui, un appel à une dépendance qui ne répond jamais monopolise un thread, une connexion et de la mémoire aussi longtemps que le système d’exploitation garde la connexion ouverte, ce qui peut durer de nombreuses minutes. Beaucoup de bibliothèques clientes n’ont pas de délai d’expiration par défaut (la très répandue bibliothèque Python requests attend indéfiniment sauf indication contraire), si bien que l’absence de délai d’expiration est une décision de conception prise par omission. L’exemple commenté ci-dessous en montre la conséquence.

Deux délais d’expiration comptent généralement. Le délai d’expiration de connexion borne l’établissement d’une connexion et peut être court, quelques centaines de millisecondes à l’intérieur d’un centre de données, car un serveur sain accepte les connexions presque immédiatement. Le délai d’expiration de requête borne l’échange complet et doit venir de la mesure : légèrement au-dessus de la latence de la dépendance à un percentile élevé (p99 ou p99,9) sous charge normale, de sorte qu’il coupe les attentes pathologiques sans faire échouer les requêtes simplement lentes. Il doit aussi tenir dans le propre budget de l’appelant. Si l’API gateway abandonne au bout de 2 secondes mais que le service de commandes attend 10 secondes la tarification, le service de commandes continue de travailler pendant 8 secondes sur une requête que personne n’attend plus. Les délais d’expiration doivent donc raccourcir à mesure que l’on descend dans une chaîne d’appels, et c’est l’idée qui sous-tend les échéances.

Les échéances et leur propagation

Une échéance est un instant absolu auquel toute la requête doit être terminée. La propagation des échéances (deadline propagation) transmet le temps restant à chaque appel aval, de sorte que chaque service sait combien de budget il lui reste au lieu d’appliquer son propre délai d’expiration fixe. gRPC l’intègre nativement : un client fixe une échéance, le temps restant voyage avec l’appel, et un serveur peut vérifier si l’échéance est dépassée et arrêter le travail. Sur HTTP, les équipes propagent un en-tête contenant les millisecondes restantes ou l’échéance absolue, idéalement via le même middleware que celui qui propage le contexte de traçage (section 9.6).

La propagation apporte deux avantages. Un service peut échouer rapidement quand le temps restant est manifestement trop court pour le travail, plutôt que de lancer une requête de base de données qui ne pourra pas se terminer à temps. Et quand l’utilisateur abandonne, le travail en aval s’arrête aussi, au lieu de continuer à consommer de la capacité précisément pendant la surcharge qui a causé le retard. C’est du délestage de charge appliqué aux requêtes mortes, l’une des protections les plus efficaces dont puisse disposer un système sous contrainte.

Nouvelles tentatives avec backoff exponentiel et jitter

Beaucoup de défaillances sont transitoires : un paquet perdu, une connexion réinitialisée pendant un basculement, un bref 503 renvoyé par une instance surchargée. Réessayer les transforme en succès que l’utilisateur ne voit jamais. Mais les nouvelles tentatives sont aussi de la charge, et des nouvelles tentatives mal conçues comptent parmi les causes de pannes les plus courantes. Quatre règles les rendent sûres. Ne réessayez que les erreurs transitoires (délais d’expiration, échecs de connexion, 502, 503, 504, et 429 après le délai indiqué), jamais des erreurs qui se reproduiront, comme 400 ou 404. Ne réessayez que les opérations idempotentes ou celles qui portent une clé d’idempotence, car une requête qui a expiré a peut-être réussi. Réessayez un petit nombre de fois, en général deux ou trois. Et attendez entre les tentatives, avec un backoff exponentiel : un délai qui double à chaque tentative, jusqu’à un plafond.

Le backoff seul ne suffit pas. Si mille clients échouent au même moment, comme c’est le cas quand une dépendance a un raté, ils réessaient tous après 100 ms, puis tous après 200 ms, et arrivent en vagues synchronisées qui peuvent maintenir la dépendance à terre. L’article de Marc Brooker Exponential Backoff And Jitter (AWS Architecture Blog, 2015) a simulé ce phénomène et montré qu’ajouter de l’aléatoire, le jitter (gigue aléatoire), réduit fortement à la fois le travail total et le temps nécessaire pour terminer. Le jitter complet (full jitter) qu’il recommande attend un temps aléatoire compris entre zéro et la borne exponentielle : sleep = random(0, min(cap, base × 2attempt)). Le jitter a sa place partout où de nombreux clients agissent en même temps : nouvelles tentatives, reconnexions, dates d’expiration du cache et tâches planifiées.

import random, time

class TransientError(Exception):
    """Timeouts, connection resets, 502, 503 and 504 responses."""

def call_with_retries(fn, attempts=3, base=0.1, cap=2.0):
    for attempt in range(attempts):
        try:
            return fn()
        except TransientError:
            if attempt == attempts - 1:
                raise                      # give up: let the caller decide
            ceiling = min(cap, base * 2 ** attempt)
            time.sleep(random.uniform(0, ceiling))   # full jitter

Tempêtes de nouvelles tentatives et budgets de nouvelles tentatives

Les nouvelles tentatives se multiplient d’une couche à l’autre. Supposons qu’un toucher dans l’application mobile passe par l’API gateway, le service de commandes et le client de paiement, et que chacun des trois fasse jusqu’à trois tentatives. Si le prestataire de paiement est en panne, une seule action de l’utilisateur produit 3 × 3 × 3 = 27 appels vers lui, et une panne qui aurait dû se traduire par un taux d’erreur stable devient une tempête de nouvelles tentatives (retry storm) de 27 fois la charge normale, qui maintient le prestataire à terre même après la correction de la cause initiale. Les utilisateurs qui touchent de nouveau l’écran ajoutent une quatrième couche.

Trois défenses fonctionnent ensemble. D’abord, ne réessayez qu’à une seule couche, généralement la plus proche de la dépendance défaillante, et laissez les autres couches faire remonter l’erreur ; le livre SRE de Google recommande qu’un serveur surchargé le signale explicitement, pour que les appelants situés au-dessus ne réessaient pas. Ensuite, utilisez un budget de nouvelles tentatives (retry budget) : le livre SRE décrit le fait de n’autoriser les nouvelles tentatives que tant qu’elles restent sous 10 % des requêtes d’un client, ce qui plafonne la charge supplémentaire due aux nouvelles tentatives à environ 1,1 fois la normale, au lieu de jusqu’à trois fois. Les SDK d’AWS implémentent un quota similaire de jetons de nouvelle tentative, et la politique de nouvelles tentatives de gRPC inclut une régulation (throttling) dans le même but. Enfin, combinez les nouvelles tentatives avec un disjoncteur, pour qu’une dépendance que l’on sait en panne ne soit pas réessayée du tout.

Disjoncteurs

Un disjoncteur (circuit breaker), nommé ainsi par Nygard d’après l’appareil électrique, enveloppe les appels à une dépendance et observe leurs résultats. Tant que la dépendance est saine, le disjoncteur est fermé et les appels passent, tandis que les défaillances et les expirations de délai sont comptées. Quand les défaillances franchissent un seuil, par exemple la moitié des 20 derniers appels, le disjoncteur s’ouvre : pendant une période définie, chaque appel échoue immédiatement sans toucher au réseau, ce qui protège les threads de l’appelant et laisse à la dépendance le temps de se rétablir. Quand la période expire, le disjoncteur devient semi-ouvert et laisse passer quelques appels d’essai. S’ils réussissent, il se ferme ; si l’un d’eux échoue, il s’ouvre de nouveau pour une autre période. La description qu’en a donnée Martin Fowler en 2014 a fait largement connaître le patron, et la bibliothèque Hystrix de Netflix (désormais en mode maintenance) l’a popularisé dans les microservices ; Resilience4j pour Java et Polly pour .NET sont aujourd’hui les bibliothèques courantes, et les service meshes offrent des protections apparentées comme les limites de concurrence et la détection des instances aberrantes (dans Envoy, celles-ci s’appellent circuit breaking, bien qu’elles fonctionnent différemment).

Les réglages méritent réflexion. Qu’est-ce qui compte comme une défaillance ? Les expirations de délai et les réponses 5xx, oui ; les réponses 4xx, généralement non, car elles reflètent la requête de l’appelant plutôt que la santé de la dépendance. Les succès lents peuvent aussi compter, pour qu’une dépendance qui répond en 5 secondes soit traitée comme défaillante. La fenêtre doit être assez grande pour éviter un déclenchement sur deux ou trois appels malchanceux (les bibliothèques exigent un nombre minimal d’appels), et la période d’ouverture assez longue pour permettre le rétablissement, mais assez courte pour ne pas prolonger une panne. Les disjoncteurs doivent être définis par dépendance, et parfois par endpoint, pour qu’un endpoint de reporting défaillant ne coupe pas la prise de commandes. Les nouvelles tentatives doivent traiter un disjoncteur ouvert comme une réponse définitive plutôt que comme quelque chose à réessayer. Enfin, chaque changement d’état doit être journalisé et représenté sur un graphique, car un disjoncteur ouvert est un symptôme que quelqu’un doit voir.

import time

class CircuitOpen(Exception):
    pass

class CircuitBreaker:
    def __init__(self, failure_threshold=5, reset_after=30.0):
        self.failure_threshold = failure_threshold  # failures in a row that trip it
        self.reset_after = reset_after              # seconds to stay open
        self.failures, self.state, self.opened_at = 0, "closed", 0.0

    def call(self, fn, *args, **kwargs):
        if self.state == "open":
            if time.monotonic() - self.opened_at < self.reset_after:
                raise CircuitOpen("failing fast")   # no remote call at all
            self.state = "half-open"                # let a trial call through
        try:
            result = fn(*args, **kwargs)
        except Exception:
            self.failures += 1
            if self.state == "half-open" or self.failures >= self.failure_threshold:
                self.state, self.opened_at = "open", time.monotonic()
            raise
        self.failures, self.state = 0, "closed"    # success closes the circuit
        return result

payments = CircuitBreaker()
# payments.call(provider.authorise, order_id, amount, timeout=2.0)

Cloisonnement

La coque d’un navire est divisée par des cloisons étanches en compartiments, de sorte qu’une brèche inonde un seul compartiment au lieu de couler le navire. En logiciel, un cloisonnement (bulkhead) partitionne les ressources pour qu’une partie défaillante ou surchargée ne puisse pas tout consommer. La forme la plus courante donne à chaque dépendance son propre pool de threads, pool de connexions ou sémaphore borné : les paiements peuvent utiliser au plus 40 appels simultanés par instance, la consultation des restaurants 40, l’affectation des livreurs 40. Quand les paiements ralentissent, leur pool se remplit et les appels de paiement suivants sont rejetés immédiatement, mais les appels vers les restaurants et les livreurs continuent. Un délai d’expiration limite combien de temps chaque appel peut retenir des ressources ; un cloisonnement limite combien d’appels peuvent en retenir à la fois, si bien qu’il protège même quand les délais d’expiration sont trop longs.

Le cloisonnement fonctionne aussi à plus grande échelle. Des déploiements distincts du même service pour différents appelants (un pool d’instances du service de commandes pour l’application grand public, un autre pour l’API des restaurants partenaires) empêchent une intégration partenaire défaillante d’affamer les clients. Les architectures cellulaires, l’axe Z du cube de scalabilité, font de chaque cellule un cloisonnement pour une tranche de clients, et le shuffle sharding, décrit par des ingénieurs d’AWS, attribue à chaque client une petite combinaison aléatoire d’instances, de sorte que le trafic empoisonné d’un client n’affecte que très peu d’autres clients. Le coût de tout cloisonnement est le taux d’utilisation : la capacité réservée à un compartiment ne peut pas être prêtée à un autre, donc les pools doivent être dimensionnés à partir de la demande mesurée.

Solutions de repli et dégradation gracieuse

Quand un appel échoue ou qu’un disjoncteur est ouvert, l’appelant doit tout de même répondre. Une solution de repli (fallback) décide de ce qu’il renvoie. Les options, de la meilleure à la pire pour l’utilisateur, sont : une valeur en cache ou périmée (la dernière carte connue, avec des prix confirmés à l’étape de paiement) ; une valeur par défaut raisonnable (un délai de livraison estimé de 30 à 45 minutes au lieu d’une estimation en direct) ; une fonctionnalité réduite (des plats populaires au lieu de recommandations personnalisées) ; le report du travail (accepter un avis et le publier quand le service d’avis se rétablit) ; et une erreur claire et rapide qui indique à l’utilisateur quoi faire. Concevoir ces options fonctionnalité par fonctionnalité, avec le responsable produit, voilà ce que la dégradation gracieuse signifie en pratique : le parcours principal (parcourir, commander, payer, suivre) continue de fonctionner tandis que les fonctionnalités non essentielles s’effacent. La même réflexion guide le délestage de charge (section 9.3) : sachez à l’avance quelles fonctionnalités désactiver en premier.

Les décisions de sécurité sont l’exception : si le service d’autorisation est injoignable, le repli sûr est de refuser (échouer en mode fermé, fail closed), pas d’autoriser. Les praticiens ne sont d’ailleurs pas d’accord sur les solutions de repli en général. Nygard et les ingénieurs de Netflix les préconisent largement. Des ingénieurs d’Amazon ont soutenu, dans l’article de la Builders’ Library Avoiding fallback in distributed systems, que les chemins de repli sont rarement exercés, difficiles à tester, et peuvent eux-mêmes déclencher des pannes en faisant basculer un grand parc vers un mode non testé au pire moment ; ils préfèrent rendre le chemin principal plus fiable et échouer rapidement. Les deux positions s’accordent sur la règle pratique : une solution de repli doit être plus simple que ce qu’elle remplace, ne doit pas dépendre du composant défaillant, et doit être exercée régulièrement, par exemple lors de game days (section 9.8), faute de quoi elle ne devrait pas exister.

Idempotence : ce qui rend sûres les nouvelles tentatives et la couverture

L’idempotence est la propriété selon laquelle faire quelque chose deux fois a le même effet que le faire une seule fois. Tous les patrons de cette section qui répètent du travail en dépendent : les nouvelles tentatives après un délai d’expiration, les requêtes de couverture, la nouvelle livraison de messages après le plantage d’un consommateur, et les rejeux depuis une file de lettres mortes. La section 6.5 a montré comment une clé d’idempotence fait de POST /orders une nouvelle tentative sans risque, et la section 6.4 comment les consommateurs idempotents dédupliquent les messages. La règle architecturale est simple : avant d’ajouter une nouvelle tentative, vérifiez que l’opération est idempotente et, si elle ne l’est pas, ajoutez d’abord une clé ou une détection des doublons. Une politique de nouvelles tentatives sur un appel de paiement non idempotent n’est pas un patron de résilience ; c’est un générateur de doubles débits.

Requêtes de couverture

Les nouvelles tentatives traitent les défaillances ; les requêtes de couverture (hedged requests) traitent la lenteur. La section 2.4 les a présentées à partir de l’article The Tail at Scale de Dean et Barroso (2013) : envoyez une requête à une réplique et, si elle n’a pas répondu dans un délai égal, par exemple, à la latence du 95e percentile, envoyez une copie à une seconde réplique et utilisez la première réponse reçue, en annulant l’autre. Comme seuls les quelques pour cent de requêtes les plus lentes sont dupliqués, la charge supplémentaire est faible, tandis que la queue se réduit de façon spectaculaire, comme l’a montré le banc d’essai cité à la section 2.4.

La couverture a des préconditions. L’opération doit être idempotente, normalement une lecture. Il doit y avoir des répliques indépendantes, pour que la seconde copie ait peu de chances d’être lente pour la même raison. Les requêtes supplémentaires doivent être budgétées et désactivées en cas de surcharge, car quand toutes les répliques sont lentes, la couverture double la charge d’un système déjà en difficulté, exactement comme une nouvelle tentative non budgétée. Utilisée avec soin sur des chemins en fan-out à forte intensité de lecture, comme la recherche et la consultation des cartes, c’est l’un des outils les plus efficaces contre la latence de queue.