Philosophie de l'ingénierie : Werner Vogels

Points clés

• Son principe fondateur est que tout tombe en panne en permanence, et qu’on conçoit donc pour la panne plutôt que contre elle. CTO d’Amazon depuis 2005, Werner Vogels a transformé une observation brute – à une échelle suffisante, la défaillance d’un composant est constante et statistiquement garantie – en une doctrine de conception : supposez que chaque disque, chaque serveur, chaque lien réseau et chaque dépendance va tomber en panne, et bâtissez des systèmes qui restent disponibles à travers la panne au lieu de prétendre qu’on peut l’empêcher.¹⁶
• Il est coauteur de l’article Dynamo, qui a ouvert la voie aux idées derrière le NoSQL moderne. « Dynamo : Amazon’s Highly Available Key-value Store » (SOSP 2007) a réuni le hachage cohérent, les horloges vectorielles, les quorums lâches, l’appartenance par rumeur et la cohérence à terme dans un seul magasin toujours inscriptible, et a directement influencé Cassandra, Riak, Voldemort, ainsi que le propre DynamoDB d’Amazon.²³
• Il est le principal évangéliste de la cohérence à terme. Son essai « Eventually Consistent » a exposé clairement l’arbitrage entre disponibilité et cohérence : quand le réseau se partitionne – et à grande échelle, il le fera – vous devez choisir, et Dynamo a choisi de rester disponible et de converger bientôt plutôt que de bloquer jusqu’à ce que chaque réplique soit d’accord.⁴⁷
• Il a légué à la culture d’ingénierie la formule « you build it, you run it » (qui le construit l’exploite). Lors d’une conversation en 2006, il a décrit le modèle d’Amazon où les développeurs possèdent leurs services en production – en les cadrant, les construisant et les exploitant – et a soutenu que mettre les bâtisseurs au bipeur et face au client est ce qui tire la qualité vers le haut.⁵

Le principe

« Everything fails, all the time. » (Tout tombe en panne, en permanence.) – Werner Vogels, CTO d’Amazon, sur la conception de systèmes distribués fiables⁶

La plupart de l’ingénierie optimise pour le cas où tout fonctionne. Vous écrivez le chemin idéal, traitez les quelques erreurs que vous pouvez imaginer, et livrez. Cet instinct survit jusqu’au moment précis où vous exploitez à grande échelle – et là, il vous trahit. Quand vous faites tourner des centaines de milliers de machines, « rare » cesse d’être rare. Une panne de disque qui survient une fois tous les trois ans par lecteur survient quelque part dans votre flotte toutes les quelques minutes. Un lien réseau qui perd un paquet sur un million perd des millions de paquets par jour. La formule la plus célèbre de Vogels comprime cela en quatre mots : tout tombe en panne en permanence.⁶ La panne n’est pas une exception à contourner par la conception ; à grande échelle, c’est la condition de régime permanent pour laquelle vous devez concevoir.

Le principe qui en découle est l’inverse du principe habituel. Si vous ne pouvez pas empêcher la panne – et à grande échelle, c’est démontrable, vous ne le pouvez pas – alors l’empêcher est le mauvais objectif. Le bon objectif est de rester disponible pendant que les choses tombent en panne. Vous supposez donc que chaque composant va mourir, et vous concevez de sorte que n’importe quelle mort isolée soit survivable : répliquez les données entre machines pour que la perte de l’une soit invisible, découplez les services derrière des API pour qu’une dépendance défaillante dégrade une fonctionnalité au lieu de renverser le système, et minimisez le rayon d’impact de toute faute isolée afin qu’elle ne puisse pas tout faire tomber. Le système n’est pas bâti pour éviter le cas de panne ; il est bâti pour que le cas de panne soit ennuyeux.¹⁶

Il y a une seconde moitié au principe, et c’est elle qui rend la première réelle : vous ne pouvez pas avoir une cohérence parfaite et une disponibilité parfaite en même temps dès lors que le réseau peut se partitionner, vous devez donc choisir – et Vogels a choisi la disponibilité. Quand une coupure réseau isole vos répliques les unes des autres, un système peut soit refuser de répondre jusqu’à ce que tout le monde soit d’accord (cohérent, mais indisponible), soit continuer à répondre avec ce qu’il a et réconcilier plus tard (disponible, mais brièvement incohérent). Pour le panier d’Amazon, refuser de répondre était inacceptable – un panier qui rejette un « ajouter au panier » pendant une partition est un panier qui perd une vente.⁴ Dynamo accepte donc toujours l’écriture et laisse les répliques converger ensuite. Le coût est une petite fenêtre où des répliques différentes peuvent renvoyer des réponses différentes ; le gain est un système qui ne dit jamais « non » à un client. Cet arbitrage – rester disponible et converger bientôt plutôt que bloquer jusqu’à ce que tout le monde soit d’accord – c’est la cohérence à terme, et Vogels a passé une carrière à soutenir que c’est le bon arbitrage à grande échelle.⁴⁷

Contexte

Werner Vogels est né le 3 octobre 1958 à Ermelo, aux Pays-Bas.¹ Son chemin vers l’informatique n’a pas été la ligne droite conventionnelle passant par une grande université. Il a étudié l’informatique à l’Université des sciences appliquées de La Haye, terminant en 1989, et n’a obtenu que plus tard un doctorat en informatique à l’Université Vrije d’Amsterdam – sa thèse de 2003, « Scalable Cluster Technologies for Mission Critical Enterprise Computing », fut dirigée par Henri Bal et Andrew Tanenbaum, ce dernier l’une des figures fondatrices du domaine en systèmes distribués et systèmes d’exploitation.¹ Le détail à retenir, c’est que le doctorat a suivi des années de travail réel sur les systèmes plutôt que de le précéder ; la théorie a rattrapé la pratique.

Le chapitre le plus formateur est venu à l’Université Cornell, où de 1994 à 2004 il fut chercheur travaillant sur des systèmes d’entreprise extensibles et fiables.¹ À Cornell, il était au sein du groupe de systèmes distribués de Ken Birman – la lignée derrière Isis et la communication de groupe fiable, ce corpus de travaux qui demandait comment un ensemble de machines peut s’accorder, rester cohérent et continuer à tourner pendant que ses membres tombent en panne et se rétablissent. Il a cofondé une entreprise, Reliable Network Solutions, avec Birman et Robbert van Renesse, et en fut le VP et le CTO.¹ Voilà le terreau intellectuel dans lequel Vogels a grandi : non pas « comment empêcher les machines de tomber en panne », mais « comment un groupe de machines reste correct et disponible pendant que ses membres tombent en panne ». Quand il a dit plus tard que tout tombe en panne en permanence, il n’improvisait pas – il énonçait la prémisse fondatrice de la tradition des systèmes distribués fiables dans laquelle il avait passé une décennie.

Il a rejoint Amazon en septembre 2004 comme directeur de la recherche en systèmes, fut nommé CTO en janvier 2005, et y a ajouté le titre de VP en mars 2005 – le rôle qu’il occupe depuis, pilotant l’orientation technologique de toute l’entreprise.¹ Son arrivée a coïncidé avec les années où Amazon inventait le cloud moderne : le système de stockage Dynamo fut construit et rédigé durant cette période, Amazon Web Services lança ses services fondateurs, et Vogels devint la voix publique des principes d’architecture sous-jacents à tout cela – concevoir pour la panne, découpler via des services, embrasser la cohérence à terme, et confier la conduite d’un service aux personnes qui le construisent.²⁴⁵

Le travail

« Everything fails all the time » : concevoir pour la panne et cohérence à terme

Commencez ici, car c’est le principe transformé en ingénierie. La doctrine comporte deux gestes. Le premier est concevoir pour la panne : traiter chaque composant comme quelque chose qui va tomber en panne, et faire en sorte que le système survive à sa perte. Cela signifie de la redondance (répliquer pour qu’une copie puisse disparaître), du découplage (les services parlent à travers des API afin qu’une dépendance malade se dégrade en douceur au lieu de cascader), et un confinement du rayon d’impact (partitionner le système pour qu’une faute soit piégée dans une petite cellule au lieu de se propager).¹⁶ Le test d’une conception n’est pas « est-ce que ça marche quand tout est sain » mais « que se passe-t-il quand cette pièce meurt au pire moment possible » – et la réponse doit être « le système continue à servir ».

Le second geste est celui qui rend la haute disponibilité possible à grande échelle : la cohérence à terme. L’observation CAP d’Eric Brewer dit que, lorsque le réseau se partitionne, un système distribué ne peut pas être à la fois parfaitement cohérent et pleinement disponible – il doit renoncer à l’un des deux.⁷ L’essai « Eventually Consistent » de Vogels rend le choix explicite et définit l’alternative avec précision : sous la cohérence à terme, « le système de stockage garantit que si aucune nouvelle mise à jour n’est faite sur l’objet, à terme tous les accès renverront la dernière valeur mise à jour ».⁴ Le mot à terme est tout l’arbitrage. Un système qui privilégie la disponibilité « peut toujours accepter l’écriture, mais sous certaines conditions une lecture ne reflétera pas le résultat d’une écriture récemment achevée ».⁴ Pendant une fenêtre brève et bornée, deux répliques peuvent diverger – mais aucune ne refuse jamais de répondre. La convergence se fait en arrière-plan, et l’utilisateur n’est jamais bloqué.

Pourquoi c’est important en tant qu’ingénierie : le modèle mental qu’ont la plupart des développeurs d’une base de données est celui de la machine unique, où une écriture est instantanément visible pour chaque lecture suivante parce qu’il n’y a qu’une seule copie. Ce modèle ne survit pas à l’échelle, car une seule copie est un point unique de défaillance et une seule machine est un plafond de débit. Au moment où vous répliquez – ce que vous devez faire pour être disponible – vous héritez de la question de ce que voit un lecteur pendant que les copies rattrapent leur retard. La contribution de Vogels fut d’insister sur le fait que ce n’est pas un bogue à cacher mais une dimension de conception à choisir délibérément, et de donner aux ingénieurs le vocabulaire – lecture de ses propres écritures, lectures monotones, cohérence de session – pour choisir exactement la quantité de cohérence dont une charge de travail donnée a réellement besoin, au lieu de payer partout pour la garantie la plus forte.⁴

L’article Dynamo et le mouvement NoSQL

Le principe a un artefact canonique : « Dynamo : Amazon’s Highly Available Key-value Store », que Vogels a coécrit et qui fut publié à SOSP 2007, le forum de référence du domaine pour les systèmes d’exploitation.² Dynamo fut la réponse d’Amazon à une exigence précise et brutale – le panier devait accepter les écritures toujours, même pendant des partitions de centre de données et des pannes de disque, car un panier indisponible perd directement du chiffre d’affaires.²³ Les bases de données relationnelles traditionnelles, réglées pour une forte cohérence, ne pouvaient pas le promettre sous partition. Amazon a donc construit un magasin qui troquait la cohérence contre la disponibilité et a noté exactement comment.

Dynamo est un catalogue de techniques de systèmes distribués assemblées en un seul système décentralisé toujours inscriptible, et l’influence de l’article vient de la netteté avec laquelle il les a exposées.²³ Le hachage cohérent partitionne les données entre nœuds afin que l’anneau puisse croître ou rétrécir sans tout rebrasser – « une extensibilité incrémentale, possiblement linéaire ».³ Les horloges vectorielles suivent l’histoire causale de chaque valeur afin que des écritures concurrentes puissent être détectées plutôt que silencieusement perdues. Les quorums lâches et le transfert avec indication maintiennent le système inscriptible même quand certaines répliques sont injoignables, en garant les écritures sur un remplaçant temporaire jusqu’au retour du nœud légitime. L’anti-entropie avec arbres de Merkle permet aux répliques de trouver et réparer efficacement leurs différences. L’appartenance par rumeur permet aux nœuds d’apprendre l’existence les uns des autres et de détecter les pannes sans coordinateur central – la conception est délibérément symétrique et décentralisée, de sorte que « chaque nœud de Dynamo devrait avoir le même ensemble de responsabilités que ses pairs », ce qui signifie qu’il n’existe aucun nœud spécial dont la mort serait catastrophique.³ Chacun de ces choix sert le même maître : rester disponible quand les choses tombent en panne.

Amazon n’a jamais publié le code de Dynamo, mais l’article, lui, a fait le travail – il est devenu l’un des articles de systèmes les plus influents de sa décennie, la graine intellectuelle du mouvement NoSQL.³ Apache Cassandra, Riak et Project Voldemort font tous remonter directement à lui leurs conceptions sans chef et cohérentes à terme.³ Et le nom a survécu commercialement dans Amazon DynamoDB, qui repose sur les principes de Dynamo même s’il a fait sous le capot des choix d’ingénierie différents (réplication à chef unique plutôt que le modèle purement sans chef de Dynamo).³ La leçon de l’influence de Dynamo vaut elle-même d’être notée : le fossé concurrentiel d’Amazon n’était pas le code, c’était la clarté. En expliquant précisément quelles garanties ils abandonnaient et pourquoi, ils ont appris à une génération d’ingénieurs comment raisonner sur l’arbitrage.

AWS, l’orientation service, et « you build it, you run it »

Dynamo est un système de stockage ; la contribution plus profonde de Vogels est architecturale et culturelle. La plateforme d’Amazon est bâtie comme un maillage de services indépendants qui ne parlent qu’à travers des API – aucune base de données partagée atteinte derrière le rideau, aucun couplage caché.⁵ Cette discipline compte pour la panne : quand les services sont découplés derrière des interfaces dures, l’un qui tombe en panne dégrade la fonctionnalité précise qu’il alimente au lieu de corrompre les données ou de figer les fils d’exécution de tout ce qui l’a touché. L’orientation service, c’est le confinement du rayon d’impact exprimé en architecture. C’est aussi ce qui a rendu AWS possible – une fois que vos systèmes internes sont des services propres, adressables par API, les exposer au monde extérieur comme produits est une étape suivante naturelle.

La moitié culturelle est la formule pour laquelle Vogels est cité aussi souvent que « tout tombe en panne en permanence » : « you build it, you run it » (qui le construit l’exploite). Lors d’une conversation de 2006 avec Jim Gray, il a décrit le modèle d’Amazon où chaque service est possédé de bout en bout par l’équipe qui le fait : « Chaque service a une équipe qui lui est associée, et cette équipe est complètement responsable du service – du cadrage de la fonctionnalité à son architecture, à sa construction et à son exploitation. »⁵ Et la justification portait explicitement sur la qualité par la propriété : « Qui le construit l’exploite. Cela met les développeurs en contact avec le fonctionnement quotidien de leur logiciel. Cela les met aussi en contact quotidien avec le client. »⁵ Il n’y a pas de mur par-dessus lequel jeter le code ; l’ingénieur qui a écrit le service en porte le bipeur. L’effet est une boucle de rétroaction serrée – la personne la mieux placée pour réparer une fragilité est celle qui en ressent la douleur à 3 heures du matin, et la personne qui a conçu la fonctionnalité entend directement la plainte du client. Ici, la propriété n’est pas un slogan RH ; c’est un mécanisme de fiabilité. Une équipe qui exploite ce qu’elle construit conçoit pour la panne parce que la panne réveille elle-même.

Évangéliser le cloud : rayon d’impact, cellules, et systèmes bien architecturés

Le quatrième corpus de travaux de Vogels est moins un artefact unique qu’un rôle soutenu : pendant deux décennies, il a été l’architecte-évangéliste qui a codifié comment bâtir sur le cloud, et pas seulement comment bâtir le cloud.¹⁶ Les thèmes récurrents sont le principe appliqué à une portée toujours plus large. Minimisez le rayon d’impact : partitionnez les systèmes en cellules indépendantes afin qu’une faute, un mauvais déploiement ou une requête empoisonnée soit confinée à une tranche de clients plutôt qu’à tous. Découplez agressivement : préférez des services asynchrones, faiblement couplés, avec des contrats explicites, aux chaînes synchrones serrées où une dépendance lente fige tout le chemin d’appel. Automatisez le rétablissement, ne le documentez pas : un guide opératoire qui requiert un humain ne s’exécute pas quand l’humain dort. Embrassez la panne comme une entrée de test, en injectant délibérément des fautes pour prouver que le système y survit plutôt que d’espérer qu’il le fera. Chacun de ces points est « tout tombe en panne en permanence » transformé en pratique opérationnelle – le message constant, répété à travers conférences, écrits et une seconde conversation ACM des années plus tard, selon lequel la résilience est une propriété qu’on conçoit dès la première ligne, pas une couche qu’on ajoute une fois la démo qui marche.⁶

La méthode

Lisez en travers de Dynamo, de la cohérence à terme, de l’orientation service et de « you build it, you run it », et les mêmes engagements reviennent. La méthode de Vogels est moins un slogan qu’un ensemble d’habitudes permanentes.

Concevez d’abord pour le cas de panne. À grande échelle, la panne est le régime permanent, pas l’exception, donc la question n’est jamais « est-ce que ça marche » mais « que se passe-t-il quand chaque pièce de ceci meurt ».⁶ La leçon se transpose bien au-delà de l’échelle d’Amazon : n’écrivez pas le chemin idéal pour ensuite rapiécer la gestion d’erreurs – énumérez d’abord les modes de panne et laissez le chemin qui fonctionne découler d’un système qui leur survit déjà. C’est la porte de l’évidence appliquée à la fiabilité – « ça marche dans la démo » ne prouve rien ; « ça reste disponible quand je tue un nœud en plein milieu d’une requête » est le même critère d’auto-guérison que Radia Perlman a bâti dans des réseaux qui reconvergent sans humain dans la boucle.

Choisissez votre cohérence, n’en héritez pas. Le geste le plus profond de Dynamo est de refuser le réglage par défaut selon lequel chaque lecture doit voir chaque écriture antérieure. Vogels fait de la cohérence un cadran que vous réglez par charge de travail – forte là où l’exactitude l’exige, à terme là où la disponibilité importe davantage – et reste précis sur la garantie qu’un système fournit réellement.⁴⁷ La discipline consiste à savoir exactement sur quoi repose votre affirmation de cohérence et à ne jamais payer pour une garantie dont une charge de travail n’a pas besoin. C’est la même précision sur l’exactitude que Leslie Lamport a apportée au temps distribué : ne présumez pas la propriété, définissez-la exactement et sachez quand elle tient.

Découplez pour confiner le rayon d’impact. Des services indépendants derrière des API dures signifient qu’une panne est piégée là où elle survient au lieu de cascader.⁵ L’habitude permanente consiste à tracer les frontières de sorte que le pire cas soit une fonctionnalité dégradée, jamais un système à terre – à demander de chaque dépendance : « quand celle-ci tombe, quelle est la taille du trou ? » et à faire en sorte que le trou soit petit. C’est la forme architecturale du produit minimum digne : la frontière la plus propre est celle qui fait exactement son travail et tombe en panne seule.

Faites en sorte que les bâtisseurs possèdent l’exploitation. « You build it, you run it » met les personnes qui conçoivent un service à son bipeur, bouclant la boucle entre une fragilité et la personne capable de la réparer.⁵ La leçon est que la douleur opérationnelle est le signal de qualité le plus honnête qui soit – une équipe isolée de la production sous-investira dans la résilience, parce que le coût de la fragilité retombe sur quelqu’un d’autre. La propriété est un mécanisme de fiabilité, c’est-à-dire la qualité est la seule variable transformée en organigramme : la seule façon de garantir la qualité est de faire ressentir au bâtisseur la conséquence de son absence.

Expliquez l’arbitrage au grand jour. L’influence de Dynamo n’est pas venue de son code – jamais publié – mais d’un article qui énonçait clairement quelles garanties étaient abandonnées et pourquoi.²³ L’habitude consiste à rendre le raisonnement lisible : nommez l’arbitrage, justifiez le côté que vous avez choisi, et apprenez à l’ingénieur suivant à raisonner dessus plutôt qu’à reproduire le résultat par culte du cargo. La clarté sur le pourquoi est ce qui permet à une conception de survivre à son auteur – la même discipline d’explication qui a rendu les articles de Perlman et de Lamport enseignables des décennies plus tard.

Chaîne d’influence

Qui l’a façonné

Ken Birman et la tradition Cornell des systèmes distribués fiables. La décennie de Vogels à Cornell, au sein du groupe de Birman et de la lignée Isis/communication de groupe fiable, est la source de sa prémisse fondatrice.¹ La question centrale de cette tradition – comment un groupe de machines reste correct et disponible pendant que ses membres tombent en panne et se rétablissent – est précisément la question à laquelle « tout tombe en panne en permanence » répond. Il n’a pas inventé un slogan ; il a réénoncé le premier principe de son domaine pour un public planétaire. (Influence formatrice)

Andrew Tanenbaum et l’académie des systèmes distribués. Son doctorat à l’Université Vrije fut dirigé en partie par Tanenbaum, l’un des enseignants fondateurs du domaine en systèmes d’exploitation et systèmes distribués.¹ L’assise se voit : Dynamo se lit comme une synthèse opérante du canon des systèmes distribués – hachage cohérent, horloges vectorielles, quorums, rumeur – assemblée par quelqu’un qui connaissait la littérature sur le bout des doigts. (Influence formatrice)

Eric Brewer et l’arbitrage CAP. Le plaidoyer de Vogels pour la cohérence à terme repose explicitement sur l’observation CAP selon laquelle un système tolérant aux partitions doit arbitrer la cohérence contre la disponibilité.⁴⁷ Brewer a posé l’impossibilité ; Vogels a opérationnalisé le choix à l’échelle d’Amazon et a fait de « choisir la disponibilité et converger » un défaut respectable. (Influence directe)

Qui il a façonné

Tout le mouvement NoSQL. L’article Dynamo est l’ancêtre direct de Cassandra, Riak et Voldemort, et l’éponyme de DynamoDB – le motif de conception sans chef et cohérent à terme s’est propagé d’un seul article de 2007 dans la couche de données de toute une génération de systèmes.³

L’architecture cloud-native et la culture DevOps. « You build it, you run it » est devenu l’une des idées fondatrices du DevOps moderne – la propriété de service de bout en bout, les développeurs d’astreinte et la dissolution du mur dev/ops remontent directement au modèle que Vogels a décrit en 2006.⁵

Une génération d’architectes cloud. À travers les principes de conception d’AWS et son évangélisation soutenue, « concevoir pour la panne », « minimiser le rayon d’impact » et « découpler via des services » sont devenus le vocabulaire par défaut que les ingénieurs emploient pour raisonner sur la construction de systèmes fiables dans le cloud.⁶

Le fil conducteur

Vogels est la clé de voûte à l’échelle opérationnelle de cette série – la figure qui a pris la théorie des systèmes distribués et l’a fait tourner sur une planète entière de machines. Leslie Lamport a donné aux systèmes distribués leurs fondations : comment définir le temps, l’ordonnancement et le consensus avec précision, et comment garder un système correct quand des participants tombent en panne ou se comportent arbitrairement. Vogels est ce à quoi ressemblent ces fondations quand elles doivent servir un panier du Black Friday – les mêmes questions de cohérence et de panne, répondues non pas sur un tableau blanc mais sous charge réelle, avec du vrai chiffre d’affaires misé sur le fait de rester disponible.⁴ Et Radia Perlman a bâti des réseaux qui traitent le cas de panne comme le centre de la conception, se guérissant eux-mêmes sans humain dans la boucle ; Vogels a bâti des services sur exactement cet instinct, un étage plus haut dans la pile – répliquer, découpler, confiner le rayon d’impact, et laisser le système converger de lui-même. Là où Lamport dit définissez l’exactitude et prouvez qu’elle survit à la panne et où Perlman dit bâtissez-le pour qu’il se guérisse lui-même, Vogels dit : tout tombe en panne en permanence, alors cessez d’essayer de l’empêcher – concevez pour que le système reste disponible droit à travers la panne, et laissez les bâtisseurs qui l’exploitent ressentir chaque fissure. (Pont de série)

Ce que j’en retiens

La leçon que je garde de Vogels est de traiter la panne comme le cas normal, pas l’exception. Mon instinct, comme celui de la plupart des bâtisseurs, est d’écrire le chemin où l’appel réussit, où la dépendance répond, où le disque est là – puis de boulonner un try/catch une fois que ça marche. « Tout tombe en panne en permanence » est la réprimande : à n’importe quelle échelle réelle, la panne n’est pas un événement rare qui arrive à mon système, c’est une condition constante dans laquelle mon système vit. Alors quand je construis quelque chose maintenant – une tâche de synchronisation, un client d’API, un consommateur de file – j’essaie de partir de « qu’est-ce qui meurt, et le reste continue-t-il à servir quand cela arrive ? » plutôt que d’y arriver en dernier. La version honnête de « ça marche » n’est pas la démo toute verte ; c’est tuer une dépendance en plein milieu d’une requête et regarder le système se dégrader en douceur au lieu de s’effondrer. Un système qui ne survit qu’au chemin idéal est un système dont je n’ai pas fini la conception.

La seconde leçon est que la disponibilité et la cohérence sont un arbitrage que je dois faire exprès. Il est tentant de vouloir les deux – que chaque lecture voie chaque écriture, et que le système ne dise jamais non – et pour une seule machine, on peut. À l’instant où je réplique quoi que ce soit, ce confort disparaît, et la discipline de Vogels est de choisir le côté délibérément pour chaque charge de travail plutôt que de retomber par habitude sur la garantie la plus forte partout. La plupart de ce que je construis n’a pas besoin qu’une lecture reflète instantanément la dernière écriture ; il a besoin de ne jamais refuser le client. La cohérence à terme a recadré cela pour moi, la faisant passer d’un compromis effrayant à un outil précis : nommez exactement à quel point un lecteur peut tolérer d’être périmé, achetez de la disponibilité avec ce mou, et cessez de payer pour une garantie dont la fonctionnalité n’a jamais eu besoin. Le savoir-faire ne consiste pas à toujours réclamer la promesse la plus forte – mais à savoir quelle promesse le travail exige réellement.

FAQ

Que signifie « everything fails all the time » (tout tombe en panne en permanence) ?

C’est la compression par Werner Vogels d’une leçon durement gagnée sur l’échelle : quand vous exploitez assez de machines, la défaillance d’un composant cesse d’être une exception rare et devient une condition constante, statistiquement garantie.⁶ Un mode de panne assez rare pour être ignoré sur un seul serveur survient quelque part dans une grande flotte en permanence. La conséquence pratique est l’inverse de l’ingénierie normale : au lieu d’essayer d’empêcher la panne, vous supposez que chaque disque, chaque serveur, chaque lien et chaque dépendance va tomber en panne, et vous concevez des systèmes qui restent disponibles à travers la panne – via la redondance, le découplage et un rayon d’impact confiné – afin que toute faute isolée soit survivable et, idéalement, invisible.¹⁶

Qu’est-ce que l’article Dynamo ?

« Dynamo : Amazon’s Highly Available Key-value Store » est un article SOSP de 2007, coécrit par Vogels, décrivant le système de stockage qu’Amazon a construit pour garder des services comme le panier inscriptibles même pendant des pannes et des partitions réseau.²³ Il combinait le hachage cohérent pour le partitionnement, les horloges vectorielles pour suivre les écritures concurrentes, les quorums lâches et le transfert avec indication pour rester disponible sous panne, l’anti-entropie avec arbres de Merkle pour la réparation, et la rumeur pour l’appartenance décentralisée – le tout au service d’accepter toujours une écriture et de réconcilier plus tard. Amazon n’a jamais publié le code, mais l’article est devenu fondateur du mouvement NoSQL, influençant directement Cassandra, Riak, Voldemort et Amazon DynamoDB.³

Qu’est-ce que la cohérence à terme ?

La cohérence à terme est un modèle de cohérence assoupli que Vogels a défendu et défini dans son essai « Eventually Consistent » : « si aucune nouvelle mise à jour n’est faite sur l’objet, à terme tous les accès renverront la dernière valeur mise à jour ».⁴ Dans un système répliqué, une écriture peut atteindre certaines répliques avant d’autres, de sorte que pendant une brève fenêtre des répliques différentes peuvent renvoyer des réponses différentes – mais aucune ne refuse jamais une requête. Le système reste disponible et converge en arrière-plan plutôt que de bloquer jusqu’à ce que chaque réplique soit d’accord. C’est le côté disponibilité de l’arbitrage CAP : quand le réseau se partitionne, un système peut être cohérent (refuser de répondre jusqu’à ce que tous soient d’accord) ou disponible (répondre avec ce qu’il a et réconcilier plus tard), et la cohérence à terme choisit disponible.⁴⁷

Que signifie « you build it, you run it » ?

« You build it, you run it » (qui le construit l’exploite) est la description par Vogels, issue d’une conversation ACM Queue de 2006, du modèle d’Amazon de propriété de service de bout en bout : l’équipe qui construit un service est « complètement responsable du service – du cadrage de la fonctionnalité à son architecture, à sa construction et à son exploitation ».⁵ Il n’y a pas de mur entre développement et exploitation – les ingénieurs qui ont écrit le code en portent le bipeur. Vogels a soutenu que cela « met les développeurs en contact avec le fonctionnement quotidien de leur logiciel » et « en contact quotidien avec le client », et que la boucle de rétroaction qui en résulte est ce qui tire la qualité vers le haut.⁵ L’idée est devenue l’un des principes fondateurs de la culture DevOps moderne.

Sources