Avantages des systèmes distribués : quand la distribution est utile

Les principaux avantages des systèmes distribués sont une capacité accrue, le traitement parallèle, la disponibilité, l'isolation des pannes et la possibilité de rapprocher les services des utilisateurs ou des données. Ces bénéfices dépendent de la répartition du travail, de la coordination de l'état et de la gestion des défaillances. Ajouter des ordinateurs peut aussi augmenter les coûts et ralentir une application.

Pour les ingénieurs et les responsables techniques, la question utile est celle de la contrainte à résoudre. Ce guide explique les mécanismes qui rendent l'informatique distribuée intéressante, les charges de travail qui peuvent en bénéficier et les coûts à mesurer avant d'adopter une architecture plus complexe.

Quels sont les avantages des systèmes distribués ?

• Évolutivité horizontale : répartir la demande entre des machines supplémentaires lorsqu'une seule machine atteint ses limites utiles.
• Capacité de traitement accrue : exécuter simultanément des travaux indépendants ou décomposer un calcul adapté en tâches parallèles.
• Disponibilité : maintenir le service face à certaines pannes grâce à la redondance et à des procédures de reprise testées.
• Isolation des pannes : contenir certains incidents dans un service, un groupe de clients ou une partition de données.
• Proximité géographique : placer le traitement et les données là où ils sont nécessaires.
• Dimensionnement indépendant : attribuer à chaque composant les ressources dont sa charge de travail a besoin.
• Partage des ressources et croissance progressive : mutualiser les capacités adaptées et les étendre par étapes.
• Autonomie des organisations : permettre aux équipes ou aux institutions de coopérer tout en restant responsables de leurs systèmes.

Chaque avantage nécessite un mécanisme opérationnel. La réplication peut contribuer à la disponibilité, par exemple, mais des répliques qui dépendent du même réseau défaillant ou des mêmes identifiants peuvent devenir inutilisables ensemble.

Systèmes distribués et calcul distribué

Un système distribué comprend des composants installés sur des ordinateurs distincts qui communiquent par un réseau. Le calcul distribué met souvent l'accent sur le partage d'un travail de calcul entre plusieurs machines. Les bases de données distribuées, les services de stockage, les applications client-serveur et les grappes de calcul illustrent différentes formes de distribution.

Le cloud est un moyen d'obtenir et d'exploiter ces ressources ; la distribution existe aussi dans les centres de données privés et les grappes de recherche.

La distribution diffère également de la décentralisation. Un opérateur unique peut contrôler un service réparti entre de nombreux serveurs. Notre explication des systèmes distribués et décentralisés distingue l'emplacement des composants de la répartition de l'autorité.

Dans ce guide, une « architecture sur une seule machine » signifie que la charge de travail concernée s'exécute sur un ordinateur unique. Un service géré de façon centralisée peut déjà utiliser plusieurs serveurs : le contrôle centralisé ne doit donc pas être confondu avec un ordinateur physique unique.

Évolutivité horizontale : ajouter de la capacité utile

La mise à l'échelle horizontale ajoute des machines ou des instances de service. La mise à l'échelle verticale donne davantage de ressources à une machine existante. Une architecture distribuée peut permettre les deux, mais sa capacité à s'étendre horizontalement dépend du travail que les nouveaux nœuds peuvent retirer aux autres.

Pour une API web, un répartiteur de charge peut distribuer les requêtes entre des instances sans état. Pour une base de données, le partitionnement horizontal, ou sharding, répartit les données afin que différentes machines en traitent des sous-ensembles. Ajouter des répliques de lecture, des processus de traitement ou des nœuds de stockage répond à des limites différentes ; ces ajouts ne sont pas interchangeables.

Prenons un service documentaire fictif dont les clients consultent surtout leurs propres documents. Un partitionnement par client pourrait répartir efficacement les requêtes. Si un client représente l'essentiel de l'activité, il peut toutefois saturer sa partition pendant que d'autres machines restent sous-utilisées. Une recherche couvrant tous les clients ajoute une coordination entre partitions.

Cet avantage convient aux charges qui dépassent la capacité d'une machine en calcul, mémoire, stockage ou débit, et qui se divisent de façon pertinente. Mesurez la partition la plus sollicitée et les dépendances partagées. Ajouter des instances d'API cesse d'apporter une capacité utile si chaque requête attend la même base de données saturée.

Capacité de traitement et travail parallèle

Plusieurs ordinateurs peuvent fournir une puissance de calcul, une mémoire et un stockage cumulés. Ces ressources ne se comportent pas automatiquement comme une machine plus grande : le logiciel doit répartir les tâches et déplacer les données nécessaires.

Le travail concurrent exécute plusieurs travaux distincts sur des périodes qui se chevauchent. Une file de traitement d'images peut attribuer des images différentes à plusieurs processus. Le travail parallèle décompose un calcul en tâches qui coopèrent, par exemple pour traiter différentes parties d'une simulation. Ces descriptions peuvent se recouper, mais elles révèlent des besoins de coordination différents.

Les travaux indépendants offrent souvent une possibilité assez directe. Augmenter le nombre de processus de traitement peut raccourcir une file si le stockage, l'ordonnancement et la gestion des résultats suivent. Une simulation étroitement couplée peut passer une grande partie de son temps à échanger des résultats intermédiaires ; les performances réseau deviennent alors plus déterminantes.

Le rendu, le calcul scientifique, le traitement par lots, l'indexation de recherche et certaines tâches d'IA peuvent en bénéficier. Mesurez le travail terminé par heure et le délai d'obtention des résultats, en incluant le démarrage et les transferts de données. Doubler le matériel n'est utile que si le travail supplémentaire accompli justifie son coût.

Traitement parallèle des données

Un grand jeu de données peut être divisé en partitions, traité simultanément puis regroupé. L'article de recherche sur MapReduce décrit un modèle de programmation pour cette approche. Il explique une architecture, sans promettre de performances pour une nouvelle charge de travail.

Dans un rapport quotidien fictif, plusieurs processus pourraient compter les événements de fichiers distincts, puis additionner leurs résultats. Une jointure qui regroupe les événements par client peut nécessiter une redistribution, appelée « shuffle » : les enregistrements circulent entre les machines pour réunir les données liées. Un groupe particulièrement volumineux peut retarder le résultat final.

Le guide de programmation d'Apache Spark décrit ces opérations et leurs coûts en communication, mémoire et disque. La disposition des données et leur répartition inégale comptent autant que le nombre de processus. Réduire les déplacements inutiles peut apporter davantage qu'un ajout de nœuds.

Disponibilité : une redondance qui fonctionne en cas de panne

La disponibilité désigne la possibilité d'utiliser correctement un service. Elle peut être mesurée par les requêtes réussies ou par le temps d'utilisation possible, selon l'objectif retenu. La distribution offre des moyens de préserver ce service lorsque certains composants tombent en panne.

Plusieurs instances peuvent recevoir le trafic si l'une s'arrête. La réplication des données peut fournir une autre copie lorsqu'un nœud de stockage devient indisponible. Un déploiement entre des domaines de défaillance adaptés peut réduire l'exposition à une panne locale. Les recommandations de Microsoft sur la redondance présentent ces options et l'importance des dépendances qui les soutiennent.

Une revue de conception utile examine ce qui se passe après la détection d'une panne. Le trafic peut-il atteindre une instance saine ? Dispose-t-elle de l'état nécessaire ? La capacité restante peut-elle absorber la demande ? La reprise dépend-elle du service qui vient de tomber en panne ?

Deux instances d'application apportent peu à la disponibilité si elles nécessitent toutes deux une base de données indisponible. Des répliques supplémentaires ne corrigent pas non plus un changement défectueux déployé partout à la fois. La réserve de capacité, les changements contrôlés, la restauration de l'état et les basculements testés rendent la redondance utile. Le nombre de répliques ne suffit pas à établir un objectif de disponibilité.

Isolation des pannes : limiter les perturbations

L'isolation des pannes vise à empêcher un problème de se propager. Une défaillance des rapports ne devrait pas nécessairement empêcher les clients de passer commande. Des files, des réserves de ressources et des frontières de service distinctes peuvent permettre cette séparation.

Le modèle de cloisonnement, ou bulkhead, isole les ressources pour qu'une dépendance surchargée ne consomme pas la capacité nécessaire aux autres. Dans une application fictive, limiter les connexions utilisées par les recommandations facultatives peut préserver des ressources pour la commande.

Répartir les clients entre des groupes indépendants peut aussi limiter les utilisateurs touchés par une panne locale. Cette protection disparaît si chaque groupe dépend du même service saturé ou si les appelants attendent indéfiniment une dépendance défaillante.

La distribution peut donc offrir des possibilités d'isolation tout en créant des pannes en cascade. Définissez les délais d'attente, les limites de tentatives et les modes dégradés acceptables. Vérifiez que les parties non touchées continuent à accomplir un travail utile. Déplacer deux fonctions sur des machines distinctes ne suffit pas si leur comportement en cas de panne reste étroitement lié.

Proximité géographique : réduire les bons trajets réseau

Les services peuvent fonctionner près des utilisateurs, des appareils, des sources de données ou des systèmes dont ils dépendent. Cela peut réduire certains trajets réseau et les transferts à longue distance, surtout lorsque les requêtes peuvent être traitées localement.

Les réseaux de diffusion de contenu illustrent ce mécanisme. Comme l'explique la documentation de CloudFront, un objet en cache peut être servi depuis un emplacement périphérique ; un objet absent doit être récupéré à son origine. La présence dans le cache et le parcours de la requête influencent le résultat.

Pour une application interactive, placer un serveur web près de l'utilisateur peut apporter peu si chaque action appelle encore une base de données située de l'autre côté d'un océan. Le traitement local de données de capteurs peut réduire le trafic sortant, mais les mises à jour, les envois et les dépendances distantes nécessitent toujours de la bande passante.

Mesurez la latence complète des requêtes depuis les lieux visés, y compris les requêtes lentes. La coordination entre régions peut ajouter des délais, notamment lorsqu'une écriture attend des participants éloignés. Le placement peut aussi répondre à des exigences précises de localisation des données, sans suffire à établir la conformité réglementaire.

Dimensionnement indépendant des composants

Les différentes parties d'une application ont souvent des besoins distincts. Un service multimédia peut recevoir les requêtes par une API modeste, tandis qu'une file d'encodage nécessite davantage de processus CPU ou GPU pendant les périodes chargées. Dimensionner ces processus séparément peut éviter d'augmenter toutes les couches en même temps.

Il n'est pas nécessaire de convertir toute l'application en microservices. Une application principale accompagnée de processus de traitement en arrière-plan peut suffire. Les frontières doivent correspondre à une différence concrète de charge, de responsabilité ou de besoin de déploiement.

Les recommandations de Microsoft sur les microservices décrivent le déploiement et le dimensionnement indépendants, avec les coûts supplémentaires de communication, de test et d'exploitation. Les interfaces stables comptent : si chaque changement impose une version coordonnée de tous les services, l'autonomie attendue n'est pas obtenue.

Partage des ressources et croissance progressive

Le partage peut rendre une capacité inutilisée disponible pour des travaux adaptés. Un groupe de recherche peut planifier des expériences distinctes sur une grappe, tandis que plusieurs équipes peuvent partager des ressources de calcul avec des quotas et des priorités explicites. Le calcul en grille peut coordonner des ressources relevant de plusieurs organisations.

Un partage utile exige de la compatibilité. Les jeux d'instructions CPU, la mémoire GPU, les systèmes d'exploitation, les licences, l'accès aux données et la capacité réseau limitent les emplacements où un travail peut s'exécuter. Une machine libre n'est pas nécessairement une machine adaptée.

Les ordonnanceurs et les contrôles de ressources déterminent aussi si une charge peut accaparer la capacité d'une autre. Kubernetes distingue, par exemple, les demandes et les limites de ressources. La mutualisation nécessite ce type de contrôle ; elle ne garantit pas une utilisation efficace.

La croissance progressive permet à certaines architectures d'ajouter de la capacité par étapes. Un service de stockage peut introduire des nœuds à mesure que la demande augmente, mais y déplacer les données existantes consomme aussi des ressources. Évaluez les performances pendant le rééquilibrage, le plus petit ajout économiquement pertinent et l'effort nécessaire pour revenir sur un changement de capacité.

Systèmes hétérogènes et migration progressive

Les interfaces réseau peuvent permettre à des matériels, des systèmes d'exploitation et des langages différents de coopérer. Une organisation peut ainsi intégrer une application existante à de nouvelles capacités de traitement sans tout remplacer en une fois.

Imaginons un service documentaire qui conserve son application tout en ajoutant un processus spécialisé de conversion. Un format de tâche versionné peut séparer les deux implémentations. Les tests de compatibilité, la gestion des erreurs et la maintenance restent nécessaires dans les deux environnements.

L'hétérogénéité apporte de la souplesse lorsqu'elle répond à un besoin. Une variation incontrôlée peut multiplier les combinaisons de déploiement et compliquer le diagnostic. Pour les choix d'implémentation, consultez notre guide des technologies des systèmes distribués.

Autonomie des organisations

Certains systèmes doivent coopérer sans réunir toutes les données ni tout le contrôle dans une seule organisation. Plusieurs institutions peuvent exposer des informations choisies par des interfaces convenues tout en restant responsables de leurs propres dossiers.

Notre guide des systèmes d'information distribués examine le lien entre la responsabilité des données, leur sens partagé et la coordination technique. L'autonomie peut constituer une exigence légitime même si une base centralisée serait plus simple à construire.

Elle nécessite néanmoins des accords. Les équipes doivent définir le responsable de chaque champ, le sens d'une mise à jour, l'attribution des accès et la prise en charge des incidents communs. Modifier le schéma d'une institution peut casser l'intégration d'une autre si le versionnement et la communication ne sont pas prévus.

Les inconvénients des systèmes distribués

Ces bénéfices s'accompagnent d'une dépendance au réseau et de défaillances partielles. Une requête peut expirer alors que le service destinataire l'a exécutée. Une nouvelle tentative qui ignore cette incertitude peut répéter l'opération. Une machine saine peut devenir inaccessible et différents composants peuvent observer des états différents.

Cohérence des données et coordination

La réplication ne signifie pas que chaque lecteur voit immédiatement les mêmes données. Les applications doivent choisir le comportement acceptable pour les lectures et les écritures, puis mettre en place la coordination nécessaire. L'analyse de Google sur l'état critique et le consensus explique pourquoi un accord fiable exige davantage que de simples signaux périodiques de détection des pannes.

Pour un brouillon, une mise à jour retardée peut être acceptable. Pour une modification de permission, une information périmée peut accorder un accès qui aurait dû être retiré. Évaluez la cohérence opération par opération. « Toujours fortement cohérent » ou « la cohérence éventuelle suffit » ne définit pas correctement les besoins de tous les processus.

Diagnostic et responsabilités d'exploitation

Une requête lente peut traverser plusieurs services, files et bases de données. Les journaux d'une machine ne montrent qu'une partie de son parcours. Les traces distribuées relient les opérations entre services et aident à déterminer où le temps a été passé.

Les équipes ont aussi besoin de mesures utiles, d'une réponse coordonnée aux incidents, de vérifications de compatibilité et d'exercices de reprise. Davantage de composants créent davantage de travail de déploiement et de configuration. Les services gérés peuvent transférer une partie de cet effort au fournisseur, mais les applications doivent toujours gérer les comportements de défaillance documentés.

Sécurité et coût

La distribution ajoute des identités de service, des identifiants, des API et des décisions de contrôle d'accès. L'isolation peut protéger les ressources si elle est effectivement appliquée. Les recommandations zero trust du NIST rejettent la confiance implicite fondée uniquement sur l'emplacement réseau. L'appartenance d'un service à la même grappe ne constitue pas une autorisation suffisante.

Des économies sont possibles si l'utilisation utile s'améliore ou si la croissance progressive évite de réserver une capacité inutilisée. Les coûts peuvent aussi augmenter avec la réplication, la redondance inactive, les transferts, l'observabilité, les licences et le travail d'ingénierie. Comparez le coût par travail terminé ou par requête réussie au niveau de service requis. Le matériel standard est un élément de ce calcul, sans prouver que le service coûtera moins cher.

Architecture distribuée ou sur une seule machine

Une comparaison pratique doit examiner la charge de travail :

• Capacité : une machine peut être renforcée dans ses limites ; la capacité distribuée dépend de la répartition du travail et des goulets d'étranglement partagés.
• Pannes : une seule machine concentre le risque d'exécution ; plusieurs machines ajoutent des options de reprise, des défaillances partielles et des risques de coordination.
• Communication : les appels locaux évitent de nombreux coûts réseau ; les appels distants nécessitent sérialisation, transport et gestion des échecs.
• Transactions : une base locale peut simplifier des changements liés ; des changements entre services ou partitions exigent une conception supplémentaire.
• Géographie : un lieu d'exécution unique limite les choix ; la distribution peut traiter certains travaux localement si leurs dépendances le permettent.
• Exploitation : moins de composants peuvent simplifier le déploiement, le diagnostic et la sécurité ; la distribution nécessite de la visibilité et des responsabilités entre composants.
• Croissance et coût : des machines plus grandes et des nœuds supplémentaires ont des paliers de capacité, des prix et des coûts d'exploitation différents. Comparez-les avec une demande réaliste.

Un service géré de façon centralisée peut combiner ces approches. Il peut conserver les données transactionnelles dans une base logique unique tout en répartissant les requêtes sans état ou les traitements en arrière-plan.

Quand la distribution justifie sa complexité

Partez d'une exigence que la conception actuelle ne satisfait pas. Testez ensuite le changement d'architecture le plus limité qui pourrait y répondre :

1. Nommez la contrainte. Précisez le débit, l'échéance de traitement, l'objectif de reprise, le besoin géographique ou la frontière de responsabilité.
2. Localisez le goulet d'étranglement. Mesurez le calcul, le stockage, les files et le temps réseau avant de choisir un mécanisme de dimensionnement.
3. Testez des travaux représentatifs. Incluez une demande inégale, de gros enregistrements, des dépendances réalistes et le coût du déplacement des données.
4. Testez les défaillances. Vérifiez le service utile lors de la perte d'un nœud, d'une dépendance indisponible, de messages retardés et de la reprise.
5. Comparez les coûts complets. Intégrez l'exploitation continue et la migration à l'infrastructure, puis déterminez si l'amélioration satisfait l'exigence.

Conservez une conception plus simple lorsqu'elle absorbe confortablement la demande prévue, lorsque les transactions locales dominent ou lorsque la distribution ne répond à aucun besoin précis. Un service géré peut aussi satisfaire le besoin en réduisant ce que votre équipe doit exploiter. Retenez le degré de distribution que la charge de travail peut justifier.

Questions fréquentes

Qu'est-ce qui rend le calcul distribué puissant ?

Il permet à des travaux adaptés d'utiliser les ressources cumulées de plusieurs machines. Des tâches parallèles peuvent raccourcir un calcul, tandis que des travaux indépendants peuvent augmenter le débit. Le bénéfice dépend du rapport entre travail utile, communication, synchronisation et déplacement des données.

Les systèmes distribués n'ont-ils aucun point unique de défaillance ?

Non. Une application distribuée peut encore dépendre d'une base de données, d'un ordonnanceur, d'un service d'identité ou d'un chemin réseau unique. Examinez les dépendances et les domaines de défaillance au lieu de déduire la résilience du nombre de nœuds.

Les systèmes distribués sont-ils toujours plus rapides ou moins chers ?

Non. Une petite charge peut s'exécuter plus vite et coûter moins cher sur une seule machine. La distribution justifie son coût lorsqu'elle répond plus efficacement à une exigence mesurée de capacité, de disponibilité, de localisation ou de responsabilité.

Quels sont les avantages d'un système de fichiers distribué ?

Selon sa conception, il peut regrouper de la capacité de stockage, permettre à plusieurs clients d'accéder aux mêmes fichiers et utiliser la redondance face à certaines pannes. Les performances des métadonnées, les règles de cohérence, le réseau et les procédures de reprise déterminent le résultat pratique. L'accès partagé n'implique pas un débit illimité.

Une application monolithique peut-elle utiliser une infrastructure distribuée ?

Oui. Plusieurs instances de la même application peuvent répondre aux requêtes, tandis que des processus en arrière-plan ou une base répliquée fonctionnent séparément. La structure de l'application et la distribution de l'infrastructure sont des choix de conception distincts.