Modèles de Logiciels Écologiques

La Green Software Foundation a commencé à travailler sur les Modèles de Logiciels Écologiques.

Puisque nous sommes très alignés avec les objectifs de la Green Software Foundation, nous voulions attirer l’attention de tous sur certains de ces modèles appliqués dans le contexte de DownToZero.Cloud.

• Modèles de Logiciels Écologiques

Intelligence Artificielle (IA)

https://patterns.greensoftware.foundation/catalog/ai/

Comme nous ne proposons aucun service lié à l’IA, nous passons cette section du catalogue.

Cloud

https://patterns.greensoftware.foundation/catalog/cloud/

Mettre en cache les données statiques

D’un point de vue efficacité énergétique, il vaut mieux réduire le trafic réseau en lisant les données localement via un cache plutôt que d’y accéder à distance sur le réseau.

Nous mettons en cache sur de nombreuses instances lors du traitement des requêtes, par exemple notre runtime asynchrone de tâches met en cache localement les images Docker, ainsi nous n’avons pas besoin de télécharger l’image complète à chaque invocation.

Nous utilisons aussi autant que possible les hashs d’images pour les images de conteneurs afin de réduire la charge en temps réel lors de l’instanciation de nouveaux conteneurs.

Choisir la région la plus proche des utilisateurs

D’un point de vue efficacité énergétique, il est préférable de raccourcir la distance parcourue par un paquet réseau afin de réduire l’énergie nécessaire à sa transmission. De même, d’un point de vue carbone incorporé, lorsqu’un paquet traverse moins d’équipements informatiques, nous sommes plus efficaces en matière de matériel.

Puisque nous ne sommes pas multi-régionaux, ni ne dévoilons directement la disposition régionale de notre infrastructure, cela ne peut pas être influencé par un utilisateur.
En interne, nous essayons d’optimiser autant que possible la régionalisation, sans sacrifier la durabilité et la disponibilité.

Compresser les données stockées

Stocker trop de données non compressées peut entraîner un gaspillage de bande passante et augmenter les besoins de capacité de stockage.

Nous nous engageons à ne stocker que des données compressées.

L’Objectstore et le registre de conteneurs supportent la compression au niveau du stockage. C’est intégré aux deux services.
Le service d’observabilité dispose d’un mécanisme interne de tiering qui déplace les données d’un stockage chaud vers un format plus froid et mieux compressé après une période de rétention définie.

Compresser les données transmises

D’un point de vue efficacité énergétique, il est préférable de minimiser la taille des données transmises afin de réduire l’énergie requise en diminuant le trafic réseau.

Conteneuriser vos charges de travail

Les conteneurs permettent une utilisation plus flexible des ressources, car les charges de travail peuvent être facilement déplacées entre machines. Les conteneurs facilitent le packing binaire et requièrent moins de ressources de calcul que les machines virtuelles, ce qui réduit les allocations de ressources inutiles et augmente l’utilisation des ressources de calcul.

Nous ne supportons que des charges de travail conteneurisées. Pouvoir déplacer les charges entre différents sites est au cœur de DTZ pour permettre de basculer les charges vers des environnements d’exécution plus efficaces à la demande.

Supprimer les ressources de stockage inutilisées

D’un point de vue carbone incorporé, il est préférable de supprimer les ressources de stockage inutilisées afin d’être efficace en matériel et d’optimiser la couche de stockage pour la tâche.

Notre object store supporte les expirations sur les objets, permettant de nettoyer chaque entité lorsqu’elle n’est plus utilisée. Notre registre de conteneurs exécute également des jobs de nettoyage configurables pour réduire le nombre d’objets stockés.

Chiffrer ce qui est nécessaire

La protection des données par chiffrement est un aspect crucial de nos mesures de sécurité. Cependant, le chiffrement peut être gourmand en ressources à plusieurs niveaux. D’abord, la quantité de CPU requise dépend de l’algorithme choisi, les algorithmes complexes nécessitant plus de puissance de calcul. De plus, le chiffrement augmente la taille des données stockées car il comprend généralement des métadonnées et un bourrage supplémentaires, ce qui est particulièrement notable pour les fichiers plus petits. En outre, le chiffrement est une tâche répétitive à effectuer à chaque lecture ou mise à jour de données, ce qui peut augmenter la consommation énergétique, notamment dans les systèmes à haut débit.

Évaluer d’autres architectures CPU

Les applications sont développées avec une architecture logicielle qui correspond le mieux aux besoins métier qu’elles desservent. Les fournisseurs cloud facilitent l’évaluation d’autres types de CPU, comme x86-64, qui peuvent être inclus dans l’évaluation avec de nombreuses alternatives économiques offrant un bon rapport performance par watt.

Pour l’instant nous ne supportons qu’une seule architecture CPU, X86. Nous n’avons actuellement pas les ressources pour évaluer différentes architectures.

Utiliser un service mesh uniquement si nécessaire

Un service mesh déploie des conteneurs supplémentaires pour la communication, généralement en motif sidecar, afin de fournir plus de capacités opérationnelles. Cela peut augmenter l’utilisation CPU et le trafic réseau, mais permet aussi de découpler l’application de ces capacités en les déplaçant de la couche application à la couche infrastructure.

Puisque notre réseau ne dépend pas d’abstractions Kubernetes, nous n’avons pas non plus besoin d’un service mesh.

Terminer TLS à la passerelle frontalière

Le Transport Layer Security (TLS) garantit que toutes les données échangées entre le serveur web et les navigateurs restent privées et chiffrées. Toutefois, terminer et rétablir TLS augmente l’utilisation CPU et peut être inutile dans certaines architectures.

Implémenter un design sans état

L’état d’un service désigne les données en mémoire ou sur disque nécessaires au fonctionnement du service. L’état inclut les structures de données et variables membres que le service lit et écrit. Selon l’architecture, l’état peut aussi inclure des fichiers ou d’autres ressources stockées sur disque.

Nos services existants, comme Container Services et Container Jobs, reposent sur un design sans état et offrent aussi ces capacités à nos utilisateurs.

Adapter les objectifs de niveau de service aux besoins métier

Si des indisponibilités sont acceptables, il vaut mieux ne pas rechercher la plus haute disponibilité mais concevoir la solution selon les besoins réels. Des garanties de disponibilité moindres peuvent réduire la consommation d’énergie en utilisant moins de composants d’infrastructure.

Notre SLO est de fournir le meilleur service possible, sans compromettre l’efficacité et la durabilité. Nos services s’appuient donc fortement sur une montée en charge automatique pour toujours fournir un niveau de service approprié avec un minimum de surcharge.

Adapter les exigences d’utilisation des machines virtuelles (VM)

Il vaut mieux avoir une VM fonctionnant à forte utilisation qu’en exploiter deux à faible taux d’utilisation, non seulement pour la proportionnalité énergétique mais aussi pour le carbone incorporé.

Jusqu’à présent, nous ne proposons pas de services basés sur VM. Toutes nos offres d’infrastructure reposent sur des conteneurs pour offrir une expérience plus fluide.

Adapter les exigences d’utilisation avec des serveurs préconfigurés

Il vaut mieux avoir une VM fonctionnant à forte utilisation qu’en exploiter deux à faible taux d’utilisation, non seulement pour la proportionnalité énergétique mais aussi pour le carbone incorporé.

Nous visons une forte utilisation dans notre infrastructure, mais ces composants ne sont pas exposés à l’utilisateur final. L’utilisateur ne voit que les conteneurs comme abstraction. Puisque nous fournissons des métriques d’efficacité énergétique, celles-ci peuvent varier en fonction de l’utilisation de l’infrastructure sous-jacente.

Minimiser le nombre total d’environnements déployés

Dans une application donnée, il peut être nécessaire d’utiliser plusieurs environnements dans le flux de travail. Typiquement, un environnement de développement est utilisé pour les mises à jour régulières, tandis que des environnements de staging ou de test servent à s’assurer qu’il n’y a pas de problèmes avant que le code n’atteigne un environnement de production accessible aux utilisateurs.

Optimiser l’utilisation du stockage

Il vaut mieux maximiser l’utilisation du stockage afin que la couche de stockage soit optimisée pour la tâche, tant en termes de proportionnalité énergétique que de carbone incorporé.

Optimiser l’utilisation moyenne du CPU

L’utilisation du CPU varie au cours de la journée, parfois fortement selon les besoins de calcul. Plus la variance entre l’utilisation moyenne et maximale est grande, plus de ressources doivent être provisionnées en veille pour absorber ces pics de trafic.

Optimiser l’impact sur les appareils et équipements des clients

Les applications s’exécutent sur le matériel du client ou y sont affichées. Le matériel utilisé a une empreinte carbone incorporée due à la production et à l’électricité utilisée en fonctionnement. Optimiser la conception et l’architecture logicielle pour prolonger la durée de vie des appareils clients réduit l’intensité carbone de l’application. Idéalement, le client peut utiliser le matériel jusqu’à sa défaillance ou son obsolescence.

Optimiser l’utilisation maximale du CPU

L’utilisation du CPU varie au cours de la journée, parfois fortement selon les besoins de calcul. Plus la variance entre l’utilisation moyenne et maximale est grande, plus de ressources doivent être provisionnées en veille pour absorber ces pics de trafic.

Mettre en file d’attente les requêtes de traitement non urgentes

Tous les systèmes ont des périodes de charge élevée et faible. D’un point de vue efficacité matérielle, nous sommes plus efficaces si nous minimisons l’impact des pics de requêtes par une mise en œuvre permettant une utilisation uniforme des composants. D’un point de vue efficacité énergétique, nous sommes plus efficaces en maintenant les ressources inactives au minimum.

Notre service Container Jobs concrétise cet objectif comme un service au sein de DTZ.

Réduire les données transmises

D’un point de vue efficacité énergétique, il vaut mieux minimiser la taille des données transmises afin de réduire l’énergie requise en diminuant le trafic réseau.

Supprimer les actifs inutilisés

Surveillez et analysez l’application et la facture cloud pour identifier les ressources non utilisées ou pouvant être réduites.

Réduire les applications Kubernetes lorsqu’elles ne sont pas utilisées

Pour réduire les émissions de carbone et les coûts, les clusters Kubernetes Dev&Test peuvent éteindre les nœuds (VMs) hors des heures de bureau (par exemple, la nuit et les week-ends). => l’optimisation est ainsi mise en œuvre au niveau du cluster.

Nous ne proposons pas de services basés sur Kubernetes.

Réduire les applications lorsqu’elles ne sont pas utilisées

Les applications consomment du CPU même lorsqu’elles ne sont pas activement utilisées, par exemple pour des minuteries en arrière-plan, gestion de la mémoire, vérifications de santé, etc. Même arrêtée, l’infrastructure sous-jacente consomme de l’énergie en veille. Cela peut aussi se produire avec les applications de développement et test ou l’infrastructure hors heures ouvrables.

DownToZero, comme son nom l’indique, le scale down est au cœur de nos activités. Nous visons à ce que tous les services fournissent des possibilités de réduction.

Adapter l’infrastructure à la charge utilisateur

La demande en ressources dépend de la charge utilisateur à un moment donné. Cependant, la plupart des applications fonctionnent sans en tenir compte. Par conséquent, les ressources sont sous-utilisées et inefficaces.

Adapter la montée en charge Kubernetes en fonction des métriques de demande pertinentes

Par défaut, Kubernetes scale les charges de travail en fonction de l’utilisation CPU et RAM. En pratique, il est difficile de corréler les pilotes de demande de votre application avec l’utilisation CPU et RAM.

Nous ne proposons pas de services Kubernetes.

Monter en charge les composants logiques indépendamment

Une architecture microservices peut réduire la quantité de ressources de calcul requises, car chaque composant indépendant peut être mis à l’échelle selon sa propre demande.

Scanner pour les vulnérabilités

De nombreuses attaques sur l’infrastructure cloud visent à détourner des ressources déployées, ce qui entraîne un pic d’utilisation et de coûts inutile.

Définir les politiques de rétention de stockage

D’un point de vue carbone incorporé, il vaut mieux disposer d’un mécanisme automatisé pour supprimer les ressources de stockage inutilisées afin d’être efficient en matériel et optimiser la couche de stockage pour la tâche.

Éliminer le trafic de priorité inférieure

Lorsque les ressources sont contraintes lors d’événements à fort trafic ou quand l’intensité carbone est élevée, davantage d’émissions de carbone seront générées par votre système. Ajouter plus de ressources pour gérer la montée en charge augmente le carbone incorporé et la demande électrique. Continuer à traiter toutes les requêtes dans ces conditions augmente les émissions globales. Éliminer le trafic à priorité inférieure dans ces scénarios permet d’économiser ressources et émissions. Cela nécessite une bonne compréhension du trafic, notamment quelles requêtes sont critiques et lesquelles peuvent tolérer des tentatives de nouvelle transmission ou des échecs.

Décaler dans le temps les jobs cron Kubernetes

Les émissions carbone d’un système logiciel dépendent de la puissance consommée par ce logiciel, mais aussi de l’intensité carbone de l’électricité utilisée. Pour cette raison, exécuter un logiciel économe en énergie sur un réseau électrique à forte intensité carbone peut être inefficace pour réduire les émissions globales.

Bien que nous ne proposions pas de services Kubernetes, nos Container Jobs offrent un modèle d’ordonnancement flexible. Voir nos docs pour plus d’infos.

Utiliser des appels réseau asynchrones plutôt que synchrones

Lors d’appels inter-processus vers des bases de données, systèmes de fichiers ou APIs REST, s’appuyer sur des appels synchrones peut bloquer le thread d’appel, ce qui augmente la charge CPU.

Utiliser les modèles de disjoncteur (circuit breaker)

Les applications modernes communiquent régulièrement entre elles. Ces applications ont leur propre calendrier de déploiement, indisponibilités et disponibilité, la connexion réseau peut donc rencontrer des problèmes. Si l’application distante est injoignable, toutes les requêtes réseau échoueront et les requêtes futures seront vaines.

Utiliser des outils et contrôles de sécurité réseau natifs du cloud

Les firewalls réseau et d’applications web protègent contre les attaques les plus courantes et filtrent les bots malveillants. Ces outils aident à éliminer les transmissions de données inutiles et réduisent la charge sur l’infrastructure cloud, tout en consommant moins de bande passante et infrastructure.

Utiliser la protection DDoS

Les attaques par déni de service distribué (DDoS) sont utilisées pour augmenter la charge serveur afin qu’il ne puisse répondre aux requêtes légitimes, souvent pour nuire au propriétaire du service ou matériel. En raison de la nature de l’attaque, beaucoup de ressources environnementales sont consommées par des requêtes inutiles.

Utiliser des VMs processeurs natives cloud

Les machines virtuelles cloud ont différentes capacités selon les processeurs matériels. Utiliser des VMs basées sur l’efficacité de leur processeur impacte l’efficacité matérielle et réduit les émissions carbone.

Utiliser les services cloud serverless

Les services cloud serverless sont gérés par le fournisseur cloud pour l’application. Ils évoluent dynamiquement avec la charge nécessaire pour accomplir la tâche et appliquent les meilleures pratiques pour minimiser l’usage des ressources.

Toutes les offres DownToZero sont des services cloud serverless.

Web

https://patterns.greensoftware.foundation/catalog/web/

Comme nous ne proposons aucun service lié au Web, nous passons cette section du catalogue.