Flux RSSGreen IT : quel impact sur le design des architectures logicielles ?
Par Eric Fauquemberge, architecte .NET chez Novedia Solutions et référent de la communauté .NET
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 on voit 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.
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-cœurs 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 (Le blog de l'équipe PFX).
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 : Les éditeurs de logiciels dépassés par l'évolution des puces multicœurs).
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 sur allocation initiale !
En se rendant capable d'estimer plus précisément 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 monolithique 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 hiérarchiques. 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 CPU à 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 ;
- 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...
___________________
Novedia Group en bref
Novedia, groupe dédié aux technologies de l'information et de la communication, accompagne les entreprises dans les phases de réflexion, de réalisation et d'animation de leurs activités web et mobiles. Le groupe réunit 500 collaborateurs en France et à l'International, compte plus de 150 clients sur tous les secteurs d'activités et fait état d'un CA de 45 millions d'euros sur l'année 2008. Il est présent dans une quinzaine de pays.
http://www.novediagroup.com
Imprimer l'article
Transférer par mail
Réagir à cet article
Les commentaires
L'argument de départ est faux. On peut en voir une des réactions ici:
http://www.informatiquepourtous.com/forum/index.php?showtopic=25570
Le seul fait de pouvoir croire en une telle exageration, fût elle donnée par le times, me laisse perplexe sur les compétences de l'auteur.
Imaginons une demie seconde la puissance de refroidissement des serveurs google si un clic valait tant d'énergie.
...
avec des éoliennes pour ventilo peut être?
Par plouffy le 25/07/2009 à 11:24
Les 10 derniers articles mis en ligne
- Le Mac pour les Nuls, les Nulles et les plus Nuls...
- La musique au service du marketing, l’impact de la musique dans la relation client
- 2012 : La demande en technologies ne connaît pas la crise
- Le triple A du WWW - Par Hervé Kabla, Directeur Général, co-fondateur de blogAngels
- Les inondations en Thaïlande ont un impact positif sur les résultats de Seagate
- Nominations au sein de la division Secteur Public de Logica Business Consulting
- MyJobCompany.com : le recrutement par cooptation
- Athic annonce son partenariat technologique avec Abbyy
- Les 10 tendances principales en matière de solutions décisionnelles pour 2012
- Le French Scrum User Group convie les professionnels de l’Agilité au Scrum Day 2012
le 31/01/2012 à 04:56