Réduisez votre empreinte carbone sur Google Cloud

Last reviewed 2021-10-11 UTC

Ce document explique l'approche de Google Cloud en termes de développement durable. Il comprend des informations et d'autres ressources que vous pouvez utiliser pour comprendre votre empreinte carbone sur Google Cloud, ainsi que des méthodes vous permettant de réduire ou de minimiser cet empreinte. L'audience visée pour ce document est la suivante :

Les développeurs qui souhaitent créer des applications avec une empreinte carbone minimale.
L'équipe d'infrastructure et les autres équipes techniques qui souhaitent comprendre leur empreinte carbone actuelle et identifier les possibilités de réduction de cette empreinte.

Dans ce document, nous partons du principe que vous connaissez Google Cloud et que vous exécutez des charges de travail de machines virtuelles (VM).

Comprendre les émissions de carbone liées au cloud

Google présente un bilan carbone neutre depuis 2007 et s'est engagé à utiliser 100 % d'énergie renouvelable (24h/24 et 7j/7) d'ici 2030. Les centres de données Google, y compris ceux qui exécutent des services Google Cloud, utilisent beaucoup moins d'énergie que les centres de données classiques. C'est pourquoi Google Cloud peut aujourd'hui vous aider à réduire les émissions de carbone liées à votre infrastructure informatique.

Google exploite plusieurs régions cloud, qui sont diffusées via un réseau mondial de centres de données. Ces centres consomment de l'électricité générée par le réseau local pour exécuter les services cloud. L'impact environnemental de l'électricité générée par le réseau local est mesuré sur la base de l'intensité carbone du réseau électrique. L'intensité carbone du réseau électrique reflète les émissions de carbone des centrales qui produisent de l'électricité pour le réseau électrique.

L'impact environnemental n'est pas le même dans tous les centres de données, en raison de facteurs tels que le mix énergétique et l'efficacité de production. Depuis 2017, Google achète également de l'énergie renouvelable en quantité égale à l'électricité consommée par l'entreprise dans le monde entier grâce à des contrats d'achat d'électricité (PPA). Ces contrats d'achat d'électricité (PPA) permettent de produire de l'énergie sans aucune émission de carbone, pour le compte de Google et dans les réseaux électriques utilisés par nos centres de données.

L'impact environnemental de l'électricité consommée par les centres de données Google est déterminé en combinant l'intensité carbone du réseau électrique avec l'énergie attribuable à Google en provenance de sources sans émissions de carbone. Google a donc créé la métrique pourcentage d'énergie décarbonée (CFE%), calculée à partir de ces deux éléments. Le CFE% décrit la consommation horaire moyenne d'énergie sans émissions de carbone pour chaque région et représente le pourcentage moyen d'énergie sans émissions de carbone consommé par votre application. En raison d'un approvisionnement en énergie plus propre, les régions ayant un CFE% plus élevé produisent moins d'émissions de carbone pour une même charge de travail que les régions ayant un CFE% inférieur.

Pour réduire vos émissions de carbone, vous devez réduire la consommation électrique de vos charges de travail cloud qui reposent sur des sources générant des émissions de carbone. Pour réduire vos émissions de carbone, nous vous recommandons d'appliquer les stratégies principales suivantes :

Choisissez des régions cloud avec un CFE% moyen plus élevé et une intensité carbone de réseau plus faible. Pour les régions ayant le même CFE%, utilisez l'intensité carbone de réseau afin de comparer les performances d'émissions de ces régions.
Optimisez vos charges de travail cloud pour réduire vos émissions de carbone. Par exemple, augmentez l'efficacité en utilisant des services cloud élastiques et des fonctionnalités d'autoscaling pour minimiser les ressources de calcul inutilisées, et exécutez les charges de travail par lot pendant les périodes où l'intensité carbone du réseau est inférieure.
Définissez des règles d'administration permettant de restreindre l'emplacement des ressources cloud à des régions plus propres.

Comprendre votre empreinte carbone

Google Cloud propose un outil Empreinte carbone afin de vous aider à mieux comprendre l'empreinte carbone de votre utilisation de Google Cloud. Empreinte carbone indique le total des émissions générées en se basant sur l'intensité carbone du réseau électrique local. De plus, le rapport inclut la répartition des émissions entre vos différents projets Google Cloud et les services cloud que vous utilisez. Les données concernant les émissions sont consignées selon la méthodologie de création de rapports d'empreinte carbone de Google et peuvent vous aider à satisfaire les exigences de création de rapports du Greenhouse Gas (GHG) Protocol (Scope 3 Standard) en tant que client Google Cloud. Vous pouvez exporter les données Empreinte carbone vers BigQuery pour une analyse plus approfondie.

Vous pouvez utiliser le tableau de bord Empreinte carbone et l'exportation BigQuery pour mieux comprendre les émissions résultant de votre utilisation des services Google Cloud à différents emplacements. Vous pouvez utiliser ces données pour comparer l'empreinte carbone des différents services Google Cloud. Par exemple, pour mieux comprendre leurs émissions respectives, vous pouvez comparer les émissions totales de deux services ou plus qui s'exécutent dans une même région cloud.

Les données brutes sur les émissions de gaz à effet de serre produites par les clients Google Cloud et fournies par le rapport Carbon Footprint n'ont pas été vérifiées ni garanties par des tiers.

Choisir les régions cloud les plus adaptées

Le choix de régions cloud plus propres pour exécuter vos charges de travail est l'un des moyens les plus simples et les plus efficaces de réduire les émissions de carbone. Google publie les données carbone pour toutes les régions cloud, ce qui inclut la métrique CFE% et l'intensité carbone du réseau électrique local. Pour réduire vos émissions globales, nous vous recommandons de choisir des régions avec un CFE% plus élevé lorsque cela est possible. Pour vous aider à choisir des régions plus propres, Google Cloud inclut un indicateur Faible CO2 sur certains sélecteurs d'emplacement de Google Cloud Console, ainsi que sur les pages "Emplacements" de la documentation Google Cloud. Pour en savoir plus sur les critères qu'une région doit respecter pour recevoir cet indicateur, consultez la section Énergie décarbonée pour les régions Google Cloud.

Lorsque plusieurs régions ont un CFE% similaire, comparez leur intensité carbone de réseau électrique. La comparaison de l'intensité carbone de réseau électrique dans différentes régions est également importante si vous vous concentrez sur les réductions d'émissions en fonction de l'emplacement. Par exemple, pour un score CFE% similaire, la grille peut être alimentée par des centrales à charbon ou par des centrales à gaz. L'intensité carbone de réseau reflète ce mix énergétique et vous aide à sélectionner le réseau produisant le moins d'émissions.

Cependant, la réduction des émissions n'est parfois qu'une des nombreuses exigences que vous devez prendre en compte lors du choix d'une région. Par exemple, vous devrez peut-être prendre en compte la disponibilité de services Google Cloud spécifiques, les tarifs, les exigences d'emplacement des données et la latence de diffusion pour vos utilisateurs. La région dont le CFE% global est le plus élevé peut ne pas être adaptée à votre cas d'utilisation. Pour garantir des émissions les plus faibles possibles, sélectionnez la région qui offre le CFE le plus élevé tout en répondant à toutes vos exigences.

Pour simplifier le choix de région, utilisez l'outil de sélection de région Google Cloud afin de déterminer les régions cloud qui répondent le mieux à vos exigences d'empreinte carbone, de prix et de latence. Pour en savoir plus sur l'outil de sélection de région Google Cloud, consultez la page Choisir la région Google Cloud qui vous convient.

Si votre organisation propose aux utilisateurs des régions cloud à utiliser, vous pouvez également définir une règle d'administration permettant de restreindre les emplacements aux régions à faibles émissions de CO2.

Choisir les services cloud les plus adaptés

Google Cloud offre une gamme de services cloud adaptés à différentes charges de travail informatiques. Pour réduire votre empreinte carbone, envisagez de migrer vos charges de travail de VM vers Compute Engine si elles sont actuellement exécutées sur une infrastructure moins économe en énergie (un centre de données sur site par exemple). Pour en savoir plus sur la migration de VM vers Google Cloud à partir de centres de données sur site et de divers environnements cloud, consultez la page Parcours de migration avec Migrate to Virtual Machines.

De nombreuses charges de travail ne nécessitent pas de VM. Vous pouvez donc les déployer sur d'autres services entièrement gérés conçus pour différents types de charges de travail. Ces services intègrent souvent des fonctionnalités de scaling et de redimensionnement automatiques qui permettent d'optimiser les performances et l'utilisation des ressources. Par exemple, Cloud Run est un environnement entièrement sans serveur qui fait évoluer les applications en conteneur plus rapidement et avec moins de ressources inactives en comparaison à l'exécution d'une pile d'application comparable sur des VM. Le fait de réduire le nombre de ressources inactives permet d'optimiser les coûts et de réduire l'empreinte carbone.

Envisagez d'utiliser les offres suivantes pour les types de charge de travail courants. La liste des services n'est pas exhaustive, mais elle explique comment différents services gérés peuvent optimiser l'utilisation des ressources cloud (souvent de manière automatique), ce qui réduit simultanément les coûts liés au cloud et l'empreinte carbone.

Cloud Run : offre sans serveur permettant d'exécuter des applications en conteneur, écrites dans le langage de votre choix. Elle permet un autoscaling rapide de votre application de zéro à N instances de conteneur en fonction du trafic. En l'absence de trafic, votre application n'utilise aucune ressource informatique pour la diffusion. Le service est conçu pour gérer des modèles de trafic intenses et optimiser votre utilisation des ressources de calcul en conséquence.
Cloud Functions : offre FaaS (Functions-as-a-Service) sans serveur. Cloud Functions s'exécute sur la même infrastructure que Cloud Run et App Engine, ce qui permet au service de bénéficier des mêmes fonctionnalités d'autoscaling rapide à partir de zéro.
Google Kubernetes Engine (GKE) : service cloud qui fournit des environnements Kubernetes gérés. Par rapport à l'utilisation directe de VM, l'exécution de charges de travail conteneurisées à l'aide d'environnements Kubernetes sur GKE peut minimiser les ressources cloud inutilisées, ce qui permet de réduire les coûts liés au cloud et l'empreinte carbone de vos charges de travail.
BigQuery : entrepôt de données cloud sans serveur qui permet d'interroger de grands ensembles de données à l'échelle du pétaoctet. En prenant en charge de nombreux utilisateurs sur une grande infrastructure mutualisée, BigQuery utilise efficacement les ressources de calcul grâce à des économies d'échelle massives. L'architecture BigQuery sépare le stockage et le calcul, ce qui permet d'allouer efficacement des ressources de calcul pour faire évoluer le stockage de données séparément de l'exécution des requêtes. BigQuery attribue de manière dynamique des ressources de calcul (appelées emplacements) en fonction des besoins pour l'exécution des requêtes. La planification équitable réaffecte automatiquement la capacité d'emplacements aux projets en fonction des besoins pour l'exécution des requêtes.

Cependant, d'autres charges de travail peuvent encore nécessiter des VM. Lorsque vous avez besoin de VM, évitez de provisionner plus de ressources que ce dont vous avez besoin ou de laisser les ressources inutilisées s'exécuter, sans quoi vos coûts et vos émissions de carbone risquent d'augmenter.

Minimiser les ressources cloud inactives

Vous remarquerez peut-être que les pratiques d'optimisation des coûts qui réduisent les ressources inactives ou utilisées de manière inefficace permettent également de réduire l'empreinte carbone. Les ressources inactives sont synonymes de gaspillage avec des coûts et des émissions inutiles. Voici quelques exemples de ressources non utilisées :

Des ressources cloud actives et non utilisées, par exemple des instances de VM qui ne sont pas arrêtées lorsqu'une charge de travail est terminée.
Des ressources surprovisionnées, par exemple en utilisant plus de VM ou des types de machines plus puissants que nécessaire pour une charge de travail donnée.
Des architectures ou workflows mal optimisés, par exemple les applications Lift and Shift qui ont été migrées (mais pas optimisées) pour le cloud, ou les infrastructures de stockage et de calcul qui ne sont pas séparées pour les charges de travail de traitement et d'analyse des données.

Les ressources de VM inutilisées et surprovisionnées ont généralement un impact important sur les coûts et l'empreinte carbone. Pour réduire l'empreinte carbone, réfléchissez à la manière dont vous pouvez réduire la capacité des VM inactives et les autres ressources cloud inutilisées avec des processus d'automatisation, de surveillance et d'optimisation des charges de travail. Ces sujets n'entrent pas dans le cadre du présent document. Cependant, certaines pratiques simples peuvent avoir un impact important sur vos coûts et votre empreinte carbone. Certaines de ces pratiques sont implémentées par Active Assist, une solution qui fournit les types de recommandations automatiques suivants pour optimiser votre utilisation du cloud :

Identifier et supprimer les ressources de VM inactives : Vérifiez régulièrement les recommandations de ressources inactives (disques inutilisés dans Google Cloud Console par exemple). Vous pouvez également afficher les recommandations de ressources inactives en utilisant gcloud CLI ou l'API. Après vous être assuré que les ressources inactives ne sont plus nécessaires, vous pouvez les supprimer pour réduire les coûts et les émissions.
Redimensionner les instances de VM : ajustez la taille des VM en fonction de l'utilisation de leurs ressources en consultant régulièrement les recommandations de redimensionnement dans Google Cloud Console. Le redimensionnement permet de remédier au gaspillage lié à un surprovisionnement. Vous pouvez également afficher les recommandations de redimensionnement en utilisant gcloud CLI ou l'API.
Identifier et supprimer les VM inactives : utilisez l'outil de recommandation de VM inactives pour identifier les instances de VM qui n'ont pas été utilisées. Vous pouvez supprimer les VM inactives après vous être assuré qu'elles ne sont plus nécessaires.
Récupérer ou supprimer des projets sans surveillance : utilisez l'outil de recommandation de projets sans surveillance pour découvrir les projets sans surveillance qui ne sont pas utilisés ou très peu utilisés et arrêtez ces projets dans la mesure du possible.
Planifier des VM pour qu'elles s'exécutent au besoin : si les VM ne sont nécessaires qu'à certains moments, envisagez de programmer le démarrage et l'arrêt automatiques des instances de VM.
Corriger les instances Cloud SQL inactives et surprovisionnées : utilisez Active Assist pour identifier les instances Cloud SQL pour MySQL, PostgresSQL et SQL Server surprovisionnées et inactives. Une fois les instances identifiées, vous pouvez les redimensionner ou les supprimer.

Une architecture non optimale entraîne une utilisation moins efficace des ressources cloud. Bien que des problèmes d'architecture puissent survenir avec des applications conçues pour le cloud, ces problèmes se produisent le plus souvent avec des charges de travail sur site. Par exemple, des applications monolithiques migrées vers Google Cloud sans optimisation (un processus communément appelé migration Lift and Shift). Les pratiques suivantes peuvent vous aider à optimiser votre architecture :

Créer des ressources lorsqu'elles sont nécessaires : bien que les ressources cloud soient élastiques, elles offrent des avantages limités en termes d'efficacité si les charges de travail sont déployées sur des ressources fixes qui s'exécutent en continu, quelle que soit l'utilisation réelle. Identifiez les possibilités de création (et de suppression) de ressources, par exemple en utilisant la planification de VM ou les fonctionnalités élastiques des services cloud. Les fonctionnalités élastiques incluent l'utilisation de Compute Engine pour effectuer l'autoscaling des VM qui exécutent des serveurs Web sans état, ou l'utilisation de Dataflow pour procéder à l'autoscaling des nœuds de calcul pour un pipeline de flux de données.
Conteneuriser les charges de travail : envisagez d'empaqueter vos charges de travail dans des conteneurs et d'utiliser un outil d'orchestration de conteneurs tel que Google Kubernetes Engine (GKE) pour exécuter efficacement les conteneurs. Lorsque vous utilisez GKE, vous pouvez planifier efficacement les conteneurs sur un cluster de VM en fonction de leurs besoins en ressources. Plusieurs conteneurs peuvent également partager les ressources d'une même VM, si leurs exigences de ressources le permettent.

Migrate for GKE et Migrate for GKE Enterprise constituent une solution simplifiée pour la migration des charges de travail depuis des VM vers des conteneurs. La migration des VM vers des conteneurs peut constituer une première étape de modernisation des applications. Les étapes ultérieures peuvent impliquer des pratiques d'optimisation des coûts qui réduisent également les émissions, ou encore une refactorisation des applications en microservices.

Si vous avez besoin d'une flexibilité de configuration complète et d'un contrôle total sur l'orchestration des conteneurs, envisagez d'utiliser GKE. Si vous devez exécuter une application Web ou un microservice en conteneur et que vous n'avez pas besoin d'un environnement Kubernetes complet, envisagez d'utiliser Cloud Run. Cloud Run élimine la complexité de l'exécution des conteneurs et se concentre sur le fait de fournir une expérience améliorée aux développeurs. Pour une comparaison plus détaillée, consultez la page Google Kubernetes Engine et Cloud Run.

Refactoriser des applications monolithiques en microservices : les applications monolithiques combinent tous leurs modules en un seul programme, ce qui rend difficile l'allocation de ressources pour exécuter des modules spécifiques. Les applications monolithiques peuvent donc être difficiles à exécuter et à faire évoluer efficacement, avec une empreinte carbone plus importante qu'une mise en œuvre basée sur des microservices.

Prenons l'exemple d'un site Web d'e-commerce monolithique disposant d'un service de panier d'achat et d'un service de paiement. Les utilisateurs peuvent interagir avec le service de panier d'achat plusieurs fois au cours d'une session et interagir avec le service de paiement uniquement à la fin d'une session. Les deux services ont des exigences de ressources différentes en raison des caractéristiques du trafic et de la charge, mais ils ne peuvent pas être exécutés séparément car ils font tous les deux partie de la même application monolithique. Si le monolithe s'exécute sur des VM, chaque VM supplémentaire ajoute des ressources de calcul pour exécuter les deux services, même si un seul des services nécessite d'augmenter sa capacité de diffusion.

Contrairement aux monolithes, l'architecture à microservices sépare les modules d'application dans leurs propres programmes légers intégrés à l'aide d'appels réseau. Les microservices peuvent être adaptés les uns aux autres et utilisent des formes de ressources différentes (par exemple, les types de machines de VM, les allocations de processeurs virtuels et de mémoire Cloud Run ou les types d'instances App Engine) adaptés à l'exécution de ce service. Le scaling des microservices permet une utilisation plus efficace des ressources cloud et réduit les coûts et les émissions grâce à un scaling précis et à une diminution du surprovisionnement. Pour en savoir plus, consultez la page Refactoriser un monolithe en microservices.
Utiliser des services cloud qui dissocient les ressources de stockage et de calcul : certaines charges de travail de traitement et d'analyse sur site (basées sur le cloud), telles que Apache Hadoop et Apache Spark, partagent souvent la même infrastructure pour le stockage des données et le calcul. Si vous conservez une empreinte d'infrastructure importante pour le stockage des données et que vous devez dimensionner cette même empreinte pour les pics de besoins en calcul, l'utilisation des ressources de calcul est souvent faible. Une utilisation faible entraîne une augmentation du nombre de ressources inactives, ce qui augmente les coûts et génère inutilement des émissions.

Lorsque vous migrez ces charges de travail vers Google Cloud, nous vous recommandons d'utiliser des services gérés qui séparent les infrastructure de stockage et de calcul tels que les suivants :
- BigQuery : BigQuery est un entrepôt de données sans serveur à l'échelle du pétaoctet. Vous pouvez utiliser BigQuery pour les charges de travail d'analyse basées sur SQL. Le stockage des ensembles de données dans BigQuery est découplé des ressources de calcul. Cette séparation signifie que le stockage BigQuery est mis à l'échelle pour fournir un stockage quasiment illimité qui utilise efficacement les ressources. Cela signifie également que les ensembles de données peuvent être partagés sur place sans dupliquer les données ni créer un cluster.
- Dataproc : Dataproc est un service géré pour les charges de travail Hadoop et Spark. De nombreux déploiements Hadoop et Spark sur site utilisent des clusters de calcul qui sont toujours activés, indépendamment des caractéristiques d'utilisation. Bien que vous puissiez créer des clusters à longue durée de vie à l'aide de Dataproc, nous vous recommandons de créer des clusters éphémères lorsque vous devez exécuter des tâches. Les données lues ou écrites par les tâches Dataproc sont gérées séparément dans des services de stockage dédiés tels que Cloud Storage et Bigtable. En éliminant le besoin de maintenir un environnement de stockage Hadoop même lorsqu'aucune tâche n'est en cours d'exécution, vous réduisez la complexité opérationnelle, les coûts et les émissions.
- Spanner : Spanner est un service de base de données SQL distribué et évolutif à l'échelle mondiale qui dissocie les opérations de calcul et de stockage, ce qui permet de les faire évoluer séparément. Vous pouvez également effectuer le scaling automatique du nombre de nœuds de ressources de calcul pour les instances Spanner à l'aide de l'outil d'autoscaling. L'autoscaling des déploiements Spanner permet à votre infrastructure de s'adapter et d'évoluer automatiquement pour répondre aux exigences de charge. Elle permet également de réduire les coûts et les émissions de carbone en cas de faible charge.
Migrer les charges de travail vers des services gérés : les offres gérées peuvent réduire les ressources inutilisées en effectuant un scaling automatique des charges de travail, en plus d'autres fonctionnalités permettant de réduire les besoins en infrastructure. Pour en savoir plus, consultez la section Choisir le service cloud le plus approprié plus haut dans ce document.

Réduire les émissions pour les charges de travail par lot

Contrairement à de nombreuses charges de travail de diffusion en ligne, les charges de travail par lot sont souvent flexibles en termes d'emplacement et d'horaire d'exécution. Les exemples de charges de travail par lot incluent les tâches de calcul hautes performances (HPC) pour les calculs scientifiques, les rapprochements quotidiens de comptes ou la génération de recommandations de produits pour les e-mails marketing.

Comme pour les autres charges de travail, nous vous recommandons d'exécuter des charges de travail par lot dans des régions avec un CFE% plus élevé afin de réduire votre empreinte carbone globale. Si vous avez une certaine flexibilité dans l'exécution des tâches par lot, vous pouvez peut-être réduire davantage votre empreinte carbone en exécutant des tâches aux moments qui coïncident avec une intensité carbone réduite du réseau électrique. Pour afficher les données de mix énergétique et d'intensité carbone par heure dans différentes régions Google Cloud à l'échelle mondiale, utilisez le site Web electricityMap géré par Tomorrow.

Par définition, les charges de travail par lot ne sont pas sensibles à la latence. Cependant des dépendances sur des systèmes connexes (tels que des sources et des récepteurs de données) peuvent générer des coûts de mise en réseau indésirables. Cette dépendance peut exister pour des tâches faisant partie d'une application ou d'un workflow plus important, par exemple une tâche d'extraction, transformation et chargement (ETL) qui lit les données d'un ou plusieurs systèmes sources, puis écrit des données transformées dans un entrepôt de données. Si la tâche ETL traite et transfère de grandes quantités de données entre les régions cloud, il peut être difficile ou coûteux d'exécuter les tâches séparément en raison de l'impact sur les performances réseau et de l'augmentation des coûts de sortie interrégionaux.

Nous vous recommandons d'exécuter les types de charges de travail par lot suivants dans les régions à faible CO2 :

Charges de travail par lot autonomes : imaginons une charge de travail HPC autonome pour laquelle vous choisissez la région avec les meilleures caractéristiques de prix et d'émission en fonction de vos besoins, vous utilisez des services de stockage et de calcul dans cette même région, et vous téléchargez directement les résultats de l'analyse. Dans ce scénario, aucun trafic interrégional ne peut entraîner des pénalités de performances réseau ou des coûts de sortie réseau au-delà de ceux associés à la récupération des résultats d'analyse.
Charges de travail par lot nécessitant un transfert de données minimal avec d'autres régions cloud : envisagez une API qui diffuse les recommandations de produits à partir d'un modèle de machine learning (ML). L'API peut être hébergée dans plusieurs régions cloud pour une diffusion à faible latence aux utilisateurs. Les modèles de ML peuvent être entraînés régulièrement dans le cadre d'un processus centralisé par lot utilisant des données de flux de clics provenant de navigateurs, puis copiés dans chaque région cloud où l'API est hébergée. Dans ce scénario, les artefacts de modèle de sortie des tâches d'entraînement sont de petite taille (quelques dizaines de mégaoctets environ).

Dans ce scénario, les données de flux de clics pour l'entraînement des modèles de ML sont envoyées directement des navigateurs vers la région cloud qui héberge le backend de ML. Lorsque le backend de ML entraîne un nouvel ensemble de modèles, le transfert de données pour la copie de modèles vers d'autres régions cloud est relativement petit (peut-être quelques centaines de mégaoctets pour une dizaine de modèles à copier).

Recommandations

Vous trouverez dans le tableau suivant des recommandations pour réduire votre empreinte carbone sur Google Cloud :

Sujet	Recommandations
Comprendre les émissions de carbone liées au cloud	Découvrez comment le pourcentage d'énergie décarbonée (CFE%) représente la consommation d'énergie produite sans émissions de carbone des régions cloud. Découvrez les principales stratégies pour réduire votre empreinte carbone.
Comprendre votre empreinte carbone	Utilisez l'outil Empreinte carbone pour vous aider à comprendre l'empreinte carbone associée à votre utilisation de Google Cloud.
Choisir les régions cloud les plus adaptées	Utilisez l'outil de sélection de région Google Cloud pour déterminer les meilleures régions cloud en fonction de l'empreinte carbone, du prix et de la latence. Envisagez de créer des règles d'administration pour limiter l'utilisation aux régions à faible CO2.
Choisir les services cloud les plus adaptés	Migrez les VM exécutées dans des centres de données sur site moins efficaces vers Compute Engine. Utilisez des services gérés cloud optimisés pour des charges de travail spécifiques plutôt que des VM autogérées.
Réduire les ressources cloud inutilisées	Utilisez les fonctionnalités Active Assist pour supprimer les VM inutilisées, optimiser les formes de VM et arrêter les projets sans surveillance. Identifiez les possibilités de création (et de suppression) de ressources cloud en fonction de vos besoins plutôt que de conserver les ressources indéfiniment. Planifiez les VM pour les démarrer et les arrêter en fonction des besoins. Migrez les charges de travail vers des conteneurs et exécutez-les efficacement à l'aide de services gérés tels que Cloud Run et GKE. Refactorisez les applications monolithiques en microservices pour gagner en efficacité. Utilisez des services qui dissocient les opérations de calcul et de stockage pour le traitement et l'analyse des données. Migrez des charges de travail de VM existantes vers des services gérés.
Réduire les émissions pour les charges de travail par lot	Exécutez des charges de travail par lot avec une sortie interrégionale minimale, voire nulle, dans des régions à faible CO2. Exécutez des charges de travail par lot à des heures de la journée qui coïncident avec une intensité carbone plus faible sur le réseau électrique, si possible.

Étape suivante

Consultez la documentation sur le tableau de bord Empreinte carbone de Google Cloud.
Découvrez les progrès réalisés par Google pour utiliser de l'énergie sans émissions 24h/24 et 7j/7.
Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.