Performances, scalabilité, résilience et exploitabilité

Bienvenue dans le chapitre 9 : Performances, scalabilité, résilience et exploitabilité. Une conception qui atteint ses objectifs sur un diagramme peut tout de même s’effondrer un vendredi à midi et demi, quand tous les bureaux de la ville commandent leur déjeuner. La différence tient rarement à du code astucieux. Elle tient à un ensemble de décisions architecturales : comment la capacité est ajoutée, comment la charge est répartie, comment le travail attend, comment les défaillances sont contenues, et comment les personnes qui exploitent le système savent ce qu’il fait.

Ce chapitre s’adresse aux développeurs et aux architectes qui connaissent les styles distribués du chapitre 6, et qui doivent garder un système rapide et opérationnel sous une charge réelle. Il s’appuie sur le chapitre 2, qui a rendu précises les performances et la disponibilité sous forme de scénarios d’attribut de qualité testables. Vous apprendrez ici à atteindre ces scénarios dans un système en fonctionnement, et à les garder vrais le jour le plus chargé de l’année. Il renvoie au chapitre 7 pour la réplication, le partitionnement et la mise en cache, plutôt que de les répéter. Et il mène au chapitre 10, consacré aux plateformes cloud, aux fonctionnalités de Kubernetes et aux conceptions multirégions sur lesquelles ces systèmes tournent généralement.

Deux exemples récurrents traversent le chapitre. Une plateforme de livraison de repas, avec des pics marqués à midi et le soir. Et une mise en vente de billets, où la demande passe de presque rien à plusieurs fois la capacité du système en quelques secondes. La section neuf point un compare la scalabilité verticale et la scalabilité horizontale, utilise le cube de scalabilité pour distinguer le clonage, le découpage par fonction et le découpage par données, et explique pourquoi l’autoscaling sur le CPU est souvent un mauvais choix. La section neuf point deux traite de ce qui se trouve devant les instances : les équilibreurs de charge, les algorithmes qu’ils utilisent, les contrôles de santé, le drainage des connexions, et les raisons pour lesquelles les sessions persistantes doivent céder la place à un état de session conservé hors de l’instance. La section neuf point trois porte sur ce qui se passe quand le travail arrive plus vite qu’il ne peut être fait : files bornées, back pressure, délestage de charge et limitation de débit, qui décident de ce qui est accepté, de ce qui attend et de ce qui est refusé poliment. La section neuf point quatre traite des défaillances entre services : délais d’expiration et échéances, nouvelles tentatives avec backoff et jitter, disjoncteurs, cloisonnement et solutions de repli.

L’exemple commenté de la section neuf point quatre montre comment un seul délai d’expiration manquant permet à une seule dépendance lente de faire tomber tout ce qui l’appelle. Le prestataire de paiement répond normalement en zéro virgule trois seconde. Aujourd’hui, il ne répond plus. Le service de commandes l’appelle sans délai d’expiration, si bien que, un par un, ses deux cents threads finissent tous par attendre des appels de paiement. Alors l’étape de paiement échoue. Mais l’historique des commandes et le suivi échouent aussi, alors qu’ils ne touchent jamais aux paiements, parce qu’il ne reste plus aucun thread libre pour les servir. La base de données est en parfaite santé, mais aucun thread n’est libre pour l’appeler. Les délais d’expiration, les disjoncteurs et le cloisonnement sont les patrons qui arrêtent ce type de cascade.

La seconde moitié passe des mécanismes à l’exploitation. La section neuf point cinq montre comment exprimer la fiabilité du point de vue de l’utilisateur, et comment un budget d’erreur transforme un objectif de disponibilité en une quantité de défaillances autorisées que les équipes peuvent dépenser en changements. La section neuf point six traite des journaux, des métriques et des traces qui permettent aux ingénieurs de poser de nouvelles questions à un système en production, ainsi que du traçage distribué avec OpenTelemetry. La section neuf point sept boucle la boucle entre prévisions et preuves, avec les tests de charge, de stress, d’endurance, de pic et de point de rupture, et un plan de capacité pour une mise en vente de billets. Et la section neuf point huit traite des défaillances qui surviennent malgré tout : des expériences délibérées pour trouver les faiblesses avant les clients, des rôles clairs pendant les incidents, et des revues sans reproche qui changent le système plutôt que les personnes.

Ce diagramme de la section neuf point cinq place trois termes sur une même échelle, à partir de la disponibilité de l’étape de paiement sur une fenêtre glissante de vingt-huit jours. L’objectif de niveau de service, ou SLO, est la cible interne : ici, quatre-vingt-dix-neuf virgule neuf pour cent. L’accord de niveau de service, ou SLA, est un contrat avec les partenaires, fixé moins haut, à quatre-vingt-dix-neuf virgule cinq pour cent. L’indicateur de niveau de service, ou SLI, est la mesure. Ce mois-ci, il est de quatre-vingt-dix-neuf virgule quatre-vingt-quatorze pour cent, dans la zone où le service reste dans son budget. En dessous du SLO, l’objectif est manqué, et une politique de budget d’erreur écrite indique ce qui se passe ensuite. Ce n’est qu’en dessous du SLA que des crédits de service sont dus. L’écart entre le SLO et le SLA est la zone d’alerte. Le budget d’erreur est simplement un moins le SLO. Sur trente jours, un objectif de quatre-vingt-dix-neuf virgule neuf pour cent autorise quarante-trois virgule deux minutes de panne totale, soit une requête sur mille en échec.

Les sections forment une chaîne, et elles mènent à une idée. Toute ressource est finie, donc tout système a un point de rupture. Le travail de l’architecte est de décider à l’avance de ce qui se passe quand il est atteint. Un système bien conçu soumis à une charge excessive ralentit en douceur, et se déleste d’abord du travail le moins important. Il refuse clairement, plutôt que d’expirer en silence. Il isole la partie défaillante. Et il se rétablit de lui-même quand la pression retombe. Un système mal conçu met en file sans limite, réessaie jusqu’à s’effondrer, et entraîne ses voisins dans sa chute. Ces mécanismes coûtent peu à ajouter lors de la conception, et cher à ajouter après coup. Qu’un service soit sans état, qu’une file soit bornée et qu’une requête porte une échéance, tout cela se décide bien avant le premier incident.

À la fin du chapitre, vous saurez choisir comment passer à l’échelle, et dimensionner un parc pour un pic connu avec la loi de Little et une marge de capacité. Vous saurez combiner délais d’expiration, échéances, nouvelles tentatives avec backoff et jitter, disjoncteurs, cloisonnement et solutions de repli pour contenir les défaillances. Vous saurez définir des indicateurs et des objectifs de niveau de service du point de vue de l’utilisateur, calculer des budgets d’erreur, et concevoir des alertes sur la vitesse à laquelle ils sont consommés. Et vous saurez planifier la capacité et les tests de performances, mener des expériences de chaos en toute sécurité, et animer des revues post-incident sans reproche.

Comme les sections forment une chaîne, mieux vaut les lire dans l’ordre. Mais chacune se suffit aussi à elle-même, et vous pouvez donc aller directement à la section dont vous avez besoin. Comptez environ trois heures et demie pour lire tout le chapitre. À la fin de chaque section, vous trouverez des questions d’autoévaluation. Répondez-y de tête avant de regarder les réponses. Quand vous serez prêt, un test facultatif du chapitre vous attend, qui dure environ quarante-cinq minutes. Il comporte vingt questions à choix multiples et deux réponses rédigées. La note de réussite est de quatre-vingts pour cent.

Voilà comment le chapitre est construit. Commencez par la section neuf point un, sur la scalabilité verticale, la scalabilité horizontale et le cube de scalabilité. À très vite.