Pourquoi distribuer, et les illusions de l’informatique distribuée

Ce qui rend un système distribué

Un système distribué est un ensemble de programmes, s’exécutant sur des ordinateurs différents, qui coopèrent en échangeant des messages sur un réseau pour fournir ce que les utilisateurs perçoivent comme un seul service. Votre application de livraison de repas en est un : le téléphone, les services de commandes et de paiement de l’entreprise, la tablette du restaurant, le téléphone du livreur et un processeur de paiement par carte jouent tous un rôle dans une même commande. Le chapitre 5 a décrit des styles déployés comme une seule unité (les monolithes) ; ce chapitre porte sur les styles dont les parties sont déployées séparément et communiquent à travers le réseau.

Leslie Lamport, qui a plus que quiconque contribué à donner au domaine des fondements mathématiques, en a résumé la difficulté essentielle dans un e-mail interne de mai 1987 : un système distribué est un système dans lequel la défaillance d’un ordinateur dont vous ignoriez jusqu’à l’existence peut rendre votre propre ordinateur inutilisable. La boutade fonctionne parce qu’elle est vraie. Dès qu’un système dépend de machines qu’il ne contrôle pas et ne voit pas, toute une catégorie de pannes apparaît, qui ne peuvent tout simplement pas se produire à l’intérieur d’un seul processus.

C’est pourquoi la distribution est une décision qui a un prix, et non un signe de maturité. La suite de cette section expose les raisons qui justifient ce prix, les fausses hypothèses qui conduisent à le sous-estimer, et une manière d’en calculer une partie avant de payer.

Pourquoi distribuer

Il existe une poignée de raisons légitimes de répartir un système entre plusieurs processus et machines. Chacune correspond à un attribut de qualité du chapitre 2 qu’une seule unité de déploiement peine à fournir au-delà d’une certaine taille. Chacune a aussi, à l’intérieur d’un monolithe, un substitut partiel moins coûteux, et un bon architecte examine d’abord ce substitut.

Deux observations découlent de ce tableau. Premièrement, les raisons les plus fortes sont souvent organisationnelles : la déployabilité indépendante et l’autonomie des équipes comptent surtout quand de nombreuses équipes travaillent sur un même produit, ce qui explique pourquoi la loi de Conway (chapitre 3) revient sans cesse dans ce chapitre. Deuxièmement, la distribution est rarement du tout ou rien. Beaucoup de systèmes réussis sont un monolithe modulaire accompagné de deux ou trois services séparés, chacun détaché pour une raison précise et nommée.

La défaillance partielle : le problème qui définit le domaine

À l’intérieur d’un processus, un appel de fonction soit retourne, soit le processus entier meurt avec lui. À travers un réseau, il existe une troisième issue, et elle change tout : la défaillance partielle, dans laquelle certaines parties du système fonctionnent tandis que d’autres sont en défaillance, lentes ou injoignables. Pire, l’appelant ne peut souvent pas savoir lesquelles.

Prenons le service des commandes qui demande au service de paiement d’autoriser £24,50. Si aucune réponse n’arrive avant le délai d’expiration, le service des commandes ne sait pas si la requête s’est perdue en chemin, si le service de paiement a planté ou s’est bloqué avant ou après avoir débité la carte, ou si la carte a été débitée et que seule la réponse s’est perdue. Du côté de l’appelant, les trois situations sont identiques.

Les conséquences pratiques façonnent toute conception distribuée. Une nouvelle tentative pourrait débiter le client deux fois : les opérations susceptibles d’être retentées doivent donc pouvoir être répétées sans risque. Cette propriété est l’idempotence, et on l’obtient généralement en donnant à chaque requête une clé unique que le récepteur mémorise. Une dépendance lente est souvent pire qu’une dépendance morte, car les appelants continuent d’attendre et immobilisent des threads et des connexions ; quand un service ralentit, ses appelants épuisent leurs ressources et ralentissent à leur tour : c’est une défaillance en cascade. Et comme un réseau peut se scinder de sorte que deux groupes de machines ne puissent plus se joindre tout en continuant de fonctionner, des données conservées aux deux endroits peuvent diverger : c’est le sujet de la section sur CAP, plus loin dans ce chapitre.

Il n’existe pas non plus d’horloge globale. L’horloge de chaque machine dérive et est corrigée séparément : les horodatages de deux services ne peuvent donc pas être comparés en toute confiance, et « qu’est-ce qui s’est passé en premier ? » peut être une question difficile. L’article de Lamport de 1978 sur le temps et les horloges dans les systèmes distribués a montré comment ordonner des événements sans s’appuyer sur des horloges physiques ; pour les architectes, la leçon est simplement de ne pas fonder la justesse sur la comparaison d’heures murales entre machines.

Les huit illusions de l’informatique distribuée

Les illusions de l’informatique distribuée sont huit hypothèses que font les personnes qui découvrent les systèmes distribués ; elles sont toutes fausses et finissent toutes par causer des problèmes. La liste vient de Sun Microsystems : L Peter Deutsch en a établi sept en 1994, en s’appuyant sur quatre que des collègues, dont Bill Joy, avaient déjà relevées, et James Gosling, le créateur de Java, a ajouté la huitième vers 1997. Trois décennies plus tard, chacune décrit encore, cette semaine, une vraie panne quelque part.

Ce que coûte la distribution

Chaque raison de distribuer se paie dans la même monnaie. La latence est le premier coût. Un appel de fonction à l’intérieur d’un processus prend quelques nanosecondes ; un aller-retour réseau entre machines du même centre de données prend généralement de quelques centaines de microsecondes à une milliseconde ou plus, avant toute sérialisation ou tout traitement. Entre continents, la physique fixe un plancher : la lumière dans une fibre optique voyage à environ 200 000 km par seconde, si bien qu’un aller-retour Londres–New York (environ 5600 km dans chaque sens) ne peut pas prendre moins d’environ 56 ms. L’arithmétique de la latence de queue du chapitre 2 s’applique à chaque saut.

L’observabilité est le deuxième. Dans un monolithe, une trace de pile raconte toute l’histoire d’une requête en échec. Dans un système distribué, l’histoire est éparpillée dans les journaux de nombreux services sur de nombreuses machines. L’observabilité, c’est-à-dire la capacité à comprendre ce que fait le système à partir de ce qu’il produit, doit être prévue dès la conception : identifiants de corrélation transmis à chaque appel, journaux centralisés, métriques par service et traçage distribué (chapitre 9).

La cohérence est le troisième. Une seule transaction de base de données peut mettre à jour une commande et son paiement de façon atomique. Quand la commande et le paiement vivent dans des services différents avec des bases de données différentes, il n’y a pas de transaction partagée ; le système doit accepter une période pendant laquelle les deux divergent et s’assurer qu’ils convergent. Les sections suivantes présentent les outils : les modèles de cohérence, ainsi que les sagas et le patron outbox.

La charge d’exploitation est le quatrième, et celui que l’on sous-estime le plus souvent. Chaque service a besoin d’un pipeline de build, d’un déploiement, d’une configuration, de secrets, d’une supervision, d’alertes, d’une planification de la capacité, de correctifs de sécurité et de quelqu’un d’astreinte. Les tests changent aussi : une modification n’est sûre que si chaque consommateur de son interface fonctionne encore, ce qui demande des tests de contrat et des changements rétrocompatibles. Ces coûts sont à peu près proportionnels au nombre d’unités déployables, c’est pourquoi le nombre de services compte.

Faire le calcul : les chaînes synchrones

Le moment le moins coûteux pour découvrir qu’une conception distribuée est trop fragile ou trop lente, c’est sur le papier. L’outil est la règle des éléments en série du chapitre 2 : si une requête a besoin que chaque composant d’une chaîne fonctionne, la disponibilité de la chaîne est le produit des disponibilités des composants, et sa latence est à peu près la somme de leurs latences.

Le quantum d’architecture, revisité

Le chapitre 5 a présenté le quantum d’architecture : une partie déployable indépendamment, à forte cohésion fonctionnelle, données comprises, à laquelle s’applique un même ensemble de caractéristiques d’architecture (Styles architecturaux, patrons et tactiques). Dans Software Architecture: The Hard Parts (2021), Ford, Richards, Sadalage et Dehghani affinent l’idée avec deux types de couplage. Le couplage statique est ce qui doit être présent pour qu’une partie puisse être déployée et exécutée : son code, ses bibliothèques, sa base de données et son infrastructure. Le couplage dynamique est la manière dont les parties dépendent les unes des autres pendant l’exécution : si elles s’appellent de façon synchrone ou asynchrone, et comment elles se coordonnent et restent cohérentes.

L’exemple commenté montre pourquoi l’aspect dynamique compte. Pendant toute la durée d’un appel synchrone, l’appelant ne peut pas terminer son travail si l’appelé n’est pas disponible et rapide ; les deux sont liés sur le plan opérationnel, et leurs disponibilités et latences se combinent comme calculé ci-dessus. Cinq services déployés séparément dans une chaîne synchrone constituent cinq unités de déploiement, mais pour la disponibilité de Commander, ils se comportent comme une seule unité fragile. Cette dépendance au fait que l’autre partie soit disponible au même moment est le couplage temporel. La messagerie asynchrone en supprime une grande partie : si le service des commandes dépose un message dans une file durable, le service de paiement peut être indisponible pendant une minute puis rattraper son retard, et le client obtient quand même un numéro de commande. Le prix à payer est que le client n’obtient pas immédiatement de réponse définitive, ce qui est autant une décision produit qu’une décision technique.

C’est la leçon la plus profonde de la section. Tracer les frontières des services, c’est la moitié de la conception ; décider quelles interactions doivent être synchrones, et garder cet ensemble réduit, c’est l’autre moitié.