Traitement distribué : répartir un travail entre plusieurs machines

Le traitement distribué répartit un travail de calcul entre plusieurs ordinateurs reliés par un réseau. Un logiciel divise le travail, affecte les tâches aux processus d'exécution, déplace les données entre les étapes qui en dépendent et suit les résultats ainsi que les échecs. Cette organisation peut augmenter la capacité ou réduire la durée d'un traitement. Mais les communications et la coordination peuvent aussi rendre son exécution plus lente.

Ce guide présente ce modèle aux développeurs, aux équipes chargées des données et aux décideurs techniques. Il explique le traitement distribué des données, les traitements par lots et en continu, le partitionnement, les échanges de données, la reprise après incident et les mesures qui permettent de savoir si des machines supplémentaires sont utiles.

Qu'est-ce que le traitement distribué ?

Un système de traitement distribué exécute différentes parties d'un travail sur des machines distinctes, reliées par un réseau. Chaque machine possède ses propres ressources de calcul et sa mémoire locale. Les processus d'exécution, souvent appelés workers, échangent des messages ou utilisent du stockage et d'autres services pour se coordonner. Leur connexion au réseau ne leur donne pas une mémoire ordinaire partagée.

Le travail peut consister à transformer un jeu de données, à lancer plusieurs simulations ou à réaliser des milliers de rendus indépendants. Le traitement distribué des données désigne le sous-ensemble consacré aux données : filtrage de journaux, jointure d'enregistrements ou calcul d'agrégats, par exemple. Des calculs intensifs peuvent aussi être répartis sans nécessiter le déplacement d'un jeu de données particulièrement volumineux.

Un schéma courant consiste à partitionner les données d'entrée, à traiter les partitions, à échanger les résultats intermédiaires lorsque cela est nécessaire, puis à écrire les résultats. Certaines applications répètent ces étapes. D'autres traitent continuellement les événements entrants. Un coordinateur ou un ordonnanceur gère souvent le travail, mais une architecture maître-workers ne définit pas tous les systèmes de calcul distribué.

La distribution n'implique pas non plus une gouvernance décentralisée. Une seule organisation peut exploiter tous les workers et organiser les tâches de manière centralisée. Notre article sur les systèmes distribués et décentralisés distingue la répartition des composants de l'autorité de décision.

Traitement distribué, traitement parallèle et systèmes distribués

Le traitement parallèle consiste à exécuter plusieurs opérations simultanément. Les cœurs d'un processeur ou les GPU d'une même machine peuvent travailler en parallèle. Le traitement distribué désigne un travail réparti entre des machines reliées par un réseau. Il utilise souvent le parallélisme au sein de chaque machine et entre les machines.

• Un serveur multicœur : des threads traitent simultanément des images avec les ressources locales de la machine. Il s'agit de traitement parallèle, sans travail distribué entre plusieurs machines.
• Un groupe de serveurs : chaque worker traite une partie d'un jeu de données et échange des résultats sur le réseau. Le traitement peut être à la fois distribué et parallèle.
• Une base de données distribuée : une recherche servie par une seule partition utilise un système distribué sans nécessairement lancer un traitement sur plusieurs nœuds. Une requête analytique qui combine les résultats de plusieurs partitions répartit, elle, son traitement.

Un système distribué est un ensemble plus large de composants qui communiquent sur un réseau. Le traitement distribué décrit la manière dont le travail s'exécute entre ces composants. Un stockage répliqué, un ensemble de services web et un cluster de calcul peuvent tous être des systèmes distribués, tout en répondant à des besoins différents.

Un service géré de manière centralisée peut déjà fonctionner sur de nombreux ordinateurs. Comparer un traitement distribué à une exécution sur une seule machine est donc plus précis que de supposer que tout système « centralisé » repose sur un serveur unique.

Comment s'exécute un traitement distribué ?

Prenons l'exemple d'un rapport quotidien sur les ventes. Les données arrivent sous forme de fichiers. Les workers peuvent nettoyer ces fichiers indépendamment, mais les totaux par produit nécessitent de réunir les enregistrements d'un même produit. Ce changement de regroupement crée une dépendance entre les workers.

1. Définir les entrées et les sorties. Précisez les données sources, la transformation et les critères d'un résultat complet. Fixez la version des données d'entrée lorsqu'un résultat reproductible est nécessaire.
2. Partitionner le travail. Divisez les fichiers, les plages de clés ou les travaux indépendants en unités que les workers peuvent traiter.
3. Ordonnancer les tâches. Affectez les tâches prêtes aux ressources disponibles, en tenant compte de la mémoire, des processeurs, des dépendances et des contraintes de placement.
4. Exécuter les tâches. Chaque worker réalise le travail qui lui est affecté et signale son avancement ou un échec.
5. Échanger les résultats nécessaires. Déplacez ou regroupez les données intermédiaires lorsque l'étape suivante a besoin d'informations provenant d'autres partitions.
6. Reprendre le travail incomplet. Relancez des tâches, recalculez les résultats manquants ou restaurez un état sauvegardé, selon le modèle de reprise du moteur.
7. Valider la sortie. Rendez le résultat utilisable avec les mécanismes d'écriture et de validation pris en charge par sa destination, puis vérifiez la fin du traitement.

Chaque travail n'a pas besoin de toutes ces étapes. Des conversions d'images indépendantes peuvent écrire des résultats séparés sans agrégation globale. Une application de traitement en continu peut mettre à jour son état et ses sorties indéfiniment, sans produire un résultat final unique.

Il faut distinguer workers, tâches et partitions. Un worker est un processus ou une ressource d'exécution ; une tâche est une unité d'exécution ; une partition est une subdivision des données ou du travail. Un worker peut exécuter de nombreuses tâches au fil du temps. Modifier leur nombre ne repartitionne pas automatiquement un traitement en cours.

Traitement par lots et traitement en continu

Le traitement par lots utilise des données délimitées

Un traitement par lots porte sur un ensemble défini de données et se termine. Il peut produire une analyse quotidienne, transformer des données dans un pipeline ETL, analyser des journaux historiques ou générer un rapport. Sa réussite peut être définie par un résultat complet et vérifié, livré avant une échéance.

Hadoop MapReduce en fournit un exemple classique. Les tâches map traitent des portions d'entrée et produisent des paires clé-valeur intermédiaires. Le logiciel regroupe et trie ces résultats pour les tâches reduce, tout en organisant, surveillant et relançant les tâches qui échouent. Ce modèle de traitement ne décrit pas l'architecture de toutes les applications distribuées.

Le traitement en continu suit l'arrivée des données

Un moteur de traitement en continu prend en charge les enregistrements à mesure qu'ils deviennent disponibles, parfois sans fin définie. Cette approche convient notamment aux flux d'événements, à la télémétrie, aux métriques opérationnelles et au suivi des transactions. Les opérateurs avec état conservent des informations d'un événement à l'autre, comme un compteur ou l'activité récente associée à une clé.

Le traitement en continu ne garantit pas un délai de réponse précis. Les files d'attente, les pics d'arrivée, les limites des destinations, les points de contrôle et les règles applicables aux données tardives influencent la latence. Une équipe a besoin d'un objectif de fraîcheur mesurable, au-delà de l'étiquette « temps réel ».

Le temps d'événement correspond au moment où un fait s'est produit ; le temps de traitement correspond au moment où le système le traite. Un événement peut arriver en retard ou dans le désordre. Le modèle temporel de Flink explique comment les fenêtres et les watermarks permettent les calculs fondés sur le temps d'événement. L'application doit néanmoins définir le traitement des données qui arrivent après la fenêtre attendue.

Les traitements par lots et en continu peuvent partager leur infrastructure et leurs logiciels. La distinction décrit les entrées et les besoins d'exécution ; elle n'impose pas une flotte de machines différente pour chacun.

Le partitionnement et l'ordonnancement déterminent le parallélisme utile

Le partitionnement crée des unités de travail qui peuvent progresser séparément. Un traitement peut diviser ses entrées par fichier, utiliser le hachage d'un identifiant client, affecter des plages de clés ou répartir des simulations indépendantes. Choisissez la stratégie en fonction des opérations nécessaires à l'application.

Des volumes identiques en octets ne garantissent pas une charge identique. Une partition peut contenir des enregistrements plus coûteux à traiter, une jointure beaucoup plus volumineuse ou une clé très fréquente. Ce déséquilibre, souvent appelé data skew, laisse certains workers inactifs pendant que les autres terminent les tâches les plus lentes.

Trop peu de partitions peuvent laisser des ressources inutilisées. Trop de petites tâches peuvent consacrer une part excessive du temps à l'ordonnancement, à l'initialisation et au suivi. Mesurez la durée des tâches et l'écart entre les tâches habituelles et les plus lentes avant de modifier le nombre de partitions.

L'ordonnanceur affecte les tâches prêtes aux ressources. Il peut tenir compte des processeurs, de la mémoire, des accélérateurs, de l'emplacement des données et des autres travaux. Les dépendances comptent aussi : ajouter des workers ne permet pas d'exécuter une étape dont les entrées ne sont pas encore disponibles.

La proximité des données est un choix d'architecture

Placer le calcul près de ses données peut réduire les transferts. Les architectures qui séparent calcul et stockage peuvent, de leur côté, favoriser leur dimensionnement indépendant, le partage des jeux de données ou l'utilisation de workers temporaires. Aucune organisation n'est supérieure dans tous les cas.

Tenez compte du volume des données, des lectures répétées, du cache, de la capacité du réseau et de la reprise. Si de nombreux workers lisent le même service de stockage, augmenter le calcul peut simplement accroître la concurrence pour ce service. Notre guide des systèmes de fichiers HPC et du stockage parallèle explique pourquoi le débit cumulé, les opérations sur les métadonnées et le temps d'exécution de l'application doivent être mesurés séparément.

Pourquoi les échanges de données peuvent dominer un traitement

Certaines opérations doivent réunir des enregistrements initialement placés sur des workers différents. Un regroupement par client, une jointure ou un tri global peut nécessiter une redistribution appelée shuffle. Le guide de programmation de Spark décrit les coûts associés au réseau, à la sérialisation, à la mémoire et au disque.

Dans l'exemple des ventes, les workers peuvent calculer des totaux locaux, puis envoyer les résultats partiels de chaque produit vers une partition désignée en aval. Une agrégation locale peut réduire le trafic lorsque l'opération le permet. Pour une jointure avec un petit jeu de référence, copier ce jeu sur les workers peut être pertinent, à condition qu'il tienne dans leur mémoire disponible.

Ces choix dépendent du travail. Diffuser un jeu volumineux peut surcharger chaque worker ; mettre en cache des données qui ne seront jamais réutilisées peut gaspiller de la mémoire. Examinez le plan d'exécution et mesurez les octets réellement déplacés avant d'appliquer une optimisation.

Ajouter des workers peut accélérer les calculs locaux tout en augmentant les communications. Un test utile sépare le temps de lecture, de calcul, d'échange, d'attente et d'écriture. Sans cette distinction, une limite du réseau ou du stockage peut être prise pour un manque de puissance de calcul.

La tolérance aux pannes exige un mécanisme de reprise

Un worker peut tomber en panne alors que les autres nœuds continuent à fonctionner. Une interruption réseau peut aussi faire paraître indisponible un processus qui fonctionne encore. Le logiciel doit disposer de règles pour détecter le travail incomplet, décider de sa relance et garantir la validité des résultats acceptés.

Les mécanismes courants comprennent les nouvelles tentatives, le recalcul à partir des entrées conservées, la sauvegarde durable des résultats intermédiaires et les points de contrôle. Chacun couvre certains types d'incidents. Une nouvelle tentative ne peut pas recréer des données sources disparues. Un point de contrôle conservé uniquement sur un disque défaillant ne permet pas de reprendre après la perte de ce disque.

Le modèle de traitement avec état de Flink associe les points de contrôle à des entrées rejouables pour restaurer l'état des opérateurs en continu. Leur fréquence impose un compromis entre le travail effectué en fonctionnement normal et celui à répéter après une panne. Le comportement de reprise diffère aussi entre ses modes d'exécution par lots et en continu.

Les nouvelles tentatives et les garanties « exactement une fois » ont des limites précises

Une tâche peut écrire dans un système externe puis échouer avant que sa fin soit enregistrée. La relancer peut répéter cette écriture. Des opérations idempotentes, une déduplication ou un mécanisme compatible de transaction et de validation peuvent être nécessaires pour éviter les effets en double.

Le traitement « exactement une fois » de l'état interne ne garantit pas automatiquement l'envoi d'un seul courriel, un seul paiement ou une seule modification de base de données hors du moteur. Les garanties des connecteurs Flink distinguent le comportement des sources et des destinations. Vérifiez le parcours complet et sa configuration, plutôt que de considérer une fonctionnalité du moteur comme une promesse pour toute l'application.

La reprise consomme des ressources et retarde l'achèvement utile. Testez la perte d'un worker, les lectures interrompues, les écritures échouées et le redémarrage avec des données représentatives. Incluez le coordinateur, la source et la destination dans l'examen des dépendances. La survie de certains workers ne prouve pas que le travail pourra aboutir.

Spark, MapReduce et Flink sont des exemples, pas des obligations

Dans une application Spark en cluster, le driver coordonne le travail, un gestionnaire de cluster affecte les ressources et des processus executors exécutent les tâches et conservent les données de l'application sur les workers. Ces rôles donnent un exemple concret, sans signifier que tous les systèmes de traitement suivent cette architecture.

Hadoop MapReduce organise les calculs par lots autour de tâches map et reduce. Flink prend en charge le traitement avec état de flux bornés et non bornés, avec des choix d'exécution et de reprise adaptés au travail. Leurs possibilités se recoupent, mais leur déploiement, leurs interfaces, la gestion de l'état et leurs contraintes d'exploitation diffèrent.

Des travaux indépendants peuvent aussi utiliser une file de tâches et des workers. Une application scientifique peut s'appuyer sur une bibliothèque d'échange de messages. Un service géré peut prendre en charge une grande partie de l'infrastructure. Il faut un logiciel qui divise et coordonne le travail, sans obligation d'utiliser un moteur particulier ou une plateforme de conteneurs.

Trois types de travaux, trois modes de coordination

Analyse de données et ETL

Une équipe partitionne un grand jeu de données, nettoie les enregistrements indépendamment, les redistribue pour une jointure ou un calcul groupé, puis écrit le résultat. Les déplacements de données et les clés déséquilibrées peuvent dominer la durée totale, même lorsque les transformations sont peu coûteuses.

Traitement continu des événements

Les événements entrants sont affectés à des tâches, souvent selon une clé comme un appareil ou un compte. Les tâches mettent à jour leur état et produisent des sorties pendant que les mécanismes de reprise conservent une position de traitement définie. Le retard accumulé, les événements tardifs et les destinations lentes comptent autant que le nombre brut d'événements par seconde.

Fichiers ou simulations indépendants

Les workers prennent dans une file des fichiers, des images à rendre ou des cas de simulation distincts. Ils communiquent peu pendant l'exécution, même si les entrées partagées, le stockage des résultats et l'affectation des tâches peuvent limiter le débit. Le suivi des identifiants de tâches terminées permet de distinguer le travail achevé de celui qui peut être relancé sans risque.

Quand répartir le traitement et quand garder une seule machine

La distribution est utile lorsque du travail divisible dépasse la capacité pratique d'une machine, lorsque des travaux indépendants manquent leur échéance ou lorsqu'un flux croissant exige davantage de débit soutenu. Certains pipelines d'IA entrent dans ces catégories, mais l'IA n'est qu'une application de ce modèle.

Commencez par mesurer une exécution sur une seule machine lorsque les données tiennent facilement en mémoire ou sur son stockage, lorsque l'algorithme est surtout séquentiel ou lorsque les tâches doivent accéder fréquemment à une mémoire partagée avec une faible latence. Le matériel existant peut déjà répondre au besoin sans coordination réseau ni exploitation supplémentaire.

Ajouter des machines ajoute aussi du déploiement, du contrôle d'accès, de la supervision, de la gestion des dépendances et des incidents. Plusieurs serveurs modestes ne sont pas automatiquement moins coûteux qu'une machine plus puissante si l'on inclut le stockage, le réseau, les périodes d'inactivité et le travail d'ingénierie.

Traitement distribué, cloud et calcul en grille

Le traitement distribué est un modèle d'exécution. Le cloud décrit la fourniture et l'exploitation de ressources et de services. Un travail distribué peut s'exécuter sur un cluster interne, des instances cloud ou un déploiement hybride. Louer plusieurs instances ne répartit pas automatiquement le travail d'une application.

Le calcul en grille met généralement en commun les ressources de systèmes administrés séparément pour des travaux adaptés. Il représente une organisation possible au sein du calcul distribué, sans décrire tous les clusters de traitement.

La même distinction s'applique à l'évaluation de Compute with Hivenet : déterminez ce que l'application ou le moteur de traitement doit déployer et coordonner. Une infrastructure distribuée ne signifie pas que le fournisseur divise automatiquement les travaux de ses clients.

Comment mesurer les performances du traitement distribué

Mesurez le travail achevé et la validité des résultats, puis comparez les ressources utilisées. Les indicateurs utiles comprennent :

• Le délai jusqu'au résultat : le temps total écoulé, y compris le démarrage, les lectures, les nouvelles tentatives et la fin des écritures.
• Le débit et la fraîcheur : les enregistrements ou travaux terminés par intervalle, ainsi que le retard et la latence des événements lorsque c'est pertinent.
• L'efficacité du passage à l'échelle : le gain obtenu avec des workers supplémentaires pour un travail fixe, sur des machines et avec des paramètres équivalents.
• Les déplacements de données : les octets échangés, le temps de shuffle, le trafic vers le stockage et les écritures temporaires sur disque lorsque la mémoire manque.
• L'utilisation des ressources et les déséquilibres : le temps de calcul comparé au temps d'attente et les écarts entre tâches ou partitions.
• Le coût par travail terminé : le calcul, le stockage, le réseau et les services gérés, y compris les tentatives échouées et la capacité inutilisée.

Prenons un calcul illustratif : une machine termine un travail fixe en 120 minutes, contre 40 minutes pour quatre machines équivalentes. L'accélération est de 3 et l'efficacité relative aux quatre workers est de 75 %. Le temps cumulé des workers passe de 120 à 160 minutes-machine, avant les coûts du coordinateur et les autres dépenses. Terminer plus vite peut donc consommer davantage de calcul au total.

Gardez des entrées, des exigences de sortie, des versions et des paramètres de protection comparables. Répétez les essais, distinguez les résultats avec cache chaud des lectures à froid et testez une panne réaliste. Pour un flux, incluez des pics et une destination lente au lieu de mesurer uniquement une moyenne stable.

Choisissez la configuration la plus simple qui respecte les exigences de délai, de débit, de validité et de reprise. Ajoutez des workers lorsque les mesures montrent qu'ils suppriment une limite pertinente.

Questions fréquentes

Le traitement distribué des données couvre-t-il tout le traitement distribué ?

Il en constitue un sous-ensemble majeur consacré aux jeux de données. Le traitement distribué comprend aussi des simulations indépendantes, du rendu et d'autres calculs pour lesquels le volume des données n'est pas la principale raison d'utiliser plusieurs machines.

Davantage de puissance accélère-t-elle toujours un traitement ?

Non. Les dépendances séquentielles, les échanges de données, les limites du stockage, les partitions déséquilibrées et les coûts de démarrage peuvent empêcher des workers supplémentaires de réduire la durée totale.

Faut-il utiliser Spark, Hadoop ou Flink ?

Non. Ce sont des exemples utiles. Une file de tâches, un système de workers sur mesure, un environnement de calcul scientifique ou un service géré peut mieux convenir. Examinez les dépendances et les besoins de reprise avant de choisir le logiciel.

Un système distribué continue-t-il à fonctionner si un nœud tombe en panne ?

Cela dépend du nœud concerné et du mécanisme de reprise. Certaines tâches peuvent continuer pendant que d'autres sont relancées ou attendent une dépendance commune. Vérifiez que le résultat est complet et correct, au lieu de compter les processus encore actifs.

Utiliser un fournisseur cloud distribue-t-il mon application ?

Non. L'application ou un service géré choisi doit mettre en œuvre la division et la coordination du travail. La capacité de l'infrastructure ne transforme pas, à elle seule, un programme conçu pour une machine en traitement distribué.