Nettoyage de données : nos bonnes pratiques pour les développeurs

Nettoyage-données-développeur

Dans le quotidien d’un développeur, la manipulation de données est omniprésente, qu’elle soit locale à son poste de travail ou sur des serveurs distants. Toutefois, sa consommation de données impacte directement son empreinte numérique et donc son empreinte carbone. C’est pourquoi nous avons cette année contribué au Cyber World Clean Up Day, en sensibilisant nos collègues et en partageant avec eux des bonnes pratiques à mettre en place.
Aujourd’hui, nous vous proposons de découvrir et d’acquérir à votre tour ces bons réflexes (si ce n’est pas déjà fait) pour diminuer à terme votre consommation de données !

Environnements virtualisés

Que ce soit sur un cloud public ou sur une infrastructure on-premise, un développeur est la plupart du temps amené à créer des environnements virtualisés (ou à en demander la création) afin de tester son code et ses déploiements.

Obsolescence

Une fois un projet de développement terminé et clôturé, il est fréquent de constater que les environnements associés existent toujours et qu’ils sont encore en cours d’exécution, et ce même après plusieurs mois voire années !

Un environnement en cours d’exécution consomme continuellement de l’énergie. En conséquence, cette situation peut se résumer grossièrement au cercle vicieux suivant : qui dit consommation d’énergie/électricité dit chauffe, et donc nécessite un refroidissement plus important, ce qui résulte à une surconsommation du système de refroidissement, et donc à une hausse indirecte mais supplémentaire d’énergie.

Quant à un environnement au repos (donc stoppé mais toujours existant physiquement sur l’infrastructure), il consomme tout de même des ressources, et plus précisément :

  • Espace disque : il reste occupé et réservé, ce qui peut résulter pour d’autres projets actifs à des extensions inutiles de stockage sur les serveurs, ce qui a un coût (le prix et les caractéristiques d’un disque dur de serveur sont très différents de ceux que vous pouvez trouver sur votre machine !)
  • CPU et de RAM : ils ne sont pas réellement consommés au repos, mais en fonction des infrastructures ils sont la plupart de temps « réservés », ce qui revient au final à bloquer ces ressources pour d’autres projets actifs

Gestion des snapshots

Les snapshots sont très utiles mais ils sont aussi très consommateurs d’espace disque. Afin de ne pas démultiplier l’espace consommé, il est important de penser à les supprimer lorsqu’ils ne sont plus nécessaires, ou d’en demander la suppression si cette action est réservée à l’équipe IT.

Type de disque VMware

Sur une plateforme VMware, lorsque l’on crée une machine virtuelle, on peut spécifier le type de disque, à savoir :

  • Thin provision : ne consomme physiquement que ce qui est nécessaire mais rend les écritures plus lentes
  • Thick Provision Eager Zeroed : préparation du disque entier, consomme tout l’espace mais permet d’obtenir de meilleures performances en écriture
  • Thick Provision Lazy Zeroed : préparation d’une partie du disque, consomme l’espace au fur et à mesure mais des performances correctes

La solution “Thick Provision Lazy Zeroed” est le meilleur compromis entre économie d’espace disque et performances. Toutefois, pour des besoins de très hautes performances d’écriture (exemple : bases de données en production), le type « Thick Provision Eager Zeroed » reste le plus efficace.

Taille des disques

Lors de la création de l’environnement virtualisé, il est nécessaire de bien évaluer l’espace disque qui sera nécessaire, en comptant la partie système d’exploitation + toutes les autres données.

Il ne faut pas prévoir trop de marge, car d’un point de vue infrastructure il sera plus simple d’augmenter un disque au besoin, que de le réduire (ce qui n’est pas du tout possible la plupart du temps).

Pour résumer, les principaux conseils concernant les environnements virtualisés sont les suivants :

  • Stoppez les environnements lorsqu’ils ne sont pas ou plus nécessaires
  • Supprimez ou archivez ces environnements lorsque le projet est terminé
  • Supprimez régulièrement les snapshots obsolètes
  • Sur VMware, utilisez des disques de type “Thick Provision Lazy Zeroed“ lorsque c’est possible
  • Dimensionnez le stockage au plus près du besoin dès le départ

 

Logs

Supprimer les environnements virtuels, c’est bien, mais on peut également faire du nettoyage au sein de l’environnement, et ce durant sa phase d’activité (qui peut varier de plusieurs mois à plusieurs années).

En phase de développement, il est assez fréquent de configurer les serveurs applicatifs en mode debug afin d’avoir les logs les plus verbeux possible. Mais cela a évidemment un coût : l’espace disque. Les logs sont généralement le premier facteur de saturation des disques.

Les bonnes pratiques peuvent être les suivantes :

  • S’assurer d’avoir un mécanisme de nettoyage automatique de logs (typiquement un outil comme “Logrotate” sur des machines Linux/Unix)
  • Activer le mode debug des serveurs applicatifs uniquement lorsque c’est nécessaire, et bien penser à le désactiver lorsque la phase de debug est terminée !

 

Containerisation

La containerisation (que ce soit avec Docker ou d’autres solutions) peut vous permettre, si elle est bien utilisée, d’avoir des gains de ressources à plusieurs niveaux :

  • CPU/RAM : ces ressources sont directement consommées sur le poste physique, il n’y a pas d’émulation
  • Stockage : plusieurs containers peuvent se partager la même image de base, ce qui évite une duplication de données

L’utilisation de containers peut permettre l’optimisation de stockage, mais à contrario on peut vite se retrouver avec des dizaines voire des centaines d’images sur son poste ! De plus, avec Docker, certaines couches d’images peuvent devenir orphelines et consommer de l’espace inutilement. La commande suivante permet de nettoyer ces couches :

docker image prune

Et celle-ci permet de nettoyer, en plus des couches orphelines, toutes les images qui ne sont utilisées par aucun container à l’instant présent :

docker image prune -a

Plus d’informations ici.

Les conseils peuvent être les suivants :

  • Utilisez un système de container lorsque c’est possible, et utiliser un maximum d’images communes entre les différents containers
  • Nettoyez régulièrement les couches et images inutiles ou obsolètes

 

Git

Plusieurs conseils :

  • Supprimez les branches mortes ou obsolètes
  • Supprimez les dépôts inutiles en local, et sur le serveur Git lorsque c’est possible
  • N’y stockez pas de binaires : ils ne sont pas versionnables, privilégier par exemple des repositories Maven
  • Evitez d’y stocker de gros fichiers : privilégier sinon Git LFS, qui permet de stocker de façon transparente certains types de fichiers volumineux dans un filesystem dédié
  • Privilégiez la documentation au format texte (et non binaire comme le format de Word par exemple) : faire de la « Doc-as-code », avec des formats comme Markdown ou AsciiDoc

 

SharePoint

Chaque fichier présent dans un espace SharePoint bénéficie par défaut d’un système de révision (versionning). Cette fonctionnalité est très utile mais elle est aussi lourde, car pour chaque modification d’un fichier, une révision est créée, dupliquant de façon transparente le fichier.
On peut donc très rapidement se retrouver avec des documents qui peuvent contenir des centaines de révisions sans qu’on s’en rende compte !

Pour vérifier le nombre de révisions et pour les supprimer, procédez ainsi :

  1. Cliquez sur les trois points à droite du nom du fichier (ou via un clic droit)
  2. Cliquez sur « Historique des révisions »
  3. Cliquez sur « Supprimer toutes les versions » si vous désirez garder uniquement la version courante. Cliquez sinon sur la révision à supprimer

Sharepoint données

 

Sharepoint 2

Attention, les révisions supprimées (comme tout document supprimé de façon générale) peuvent se retrouver dans une corbeille, voire même dans une seconde corbeille si votre site SharePoint en possède.

Pour vider ces corbeilles :

    1. Accédez à la corbeille du site SharePoint concerné
    2. Cliquez sur “Vider la corbeille” et valider la suppression

Sharepoint 3

Sharepoint 4

 

3. Pour la seconde corbeille, cliquez sur « Corbeille secondaire » tout en bas de la page SharePoint puis réitérez les étapes précédentes :

Sharepoint 5

Retrouvez plus d’informations ici.

 

Microsoft Teams

Microsoft Teams est un outil collaboratif qui est de plus en plus adopté par les entreprises. Il permet entre autres de créer des canaux de communication par équipe, et il a aussi vocation à remplacer Skype Entreprise (dont la fin de vie officielle est planifiée au 31/07/2021) pour les fonctionnalités de messagerie instantanée ainsi que l’audio/vidéo. Microsoft Teams permet de s’envoyer des fichiers, soit de personne à personne, soit sur un canal groupé. Mais une fois le fichier échangé, il reste toutefois stocké « à vie » dans l’espace OneDrive du collaborateur émetteur du fichier, ou dans l’espace documentaire du SharePoint associé au canal groupé. Vérifiez et nettoyez donc la documentation échangée dans les canaux Teams.

Pour vérifier l’existence de ces fichiers et les supprimer si vous en êtes propriétaire, il suffit d’aller dans l’onglet « Fichiers » de la discussion ou du canal groupé.

Exemple :

Microsoft teams

 

Fichiers exécutables d’installations

En tant que développeur, vous pouvez être amené à installer et utiliser de nombreux outils. Pour ce faire, vous téléchargez de multiples de fichiers exécutables (exemples : IDE, outils de SGBD, frameworks, etc.).

Pour éviter que de nombreux exécutables, et parfois plusieurs versions du même programme, s’accumulent sur chaque poste de travail, il est préférable de disposer d’un partage centralisé pour y stocker une seule fois les versions nécessaires des différents exécutables. Vous pouvez alors y récupérer ce dont vous avez besoin, et supprimer de votre poste le fichier exécutable une fois le programme installé.

 

Réflexions en amont du projet

  • Maîtriser le poids des pages du produit fini
  • Réduire le nombre de requêtes backend
  • Optimiser son backend
  • Réduire le poids des médias (images / vidéos)
  • Assurer la retro compatibilité sur de vieux OS (surtout vrai pour les développeurs d’applications mobiles) pour ne pas « encourager » l’obsolescence programmée
    Pour tester l’empreinte d’un site : https://www.websitecarbon.com/
  • Niveau SEO : s’assurer que son site est aussi référencé sur les moteurs de recherche « éco-responsables », comme par exemple Ecosia
    Il existe également des hébergeurs avec des labels “écolo” : https://www.thegreenwebfoundation.org/
  • Faire de l’auto-scaling plutôt que dimensionner ses serveurs au plus haut (pour les pics d’activité)
  • Maintenir son site régulièrement (les évolutions des technologies comme Java ou PHP s’accompagnent souvent d’une réduction de ressources consommées pour des performances équivalentes)

 

Il est évident que tous ces conseils, bien qu’ils ne soient pas exhaustifs, ne pourront pas être appliqués dans tous les contextes, mais ils permettent de se rendre compte de la largeur du périmètre sur lequel un développeur agit sur la donnée. Il peut être à l’origine d’un gaspillage massif de données et d’énergie si on cumule ses tâches quotidiennes.
Avec ces conseils, et de façon plus générale, nous pourrions (et devrions) tous, développeurs ou non, nous poser les questions suivantes à chaque fois que nous avons l’occasion de créer de la donnée :

  • Est-ce que cette donnée est utile, légère et optimisée ?
  • Est-ce que ce que je suis en train de créer de la donnée à l’endroit adéquat ?
  • Est-ce que la donnée n’est pas déjà présente et disponible ailleurs ?
  • Est-ce que je devrai supprimer ces données à moment donné ?

 

Article écrit par Frédéric Gracia, Ingénieur Systèmes & Réseaux et Matthieu Meyer, Manager Support

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !