Qu’est-ce qu’un système distribué ?

Les systèmes distribués répartissent le travail et les données entre de nombreuses machines fonctionnant simultanément. Une tâche qui aurait pu prendre des semaines à une seule grande machine peut donc être accomplie en quelques heures, voire quelques minutes. Chaque machine ou « nœud » du système dispose de son propre processeur, de sa propre mémoire et souvent de son propre espace de stockage. Les nœuds peuvent s’échanger des messages pour coordonner le partage des données, répartir la charge de travail et combiner leurs efforts vers un objectif commun.

Dans un système distribué, les machines peuvent se trouver dans la même baie de serveurs (d’un centre de données), dans différents centres de données ou dans des environnements de cloud hybride répartis à travers le monde. Quelle que soit la configuration, les systèmes distribués sont conçus pour que les utilisateurs et les applications clientes interagissent avec eux comme s’il s’agissait d’un seul service (« une base de données », « un site web », « un service de stockage »), et non d’un ensemble de serveurs individuels.

Les systèmes distribués offrent aux entreprises une solution à un défi informatique moderne urgent. De nombreuses applications actuelles sont trop volumineuses, trop sollicitées ou trop critiques pour fonctionner correctement sur une seule machine. Ces applications traitent fréquemment des quantités massives de données et de requêtes susceptibles de submerger un serveur unique. Elles gèrent des pics de trafic qui nécessitent des capacités de répartition de charge agiles. Elles gèrent des processus essentiels où un temps d’arrêt prolongé peut être catastrophique (pour les systèmes bancaires, par exemple).

Les systèmes distribués répartissent les workloads sur de nombreux nœuds et peuvent ajouter automatiquement des nœuds supplémentaires au réseau selon les besoins. Cette évolutivité permet au système d’accueillir davantage d’utilisateurs et de données, même lorsque les flux de trafic sont imprévisibles. C’est grâce à l’évolutivité des systèmes distribués que les plateformes de streaming, par exemple, peuvent desservir des millions d’utilisateurs à travers le monde, souvent simultanément.

Les systèmes distribués peuvent également contribuer à optimiser la fiabilité et la tolérance aux pannes d’une architecture informatique. Lorsqu’un nœud tombe en panne, d’autres nœuds peuvent prendre le relais afin que le service global continue de fonctionner. Cette fonctionnalité réduit les points de défaillance uniques et aide les entreprises à maintenir des systèmes à haute disponibilité, ce qui est crucial pour les systèmes nécessitant un temps de fonctionnement proche de 100 %.

De plus, les nœuds distincts d’un système distribué coopèrent étroitement tout en disposant de leurs propres bases de données et systèmes de stockage. Cette configuration permet aux équipes informatiques de concevoir plus facilement des architectures modulaires où différentes parties du système peuvent évoluer et s’adapter de manière indépendante.

Les systèmes distribués englobent toute une gamme d’architectures différentes, mais ils partagent tous un ensemble de caractéristiques fondamentales.

Pour comprendre le fonctionnement des systèmes distribués, prenons l’exemple des jeux en ligne massivement multijoueurs (MMOG).

Les MMOG s’appuient sur des architectures distribuées où de nombreux serveurs et nœuds travaillent ensemble pour maintenir un univers de jeu persistant. Des milliers de joueurs peuvent ainsi voler, échanger, se battre et explorer simultanément.

Le monde du jeu étant immense et le nombre de joueurs très élevé, le back-end est réparti sur un cluster de machines au lieu d’être géré par un seul système. Un ensemble de serveurs gère les fonctionnalités de l’univers du jeu (positions des joueurs, dégâts, inventaire), tandis que d’autres parties de l’infrastructure s’occupent de la connexion des utilisateurs, du chat et de la persistance de l’univers. Cette répartition permet au jeu de rester réactif même lorsque de nombreux joueurs sont connectés simultanément dans la même région.

Tout au long de chaque session de jeu, le système doit synchroniser l’état du jeu entre tous les joueurs. Lorsqu’un joueur effectue une action (déplacer un vaisseau lors d’une bataille de flotte, par exemple), le client envoie cette action au serveur correspondant à cette partie de l’univers du jeu. Le serveur met alors à jour l’état partagé du jeu en temps réel et partage le résultat avec les autres joueurs qui doivent le voir.

De plus, le système de jeu distribué utilise des protocoles spécialisés pour garantir que chaque joueur voie les mêmes événements de jeu se dérouler à peu près au même moment.

Si un serveur tombe en panne pendant le jeu, les autres serveurs sont conçus pour prendre le relais et continuer à fonctionner normalement afin que les joueurs ne subissent aucune interruption.

Les systèmes distribués sont l’opposé fonctionnel des systèmes centralisés. Alors que les systèmes distribués exploitent un ensemble de dispositifs pour assurer le fonctionnement, les systèmes centralisés s’appuient sur un serveur principal.

Dans un système centralisé, un nœud central coordonne la plupart ou la totalité des opérations. Les clients envoient généralement des requêtes à ce nœud, et celui-ci décide comment les traiter. Cette dynamique rend le système plus facile à comprendre, car l’autorité est concentrée en un seul endroit.

Cependant, un nœud unique signifie qu’il s’agit d’un point de défaillance unique. Dans un système centralisé, l’ensemble du système devient indisponible si le serveur central tombe en panne. La centralisation peut donc poser des problèmes importants dans les situations où la haute disponibilité est essentielle.

Les systèmes centralisés évoluent souvent verticalement. Si une équipe informatique souhaite améliorer le serveur principal, elle le fait en lui ajoutant des processeurs, de la mémoire ou de l’espace de stockage. Malheureusement, l’évolutivité verticale n’est pas une pratique viable à long terme. Au fil du temps, elle nécessite trop de matériel et devient trop coûteuse.

Ainsi, les systèmes centralisés sont mieux adaptés aux situations où la simplicité architecturale et la supervision centralisée priment sur une résilience ultra-élevée. La centralisation est couramment utilisée pour les petits réseaux informatiques, les systèmes d’entreprise internes, les serveurs de fichiers et les applications client-serveur où une seule autorité a besoin d’un contrôle strict.

Dans un système distribué, aucune machine n’a le contrôle total. De multiples nœuds coopèrent, et chaque nœud peut gérer une partie du workload ou stocker une partie des données. La structure est intrinsèquement plus flexible, mais elle exige une coordination entre les nœuds.

Les systèmes distribués sont plus tolérants aux pannes car les autres nœuds peuvent continuer à fonctionner si l’un d’entre eux tombe en panne. Un système distribué peut tout de même tomber en panne, mais il a tendance à se dégrader plus progressivement qu’un système centralisé.

Les systèmes distribués s’appuient sur la mise à l’échelle horizontale, où le système ajoute davantage de machines pour répondre à la demande croissante en ressources.

Par conséquent, les environnements distribués sont souvent préférés dans les situations où un grand nombre d’utilisateurs, des jeux de données volumineux ou une répartition géographique rendent l’utilisation d’une machine centrale peu pratique. Les systèmes distribués sont courants pour les services web, les plateformes cloud, les réseaux blockchain et les services à grande échelle qui demandent une haute disponibilité et une grande évolutivité.

Les systèmes distribués peuvent être regroupés en quelques types courants, en fonction de la manière dont les machines sont organisées et de la façon dont elles communiquent.

Dans un système client-serveur, un serveur central (ou un petit groupe de serveurs) fournit des services, tandis que les autres machines (les « clients ») dépendent du travail du serveur central.

Le serveur central, souvent la machine la plus puissante en termes de matériel, est chargé de gérer les ressources partagées (fichiers, bases de données, imprimantes, comptes utilisateurs). Les clients sont généralement des machines d’utilisateurs finaux (ordinateurs portables, téléphones mobiles, navigateurs) qui se concentrent sur l’interaction avec l’utilisateur et le traitement des requêtes et des réponses.

Comme les clients et le serveur central fonctionnent sur des machines distinctes et communiquent via un réseau, les systèmes client-serveur sont considérés comme des systèmes distribués. Cependant, la communication entre les nœuds dans une architecture client-serveur est centralisée.

Chaque client dépend du serveur central pour accéder aux ressources partagées, et les clients ne communiquent pas directement entre eux au sujet de ces ressources. Au lieu de cela, la communication entre les clients et le serveur suit généralement un modèle requête-réponse.

Lorsque l’utilisateur effectue une action (comme cliquer sur un bouton), le client convertit cette action en un message de requête et l’envoie au serveur via le réseau. Le serveur reçoit la requête, la traite, puis renvoie une réponse. Le client interprète ensuite la réponse et affiche le résultat à l’utilisateur sous une forme lisible par les humains.

Ainsi, une application web peut utiliser un navigateur (client) qui envoie des requêtes HTTP à un serveur web, lequel lit ou écrit dans une base de données puis renvoie une réponse HTML ou JSON.

La communication centralisée facilite la mise à jour des systèmes client-serveur, l’application des politiques de sécurité et la gestion des données. Le revers de la médaille, cependant, est que la centralisation peut créer des goulets d’étranglement et des points de défaillance uniques.

Dans les systèmes pair à pair (P2P), tous les nœuds, appelés « pairs », ont des rôles à peu près équivalents. Chaque pair met à disposition une partie de ses propres ressources et exploite celles offertes par les autres pairs. Chaque pair peut à la fois demander des ressources et en fournir à d’autres nœuds.

Par conséquent, les termes « client » et « serveur » dans un système P2P ne sont que des rôles qu’un nœud joue temporairement, et non des identités fixes.

Dans un système P2P pur, les pairs se découvrent mutuellement et communiquent via un réseau superposé, un réseau logique construit sur des connexions Internet physiques. Le réseau superposé détermine qui communique avec qui et comment les données sont acheminées entre les pairs.

Lorsqu’un pair a besoin de quelque chose (un fragment de fichier, par exemple), il envoie des requêtes directement aux autres pairs susceptibles de le posséder. Lorsqu’un autre pair reçoit la requête, il peut y répondre et renvoyer les données demandées, agissant ainsi comme un serveur à ce moment-là. Plus tard, les rôles peuvent s’inverser, et les deux mêmes nœuds peuvent échanger leurs rôles : l’un fournissant les données et l’autre les demandant.

Comme tous les pairs peuvent à la fois donner et recevoir, les workloads de traitement des données tendent à être répartis plus uniformément sur le réseau. Et à mesure que de nouveaux pairs rejoignent le réseau, ils apportent davantage de capacité, ce qui facilite l’évolutivité du système.

Les réseaux de partage de fichiers classiques sont un bon exemple de systèmes P2P. L’ordinateur de chaque utilisateur stocke des fragments de fichiers et les charge vers d’autres nœuds tout en téléchargeant les fragments manquants.

Les systèmes P2P sont plus résistants aux points de défaillance uniques que les systèmes client-serveur. Si un pair se déconnecte, l’ensemble du système continue généralement de fonctionner car d’autres pairs détiennent des copies des données ou peuvent acheminer les données en contournant le nœud défaillant.

Les systèmes à plusieurs niveaux étendent le modèle client-serveur de base et l’organisent en plusieurs couches clairement séparées, chacune ayant sa propre fonction. Les formes les plus courantes sont les systèmes à deux niveaux, à trois niveaux et à n niveaux.

Un système à deux niveaux est une autre façon de désigner une architecture client-serveur. Le client contient la majeure partie de la logique d’application et communique directement avec la base de données du serveur pour exécuter des requêtes et des mises à jour. Le processus est simple, mais il lie étroitement l’interface utilisateur aux données. Toute modification de la structure des données peut entraîner des changements dans de nombreux autres clients.

Les architectures à trois niveaux utilisent trois couches. La couche de présentation gère l’interface utilisateur (pages web, interface utilisateur mobile et de bureau). La couche d’application, ou « logique métier », met en œuvre les règles et les workflows (validations, calculs, décisions). La couche de données stocke et récupère les données à partir de bases de données distribuées ou d’autres systèmes de stockage.

Les systèmes à n niveaux étendent le concept à trois niveaux en ajoutant des couches plus spécialisées. Par exemple, les équipes informatiques peuvent choisir de créer une interface de programmation d’application (API) ou une couche de service distincte qui expose des points de terminaison REST ou GraphQL. Elles peuvent également séparer une couche d’authentification et de chiffrement pour gérer les connexions des utilisateurs et les tokens.

Les couches supplémentaires suivent le même principe que les trois premières. Chaque couche a une responsabilité principale, et les couches communiquent via des interfaces bien définies. Cette modularité permet aux équipes de travailler sur, de mettre à niveau ou de remplacer différentes couches indépendamment, voire d’exploiter des technologies différentes pour chacune d’entre elles.

Les systèmes à plusieurs niveaux sont fréquemment employés pour opérer des sites web de commerce électronique et des applications bancaires.

Un cluster est un groupe d’ordinateurs situés à proximité les uns des autres qui fonctionnent comme s’ils formaient une seule machine plus puissante. Les nœuds d’un cluster sont étroitement liés ; ils sont donc généralement :

• au même endroit physique (dans la même pièce ou le même centre de données) ;
  
  
• reliés par des liaisons à haut débit, telles que des réseaux locaux (LAN) à large bande passante ou des interconnexions spécialisées ;
  
  
• basés sur du matériel et des systèmes d’exploitation similaires ou identiques.

Les nœuds étant similaires et bien connectés, le cluster peut diviser une tâche volumineuse en plusieurs parties plus petites afin de les traiter en parallèle sur différents nœuds, puis regrouper les résultats.

Les clusters sont gérés par des logiciels spécialisés tels que des middlewares de cluster, un planificateur ou un gestionnaire de ressources. Le logiciel décide quels nœuds exécutent quelles tâches, surveille l’état des nœuds, gère l’acheminement des données et équilibre les workloads entre les nœuds. C’est cette couche de gestion qui transforme « un ensemble d’ordinateurs sur un réseau » en un cluster. Elle permet aux utilisateurs d’envoyer une tâche au cluster dans son ensemble au lieu de se connecter manuellement à chaque machine.

Les systèmes de clusters sont pratiques dans les situations qui nécessitent un calcul haute performance, telles que l’analyse de mégadonnées, l’entraînement de modèles d’IA et les simulations scientifiques.

L’informatique en grille consiste à mettre en commun de nombreux ordinateurs indépendants, souvent dispersés dans différentes villes et différents pays, et à les faire coopérer sur une seule et même tâche de calcul de grande envergure.

Chaque machine intégrée à une grille peut appartenir à une entreprise ou à un individu différent. Elles peuvent toutes avoir des processeurs, des tailles de mémoire, des systèmes d’exploitation et des politiques locales distincts. Néanmoins, elles acceptent de partager une partie de leurs ressources inutilisées pour résoudre des problèmes communs.

Comme une grille s’étend sur plusieurs domaines administratifs, aucune organisation ne possède ni ne contrôle entièrement toutes les machines. C’est là une différence fondamentale entre les grilles et les clusters, où une seule institution possède et gère les serveurs hébergés dans un centre de données.

Dans un système de grille, chaque nœud reste autonome. Il peut rejoindre ou quitter le réseau, dispose de son propre gestionnaire de ressources local et peut avoir des règles de sécurité ou des priorités différentes. Le middleware de grille fournit une couche commune pour envoyer des tâches, découvrir les ressources disponibles, planifier le travail, transférer des données et collecter les résultats. Ce middleware permet à l’ensemble de la grille de fonctionner comme un supercalculateur virtuel pour les utilisateurs finaux.

Lorsqu’un utilisateur envoie une tâche volumineuse (telle qu’une simulation de repliement de protéines ou un calcul de risque financier), le middleware divise automatiquement la tâche en de nombreuses petites tâches. Il recherche ensuite des machines inactives ou sous-utilisées n’importe où dans la grille pour leur attribuer des parties de la tâche. Chaque machine traite sa partie, puis renvoie des résultats qui sont combinés pour former la réponse finale.

Il est important de noter que les nœuds de la grille ne sont pas exclusivement dédiés à cette grille. Il peut s’agir d’ordinateurs de bureau ou de serveurs classiques qui mettent à disposition des cycles CPU inutilisés lorsqu’ils ne sont pas occupés par leur travail local principal.

Les systèmes distribués basés sur le cloud s’appuient sur de grands centres de données exploités par des fournisseurs de cloud.

Au lieu de posséder des serveurs physiques, les entreprises louent des ressources informatiques distribuées via Internet. Ces ressources sont mises à disposition sous forme de machines virtuelles (VM), de conteneurs, de bases de données, de files d’attente et d’autres services gérés.

Les systèmes cloud sont avant tout élastiques. Les entreprises peuvent demander davantage de capacité de calcul, de stockage ou de réseau lorsque les workloads augmentent, et libérer des ressources lorsque la charge diminue. Ils permettent également aux entreprises de ne payer que pour les ressources qu’elles utilisent, au lieu d’acheter du matériel à l’avance.

Avec les systèmes cloud, les équipes informatiques peuvent mettre en œuvre des processus de mise à l’échelle horizontale dynamique. Les groupes d’auto-scaling, des groupes logiques d’instances de serveurs identiques, surveillent les fluctuations des indicateurs de workloads. Lorsqu’une charge dépasse les seuils établis, des outils d’automatisation lancent davantage d’instances du service. Lorsque la charge diminue, ils arrêtent automatiquement les instances supplémentaires pour réaliser des économies.

Les architectures de microservices sont des systèmes distribués au niveau des applications qui exploitent plusieurs composants indépendants s’exécutant sur différentes machines pour créer des applications logicielles.

Contrairement aux applications monolithiques, aucun microservice d’une architecture de microservices ne contient l’application dans son intégralité. Au contraire, chaque microservice est un petit service autonome (doté de son propre code et généralement de son propre magasin de données) qui est responsable d’une capacité spécifique et s’exécute indépendamment des autres conteneurs.

Comme ils sont indépendants, les microservices peuvent être développés, déployés et mis à l’échelle individuellement, mais les avantages du système découlent de la collaboration entre les microservices.

Lorsqu’un utilisateur envoie une requête, le client crée un message et l’envoie à un dispositif edge (un équilibreur de charge ou une passerelle API, par exemple). Le dispositif transmet la requête au microservice approprié. Le microservice destinataire lit le message, exécute sa propre logique métier, puis renvoie une réponse au dispositif edge, qui la transmet à l’utilisateur.

Les systèmes distribués sont omniprésents dans le monde réel. Bon nombre des outils et services que les gens utilisent pour leurs loisirs, leurs activités professionnelles et la gestion de leurs finances reposent sur ces systèmes.

• Évolutivité : les systèmes informatiques distribués excellent dans la mise à l’échelle horizontale, ce qui permet aux entreprises d’ajouter simplement plus de nœuds au réseau lorsque les workloads augmentent, plutôt que d’investir dans des mises à niveau coûteuses de serveurs individuels.

• Fiabilité et tolérance aux pannes : en éliminant les points de défaillance uniques, les systèmes distribués offrent une redondance intégrée qui maintient les applications opérationnelles pour les utilisateurs, même en cas de défaillance de nœuds individuels.

• Efficacité des ressources et économies : les architectures distribuées permettent aux entreprises de créer des environnements informatiques puissants en utilisant des clusters de matériel standard à moindre coût plutôt que des supercalculateurs spécialisés onéreux.

• Distribution et accessibilité mondiales : les systèmes distribués peuvent déployer des applications plus près des utilisateurs dans le monde entier, réduisant ainsi la latence en traitant les requêtes à partir de nœuds géographiquement plus proches.