Tribunes

Green IT : impact sur le design des architectures logicielles

L'architecture et la conception des solutions logicielles peuvent et doivent participer à la démarche Green-IT grâce à de bonnes pratiques.

PublicitéEffectuer deux recherches sur Google consomme l'énergie équivalente à celle nécessaire pour faire chauffer 2 tasses d'eau dans une bouilloire (soit 7g de CO2, pour les fans de chiffres). C'est le résultat d'une étude scientifique intitulée Google and you'll damage the planet et citée par le journal anglais Times le 11 Janvier 2009. Ainsi voit on que les activités informatiques sont bien énergivores... Cela rend plus concret et compréhensible le besoin de prendre en compte les considérations environnementales dans la mise en place des systèmes d'information. Nous allons ici essayer de mettre en évidence l'impact que devrait avoir cette approche sur le design des architectures logicielles, et comment les acteurs du développement informatique peuvent y contribuer. Vous pourrez constater un biais orienté vers les technologies .Net dans les exemples cités, mais les principes s'appliquent facilement dans tous les environnements technologiques. Commençons par clarifier quelque peu le concept de Green IT... Green IT : qu'est-ce donc ? Il s'agit de l'effort réalisé par l'ensemble de l'écosystème informatique (fournisseurs de matériels, gestionnaires de centre de données, départements IT des entreprises, éditeurs logiciels) pour réduire l'impact environnemental de cette activité. On peut y voir plusieurs motivations : - émergence dans la société d'une forte préoccupation pour tout ce qui touche à l'écologie : réchauffement climatique, optimisation des ressources énergétiques... - réduction des coûts financiers engendrés par la partie opérationnelle de l'IT ... motivation certes plus terre à terre et un peu moins noble, mais d'autant plus pertinente en ces temps de crise... Etre Green, c'est réduire sa consommation électrique en jouant sur le levier de la consommation de ses centres de données (alimentation des serveurs, climatisation ...), mais aussi réduire la quantité de matériaux à recycler (serveurs en fin de vie ...). Cela regarde-t-il l'architecture logicielle ? Tout cela est bien joli et n'est donc pas qu'un concept fumeux, me direz-vous, mais... - ne peut-on pas se contenter des efforts des constructeurs informatiques qui optimisent leurs composants (CPU basse consommation, gestion de la veille...) ? - n'est ce pas un problème qui doit être géré par l'IT (gestion des datacenters, recours à la virtualisation...) ? La réponse est négative : l'architecture et la conception des solutions logicielles peuvent et doivent participer à cette démarche. Voici quelques pistes et bonnes pratiques d'architecture qui vont nous permettre d'apporter notre pierre à l'édifice... Que peut-on faire dans le cadre de l'architecture logicielle ? 1. Utiliser chaque serveur au maximum de sa capacité Traditionnellement, on s'occupe peu d'utiliser au maximum les capacités processeur d'un serveur. L'arrivée des processeurs multi-coeurs amène de réelles capacités de traitements parallèles auparavant uniquement accessibles aux machines multi-processeurs. Cependant, la programmation parallèle est souvent perçue, et à raison, comme une activité relativement complexe à implémenter, à déboguer (ah, la synchro de thread et l'accès concurrent...) et à maintenir (compétences rares). Désormais, les utilisateurs du framework .Net ont à disposition une librairie facilitant grandement la programmation multi thread : les Extensions Parallèles à .NET (PFX). Ce framework additionel permet par exemple d'exécuter les itérations d'une boucle dans un pool de threads sans avoir à se soucier des problématiques de synchronisation, d'allocation de threads etc. Cela peut répondre à des besoins de calculs ou chaque itération est indépendante des autres. On peut aussi utiliser PFX for Linq (PLinq) pour accélérer l'accès et la manipulation des données. En utilisant un serveur au maximum de ses capacités processeur par la l'utilisation du multithreading, on réduit le besoin de montée en charge par ajout de serveurs. On est alors un peu plus Green. Un bon article sur le sujet : http://www.zdnet.fr/actualites/informatique/0,39040745,39386864,00.htm?xtor=RSS-8 Le blog de l'équipe PFX : http://blogs.msdn.com/pfxteam/ 2. Instrumenter les applications dans ce but On a l'habitude d'instrumenter nos applications afin de signaler les problèmes aux outils d'exploitation et pour faciliter le déboguage a posteriori (logging, event log ...). Il est intéressant d'ajouter dans cette partie de l'architecture applicative des capacités de reporting de l'état de l'application au monde extérieur : compteurs de performance pour indiquer le flux traité par l'application etc. Ainsi, on est facilement capable d'analyser les pics de charge constatés par l'application en production et ainsi de procéder au provisioning adéquat de serveurs, ce qui peut notamment permettre de réduire le nombre de serveurs en cas de surallocation initiale ! En se rendant capable d'estimer plus précisement le nombre de serveurs nécessaires à l'utilisation de l'application, on est Green. Par ailleurs, on s'efforcera de rendre débrayables tous ces mécanismes s'il s'avéraient trop consommateurs de ressources, ce qui pourrait alors s'avérer contre productif par rapport à l'objectif ! 3. Veiller à la granularité des composants Lorsqu'on est amené à faire croître le nombre d'instances d'une application monolitihique pour répondre à des problèmes de charge, l'ensemble des couches de cette application se trouve dupliqué, alors qu'il est fort possible que seule une couche de l'application soit saturée (la couche métier par exemple). C'est alors un gâchis de ressources. En rendant nos applications le plus modulaire possible, on sera d'autant plus flexible dans les possibilités de montée en charge. On s'efforcera donc de découper les applications en modules s'exécutant de manière indépendante. On pourra s'inspirer des pistes ouvertes par l'approche SOA. 4. Utiliser asynchronisme et découplage En complément du point précédent, on s'efforcera de rendre les couches de nos applications le moins couplées possibles, pour pouvoir gérer la multiplicité des services implémentant une couche. On tirera partie des mécanismes de queues de messages pour implémenter des patterns de type producteurs/consommateurs. L'asynchronisme sera à prendre en compte, d'autant plus que la réduction des coûts pourra imposer qu'une ressource ne sera pas toujours à disposition au moment où l'on en a besoin. 5. Aller sur la voie du Cloud Computing Pour terminer, je voudrais mentionner la piste du Cloud Computing. En déchargeant les entreprises des tâches liés à la gestion physique des serveurs, et en déportant cette gestion dans des data centers à l'empreinte écologique optimisée, cette piste est prometteuse. Au delà de l'optimisation du coût individuel d'un serveur, elle permet aussi de répondre à des problématiques de pics de charge ponctuels (les soldes pour un site de e-commerce), ou de sous charge (juste avant les soldes !) par réallocation du nombre de serveurs affectés à l'application. Néanmoins, avoir recours à la solution du Cloud Computing n'est pas sans conséquence sur l'architecture logicielle ! Je vais prendre ici l'exemple de l'offre Microsoft Windows Azure. S'exécutant dans des "bacs à sable" (au mieux une machine virtuelle/physique indépendante, au pire dans des application domains séparés mais partageant une machine virtuelle/physique), les applications vont devoir d'adapter: - persistance et gestion d'état : l'offre Azure n'inclut pas l'accès à une base de données relationnelles mais à des sous systèmes de stockage basés sur des queues, des listes et des bases de données hierarchiques. Il faudra donc rendre l'application très modulaire et adaptable dans sa couche d'accès aux données, et ne plus systématiquement penser "relationnel". - accès aux ressources locales : les applications pouvant être déplacées de machines en machines selon le bon vouloir de l'ordonnanceur Azure, il ne faudra pas compter sur l'accès au système de fichiers ou à la registry, même pour du stockage temporaire. - restriction de sécurité : les applications devront fonctionner en mode "medium trust", notamment pour s'exécuter de manière sécurisée dans un environnement partagé. Ce mode de fonctionnement a un impact sur le modèle de sécurité à adopter. Etant facturés à la consommation des ressources de base CPU/disque/mémoire, ce type d'hébergement d'application sera d'autant plus économique que ces consommations sont optimisées. Gageons donc que l'utilisation de profilers de performance et l'optimisation des algorithmes et structures de stockage sera le nerf de la guerre (économique). En utilisant le Cloud Computing à bon escient, on sera Green. Conclusion On a vu que l'utilisation de techniques et de choix architecturaux pertinents pouvait faire contribuer les applications informatiques à une démarche d'optimisation d'empreinte écologique. On retiendra, en résumé : - programmation parallèle pour utiliser les CPUs à leur maximum; - instrumentation des applications pour faciliter le provisoning de ressources; - granularité des composants pour faire monter en charge des sous ensembles de l'application; - découplage et asynchronisme; - utilisation du Cloud Computing, qui amène à repenser le contexte d'exécution de nos applications ... et à les optimiser ! Et aussi : éteignez la lumière en quittant votre bureau, privilégiez les escaliers à l'ascenseur...