Le Cloud Computing consommerait moins d’énergie que prévu

Les chiffres de la consommation énergétique du Cloud sont assez largement inférieurs aux prévisions. En cause : la crise, ainsi que l’optimisation des centres de données, dont le fonctionnement requiert moins d’électricité qu’auparavant.

Le Cloud est un procédé gourmand en énergie. Faire fonctionner les centres de données qui servent à héberger ces nouvelles applications consomme en effet une grande quantité d’électricité. Toutefois, d’après une étude menée par Jonathan G. Koomey, professeur à l’université de Stanford, cette consommation est aujourd’hui moins élevée que ce qui était prévu il y 5 ans. Ainsi l’Agence pour la protection de l’environnement prévoyait un doublement de l’énergie consommée par ce secteur. Or, la croissance effective n’a été «que» de 56% depuis 2005.

Un constat, deux explications

Première responsable de ce résultat : la crise économique. Comme le souligne l’auteur de l’étude, « cette baisse est en partie imputable à la récession ». Mais celui-ci nuance immédiatement son propos : «ce qui a réellement changé la donne, ce sont les évolutions dans la façon de concevoir et de gérer les centres de données. La consommation de ceux-ci est en effet bien moindre que ce à quoi l’on pouvait s’attendre». Il est toutefois impossible de délimiter clairement l’impact de l’un et l’autre phénomène. Au final, cette baisse risque de toute façon de n’être que temporaire. L’expansion du marché, et les nouveaux usages du Cloud (achats en ligne, musique…) requièrent en effet de plus en plus de capacité de stockage, et entraînent logiquement une hausse du besoin en énergie.

La stratégie Google : un exemple à suivre ?

Pour limiter cette augmentation, l’étude s’intéresse au modèle adopté par Google. En effet, étant donné le type d’activités et la taille de l’entreprise, sa consommation d’énergie destinée au Cloud devrait atteindre des proportions conséquentes. Pourtant, il n’en est rien : Google ne représenterait que 1% du total mondial d’énergie consommée par les centres de données. Cela confirmerait l’idée selon laquelle Google serait plus efficace que le reste du marché du Cloud, énergétiquement parlant. Au final, il serait donc plus profitable de favoriser l’installation de centre de données adaptés selon les tâches requises (comme le fait Google) plutôt que de recourir à un équipement standardisé.

 

Pour allez plus loin, vous pouvez consulter l’étude .PDF en question (8 mo – en anglais) hébergée sur Enerzine.com, en cliquant sur ce lien >>> ICI

[ Source : Atelier – BNP Paribas ]

Articles connexes

6 Commentaires
Le plus ancien
Le plus récent Le plus populaire
Commentaires en ligne
Afficher tous les commentaires
deniso

Certes l’augmentation est moins forte que prévue mais la consommation énergétique des data centers est amenée à exploser dans les années à venir, il ne peut en être autrement. Maintenant il faut se poser la question sur comment maîtriser cette explosion ? Avec des solutions éprouvées dans l’industrie () ?

Lionel_fr

La consommation électrique du parc informatique est aussi anti-linéaire qu’on peut l’être. Google chrome entre dans sa phase de déploiement du modèle native-client qui fait remonter le C/C++ jusqu’au client protégé par un “bac à sable”. Le procédé se substitue à HTML5 + Javastript avec un gain de performances potentiel facteur 10 ! Apple a fait la même chose avec ObjectiveC , seule plateforme de dev autorisée sur ses plateformes mobiles. Ce faisant, on quitte la logique de l’empilement des couches pour revenir au C fondamental ce qui constitue une rupture très forte par rapport aux “croyances païennes” des années 2K. Le paradoxe de cette situation est Java qui reste prépondérant sur Androïd alors que son modèle multiplateformes est couteux en énergie au moment de l’éxecution. Javascript consomme des watts inutiles par son typage faible, sa compilation JIT mais quid de PHP qui fait exactement la même chose au niveau des serveurs ? (modèle ovh). Si l’utilisation systématique du C permet de sauver de l’énergie, il faudrait la propager aux serveurs et concevoir les pages en C, ce qui n’est pas vraiment difficile mais plus long en terme de développement (chaines statiques, pointeurs explicites,..) D’ou ma suggestion : quid de développer des outils de conversion PHP -> C … bon ! Ensuite , si le cloud consomme moins que prévu c’est aussi parce que le modèle de communication est très lourd : PHP->HTML->javascript->XML… sans compter les codes construits dynamiquement et autre étrangetés qu’autorise cette architecture. Alourdir le serveur et alléger le client permet certainement une économie importante globalement et plus encore localement car les clients mobiles fonctionnent sur batterie ou chaque milliwatt est autrement précieux. Le cloud permet une mutualisation de ressources telle, qu’il suffit d’optimiser un seul de ces maillons faibles pour obtenir des résultats très visibles en termes de consommation. On peut s’attaquer ensuite à l’effet domino : perf++ = consommation– ce qui permet à un serveur de traiter plus de demandes et donc d’en diminuer le nombre… On est loin d’avoir une vue globale des économies qu’il est possible de réaliser uniquement par le software. Le hardware a aussi son mot à dire mais la loi de Moore suffit à résumer cette partie dans notre cas de figure. Donc c’est au soft de jouer non ? Je me demande ce qu’en pense EnerZ .. Il y a tellement de possibilités ..

Lionel_fr

je ne pense pas que la consommation doive nécessairement exploser : un exemple : le pear 2 pear , protocole injustement associé à la déconfiture des auteurs sur internet. Or le P2P n’a rien à voir avec les auteurs, c’est un peu l’aboutissement d’IP puisque il utilise chaque client comme un cache pour les autres clients.. il évite une montagne de serveurs qui envoient exactement les mêmes données à des millions d’éxemplaires – comme c’est la cas sur Youtube ou Dailymotion. Il est éviedent que si le datacenter se contentait d’envoyer une seule copie par noeud de réseau et que chaque noeud “arrose” à son tour d’autres “clients-noeud” , on pourrait économiser des gigawatts sur la video. Sur la construction de pages dynamiques, mon message précédent montre à quel point le potentiel d’optimisation est vaste .. Compte tenu des efforts d’Apple et Google dans le soft et d’Intel dans le hardware et à fortiori ARM quand il aura atteint le même niveau de technicité qu’Intel, on peut imaginer que l’énergie gagnée soit supérieure à la croissance naturelle de la demande. La situation actuelle reflète surtout l’état des technologies des années 2000, mais si on généralise l’effort fourni par ces constructeurs , on peut vraiment faire baisser la consommation.

Lionel_fr

Il me semble que les premiers grands portails comme Yahoo et Google ont utilisé leur consommation electrique comme un avantage concurrentiel. La concurrence étant plus économe a limité ses datacenters, c’est le cas en France ou les portails ont été des echecs fracassants parce qu’ils limitaient leur service à ce qui était économiquement viable Aujourd’hui on assiste au mouvement inverse ou des costructeurs comme Apple utilisent une architecture économe en énergie comme un avantage concurrentiel , la concurrence empétrée dans les architectures couteuses en perf et en énergie ne parvient pas à tirer autant parti du hardware qu’un iPhone qio le fait tourner que du code en C. Deux stratégies gagnantes diamétralement opposées , le seul facteur commun est l’avantage concurrentiel…

Lionel_fr

Encore un exemple de ce qu’il faut faire : Ce n’est qu’un exemple parmi des millions .. Une nouvelle famille de bases de données nommées “NoSql” s’est développée récemment. Elle permet notamment aux réseaux sociaux de gérer des tables ENORMES de plusieurs centaines de milliards de lignes. Si on accepte qu’un simple “select *” peut devenir très couteux de façon complètement invisible – car il s’alourdit à mesure que la table grandit. Vous imaginez les milliards de lignes de code à revoir pour que l’internet arrète de consommer 100 fois plus d’énergie que necessaire… Si on fait un bilan rapide , on voit qu’une table appelée par un select * le 1er janvier provoque 100 fois plus de traffic réseau le 1er décembre suivant, sans aucun changement visible sur le programme appelant… Faut-il pour autant forcer les développeurs à lister les champs dans chaque requete en sachant que cela va les ralentir et que le cout d’un développement va exploser ? La réponse est probablement non Par contre, un hébergeur comme ovh serait bien inspiré de fournir de bons profilers à ses clients car il ne facture pas le traffic local vers ses serveurs mysql et que logiquement , il est obligé de surdimensionner son réseau local, ses routeurs, sans parler de ses répartisseurs de charge qui vont réorganiser seon réseau en temps réel simplement parce qu’un select * traine dans un bout de code qui date de la préhistoire.. Un profiler permet de le détecter mais qui l’utilise alors que le cout de l’infrastructure réseau (datacenter) ne sera jamais répercutée vers le client ? L’autre défaut qu’on peut reprocher à sql est le peu de contrôle qu’on a sur les indexes. C’est le serveur lui-même qui décide de leur utilisation et le language ne permet pas de la “forcer” Mais toute base de données est appelée à grandir et de nouveaux ploblèmes liés à la volumétrie apparaissent régulièrement dans ce type d’utilisation. Un index ne sert pas à grand chose sur une table de 200 lignes mais un jour cette table atteint 200 millions de lignes et l’index mal testé au début se révèle inadéquat quand il n’est pas simplement ignoré par le serveur qui se contente de ralentir sans raison apparente… Bref il y a de quoi faire, au boulot !

Lionel_fr

Quelqu’un dans un autre topic me dit omniscient , ça me motive pour revenir à la situation de mon premier post : une majorité écrasante (90%?) de serveurs passe ses journées à faire tourner du PHP. Dans le cas d’Ovh, les serveurs mysql sont mutualisés sur des machines distinctes des serveurs Apache. Une page web standard va faire .. allez, une 15aine de requètes pour se construire dynamiquement au moment précis ou l’internaute clique Auparavant, le code PHP aura été parsé, les #includes inconditionnels auront été inclus au niveau source (PHP permet de faire des inclusions dans des IF) Le code PHP sera compilé en accédant aux variables de session stockées par apache, puis executé en lançant les select sql tour à tour (synchrone) car il faut souvent attendre le résultat d’une requète pour lancer la suivante. Mysql reçoit la requete, parse, compile, execute et renvoie le résultat à PHP qui attend etc… 15fois de suite par page ! Je n’entre pas dans la logique d’AJAX qui ne concerne pas (encore) les Enerzinophiles.. Ajoutons quand même les requetes lancées aux API google dont j’ignore s’il faut attendre la réponse pour afficher le html. On peut néammoins noter que google ads a un trafic monstrueux à gérer et qu’il emploie sans doute un code très optimisé pour servir les requetes. Justement, Google est le premier parc de datacenters au monde, l’optimisation de son service lui permet de sauver des milliers de serveurs, il peut donc investir dans le développement de ses services widget dont on peut dire qu’ils ne fonctionnent certainement pas sous PHP ! Mais comment un site mutualisé chez OVH pourrait il optimiser sa consommation (ce que personne ne lui demande et surtout pas ovh ..)??? Réécrire les pages en C ne demande pas beaucoup de travail , 3 à 5 modèles de pages (sans inclusions : il faut copier coller la charte graphique dans chaque page) compilées en code natif et executées à chaque requete des internautes.. disons 15 jours de boulot , peut être un mois car on en profiterait pour améliorer quelques points.. peanuts ! On a donc déjà viré tout le PHP staff , parsing, inclusions, reparsing, compilation(s) à la volée. En C , on passe directement à l’execution et bien sûr, on refait les 15 requètes, mais cette fois ci, au lieu de balancer du code sql sur le réseau, on va appeler des procédures stockées. Il faut donc écrire 15 procédures , c’est le travail d’une journée, un peu plus s’il y a des requetes avec arguments (plus rapides que les concaténations sql). A son tour, le serveur BDD n’a plus besoin de parser ni compiler, il peut éxecuter la requete déjà compilée et renvoyer le résultat entre 3 et 5 fois plus vite qu’avant. On aura sans doute des résultats encore meilleurs avec du NoSql mais au prix d’un serveur dédié… et beaucoup de travail (sans compter les mises à jour). Au passage on se sera complètement protégé d’un certain nombre d’intrusions dont je tairai le nom pour ne pas vendre la mèche à des desperados d’un autre continent.. Au final , 5 modèles de pages en C et une cinquantaine de procédures stockées auront été nécessaires pour que le même service soit 5 à 10 fois plus rapide – ou qu’il puisse accueillir 15 fois plus de visiteurs sans changer de hardware à consommation égale.. Les chiffres sont à la louche mais on peut comprendre ce qui se passe chez les grands fournisseurs de service .. Si l’énergie des datacenters devient vraiment un argument de vente, les webmasters vont devoir mettre la main à la pâte