Monitorer, c’est important pour diminuer sa consommation de ressources

Depuis quelques années, je me suis investie personnellement dans une démarche de réduction de mon empreinte environnementale. Mon ambition est de porter la même attention à mon impact professionnel, en tant que développeuse.

Quand je suis arrivée chez Adeo / Leroy Merlin en 2020, j’ai tout de suite rejoint un petit groupe de motivés qui partageaient cette même ambition, et nous avons monté ensemble un atelier régulier pour proposer des initiatives dans le but de réduire l’empreinte des services que nous développions. Une tâche assez difficile en réalité, car très peu de professionnels de l’informatique sont sensibilisés à cette problématique aujourd’hui.

Parmi toutes les initiatives que nous avons portées, la plus ambitieuse a été de mettre en place un OKR (Objective and Key Results) sur la consommation de ressources de notre domaine : toutes les équipes étaient challengées pour ajuster la taille de leurs serveurs chez notre hébergeur cloud GCP (Google Cloud Platform). Cela concerne les services travaillant sur Opus, la solution de merchandising pour le site Leroy Merlin. Je fais personnellement partie de l’équipe Search, responsable du moteur de recherche du site.

Bénéfices attendus

Quel est l’intérêt de monitorer notre consommation ? Pourquoi réduire la taille des serveurs dans le cloud ? Quels bénéfices cela apportera-t-il ?

Dans le secteur numérique, les data centers représentent environ 15% des émissions de gaz à effet de serre (source p.14), dont la majeure partie est liée à notre utilisation. Il n’est donc pas négligeable de réduire notre consommation cloud. En la monitorant, il est possible de suivre son évolution dans le temps et de se rendre compte si celle-ci augmente. L’intérêt d’ajuster la taille, c’est aussi de limiter la croissance possible des services. On peut évidemment remonter le niveau demandé si besoin, mais il faut idéalement se poser la question suivante : est-ce normal que je doive augmenter la taille de mes serveurs ? Pourquoi ma consommation a-t-elle augmenté ?

Plus nous prendrons le réflexe de surveiller, moins nous aurons tendance à surconsommer quand nous pouvons l’éviter. D’autant plus que la facturation se fait sur les ressources allouées, c’est donc aussi un moyen de faire des économies de frais sur nos serveurs, qui est bénéfique financièrement.

Première étape : les préconisations

Il a d’abord fallu qu’on se pose certaines questions : qu’est-ce qu’une utilisation optimale d’un serveur ? Nos services sont déployés sur le cloud pour profiter de l’auto-scaling, c’est-à-dire la capacité à répliquer le service pour tenir la charge. Le but n’est pas d’utiliser 100% du CPU ou de la mémoire de la machine, il faut conserver une marge pour scaler sereinement en cas de pic de trafic, car nous devons conserver la latence la plus faible possible.

Nos services sont écrits en NodeJS, dont la consommation en CPU varie plus fortement que la consommation de mémoire. Nous avons donc opté pour les niveaux optimums suivants :

Cela signifie concrètement que nos services, lorsqu’ils tournent au quotidien, seront bien ajustés si la consommation de CPU tourne autour de 60% et celle de la mémoire autour de 80%. On conserve des deux côtés une marge de sécurité pour la scalabilité.

Pour schématiser, si on représente en rouge la consommation réelle de notre service et en gris la machine qui est réservée pour faire tourner le service, alors le but est bien d’ajuster la machine réservée pour qu’elle corresponde à nos besoins réels :

Attention, il ne s’agit pas d’augmenter notre consommation, ici les deux cercles rouges font la même taille. C’est seulement le cercle gris qui diminue, donc c’est seulement la quantité de ressources allouées qui évolue.

Deuxième étape : le dashboard

Une fois les préconisations faites, nous nous sommes chargés de fournir un dashboard dans Datadog pour que les équipes puissent connaître leur consommation actuelle de CPU et mémoire, et sachent quelles actions mettre en place pour ajuster les machines dans GCP. C’est mon collègue ops Sylvain Lefranc qui s’en est chargé.

Dans ce dashboard, nous calculons un score sur 100 qui correspond à la consommation actuelle sur celle demandée, avec un score maximal sur les niveaux préconisés. Pour faciliter la compréhension, nous avons décidé de mettre des notes de A à E pour le CPU et pour la mémoire, et d’en faire une moyenne pour obtenir une note globale du service.

L’OKR pour les équipes consistait à monter sa note globale à un minimum de C pour tous les services associés à un périmètre. Nous l’avons appelé “Score Back” pour le différencier d’un autre OKR spécifique au Front (mais qui ne sera pas abordé ici).

Voici les résultats des périmètres pour mars 2022, au moment où nous commencions à avoir des données, par équipe et pour tous les environnements :

Nous avons fait adopter cet OKR au sein du domaine, et l’avons annoncé aux équipes concernées. Nous avons fait plusieurs communications à ce sujet, et les réactions étaient plutôt positives et enthousiastes, d’autant plus qu’on fournissait les outils nécessaires pour monitorer et que l’équipe d’ops du projet se tenait disponible pour accompagner et aider les équipes.

Troisième étape : le travail des équipes

Chaque équipe a donc pris le sujet de son côté, j’ai moi-même mis cela en place sur les produits dans mon périmètre. Voici le dashboard que nous avons à disposition. Une fois qu’on a sélectionné son périmètre et le(s) environnement(s) concerné(s), on obtient le score global, le score pour le CPU et celui pour la mémoire. Le score global est la moyenne des deux autres. Nous avions donc initialement une note de D en avril 2022.

En termes de temps consacré à cette tâche, j’ai personnellement effectué ce travail sur 4 services, et il m’a fallu environ une journée pour modifier les valeurs et vérifier à chaque fois le comportement des serveurs dans le temps, et deux heures en commun avec un autre collègue.

Il était important de jouer nos tests de performance avec cette nouvelle configuration pour vérifier que le service tiendra la charge sans latence supplémentaire, ce qui est bien le cas pour nous.

Voici notre score de périmètre à l’heure actuelle :

Comme vous pouvez le voir, nous sommes passés de D à A ! Niveau mémoire, nous tournons bien autour des 80%, ce qui était l’objectif. Par contre niveau CPU, nous ne sommes pas à 60%, et nous ne pourrons pas vraiment faire mieux : certains de nos services sont si peu consommateurs que les réduire davantage en ferait des services sous-taillés qui scalent au moindre appel ! Si on diminue la taille mais qu’on augmente le nombre de pods, c’est contre-productif en termes d’impact au final car on va multiplier une taille plus faible par un nombre plus important de services, et potentiellement allouer encore plus de ressources qu’avant !

Heureusement, nous affichons aussi dans le dashboard le nombre de pods et la latence, pour vérifier la tendance dans le temps. Elle doit être la même qu’avant le resizing, ce qui est le cas chez nous.

Voici les notes globales des équipes du domaine en octobre 2022 :

Sur le domaine global, nous avons gagné seulement 1 point et sommes encore en D. Mais quand on y regarde de plus près, certaines équipes ont fait des progrès très impressionnants ! Notamment une équipe qui est passée de 19 à 79 ! Mais certaines équipes n’ont pas participé, et leurs notes se sont même dégradées pour certaines. On est loin de respecter notre OKR qui était de passer toutes les équipes en C minimum.

Pour ceux qui se demandent pourquoi mon périmètre (Opus Search) n’a pas un A comme sur mon dashboard, c’est parce que nous sommes divisés en deux produits, et que je n’interviens que sur un seul des deux. Or le deuxième produit a un score de D qui fait grandement descendre notre moyenne. Il y a donc encore du travail à faire pour une partie de mon équipe ! Car ça ne doit pas être un acte ponctuel, mais une habitude à prendre et une surveillance qui se met en place dans le temps.

Malgré tout, notre grande fierté a été de voir des équipes qui ne faisaient pas partie de notre atelier et qui pourtant ont été convaincus par la démarche ! Ils se sont montrés moteurs et ont bien contribué sur leurs services.

Conclusion

Il est très dur de motiver des collègues (qu’ils soient développeurs, ops ou PO) à travailler et passer du temps sur ce sujet quand ils n’ont pas été préalablement sensibilisés à la question environnementale. J’ai donc pris conscience qu’avant de mettre en place des actions concrètes comme celles-ci, il faut d’abord préparer le terrain et sensibiliser les collègues.

C’est pourquoi j’ai décidé de monter chez SFEIR une communauté autour du Numérique Responsable, pour transmettre une autre vision de l’informatique, qui soit soutenable dans le temps. À l’heure où tous les secteurs doivent faire un effort pour diminuer leur impact, le numérique est au contraire en progression exponentielle, alors qu’il pourrait largement contribuer à réduire les émissions de gaz à effet de serre à hauteur de 20% (source GIEC p.196 et source GeSI). A nous de nous investir pour cette cause !

Je remercie aussi particulièrement Sylvain Lefranc, Etienne Adriansen et tous les collègues d’Adeo / Leroy Merlin qui ont participé avec moi à cette initiative !