Cloud, big data et traitement asynchrone : danger pour l'environnement

Par Olivier Philippot  -  29/02/2012

 
ImprimerImprimer

Bonnes pratiques - Programmation asynchrone

Article  publié en collaboration avec le Green Code Lab. Ecrit par Jean-Philippe Gouigoux contributeur Green Code Lab et auteur du livre Ecrire du Code .Net performant

Programmation asynchrone, cloud et big data  : trois des pistes majeures qui nous sont aujourd’hui proposées en tant qu’innovations informatiques peuvent avoir un impact négatif sur la consommation de ressources.

  • Le Cloud : le fait de disposer ponctuellement d’énormément de ressources pour un coût équivalent à la possession de moins de machines a bien sûr un intérêt en termes de réduction de parc des sociétés utilisatrices, mais peut également pousser à une surconsommation, par déresponsabilisation (pas d’acte d’achat).
  • La programmation asynchrone : le temps de traitement synchrone possède une force de signal pour un utilisateur, en termes de ressources nécessaires à un traitement.
  • L’asynchronisme supprime ce retour. Big Data : si vous donnez la possibilité à un analyse de réaliser, en mettant des machines en cluster, des simulations ou des requêtes qui étaient auparavant inutiles car trop longues, il est évident que ces activités vont être de plus en plus sollicitées par celui-ci.

Mais ce qui m’embête le plus, c’est l’effet suivant qu’induit le mélange de ces technologies : La boucle de rétroaction liant la quantité de ressources à la difficulté perçue du traitement risque à terme de disparaitre. Or, il s’agit d’un des seuls garde-fous sur la consommation de ressources informatiques.

Une image vaut mille mots

Je mesure qu’en mode texte, ce n’est peut-être pas très clair. Du coup, j’ai fait l’effort de faire une petite série de diagrammes. Quand on dit que PowerPoint rend bête, je ne suis pas d’accord… Les bullet points rendent bête. Les transitions graphiques sublimes sur un contenu inexistant rendent bête. Les titres accrocheurs sans explication rationnelle rendent bête. Mais pas l’outil, ni la facilité qu’il procure pour créer un diagramme.

Voici en gros comment se passe la boucle de rétroaction dans une architecture “traditionnelle”, avec un client envoyant une requête à un serveur :

image

Dans la boucle intérieure, une requête simple provoque une retour rapide. Dans la boucle extérieure, une requête plus complexe provoque un retour plus lent. L’utilisateur reçoit un signal en retour concernant la complexité de ce qu’il demande au serveur, et sera donc vaguement conscient du niveau de ressources nécessaires.

On passe en mode Cloud, avec un cluster de machines dédiées à votre système Big Data :

image

Vous voyez le problème ? On n’a plus de retour sur la complexité du traitement, car le lissage va se faire sur le nombre de machines. Que le traitement mobilise toutes les ressources du cluster ou une seule table de référence pour répondre, le traitement ne prendra pas fondamentalement plus de temps. L’utilisateur n’a plus de retour intuitif sur la quantité de ressources que son interaction lui a fait consommer.

Et si on va plus loin avec un traitement asynchrone, c’est encore pire :

image

Là, il se peut carrément que l’utilisateur ne reçoive aucune retour, en fonction du comportement de son logiciel et des notifications associées.

Pourquoi c’est gênant

Dans un monde idéal avec des développements performants et des niveaux de consommation rationnels, l’absence de la boucle de rétroaction (l’utilisateur utilise moins de ressources, car il se rend compte que les actions sont lentes et tend à les économiser) ne serait pas si gênante.

Mais à part dans des cas très particuliers, les développements sont rarement optimaux du point de vue de l’utilisation des ressources (avez-vous déjà discuté plus d’une heure avec un utilisateur sans qu’il se plaigne de la performance de votre application ?).

De plus, le manque de retour favorise une consommation surélevée de la ressource. Prenons l’exemple du courrier électronique. J’avoue le premier ne pas faire attention aux nombre de mails que j’expédie. Le fait que l’envoi soit quasi-immédiat et que nous n’ayons aucun retour sur la complexité de faire transiter cette donnée de l’autre côté de la planète y est pour quelque chose. Si les mails avaient un coût direct, et pas seulement un coût indirect par l’abonnement, même très léger, nous n’en enverrions certainement pas autant. Imaginez que vous payiez un forfait à EDF… seriez-vous aussi attentifs à ne pas laisser les lumières derrière vous ?

Pour le Cloud et Big Data, c’est la même problématique : une interaction métier avec un serveur peut très bien mobiliser un cluster de 64 machines sans que vous en soyez conscient. Peut-être imaginerez-vous même qu’il ne s’agit que d’une requête à une base de données. De la même manière qu’un développeur appelle souvent de bonne fois une méthode dans une boucle sans s’être rendu compte que cette méthode appelait un service web… Et l’asynchronisme achève de rendre ceci transparent.

 Conclusion

Pour autant, tout n’est pas noir. Il ne faut pas nier non plus que le fait de grouper des traitements dans des sites spécialisés, avec un refroidissement unifié ou encore mieux réalisé de manière passive (comme le fait OVH, ou avec des datacenters en environnements polaires) permet de réduire le coût énergétique global, et d’optimiser les ressources de construction des matériels.L’approche Big Data, quant à elle, peut permettre d’avoir accès à des analyses qui auraient sinon été réalisées de toute manière à grand renfort de CPU sur plusieurs heures, voire plusieurs journées de traitement.

Enfin, l’asynchronisme est une des méthodes possibles pour favoriser le parallélisme et donc une meilleure utilisation des ressources.

Mais il ne faut pas oublier que, au delà de tous les efforts qui sont réalisés sur la réduction de la consommation sur une base fixe de traitements à réaliser, le mieux est encore de réduire au maximum les traitements à la source. Monsieur Ourghanlian, j’adore vos analyses, votre capacité à les expliquer et surtout votre ouverture sur des domaines autre que l’informatique, mais dans cet article, vous ne parlez à aucun moment du code, alors que c’est la racine du GreenIT !

Coder pour la performance dès le début est extraordinairement important, car cela influe sur tous les niveaux de la chaîne :

image

Il en va de même pour ces nouvelles approches architecturelles : avant de déployer des solutions qui empêchent toute conscience par un utilisateur de l’impact de ses actions, il convient de se poser la question si des approches plus légères ne seraient pas suffisantes, quitte à ce que l’utilisateur final patiente un peu, affine ses analyses avant de les faire tourner. Bref, l’aider à avoir un comportement plus écologiquement responsable.

Partager sur Viadeo


Tags: , , ,

Commentaires

Bonjour,

Pour nuancer vos propos, je tenais à souligner que de plus en plus de DSI mettent en place des offres de service à l’intérieur de leur entreprise. Elles se positionnent en tant que fournisseur. Un des objectifs est justement de rationaliser les demandes et d’afficher dans un premier temps l’impact aux utilisateurs. L’impact financier certes mais certaines entreprises évoluées prennent en compte d’autres indiquateurs métiers pour déterminer quels sont les services demandés qui offrent réellement un bénéfice à l’entreprise.

Lorsque ces services sont refacturés en interne, les premiers effets se font généralement sentir sur la messagerie. Quand le coût est masqué, tous les utilisateur veulent au moins 500 Mo à 2 Go pour stocker leurs mails. Quand la DSI apporte la facture de l’infrastructure requise (serveurs, disque, sauvegarde, électricité, clim, maintenance, etc.) les utilisateurs se rendent finalement compte que 200 Mo est suffisant.

Amener de la transparence est donc effectivement bénéfique à tous points de vue.

Anonyme (non vérifié) le 02/03/2012

Ayant enseigné l’informatique pendant quelques années, j’ai pu constaté chez les étudiants de BTS info, un réflexe qui m’a paru étrange au départ.
Quand ils avaient à enregistrer des données locales simples, ils utilisaient systématiquement une base de donnée tierce plutôt que d’enregistrer directement dans un fichier.
Certains de mes collègues estimaient que le concept de fichier n’était pas au programme.

Anonyme (non vérifié) le 05/03/2012

@Anonyme1 : Merci pour cet exemple sur la refacturation du service (messagerie). C’est effectivement tout l’intérêt de la refacturation. Mais est-il nécessaire de mettre en oeuvre un nuage informatique pour cela ?

Pour rappel, un nuage informatique (privé ou public) est une infrastructure physiques (serveurs, etc.) qu’on abstraie au travers d’une interface de programmation (API). Ainsi, quand on utilise S3 d’Amazon on utilise un langage particulier pour stocker et lire un fichier en lieu et place d’instructions “physiques”.

admin le 05/03/2012

Une solution actuellement envisagée sérieusement par la Commission européenne pour limiter le gaspillage des ressources, notamment énergétiques, par le secteur des TIC : la voie réglementaire.

Le secteur automobile connaît bien ce cliquet impitoyable : chaque année les moteurs doivent émettre moins de gaz à effet de serre sinon ils ne peuvent pas être vendus dans l’UE ! Simple et extrêmement efficace pour stimuler l’innovation intelligente…

Évidemment, il y a des résistances à généraliser cela aux TIC : lire l’article complet sur Euractiv.

David Bourguignon (non vérifié) le 07/03/2012

@David : et pourtant cela serait, effectivement, tellement efficace ! Merci pour le lien.

admin le 07/03/2012

@admin : La Commission européenne est connue pour sa ténacité en matière réglementaire. Rien à voir avec nos papillonnages nationaux… :-) Et comme le réseau électrique européen a frisé début février sa première grande crise de surconsommation, je pense que cela va arriver bien plus tôt que prévu… Ce ne sera d’ailleurs pas limité à l’industrie des TIC. Les fabricants de télés qui surconsomment et autres bidules indispensables-depuis-cinq-ans ont aussi du souci à se faire ! :-)

David Bourguignon (non vérifié) le 08/03/2012

C bien le problème. la conjonction des équipements électroniques et électriques. De plus en plus d’équipement = de plus en plus de consommation. Concernant les ordinateurs, j’avais déjà répondu sur un des articles que mon foyer avait quatre ordinateurs de table, j’ai tout changé en portables et même en tablette pour certain qui ne fait que de la messagerie et visite des sites. Mes enfants jeux, internet et autres. Devrais-je supprimer les ordo a mes enfants, alors, qu’en plus, on leur demande de plus en plus a l’école de travailler avec.

De plus, quand je vois ce qui est installé comme add-on parfois invisible surement consommateur car exécuter a intervalle régulier de manière inutile, nous sommes loin de l’optimisation logiciel a ce jour.

Est-ce que le Cloud et BigData va changer quelque chose? Peut être que les entreprises on une maitrise de ce type d’élément, mais je doute. Le kit n’est surement pas complet. Il faudrait aussi avoir des outils d’analyse de consommation sur chaque poste, consolidant le tout vers un serveur de rapport pour bien visualiser la consommation réelle. Mais cela demande des moyens. J’ai travaillé pour des sociétés qui pour des raisons de répartition de cout, donc effectivement de facturation, avaient mis en place le relevé de temps CPU par des outils de supervision et uniquement sur les serveurs. Peut être un premier moyen pour évaluer la consommation énergétique logicielle.

Est-ce la consommation des entreprises est plus gourmande que celle des foyers possédant des équipements de plus en plus nombreux a la maison. Du coup les foyers ne sont ils pas une source de consommation aussi importante voir plus importante que les entreprises.

L’optimisation logiciel c’est difficile, j’en sais quelque chose, je suis de la partie, surtout quand c fait par de gens qui ne sont pas formés pour. Le développement custom (sans réutilisation systématique) dont le pourcentage reste encore important, est un autre problème. Le Cloud peut être effectivement une solution, mais pas en l’état des choses, le cloud est une chose, le développement logicielle en est une autre. Selon le niveau de Cloud utilisé XaaS le problème subsiste. Par exemple, le pourcentage PaaS étant plus important aujourd’hui que le SaaS. Un Cloud PaaS avec des logiciels systématiquement customs, cela laisse envisager le risque consommation inutile des logiciels.

Le seul remède, développer pour ne plus développer et introduire systématiquement des règles de dev qui n’existent pas encore même dans les sociétés de développement logiciels. Les manières, les pratiques, les moyens doivent encore radicalement évoluer et espérer changer de vision, d’approche.

Encore une fois les forces s’additionnes, mais jamais ne fusionne.

Je rebondi sur la petite phrase d’Oliver concernant l’outil. C évidant, l’outil n’est que l’outil. L’outil devient utile et intelligent que lorsque l’individu est intelligent à son emploi. Je ne sais pas si cela était intentionnel, mais ce que dit Olivier a propos de l’outil est capital et les exemples sont légions sur l’inintelligence de l’emploi de l’outil. Mais aussi, l’individu doit mettre encore plus d’intelligence dans les outils qu’il produit. Et c valable pour l’équilibre difficile a trouver entre les mode de développement de TIC et l’impact énergétique induit.

Les limites technologiques sont essentiellement du a la limite de l’intelligence, ces limites sont repoussées de jours en jours mais pas a la bonne vitesse, le déséquilibre vient de la précédance inversée des priorités des individus à obtenir quelque chose avant de ce préoccuper des impacts. Nous fonctionnons comme cela depuis l’air industrielle, qu’est qui ferait que cela change pour notre air électronique et ensuite?

C’est dommage d’en arriver toujours a une législation pour limiter la casse qui est déjà généralement bien en place. Et pour quoi et pour qui exactement, le problème est tellement vaste.

Est-ce que tout pourra être mis en Cloud? Et si oui de quelle manière?

Boris (non vérifié) le 11/03/2012

Poster un nouveau commentaire

Le contenu de ce champ ne sera pas montré publiquement.