Ce principe du pilier "Développement durable" du Google Cloud Well-Architected Framework fournit des recommandations pour vous aider à optimiser l'utilisation des ressources par vos charges de travail dans Google Cloud.
Présentation du principe
L'optimisation de l'utilisation des ressources est essentielle pour améliorer la durabilité de votre environnement cloud. Chaque ressource provisionnée, des cycles de calcul au stockage de données, a un impact direct sur la consommation d'énergie, l'intensité de l'eau et les émissions de carbone. Pour réduire l'empreinte écologique de vos charges de travail, vous devez faire des choix éclairés lorsque vous provisionnez, gérez et utilisez des ressources cloud.
Recommandations
Pour optimiser l'utilisation des ressources, tenez compte des recommandations des sections suivantes.
Mettre en œuvre un scaling automatisé et dynamique
Le scaling automatisé et dynamique garantit une utilisation optimale des ressources, ce qui permet d'éviter le gaspillage d'énergie lié à une infrastructure inactive ou surprovisionnée. La réduction du gaspillage d'énergie se traduit par une baisse des coûts et des émissions de carbone.
Utilisez les techniques suivantes pour mettre en œuvre une évolutivité automatisée et dynamique.
Utiliser le scaling horizontal
Le scaling horizontal est la technique de scaling privilégiée pour la plupart des applications cloud-first. Au lieu d'augmenter la taille de chaque instance, ce que l'on appelle le scaling vertical, vous ajoutez des instances pour répartir la charge. Par exemple, vous pouvez utiliser des groupes d'instances gérés (MIG) pour effectuer un scaling horizontal automatique d'un groupe de VM Compute Engine. L'infrastructure à scaling horizontal est plus résiliente, car la défaillance d'une instance n'affecte pas la disponibilité de l'application. Le scaling horizontal est également une technique efficace en termes de ressources pour les applications dont les niveaux de charge sont variables.
Configurer des règles de scaling appropriées
Configurez les paramètres d'autoscaling en fonction des exigences de vos charges de travail. Définissez des métriques et des seuils personnalisés spécifiques au comportement de l'application. Au lieu de vous fier uniquement à l'utilisation du processeur, tenez compte de métriques telles que la profondeur de la file d'attente pour les tâches asynchrones, la latence des requêtes et les métriques d'application personnalisées. Pour éviter un scaling fréquent et inutile ou un flapping, définissez des règles de scaling claires. Par exemple, pour les charges de travail que vous déployez dans Google Kubernetes Engine (GKE), configurez une règle d'autoscaling de cluster appropriée.
Combiner le scaling réactif et proactif
Avec le scaling réactif, le système s'adapte en fonction des variations de charge en temps réel. Cette technique convient aux applications dont les pics de charge sont imprévisibles.
Le scaling proactif convient aux charges de travail avec des modèles prévisibles, tels que les heures d'ouverture fixes et la génération de rapports hebdomadaires. Pour ces charges de travail, utilisez l'autoscaling planifié afin de préprovisionner les ressources pour qu'elles puissent gérer un niveau de charge prévu. Cette technique évite la course aux ressources et garantit une expérience utilisateur plus fluide et plus efficace. Elle vous aide également à planifier de manière proactive les pics de charge connus, tels que les événements commerciaux importants et les efforts marketing ciblés.
Google Cloud Les services et fonctionnalités gérés tels que GKE Autopilot, Cloud Run et les groupes d'instances gérés gèrent automatiquement le scaling proactif en apprenant de vos modèles de charge de travail. Par défaut, lorsqu'un service Cloud Run ne reçoit aucun trafic, il est réduit à zéro instance.
Concevoir des applications sans état
Pour qu'une application puisse évoluer horizontalement, ses composants doivent être sans état. Cela signifie que la session ou les données d'un utilisateur spécifique ne sont pas liées à une seule instance de calcul. Lorsque vous stockez l'état de la session en dehors de l'instance de calcul, par exemple dans Memorystore pour Redis, n'importe quelle instance de calcul peut gérer les requêtes de n'importe quel utilisateur. Cette approche de conception permet un scaling horizontal fluide et efficace.
Utiliser la planification et les lots
Le traitement par lot est idéal pour les charges de travail à grande échelle et non urgentes. Les tâches par lot peuvent vous aider à optimiser vos charges de travail en termes d'efficacité énergétique et de coût.
Utilisez les techniques suivantes pour mettre en œuvre la planification et les tâches par lot.
Planifier pour une faible intensité carbone
Planifiez l'exécution de vos tâches par lot dans des régions à faible émission de carbone et pendant les périodes où le réseau électrique local présente un pourcentage élevé d'énergie propre. Pour identifier les moments de la journée où l'intensité carbone est la plus faible dans une région, utilisez le rapport Empreinte carbone.
Utiliser des VM Spot pour les charges de travail non critiques
Les VM Spot vous permettent de profiter de la capacité inutilisée de Compute Engine à un prix très réduit. Les VM Spot peuvent être préemptées, mais elles constituent un moyen économique de traiter de grands ensembles de données sans avoir besoin de ressources dédiées et toujours actives. Les VM Spot sont idéales pour les tâches par lot non critiques et tolérantes aux pannes.
Consolider et paralléliser les tâches
Pour réduire la surcharge liée au démarrage et à l'arrêt des tâches individuelles, regroupez les tâches similaires dans un seul grand lot. Exécutez ces charges de travail à volume élevé sur des services tels que Batch. Le service provisionne et gère automatiquement l'infrastructure nécessaire, ce qui permet de garantir une utilisation optimale des ressources.
Utiliser des services gérés
Les services gérés tels que Batch et Dataflow gèrent automatiquement le provisionnement, la planification et la surveillance des ressources. La plate-forme cloud gère l'optimisation des ressources. Vous pouvez vous concentrer sur la logique de l'application. Par exemple, Dataflow ajuste automatiquement le nombre de nœuds de calcul en fonction du volume de données dans le pipeline. Vous n'avez donc pas à payer pour les ressources inactives.
Adapter les familles de machines virtuelles aux exigences des charges de travail
Les types de machines que vous pouvez utiliser pour vos VM Compute Engine sont regroupés en familles de machines, qui sont optimisées pour différentes charges de travail. Choisissez les familles de machines appropriées en fonction des exigences de vos charges de travail.
| Famille de machines | Recommandé pour les types de charges de travail | Conseils en matière de développement durable |
|---|---|---|
| Instances à usage général (E2, N2, N4, Tau T2A/T2D): ces instances offrent un rapport équilibré entre le processeur et la mémoire. | Serveurs Web, microservices, bases de données de petite à moyenne taille et environnements de développement. | La série E2 est très rentable et économe en énergie grâce à son allocation dynamique des ressources. La série Tau T2A utilise des processeurs basés sur Arm, qui sont souvent plus économes en énergie par unité de performances pour les charges de travail à grande échelle. |
| Instances optimisées pour le calcul (C2, C3) : ces instances offrent un rapport vCPU/mémoire élevé et des performances élevées par cœur. | Calcul hautes performances (HPC), traitement par lot, serveurs de jeux, et analyse de données basée sur le processeur. | Une instance de la série C vous permet d'effectuer des tâches exigeantes en calculs plus rapidement, ce qui réduit le temps de calcul total et la consommation d'énergie de la tâche. |
| Instances à mémoire optimisée (M3, M2) : ces instances sont conçues pour les charges de travail nécessitant une grande quantité de mémoire. | Bases de données et entrepôts de données volumineux en mémoire, tels que SAP HANA ou l'analyse en mémoire. | Les instances à mémoire optimisée permettent de consolider les charges de travail exigeantes en mémoire sur moins de nœuds physiques. Cette consolidation réduit la consommation d'énergie totale par rapport à l'utilisation de plusieurs instances plus petites. La mémoire hautes performances réduit la latence d'accès aux données, ce qui peut réduire le temps total que le processeur passe dans un état actif state. |
| Instances optimisées pour le stockage (Z3) : ces instances offrent un stockage SSD local à haut débit et à faible latence. | Entreposage de données, analyse des journaux et bases de données SQL, NoSQL et vectorielles. | Les instances optimisées pour le stockage traitent localement des ensembles de données volumineux, ce qui permet d'éliminer l'énergie utilisée pour la sortie des données réseau entre les emplacements. Lorsque vous utilisez le stockage local pour les tâches à IOPS élevés, vous évitez de surprovisionner plusieurs instances standards. |
| Instances optimisées pour les accélérateurs (A3, A2, G2) : ces instances sont conçues pour les charges de travail accélérées par GPU et TPU, telles que l'IA, le ML et le HPC. | Entraînement et inférence de modèles de ML, et simulations scientifiques. | Les TPU sont conçus pour une efficacité énergétique optimale. Ils offrent un plus grand nombre de calculs par watt. Une instance accélérée par GPU, comme la série A3 avec des GPU NVIDIA H100 peut être beaucoup plus économe en énergie pour l'entraînement de grands modèles qu'une alternative basée uniquement sur le processeur. Bien qu'une instance accélérée par GPU ait une consommation d'énergie nominale plus élevée, la tâche est effectuée beaucoup plus rapidement. |
Passer aux derniers types de machines
L'utilisation des derniers types de machines peut contribuer à améliorer la durabilité. Lorsque les types de machines sont mis à jour, ils sont souvent conçus pour être plus économes en énergie et offrir des performances supérieures par watt. Les VM qui utilisent les derniers types de machines peuvent effectuer la même quantité de travail avec une consommation d'énergie inférieure.
Les processeurs, les GPU et les TPU bénéficient souvent des avancées techniques en matière d'architecture de puce, telles que les suivantes :
- Cœurs spécialisés : les avancées en matière de processeurs incluent souvent des cœurs ou des instructions spécialisés pour les charges de travail courantes. Par exemple, les processeurs peuvent avoir des cœurs dédiés aux opérations vectorielles ou des accélérateurs d'IA intégrés. Lorsque ces tâches sont déchargées du processeur principal, elles sont effectuées plus efficacement et consomment moins d'énergie.
- Gestion de l'alimentation améliorée : les avancées en matière d'architectures de puces incluent souvent des fonctionnalités de gestion de l'alimentation plus sophistiquées, telles que l'ajustement dynamique de la tension et de la fréquence en fonction de la charge de travail. Ces fonctionnalités de gestion de l'alimentation permettent aux puces de fonctionner avec une efficacité maximale et de passer en état de faible consommation lorsqu'elles sont inactives, ce qui minimise la consommation d'énergie.
Les améliorations techniques apportées à l'architecture des puces offrent les avantages directs suivants en termes de durabilité et de coût :
- Performances supérieures par watt : il s'agit d'une métrique clé pour la durabilité. Par exemple, les VM C4 présentent un rapport prix/performances 40 % supérieur à celui des VM C3 pour la même consommation d'énergie. Le processeur C4A offre une efficacité énergétique 60 % supérieure à celle des processeurs x86 comparables. Ces capacités de performances vous permettent d'effectuer des tâches plus rapidement ou d'utiliser moins d'instances pour la même charge.
- Consommation d'énergie totale inférieure : grâce à des processeurs améliorés, les ressources de calcul sont utilisées pendant une durée plus courte pour une tâche donnée, ce qui réduit la consommation d'énergie globale et l'empreinte carbone. L'impact carbone est particulièrement élevé pour les charges de travail de courte durée et exigeantes en calculs, telles que les tâches par lot et l'entraînement de modèles de ML.
- Utilisation optimale des ressources : les derniers types de machines sont souvent mieux adaptés aux logiciels modernes et plus compatibles avec les fonctionnalités avancées des plates-formes cloud. Ces types de machines permettent généralement une meilleure utilisation des ressources, ce qui réduit le besoin de surprovisionnement et contribue à garantir que chaque watt d'énergie est utilisé de manière productive.
Déployer des applications en conteneur
Vous pouvez utiliser des services entièrement gérés basés sur des conteneurs tels que GKE et Cloud Run dans le cadre de votre stratégie de cloud computing durable. Ces services permettent d'optimiser l'utilisation des ressources et d'automatiser la gestion des ressources.
Exploiter la fonctionnalité de scaling à zéro instance de Cloud Run
Cloud Run fournit un environnement sans serveur géré qui ajuste automatiquement le nombre d'instances à zéro lorsqu'il n'y a pas de trafic entrant pour un service ou lorsqu'une tâche est terminée. L'autoscaling permet d'éliminer la consommation d'énergie par une infrastructure inactive. Les ressources ne sont alimentées que lorsqu'elles traitent activement des requêtes. Cette stratégie est très efficace pour les charges de travail intermittentes ou basées sur des événements. Pour les charges de travail d'IA, vous pouvez utiliser des GPU avec Cloud Run, ce qui vous permet de consommer et de payer les GPU uniquement lorsqu'ils sont utilisés.
Automatiser l'optimisation des ressources à l'aide de GKE
GKE est une plate-forme d'orchestration de conteneurs qui garantit que les applications n'utilisent que les ressources dont elles ont besoin. Pour vous aider à automatiser l'optimisation des ressources, GKE fournit les techniques suivantes :
- Bin packing: GKE Autopilot regroupe intelligemment plusieurs conteneurs sur les nœuds disponibles. Le bin packing maximise l'utilisation de chaque nœud et réduit le nombre de nœuds inactifs ou sous-utilisés, ce qui contribue à réduire la consommation d'énergie.
- Autoscaling horizontal des pods (AHP): Avec l'HPA, le nombre d'instances dupliquées de conteneur (pods) est ajusté automatiquement en fonction de métriques prédéfinies telles que l'utilisation du processeur ou des métriques personnalisées spécifiques à l'application. Par exemple, si votre application connaît un pic de trafic, GKE ajoute des pods pour répondre à la demande. Lorsque le trafic diminue, GKE réduit le nombre de pods. Ce scaling dynamique évite le surprovisionnement des ressources. Vous n'avez donc pas à payer ni à alimenter une capacité de calcul inutile.
- Autoscaling vertical des pods (VPA): vous pouvez configurer GKE pour qu'il ajuste automatiquement les allocations et les limites de processeur et de mémoire pour les conteneurs individuels. Cette configuration garantit qu'un conteneur ne se voit pas allouer plus de ressources que nécessaire, ce qui permet d'éviter le surprovisionnement des ressources.
- Autoscaling multidimensionnel des pods GKE: pour les charges de travail complexes, vous pouvez configurer l'AHP et le VPA simultanément afin d'optimiser à la fois le nombre de pods et la taille de chaque pod. Cette technique permet de garantir l'empreinte énergétique la plus faible possible pour les performances requises.
- Planification tenant compte de la topologie (TAS) : la TAS améliore l'efficacité du réseau pour les charges de travail d'IA et de ML dans GKE en plaçant les pods en fonction de la structure physique de l'infrastructure du centre de données. La TAS colocalise stratégiquement les charges de travail pour minimiser les sauts de réseau. Cette colocation permet de réduire la latence de communication et la consommation d'énergie. En optimisant l'alignement physique des nœuds et du matériel spécialisé, la TAS accélère l'exécution des tâches et maximise l'efficacité énergétique des charges de travail d'IA et de ML à grande échelle.
Configurer une planification tenant compte des émissions de carbone
Chez Google, nous déplaçons continuellement nos charges de travail vers des emplacements et des moments qui fournissent l'électricité la plus propre. Nous réutilisons également les équipements plus anciens pour d'autres cas d'utilisation. Vous pouvez utiliser cette stratégie de planification tenant compte des émissions de carbone pour vous assurer que vos charges de travail en conteneur utilisent de l'énergie propre.
Pour mettre en œuvre une planification tenant compte des émissions de carbone, vous avez besoin d'informations en temps réel sur le mix énergétique qui alimente les centres de données d'une région. Vous pouvez obtenir ces informations dans un format lisible par machine à partir du dépôt Carbon free energy for Google Cloud regions sur GitHub ou d'un ensemble de données public BigQuery. Les données de mix énergétique et d'intensité carbone par heure utilisées pour calculer l' ensemble de données annuel sur les émissions de carbone de Google proviennent d' Electricity Maps.
Pour mettre en œuvre une planification tenant compte des émissions de carbone, nous vous recommandons les techniques suivantes :
- Déplacement géographique : planifiez l'exécution de vos charges de travail dans des régions qui utilisent une plus grande proportion de sources d'énergie renouvelables. Cette approche vous permet d'utiliser des réseaux électriques plus propres.
- Déplacement temporel : pour les charges de travail non critiques et flexibles, telles que le traitement par lot, configurez les charges de travail pour qu'elles s'exécutent en dehors des heures de pointe ou lorsque les énergies renouvelables sont les plus abondantes. Cette approche, appelée déplacement temporel, permet de réduire l'empreinte carbone globale en tirant parti de sources d'énergie plus propres lorsqu'elles sont disponibles.
Concevoir une reprise après sinistre économe en énergie
La préparation à la reprise après sinistre (DR) implique souvent le préprovisionnement de ressources redondantes dans une région secondaire. Toutefois, les ressources inactives ou sous-utilisées peuvent entraîner un gaspillage d'énergie important. Choisissez des stratégies de reprise après sinistre qui maximisent l'utilisation des ressources et minimisent l'impact carbone sans compromettre vos objectifs de délai de reprise (RTO).
Optimiser l'efficacité du démarrage à froid
Utilisez les approches suivantes pour minimiser ou éliminer les ressources actives dans votre région secondaire (DR) :
- Privilégier la reprise après sinistre à froid : maintenez les ressources de la région de reprise après sinistre désactivées ou dans un état de scaling à zéro instance. Cette approche permet d'éliminer l'empreinte carbone des ressources de calcul inactives.
- Tirer parti du basculement sans serveur : utilisez des services sans serveur gérés tels que Cloud Run pour les points de terminaison de reprise après sinistre. Cloud Run est réduit à zéro instance lorsqu'il n'est pas utilisé. Vous pouvez donc maintenir une topologie de reprise après sinistre qui ne consomme aucune énergie tant que le trafic n'est pas redirigé vers la région de reprise après sinistre.
- Automatiser la reprise avec l'infrastructure as code (IaC) : au lieu de maintenir les ressources en cours d'exécution (à chaud) sur le site de reprise après sinistre, utilisez un outil IaC tel que Terraform pour provisionner rapidement des environnements uniquement lorsque cela est nécessaire.
Équilibrer la redondance et l'utilisation
La redondance des ressources est l'un des principaux facteurs de gaspillage d'énergie. Pour réduire la redondance, utilisez les approches suivantes :
- Préférer l'actif/actif à l'actif/passif : dans une configuration actif/passif, les ressources du site passif sont inactives, ce qui entraîne un gaspillage d'énergie. Une architecture actif/actif de taille optimale garantit que toutes les ressources provisionnées dans les deux régions diffusent activement le trafic. Cette approche vous permet de maximiser l'efficacité énergétique de votre infrastructure.
- Dimensionner correctement la redondance : répliquez les données et les services dans plusieurs régions uniquement lorsque la réplication est nécessaire pour répondre aux exigences de haute disponibilité ou de reprise après sinistre. Chaque instance répliquée supplémentaire augmente le coût énergétique du stockage persistant et de la sortie réseau.