Moore's Law and The Future of [Technology] Economy

Qu’est-ce qu’un système distribué ?

Jusqu’à présent nos avons considéré une machine seule, or chacun sait qu’aujourd’hui les nœuds de calcul sont connectés par des réseaux de toutes sortes. Ces réseaux peuvent être très locaux, comme Bluetooth ou les LAN – Local Area Networks – ayant pour support de l’Ethernet, du WiFi ou du CPL[1], ou globaux – on dit WAN, pour Wide Area Network – comme l’Internet à base d’ADSL, de fibre optique ou de réseau sans fil 3G, demain LTE ou WiMax. Sur ces réseaux en tant que supports physiques, on fait circuler de l’information sous forme de paquets en utilisant généralement le protocole de l’Internet, IP – Internet Protocol.

L’Internet, dont il est désormais connu qu’il a été initialement financé par l’armée américaine en 1969 – il s’appelait l’ARPANET – puis utilisé par les universités, a vu son expansion commerciale lancée en 1993 sous l’administration Clinton-Gore. On parlait à l’époque « d’autoroutes de l’information ». En sus des applications de courrier électronique et de transfert de fichiers déjà existantes à l’époque, le fait majeur ayant motivé son décollage a été l’explosion du web à partir de sa création par Tim Berners-Lee en 1991 au CERN, en Suisse. Le web repose aussi sur un protocole, http, et un standard de ce que l’on appelle l’hypertexte, html, et permettent d’échanger du contenu de toute nature, indépendamment des machines supports. Le web est donc une infrastructure logicielle s’exécutant au-dessus de l’infrastructure de l’Internet.

Tim Berners-Lee

On voit que dès que l’on parle de réseaux on nage dans un océan de protocoles adaptés, mais reposant sur une philosophie commune : l’intelligence est située aux nœuds du réseau, le réseau est là pour transmettre l’information entre ces nœuds à leur demande. Un protocole est fondamentalement une langue commune aux nœuds pour échanger l’information et aussi la méta-information au sujet de cet échange, comme les accusés de réception, les messages d’erreurs, etc. – un peu comme les pilotes de ligne et le trafic aérien communiquent à travers un anglais limité, très codifié, utilisé par tous internationalement, et sensé répondre à toutes les situations.

La performance d’un réseau est caractérisée par quelques quantités fondamentales, comme le débit et la latence : le débit caractérise la quantité d’information que le réseau est capable de transmettre dans une unité de temps – par exemple 4 Mbits/s – la latence est le temps qu’il y a entre l’émission d’un message et sa réception (la moitié d’un aller-retour). Mais d’autres caractéristiques qualitatives sont également importantes. Le réseau peut être « best effort » ou « worst case », dans le premier cas il tente d’optimiser l’acheminement mais sans garantie de temps ni de débit, dans le second il est capable d’apporter des garanties sur des bornes de ces quantités. De façon intermédiaire, il peut apporter de la qualité de service (QoS – Quality of Service) c’est-à-dire apporter ce type de garantie pour certains flux d’information par rapport à d’autres. Son niveau de sécurité est plus ou moins important, c’est-à-dire sa capacité à ne pas révéler les informations qu’il transporte à des personnes non autorisées ou de résister à des attaques diverses.

En pratique deux protocoles structurent l’ensemble des réseaux dans le monde : IP, le protocole de l’Internet, et http, le protocole du web. Leur adoption quasi universelle a bien sûr été à l’origine du formidable développement de l’Internet et du web, mais a aussi transformé ceux-ci en une unique plate-forme d’exécution de services.

Tous les nœuds sur l’Internet ne sont pas « mis à plat » de façon uniforme; en réalité les nœuds sont groupés localement en systèmes cohérents, dépendant le plus souvent d’une même organisation, et sur lesquels on fait tourner des services pour cette organisation. Ainsi le réseau à votre domicile, le réseau d’une entreprise, des serveurs dans ce qu’on appelle une ferme de serveurs, le réseau des systèmes sous le capot de votre voiture, etc., forment de tels ensembles. On les appelle des systèmes distribués.

Un système distribué est donc constitué de plusieurs nœuds de calcul reliés par des réseaux, est considéré comme une entité unique pour les services qui vont s’y exécuter, communique avec l’extérieur de façon homogène, en général à travers un point unique qu’on appelle gateway – passerelle – et est vu de l’extérieur comme un unique nœud de calcul. Les nœuds d’un système distribué peuvent être aussi complexes qu’on le veut, et comporter tout ou partie des éléments d’infrastructure hardware ou software précédemment décrits.

Un système distribué constitue la base de la plate-forme d’exécution moderne, car les circonstances où on n’a qu’une machine isolée disparaissent : tout objet disposant d’une puissance de calcul tend à être connecté, puis associé à un ensemble plus grand.

Néanmoins, un système distribué ne serait pas pratique à utiliser « nu », c’est-à-dire avec uniquement des nœuds de calcul connectés par des réseaux. De la même façon que l’on a construit des systèmes d’exploitation et des langages au-dessus des machines nues afin de rendre leur programmation et leur utilisation plus facile et riche, on construit au-dessus des systèmes distribués une infrastructure logicielle, appelée middleware, et on étend les langages de programmation pour permettre au programmeur de considérer le système distribué comme une unique plate-forme.

Le domaine du middleware est encore plus complexe que celui des systèmes d’exploitation, et est encore en forte évolution. Une des raisons à cela est que l’extension de la pyramide de Feynman vers le bas et la complexification des écosystèmes existants sous l’impulsion de la loi de Moore crée sans arrêt de nouvelles circonstances pour mettre en œuvre des systèmes distribués, mais avec des contraintes nouvelles et variées de performance, de connectivité, etc.

En résumé, les systèmes distribués constituent aujourd’hui la partie de l’infrastructure visible aux créateurs de services : ils sont la plate-forme d’exécution des services lorsque l’écosystème en question atteint le degré de maturité suffisant. Plusieurs telles plates-formes existent, qui correspondent peu ou prou aux niveaux de la pyramide de Feynman[2], et tendant désormais à les intégrer dans de gigantesques systèmes de systèmes.

Nous procédons dans le paragraphe suivant à un rapide tour d’horizon des grands problèmes qu’un middleware doit être capable de résoudre.

Puis nous rentrons dans le détail des écosystèmes et des infrastructures en descendant progressivement le long de la pyramide de Feynman.

Radiographie d’un middleware

Donnons une idée de ce dont peut être fait un middleware et des problèmes qu’il peut avoir à résoudre. Cette description est générale, et chaque point est plus ou moins critique selon l’écosystème et le positionnement dans la pyramide de Feynman.

Le premier point est qu’un système distribué et son middleware définissent un modèle de programmation. On entend par là les langages et outils fournis au développeur pour développer son application distribuée en s’abstrayant autant que possible des détails de l’infrastructure sous-jacente ainsi que la façon dont les applications s’exécutent sur les divers nœuds de calcul – par exemple par des appels synchrones ou asynchrones[3]. Le modèle est pratiquement toujours un modèle à composants, c’est-à-dire que l’on découpe le logiciel à construire en un ensemble de modules faisant chacun sens, qui en communiquant de façon ad hoc vont produire le comportement global attendu, chaque composant ayant vocation à « tourner » sur un nœud du système distribué. Toute une série de variations sont possibles pour définir les composants et leurs communications, et la façon dont ils peuvent être organisés en entités plus complexes. En outre, on aimerait pouvoir définir à part et de façon déclarative les propriétés souhaitables de ces composants, par exemple en terme de sécurité ou de garantie de performance.

Le second aspect est que l’on a besoin d’un système pour spécifier et réaliser le déploiement des composants. Celui-ci peut être fixé une fois pour toutes sur un système dont l’infrastructure est fixe et peu soumise aux pannes, il doit être dynamique sinon. Dans ce dernier cas le middleware doit être capable d’identifier les ressources disponibles. Le déploiement peut être plus ou moins contraint par le concepteur, ou laissé à l’initiative du middleware. Celui-ci peut prendre en compte les nécessaires interactions avec l’utilisateur ou l’environnement via les capteurs et actionneurs (par exemple en rapprochant un composant d’un système d’interaction). Il doit être également capable de comprendre dans une certaine mesure la sémantique des données échangées (cf. partie sur le contenu). Enfin il doit être capable de résoudre les éventuels conflits entre services ou composants.

Le troisième aspect est qu’il doit savoir gérer les ressources, par exemple par l’équilibrage de charges, et garantir les éventuels impératifs de qualité de service. Il doit également être capable de prendre en charge la connectivité globale (Internet), et à l’inverse la connectivité avec des nœuds hétérogènes, singulièrement lorsque ceux-ci ne disposent que de ressources limitées.

Quatrièmement, il doit être capable de gérer la distribution des données. C’est un problème complexe car on doit marier performance et bien sûr correction des traitements. Ainsi, on est conduit pour accélérer l’accès aux données à les rapprocher des nœuds exécutant les traitements les utilisant, éventuellement en les dupliquant. Mais il faut alors aussi assurer la cohérence globale, par exemple si l’on modifie une copie l’effet apparent doit être « immédiat » pour l’ensemble du système.

Cinquièmement, il doit être capable d’alerte et de diagnostic de dysfonctionnement, et de proposer et mettre en œuvre des mesures palliatives. Il doit également mettre en œuvre ce qu’on appelle l’isolation d’erreur, c’est-à-dire interdire qu’un service soit affecté par le crash d’un service logiquement indépendant. Pour les systèmes l’exigeant, il doit supporter des preuves de correction sur la base des preuves pour les composants.

Sixièmement et enfin, il doit mettre en œuvre le niveau de sécurité requis : authentification, protection des données, résistance à l’intrusion et aux attaques.

Moore’s Law and the Future of [Technology] Economy de Jean-Luc Dormoy est mis à disposition selon les termes de la licence Creative Commons Attribution – Pas d’Utilisation Commerciale – Partage à l’Identique 3.0 non transposé.
Basé(e) sur une oeuvre à mooreslawblog.com.