La mesure pour révéler l'impact caché du numérique sur le climat et ouvrir la voie à une action éclairée

Introduction: La mesure comme boussole

Dans un monde où les nouvelles alarmantes sur le changement climatique sont monnaie courante, le dernier rapport du GIEC offre une perspective encore plus sombre. Il prédit une possible augmentation de la température mondiale de +5°C d'ici 2100, par rapport à l'ère pré-industrielle, et menace d'intensifier les canicules, inondations et sécheresses, avec des répercussions profondes sur notre écosystème et société. Ces perturbations sont principalement provoquées par l'activité humaine (cf: anthropocène), et ce, notamment via la consommation d'énergies fossiles. Il est important de souligner que le coupable n'est pas uniquement le bâtiment, le transport ou l'agriculture - le numérique fait également partie de l'équation.

Tout en étant une source notable d'émissions de carbone, le secteur numérique est également un domaine clé où des changements significatifs pourraient avoir un impact positif. En raison de sa présence ubiquitaire dans notre société, il offre de nombreuses possibilités pour réduire notre empreinte carbone globale en permettant de modéliser, mutualiser, pour offrir davantage d’efficience à nos systèmes. Malgré une contribution apparemment minime, le secteur numérique connaît une croissance rapide, et pourrait atteindre 6,7% de l'empreinte carbone d'ici 2040. Mais au-delà des chiffres, il y a des défis plus complexes et insidieux à relever. L'innovation technologique peut avoir un effet rebond désastreux et le postulat de Khazzoom-Brookes s'applique particulièrement bien dans ce contexte, soulignant comment l'augmentation de l'utilisation d'une technologie peut avoir des répercussions sur d'autres technologies avec la notion de croissance partagée. (De nouvelles antennes pour supporter les débits liés à la 5G, de nouvelles infrastructures pour l’IPV6 dûes à la prolifération des terminaux…)
La quantification de l'empreinte carbone du numérique n'est pas une tâche facile. Elle nécessite une approche rigoureuse et scientifique, une communication transparente des entreprises et une unité de mesure précise et parlante : le CO2eq.
Cela correspond à l'émission exprimée en équivalent dioxyde de carbone (CO2eq). Cette mesure standardise le potentiel de réchauffement global (PRG) de différents gaz à effet de serre (GES) à celui du dioxyde de carbone. En d'autres termes, elle indique la quantité spécifique d'un gaz donné qui aurait un impact équivalent à une tonne de CO2 libéré dans l'atmosphère.

Source : 4e rapport du GIEC de 2007 - valeurs de référence actuelles

Pour des raisons de manque de ressources et de temps, nous avons décidé de recadrer le sujet de ce stage spécifiquement aux émissions en CO2eq d'un terminal lors de la phase d'utilisation. Puisque notre intensité carbone ne changera pas tout au long des expérimentations, nous pouvons le rapprocher de la consommation énergétique du scope 2. Pour la suite de cette étude, nous expérimentons sur un portable Dell Latitude 7520 avec une distribution Ubuntu 20.04.

Aujourd’hui, de nombreux outils veulent aider le consommateur à connaître la consommation électrique de son ordinateur comme EcoIndex, Scaphandre ou encore Website Carbon. De la démarche à l’implémentation, ces logiciels sont critiquables et il est nécessaire de connaître leurs forces et faiblesses dans un contexte donné pour pouvoir réellement surveiller sa consommation en minimisant les biais. Dans cet article, nous explorerons les enjeux et défis de la mesure.

Disclaimer : Les informations présentées dans cet article portent spécifiquement sur l'impact caché du numérique lié à la consommation électrique. Nous souhaitons souligner que cet article ne traite pas de manière exhaustive de l'ensemble du système d'information et des divers aspects connexes tels que les effets rebonds, l'obsolescence sous toutes ses formes (technique, fonctionnelle, indirecte, programmée…), et d'autres facteurs. Ce sujet étant un domaine vaste et en constante évolution, nous vous invitons à faire preuve de discernement et à considérer différentes sources d'information pour vous forger une opinion éclairée sur cette question complexe. Les opinions exprimées dans cet article sont celles des auteur·e·s et ne représentent pas nécessairement celles de l'ensemble de la communauté scientifique ou des acteur·rice·s de l'industrie du numérique travaillant sur ce sujet.

Partie 1: Notre approche empirique pour mesurer la consommation énergétique des terminaux numériques

Quelle est la consommation énergétique de mon système lors de mes développements ? Quels composants de mon application sont les plus énergivores ? Comment puis-je optimiser mon code pour réduire la consommation énergétique de mon application ?

Lorsque l’on aborde les sujets liés à l’éco-conception, les développeurs se posent souvent ces questions essentielles sans trouver de réponses adéquates ou d'outils fiables en ligne. Les ressources existantes, souvent limitées à la surveillance de la consommation du processeur ou celles qui ne sont pas open-source, entravent notre capacité à comprendre et à valider la méthodologie derrière les calculs de consommation. De plus, le manque d'informations détaillées sur la consommation énergétique des divers éléments d’une application rend l'analyse encore plus complexe.
Il nous paraissait indispensable de commencer par expérimenter et comprendre la mesure de consommation énergétique à l'échelle d'un poste de développeur. Cela permet d'établir une méthodologie réplicable, d’identifier les difficultés, les biais liés à la mesure pour généraliser une démarche à plus grande échelle avec une variété d'autres outils et systèmes (interface IPMI, sondes logicielles…)

Dans ce contexte, nous avons conçu notre étude dans le but de mener une expérimentation rigoureuse pour estimer précisément la consommation énergétique de notre terminal. Cette donnée servira de point de référence pour comparer les résultats obtenus avec d'autres outils de mesure disponibles sur le marché, notamment pour questionner et interpréter les mesures logicielles.

La première phase de notre processus implique l'utilisation d'un wattmètre. En branchant simplement le terminal au wattmètre, qui est lui-même connecté à une prise de courant, nous pouvons obtenir une lecture en temps réel de la puissance consommée par le terminal. Cependant, cette approche ne nous permet pas d'accéder et d'analyser ces données de manière plus approfondie.

Pour cela, nous avons recours à une étape plus avancée, en utilisant une carte électronique équipée d’un microcontrôleur associé à un compteur énergétique qui permet de déterminer la tension alternative, le courant, la fréquence, le facteur de puissance ainsi que l’énergie active. Dans le cadre de notre expérimentation, nous utilisons une carte Adafruit Metro M4 et module PZEM-004T-100A. Le dispositif Adafruit est connecté au terminal via USB, et le PZEM est installé en dérivation avec une pince ampèremétrique en série. Grâce à un programme spécifiquement conçu pour microcontrôleur Atmega via la librairie du module et un exporteur écrit en Rust, nous avons la possibilité de capturer et d'accéder aux données de consommation en temps réel (modulo la fréquence de traitement). Ces informations seront ensuite traitées et analysées à l'aide de Prometheus-Grafana, il s’agit d’une base de données timeseries et d’un outil de visualisation de ces données. Cela nous permet de visualiser et de comprendre plus précisément la consommation énergétique de notre terminal en exploitant l’outil avec différents scénarios en confrontant les courbes d’analyse.

Partie 2: Plonger dans les profondeurs de la mesure logicielle avec Scaphandre

Schéma: montage décrit précédemment.

L'exactitude et la transparence de la méthodologie associées à la mesure sont des critères essentiels lors de l'évaluation de la consommation d'énergie d'un système informatique. C'est pourquoi il est nécessaire de s'appuyer sur des outils open-source, car ils permettent non seulement de pouvoir interpréter les résultats de la mesure, mais aussi de remettre en question la véracité de l’implémentation en examinant le code…

Prenons par exemple WebsiteCarbon, un outil couramment utilisé pour estimer l'énergie consommée par un site internet. Il base son estimation sur l'idée que la consommation énergétique est proportionnelle à la taille de la page, supposant qu'1 GB consomme 1.805 kWh. Ce chiffre est toutefois dépassé, car les recherches les plus récentes suggèrent un taux plus proche de 0.0065 kWh/GB pour un poste et réseau fixe. De plus, la formule d'allocation utilisée ici peut être remise en question, car les coûts de fonctionnement des équipements réseau sont en grande partie fixes et ne dépendent pas entièrement du volume de données échangées.

Extrait: du code de Website Carbon

Sur un différent périmètre, l'outil open-source Scaphandre, développé par Hubblo, propose une approche différente et plus précise car bas niveau du suivi de la consommation d'énergie. Cet outil permet une analyse plus granulaire de la consommation en watts heure des processus d'un système informatique, en évitant d'ajouter une couche de calcul qui pourrait biaiser les résultats. Il est écrit en Rust et est également disponible en tant qu'image Docker.

Scaphandre est constitué de deux éléments principaux : les sondes qui récupèrent les métriques souhaitées, notamment via Powercap RAPL (qui peut-être également à l’origine de problèmes de sécurité), et les "exporters" qui formatent les données de sortie en fonction des besoins de l'utilisateur (stdout, json, prometheus, etc.). Bien que le Power Capping Framework soit actuellement l'outil le plus précis pour mesurer la consommation en watts par heure d'un processeur, il est limité à certains modèles (Intel/AMD) et n'est donc pas adapté à toutes les configurations.

Capture d’écran: Illustre la sortie standard de Scaphandre

Scaphandre via stdout affiche les 20 processus les plus gourmands en énergie, ainsi que la consommation totale de l'hôte. Cependant, il est important de noter que Scaphandre ne prend en compte que la consommation des processus par rapport au processeur et gpu intégré. D'autres facteurs, tels que l'utilisation des ventilateurs, l'usure de la batterie, la mémoire, le GPU, etc., peuvent également contribuer à la consommation d'énergie d'un ordinateur. Sur certaines configurations, Scaphandre peut également fournir des données sur la consommation de tout ce qui est relié à la carte mère, mais ce n'est pas le cas sur la notre.

Lorsque nous comparons les mesures de Scaphandre à celles de notre mesure physique, nous constatons que la consommation enregistrée par la mesure matérielle est deux fois supérieure à celle de Scaphandre pour utilisation faible du laptop. Il est donc crucial d'utiliser Scaphandre de manière judicieuse, en complément d'autres mesures logicielles.

Capture d’écran: Comparaison la mesure matérielle à la mesure logicielle en montrant l’ensemble des informations exportées via la carte Metro M4 et affichées dans la sortie standard par Scaphandre

Courbe: Comparaison de la mesure matérielle à la mesure logicielle via Grafana à partir des différentes sources

Ce graphique, illustrant les jobs de multi-processing lancés via OpenMP, met en évidence des problèmes potentiels liés à la disparité entre la mesure logicielle et la mesure physique. La courbe verte représente la mesure physique (PZEM), tandis que la courbe jaune indique les mesures capturées par Scaphandre.

Il est frappant de constater un écart significatif, presque quadruple, entre ces deux ensembles de données sur une utilisation cette fois accrue du laptop. Cependant, il est essentiel de noter que les tendances obtenues via Scaphandre reflètent correctement celles de la mesure physique. Ces écarts se justifient par le fait que Scaphandre ne prend en compte que le CPU et GPU intégrés.

Ainsi, même face à cette différence importante entre la mesure physique et logicielle, Scaphandre reste un outil de travail intéressant à nos yeux.

Dans quel cas l’utilisation de Scaphandre peut-elle alors se montrer judicieuse ?

Scaphandre, bien qu'il ne respecte pas nécessairement les ordres de grandeur de la mesure physique, joue un rôle crucial en mettant en évidence des tendances de surconsommation de ressources. Cet outil nous offre également la possibilité de comparer différents logiciels entre eux, fournissant ainsi des données précieuses pour optimiser la gestion de nos ressources, nous aider dans nos choix...

Tout d’abord, nous avons voulu adopter le point de vue d’un développeur qui chercherait à inclure la consommation énergétique du build dans le choix de ses technologies. Fabien Mercier de l’équipe “Growing People and Software” à Octo, hésitait entre deux frameworks de tests (Vitest et Jest) et voulait connaître celui qui consommait le moins lors de l’exécution du build. Nous avons alors lancé Scaphandre avec Grafana/Prometheus et, en parallèle, un script exécutant successivement les deux frameworks.

Schéma: Comparaison des 2 frameworks via Scaphandre

Ce que que nous pouvons remarquer sur le schéma précédent, c’est que Vitest est plus rapide et consomme en moyenne moins que Jest, mais aussi qu’une anomalie s’est introduite dans nos résultats. En effet, Scaphandre n’est pas aussi granuleux que voulu et manque parfois certaines mesures, comme ici le pic de consommation récurrent de Jest. Nous avons augmenté nos durées d'exécution minimales à plus de 15 secondes et avons répété l'expérience à plusieurs reprises pour éviter de tirer des conclusions hâtives basées sur des résultats potentiellement biaisés résultant d'une exécution isolée.

Malgré ses atouts indéniables, Scaphandre n'est pas sans limitations. Il existe un éventail de facteurs susceptibles d'influer sur la consommation énergétique de notre environnement de développement, que Scaphandre n'intègre pas nécessairement dans ses mesures. Cela soulève une question cruciale : comment pouvons-nous affiner notre mesure logicielle pour tenir compte de ces facteurs supplémentaires ?

Partie 3: Cherchons à sculpter un outil plus précis pour naviguer en eaux profondes

Afin d'approfondir notre quête de précision dans la mesure de consommation d'énergie, nous avons décidé de prendre les rênes et de concevoir notre propre instrument d'évaluation. Notre objectif ? Déterminer la consommation spécifique d’un ordinateur portable fourni par OCTO.

En reconnaissant les défis inhérents à l'open-hardware qui pose des problèmes d’accès à certaines informations du fait des drivers propriétaires associés et les insuffisances de données des fournisseurs, nous avons pris la décision délibérée de laisser derrière nous l'illusion d'un outil universel qui serait capable de fonctionner sur toutes les configurations possibles. À la place, nous avons choisi une approche ciblée, visant à développer une solution spécifique à notre configuration, nous permettant, harponné à la mesure physique, de naviguer avec confiance dans des eaux plus profondes que Scaphandre.

Le CPU

L’objectif ici est de calculer la consommation du CPU+GPU intégré sans la sonde RAPL. Pour calculer la consommation du CPU sans se servir d’outils spécifiques, on va chercher à se rapprocher de la TDP, soit l’enveloppe thermique. La TDP représente la dissipation thermique maximale du composant, exprimée en watts. Sur les processeurs Intel, “la confusion est totale” entre consommation et TDP. Grâce aux données fournisseurs, et des études en ligne, on obtient une équivalence fréquence→consommation :

On essaie ensuite de créer une fonction à partir de ces données grâce au site dcode. On rentre notre tableau et on procède à un ajustement par hyperbole pour obtenir l’équation :

Tel que x est la fréquence du CPU en temps réel, qu’on obtiendra grâce à la librairie cpufreq-utils.

Lorsqu’on compare notre calcul avec les données de Scaphandre, ça match plutôt bien (en vert notre mesure, en jaune celle de Scaphandre sur un entrainement de modèle).

Le DISK

Le disque du laptop est un SSD NVMe. Avec beaucoup de cross-sourcing, on remarque que la consommation du disque dépend de l’écriture et de la lecture. Elle dépend d’autres facteurs comme le mode d’écriture (random, sequential) ou encore la place disponible sur le disque, mais nous ne prendrons pas en compte ces facteurs car la différence est mal étudiée et difficile à inclure dans le calcul.

Notre démarche est la suivante : on applique un coût fixe qui sera la consommation idle du disque, puis on fait varier cette consommation par rapport à l’écriture et à la lecture. Grâce à cette ressource, on obtient la vitesse maximale du disque. Puis, ce benchmark et cette étude nous fournissent des équivalences entre la vitesse maximale de RW et la consommation du disque. Impossible de trouver des valeurs plus précises côté fournisseurs.

On obtient alors ce tableau d'équivalence :

On en tire l'équation:

idle + (current_read / max_read) * (conso_max_read - idle) + (current_write / max_write) * (conso_max_write - idle)

L’écriture et la lecture en temps réel sont fournies par le paquet iotop.

La RAM

Pour la RAM, nous pensions pouvoir utiliser la même démarche. Malheureusement, il n’y a pas d’outils performants disponibles sur notre machine pour avoir l’utilisation de la RAM en temps réel. Je ne peux donc pas faire varier cette valeur et c’est pour cela que nous appliquerons un coût fixe.

Grâce à l'étude de Micron Technology, nous trouvons l'équivalence 8GO de RAM DDR4 = 0,4W. L’ordinateur portable dispose de 32GO de RAM, ce qui équivaut à 1,6W en coût fixe.

En combinant nos trois mesures (CPU, disque et RAM), on parvient à ce résultat :

Cette mesure est plus proche de celle de Scaphandre, dans les tendances et dans l'ordre de grandeur. Néanmoins sa mise en place est bien plus compliquée puisqu’elle demande une adaptation pour chaque composant et un travail de recherche. On observe toujours une différence par rapport à la mesure PZEM qui peut être expliquée par de nombreux facteurs : système de refroidissement, perte de la batterie, ports, clavier, écran et même surévaluation du montage PZEM.

Conclusion

À l'heure actuelle, la quête d'une solution logicielle offrant une mesure précise de la consommation énergétique globale d'un système reste un défi. Toutefois, il est essentiel de reconnaître que chaque environnement nécessite une approche adaptée. Prenons par exemple Scaphandre, qui semble adapté à un contexte de développement pour les phases de build, ou pour une entreprise désireuse de surveiller la variation de la consommation CPU de leurs serveurs on-premise sur une période donnée.

La question fondamentale réside dans ce que nous mesurons. La consommation énergétique d'un système IoT peut sembler insignifiante lorsqu'elle est prise individuellement, mais la prolifération de ces dispositifs pourrait entraîner une production massive de composants, offrant une puissance de calcul moins importante que celle que l'on pourrait obtenir avec des baies en datacenter. Ces dernières, malgré une consommation énergétique élevée, peuvent rendre un service qui, rapporté à l'utilisateur, donne une consommation énergétique relativement faible. La notion d'efficience, qui n'a pas été traitée dans cet article, est étroitement liée à ces choix de conception. Elle permet d'évaluer la capacité du système à accomplir un certain nombre de tâches pour atteindre un objectif, en rapport avec la quantité de ressources consommées.

Le contexte est donc essentiel dans la mesure de l'efficience énergétique, ce qui souligne l'importance de la transparence dans nos protocoles de mesure. La présentation claire et explicite de la méthodologie qui justifie nos résultats nous permet non seulement de mieux comprendre nos systèmes, mais également de favoriser le partage de connaissances et d'expertises. C'est une étape nécessaire dans notre démarche collective vers une informatique plus durable.

Dans l'optique d'une compréhension encore plus approfondie de notre impact environnemental, l'élaboration d'une méthode de calcul multicritères serait un pas intéressant à franchir. Cette méthode, en plus de mesurer la consommation énergétique, pourrait également évaluer d'autres conséquences écologiques telles que la pollution de l'eau et du sol, l'utilisation des ressources abiotiques, et la consommation d'eau.

Il est indéniable que l'impact énergétique de nos systèmes d'information s'impose aujourd'hui comme une préoccupation de premier plan. Cette prise de conscience est déjà en soi un progrès significatif. Malgré les avancées technologiques majeures, nous devons interroger la complexité des systèmes qui nous permettent d'atteindre des niveaux d'efficience élevés, souvent au détriment de la résilience de nos systèmes. Une perspective plus orientée vers la sobriété, moins centrée sur la technologie, pourrait être une alternative viable pour minimiser l'impact du numérique (pour plus d'informations, voir l’article: https://blog.octo.com/pour-en-finir-avec-la-loi-de-moore/).

Il est clair que le défi de l'évaluation précise de la consommation énergétique totale d'un système persiste. Le manque de standardisation dans les méthodes de mesure risque de freiner l'établissement de régulations qui pourraient aider à modérer l'impact environnemental du secteur technologique. Il est donc essentiel de créer une connivence sur ce sujet au sein des équipes en continuant à développer et à affiner nos outils et méthodes d'évaluation, pour faire face à ce défi.

Remerciements

Armen Ozcelik, Alaric Rougnon-glasson, Sonny Klotz