États des agents composants

Au même titre qu’un agent composite, chaque agent composant possède différents états qui traduisent sa situation courante et déterminent son comportement. Par souci de clarté, n’est donnée dans cette section qu’une brève description de chaque état pour chaque agent composant.

Cependant, les automates de l’annexeAprésentent en détail les conditions de changement d’état

et les réponses données à chaque message susceptible d’être reçu dans un état donné.

Manager

Comme précisé dans la section précédente, les états du manager reflètent précisément les états de l’agent : actif (active), en pause (pause) ou inactif (idle).

Lorsqu’il est actif, le manager donne des tâches à consommer au worker et à déléguer au broker . La priorité est toujours donnée au worker . Le manager passe en état de pause lorsqu’il n’a plus de tâche à déléguer. Dans ce cas, il continue à fournir des tâches à consommer au worker . Enfin le manager est inactif lorsque son lot de tâches est vide.

Quelque soit son état, le manager (a) met continuellement la base de croyances à jour grâce aux messages informPeerWorkload que lui envoie le broker et (b) ajoute systématiquement une tâche obtenue par le broker suite à une enchère (request). Dans le premier cas, cela permet au manager en pause d’éventuellement redevenir actif car une tâche devient délégable avec les nouvelles croyances. Dans le second cas, cela permet, d’une part, au manager d’avoir une nouvelle tâche à fournir au worker ou à considérer pour une délégation socialement rationnelle, et, d’autre part, de changer d’état en fonction du profil de la tâche (actif si délégable, en pause sinon).

Broker

Le broker possède deux rôles mutuellement exclusifs : initiateur ou enchérisseur. Sans directive de son manager , le broker est en attente (broker ). Lorsqu’il est en attente, le premier message que le broker reçoit détermine son prochain état.

• S’il reçoit un cfp d’abord, le broker devient enchérisseur (bidder). Dans ce cas il refuse toute demande du manager (abort) et reste enchérisseur tant qu’il reçoit des cfp pour lesquels il est en mesure de faire des propositions.

7.5. Conclusion 115

• S’il reçoit une demande du manager pour soumettre une tâche (submit), le broker devient

inititateur (initiator ). Dans cet état, l’agent mène l’enchère (cf. chapitre5) et stocke les cfp

qu’il reçoit. Quand son enchère est terminée, il évalue les cfp stockés, fait une proposition pour ceux qui représentent une délégation socialement rationnelle et décline les autres. Si le broker génère une proposition, il passe directement dans l’état enchérisseur. Sinon, il est de nouveau en attente et en informe le manager (notBusy).

Tant qu’un broker reçoit des cfp et qu’il est en mesure de générer des propositions, alors il existe au moins un agent plus chargé dans le système. Dans ce cas, le broker reste enchérisseur et participe à décharger au maximum les agents plus chargés que lui.

Les automates de l’annexeAcomportent d’autres états qui correspondent aux phases du broker

en tant qu’enchérisseur ou initiateur. Par exemple, l’état contracteur (contractor ) correspond à la phase dans laquelle un initiateur attend la confirmation de l’enchérisseur choisi pour bénéficier de la tâche qu’il délègue.

Worker

Le comportement du worker est le plus simple : il est occupé (busy) tant qu’il consomme une tâche ; il est libre (free) sinon. Dès que le worker est libre, il informe le manager (done) qui lui fournit au plus vite une nouvelle tâche à consommer.

7.5

Conclusion

La structure composite d’agent présentée dans ce chapitre est motivée par le fait qu’un même agent possède plusieurs responsabilités : la gestion de son lot de tâches, l’initiation et la partici- pation aux enchères, et l’exécution des tâches. La gestion simultanée de ces actions par un agent unique aurait été d’une complexité élevée. Le fait d’attribuer chacune des trois responsabilités d’un agent à ses trois agents composants permet de clairement isoler, identifier et spécifier les rôles et les comportements de l’agent en fonction de son lot de tâches, de sa charge de travail et de ses croyances. Ainsi, un agent est composé d’un manager qui gère le lot de tâches, d’un

broker qui s’implique dans les enchères comme initiateur ou enchérisseur et d’un worker qui

exécute les tâches. Chacun des trois agents composants possède sa propre file de messages et l’agent composite redirige les messages extérieurs liées aux enchères directement à son broker . Les ingrédients qui constituent un agent sont : son adresse, sa liste d’accointances, son état courant, son comportement et sa file de messages. En particulier, le comportement d’un agent détermine quelle est sa prochaine action en fonction de son état courant et du premier message de sa file. Chaque agent composant possède ses propres états qui indiquent quelle action réaliser à la réception d’un message. Par exemple, une fois que le broker est dans l’état initiateur, il ne répond pas aux cfp qu’il reçoit mais les stocke pour les considérer une fois que son enchère est terminée. Autre exemple, si le manager est en pause, ce dernier cesse de demander au broker d’initier des enchères car aucune de ses tâches n’est délégable selon ses croyances.

La difficulté dans la conception des comportements réside dans le fait que les agents ne partagent pas un état global. Ils n’ont qu’une connaissance partielle de l’état du système et de l’allocation. L’état d’un agent composite et de ses agents composants dépend de la représentation qu’ils

116 Chapitre 7. Architecture composite d’agent

ont de l’allocation courante et traduit les actions que l’agent peut réaliser selon sa charge de travail et ses croyances. J’ai spécifié l’ensemble des comportements de chaque agent (composite

ou composant) à l’aide d’automates finis déterministes. Comme le montre la section 7.2.2, cette

spécification se transpose naturellement lors de l’implémentation des agents. Afin de quantifier

la complexité des comportements des agents composants, le tableau 7.1 donne, pour chacun

d’entre eux, le nombre de lignes de code nécessaires pour les implémenter ainsi que le nombre de transitions entrantes et sortantes pour chacun de leurs états.

Agent composant Lignes de code États Transitions entrantes Transitions sortantes

Worker 511 free 3 2 busy 2 2 Manager 1352 active 32 43 pause 22 17 idle 16 10 Broker 1349 broker 16 11 initiator 6 8 awarder 4 6 contractor 5 6 bidder 8 7 enquirer 6 6

Chapitre

8

MAS4Data

Sommaire

8.1 Introduction . . . 117 8.2 Liens entre un job MapReduce et une instance MASTA . . . 118 8.2.1 Description de la phase de reduce par une instance MASTA . . . 118 8.2.2 Correction des biais de la phase de reduce . . . 119 8.3 Découpe des tâches de reduce . . . 120 8.3.1 Conditions pour la découpe de tâches . . . 120 8.3.2 Agrégation des résultats intermédiaires . . . 121 8.4 Similitudes et différences avec Hadoop . . . 122 8.5 Conclusion . . . 123 8.5.1 Synthèse . . . 123 8.5.2 Perspectives . . . 124

8.1

Introduction

Dans ce chapitre je présente MAS4Data (Multi-agent system for analyzing large data sets), le prototype distribué qui implémente le patron de conception MapReduce à l’aide d’un système

multi-agents. Je montre que la phase de reduce d’un job MapReduce (cf. chapitre 3) peut être

vue comme un problème MASTA. Comme décrit dans le chapitre 3, le déploiement du patron

de conception MapReduce et la forme des données à traiter peuvent engendrer des biais, qui entrainent une mauvaise répartition de tâches de reduce parmi les reducers. Cette mauvaise répartition de la charge de travail impacte le temps d’exécution du job et se traduit par une utilisation sous-optimale des nœuds de calcul. En définissant des agents reducers capables de réaliser des délégations socialement rationnelles, il est possible d’améliorer la répartition de la charge de travail des différents nœuds de calcul au cours de la phase de reduce.

Les deux biais de la phase de reduce sont le biais de partitionnement et le biais des clés coûteuses. Alors que le premier peut être résolu par une réallocation des tâches de reduce, le second est souvent plus complexe à corriger. Cependant, dans le cas où le job MapReduce possède des propriétés précises, il est possible pour les agents d’utiliser un processus de découpe de tâche

basé sur l’heuristique présentée dans le chapitre 6 pour découper les tâches très coûteuses et

118 Chapitre 8. MAS4Data

Ce chapitre présente comment la résolution d’un problème MASTA permet d’améliorer les per-

formances d’un job MapReduce distribué. Dans un premier temps, la section8.2décrit comment

la phase de reduce d’un job MapReduce peut être décrite par une instance MASTA. Ensuite,

la section 8.3 présente le mécanisme de découpe de tâche de reduce basé sur l’heuristique de

découpe présentée en section 6.3. Les différences entre l’implémentation de MapReduce par un

système multi-agents et l’implémentation de référence Hadoop sont abordées dans la section8.4.

Enfin la section 8.5conclut ce chapitre et en présente quelques perspectives.