Ce principe du pilier de durabilité du Google Cloud framework Well-Architected fournit des recommandations pour vous aider à optimiser l'utilisation des ressources par vos charges de travail dans Google Cloud.
Présentation des principes
L'optimisation de l'utilisation des ressources est essentielle pour améliorer la durabilité de votre environnement cloud. Chaque ressource provisionnée (cycles de calcul, stockage de données, etc.) a un impact direct sur la consommation d'énergie, l'intensité hydrique et les émissions de carbone. Pour réduire l'empreinte environnementale 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.
Implémenter un scaling automatique et dynamique
La mise à l'échelle automatisée 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 diminution des coûts et des émissions de carbone.
Utilisez les techniques suivantes pour implémenter une évolutivité automatisée et dynamique.
Utiliser le scaling horizontal
Le scaling horizontal est la technique de scaling à privilégier pour la plupart des applications cloud. 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 automatiquement un groupe de VM Compute Engine. Une 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 économe en 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 des applications. Au lieu de vous fier uniquement à l'utilisation du processeur, pensez à utiliser des 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 stratégie d'autoscaling de cluster appropriée.
Combiner la mise à l'échelle réactive et proactive
Avec le scaling réactif, le système évolue en fonction des variations de charge en temps réel. Cette technique convient aux applications qui connaissent des pics de charge imprévisibles.
Le scaling proactif convient aux charges de travail avec des modèles prévisibles, comme les heures d'ouverture quotidiennes fixes et la génération de rapports hebdomadaires. Pour ces charges de travail, utilisez l'autoscaling planifié afin de provisionner les ressources à l'avance pour qu'elles puissent gérer un niveau de charge anticipé. Cette technique évite la course aux ressources et assure une expérience utilisateur plus fluide et plus efficace. Cette technique vous aide également à planifier de manière proactive les pics de charge connus, tels que les grands événements commerciaux et les efforts marketing ciblés.
Les services et fonctionnalités gérésGoogle Cloud , 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 mis à l'échelle à 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 traiter les requêtes de n'importe quel utilisateur. Cette approche de conception permet une mise à l'échelle horizontale 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 jobs 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 implémenter des jobs planifiés et par lot.
Programmation pour une faible intensité carbone
Planifiez l'exécution de vos jobs 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 périodes de la journée les moins intensives en carbone pour une région, utilisez le rapport sur l'empreinte carbone.
Utiliser des VM spot pour les charges de travail non critiques
Les VM Spot vous permettent de profiter de la capacité Compute Engine inutilisée à 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 disponibles. Les VM Spot sont idéales pour les tâches par lots non critiques et tolérantes aux pannes.
Consolider et paralléliser les jobs
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 d'assurer 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 ne payez donc pas pour les ressources inactives.
Faire correspondre les familles de machines virtuelles aux exigences de la charge de travail
Les types de machines que vous pouvez utiliser pour vos VM Compute Engine sont regroupés dans des 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 sur le développement durable |
|---|---|---|
| Instances à usage général (E2, N2, N4, Tau T2A/T2D) : ces instances offrent un rapport équilibré entre processeur et 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 l'architecture 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 ratio processeur virtuel/mémoire élevé et des performances par cœur élevées. | 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 plus rapidement les tâches nécessitant beaucoup de processeur, ce qui réduit le temps de calcul total et la consommation d'énergie du job. |
| Instances à mémoire optimisée (M3, M2) : ces instances sont conçues pour les charges de travail qui nécessitent une grande quantité de mémoire. | Vastes bases de données et entrepôts de données en mémoire, tels que SAP HANA ou l'analyse en mémoire. | Les instances à mémoire optimisée permettent de regrouper les charges de travail gourmandes en mémoire sur moins de nœuds physiques. Cette consolidation réduit la quantité totale d'énergie requise 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. |
| Instances optimisées pour le stockage (Z3) : ces instances offrent un stockage SSD local à haut débit et à faible latence. | Entrepôts de données, analyse des journaux, et bases de données SQL, NoSQL et vectorielles. | Les instances optimisées pour le stockage traitent d'énormes ensembles de données en local, 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. Elles offrent un nombre de calculs par watt plus élevé. Une instance accélérée par GPU comme la série A3 avec des GPU NVIDIA H100 peut être beaucoup plus écoénergétique pour l'entraînement de grands modèles qu'une alternative utilisant uniquement des CPU. 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 pour offrir des performances plus élevées 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 CPU, GPU et TPU bénéficient souvent des avancées techniques dans l'architecture des puces, comme les suivantes :
- Cœurs spécialisés : les processeurs sont souvent dotés de cœurs ou d'instructions spécialisés pour les charges de travail courantes. Par exemple, les processeurs peuvent disposer de cœurs dédiés aux opérations vectorielles ou d'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 dans les 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 à leur efficacité maximale et de passer en mode basse 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ûts :
- Performances énergétiques améliorées : il s'agit d'une métrique clé pour la durabilité. Par exemple, les VM C4 offrent 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.
- Réduction de la consommation totale d'énergie : 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 nécessitant une utilisation intensive des ressources de calcul, comme les jobs 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 la nécessité d'un surprovisionnement et contribue à garantir que chaque watt d'énergie est utilisé de manière productive.
Déployer des applications conteneurisées
Vous pouvez utiliser des services entièrement gérés basés sur des conteneurs tels que GKE et Cloud Run dans votre stratégie de cloud computing durable. Ces services permettent d'optimiser l'utilisation des ressources et d'automatiser leur gestion.
Exploiter la capacité de mise à l'échelle à zéro de Cloud Run
Cloud Run fournit un environnement sans serveur géré qui met automatiquement à l'échelle les instances à zéro lorsqu'il n'y a pas de trafic entrant pour un service ou lorsqu'un job est terminé. L'autoscaling permet d'éliminer la consommation d'énergie par l'infrastructure inactive. Les ressources ne sont alimentées que lorsqu'elles traitent activement les 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 propose 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 HPA, le nombre de répliques de conteneurs (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 empêche le surprovisionnement des ressources. Vous n'avez donc pas à payer ni à activer une capacité de calcul inutile.
- Autoscaling de pods verticaux (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 attribuer 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 AHP et VPA simultanément afin d'optimiser à la fois le nombre de pods et la taille de chacun d'eux. Cette technique permet de garantir la plus petite empreinte énergétique possible pour les performances requises.
- Planification tenant compte de la topologie (TAS, Topology-Aware Scheduling) : 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. 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é, 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 la planification tenant compte des émissions de carbone
Chez Google, nous déplaçons continuellement nos charges de travail vers des lieux et des moments où l'électricité est la plus propre. Nous réutilisons ou récupérons également les anciens équipements pour d'autres cas d'utilisation. Vous pouvez utiliser cette stratégie de planification tenant compte du carbone pour vous assurer que vos charges de travail conteneurisées utilisent de l'énergie propre.
Pour implémenter la planification tenant compte du carbone, vous avez besoin d'informations sur le mix énergétique qui alimente les centres de données d'une région en temps réel. Vous pouvez obtenir ces informations dans un format lisible par machine à partir du dépôt Énergie sans carbone pour les régions Google Cloud sur GitHub ou à partir d'un ensemble de données public BigQuery. Les données horaires sur le mix énergétique et l'intensité carbone utilisées pour calculer l'ensemble de données annuel sur le carbone de Google proviennent d'Electricity Maps.
Pour implémenter la planification tenant compte du 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écalage temporel : pour les charges de travail flexibles et non critiques, comme le traitement par lot, configurez-les pour qu'elles s'exécutent pendant les heures creuses ou lorsque les énergies renouvelables sont les plus abondantes. Cette approche, appelée "décalage temporel", permet de réduire l'empreinte carbone globale en tirant parti des sources d'énergie plus propres lorsqu'elles sont disponibles.
Concevoir une reprise après sinistre écoénergétique
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 temps de récupération (RTO).
Optimiser l'efficacité du démarrage à froid
Utilisez les approches suivantes pour minimiser ou éliminer les ressources actives dans votre région secondaire (reprise après sinistre) :
- Priorisez la reprise après sinistre à froid : gardez les ressources de la région de reprise après sinistre désactivées ou à l'état "mis à l'échelle à zéro". Cette approche permet d'éliminer l'empreinte carbone des ressources de calcul inactives.
- Profitez 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 passe à zéro lorsqu'il n'est pas utilisé. Vous pouvez ainsi 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.
- Automatisez la récupération 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 les environnements uniquement en cas de besoin.
Équilibrer la redondance et l'utilisation
La redondance des ressources est l'une des principales causes de gaspillage d'énergie. Pour réduire la redondance, utilisez les approches suivantes :
- Préférez la configuration active-active à la configuration active-passive : dans une configuration active-passive, 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 aide à maximiser l'efficacité énergétique de votre infrastructure.
- Redondance adaptée : répliquez les données et les services dans les 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 réplica supplémentaire augmente le coût énergétique du stockage persistant et de la sortie réseau.