Riduci l'impronta di carbonio di Google Cloud

Last reviewed 2021-10-11 UTC

Questo documento spiega l'approccio di Google Cloud alla sostenibilità ambientale. Include informazioni e altre risorse che puoi utilizzare per comprendere la tua impronta di carbonio su Google Cloud, nonché metodi che puoi utilizzare per ridurlo o ridurlo. Il pubblico di destinazione di questo documento include quanto segue:

  • Sviluppatori che vogliono creare applicazioni con un impatto ambientale minimo.
  • Infrastruttura e altri team tecnici che vogliono comprendere la propria impronta di carbonio attuale e identificare opportunità per ridurla.

Questo documento presuppone che tu conosca Google Cloud e l'esecuzione dei carichi di lavoro delle macchine virtuali (VM).

Informazioni sulle emissioni di anidride carbonica del cloud

Google è carbon neutral dal 2007 e si è impegnata a utilizzare energia a zero emissioni di CO2 al 100%, 24 ore su 24, 7 giorni su 7, entro il 2030. Anche i data center di Google, inclusi quelli che eseguono i servizi Google Cloud, utilizzano molta meno energia rispetto ai data center tradizionali. Per questo motivo, l'utilizzo di Google Cloud può aiutarti a ridurre l'impatto ambientale dell'IT.

Google gestisce diverse regioni cloud, garantite tramite una rete globale di data center. Questi data center consumano l'elettricità generata dalla rete locale per eseguire i servizi cloud. L'impatto ambientale dell'elettricità generata dalla rete locale viene misurato in base all'intensità di carbonio della rete. L'intensità di carbonio della rete indica la quantità di anidride carbonica emessa dalle centrali elettriche che generano elettricità per la rete.

L'impatto ambientale non è uguale in tutte le sedi dei data center, a causa di fattori come il diverso mix energetico ed efficienza produttiva. Dal 2017, Google acquista anche energia rinnovabile uguale all'elettricità che consuma a livello globale nello stesso anno, tramite i contratti di acquisto di energia (PPA). Questi PPA portano alla produzione di energia a zero emissioni di CO2 attribuibile a Google, che entra nelle reti da cui i nostri data center consumano elettricità.

L'impatto ambientale dell'elettricità consumata dai data center di Google è determinato dalla combinazione tra intensità di carbonio della rete e energia proveniente da fonti di energia a zero emissioni di CO2 attribuite a Google. Google ha introdotto la metrica Percentuale di energia a zero emissioni di CO2 (CFE%), calcolata a partire da questi due elementi. CFE% descrive il consumo medio orario di energia a zero emissioni di CO2 per ogni regione e rappresenta la percentuale media di tempo in cui la tua applicazione viene eseguita con energia a zero emissioni di CO2. Grazie a una fornitura di energia più pulita, le regioni con una percentuale di CFE maggiore producono meno emissioni di anidride carbonica rispetto a quelle con una percentuale di CFE inferiore per lo stesso carico di lavoro.

Per ridurre le emissioni di anidride carbonica, devi ridurre il consumo di elettricità dei tuoi carichi di lavoro cloud da fonti basate sulle emissioni di anidride carbonica. Per ridurre le emissioni di anidride carbonica, ti consigliamo le seguenti strategie principali:

  1. Scegli regioni cloud con una percentuale media di CFE oraria più alta e una minore intensità di carbonio della griglia. Per le regioni con la stessa percentuale di CFE, utilizza l'intensità di carbonio della rete per confrontare ulteriormente il rendimento in termini di emissioni di quelle regioni.
  2. Ottimizza i carichi di lavoro cloud per ridurre le emissioni di anidride carbonica. Ad esempio, aumenta l'efficienza utilizzando servizi cloud elastici e funzionalità di scalabilità automatica per ridurre al minimo le risorse di calcolo inutilizzate ed esegui carichi di lavoro batch nei momenti in cui l'intensità di carbonio della rete è inferiore.
  3. Imposta criteri dell'organizzazione per limitare la località delle risorse cloud a regioni più pulite.

Comprendi l'impatto ambientale

Google Cloud fornisce Carbon Footprint, uno strumento che ti aiuta a comprendere l'impatto ambientale generato dal tuo utilizzo di Google Cloud. Carbon Footprint fornisce le emissioni totali in base all'intensità di carbonio della rete elettrica locale. Il report attribuisce ulteriormente le emissioni ai progetti Google Cloud di tua proprietà e ai servizi cloud che utilizzi. I dati sulle emissioni vengono riportati in base alla metodologia di reporting Carbon Footprint di Google e possono aiutarti a soddisfare i requisiti di reporting dello standard di ambito 3 del protocollo Greenhouse Gas (GHG) in qualità di cliente Google Cloud. Puoi esportare i dati di Carbon Footprint in BigQuery per ulteriori analisi.

Puoi utilizzare la dashboard di Carbon Footprint e BigQuery Export per comprendere le emissioni basate sulla località derivanti dall'uso dei servizi Google Cloud. Puoi utilizzare questi dati per confrontare l'impatto ambientale dei diversi servizi Google Cloud. Ad esempio, per comprendere le emissioni relative, puoi confrontare le emissioni totali di due o più servizi in esecuzione nella stessa regione cloud.

I dati sulle emissioni di gas serra lorde di Google Cloud specifici per il cliente forniti dal report Carbon Footprint non sono stati verificati o garantiti da terze parti.

Scegli le regioni cloud più adatte

Scegliere regioni cloud più pulite per l'esecuzione dei carichi di lavoro è uno dei modi più semplici ed efficaci per ridurre le emissioni di anidride carbonica. Google pubblica i dati sulle emissioni di anidride carbonica per tutte le regioni cloud, inclusi la percentuale di CFE e l'intensità di carbonio della rete della rete elettrica locale. Per ridurre le emissioni complessive, ti consigliamo di scegliere regioni con una percentuale di CFE più elevata, ove possibile. Per aiutarti a scegliere regioni più pulite, Google Cloud include un indicatore A basse emissioni di CO2 su alcuni selettori di località della console Google Cloud e sulle pagine "Località" della documentazione di Google Cloud. Per informazioni sui criteri che una regione deve soddisfare per ricevere questo indicatore, consulta Energia a zero emissioni di CO2 per le regioni di Google Cloud.

Se più regioni hanno una percentuale di CFE simile, confronta l'intensità di carbonio della loro rete. Il confronto dell'intensità di carbonio della rete di diverse regioni è importante anche se il tuo obiettivo è ridurre le emissioni in base alla località. Ad esempio, per ottenere un punteggio CFE% simile, la rete potrebbe essere alimentata da centrali elettriche a carbone o a gas. L'intensità di carbonio della rete riflette questo mix e ti aiuta a selezionare la griglia a più emissione di anidride carbonica più bassa.

La riduzione delle emissioni potrebbe essere uno dei tanti requisiti che è necessario bilanciare quando si sceglie una regione. Ad esempio, potrebbe essere necessario considerare la disponibilità di specifici servizi Google Cloud, i prezzi, i requisiti per la località dei dati e la latenza di servizio per gli utenti. La regione con la percentuale di CFE complessiva più elevata potrebbe non essere adatta al tuo caso d'uso. Per garantire le emissioni minime, seleziona la regione con la percentuale di CFE più alta e che soddisfa tutti i tuoi requisiti.

Per semplificare la selezione della regione, utilizza il selettore di regioni Google Cloud per individuare le regioni cloud migliori che soddisfano i tuoi requisiti in base all'impatto ambientale, al prezzo e alla latenza. Per ulteriori informazioni sul selettore di regione Google Cloud, consulta Scegliere la regione Google Cloud adatta a te.

Se la tua organizzazione consente agli utenti di scegliere le regioni cloud da utilizzare, puoi anche impostare un criterio dell'organizzazione per limitare le località alle regioni a bassa CO2.

Scegli i servizi cloud più adatti

Google Cloud offre una gamma di servizi cloud adatti a diversi carichi di lavoro IT. Per ridurre l'impatto ambientale esistente, valuta la migrazione dei carichi di lavoro delle VM a Compute Engine da un'infrastruttura a minor efficienza energetica, ad esempio un data center on-premise. Per informazioni su come eseguire la migrazione delle VM in Google Cloud dai data center on-premise e da vari ambienti cloud, consulta Migrazione delle VM con Migrate to Virtual Machines.

Molti carichi di lavoro non richiedono VM, quindi puoi eseguirne il deployment in altri servizi completamente gestiti destinati a diversi tipi di carichi di lavoro. Questi servizi spesso dispongono di funzionalità integrate di scalabilità e dimensionamento ottimale automatiche che aiutano a ottimizzare le prestazioni e l'utilizzo delle risorse. Ad esempio, Cloud Run è un ambiente completamente serverless che consente di scalare le applicazioni containerizzate più velocemente e con meno risorse inattive rispetto all'esecuzione di uno stack di applicazioni simile sulle VM. La riduzione delle risorse inattive consente di ottimizzare i costi e ridurre l'impronta di carbonio.

Prendi in considerazione le seguenti offerte per i tipi di carichi di lavoro comuni. L'elenco dei servizi non è completo, ma spiega come i diversi servizi gestiti possono ottimizzare l'utilizzo delle risorse cloud (spesso automaticamente), riducendo contemporaneamente i costi del cloud e l'impronta di carbonio.

  • Cloud Run: un'offerta serverless per l'esecuzione di applicazioni containerizzate, scritta nel linguaggio che preferisci. Offre una scalabilità automatica rapida della tua applicazione da zero a N istanze di container, in base al traffico. In assenza di traffico, l'applicazione non utilizza risorse di calcolo per la pubblicazione. Il servizio è progettato per gestire pattern di traffico intensivi e ottimizzare di conseguenza l'uso delle risorse di calcolo.
  • Cloud Functions: un'offerta Functions as a Service (FaaS) serverless. Viene eseguito nella stessa infrastruttura di Cloud Run e App Engine, che estende a Cloud Functions le stesse funzionalità di scalabilità da zero e scalabilità automatica rapida.
  • Google Kubernetes Engine (GKE): un servizio cloud che fornisce ambienti Kubernetes gestiti. Rispetto all'utilizzo diretto delle VM, l'esecuzione di carichi di lavoro containerizzati utilizzando gli ambienti Kubernetes su GKE può ridurre al minimo le risorse cloud inutilizzate, con conseguente riduzione dei costi cloud e dell'impronta di carbonio inferiore per i carichi di lavoro.
  • BigQuery: un data warehouse serverless su cloud che supporta query su grandi set di dati dell'ordine di petabyte. Supportando molti utenti in un'ampia infrastruttura multi-tenant, BigQuery utilizza in modo efficiente le risorse di calcolo attraverso enormi economie di scala. L'architettura di BigQuery separa spazio di archiviazione e calcolo, posizionando in modo efficiente le risorse di calcolo per scalare l'archiviazione dei dati separatamente dall'esecuzione delle query. BigQuery assegna le risorse di calcolo (chiamate slot) dinamicamente in base alle esigenze dell'esecuzione delle query. La pianificazione equa rialloca automaticamente la capacità degli slot tra i progetti e l'esecuzione di query in base alle esigenze.

Potresti avere altri carichi di lavoro che richiedono ancora VM. Quando le VM sono necessarie, evita il provisioning eccessivo di ciò che ti serve ed evita di lasciare in esecuzione risorse inutilizzate, il che può portare a un aumento dei costi e delle emissioni.

Riduci al minimo le risorse cloud inattive

Potresti osservare che le pratiche di ottimizzazione dei costi che riducono l'uso inattiva o inefficiente delle risorse cloud si traducono bene anche in una riduzione dell'impronta di carbonio. Le risorse inattive creano sprechi comportando costi ed emissioni non necessarie. Considera le seguenti forme di risorse non utilizzate:

  1. Risorse cloud attive e non utilizzate, ad esempio istanze VM che non vengono terminate al completamento di un carico di lavoro.
  2. Risorse in overprovisioning, ad esempio utilizzando più VM o tipi di macchine VM più grandi del necessario per un carico di lavoro.
  3. Architettura o flusso di lavoro non ottimali, ad esempio applicazioni lift and shift di cui è stata eseguita la migrazione al cloud (ma non ottimizzate per il cloud) o infrastruttura di archiviazione e calcolo non separata per i carichi di lavoro di analisi e elaborazione dei dati.

Le risorse VM inutilizzate e con overprovisioning di solito hanno l'impatto più significativo su costi inutili e maggiore impronta di carbonio. Per ridurre al minimo l'impatto ambientale, valuta come ridurre al minimo la capacità delle VM inutilizzate e altre risorse cloud inutilizzate attraverso i processi di automazione, monitoraggio e ottimizzazione dei carichi di lavoro. Questi argomenti non rientrano nell'ambito di questo documento; tuttavia, esistono pratiche semplici che possono avere un impatto significativo sui costi e sull'impatto ambientale. Alcune di queste pratiche sono abilitate da Active Assist, una soluzione che fornisce i seguenti tipi di suggerimenti automatici per ottimizzare l'utilizzo del cloud:

  1. Identifica ed elimina le risorse delle VM inattive: verifica regolarmente la presenza di suggerimenti sulle risorse inattive, ad esempio dischi inutilizzati, nella console Google Cloud. Puoi anche visualizzare i suggerimenti sulle risorse inattive utilizzando gcloud CLI o tramite l'API. Dopo aver verificato che le risorse inattive non siano più necessarie, puoi eliminarle per risparmiare su costi ed emissioni.
  2. Ridimensiona le istanze VM con le dimensioni ottimali: dimensiona in modo ottimale le VM in base all'utilizzo delle risorse controllando regolarmente i suggerimenti per il dimensionamento ottimale nella console Google Cloud. Il dimensionamento ottimale può aiutare a risolvere gli sprechi dovuti all'overprovisioning. I suggerimenti relativi al dimensionamento ottimale possono essere visualizzati anche utilizzando gcloud CLI o l'API.
  3. Identifica ed elimina le VM inattive: utilizza il motore per suggerimenti sulle VM inattive per identificare le istanze VM che non sono state utilizzate. Puoi eliminare le VM inattive dopo aver verificato che non sono più necessarie.
  4. Recupera o rimuovi progetti inattivi: utilizza il motore per suggerimenti di progetti inattivi per trovare progetti inattivi con utilizzo ridotto o assente e, ove possibile, arrestali.
  5. Pianifica l'esecuzione delle VM quando sono necessarie: se le VM sono necessarie solo in determinati momenti, valuta la possibilità di pianificare le istanze VM per l'avvio e l'arresto automatici.
  6. Risolvi i problemi relativi alle istanze Cloud SQL inattive e con provisioning eccessivo: utilizza Active Assist per identificare le istanze Cloud SQL per MySQL, PostgresSQL e SQL Server con provisioning eccessivo e inattive. Una volta identificate, puoi ridimensionare o eliminare queste istanze.

Un'architettura non ottimale porta a un uso meno efficiente delle risorse cloud. Sebbene possano verificarsi problemi di architettura con applicazioni create per il cloud, questi problemi si verificano più comunemente con i carichi di lavoro on-premise. Ad esempio, le applicazioni monolitiche di cui è stata eseguita la migrazione a Google Cloud, con ottimizzazione minima o minima (comunemente nota come lift and shift). Le seguenti pratiche possono aiutarti a ottimizzare l'architettura:

  1. Crea le risorse quando sono necessarie: sebbene le risorse cloud siano elastiche, ottieni vantaggi limitati in termini di efficienza se viene eseguito il deployment dei carichi di lavoro in risorse fisse eseguite continuamente, indipendentemente dall'utilizzo effettivo. Identifica le opportunità per creare (ed eliminare) le risorse in base alle necessità, ad esempio utilizzando la pianificazione delle VM o le funzionalità elastiche all'interno dei servizi cloud. L'utilizzo di funzionalità elastiche include l'uso di Compute Engine per la scalabilità automatica delle VM che eseguono server web stateless o l'utilizzo di Dataflow per la scalabilità automatica dei worker per una pipeline di dati in modalità flusso.
  2. Containerizzare i carichi di lavoro: valuta la possibilità di pacchettizzare i carichi di lavoro in container e di utilizzare un orchestratore di container come Google Kubernetes Engine (GKE) per eseguire i container in modo efficiente. Quando usi GKE, puoi pianificare in modo efficiente i container in un cluster di VM in base ai loro requisiti di gestione delle risorse. Più container possono inoltre condividere le risorse di una singola VM, se i requisiti di gestione lo consentono.

Migrate for GKE e GKE Enterprise offre un percorso semplificato per la migrazione dei carichi di lavoro dalle VM ai container. La migrazione delle VM ai container può essere un primo passo verso la modernizzazione delle applicazioni. Le fasi successive possono prevedere pratiche di ottimizzazione dei costi che riducono anche le emissioni e il refactoring delle applicazioni in microservizi.

Se hai bisogno di una configurazione completa e di controllo sull'orchestrazione dei container, considera l'uso di GKE. Se devi eseguire un microservizio o un'applicazione web containerizzata e non hai bisogno di un ambiente Kubernetes completo, considera l'utilizzo di Cloud Run. Cloud Run astrae la complessità dell'esecuzione dei container e si concentra sull'offerta di un'esperienza migliorata agli sviluppatori. Per un confronto più dettagliato, vedi Confronto tra Google Kubernetes Engine e Cloud Run.

  1. Refactoring delle applicazioni monolitiche in microservizi: le applicazioni monolitiche combinano tutti i moduli in un unico programma, il che rende difficile l'allocazione delle risorse per l'esecuzione di moduli specifici. Le applicazioni monolitiche possono quindi essere difficili da eseguire e scalare in modo efficiente e potrebbero quindi avere un'impronta di carbonio maggiore rispetto a un'implementazione basata su microservizi.

    Prendi in considerazione un sito web di e-commerce monolitico con un servizio di carrello degli acquisti e un servizio di pagamento. Gli utenti potrebbero interagire con il servizio del carrello degli acquisti più volte in una sessione e con il servizio di pagamento solo al termine di una sessione. I due servizi hanno requisiti diversi per le risorse a causa delle diverse caratteristiche di traffico e carico, ma non possono essere eseguiti separatamente perché entrambi fanno parte della stessa applicazione monolitica. Se il monolite viene eseguito su VM, ogni VM aggiuntiva aggiunge risorse di computing per eseguire entrambi i servizi, anche se un solo servizio deve aumentare la capacità di gestione.

    A differenza dei monoliti, i microservizi separano i moduli dell'applicazione all'interno di propri programmi leggeri, integrati mediante chiamate di rete. I microservizi possono essere scalati in modo indipendente l'uno dall'altro e utilizzano forme di risorse diverse (ad esempio, tipi di macchine VM, allocazioni di vCPU e memoria di Cloud Run o tipi di istanze di App Engine) adatte all'esecuzione del servizio. La scalabilità tramite microservizi consente di utilizzare in modo più efficiente le risorse cloud attraverso una scalabilità granulare e una riduzione dell'over-provisioning, con conseguente riduzione di costi ed emissioni. Per ulteriori informazioni, consulta Refactoring di un monolite in microservizi.

  2. Utilizza servizi cloud che disaccoppiano le risorse di archiviazione e calcolo: alcuni carichi di lavoro per l'elaborazione e l'analisi dei dati on-premise (e basati su cloud), come Apache Hadoop e Apache Spark, spesso condividono la stessa infrastruttura per l'archiviazione dei dati e il calcolo. Se mantieni un ingombro elevato dell'infrastruttura per archiviare i dati, pur avendo lo stesso ingombro per i picchi di calcolo, l'utilizzo delle risorse di calcolo è spesso ridotto. Un basso utilizzo comporta un aumento delle risorse inattive, il che aumenta i costi e genera inutilmente più emissioni.

    Quando esegui la migrazione di questi carichi di lavoro in Google Cloud, ti consigliamo di utilizzare servizi gestiti che separano l'infrastruttura di archiviazione e calcolo, ad esempio:

    • BigQuery: BigQuery è un data warehouse serverless su scala petabyte come servizio. Puoi usare BigQuery per i carichi di lavoro di analisi basati su SQL. L'archiviazione del set di dati in BigQuery è disaccoppiata dalle risorse di calcolo. Questa separazione fa sì che l'archiviazione BigQuery venga scalata per offrire uno spazio di archiviazione praticamente illimitato con un utilizzo efficiente delle risorse. Inoltre, i set di dati possono essere condivisi sul posto senza duplicare i dati o avviare un nuovo cluster.
    • Dataproc: Dataproc è un servizio gestito per i carichi di lavoro Hadoop e Spark. Molti deployment Hadoop e Spark on-premise utilizzano cluster di calcolo sempre attivi, indipendentemente dalle caratteristiche di utilizzo. Sebbene sia possibile creare cluster di lunga durata utilizzando Dataproc, ti consigliamo di creare cluster temporanei quando devi eseguire i job. I dati letti o scritti dai job Dataproc vengono gestiti separatamente in servizi di archiviazione dedicati, come Cloud Storage e Bigtable. Eliminando la necessità di mantenere un ambiente per l'archiviazione Hadoop, anche quando non sono in esecuzione job, riduci la complessità operativa, i costi e le emissioni.
    • Cloud Spanner: Spanner è un servizio di database SQL distribuito e scalabile a livello globale che disaccoppia le risorse di calcolo dall'archiviazione, consentendo di scalare queste risorse separatamente. Puoi anche scalare automaticamente il numero di nodi di risorse di computing per le istanze Spanner utilizzando lo strumento di scalabilità automatica. La scalabilità automatica dei deployment Spanner consente alla tua infrastruttura di adattarsi e scalare automaticamente per soddisfare i requisiti di carico e consente di ridurre i costi e le emissioni di anidride carbonica in caso di carichi ridotti.

  3. Migrazione dei carichi di lavoro ai servizi gestiti: le offerte gestite possono ridurre al minimo le risorse inutilizzate scalando automaticamente i carichi di lavoro e offrono altre funzionalità in grado di ridurre i requisiti di infrastruttura. Per ulteriori informazioni, consulta la sezione Scegliere il servizio cloud più adatto alle precedenti di questo documento.

Riduci le emissioni per i carichi di lavoro batch

A differenza di molti carichi di lavoro di pubblicazione online, i carichi di lavoro batch sono spesso flessibili in termini di dove e quando vengono eseguiti. Esempi di carichi di lavoro batch includono job di computing ad alte prestazioni (HPC) per calcoli scientifici, l'esecuzione di riconciliazioni giornaliere degli account o la generazione di suggerimenti sui prodotti per le email di marketing.

Come per altri carichi di lavoro, ti consigliamo di eseguire carichi di lavoro batch in regioni con una percentuale di CFE maggiore per ridurre l'impronta di carbonio complessiva. Se c'è flessibilità nell'esecuzione dei job batch, potresti essere in grado di ridurre ulteriormente l'impronta di carbonio eseguendo job orari che coincidono con la minore intensità di carbonio della rete. Per visualizzare i dati orari per il mix di griglia e l'intensità di carbonio in diverse località globali in cui si trovano le regioni di Google Cloud, utilizza il sito web electricityMap, gestito da Tomorrow.

I carichi di lavoro batch non dovrebbero essere sensibili alla latenza per definizione, anche se possono esserci dipendenze da sistemi correlati (ad esempio origini dati e sink) che creano overhead di networking indesiderato. Questa dipendenza potrebbe esistere per i job che fanno parte di un'applicazione o un flusso di lavoro più grandi, ad esempio un job di estrazione, trasformazione e caricamento (ETL) che legge i dati da uno o più sistemi di origine e poi scrive i dati trasformati in un data warehouse. Se il job ETL elabora e trasferisce grandi quantità di dati tra regioni cloud, potrebbe non essere pratico o costoso eseguire job separatamente a causa dell'impatto sulle prestazioni della rete e dell'aumento dei costi del traffico in uscita tra regioni.

Ti consigliamo di eseguire i seguenti tipi di carichi di lavoro batch nelle regioni a bassa CO2:

  1. Carichi di lavoro batch autonomi: prendi in considerazione un carico di lavoro HPC autonomo in cui scegliere la regione con le caratteristiche di prezzo e emissioni migliori in base alle tue esigenze, utilizzare i servizi di archiviazione e calcolo in quella regione e scaricare direttamente i risultati dell'analisi. In questo scenario, non esiste traffico tra regioni che potrebbe comportare penalità per le prestazioni della rete o costi per il traffico in uscita dalla rete oltre al recupero dei risultati dell'analisi.

  2. Carichi di lavoro batch che richiedono un trasferimento di dati minimo con altre regioni cloud: prendi in considerazione un'API che fornisce suggerimenti sui prodotti da un modello di machine learning (ML). L'API potrebbe essere ospitata in più regioni cloud per fornire una gestione a bassa latenza agli utenti. I modelli di ML possono essere addestrati periodicamente dai dati dei flussi di clic provenienti dai browser sotto forma di processo batch centralizzato e copiati in ogni regione cloud in cui è ospitata l'API. In questo scenario, gli artefatti del modello di output dei job di addestramento sono piccoli, di circa decine di megabyte.

    In questo scenario, i dati dei flussi di clic per l'addestramento di modelli ML vengono inviati direttamente dai browser alla regione cloud che ospita il backend ML. Quando il backend ML addestra un nuovo set di modelli, il trasferimento di dati per la copia dei modelli in altre aree geografiche cloud è relativamente ridotto (forse nell'ordine delle centinaia di megabyte se è necessario copiare dieci modelli).

Suggerimenti

La seguente tabella riassume i suggerimenti per ridurre l'impatto ambientale di Google Cloud:

Argomento Suggerimenti
Informazioni sulle emissioni di anidride carbonica del cloud

Scopri come la percentuale di energia a zero emissioni di CO2 (CFE%) descrive il consumo di energia a zero emissioni di CO2 delle regioni cloud.

Scopri le principali strategie per ridurre la tua impronta di carbonio.
Comprendi l'impatto ambientale Utilizza lo strumento Carbon Footprint per aiutarti a comprendere l'impatto ambientale derivante dall'utilizzo di Google Cloud.
Scegli le regioni cloud più adatte

Utilizza il selettore della regione Google Cloud per determinare le migliori regioni cloud in base all'impronta di carbonio, al prezzo e alla latenza come considerazioni relative.

Valuta la possibilità di creare criteri dell'organizzazione per limitare l'utilizzo alle regioni a bassa CO2.
Scegli i servizi cloud più adatti

Esegui la migrazione delle VM da data center on-premise meno efficienti a Compute Engine.

Utilizza servizi gestiti su cloud ottimizzati per carichi di lavoro specifici, anziché VM autogestite.
Riduci al minimo le risorse cloud inutilizzate

Utilizza le funzionalità di Active Assist per eliminare le VM inutilizzate, ottimizzare le forme delle VM e arrestare i progetti inattivi.

Identifica le opportunità per creare (ed eliminare) le risorse cloud secondo necessità, invece di conservarle per sempre.

Pianifica le VM per l'avvio e l'arresto in base alle esigenze.

Esegui la migrazione dei carichi di lavoro nei container ed eseguili in modo efficiente utilizzando servizi gestiti come Cloud Run e GKE.

Esegui il refactoring delle applicazioni monolitiche in microservizi per ottenere vantaggi in termini di efficienza.

Utilizza servizi che disaccoppiano le risorse di calcolo e archiviazione per l'elaborazione e l'analisi dei dati.

Esegui la migrazione dei carichi di lavoro delle VM esistenti ai servizi gestiti.
Riduci le emissioni per i carichi di lavoro batch

Esegui carichi di lavoro batch con traffico in uscita tra regioni minimo o nullo in regioni a basse emissioni di CO2.

Esegui carichi di lavoro batch in momenti della giornata che coincidono con una minore intensità di carbonio della rete, ove possibile.

Passaggi successivi