Un système distribué est un système dans lequel la panne d'un ordinateur dont vous ignoriez même l'existence peut rendre votre propre ordinateur inutilisable.
Cette célèbre citation de Leslie Lamport, lauréate du prix AM Turing, résume les défis liés à la construction et à la maintenance d'un système distribué. Mais pourquoi des systèmes aussi compliqués sont-ils nécessaires ?
Avec l’avènement d’Internet et des appareils plus intelligents, la quantité de données à traiter a explosé. De simples activités quotidiennes comme commander un Uber, regarder une émission sur Netflix, une simple recherche sur Google, faire des achats en ligne ou interagir avec les réseaux sociaux, toutes les actions triviales que nous tenons pour acquises sont alimentées par des centaines de services de distribution. Tous ces services s'appuient sur certains documents fondamentaux des systèmes distribués.
Bien que cette liste ne soit certainement pas exhaustive, voici quelques-uns de mes articles préférés qui ont eu un impact considérable sur le monde des systèmes distribués.
Bien qu'il ne s'agisse pas d'un article traditionnel, Eric Brewer l'a d'abord présenté comme une conjecture dans un discours prononcé lors du Symposium ACM 2000 sur les principes de l'informatique distribuée (PODC). L'article a ensuite été formalisé et prouvé par Nancy Lynch et Seth Gilbert dans l'article Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services.
Le théorème CAP d'Eric Brewer est un concept fondamental de la théorie des systèmes distribués, affirmant qu'il est impossible pour un magasin de données distribué de fournir simultanément plus de deux garanties sur trois : cohérence, disponibilité et tolérance de partition. Tous les autres articles mentionnés ici appliquent le principe ci-dessus et font les compromis nécessaires dans leur système.
Le théorème CAP conduit toujours à de nombreuses discussions basées sur la compréhension de l'article par les lecteurs. L'ouvrage « Une critique du théorème CAP » de Martin Kleppmann fournit un meilleur cadre pour discuter des compromis.
Dans cet article fondateur de 2001, Leslie Lamport présente l'algorithme Paxos pour parvenir à un consensus dans un système distribué d'une manière simple et accessible. Les protocoles de consensus basés sur Paxos constituent l'épine dorsale de nombreuses bases de données distribuées, systèmes de stockage, plates-formes de messagerie et services de coordination utilisés par de nombreuses entreprises technologiques. Il a fortement influencé d'autres technologies comme Chubby de Google, Spanner de Google, Apache ZooKeeper, Apache BookKeeper, etc.
Le document Google File System (GFS) présente un système de fichiers distribué évolutif pour les grandes applications distribuées gourmandes en données sur du matériel standard, qui constitue la base de nombreux systèmes de fichiers distribués qui ont suivi. GFS a été une source d'inspiration majeure pour HDFS, le système de fichiers distribué utilisé par le framework Apache Hadoop et finalement Amazon S3 (bien que s3 soit fondamentalement différent).
Cet article présente le modèle de programmation MapReduce, qui démontre une approche évolutive du traitement d'ensembles de données à grande échelle à l'aide d'une infrastructure informatique distribuée. MapReduce a joué un rôle central dans la révolution du « big data », permettant aux organisations d'exploiter la puissance de l'informatique distribuée pour analyser et tirer des enseignements d'ensembles de données massifs. Vous pouvez voir comment la combinaison de GFS et MapReduce a permis à Google de traiter des pétaoctets de données pour organiser les données d'« Internet ».
L'article MapReduce (avec GFS) a inspiré le développement de tout un écosystème d'outils et de bibliothèques construits autour d'Apache Hadoop, tels qu'Apache Hive (infrastructure d'entrepôt de données construite sur Hadoop), Apache Pig (langage de flux de données de haut niveau pour Hadoop), Apache Spark (moteur de traitement de données en mémoire), Apache HBase (base de données NoSQL distribuée) et bien d'autres.
Le document Bigtable représente un système de stockage distribué pour gérer les données structurées chez Google. Une fois que MapReduce et GFS ont permis à Google de traiter les données à grande échelle et de manière rentable, l'étape suivante consistait à permettre l'accès aux données de manière fiable et hautement disponible. BigTable a pu fournir une solution flexible et hautes performances pour des applications telles que l'indexation Web, Google Earth et Google Finance.
Tout comme MapReduce a révolutionné l'ère du « big data », le papier BigTable a été la force motrice de l'ère « NoSQL ». De nombreux principes de conception et concepts architecturaux présentés dans l'article Bigtable ont été utilisés dans des technologies telles que "Apache HBase", "Cassandra", "MongoD", etc. Bien que certaines de ces applications puissent utiliser différents modèles de données (par exemple, MongoDB), ils partagent des principes communs tels que l'évolutivité horizontale, la tolérance aux pannes et le partitionnement automatique.
Dynamo paper présente la conception et la mise en œuvre d'un magasin clé-valeur hautement disponible développé par Amazon. Dynamo a répondu au besoin d'accès en temps réel à des données hautement dynamiques, telles que les articles de votre panier. Le document introduit le concept de « cohérence éventuelle » comme principe fondamental de la conception de systèmes distribués, permettant des garanties de cohérence assouplies pour atteindre une disponibilité et des performances élevées (salut le théorème CAP !).
D'après le document lui-même, « Par rapport à Bigtable, Dynamo cible les applications qui nécessitent uniquement un accès clé/valeur en mettant l'accent principalement sur la haute disponibilité, où les mises à jour ne sont pas rejetées, même en cas de partitions réseau ou de pannes de serveur. »
Semblable à BigTable, le document Dynamo a fortement influencé les technologies ultérieures telles que Riak, Voldemort, Cassandra et même les technologies de streaming d'événements comme Apache Kafka.
La croissance rapide de Facebook nécessitait une solution de base de données capable de gérer d'énormes quantités de données et de prendre en charge un grand nombre d'utilisateurs simultanés. Alors que BigTable et Dynamo étaient eux-mêmes très influents, Cassandra a été la première technologie à avoir une longueur d'avance sur les autres. En le publiant en tant que contribution open source sous licence Apache et en publiant le document , Facebook a joué un rôle déterminant en permettant l'accès à cette technologie à l'ensemble du secteur.
Cassandra s'est différenciée des deux précédentes en fournissant un modèle de cohérence réglable, permettant aux utilisateurs de choisir entre une cohérence forte (comme BigTable) et une cohérence éventuelle (comme Dynamo) en fonction des exigences de leur application.
Cet article présente Apache ZooKeeper et présente ses principes de conception et ses algorithmes pour fournir des services de coordination hautement fiables et évolutifs dans les systèmes distribués. Avant l'introduction de ZooKeeper, les développeurs de logiciels devaient souvent mettre en œuvre leurs propres solutions ad hoc pour la coordination et le consensus distribués dans les systèmes distribués.
ZooKeeper a proposé un service centralisé pour la coordination distribuée, offrant des primitives telles que les verrous distribués, l'élection des dirigeants et la gestion de la configuration. Cela a permis de simplifier le développement d'applications distribuées en déchargeant une logique de coordination complexe sur ZooKeeper. L'un des cas d'utilisation les plus courants de Zookeeper concerne la découverte de services.
Cet article présente Apache Kafka, un système de messagerie distribué conçu pour le traitement à haut débit et tolérant aux pannes des flux d'événements. La publication de Kafka en tant que document de recherche et sa version open source en tant que projet Apache l'ont établi comme un système de messagerie standard pour le traitement de données en temps réel hautement évolutif et tolérant aux pannes et les architectures pilotées par les événements.
Kafka a introduit un système de messagerie hautement évolutif et tolérant aux pannes, conçu pour gérer de gros volumes de flux de données en temps réel. Kafka a joué un rôle très important en permettant le développement de l'architecture Lambda, qui combine le traitement par lots et le traitement par flux pour gérer de gros volumes de données avec une faible latence et un débit élevé.
Cet article présente les ensembles de données distribués résilients (RDD), l'abstraction centrale d'Apache Spark, qui permet un traitement de données en mémoire tolérant aux pannes sur des clusters distribués. Le moteur d'exécution en mémoire de Spark offre des performances nettement plus rapides que MapReduce (qui dispose d'un modèle d'exécution basé sur disque), en particulier pour les algorithmes itératifs, l'apprentissage automatique et l'analyse interactive.
Ces articles couvrent un large éventail de sujets liés aux systèmes distribués, notamment les systèmes de stockage, les algorithmes de consensus, la tolérance aux pannes et l'évolutivité. Leur lecture fournira une base solide sur les principes et les pratiques de création et de gestion de systèmes distribués.
Si vous commencez votre parcours dans les systèmes distribués et souhaitez en savoir plus, ou si vous êtes déjà un expert et souhaitez simplement rafraîchir vos fondamentaux, il n'y a pas de meilleure façon d'apprendre que de lire certains de ces articles fondamentaux sur les systèmes distribués.