Les clodoaldiens de stricte obédience, y compris les schismatiques Libres clodoaldiens, sont peut-être, comme leurs précurseurs du XVIIe siècle — les Boyle, Hooke, Wallis, Wren et Newton, qui établirent la Royal Society — les premiers à défricher le champ d'une nouvelle Science des données. En tout cas, suivant la devise des pionniers : *nullius in verba*, ils affirment ne vouloir chercher la vérité des nouvelles architectures de l'informatique, des nouveaux modèles de programmation et de leurs nouveaux langages, des nouvelles divisions sociales du développement des applications Cloud Computing, non dans les professions ex cathedra de la scolastique des acteurs établis de l'industrie mais en se fondant exclusivement sur l'expérience et la pratique. Le radicalisme assumé de cette position nous donne aujourd'hui une prolifération de projets exploratoires dont les principes rompent systématiquement d'avec les doctrines prévalentes : mouvement « NoSQL » dans le domaine des bases de données, renouveau des langages de programmation fonctionnels pour les applications Web, parallélisation pour les multicoeurs, virtualisation, distribution et répartition pour les datacenters, toilettage en profondeur de l'architecture des compilateurs et des machines virtuelles, etc.
Nous évoquions encore ces sujets d'actualité avec mes amies observatrices attentives de l'industrie, Cassandra Klowd — chef de projet à la NASA de passage à Paris en pleine grève — et Claude Conputaing, aveyronnaise pur jus, en sortant de la séance en matinée du film The Social Network. Cassandra se plaignait bien sûr de la confusion générale dans les transports français et Claude racontait comment, cet été, elle avait échappé à la déchéance de la nationalité française, arrêtée qu'elle fut sur une nationale ensoleillée au volant d'une grosse cylindrée (donc suspecte) tractant son inséparable datacenter en conteneur, par une brigade de gendarmes tout aussi hortefeux que sourcilleux. Elle ne dut son salut patriotique qu'à la rassurante démonstration que son étrange caravane n'était pas pleine de ROMs mais bien de RAMs (et de mémoires Flash) — celles-ci ne sont, en effet, pas mentionnées dans la fameuse circulaire aux préfets. Le voyage estival de Claude à la recherche d'un camping adéquatement localisé pour y installer son conteneur datacenter — peu fréquenté et discret pour parer aux menaces de terrorisme, de préférence à proximité d'un barrage hydro-électrique ou d'une centrale nucléaire pour un accès facile et peu coûteux à une énergie toujours disponible, dans le méandre d'une rivière pour le refroidissement à eau, au voisinage de centres universitaires et académiques bien classés Shanghaï — l'avait menée à parcourir notre beau pays de long en large (Luzech, Cajarc, Golinhac, le confluent du Church et de la Rosser, et Couesque l'avaient particulièrement séduite). Sa position de principe, en tout cas, appelle carrément au renversement du dogme architectural actuel qui voit le cloud principalement utilisé à agréger le stack de nos applications existantes et leur système d'exploitation pour augmenter — à la demande — l'emprise de nos sites Web.
L'enfer, c'est les strates !
« Car, enfin, macarel ! L'enfer c'est les strates ! Maprédious ! », me dit-elle passablement irritée. L'économie de réduction des coûts d'hébergement amenée par le cloud computing et son déploiement de plateformes de virtualisation permet maintenant au consommateur de louer, à prix abordable, leur puissance de calcul. Mais c'est précisément la migration « tels quels » des empilements rigides de couches logicielles qui, du système d'exploitation, aux processus utilisateurs, aux machines virtuelles et runtimes de nos langages de programmation traditionnels, aux threads et, enfin, aux applications métiers juchées sur cet échafaudage, qui est cause des grandes difficultés de la transition vers la nouvelle architecture. Cette stratification, souvent solidifiée par des années de développement et d'intégration, importe avec elle tout le poids de ses complexités de configuration , d'implémentation et de déploiement, d'administration et de sécurisation dans les villes nouvelles du cloud. Le résultat est alors souvent antithétique à la fluidité et à la dynamique offerte naturellement aux données et calculs par l'essence même du cloud computing.
La résurrection de la recherche sur les systèmes d'exploitation constitue donc un premier mot d'ordre. Exokernel au MIT, Barrelfish de Microsoft Research et l'ETH de Zürich avec l'application de l'idée des Domain Specific Languages (DSL) à la programmation des systèmes d'exploitation et la vérification formelle des micronoyaux d'OS, les travaux pionniers sur L4 et EROS à John Hopkins (qui nous ramènent invariablement à Rick Rashid et Mach à CMU), ou encore KeyKOS à U. Penn, inspirent des travaux actuels comme Mirage, par exemple.
Un des principes directeurs est de considérer le hardware virtualisé du cloud comme une cible, comme une autre, des compilateurs et de traduire le plus directement possible un langage de programmation de haut niveau vers un micronoyau spécialisé tournant sur l'hyperviseur — court-circuitant au passage toutes les couches habituelles du stack applicatif. Des variantes expérimentales permettent ensuite de prendre en compte les impératifs habituels :
- Efficacité. L'usage économe du cloud exige de pouvoir instancier et détruire rapidement des machines virtuelles avec peu de latence, exercice rendu difficile par l'articulation rigide et le poids des stacks applicatifs courants.
- Sécurité. Dans cette approche directe, les applications sont des images bootables compilées d'après un code source écrit dans un langage de programmation qui soit idéalement fortement typé et sujet à des preuves formelles (cf. plus bas, la résurgence des langages fonctionnels). Le niveau de sécurité est dès lors bien plus élevé, comparé à celui des applications d'entreprises traditionnelles.
- Simplicité. Oubliée la sémantique circonvoluée des interfaces des systèmes d'exploitation, héritage de l'obligation de compatibilité avec une variété foisonnante d'applications (réseaux, systèmes de fichiers, bases de données...) élargie au fil des années !
- Spécialisation. Là où certains systèmes d'exploitation essayent de subvenir à tous les besoins : PC, mobile, routeur, serveur, consoles de jeux, l'idée est ici au contraire de spécialiser des micronoyaux pour les entrées/sorties et le calcul intensif, caractéristiques du cloud programming.
- Coûts de déploiement. Il est curieux de constater que bien souvent des approches radicalement rénovatrices dans le développement de noyaux et de systèmes d'exploitation ont parfois été victimes d'obsolescence rapide, dépassées avant même d'être achevées, par les avances encore plus rapides sur le matériel. (Que l'on considère aujourd'hui ce qui se passe sur les processeurs graphiques.) Les hyperviseurs, tout complexes et de bas niveau qu'ils soient, offrent opportunément un standard pour se concentrer sur le design de l'OS et moins sur les tâches ancillaires de la gestion de détail de l'infrastructure matérielle.
Le dilemme de l'hyperviseur
Les hyperviseurs sont parfois présentés comme l'étouffoir de la recherche sur les systèmes d'exploitation et, en cela, le succès de la virtualisation freinerait en fait le développement de l'architecture cloud computing. À ce propos, Claude Conputaing pense que ces hyperviseurs, qui la déçoivent par le peu d'innovation technique qu'ils apportent à la recherche sur les noyaux d'OS, sont peut-être paradoxalement les catalyseurs de nouvelles directions de recherche bien différentes des sujets canoniques de l'état de l'art actuel. Au plan du partage et de la protection des ressources, les hyperviseurs modernes utilisent en effet des techniques de scheduling bien connues — souvent étudiées naguère en vue de systèmes multimédia puis laissées en déshérence (qui se souvient de QLinux ?) devant le peu de traction commerciale à l'époque. De même, les mécanismes de protection des données (un état de la MMU par machine virtuelle) ne sont pas éloignés de la protection des espaces d'adresse dans un noyau conventionnel. Au plan des communications inter-processus (IPC), si les premiers designs d'hyperviseurs considéraient qu'elles étaient de la responsabilité de l'OS invité et n'offraient en conséquence que peu de support, les développements récents, à la recherche de meilleures performances, enrichissent leur IPC en déléguant l'exécution des drivers à leurs OS invités. Dans les récentes versions de Xen, par exemple, les drivers tournent dans leurs domaines séparés qui sont comme des « serveurs de drivers » pour le client hyperviseur. Cette architecture rappelle celle des micronoyaux et ne saurait non plus être qualifiée de novatrice.
Pour Claude, la recherche sur les OS est donc face à un choix autour des hyperviseurs. Soit l'on continue à chercher de meilleures implémentations de ces interfaces bien connues, à améliorer les techniques de paravirtualisation dans l'OS invité, à affiner l'implémentation de l'hyperviseur lui-même ce qui, pour n'être pas bouleversant, a le mérite considérable de trouver une application à court-terme et un impact commercial indéniable. Soit l'on constate hardiment que les techniques de virtualisation n'imposent en aucun cas une interface de VM matérielle ou d'OS invité « paravirtualisé », qui sont les formes actuelles des API de tous les hyperviseurs, et que, débarrassé des soucis du support des applications historiques (legacy) et de la douleur de l'écriture des drivers, le chercheur peut enfin explorer dans l'hyperviseur de nouvelles méthodes d'ingénierie, l'application de méthodes formelles, le support de nouveaux langages de programmation (échapper à l'ombre portée de POSIX et de C !), des nouvelles architectures de processeurs, et définir les métriques indispensables à l'évaluation de systèmes radicalement nouveaux.
La résurgence du lambda
En attendant le coup de fouet à la recherche prophétisé par Claude, certaines équipes se penchent déjà sur la question des OS spécialisés pour les applications « dans le nuage ». L'émergence de frameworks pour le calcul réparti comme MapReduce (Google), Hadoop (Fondation Apache), Dryad (Microsoft) facilitent en effet l'exploitation de groupes d'ordinateurs en parallèle. Et l'idée de spécialiser un noyau — voire d'unifier ces plateformes en les faisant tourner virtualisées sur un OS léger dans des conteneurs isolés — pour l'exécution de ces plateformes commence à voir le jour.
Le système Spark de l'Université de Berkeley, développé pour l'OS spécialisé cluster Nexus, installe la prise en compte d'un même jeu (volumineux) de données dans un grand nombre de calculs exécutés en parallèle comme abstraction principale. Cette articulation autour du jeu de données (working data set) est particulièrement adaptée aux classes d'applications pour lesquelles MapReduce et Hadoop sont notoirement moins efficaces qu'espérés : les tâches itératives — qui nécessitent, dans MapReduce/Hadoop, de recharger à chaque itération la totalité des données — et les analyses interactives ou les simulations, par exemple — qui, là aussi, induisent une forte latence puisque, dans MapReduce/Hadoop, chaque requête sur le même jeu de données est finalement traduite en tâches MapReduce distinctes.
De même, c'est le langage fonctionnel OCaml qui est employé pour coder les noyaux d'OS spécialisés cloud de Mirage. Et c'est une bonne nouvelle, ajoute Claude Conputaing, puisque la France s'enorgueillit d'héberger le véritable couvent des Camlites, l'INRIA, dont les branches apostolique et contemplative sont à l'origine du langage.
Peut-être plus novateur encore que le développement de noyaux spécialisés pour le cloud, les avancées sur de véritables nouveaux langages de programmation du cloud que Claude Conputaing invoque de plus en plus souvent pour illustrer un de ses thèmes favoris : la résurgence des langages de programmation fonctionnelle. (Une vie de Lispeur n'est jamais mise qu'entre parenthèses.)
Dans la nouvelle génération de plateformes de calcul cloud, l'utilisateur est libéré des considérations de programmation de sockets, de RPC, de transfert de données et de gestion des défaillances des machines. En revanche, il doit spécifier les traitements à effectuer dans un langage de coordination qui est généralement différent du langage de programmation employé pour coder ces traitements. Ainsi Sawzall pour MapReduce chez Google — alors que le papier laisse à penser que Awk et Python sont localement préférés pour les traitements eux-mêmes —, Hive (batch processing) et Pig (!) pour la plateforme Hadoop, alors que Java est le langage naturel pour implémenter les fonctions map() et reduce() des traitements, DryadLINQ, un jeu d'extension des langages de programmation, basé sur LINQ de Microsoft, pour les applications à répartition de données sur la plateforme Dryad, sont autant d'exemples de cette dichotomie actuelle.
Certains furent prompts à noter que ces langages de coordination ne sont pas aussi expressifs que de véritables langages de programmation généraux et, comme déjà mentionné, rendent difficile l'expression d'algorithmes itératifs (par exemple, PageRank) ou de programmes de simulation et d'analyse interactive de données. D'où une première voie de recherche : l'élévation du langage de coordination au rang de langage de programmation par l'adjonction d'une sémantique fonctionnelle, puisque l'on veut traiter sur un pied d'égalité données et calculs sur ces données. Skywriting, développé au Computer Lab. de l'Université de Cambridge, est un langage de coordination à la syntaxe inspirée de Javascript qui permet d'exécuter un graphe de tâches quelconque, qui n'est donc plus limité aux seuls graphes directs acycliques (DAG) caractéristiques des outils d'aujourd'hui. En particulier, un script Skywriting peut créer de nouvelles tâches asynchrones au vol, détecter les dépendances entre jeux de données et exécuter des itérations sans connaissance a priori de leur nombre. Skywriting est aussi un langage fonctionnel au typage dynamique qui, pour décrire les manipulation de lourds volumes de données sans en charger la mémoire, utilise un niveau d'indirection, la fonction ref() qui joue un rôle comparable au nom de fichier dans le Google File System, et à l'objet DryadTable dans DryadLINQ. Skywriting dispose ensuite d'une fonction spawn() qui prend comme argument la fonction a exécuter et ses arguments — cette dernière impliquant éventuellement du code écrit dans un autre langage de programmation — et renvoie une référence. L'opérateur de déréférencement (« * » comme en C) permet de synchroniser l'exécution des tâches, par exemple lorsque le traitement des données n'est pas terminé.
function process_chunk(chunk, prev_result) {
// Exécution du traitement sur les données
// Renvoie un résultat partiel pour le bloc donné
};
function is_converged(curr_result, prev_result) {
// Exécution du test de convergence entre les résultats de
// deux étapes successives. Renvoie un booléen
};
function iterative_alg(data_chunks) {
curr = ...; // Valeur initiale
do {
prev = curr;
curr = [];
for (chunk in data_chunks) {
// Lance le traitement des blocs de données en parallèle
curr += spawn(process_chunk, [chunk, prev]);
}
// Déréférence le résultat du test de convergence
// Bloque en attendant la fin de l'exécution des tâches précédentes
converged = *spawn(is_converged, [curr, prev]);
} while (!converged);
return curr;
};
input_data = [ ref("file://cluster-1-37/input0"),
ref("file://cluster-2-23/input1"),
...];
return iterative_alg(input_data);
Dans l'exemple ci-dessus on effectue un traitement itératif sur le cloud d'un grand volume de données divisé en blocs (la liste de références input_data) jusqu'à ce qu'un critère de convergence soit satisfait. À chaque itération, ce critère ne peut être vérifié que si tous les traitements bloc par bloc sont terminés, c'est le déréférencement *spawn(...) qui synchronise les flux de données. Le programmeur écrit une boucle while comme il en a l'habitude et le provisioning des tâches — dont le nombre est inconnu à l'avance — est pris en compte automatiquement pour les placer soit sur Hadoop, soit sur DryadLINQ.
Le retour en grâce des langages de programmation fonctionnelle n'est pas sensible uniquement dans la recherche d'une plus grande expressivité des langages de coordination pour les plateformes de cloud computing, on en trouve également le témoignage dans le renouveau du vénérable et quasi-oublié Datalog proposé récemment pour développer les applications de type cloud. À l'ère paléohistorique des années 70, Datalog fut un langage de requête et de règles pour les bases de données dites déductives, à la fois fonctionnel et déclaratif. C'est d'ailleurs à ce double titre qu'il présente une aubaine pour la programmation cloud : fonctionnel, il manipule à l'identique données et traitements, déclaratif, il se prête admirablement aux preuves formelles. (Il est aussi l'occasion d'un cocorico national et patriotique puisque sous-ensemble de Prolog, que nous devons à Alain Colmerauer et Philippe Roussel au début des années 1970, et qui devait alimenter le fantasme du péril jaune de la Cinquième génération aux États-Unis au milieu des années 1980 : rappelez-vous, une invasion de bases de données déductives, à la logique infaillible, issues des profondeurs d'un Japon qui peut dire « Non ! » devait mettre à mal la suprématie reaganienne triomphante des USA à l'apex de la guerre froide...)
En partant de cet avant-poste, très daté, des guérillas théoriques que l'histoire a drapé depuis du manteau de l'oubli, l'équipe de Joseph Hellerstein à Berkeley se livre à un dépoussiérage de Datalog — et de sa postérité innombrable — le dotant d'une part d'une gestion de la persistance et d'un véritable état évolutif (mutable state) et, d'autre part, de la prise en compte déclarative du temps avec des prédicats synchrones et asynchrones. Le langage ainsi obtenu, Dedalus, devient opérationnel dans l'espace-temps du cloud. C'est la première étape vers un langage de programmation cloud pour le commun des mortels, Bloom, qui devrait mettre le développement des applications intensives en données à la portée de tous. Dans Dedalus on distingue ainsi plusieurs types de règles :
- Les règles déductives :
reports_to( X, Y ) :- works_in_deptmt( X, Z ), runs_deptmt( Y, Z );qui sont du Datalog classique ; - Les règles inductives :
reports_to( X, Y )@next :- works_in_deptmt( X, Z ), runs_deptmt( Y, Z );dont la conclusion est vraie mais à l'instant suivant sur une échelle de temps discret ; - Les règles asynchrones :
reports_to( X, Y )@async :- works_in_deptmt( X, Z ), runs_deptmt( Y, Z );dont la conclusion devient vraie (arbitrairement) plus tard et qui permettent de capturer la latence du cloud.
Des procédures d'évaluation — dites savamment de stratification temporelle — permettent de démontrer formellement que le calcul logique de la répartition l'état du programme et de son évolution dans le temps sont corrects. Ces primitives permettent alors de programmer des applications ciblées dès l'abord pour une exécution sur le cloud dans la plus grande généralité.
Tout ceci constitue au final un véritable programme de recherche et développement dont les applications industrielles n'attendent que les premiers résultats pour rénover le calcul scientifique et ses applications, la gestion des données et des processus d'entreprises devenus volumineux et pressés à l'ère du Web, et ouvrir la voie à la production massive de Services Web de grande consommation à l'échelle des Google, Microsoft, Yahoo! et Facebook...
