Liste de lectures sur les systèmes distribués (2014)
(dancres.github.io)- La clé pour apprendre les systèmes distribués réside davantage dans un changement de mode de pensée que dans une technologie particulière, et cette liste permet de suivre, thème par thème, les problèmes rencontrés lors de la conception de systèmes à l’échelle d’Internet
- Les ressources sont réparties entre philosophie de conception, latence, études de cas de systèmes à grande échelle chez Amazon et Google, modèles de cohérence, théorie, outils, infrastructure, stockage, algorithmes de consensus, protocoles de gossip et P2P
- CAP, l’évitement du 2PC, l’eventual consistency et la réplication optimiste montrent les compromis opérationnels qui rendent difficile l’obtention simultanée d’un maximum de cohérence et de disponibilité
- Le corpus d’articles sur Google fournit des exemples d’implémentation de systèmes distribués à grande échelle comme MapReduce, Chubby, GFS, BigTable, Dremel, Spanner, Photon et Mesa, tandis que les ressources sur Amazon traitent à la fois de la transition vers une architecture orientée services et de la culture organisationnelle
- En poursuivant la lecture de Paxos, Raft, FLP, Lamport Clock, Byzantine Generals, Chord, Kademlia et Pastry, on peut structurer en un seul fil les questions de consensus, temps, réplication et routage
Mode de pensée et perspective de conception
- La partie la plus difficile des systèmes distribués est de changer sa manière de penser, et la liste commence par des articles et papiers qui aident à effectuer cette transition
- « Thought Provokers » aborde l’idée que de gros serveurs, des bases de données et des transactions ne suffisent pas à résoudre tous les problèmes
- Harvest, Yield and Scalable Tolerant Systems: traite de l’application concrète de CAP
- On Designing and Deploying Internet Scale Services: ressource de James Hamilton sur la conception et le déploiement de services à l’échelle d’Internet
- The Perils of Good Abstractions: traite de la difficulté à créer des API et interfaces parfaites
- Chaotic Perspectives: met l’accent sur l’imprévisibilité, le désordre et le parallélisme des systèmes à grande échelle
- Sont également inclus Pat Helland avec Data on the Outside versus Data on the Inside, Memories, Guesses and Apologies et Building on Quicksand
- À lire aussi : Jim Waldo avec Why Distributed Computing? ainsi que A Note on Distributed Computing de Waldo, Wollrath et al.
Latence et services à l’échelle d’Internet
- « Latency » traite de l’impact architectural du fait que la latence existe toujours
- Latency Exists, Cope!: traite des façons de gérer la latence et de son impact sur l’architecture
- Latency - the new web performance bottleneck: traite de la latence comme goulot d’étranglement des performances web
- The Tail At Scale: traite de la latence dans les systèmes à grande échelle, en particulier de la tail latency
- Les ressources sur Amazon examinent non seulement les choix techniques, mais aussi la culture et l’organisation qui se sont formées au cours de la transition vers une architecture orientée services
- A Conversation with Werner Vogels: traite de la transition d’Amazon vers une architecture orientée services
- Discipline and Focus: approfondit également la transition d’Amazon vers une architecture orientée services
- Vogels on Scalability et SOA creates order out of chaos @ Amazon sont aussi inclus
Articles sur les systèmes Google et modèles de cohérence
- Le corpus Google réunit en un seul endroit des papiers sur des systèmes à grande échelle allant de MapReduce à Mesa, relevant presque de la « rocket science » des systèmes distribués
- MapReduce
- Chubby Lock Manager
- Google File System
- BigTable
- Dremel: analyse interactive de jeux de données à l’échelle du web
- Megastore: conception d’une implémentation Paxos à faible latence entre datacenters
- Spanner: base de données Google scalable, multiversion, distribuée globalement et répliquée de manière synchrone
- Photon: jointures tolérantes aux pannes et scalables sur des flux de données continus
- Mesa: data warehouse scalable, géorépliqué et quasi temps réel qui stocke les principales données de mesure de l’activité de publicité Internet de Google
- « Consistency Models » rassemble des ressources visant à trouver le bon compromis entre cohérence et disponibilité selon le contexte du système
- CAP Conjecture: explique qu’il est impossible de satisfaire simultanément Consistency, Availability et Partition Tolerance
- CAP Twelve Years Later: Eric Brewer y développe l’explication initiale du compromis
- Sont inclus Werner Vogels avec Consistency and Availability et Eventual Consistency
- Avoiding Two-Phase Commit et 2PC or not 2PC, Wherefore Art Thou XA? traitent de l’évitement du two-phase commit et de ses limites
- Starbucks doesn't do two phase commit: traite des mécanismes asynchrones
- Optimistic Replication: traite d’une approche de cohérence relâchée pour la réplication des données
Théorie, langages, infrastructure, stockage
- « Theory » regroupe les ressources nécessaires pour comprendre les questions d’économie, d’hypothèses de panne, de temps et de limites du consensus qui reviennent constamment dans la conception de systèmes distribués
- Distributed Computing Economics: Jim Gray
- Rules of Thumb in Data Engineering: Jim Gray et Prashant Shenoy
- Fallacies of Distributed Computing: Peter Deutsch
- Impossibility of distributed consensus with one faulty process: papier également connu sous le nom de FLP ; l’accès peut nécessiter un compte ou un paiement, et un lien vers une version gratuite est aussi fourni
- Unreliable Failure Detectors for Reliable Distributed Systems: traite de la manière de contourner la difficulté posée par FLP
- Lamport Clocks: le problème d’établir une vision globale du temps lorsque l’horloge de chaque ordinateur est indépendante
- The Byzantine Generals Problem
- Les ressources sur les langages et outils montrent que choisir une technologie particulière ne fait pas disparaître à lui seul les problèmes de fiabilité
- Programming Distributed Erlang Applications: Pitfalls and Recipes: choisir Erlang et OTP ne suffit pas à simplifier la construction d’applications distribuées fiables
- Les ressources d’infrastructure montrent que la gestion des horloges est essentielle même pour des tâches de base comme le débogage
- Les ressources sur le stockage mènent vers le caching distribué et la conception de stockages comme Dynamo
Consensus, gossip, P2P
- Le corpus Paxos part du principe que Paxos lui-même est difficile à comprendre, et recommande de lire d’abord Paxos Made Simple, puis de le relire après les autres papiers
- The Part-Time Parliament: Leslie Lamport
- Paxos Made Simple: Leslie Lamport
- Paxos Made Live - An Engineering Perspective: Chandra et al.
- Revisiting the Paxos Algorithm: Lynch et al.
- How to build a highly available system with consensus: Butler Lampson
- Reconfiguring a State Machine: changement de membership de cluster
- Implementing Fault-Tolerant Services Using the State Machine Approach: tutoriel de Fred Schneider
- D’autres papiers sur le consensus couvrent à la fois les environnements WAN et des alternatives à Paxos
- Mencius: algorithme de consensus pour les réseaux étendus
- In Search of an Understandable Consensus Algorithm: version étendue du papier Raft, alternative à Paxos
- Les ressources sur les protocoles de gossip rassemblent des protocoles de communication, de monitoring et de membership au comportement épidémique
- How robust are gossip-based communication protocols?
- Astrolabe: technique robuste et scalable pour le monitoring, l’administration et le data mining dans les systèmes distribués
- SWIM: protocole de membership de groupes de processus, scalable et faiblement cohérent, de style infection
- Les ressources P2P permettent de parcourir les sujets de lookup distribué, routage, stockage et multicast au niveau applicatif
- Chord: protocole de lookup P2P scalable pour les applications Internet
- Kademlia: système d’information P2P fondé sur la métrique XOR
- Pastry: localisation d’objets et routage distribués et scalables pour les grands systèmes P2P
- PAST: utilitaire de stockage P2P persistant à grande échelle au-dessus de Pastry
- SCRIBE: infrastructure multicast distribuée à grande échelle, au niveau applicatif, pour la messagerie sur réseau étendu au-dessus de Pastry
1 commentaires
Commentaires sur Hacker News
Cette liste semble un peu datée ; je recommande la liste de lectures sur le consensus distribué de Heidi Howard
https://github.com/heidihoward/distributed-consensus-reading...
J’ai trouvé étrange de voir le MapReduce de Google présenté comme la « science des fusées » du domaine
Après vérification, cette liste date de 2014 [1] ; la situation a beaucoup changé depuis, donc il faut la prendre avec prudence
[1] https://news.ycombinator.com/from?site=dancres.github.io
Il existe une méta-liste de listes de lectures sur les systèmes distribués que j’ai créée il y a environ 10 ans
J’y ai aussi ajouté cette liste avec quelque 10 ans de retard, et Dieu seul sait combien des éléments que j’avais rassemblés sont encore accessibles aujourd’hui
https://gist.github.com/macintux/6227368
L’article https://ferd.ca/a-distributed-systems-reading-list.html, qui mentionne la liste originale, vaut aussi le détour
Elle peut être utile à ceux qui repoussent les limites ou cherchent de nouvelles approches, mais pour les autres, c’est un peu comme demander comment résoudre une équation du second degré et recevoir 100 articles de théorie des catégories
La liste de Fred Herbert est plus récente que l’originale, mais il dit lui-même qu’elle n’est pas complète. Il cite “Designing Data-Intensive Applications” comme incontournable, tout en donnant l’impression qu’il faut d’abord lire beaucoup d’articles pour vraiment le comprendre
Quand ce genre de liste est présenté comme un prérequis à la compréhension, cela peut donner l’impression d’un seuil d’entrée artificiellement relevé
Grâce à des décennies de travail accumulé par d’autres, il n’est pas nécessaire de lire 100 articles sur les nanonoyaux pour devenir un utilisateur efficace de Linux. Construire un bon système d’exploitation à partir de zéro reste difficile, mais 99 % des gens n’en ont pas besoin : il suffit de bien savoir utiliser les outils existants
Il en va de même pour les systèmes distribués : si l’on ne cherche pas à repousser la frontière de la recherche, cela n’a pas besoin d’être aussi difficile
Pour un ingénieur logiciel qui cherche de l’expérience pratique plutôt qu’une plongée profonde dans la recherche, mieux vaut construire quelque chose avec NATS [1] ou YugaByte [2], ou suivre un tutoriel pratique comme [3]
“Designing Data-Intensive Applications” vaut aussi la peine d’être lu. C’est l’un de ces livres qui s’améliorent à chaque relecture ; on peut donc très bien le lire même sans avoir parcouru 100 articles. Si certaines parties ne sont pas claires, il suffit de poser des questions et de se faire aider, et l’on peut sans problème sauter les énormes listes de lectures
1: https://nats.io/
2: https://www.yugabyte.com/
3: https://pragprog.com/titles/tjgo/distributed-services-with-g...
Et pourtant, aucune mention des technologies CRDT ?