La consommation totale en Energie, par exemple, pour une chaine web est la somme de toutes les énergies mesurées sur le client, le serveur et la base de données : E1 + E2 + E3 

Il en est de même pour le stockage : S1 + S2 + S3, et le transfert réseau : T1 + T2 + T3 + T4 

Ok, maintenant, comment on s’y prend t’on pour mesurer tout ça ? Nous avons décidé d’utiliser Selenium (https://www.selenium.dev/) pour pouvoir reproduire des scénarios utilisateurs d’application. Le scénario est enregistré une première fois puis rejoué autant de fois que nécessaire afin d’avoir une mesure « stable ». 

Sur cette base, nous sommes maintenant capables d’effectuer une mesure sur toute une chaine web et d’effectuer un différentiel entre deux architectures sur le même scénario utilisateur. 

Une refonte ? Juste pour le fun… 

Il ne reste plus qu’à choisir une évolution d’architecture à tester. Et bon timing : un projet interne visait la refonte d’une application. Nous avons pris tout ce qui est à la mode pour booster l’application :   

• Interface simplifiée pour les utilisateurs 
• Changement de technologie PHP vers Rust 
• Passage en architecture micro-service pour faciliter l’exploitation et l’évolution du logiciel 

V1 = Architecture monolithique php / mysql + client firefox 

V2 = Architecture micro-services Rust (choix d’architecture et technos) + client firefox 

Quelques hypothèses pour encadrer les tests 

Nous avons effectué les tests sur un périmètre fonctionnel identique entre la V1 et la V2. L’idée est de se concentrer sur les composants techniques du logiciel. La part de challenge des besoins étant géré en amont, nous avons choisi de faire ces tests sur les scénarios utilisateurs critiques, c’est à dire sur les scénarios que nous ne pouvons pas enlever. Afin de séparer les différents composants micro-services, nous avons opté pour un support de conteneur : Docker.  

Mode opératoire  

La première étape des opérations est de déployer ETSDiff sur un environnement de test dédié : Sur une machine physique de test OS Debian, processeur Intel compatible avec PowerAPI (https://powerapi.org/).  

Une fois l’outil en place, les dockers de la version monolithique ont été déployé afin d’effectuer les tests.  

Après un nettoyage des éléments de la version monolithique, nous avons déployé la version micro-services puis lancé les tests 

Chaque test s’effectue de la manière suivante :  

Le scénario utilisateur est exécuté 20 fois afin d’avoir une moyenne de mesure représentative.  

A chaque exécution une mesure d’Energie, Transfert et Stockage est effectuée sur l’ensemble du scénario utilisateur.  

Une fois le scénario complété, ETSDiff prend soin de nettoyer l’espace de stockage, s’assure de la fin du processus et nettoie les services (caches, MDF bdd…).  

Finalement la moyenne des 20 exécutions est calculée. 

Résultats en image : 

Résultats de l’analyse différentielle (Energie en Joules, Transfert et Stockage en Octet) 

Que peut-on tirer de ces résultats ?  

On remarque que le passage de PHP à Rust a un impact non négligeable sur la consommation énergétique… Pourquoi ? Rust (https://www.rust-lang.org/) est un langage compilé et donc très proche du processeur. Nous n’avons pas choisi ce langage au hasard. Rust est aujourd’hui une technologie en plein essor et une étude de 2017 met en avant son efficacité énergétique : https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf) comparé à PHP. 

Le passage du monolithique au Micro-service a également un impact significatif sur le transfert réseau. C’est a priori logique, car les échanges de données initialement internes sont maintenant externalisés passant d’un micro-service à un autre. 

On peut donc imaginer que, dans un Datacenter, si les micro-services sont dispatchés sur un ensemble de serveurs séparés physiquement, cela risque d’exercer une forte influence sur la consommation énergétique (matériel réseau, consommation CPU…). Dans le cas d’une offre Cloud Public mutualisée, il est impossible d’avoir la maitrise sur le positionnement de chaque service. On peut donc imaginer que le passage en architecture micro-service sur un Cloud Public a un impact négatif sur l’architecture en termes de consommation énergétique. 

La suite : Un test c’est bien, mais plusieurs c’est mieux !  

Maintenant que nous avons une vision plus large que la simple consommation énergétique pour une architecture applicative, nous souhaitons effectuer plus de tests ! Pour cela nous travaillons au développement d’une plateforme permettant une mesure plus précise, service par service :  

Grâce à cette plateforme, nous allons pouvoir valider les pratiques d’éco-conception des référentiels existant de manière industrielle comme celles du RGESN, 115 bonnes pratiques d’éco-conception, etc., mais également tester toute hypothèse « eco-friendly ». 

Conclusion 

Nous avons pu montrer l’intérêt de mesurer 3 indicateurs (Energie, Transfert et Stockage) sur un cas de refonte réelle d’une application Monolithique vers une application Micro-service. L’impact se montre réel lors d’une mise en application de cette refonte dans un contexte Cloud, là où des échanges de données entre micro-services ne sont pas nécessairement sur le même hôte physique. Afin de continuer ce type d’expérimentation, l’objectif est de créer une plateforme plus industrialisée pour tester tout type d’architecture applicative et en tirer le meilleur.  

Ces tests ont évidemment un coût. Dans notre cas, nous avons testé les deux architectures et les avons donc developpé. Le but étant de créer de la donnée et de l’expérience pour en sortir des pratiques, ou tester des pratiques existantes. Cependant on peut réellement se poser la question du coût de « build » versus le gain en « run ».  

Si nous devons mobiliser 1 an de projet, une équipe de 10 développeurs Rust pour refondre un applicatif et gagner quelques Watts en run, il faut se demander quel est le ROI (Retour sur investissement) carbone sur le projet. C’est-à-dire, combien de temps minimum mon application doit fonctionner, pour amortir mon coût carbone sur la refonte et commencer à voir un bénéfice. A l’allure à laquelle les applications deviennent obsolètes, la question semble légitime.  

Pour le moment, concentrons-nous sur la constitution de référentiels et la validation de pratique d’éco-conception par la mesure. L’impact sera bien plus conséquent ! 

Jules DELECOUR & Vincent CAGNARD