À la recherche d'E.T. ? Non, ce n'est pas le titre de la suite du célèbre film de Steven Spielberg mais la question à laquelle le projet SETI@home tente d'apporter une réponse depuis 1999. Il s'agit d'une expérience scientifique qui vise à détecter (s'ils existent) les signaux d'une vie intelligente extraterrestre. Vous voulez en savoir plus ? C'est facile, vous pouvez même mettre à contribution votre ordinateur personnel pour accélérer l'analyse des données fournies par le radiotéléscope d'Arecibo en téléchargeant un simple logiciel. Chaque portion du ciel doit être analysée plusieurs fois à la recherche de signaux électromagnétiques indiquant la présence d'une source de nature artificielle. Cette décomposition en temps et en espace se prête particulièrement bien à l'analyse distribuée, puisqu'il "suffit" d'assigner à chaque nœud une tâche correspondant à l'analyse d'une portion temporelle et spatiale des données. De fait, le projet SETI@home a permis de valider la viabilité du calcul distribué grâce à des ressources fournies par des volontaires.
Du calcul parallèle au calcul distribué
Le fait que les ressources soient fournies par des volontaires éparpillés dans le monde introduit une différence significative avec le calcul parallèle dont vous avez peut-être l'habitude : lors d'un calcul réalisé en parallèle, différents threads d'exécutions sont exécutés en même temps et partagent une mémoire commune qui leur permettent de se synchroniser entre eux.
Dans le calcul distribué, les nœuds sur lequels les calculs sont exécutés sont distants, autonomes et ne partagent pas de ressources ; la communication entre les nœuds s'effectue grâce à l'envoi de messages, au sein d'un cluster. D'un côté, ce nouveau modèle de calcul résout un certain nombre de problèmes : par exemple, le passage à l'échelle s'effectue de manière horizontale c'est à dire qu'il suffit d'ajouter des nœuds au cluster pour augmenter sa capacité de calcul. Dans le modèle parallèle, on passe à l'échelle de manière verticale, en augmentant la puissance des processeurs. Mais avec le ralentissement de la loi de Moore, ce dernier modèle est remis en question.
Par ailleurs, le modèle distribué permet une plus grande tolérance aux pannes : lorsqu'un nœud du cluster subit une panne, il suffit d'affecter la tâche qu'il était en train de traiter à un autre nœud, alors que dans le modèle parallèle la machine sur laquelle le calcul est exécuté constitue un point unique de défaillance. Cependant, cette stratégie de tolérance aux pannes nécessite de pouvoir recréer l'état du nœud en échec. Il s'agit d'une question d'autant plus complexes que nous parlons ici de données dont le volume est important... Après tout, il s'agit de Big Data !
MapReduce !
Ces questions se posent pour chaque nouvelle application que l'on doit distribuer sur plusieurs machines. Et comme les développeurs sont des gens paresseux (comprenez : ils n'aiment pas faire la même chose plusieurs fois) ils ont inventé un cadre générique qui permet de distribuer de manière standard un spectre d'applications restreint, mais suffisamment large pour couvrir une grande majorité des cas d'usage. J'ai nommé : MapReduce ! Nous allons voir ensemble quelles solutions apporte MapReduce aux problèmes de distribution des calculs, des données et de tolérance aux pannes. Nous allons également voir comment représenter les étapes d'un calcul distribué sous la forme d'un graphe acyclique orienté dont chacun des nœuds représente un état qui peut être reconstitué à partir des nœuds qui lui sont liés.
