- Les ingénieurs en systèmes distribués apprennent souvent à travers les blessures laissées par des erreurs commises en production
- Cet article a été écrit pour éviter aux nouveaux ingénieurs d’avoir à subir ces mêmes blessures
Les systèmes distribués échouent souvent
- Contrairement à d’autres domaines de l’ingénierie logicielle, les systèmes distribués ont une forte probabilité d’échec. En particulier, la probabilité d’échecs partiels est élevée.
- Les ingénieurs systèmes qui n’ont jamais travaillé en calcul distribué proposent des idées comme « il suffit d’envoyer l’écriture aux deux systèmes » ou « il suffit de réessayer l’écriture jusqu’à ce que ça marche »
- Les systèmes en réseau tombent en panne plus souvent qu’une machine unique, et ces pannes ont davantage de chances d’être partielles
- Une des écritures peut réussir tandis que l’autre échoue : comment obtenir alors une vue cohérente des données ? Ce type d’échec partiel est bien plus difficile à raisonner
- Des problèmes peuvent survenir : un switch qui tombe, un leader qui « disparaît » à cause du garbage collection, ou une écriture socket qui semble avoir réussi alors qu’elle a en réalité échoué. Lire depuis la mémoire locale est bien plus fiable que lire à travers quelques switches
- Il faut « concevoir en prévoyant l’échec »
Écrire des systèmes distribués robustes coûte plus cher
- Construire une solution distribuée robuste coûte plus cher qu’une solution sur une machine unique.
- Les machines virtuelles et les technologies cloud rendent l’ingénierie des systèmes distribués moins coûteuse, mais cela reste cher.
- Les simulations sont utiles, mais elles ne permettent pas de résoudre tous les problèmes qui surviennent dans un environnement distribué réel.
Les systèmes distribués open source robustes sont rares
- Le coût d’exploitation d’un grand nombre de machines sur une longue période pèse sur la communauté open source.
- Les personnes qui écrivent du code open source comme hobby n’ont souvent pas les ressources financières nécessaires pour explorer ou résoudre les nombreux problèmes des systèmes distribués.
- Certains problèmes sont résolus par des ingénieurs en entreprise, mais leurs priorités ne coïncident pas toujours.
La coordination est très difficile. Il faut l’éviter autant que possible
- La clé de la scalabilité horizontale, c’est l’indépendance. Il faut minimiser la communication et le consensus entre machines.
- Chaque fois que deux machines doivent se mettre d’accord sur quelque chose, l’implémentation du service devient plus difficile.
- L’algorithme Paxos est extrêmement difficile à implémenter.
Si le problème tient en mémoire, c’est probablement un problème trivial
- Pour un ingénieur en systèmes distribués, un problème limité à une seule machine est considéré comme facile.
- Quand les données sont à quelques switches de distance, il est plus difficile de les traiter rapidement.
La « lenteur » est le problème le plus difficile
- La « lenteur » peut signifier qu’un ou plusieurs systèmes parmi ceux qui traitent une requête utilisateur sont lents.
- Les échecs partiels n’apparaissent pas sur les graphiques, et tant qu’ils ne deviennent pas évidents, il est difficile d’obtenir les ressources nécessaires pour les résoudre.
Il faut implémenter la backpressure à l’échelle de tout le système
- La backpressure désigne la manière dont le système fournisseur signale des échecs au système demandeur, et comment ce dernier traite ces échecs.
- Sans mécanisme de backpressure, il y a un risque élevé d’échecs en cascade ou de pertes de messages involontaires.
Il faut trouver des moyens d’être partiellement disponible
- Cela désigne la capacité à renvoyer une partie des résultats même si une partie du système est en panne.
- Par exemple, un système de recherche renvoie les résultats déjà collectés s’il ne peut pas parcourir tous les documents dans le temps imparti.
Les métriques sont le seul moyen d’aller au bout du travail
- Exposer des métriques est le seul moyen de comprendre comment le système fonctionne réellement.
- Les fichiers de logs sont utiles, mais ils mentent souvent. Les logs de succès ne sont généralement pas enregistrés, car ils sont redondants dans la plupart des cas.
Il faut utiliser les percentiles, pas les moyennes
- Les percentiles sont plus précis et plus utiles que les moyennes. Les moyennes mènent souvent à de mauvaises décisions.
Il faut apprendre à estimer la capacité
- Il est important de savoir combien de machines sont nécessaires pour effectuer un travail.
- Par exemple, on fait souvent des calculs rapides sur un coin de table, comme estimer combien d’identifiants de tweets peuvent tenir en mémoire.
Les feature flags sont une manière de déployer l’infrastructure
- Les feature flags sont une méthode courante pour déployer progressivement de nouvelles fonctionnalités dans un système.
- Ils permettent de gagner en confiance sur un projet et de réduire le coût d’un échec.
Il faut choisir intelligemment l’espace d’identifiants
- L’espace d’identifiants d’un système façonne la structure du système.
- Par exemple, les identifiants de tweets dans l’API Twitter sont de simples nombres 64 bits, sans lien avec d’autres données.
Il faut exploiter la localité des données
- Il est plus efficace de garder le traitement et la mise en cache des données au plus près du stockage persistant.
- Le réseau subit plus de pannes et de latence qu’un déréférencement de pointeur ou qu’un
fread(3).
Réécrire des données mises en cache dans le stockage persistant est une mauvaise idée
- Ce problème apparaît dans de nombreux systèmes. Il est particulièrement fréquent dans les systèmes conçus par des personnes ayant peu d’expérience en systèmes distribués.
Les ordinateurs peuvent faire bien plus qu’on ne le pense
- Il existe beaucoup d’idées fausses sur les capacités des ordinateurs, souvent véhiculées par des praticiens peu expérimentés.
- Les serveurs web modernes peuvent traiter des milliers de requêtes en quelques centaines de millisecondes.
Il faut utiliser le théorème CAP pour critiquer un système
- Le théorème CAP n’est pas quelque chose qu’on utilise pour construire un système. En revanche, il est utile pour critiquer la conception d’un système distribué.
Il faut extraire des services
- Ici, un service désigne un système distribué qui encapsule une logique de plus haut niveau qu’un système de stockage.
- Extraire des services permet un déploiement plus rapide et plus simple que de créer des bibliothèques.
Résumé de GN⁺
- L’ingénierie des systèmes distribués se distingue des autres domaines du logiciel par sa forte probabilité d’échec et par les échecs partiels.
- Écrire des systèmes distribués robustes coûte plus cher, et ils sont rares dans la communauté open source.
- Il est important de comprendre et d’implémenter des concepts comme la coordination, la localité des données, la backpressure et la disponibilité partielle.
- L’usage de métriques et de percentiles, des feature flags et d’un bon choix d’espace d’identifiants permet d’améliorer l’efficacité et la stabilité du système.
- Il est utile d’utiliser le théorème CAP pour critiquer un système, et d’extraire des services quand c’est nécessaire.
1 commentaires
Avis sur Hacker News
Le principe CALM (Consistency as Logical Monotonicity) est plus facile à comprendre que CAP et constitue un résultat plus fondamental
Une livraison exactement une fois est impossible ; il faut choisir entre une livraison au plus une fois ou au moins une fois
Bon article. Il date d’il y a 8 ans, mais il reste encore très pertinent sur de nombreux points
Liens vers des discussions passées :
J’aime l’explication pratique et réaliste. Il n’y a pas de buzzwords comme « microservices »
Quand il travaillait chez Lookout, Jeff Hodges a présenté cet essai
J’ai eu l’occasion de travailler avec l’auteur de ce texte
Beaucoup de choses ont changé depuis 2013
fsyncdans PostgreSQL