L’implémentation distribuée de référence du patron de conception MapReduce est Hadoop [Ha-
doop 2019]. Pour mettre en œuvre la proposition de cette thèse, j’ai implémenté MAS4Data,
un prototype qui déploie un système multi-agents sur plusieurs nœuds de calculs et autorise la réallocation des tâches reduce pendant leur exécution. Cette réallocation offre à MAS4Data la possibilité de contrer les biais de la phase de reduce, ce qui est impossible pour Hadoop. Cepen- dant, MAS4Data présente quelques différences avec la philosophie de Hadoop. Cette section a pour but de les identifier.
Exécution des tâches de reduce
Hadoop applique le patron de conception MapReduce tel qu’il est décrit dans le chapitre 3. De
ce fait, lorsque qu’une tâche de reduce est affectée à un reducer par la fonction de partition, c’est généralement ce reducer qui exécute cette tâche et en produit le résultat.
À l’inverse, dans MAS4Data, les tâches de reduce sont constamment réaffectées suite aux né- gociations initiées par les agents. Dans l’impossibilité de prédire quel mapper produit quelle clé sans prétraiter les données, les tâches sont également assignées de manière statique par une fonction de partition prédéfinie. Cette fonction de partition détermine l’allocation initiale des tâches de reduce. Toutefois, celle-ci est continuellement remise en question par les reducers qui cherchent à améliorer son makespan grâce aux délégations socialement rationnelles.
Système de fichiers distribué
Hadoop utilise un système de fichiers distribué. Ainsi, lorsque les mappers produisent les chunks, ces derniers se trouvent dupliqués sur plusieurs nœuds du système. Malgré la réplication des
chunks, un reducer peut ne pas avoir un accès direct à l’ensemble des chunks liés à une clé. Dans
ce cas, pour qu’il puisse produire le résultat, les chunks manquants doivent être transférés.
Pour faciliter l’interprétation des résultats expérimentaux (cf. chapitre 9), MAS4Data n’utilise
pas de système de fichiers distribué. Les chunks sont donc écrits sur le système de fichiers local des mappers qui les produisent. Comme les reducers utilisent les délégations de tâche socialement rationnelles, les tâches de reduce circulent tout au long de la phase de reduce. Afin de ne pas déplacer inutilement les chunks, les chunks liés à une tâche ne sont transférés qu’au moment de son exécution par un reducer . Ainsi, après la phase de map, les mappers envoient une description des chunks aux reducers. Pour chaque chunk lié à une clé, le reducer connaît le nombre de valeurs qu’il contient ainsi que le nœud sur lequel il se trouve. Les phases de map et de reduce étant consécutives, il est possible de placer un mapper et un reducer sur le même nœud sans pénaliser les performances des deux phases. Si un reducer se trouve sur un nœud sur lequel un mapper a produit des chunks, ces chunks sont locaux pour lui. Lors de l’exécution d’une tâche, le reducer fait des requêtes sur les nœuds où se trouvent les chunks qui ne lui sont pas locaux afin de les
8.5. Conclusion 123
transférer et de pouvoir appliquer la fonction de reduce.
Tolérance aux pannes
J’appelle panne l’arrêt complet d’un nœud de calcul. D’après la classification présentée dans [Po-
tiron et al. 2009], une panne est donc une faute opérationnelle, externe, matérielle, naturelle,
non-malveillante, accidentelle et permanente. Un système tolérant aux pannes permet l’arrêt complet d’un nœud en cours d’exécution sans que cela entraîne la perte des tâches ou des ré- sultats. Autrement dit, un système tolérant aux pannes dispose d’un mécanisme qui permet de récupérer les résultats produits ou de réallouer les tâches exécutées par un nœud en panne. Hadoop est un système centralisé. Chaque nœud de calcul envoie régulièrement des messages de status (heartbeat messages) à un superviseur qui centralise la localité de chaque chunks, l’état de chaque nœud et l’état d’avancement des tâches en cours. En cas de panne d’un nœud ou d’un ralentissement important, ce superviseur est donc capable de tuer le reducer défectueux et de relancer le traitement de ses tâches sur un autre nœud.
MAS4Data est totalement décentralisé. Un unique superviseur est bien en charge d’initier le système distribué et d’y déployer les agents mais ce dernier ne centralise aucune information
sur le système. Comme décrit dans le chapitre 4, chaque agent possède sa propre perception
de ses pairs et de l’allocation de tâches courante. Ainsi, n’ayant pas à consulter une entité qui concentre toutes les informations sur l’état courant du système, les agents sont capables de réagir de manière réactive et indépendante pour corriger l’allocation de tâches courante. Leurs décisions sont donc locales. Pour l’instant, cela permet seulement aux agents d’être réactifs à une chute de performances et l’implémentation d’une tolérance aux pannes est aujourd’hui une perspective.
8.5
Conclusion
8.5.1 Synthèse
Ce chapitre décrit comment la phase de reduce d’un job MapReduce se traduit dans le cadre formel de l’amélioration d’une instance MASTA. Le déploiement d’un agent par nœud reducer autorise la réallocation dynamique des tâches pendant la phase de reduce. Ainsi, en appliquant les mécanismes et stratégies décrits dans la partie précédente de cette thèse, les agents reducers sont à la fois capables d’améliorer le makespan de la phase de reduce et capables d’adapter l’allocation de tâches aux fluctuations de performances. Au même titre qu’elle est bénéfique à la résolution d’un problème MASTA, la co-occurence des délégations socialement rationnelles et des consommations de tâches reduce permet de corriger le biais de partitionnement de la phase de reduce.
Le biais des clés coûteuses peut nécessiter la découpe des tâches de reduce. Grâce à la structure particulière d’une tâche de reduce, il est possible de créer des sous-tâches à partir des chunks de la tâche initiale. Cependant, pour que les reducers soient capables de conserver la cohérence des résultats malgré la découpe des tâches, il est nécessaire que la fonction de reduce puisse être décomposée en une fonction de reduce intermédiaire et une fonction de reduce finale. Lorsqu’une
124 Chapitre 8. MAS4Data
tâche est découpée, différents reducers traitent les sous-tâches en appliquant la fonction IR et envoient les résultats intermédiaires au reducer final. Une fois qu’il a récolté l’ensemble des résultats intermédiaires, ce dernier applique la fonction FR pour produire le résultat définitif de la tâche.
Afin de pouvoir appliquer les concepts décrits dans cette thèse sur des données réelles, j’ai im- plémenté un prototype distribué appelé MAS4Data. Contrairement à Hadoop, celui-ci est un système décentralisé qui autorise la réallocation des tâches de reduce pendant leur exécution grâce aux délégations de tâche sociallement rationnelles. Le chapitre suivant présente les expé- rimentations et les conclusions quant à l’efficacité et l’applicabilité d’un tel processus.
8.5.2 Perspectives
Une première perspective de ce chapitre est d’explorer la possibilité d’intégrer ce processus de réallocation à l’écosystème Hadoop. Ainsi, il serait possible de comparer une exécution qui utilise le processus de réallocation avec une exécution classique. En terme de modèle, cela demande uniquement d’ajouter la prise en compte d’un système de fichiers distribué, c’est-à-dire de consi- dérer qu’une ressource est répliquée sur plusieurs nœuds. Cependant, cela représente sûrement un travail conséquent d’ingénieurie pour gérer le transfert de tâches, l’accès aux chunks et les échanges entre reducers.
Une seconde perspective est de considérer l’impact que pourrait avoir l’ajout d’un reducer pen- dant la phase de reduce. Avec une exécution classique de MapReduce, un tel reducer est inutile car aucune tâche ne lui a été attribuée par la fonction de partition. À l’inverse, le processus peut facilement bénéficier de l’ajout d’un agent en cours d’exécution. En effet, grâce à la réallocation continue des tâches de reduce, ce nouveau reducer peut rapidement se voir attribuer des tâches et participer à améliorer le makespan de l’allocation courante. Ainsi, si le système distribué dispose de nœuds inactifs pendant la phase de reduce, il suffit à l’agent qui lui est associé d’annoncer sa présence à ses pairs avant de se voir participer aux enchères et attribuer des tâches. Le problème ici est plutôt de décider quand et pourquoi ajouter un agent au système.
Enfin, une troisième perspective est d’inclure la tolérance aux pannes dans le prototype. Comme
énoncé dans la section8.4, le mécanisme de réallocation dynamique des tâches de reduce permet
de corriger la baisse de performances d’un nœud de calcul mais pas sa disparition du système distribué en cours d’exécution. En distribuant l’information de quel agent dispose de quelles tâches, il est possible de redistribuer les tâches perdues lors de la panne d’un nœud de calcul.
Chapitre
9
Validations expérimentales
Sommaire
9.1 Introduction . . . 125 9.2 Description des jeux de données . . . 126 9.3 Réallocation dynamique des tâches . . . 127 9.3.1 Impact de la réallocation sur l’équité de contribution . . . 127 9.3.2 Bénéfices de la réallocation sur le temps d’exécution . . . 128 9.4 Dynamique du processus de réallocation . . . 130 9.5 Hétérogénéité des nœuds de calcul . . . 132 9.6 Découpe de tâche . . . 134 9.7 Comparaison des stratégies de sélection de tâche . . . 134 9.8 Conclusion . . . 139 9.8.1 Synthèse . . . 139 9.8.2 Perspectives . . . 140
9.1
Introduction
MAS4Data est un prototype qui permet l’exécution distribuée d’un job MapReduce grâce au
déploiement d’un système multi-agents (cf. chapitre8). Dans un tel système, des agents reducers,
dont le comportement et l’architecture sont décrits dans le chapitre 7, réallouent les tâches de
reduce pour améliorer l’équilibre des charges sur les différents nœuds de calcul et faire décroître
le temps d’exécution du job.
Dans ce chapitre, je corrobore les contributions mises en avant dans cette thèse au travers d’expérimentations réalisées avec MAS4Data sur divers jeux de données. Au travers de ces expériences, je cherche à montrer que :
• la réallocation des tâches permet une meilleure répartition des charges de travail ;
• les agents ajustent l’allocation de tâches tout au long de l’exécution afin de faire diminuer la charge de travail la plus élevée du système ;
• lors d’une exécution MapReduce, la stratégie de découpe de tâche permet de contrer le biais des clés coûteuses ;
• lors des négociations, il est préférable que les agents considèrent la localité des chunks, et donc qu’ils utilisent la stratégie de sélection de tâches localisées.
126 Chapitre 9. Validations expérimentales
Pour juger de la qualité d’une allocation de tâches, trois nouvelles métriques sont introduites : la contribution, l’équité de contribution et l’équité de temps. La contribution d’un agent représente la quantité de travail qu’il a réalisé. Elle est donc égale à la somme des coûts des tâches que l’agent a exécutées. L’équité de contribution d’une allocation se mesure en divisant la contribution la moins élevée par la contribution la plus élevée. Plus l’équité de contribution d’une allocation est proche de 1, plus la contribution des agents est similaire. Dans le cas d’agents homogènes en terme de capacités de calcul, une équité de contribution proche de 1 signifie donc que la charge de travail a correctement été répartie. De manière similaire, l’équité de temps se mesure en divisant le temps d’exécution de l’agent qui termine le premier par celui de l’agent qui termine le dernier. Une équité de temps proche de 1 signifie que les agents ont terminé leur travail presque simultanément. Dans le cas d’agents hétérogènes, on s’attend à ce que les agents les plus performants aient une contribution plus élevée. Dans ce cas, l’équité de temps est une mesure plus pertinente que l’équité de contribution. En effet, une équité de temps élevée indique que l’allocation des tâches a pris en compte les différences de capacités de calcul des agents. Ces trois métriques sont mesurées a posteriori, c’est-à-dire une fois l’exécution des tâches terminée. La majorité des figures de ce chapitre représentent donc des observations ex post.
Dans la plupart des expériences, le coût d’une tâche correspond au volume des données à traiter, c’est-à-dire au nombre de valeurs qui lui sont associées. Appelons cette fonction la fonction de
coût par valeurs. Avec cette fonction, le coût d’une tâche est le même pour tous les agents du
système (∀i, j ∈ A, ∀τ ∈ T , ci(τ ) = cj(τ )).
La section 9.2commence par présenter les jeux de données utilisés. La section9.3 montre l’im-
pact du processus de réallocation sur la répartition de la charge de travail. La section9.4met en
lumière la dynamique de ce processus. La section9.5confirme que les réallocations permettent de
s’adapter à l’hétérogénéité des agents, même quand celle-ci n’est pas traduite par la fonction de
coût utilisée. Ensuite, la section9.6illustre l’apport de la découpe de tâche. La section9.7com-
pare quelques stratégies de sélection de tâche présentées dans le chapitre 6. Enfin, la section9.8
conclut ce chapitre et offre quelques perspectives.