Framework dell'architettura Google Cloud

Last reviewed 2023-11-09 UTC

Puoi stampare questa pagina o salvarla in formato PDF utilizzando la funzione di stampa del browser e scegliere l'opzione Salva come PDF. Per la versione standard di questa pagina, torna al framework dell'architettura.

Il framework dell'architettura Google Cloud fornisce suggerimenti e descrive le best practice per aiutare architect, sviluppatori, amministratori e altri professionisti cloud a progettare e gestire una topologia cloud sicura, efficiente, resiliente, ad alte prestazioni ed economica. Il framework dell'architettura Google Cloud è la nostra versione di un framework ben progettato.

Un team interfunzionale di esperti di Google convalida i suggerimenti di progettazione e le best practice che compongono il framework dell'architettura. Il team cura il framework dell'architettura in modo da riflettere le funzionalità di espansione di Google Cloud, le best practice del settore, le conoscenze della community e il feedback degli utenti. Per un riepilogo delle modifiche significative, consulta la pagina Novità.

Le linee guida alla progettazione nel framework dell'architettura si applicano alle applicazioni create per il cloud e ai carichi di lavoro migrati da on-premise a Google Cloud, a deployment cloud ibrido e ambienti multi-cloud.

Il framework dell'architettura Google Cloud è organizzato in sei categorie (note anche come pilastri), come mostrato nel seguente diagramma:

Design del sistema

Questa categoria è la base del framework dell'architettura Google Cloud. Definire l'architettura, i componenti, i moduli, le interfacce e i dati necessari per soddisfare i requisiti di sistema del cloud e scoprire i prodotti e le funzionalità Google Cloud che supportano la progettazione del sistema.

Eccellenza operativa

Esegui il deployment, opera, monitora e gestisci in modo efficiente i tuoi carichi di lavoro cloud.

Sicurezza, privacy e conformità

Massimizza la sicurezza dei tuoi dati e dei carichi di lavoro nel cloud, progetta per la privacy e allineati ai requisiti e agli standard normativi.

Affidabilità

Progetta e gestisci carichi di lavoro resilienti e ad alta disponibilità nel cloud.

Ottimizzazione dei costi

Massimizza il valore aziendale del tuo investimento in Google Cloud.

Ottimizzazione del rendimento

Progetta e ottimizza le tue risorse cloud per ottenere prestazioni ottimali.

Per visualizzare i riepiloghi dei prodotti Google Cloud e del loro rapporto reciproco, vedi Prodotti, funzionalità e servizi Google Cloud in quattro parole o meno.

Framework dell'architettura Google Cloud: progettazione del sistema

La progettazione del sistema è la categoria di base del framework dell'architettura Google Cloud. Questa categoria fornisce suggerimenti di progettazione e descrive best practice e principi per aiutarti a definire l'architettura, i componenti, i moduli, le interfacce e i dati su una piattaforma cloud per soddisfare i tuoi requisiti di sistema. Scoprirai inoltre i prodotti e le funzionalità di Google Cloud che supportano la progettazione del sistema.

I documenti nella categoria di progettazione del sistema presuppongono che tu comprenda i principi di base di progettazione del sistema. Questi documenti non presuppongono familiarità con i concetti di base del cloud e i prodotti Google Cloud.

Per scenari complessi di migrazione e deployment al cloud, ti consigliamo di utilizzare i servizi di consulenza Google Cloud. I nostri consulenti vantano competenze su best practice e principi guida per aiutarti ad avere successo nel tuo percorso verso il cloud. Google Cloud ha anche un solido ecosistema di partners, che spaziano dai grandi integratori di sistemi globali ai partner con una profonda specializzazione in una determinata area come il machine learning. Ti consigliamo di rivolgerti ai partner Google Cloud per accelerare la tua trasformazione digitale e migliorare i risultati aziendali.

Nota: prima di modificare l'ambiente di produzione, ti consigliamo di sperimentare le nuove funzionalità o il design in un ambiente sandbox.

Nella categoria di progettazione del sistema del framework dell'architettura, imparerai a fare quanto segue:

• Applicare i principi fondamentali della progettazione del sistema.
• Seleziona le regioni geografiche per supportare le tue applicazioni aziendali.
• Gestione delle risorse cloud.
• Scegli e gestisci il computing.
• Progetta la tua infrastruttura di rete.
• Seleziona e implementa una strategia di archiviazione.
• Ottimizza il database.
• Analizza i dati.
• Implementa il machine learning.
• Progetta i tuoi carichi di lavoro cloud per la sostenibilità.

Principi fondamentali della progettazione del sistema

Questo documento nel framework dell'architettura Google Cloud descrive i principi fondamentali della progettazione del sistema. Una solida struttura del sistema è sicura, affidabile, scalabile e indipendente. Consente di apportare modifiche iterative e reversibili senza interrompere il sistema, ridurre al minimo i potenziali rischi e migliorare l'efficienza operativa. Per una solida progettazione del sistema, ti consigliamo di seguire quattro principi.

Documenta tutto

Quando inizi a spostare i carichi di lavoro nel cloud o a creare le tue applicazioni, uno dei principali ostacoli al successo è la mancanza di documentazione del sistema. La documentazione è particolarmente importante per visualizzare correttamente l'architettura dei deployment attuali.

Un'architettura cloud adeguatamente documentata stabilisce un linguaggio e standard comuni, che consentono ai team interfunzionali di comunicare e collaborare in modo efficace. Fornisce inoltre le informazioni necessarie per identificare e guidare le decisioni di progettazione future. La documentazione deve essere scritta in base ai tuoi casi d'uso, in modo da fornire un contesto per le decisioni di progettazione.

Nel tempo, le tue decisioni di progettazione si evolveranno e cambieranno. La cronologia delle modifiche fornisce il contesto necessario ai tuoi team per allineare le iniziative, evitare duplicati e misurare le variazioni delle prestazioni in modo efficace nel tempo. I log delle modifiche sono particolarmente importanti quando si esegue l'onboarding di un nuovo Cloud Architect che non ha ancora familiarità con la progettazione, la strategia o la storia del sistema attuale.

Semplifica la progettazione e utilizza servizi completamente gestiti

La semplicità è fondamentale per la progettazione del sistema. Se la tua architettura è troppo complessa da capire, sarà difficile implementare la progettazione e gestirla nel tempo. Ove possibile, utilizza servizi completamente gestiti per ridurre al minimo i rischi, il tempo e l'impegno associati alla gestione e alla manutenzione dei sistemi di riferimento.

Se esegui già i tuoi carichi di lavoro in produzione, esegui dei test con i servizi gestiti per vedere come potrebbero aiutarti a ridurre le complessità operative. Se stai sviluppando nuovi carichi di lavoro, inizia in modo semplice, definisci un prodotto minimo funzionante (MVP) e resisti alla tentazione di un lavoro eccessivo. Puoi identificare casi d'uso eccezionali, eseguire l'iterazione e migliorare i tuoi sistemi in modo incrementale nel tempo.

Disaccoppia l'architettura

Il disaccoppiamento è una tecnica utilizzata per separare le applicazioni e i componenti di servizio in componenti più piccoli che possono operare in modo indipendente. Ad esempio, potresti suddividere uno stack di applicazione monolitica in componenti di servizio separati. In un'architettura disaccoppiata, un'applicazione può eseguire le sue funzioni in modo indipendente, indipendentemente dalle varie dipendenze.

Un'architettura disaccoppiata offre maggiore flessibilità per:

• Applicare upgrade indipendenti.
• Applicare controlli di sicurezza specifici.
• Stabilire obiettivi di affidabilità per ogni sottosistema.
• Monitorare l'integrità.
• Controlla in modo dettagliato i parametri di costo e prestazioni.

Puoi iniziare il disaccoppiamento fin dalle prime fasi della fase di progettazione o incorporarlo negli upgrade del sistema durante la scalabilità.

Utilizzare un'architettura stateless

Un'architettura stateless può aumentare l'affidabilità e la scalabilità delle tue applicazioni.

Le applicazioni stateful si basano su varie dipendenze per eseguire le attività, ad esempio i dati memorizzati nella cache locale. Le applicazioni stateful spesso richiedono meccanismi aggiuntivi per acquisire i progressi e riavviarli senza problemi. Le applicazioni stateless possono eseguire attività senza dipendenze locali significative utilizzando l'archiviazione condivisa o i servizi memorizzati nella cache. Un'architettura stateless consente di fare lo scale up delle applicazioni con dipendenze di avvio minime. Le applicazioni possono resistere ai riavvii rigidi, avere tempi di inattività ridotti e offrire prestazioni migliori per gli utenti finali.

La categoria di progettazione del sistema descrive i suggerimenti per rendere le tue applicazioni stateless o per utilizzare funzionalità cloud-native per migliorare l'acquisizione dello stato delle macchine per le applicazioni stateful.

Passaggi successivi

• Seleziona le regioni geografiche per supportare le tue applicazioni aziendali.
• Gestione delle risorse cloud.
• Scegli e gestisci il computing.
• Progetta la tua infrastruttura di rete.
• Seleziona e implementa una strategia di archiviazione.
• Ottimizza il database.
• Analizza i dati.
• Implementa il machine learning.
• Progetta i tuoi carichi di lavoro cloud per la sostenibilità.

Scegli gli archetipi di deployment di Google Cloud

Questo documento nel framework dell'architettura Google Cloud descrive sei archetipi di deployment¹ (a livello di zona, a livello di regione, multiregionale, globale, ibrida e multi-cloud) che puoi utilizzare per creare architetture per i tuoi carichi di lavoro cloud in base ai tuoi requisiti di disponibilità, costo, prestazioni ed efficienza operativa.

Cos'è un archetipo di deployment?

Un archetipo di deployment è un modello astratto indipendente dal provider che puoi utilizzare come base per creare architetture di deployment specifiche dell'applicazione che soddisfino i tuoi requisiti aziendali e tecnici. Ogni archetipo di deployment specifica una combinazione di domini in errore in cui può essere eseguita un'applicazione. Questi domini in errore possono essere una o più zone o regioni Google Cloud e possono estendersi per includere i tuoi data center on-premise o i domini in errore in altri cloud provider.

Il seguente diagramma mostra sei applicazioni di cui è stato eseguito il deployment in Google Cloud. Ogni applicazione utilizza un archetipo di deployment che soddisfa i suoi requisiti specifici.

Come mostra il diagramma precedente, in un'architettura che utilizza l'archetipo di deployment ibrido o multi-cloud, la topologia cloud si basa su uno degli archetipi di base: a livello di zona, a livello di regione, multiregionale o globale. In questo senso, gli archetipi di deployment ibrido e multi-cloud possono essere considerati come archetipi di deployment compositi che includono uno degli archetipi di base.

Nota: gli archetipi di deployment sono diversi dagli ambiti di località. L'ambito della località di una risorsa Google Cloud definisce i confini della disponibilità. Ad esempio, l'ambito relativo alla località di una VM di Compute Engine è a livello di zona. Ciò significa che se si verifica un'interruzione della zona Google Cloud in cui viene eseguito il provisioning di una VM, la disponibilità della VM ne risenti. Tuttavia, distribuendo le VM su più zone, puoi creare un'architettura ad alta disponibilità basata sull'archetipo di deployment regionale.

La scelta di un archetipo di deployment consente di semplificare le decisioni successive relative ai prodotti e alle funzionalità di Google Cloud da utilizzare. Ad esempio, per un'applicazione containerizzata a disponibilità elevata, se scegli l'archetipo di deployment a livello di regione, i cluster Google Kubernetes Engine (GKE) regionali sono più appropriati dei cluster GKE a livello di zona.

Quando scegli un archetipo di deployment per un'applicazione, devi considerare dei compromessi tra fattori quali disponibilità, costo e complessità operativa. Ad esempio, se un'applicazione serve gli utenti in più paesi e ha bisogno di un'alta disponibilità, puoi scegliere l'archetipo di deployment multiregionale. Tuttavia, per un'applicazione interna utilizzata da dipendenti di una singola area geografica, potresti dare la priorità al costo rispetto alla disponibilità e, di conseguenza, scegliere l'archetipo di deployment a livello di regione.

Panoramica degli archetipi di deployment

Le seguenti schede forniscono le definizioni degli archetipi di deployment e un riepilogo dei casi d'uso e le considerazioni sulla progettazione per ciascuno.

Zonale

L'applicazione viene eseguita all'interno di una singola zona Google Cloud, come mostrato nel seguente diagramma:

Casi d'uso	Ambienti di sviluppo e test. Applicazioni che non richiedono un'alta disponibilità. Networking a bassa latenza tra i componenti delle applicazioni. Migrazione dei carichi di lavoro di base. Applicazioni che utilizzano software limitato alla licenza.
Note sul layout	Tempo di riposo durante le interruzioni delle zone. Per la continuità aziendale, puoi eseguire il provisioning di una replica passiva dell'applicazione in un'altra zona nella stessa regione. In caso di interruzione di una zona, puoi ripristinare l'applicazione in produzione utilizzando la replica passiva.
Ulteriori informazioni	Consulta le seguenti sezioni: Archetipo di deployment a livello di zona Analisi comparativa di tutti gli archetipi di deployment

Regionale

L'applicazione viene eseguita in modo indipendente in due o più zone all'interno di una singola regione Google Cloud, come mostrato nel seguente diagramma:

Casi d'uso	Applicazioni ad alta disponibilità che servono gli utenti all'interno di un'area geografica. Conformità con i requisiti di residenza e sovranità dei dati.
Note sul layout	Tempo di riposo durante le interruzioni della regione. Per la continuità aziendale, puoi eseguire il backup dell'applicazione e dei dati in un'altra regione. In caso di interruzione di una regione, puoi utilizzare i backup nell'altra regione per ripristinare l'applicazione in produzione. Costi e sforzi per eseguire il provisioning e gestire le risorse ridondanti.
Ulteriori informazioni	Consulta le seguenti sezioni: Archetipo di deployment a livello di regione Analisi comparativa di tutti gli archetipi di deployment

Multiregionale

L'applicazione viene eseguita in modo indipendente in più zone in due o più regioni Google Cloud. Puoi utilizzare i criteri di routing DNS per instradare il traffico in entrata ai bilanciatori del carico a livello di regione. I bilanciatori del carico a livello di regione distribuiscono quindi il traffico alle repliche a livello di zona dell'applicazione, come mostrato nel seguente diagramma:

Casi d'uso	Applicazione a disponibilità elevata con utenti dislocati in varie aree geografiche. Applicazioni che richiedono un'esperienza a bassa latenza dell'utente finale. Conformità ai requisiti di residenza dei dati e di sovranità mediante l'utilizzo di un criterio di routing DNS con recinti virtuali.
Note sul layout	Costo per trasferimento dei dati e replica dei dati tra regioni. Complessità operativa.
Ulteriori informazioni	Consulta le seguenti sezioni: Archetipo di deployment multiregionale Analisi comparativa di tutti gli archetipi di deployment

A livello mondiale

L'applicazione viene eseguita nelle regioni Google Cloud di tutto il mondo, come stack distribuito a livello globale (senza rilevare la posizione) o come stack isolati a livello di regione. Un bilanciatore del carico anycast globale distribuisce il traffico nella regione più vicina all'utente. Anche altri componenti dello stack di applicazioni possono essere globali, ad esempio database, cache e archivio di oggetti.

Il seguente diagramma mostra la variante distribuita a livello globale dell'archetipo di deployment globale. Un bilanciatore del carico anycast globale inoltra le richieste a uno stack di applicazioni distribuito in più regioni e che utilizza un database replicato a livello globale.

Il seguente diagramma mostra una variante dell'archetipo di deployment globale con stack di applicazioni isolati a livello di regione. Un bilanciatore del carico anycast globale inoltra le richieste a uno stack di applicazioni in una delle regioni. Tutti gli stack di applicazioni utilizzano un unico database replicato a livello globale.

Casi d'uso	Applicazioni ad alta disponibilità per utenti dislocati in tutto il mondo. Opportunità di ottimizzare i costi e semplificare le operazioni utilizzando risorse globali anziché più istanze di risorse a livello di regione.
Note sul layout	Costi per il trasferimento dei dati e la replica dei dati tra regioni.
Ulteriori informazioni	Consulta le seguenti sezioni: Archetipo di deployment globale Analisi comparativa di tutti gli archetipi di deployment

Ibrido

Il deployment di alcune parti dell'applicazione viene eseguito in Google Cloud, mentre altre vengono eseguite on-premise, come mostrato nel diagramma seguente. La topologia in Google Cloud può utilizzare l'archetipo di deployment a livello di zona, di regione, multiregionale o globale.

Casi d'uso	Sito per il ripristino di emergenza (RE) per i carichi di lavoro on-premise. Sviluppo on-premise per applicazioni cloud. Migrazione progressiva al cloud per le applicazioni legacy. Miglioramento delle applicazioni on-premise con funzionalità cloud.
Note sul layout	Imposta l'impegno e la complessità operativa. Costo delle risorse ridondanti.
Ulteriori informazioni	Consulta le seguenti sezioni: Archetipo di deployment ibrido Analisi comparativa di tutti gli archetipi di deployment

Multi-cloud

Il deployment di alcune parti della tua applicazione viene eseguito in Google Cloud, mentre altre in altre piattaforme cloud, come illustrato nel seguente schema. La topologia in ogni piattaforma cloud può utilizzare l'archetipo di deployment a livello di zona, a livello di regione, multiregionale o globale.

Casi d'uso	Google Cloud come sito principale e un altro cloud come sito di RE. Miglioramento delle applicazioni con le funzionalità avanzate di Google Cloud.
Note sul layout	Imposta l'impegno e la complessità operativa. Costo delle risorse ridondanti e del traffico di rete tra cloud.
Ulteriori informazioni	Consulta le seguenti sezioni: Archetipo di deployment multi-cloud Analisi comparativa di tutti gli archetipi di deployment

Seleziona zone e regioni

Questo documento nel framework dell'architettura Google Cloud fornisce best practice per il deployment del sistema in base ai requisiti geografici. Imparerai a selezionare le zone geografiche e le regioni ottimali in base alla disponibilità e alla vicinanza, per supportare la conformità, ottimizzare i costi e implementare il bilanciamento del carico.

Quando selezioni una o più regioni per le tue applicazioni aziendali, devi prendere in considerazione vari criteri, tra cui disponibilità dei servizi, latenza per l'utente finale, latenza delle applicazioni, costi e requisiti normativi o di sostenibilità. Per supportare le priorità e le politiche della tua attività, trova un equilibrio tra questi requisiti e identifica i compromessi migliori. Ad esempio, la regione più conforme potrebbe non essere quella più conveniente o potrebbe non avere l'impronta di carbonio più bassa.

Esegui il deployment in più regioni

Le regioni sono aree geografiche indipendenti composte da più zone. Una zona è un'area di deployment per le risorse Google Cloud all'interno di una regione; ogni zona rappresenta un singolo dominio in errore all'interno di una regione.

Per proteggerti dai tempi di inattività previsti (compresa la manutenzione) e da tempi di inattività imprevisti come gli incidenti, ti consigliamo di eseguire il deployment di applicazioni a tolleranza di errore ad alta disponibilità e le tue applicazioni in più zone in una o più regioni. Per saperne di più, consulta Area geografica e regioni, Considerazioni sul deployment delle applicazioni e Best practice per la selezione delle regioni di Compute Engine.

I deployment multi-zona possono fornire resilienza se i deployment multiregionali sono limitati a causa dei costi o di altre considerazioni. Questo approccio è particolarmente utile per prevenire interruzioni a livello di zona o di regione e per risolvere problemi di ripristino di emergenza e continuità aziendale. Per maggiori informazioni, consulta Progettare per la scalabilità e la disponibilità elevata.

Seleziona le regioni in base alla vicinanza geografica

La latenza influisce sull'esperienza utente e sui costi associati alla gestione degli utenti esterni. Per ridurre al minimo la latenza quando gestisci il traffico a utenti esterni, seleziona una regione o un insieme di regioni geograficamente vicine ai tuoi utenti e in cui i tuoi servizi vengono eseguiti in modo conforme. Per ulteriori informazioni, consulta le località cloud e il Centro risorse per la conformità.

Seleziona le regioni in base ai servizi disponibili

Seleziona una regione in base ai servizi disponibili richiesti dalla tua azienda. La maggior parte dei servizi è disponibile in tutte le regioni. Alcuni servizi specifici dell'azienda potrebbero essere disponibili in un sottoinsieme di regioni con la release iniziale. Per verificare la selezione della regione, consulta Località cloud.

Scegli le regioni per supportare la conformità

Seleziona una regione o un insieme di regioni specifici per soddisfare le normative geografiche o di conformità che richiedono l'utilizzo di determinate aree geografiche, ad esempio il Regolamento generale sulla protezione dei dati (GDPR) o la residenza dei dati. Per scoprire di più sulla progettazione di sistemi sicuri, consulta le pagine Offerte di conformità e Residenza dei dati, trasparenza operativa e privacy per i clienti europei su Google Cloud.

Confronta i prezzi delle principali risorse

Le regioni hanno tariffe diverse per gli stessi servizi. Per identificare una regione economicamente conveniente, confronta i prezzi delle principali risorse che prevedi di utilizzare. Le considerazioni sui costi variano a seconda dei requisiti e delle risorse di backup, come computing, networking e archiviazione dei dati. Per scoprire di più, consulta la categoria di ottimizzazione dei costi.

Usa Cloud Load Balancing per gli utenti globali

Per migliorare l'esperienza utente quando gestisci gli utenti globali, utilizza Cloud Load Balancing per fornire un singolo indirizzo IP instradato alla tua applicazione. Per scoprire di più sulla progettazione di sistemi affidabili, consulta Framework dell'architettura Google Cloud: affidabilità.

Usa lo strumento per la selezione della regione Google Cloud per supportare la sostenibilità

Google è una società carbon neutral dal 2007 e si impegna a raggiungere l'obiettivo di zero emissioni di CO2 entro il 2030. Per selezionare una regione in base alla sua impronta di carbonio, utilizza il selettore della regione di Google Cloud. Per scoprire di più sulla progettazione per la sostenibilità, consulta Sostenibilità di Cloud.

Passaggi successivi

Scopri come gestire le risorse cloud utilizzando Resource Manager, la gerarchia delle risorse di Google Cloud e il Servizio Criteri dell'organizzazione.

Esplora altre categorie nel framework dell'architettura come affidabilità, eccellenza operativa e sicurezza, privacy e conformità.

Gestione delle risorse cloud

Questo documento nel framework dell'architettura Google Cloud fornisce le best practice per organizzare e gestire le tue risorse in Google Cloud.

Gerarchia delle risorse

Le risorse Google Cloud sono organizzate gerarchicamente in organizzazioni, cartelle e progetti. Questa gerarchia consente di gestire gli aspetti comuni delle risorse, come controllo dell'accesso, le impostazioni di configurazione e i criteri. Per le best practice sulla progettazione della gerarchia delle risorse cloud, consulta Decidere una gerarchia delle risorse per la zona di destinazione di Google Cloud.

Etichette e tag delle risorse

Questa sezione fornisce le best practice per l'utilizzo di etichette e tag al fine di organizzare le risorse Google Cloud.

Usa una struttura di cartelle semplice

Le cartelle ti consentono di raggruppare qualsiasi combinazione di progetti e sottocartelle. Crea una semplice struttura di cartelle per organizzare le risorse Google Cloud. Puoi aggiungere altri livelli in base alle esigenze per definire la gerarchia delle risorse in modo che supporti le tue esigenze aziendali. La struttura delle cartelle è flessibile ed estensibile.Per ulteriori informazioni, consulta Creazione e gestione delle cartelle.

Usa cartelle e progetti per riflettere i criteri di governance dei dati

Utilizza cartelle, sottocartelle e progetti per separare le risorse l'una dall'altra e riflettere i criteri di governance dei dati all'interno della tua organizzazione. Ad esempio, puoi utilizzare una combinazione di cartelle e progetti per separare le risorse finanziarie, umane e di progettazione.

Usa i progetti per raggruppare le risorse che condividono gli stessi confini di attendibilità. Ad esempio, le risorse per lo stesso prodotto o microservizio possono appartenere allo stesso progetto. Per maggiori informazioni, consulta Decidere una gerarchia di risorse per la tua zona di destinazione Google Cloud.

Usa tag ed etichette all'avvio del progetto

Usa etichette e tag quando inizi a usare i prodotti Google Cloud, anche se non ti servono immediatamente. L'aggiunta di etichette e tag in un secondo momento può richiedere uno sforzo manuale, soggetto a errori e difficile da completare.

Un tag fornisce un modo per consentire o negare in modo condizionale i criteri a seconda che una risorsa abbia un tag specifico. Un'etichetta è una coppia chiave-valore utile per organizzare le istanze Google Cloud. Per maggiori informazioni sulle etichette, consulta i requisiti per le etichette, l'elenco dei servizi che supportano le etichette e i formati delle etichette.

Resource Manager fornisce etichette e tag per aiutarti a gestire le risorse, allocare e generare report sui costi e assegnare criteri a risorse diverse per controlli dell'accesso granulari. Ad esempio, puoi utilizzare etichette e tag per applicare principi granulari di accesso e gestione a diverse risorse e servizi tenant. Per informazioni sulle etichette delle VM e sui tag di rete, consulta Relazione tra etichette delle VM e tag di rete.

Puoi utilizzare le etichette per più scopi, tra cui:

• Gestione della fatturazione delle risorse: le etichette sono disponibili nel sistema di fatturazione, il che consente di separare i costi per etichette. Ad esempio, puoi etichettare centri di costo o budget diversi.
• Raggruppamento delle risorse in base a caratteristiche simili o relazioni: puoi utilizzare le etichette per separare fasi o ambienti del ciclo di vita dell'applicazione diversi. Ad esempio, puoi etichettare gli ambienti di produzione, sviluppo e test.

Assegnazione di etichette per supportare i report sui costi e sulla fatturazione

Per supportare report granulari sui costi e sulla fatturazione in base ad attributi esterni alle strutture di generazione di report integrate (ad esempio per progetto o per tipo di prodotto), assegna etichette alle risorse. Le etichette consentono di assegnare il consumo a centri di costo, reparti, progetti specifici o meccanismi di ricarica interni. Per ulteriori informazioni, consulta la categoria di ottimizzazione dei costi.

Evita di creare un numero elevato di etichette

Evita di creare un numero elevato di etichette. Ti consigliamo di creare etichette principalmente a livello di progetto e di evitare di crearle a livello di team secondario. Se crei etichette troppo granulari, potresti aggiungere rumore ai tuoi dati e analisi. Per informazioni sui casi d'uso comuni delle etichette, consulta Utilizzi comuni delle etichette.

Evita di aggiungere informazioni sensibili alle etichette

Le etichette non sono progettate per gestire informazioni sensibili. Non includere informazioni sensibili nelle etichette, comprese informazioni che potrebbero essere identificabili personalmente, come il nome o il titolo di una persona.

Anonimizza le informazioni nei nomi dei progetti

Segui un modello di denominazione dei progetti come COMPANY_INITIAL_IDENTIFIER-ENVIRONMENT-APP_NAME, in cui i segnaposto sono univoci e non rivelano i nomi di aziende o applicazioni. Non includere attributi che possono cambiare in futuro, ad esempio il nome di un team o una tecnologia.

Applica i tag per modellare le dimensioni aziendali

Puoi applicare tag per modellare dimensioni aziendali aggiuntive, come struttura organizzativa, regioni, tipi di carichi di lavoro o centri di costo. Per saperne di più sui tag, consulta Panoramica dei tag, Eredità dei tag e Creazione e gestione dei tag. Per informazioni su come utilizzare i tag con i criteri, consulta Criteri e tag. Per scoprire come utilizzare i tag per gestire il controllo dell'accesso'accesso, consulta Tag e controllo dell'accesso.

Criteri dell'organizzazione

Questa sezione fornisce le best practice per configurare le regole di governance delle risorse Google Cloud nella gerarchia delle risorse cloud.

Stabilire convenzioni di denominazione per i progetti

Stabilisci una convenzione di denominazione dei progetti standardizzata, ad esempio SYSTEM_NAME-ENVIRONMENT (dev, test, uat, stage, prod).

I nomi di progetto hanno un limite di 30 caratteri.

Anche se puoi applicare un prefisso come COMPANY_TAG-SUB_GROUP/SUBSIDIARY_TAG, i nomi dei progetti possono diventare obsoleti quando le aziende vengono riorganizzate. Valuta la possibilità di spostare i nomi identificabili dai nomi dei progetti alle etichette del progetto.

Automatizza la creazione dei progetti

Per creare progetti per aziende di produzione e su larga scala, utilizza un processo automatico come Deployment Manager o il modulo Terraform per la fase di sviluppo di progetti Google Cloud. Questi strumenti:

• Crea automaticamente ambienti o progetti di sviluppo, test e produzione con le autorizzazioni appropriate.
• Configura logging e monitoraggio.

Il modulo Terraform per la fabbrica di progetti Google Cloud consente di automatizzare la creazione di progetti Google Cloud. Nelle aziende di grandi dimensioni, consigliamo di rivedere e approvare i progetti prima di crearli in Google Cloud. Questa procedura consente di garantire quanto segue:

• È possibile attribuire i costi. Per ulteriori informazioni, consulta la categoria di ottimizzazione dei costi.
• I caricamenti di dati sono in atto.
• Sono soddisfatti i requisiti normativi o di conformità.

Quando automatizzi la creazione e la gestione di progetti e risorse Google Cloud, ottieni il vantaggio di coerenza, riproducibilità e testbilità. Trattare la configurazione come codice consente di gestire e gestire il ciclo di vita della configurazione insieme agli artefatti software. L'Automation ti consente di supportare best practice come convenzioni di denominazione ed etichettatura coerenti delle risorse. Con l'evolversi dei requisiti, l'automazione semplifica il refactoring.

Controlla i tuoi sistemi regolarmente

Per assicurarti che le richieste di nuovi progetti possano essere controllate e approvate, integra il sistema di gestione delle richieste di assistenza della tua azienda o un sistema autonomo che fornisce l'auditing.

Configura i progetti in modo coerente

Configura progetti in modo da soddisfare in modo coerente le esigenze della tua organizzazione. Quando configuri i progetti, includi quanto segue:

• ID progetto e convenzioni di denominazione
• Collegamento dell'account di fatturazione
• Configurazione della rete
• API e servizi abilitati
• Configurazione degli accessi a Compute Engine
• Esportazione dei log e report sull'utilizzo
• Blocco della rimozione del progetto

Disaccoppia e isola carichi di lavoro o ambienti

Quote e limiti vengono applicati a livello di progetto. Per gestire quote e limiti, disaccoppia e isola i carichi di lavoro o gli ambienti a livello di progetto. Per ulteriori informazioni, consulta Utilizzo delle quote.

Il disaccoppiamento degli ambienti è diverso dai requisiti di classificazione dei dati. La separazione dei dati dall'infrastruttura può essere costosa e complessa da implementare, perciò ti consigliamo di implementare la classificazione dei dati in base alla sensibilità dei dati e ai requisiti di conformità.

Forza l'isolamento della fatturazione

Applica l'isolamento della fatturazione per supportare diversi account di fatturazione e la visibilità dei costi per carico di lavoro e ambiente. Per ulteriori informazioni, vedi Creare, modificare o chiudere l'account di fatturazione Cloud self-service e Attivare, disattivare o modificare la fatturazione per un progetto.

Per ridurre al minimo la complessità amministrativa, utilizza controlli granulari degli accessi per gli ambienti critici a livello di progetto o per i carichi di lavoro distribuiti in più progetti. Scegliendo controllo dell'accesso per le applicazioni di produzione critiche, ti assicuri che i carichi di lavoro siano protetti e gestiti in modo efficace.

Usa il servizio Criteri dell'organizzazione per controllare le risorse

Il Servizio Criteri dell'organizzazione fornisce agli amministratori dei criteri un controllo centralizzato e programmatico sulle risorse cloud della tua organizzazione per poter configurare vincoli nella gerarchia delle risorse. Per maggiori informazioni, consulta Aggiungere un amministratore dei criteri dell'organizzazione.

Usa il servizio Criteri dell'organizzazione per rispettare i criteri normativi

Per soddisfare i requisiti di conformità, utilizza il servizio Criteri dell'organizzazione per applicare i requisiti di conformità per la condivisione e l'accesso alle risorse. Ad esempio, puoi limitare la condivisione con parti esterne o determinare dove eseguire il deployment delle risorse cloud geograficamente. Altri scenari di conformità includono:

• Centralizzazione del controllo per configurare limitazioni che definiscono le modalità di utilizzo delle risorse dell'organizzazione.
• Definire e stabilire criteri per aiutare i team di sviluppo a rimanere entro i limiti di conformità.
• Aiutano i proprietari dei progetti e i loro team ad apportare modifiche al sistema mantenendo la conformità normativa e riducendo al minimo i problemi di violazione delle regole di conformità.

Limitare la condivisione delle risorse in base al dominio

Un criterio dell'organizzazione di condivisione limitata consente di impedire la condivisione delle risorse Google Cloud con identità all'esterno dell'organizzazione. Per ulteriori informazioni, consulta Limitazione delle identità per dominio e Vincoli dei criteri dell'organizzazione.

Disattivare l'account di servizio e la creazione di chiavi

Per migliorare la sicurezza, limita l'utilizzo degli account di servizio Identity and Access Management (IAM) e delle chiavi corrispondenti. Per maggiori informazioni, consulta Limitare l'utilizzo degli account di servizio.

Limita la località fisica delle nuove risorse

Limita la località fisica delle risorse appena create limitando le località delle risorse. Per visualizzare un elenco dei vincoli che ti consentono di controllare le risorse della tua organizzazione, vedi Vincoli del servizio Criteri dell'organizzazione.

Passaggi successivi

Scopri come scegliere e gestire il computing, incluso quanto segue:

• Approccio alla migrazione del computing.

• Progetta i carichi di lavoro e scala i tuoi carichi di lavoro.

• Gestire le operazioni.

• Gestisci le migrazioni delle VM.

Esplora altre categorie nel framework dell'architettura come affidabilità, eccellenza operativa e sicurezza, privacy e conformità.

Scelta e gestione delle risorse di computing

Questo documento nel framework dell'architettura Google Cloud fornisce best practice per il deployment del sistema in base ai requisiti di calcolo. Imparerai a scegliere una piattaforma di computing e un approccio alla migrazione, a progettare e scalare i carichi di lavoro e a gestire le operazioni e le migrazioni delle VM.

Il calcolo è il fulcro di molti carichi di lavoro, sia per l'esecuzione di una logica di business personalizzata sia per l'applicazione di algoritmi di calcolo complessi su set di dati. La maggior parte delle soluzioni utilizza in qualche modo risorse di calcolo ed è fondamentale selezionare le risorse di computing adatte alle tue esigenze dell'applicazione.

Google Cloud offre diverse opzioni per l'utilizzo del tempo su una CPU. Le opzioni si basano sui tipi di CPU, sulle prestazioni e sulla modalità di pianificazione del codice, inclusa la fatturazione per l'utilizzo.

Le opzioni di calcolo di Google Cloud includono quanto segue:

• Macchine virtuali (VM) con vantaggi specifici per il cloud come la migrazione live.
• "Bin packing" dei container su macchine cluster che possono condividere CPU.
• Funzioni e approcci serverless, in cui l'utilizzo del tempo di CPU può essere misurato in base al lavoro eseguito durante una singola richiesta HTTP.

Scegliere il computing

Questa sezione fornisce le best practice per scegliere e migrare a una piattaforma di computing.

Scegli una piattaforma di computing

Quando scegli una piattaforma di computing per il tuo carico di lavoro, considera i requisiti tecnici del carico di lavoro, dei processi di automazione del ciclo di vita, della regionalizzazione e della sicurezza.

Valuta la natura di utilizzo della CPU da parte della tua app e dell'intero sistema di supporto, incluse le modalità di pacchettizzazione, deployment, distribuzione e richiamo del tuo codice. Sebbene alcuni scenari possano essere compatibili con più opzioni di piattaforma, un carico di lavoro portatile dovrebbe essere in grado di funzionare su una serie di opzioni di calcolo.

La seguente tabella offre una panoramica dei servizi di computing di Google Cloud consigliati per vari casi d'uso:

Piattaforma di computing	Casi d'uso	Prodotti consigliati
Serverless	Esegui il deployment della tua prima app. Concentrati sui dati e sulla logica di elaborazione e sullo sviluppo delle app, anziché gestire le operazioni dell'infrastruttura.	Cloud Run: inserisci la logica di business nei container con questa opzione serverless completamente gestita. Cloud Run è progettato per carichi di lavoro ad alta intensità di calcolo, ma non sempre attivi. Scala in modo economico da 0 (senza traffico) e definisci CPU e RAM delle tue attività e dei tuoi servizi. Esegui il deployment con un singolo comando e Google esegue automaticamente il provisioning della quantità corretta di risorse. Cloud Functions: separa il codice in pezzi flessibili della logica di business senza che tu debba preoccuparti di infrastruttura per bilanciamento del carico, aggiornamenti, autenticazione o scalabilità.
Kubernetes	Crea architetture di microservizi complesse che necessitano di servizi aggiuntivi come Istio per gestire il controllo del mesh di servizi.	Google Kubernetes Engine: un motore di orchestrazione dei container open source che automatizza il deployment, la scalabilità e la gestione delle app containerizzate.
Macchine virtuali (VM)	Crea ed esegui VM da famiglie di VM predefinite e personalizzabili che supportano i requisiti delle tue applicazioni e dei tuoi carichi di lavoro, nonché software e servizi di terze parti.	Compute Engine: aggiungi GPU (Graphics Processing Unit) alle istanze VM. Puoi utilizzare queste GPU per accelerare carichi di lavoro specifici sulle tue istanze, come il machine learning e l'elaborazione di dati. Per selezionare i tipi di macchine appropriati in base ai tuoi requisiti, consulta i Suggerimenti per le famiglie di macchine.

Per saperne di più, consulta Scegliere le opzioni di calcolo.

Scegli un approccio alla migrazione del computing

Se stai eseguendo la migrazione delle tue applicazioni esistenti da un altro cloud o da on-premise, utilizza uno dei seguenti prodotti Google Cloud per ottimizzare prestazioni, scalabilità, costi e sicurezza.

Obiettivo di migrazione	Caso d'uso	Prodotto consigliato
Lift and shift	Esegui la migrazione o estendi i tuoi carichi di lavoro VMware su Google Cloud in pochi minuti.	Google Cloud VMware Engine
Lift and shift	Sposta le tue applicazioni basate su VM in Compute Engine.	Migrazione alle macchine virtuali
Upgrade ai container	Modernizza le applicazioni tradizionali trasformandole in container integrati su Google Kubernetes Engine.	Migrazione ai container

Per scoprire come eseguire la migrazione dei carichi di lavoro allineando i team interni, consulta Ciclo di vita della migrazione delle VM e Creazione di un programma di migrazione su larga scala con Google Cloud.

Progettazione dei carichi di lavoro

Questa sezione fornisce le best practice per la progettazione di carichi di lavoro che supportino il tuo sistema.

Valuta le opzioni serverless per una logica semplice

La logica semplice è un tipo di calcolo che non richiede hardware o tipi di macchina specializzati, come le macchine ottimizzate per la CPU. Prima di investire nelle implementazioni di Google Kubernetes Engine (GKE) o Compute Engine per astrarre l'overhead operativo e ottimizzare costi e prestazioni, valuta le opzioni serverless per una logica leggera.

Disaccoppia le applicazioni in modo che siano stateless

Ove possibile, disaccoppia le tue applicazioni in modo che siano stateless per massimizzare l'uso delle opzioni di serverless computing. Questo approccio consente di utilizzare offerte di computing gestito, scalare le applicazioni in base alla domanda e ottimizzare costi e prestazioni. Per ulteriori informazioni sul disaccoppiamento dell'applicazione per progettare la scalabilità e la disponibilità elevata, consulta Progettare per la scalabilità e la disponibilità elevata.

Usa la logica di memorizzazione nella cache quando disaccoppi le architetture

Se l'applicazione è progettata per essere stateful, utilizza la logica di memorizzazione nella cache per disaccoppiare e rendere scalabile il carico di lavoro. Per maggiori informazioni, consulta le best practice per i database.

Utilizza le migrazioni live per semplificare gli upgrade

Per facilitare gli upgrade per la manutenzione di Google, utilizza la migrazione live impostando i criteri di disponibilità delle istanze. Per maggiori informazioni, consulta Impostare i criteri di manutenzione dell'host VM.

Scalabilità dei carichi di lavoro

Questa sezione fornisce best practice per la scalabilità dei carichi di lavoro a supporto del tuo sistema.

Usa gli script di avvio e arresto

Per le applicazioni stateful, ove possibile, utilizza gli script di avvio e arresto per avviare e arrestare lo stato dell'applicazione in modo controllato. Si parla di avvio protetto quando un computer viene attivato da una funzione software e il sistema operativo può eseguire le proprie attività di avvio sicuro dei processi e dell'apertura delle connessioni.

Le startup e le chiusure efficienti sono importanti perché le applicazioni stateful dipendono dalla disponibilità immediata dei dati in prossimità del computing, di solito su dischi locali o permanenti o nella RAM. Per evitare di eseguire i dati dell'applicazione dall'inizio per ogni avvio, utilizza uno script di avvio per ricaricare gli ultimi dati salvati ed eseguire il processo da dove era interrotto in precedenza al momento dello arresto. Per salvare lo stato della memoria dell'applicazione ed evitare di perdere i progressi durante l'arresto, utilizza uno script di chiusura. Ad esempio, utilizza uno script di arresto quando è pianificato l'arresto di una VM a causa di scale down o eventi di manutenzione di Google.

Usa i gruppi di istanze gestite per supportare la gestione delle macchine virtuali

Quando utilizzi le VM di Compute Engine, i gruppi di istanze gestite (MIG) supportano funzionalità come riparazione automatica, bilanciamento del carico, scalabilità automatica, aggiornamento automatico e carichi di lavoro stateful. Puoi creare gruppi di istanze gestite a livello di zona o di regione in base ai tuoi obiettivi di disponibilità. Puoi utilizzare i gruppi di istanze gestite per carichi di lavoro stateless o in batch e per applicazioni stateful che devono preservare lo stato unico di ogni VM.

Utilizza i gestori della scalabilità automatica dei pod per scalare i carichi di lavoro GKE

Utilizza i gestore della scalabilità automatica pod orizzontale e verticale per scalare i carichi di lavoro e il provisioning automatico dei nodi per scalare le risorse di computing sottostanti.

Distribuisci il traffico dell'applicazione

Per scalare le tue applicazioni a livello globale, utilizza Cloud Load Balancing per distribuire le istanze dell'applicazione in più regioni o zone. I bilanciatori del carico ottimizzano il routing dei pacchetti dalle reti perimetrali di Google Cloud alla zona più vicina, aumentando l'efficienza del traffico di gestione e riducendo al minimo i costi di gestione. Per ottimizzare la latenza dell'utente finale, utilizza Cloud CDN per memorizzare nella cache i contenuti statici, ove possibile.

Automatizza la creazione e la gestione del calcolo

Riduci al minimo gli errori umani nel tuo ambiente di produzione automatizzando la creazione e la gestione dei calcoli.

Gestione delle operazioni

Questa sezione fornisce le best practice per gestire le operazioni a supporto del tuo sistema.

Usa le immagini pubbliche fornite da Google

Usa immagini pubbliche fornite da Google Cloud. Le immagini pubbliche di Google Cloud vengono aggiornate regolarmente. Per maggiori informazioni, consulta Elenco delle immagini pubbliche disponibili su Compute Engine.

Puoi anche creare immagini personalizzate con configurazioni e impostazioni specifiche. Se possibile, automatizza e centralizza la creazione di immagini in un progetto separato che puoi condividere con gli utenti autorizzati all'interno della tua organizzazione. La creazione e la selezione di un'immagine personalizzata in un progetto separato ti consente di aggiornare, applicare patch e creare una VM utilizzando le tue configurazioni. Puoi quindi condividere l'immagine VM selezionata con i progetti pertinenti.

Usa gli snapshot per i backup delle istanze

Gli snapshot ti consentono di creare backup per le tue istanze. Gli snapshot sono particolarmente utili per le applicazioni stateful, che non sono sufficientemente flessibili per mantenere lo stato o salvare l'avanzamento in caso di arresti improvvisi. Se utilizzi spesso gli snapshot per creare nuove istanze, puoi ottimizzare il processo di backup creando un'immagine di base a partire da questi snapshot.

Usa un'immagine della macchina per abilitare la creazione di istanze VM

Sebbene uno snapshot acquisisca solo un'immagine dei dati all'interno di una macchina, un'immagine macchina acquisisce le configurazioni e le impostazioni della macchina, oltre ai dati. Utilizza un'immagine macchina per archiviare tutte le configurazioni, i metadati, le autorizzazioni e i dati di uno o più dischi necessari per creare un'istanza VM.

Quando crei una macchina da uno snapshot, devi configurare le impostazioni dell'istanza sulle nuove istanze VM, il che richiede molto lavoro. Le immagini macchina consentono di copiare le impostazioni note su nuove macchine, riducendo l'overhead. Per saperne di più, consulta Quando utilizzare un'immagine macchina.

Capacità, prenotazioni e isolamento

Questa sezione fornisce le best practice per gestire la capacità, le prenotazioni e l'isolamento per supportare il tuo sistema.

Usa gli sconti per impegno di utilizzo per ridurre i costi

Puoi ridurre i costi delle spese operative (OPEX) per i carichi di lavoro sempre attivi utilizzando gli sconti per impegno di utilizzo. Per ulteriori informazioni, consulta la categoria di ottimizzazione dei costi.

Scegli i tipi di macchine per supportare costi e prestazioni

Google Cloud offre tipi di macchine che consentono di scegliere il calcolo in base a parametri di costo e prestazioni. Puoi scegliere un'offerta a basse prestazioni per ottimizzare i costi o un'opzione di computing ad alte prestazioni a un costo superiore. Per ulteriori informazioni, consulta la categoria di ottimizzazione dei costi.

Utilizza i nodi single-tenant per supportare le esigenze di conformità

I nodi single-tenant sono server Compute Engine fisici dedicati a ospitare solo le VM del tuo progetto. I nodi single-tenant possono aiutarti a soddisfare i requisiti di conformità per l'isolamento fisico, tra cui:

• Mantieni le tue VM fisicamente separate dalle VM in altri progetti.
• Raggruppa le VM sullo stesso hardware host.
• Isola i carichi di lavoro di elaborazione dei pagamenti.

Per maggiori informazioni, consulta Nodi single-tenant.

Utilizza le prenotazioni per garantire la disponibilità delle risorse

Google Cloud ti consente di definire prenotazioni per i tuoi carichi di lavoro in modo che queste risorse siano sempre disponibili. La creazione delle prenotazioni non prevede costi aggiuntivi, ma paghi per le risorse prenotate anche se non le utilizzi. Per maggiori informazioni, vedi Utilizzo e gestione delle prenotazioni.

Migrazione delle VM

Questa sezione fornisce le best practice per la migrazione delle VM per supportare il tuo sistema.

Valuta gli strumenti di migrazione integrati

Valuta gli strumenti di migrazione integrati per spostare i carichi di lavoro da un altro cloud o da on-premise. Per maggiori informazioni, consulta Migrazione a Google Cloud. Google Cloud offre strumenti e servizi per aiutarti a eseguire la migrazione dei carichi di lavoro e ottimizzare costi e prestazioni. Per ricevere una valutazione gratuita dei costi di migrazione in base al tuo attuale panorama IT, consulta Google Cloud Rapid Assessment & Migration Program.

Usa l'importazione del disco virtuale per sistemi operativi personalizzati

Per importare sistemi operativi supportati personalizzati, consulta Importazione di dischi virtuali. I nodi single-tenant possono aiutarti a soddisfare i requisiti Bring Your Own License per l'hardware per le licenze per core o per processore. Per maggiori informazioni, consulta Bring Your Own License (BYOL)

Suggerimenti

Per applicare al tuo ambiente le indicazioni contenute nel framework dell'architettura, ti consigliamo di seguire questi passaggi:

• Consulta le offerte di Google Cloud Marketplace per valutare se la tua applicazione è elencata di un fornitore supportato. Google Cloud supporta l'esecuzione di vari sistemi open source e vari software di terze parti.

• Valuta la possibilità di eseguire la migrazione ai container e a GKE per estrarre e pacchettizzare la tua applicazione basata su VM come applicazione containerizzata in esecuzione su GKE.

• Utilizza Compute Engine per eseguire le tue applicazioni su Google Cloud. Se hai dipendenze legacy in esecuzione in un'applicazione basata su VM, verifica se soddisfano i requisiti del tuo fornitore.

• Valuta l'utilizzo di un bilanciatore del carico di rete passthrough interno di Google Cloud per scalare la tua architettura disaccoppiata. Per maggiori informazioni, consulta la Panoramica del bilanciatore del carico di rete passthrough interno.

• Valuta le tue opzioni per il passaggio dai casi d'uso on-premise tradizionali, come l'utilizzo del proxy ad alta disponibilità. Per ulteriori informazioni, consulta la best practice per l'indirizzo IP mobile.

• Utilizza VM Manager per gestire i sistemi operativi per i tuoi parchi VM di grandi dimensioni che eseguono Windows o Linux su Compute Engine e applica criteri di configurazione coerenti.

• Valuta la possibilità di utilizzare GKE Autopilot e lasciare che sia Google SRE a gestire completamente i tuoi cluster.

• Utilizza Policy Controller e Config Sync per la gestione di criteri e configurazioni nei tuoi cluster GKE.

• Garantisci la disponibilità e la scalabilità delle macchine in regioni e zone specifiche. Google Cloud può scalare per supportare le tue esigenze di calcolo. Tuttavia, se hai bisogno di molti tipi di macchina specifici in una regione o zona specifica, collabora con i team dedicati al tuo account per assicurarti la disponibilità. Per ulteriori informazioni, consulta Prenotazioni per Compute Engine.

Passaggi successivi

Scopri i principi di progettazione del networking, tra cui:

• Progetta architetture VPC dei carichi di lavoro.

• Progetta la connettività tra VPC.

Esplora altre categorie nel framework dell'architettura come affidabilità, eccellenza operativa e sicurezza, privacy e conformità.

Progettazione dell'infrastruttura di rete

Questo documento nel framework dell'architettura Google Cloud fornisce best practice per il deployment del sistema in base alla progettazione del networking. Imparerai a scegliere e implementare il Virtual Private Cloud (VPC) e a testare e gestire la sicurezza della rete.

Principi fondamentali

La progettazione Networking è fondamentale per il successo della progettazione del sistema in quanto consente di ottimizzare le prestazioni e proteggere le comunicazioni delle applicazioni con i servizi interni ed esterni. Quando scegli i servizi di networking, è importante valutare le esigenze dell'applicazione e valutare il modo in cui le applicazioni comunicano tra loro. Ad esempio, anche se alcuni componenti richiedono servizi globali, altri potrebbero dover essere geolocalizzati in una regione specifica.

La rete privata di Google connette località di una singola area geografica a più di 100 punti di presenza della rete globale. Google Cloud utilizza tecnologie di networking software-defined e sistemi distribuiti per ospitare e fornire i tuoi servizi in tutto il mondo. L'elemento principale di Google per il networking in Google Cloud è il VPC globale. VPC utilizza la rete globale ad alta velocità di Google per collegare le tue applicazioni in diverse regioni supportando al contempo privacy e affidabilità. Google garantisce che i tuoi contenuti vengano distribuiti con una velocità effettiva elevata utilizzando tecnologie come ampiezza di larghezza di banda a collo di bottiglia e tempo di propagazione del round trip (BBR) per il controllo della congestione.

Lo sviluppo del progetto di rete cloud include i seguenti passaggi:

1. Progetta l'architettura VPC del carico di lavoro. Inizia identificando il numero di progetti Google Cloud e reti VPC di cui hai bisogno.
2. Aggiungi connettività tra VPC. Progetta il modo in cui i tuoi carichi di lavoro si connettono ad altri carichi di lavoro in diverse reti VPC.
3. Progetta la connettività di rete ibrida. Progetta il modo in cui i VPC dei carichi di lavoro si connettono a ambienti on-premise e ad altri ambienti cloud.

Quando progetti la tua rete Google Cloud, considera quanto segue:

• Un VPC fornisce un ambiente di networking privato nel cloud per l'interconnessione di servizi basati su Compute Engine, Google Kubernetes Engine (GKE) e Serverless Computing Solutions. Puoi anche utilizzare un VPC per accedere privatamente a servizi gestiti da Google come Cloud Storage, BigQuery e Cloud SQL.
• Le reti VPC, incluse le route e le regole firewall associate, sono risorse globali e non sono associate a nessuna regione o zona specifica.
• Le subnet sono risorse regionali. Le istanze VM di Compute Engine di cui viene eseguito il deployment in zone diverse nella stessa regione cloud possono utilizzare indirizzi IP della stessa subnet.
• Il traffico da e verso le istanze può essere controllato utilizzando le regole firewall VPC.
• L'amministrazione della rete può essere protetta utilizzando i ruoli IAM (Identity and Access Management).
• Le reti VPC possono essere connesse in modo sicuro in ambienti ibridi utilizzando Cloud VPN o Cloud Interconnect.

Per un elenco completo delle specifiche VPC, consulta Specifiche.

Architettura VPC dei carichi di lavoro

Questa sezione fornisce le best practice per la progettazione di architetture VPC dei carichi di lavoro per supportare il sistema.

Considera in anticipo la progettazione della rete VPC

Fai in modo che la progettazione della rete VPC sia una parte iniziale della progettazione della configurazione della tua organizzazione in Google Cloud. Le scelte di progettazione a livello di organizzazione non possono essere facilmente annullate in seguito. Per maggiori informazioni, consulta Best practice e architetture di riferimento per la progettazione di VPC e Decidere la progettazione della rete per la tua zona di destinazione Google Cloud.

Inizia con una singola rete VPC

Per molti casi d'uso che includono risorse con requisiti comuni, un'unica rete VPC fornisce le funzionalità di cui hai bisogno. Le reti VPC singole sono semplici da creare, gestire e comprendere. Per ulteriori informazioni, consulta le specifiche di rete VPC.

Mantieni semplice la topologia di rete VPC

Per garantire un'architettura gestibile, affidabile e ben comprensibile, mantieni la progettazione della topologia della tua rete VPC il più semplice possibile.

Usa le reti VPC in modalità personalizzata

Per assicurarti che il networking di Google Cloud si integri perfettamente con i tuoi sistemi di networking esistenti, ti consigliamo di utilizzare la modalità personalizzata quando crei reti VPC. La modalità personalizzata ti consente di integrare il networking di Google Cloud negli schemi di gestione degli indirizzi IP esistenti e di controllare quali regioni cloud sono incluse nel VPC. Per ulteriori informazioni, consulta la pagina relativa a VPC.

Connettività tra VPC

Questa sezione fornisce le best practice per la progettazione di connettività tra VPC per supportare il sistema.

Scegli un metodo di connessione VPC

Se decidi di implementare più reti VPC, devi connettere queste reti. Le reti VPC sono spazi tenant isolati all'interno della rete software-defined (SDN) Andromeda di Google. Le reti VPC possono comunicare tra loro in vari modi. Scegli come connettere la rete in base ai requisiti di larghezza di banda, latenza e accordo sul livello del servizio (SLA). Per scoprire di più sulle opzioni di connessione, consulta Scegliere il metodo di connessione VPC che soddisfa le tue esigenze di costi, prestazioni e sicurezza.

Utilizza il VPC condiviso per amministrare più gruppi di lavoro

Per le organizzazioni con più team, il VPC condiviso fornisce uno strumento efficace per estendere la semplicità dell'architettura di una singola rete VPC su più gruppi di lavoro.

Usa semplici convenzioni di denominazione

Scegli convenzioni di denominazione semplici, intuitive e coerenti. In questo modo, amministratori e utenti possono comprendere lo scopo di ogni risorsa, la sua posizione e in che modo si differenzia dalle altre risorse.

Utilizza i test di connettività per verificare la sicurezza della rete

Nel contesto della sicurezza di rete, puoi utilizzare i test di connettività per verificare che il traffico che intendi impedire tra due endpoint sia bloccato. Per verificare che il traffico sia bloccato e perché, definisci un test tra due endpoint e valuta i risultati. Ad esempio, puoi testare una funzionalità VPC che consente di definire regole in grado di bloccare il traffico. Per saperne di più, consulta la panoramica dei test di connettività.

Usa Private Service Connect per creare endpoint privati

Per creare endpoint privati che ti consentano di accedere ai servizi Google con il tuo schema di indirizzi IP, utilizza Private Service Connect. Puoi accedere agli endpoint privati dall'interno del VPC e tramite la connettività ibrida che termina nel tuo VPC.

Proteggi e limita la connettività esterna

Limita l'accesso a internet solo alle risorse che ne hanno bisogno. Le risorse con solo un indirizzo IP interno privato possono comunque accedere a molte API e servizi Google tramite l'accesso privato Google.

Utilizzare Network Intelligence Center per monitorare le reti cloud

Network Intelligence Center offre una visione completa delle reti Google Cloud in tutte le regioni. Consente di identificare pattern di traffico e accesso che possono causare rischi operativi o per la sicurezza.

Passaggi successivi

Scopri le best practice per la gestione dello spazio di archiviazione, che includono quanto segue:

• Seleziona un tipo di archiviazione.
• Scegli pattern di accesso allo spazio di archiviazione e tipi di carichi di lavoro.

Esplora altre categorie nel framework dell'architettura come affidabilità, eccellenza operativa e sicurezza, privacy e conformità.

Selezionare e implementare una strategia di archiviazione

Questo documento nel framework dell'architettura Google Cloud fornisce best practice per il deployment del sistema in base allo spazio di archiviazione. Imparerai a selezionare una strategia di archiviazione e a gestire lo spazio di archiviazione, i pattern di accesso e i carichi di lavoro.

Per facilitare lo scambio di dati ed eseguire il backup e l'archiviazione in modo sicuro dei dati, le organizzazioni devono scegliere un piano di archiviazione basato su carico di lavoro, operazioni di input/output al secondo (IOPS), latenza, frequenza di recupero, posizione, capacità e formato (blocco, file e oggetto).

Cloud Storage fornisce servizi di archiviazione di oggetti affidabili e sicuri, tra cui:

• Opzioni di ridondanza integrate per proteggere i dati da guasti delle apparecchiature e garantire la disponibilità dei dati durante la manutenzione del data center.
• Opzioni di trasferimento di dati, tra cui:
  • Storage Transfer Service
  • Transfer Appliance
  • BigQuery Data Transfer Service
  • Migrazione a Google Cloud: trasferimento dei tuoi set di dati di grandi dimensioni
• Classi di archiviazione per supportare i carichi di lavoro.
• Checksum calcolati per tutte le operazioni di Cloud Storage che consentono a Google di verificare le letture e le scritture.

In Google Cloud, le IOPS scalano in base allo spazio di archiviazione di cui hai eseguito il provisioning. I tipi di archiviazione come Persistent Disk richiedono la replica e il backup manuali perché sono a livello di zona o di regione. Al contrario, l'archiviazione degli oggetti è ad alta disponibilità e replica automaticamente i dati in una singola regione o in più regioni.

Tipo di archiviazione

Questa sezione fornisce le best practice per scegliere un tipo di archiviazione per supportare il tuo sistema.

Valuta le opzioni per le esigenze di archiviazione con prestazioni elevate

Valuta i dischi permanenti o le unità a stato solido (SSD) locali per le applicazioni di computing che richiedono un'archiviazione ad alte prestazioni. Cloud Storage è un archivio di oggetti immutabili con controllo delle versioni. L'utilizzo di Cloud Storage con Cloud CDN consente di ottimizzare i costi, soprattutto per gli oggetti statici ad accesso frequente.

Filestore supporta applicazioni con multiscrittura che richiedono uno spazio condiviso ad alte prestazioni. Filestore supporta anche le applicazioni legacy e moderne che richiedono operazioni su file simili a POSIX tramite montaggi di Network File System (NFS).

Cloud Storage supporta casi d'uso come la creazione di data lake e la gestione dei requisiti di archiviazione. Prendi decisioni di compromesso in base a come scegli la classe di Cloud Storage a causa dei costi di accesso e recupero, soprattutto quando configuri i criteri di conservazione. Per maggiori informazioni, consulta Progettare una strategia di archiviazione ottimale per il carico di lavoro cloud.

Per impostazione predefinita, tutte le opzioni di archiviazione sono criptate at-rest e in transito mediante chiavi gestite da Google. Per tipi di archiviazione come Persistent Disk e Cloud Storage, puoi fornire la tua chiave o gestirla tramite Cloud Key Management Service (Cloud KMS). Stabilisci una strategia per la gestione di queste chiavi prima di utilizzarle nei dati di produzione.

Scegli i servizi Google Cloud per supportare la progettazione dello spazio di archiviazione

Per informazioni sui servizi Google Cloud che supportano la progettazione dello spazio di archiviazione, utilizza la seguente tabella:

Servizio Google Cloud	Description
Cloud Storage	Consente l'archiviazione e il recupero a livello globale di qualsiasi quantità di dati in qualsiasi momento. Puoi utilizzare Cloud Storage per scenari diversi, tra cui pubblicazione di contenuti di siti web, archiviazione di dati e ripristino di emergenza o distribuzione agli utenti di oggetti di dati di grandi dimensioni tramite download diretto. Per ulteriori informazioni, consulta le seguenti risorse: Best practice per Cloud Storage Località dei bucket Classi di archiviazione FUSE di Cloud Storage
Persistent Disk	Archiviazione a blocchi ad alte prestazioni per Google Cloud. Persistent Disk fornisce spazio di archiviazione SSD e su disco rigido (HDD) che puoi collegare alle istanze in esecuzione in Compute Engine o Google Kubernetes Engine (GKE). I dischi regionali offrono archiviazione e replica durevoli dei dati tra due zone nella stessa regione. Se hai bisogno di IOPS più elevate e bassa latenza, Google Cloud offre Filestore. Le unità SSD locali sono fisicamente collegate al server che ospita l'istanza della macchina virtuale. Puoi usare gli SSD locali come spazio su disco temporaneo.
Filestore	Un servizio gestito di archiviazione di file per applicazioni che richiedono un'interfaccia di file system e un file system condiviso per i dati. Filestore offre agli utenti un'esperienza fluida per il supporto di dispositivi NAS (Network Attached Storage) gestiti con le relative istanze di Compute Engine e GKE.
Cloud Storage for Firebase	Creato per gli sviluppatori di app che devono archiviare e pubblicare contenuti generati dagli utenti, come foto o video. Tutti i tuoi file sono archiviati in bucket di Cloud Storage, pertanto sono accessibili sia da Firebase sia da Google Cloud.

Scegli una strategia di archiviazione

Per selezionare una strategia di archiviazione che soddisfi i requisiti della tua applicazione, utilizza la seguente tabella:

Caso d'uso	Suggerimenti
Vuoi archiviare i dati su larga scala al minor costo e accedere alle prestazioni non è un problema.	Cloud Storage
Stai eseguendo applicazioni di computing che richiedono archiviazione immediata. Per ulteriori informazioni, consulta la pagina relativa all'ottimizzazione delle prestazioni di dischi permanenti e SSD locali.	Disco permanente o SSD locale
Stai eseguendo carichi di lavoro ad alte prestazioni che richiedono l'accesso in lettura e scrittura allo spazio condiviso.	Filestore
Disponi di casi d'uso di computing ad alte prestazioni (HPC) o computing ad alta velocità effettiva (HTC).	Utilizzo dei cluster per il calcolo tecnico su larga scala nel cloud

Scegli l'archiviazione dei dati attivi o ad accesso sporadico in base alle esigenze di accesso allo spazio di archiviazione

Una classe di archiviazione è una parte dei metadati utilizzata da ogni oggetto. Per i dati pubblicati con una frequenza elevata e ad alta disponibilità, utilizza la classe Standard Storage. Per i dati ad accesso non frequente e che possono tollerare una disponibilità leggermente inferiore, utilizza la classe Nearline Storage, Coldline Storage o Archive Storage. Per ulteriori informazioni sulle considerazioni sui costi per la scelta di una classe di archiviazione, consulta i prezzi di Cloud Storage.

Valuta la località di archiviazione e le esigenze di protezione dei dati per Cloud Storage

Per un bucket Cloud Storage situato in una regione, i dati al suo interno vengono replicati automaticamente tra le zone all'interno della regione. La replica dei dati tra le zone protegge i dati in caso di errore a livello di zona all'interno di una regione.

Cloud Storage offre inoltre località ridondanti tra regioni, il che significa che i dati vengono replicati in più data center geograficamente separati. Per maggiori informazioni, consulta la pagina Località dei bucket.

Usa Cloud CDN per migliorare la distribuzione di oggetti statici

Utilizza Cloud CDN per ottimizzare i costi di recupero degli oggetti e ridurre al minimo la latenza di accesso. Cloud CDN utilizza il bilanciatore del carico delle applicazioni esterno di Cloud Load Balancing per fornire il supporto per routing, controllo di integrità e indirizzi IP anycast. Per ulteriori informazioni, consulta Configurazione di Cloud CDN con bucket cloud.

Modello di accesso allo spazio di archiviazione e tipo di carico di lavoro

Questa sezione fornisce le best practice per la scelta dei pattern di accesso allo spazio di archiviazione e dei tipi di carichi di lavoro per supportare il tuo sistema.

Usa Persistent Disk per supportare un accesso allo spazio di archiviazione ad alte prestazioni

I modelli di accesso ai dati dipendono da come progetti le prestazioni del sistema. Cloud Storage offre archiviazione scalabile, ma non è la scelta ideale quando si eseguono carichi di lavoro di computing intensivo che richiedono l'accesso a una velocità effettiva elevata a grandi quantità di dati. Per un accesso allo spazio di archiviazione ad alte prestazioni, utilizza Persistent Disk.

Utilizza il backoff esponenziale quando implementi la logica per i nuovi tentativi

Utilizza il backoff esponenziale quando implementi la logica dei nuovi tentativi per gestire gli errori 5XX, 408 e 429. Viene eseguito il provisioning di ogni bucket Cloud Storage con capacità di I/O iniziale. Per maggiori informazioni, consulta le linee guida sul tasso di richieste e sulla distribuzione degli accessi. Pianifica un incremento graduale delle richieste ripetute.

Gestione dell'archiviazione

Questa sezione fornisce best practice per la gestione dello spazio di archiviazione al fine di supportare il tuo sistema.

Assegna nomi univoci a ogni bucket

Rendi univoco il nome di ogni bucket nello spazio dei nomi di Cloud Storage. Non includere informazioni sensibili nel nome del bucket. Scegli nomi di bucket e oggetti difficili da indovinare. Per maggiori informazioni, consulta le linee guida per la denominazione dei bucket e le linee guida per la denominazione degli oggetti.

Mantieni privati i bucket Cloud Storage

A meno che non ci sia un motivo relativo all'attività, assicurati che il bucket Cloud Storage non sia accessibile in modo anonimo o pubblicamente. Per ulteriori informazioni, consulta la Panoramica del controllo dell'accesso.

Assegna nomi casuali agli oggetti per distribuire il carico in modo uniforme

Assegna nomi casuali agli oggetti per favorire le prestazioni ed evitare l'hotspotting. Dove possibile, usa un prefisso randomizzato per gli oggetti. Per ulteriori informazioni, consulta l'articolo Utilizzare una convenzione di denominazione che distribuisce il carico in modo uniforme tra gli intervalli di chiavi.

Applica la prevenzione dell'accesso pubblico

Per impedire l'accesso a livello di organizzazione, cartella, progetto o bucket, utilizza la prevenzione dell'accesso pubblico. Per maggiori informazioni, consulta Utilizzo della prevenzione dell'accesso pubblico.

Passaggi successivi

Scopri i servizi di database Google Cloud e le best practice, tra cui:

• Seleziona ed esegui la migrazione del database.
• Gestire la crittografia del database.
• Gestisci networking e accesso del database.

Esplora altre categorie nel framework dell'architettura come affidabilità, eccellenza operativa e sicurezza, privacy e conformità.

Ottimizzazione del database

Questo documento nel framework dell'architettura Google Cloud fornisce best practice per il deployment del sistema in base alla progettazione del database. Imparerai a progettare, migrare e scalare i database, criptare le informazioni del database, gestire le licenze e monitorare il database per gli eventi.

Servizi chiavi

Questo documento nella categoria di progettazione del sistema Framework dell'architettura fornisce best practice che includono vari servizi di database Google Cloud. La seguente tabella offre una panoramica generale di questi servizi:

Servizio Google Cloud	Description
Cloud SQL	Un servizio di database completamente gestito che ti consente di configurare, mantenere, gestire e amministrare i database relazionali che utilizzano Cloud SQL per PostgreSQL, Cloud SQL per MySQL e Cloud SQL per SQL Server. Cloud SQL offre prestazioni e scalabilità elevate. Ospitato su Google Cloud, Cloud SQL fornisce un'infrastruttura di database per le applicazioni eseguite ovunque.
Bigtable	Scalabile fino a miliardi di righe e migliaia di colonne, consente di archiviare fino a petabyte di dati. Viene indicizzato un singolo valore in ogni riga; questo valore è noto come chiave di riga. Utilizza Bigtable per archiviare grandi quantità di dati a chiave singola con latenza molto bassa. Supporta una velocità effettiva di lettura e scrittura elevata a bassa latenza ed è un'origine dati per le operazioni MapReduce.
Spanner	Un servizio di database aziendale scalabile e distribuito a livello globale creato per il cloud, che include struttura di database relazionale e scalabilità orizzontale non relazionale. Questa combinazione offre transazioni ad alte prestazioni e coerenza tra righe, regioni e continenti. Spanner offre uno SLA (accordo sul livello del servizio) con disponibilità del 99, 999%, nessun tempo di inattività pianificato e sicurezza di livello enterprise.
Memorystore	Un servizio Redis completamente gestito per Google Cloud. Le applicazioni eseguite su Google Cloud possono aumentare le prestazioni utilizzando il servizio Redis, estremamente disponibile, scalabile e sicuro, senza gestire complessi deployment Redis.
Firestore	un database di documenti NoSQL creato per offrire scalabilità automatica, prestazioni elevate e sviluppo di applicazioni. Sebbene l'interfaccia Firestore abbia molte delle funzionalità dei database tradizionali, è un database NoSQL e descrive le relazioni tra gli oggetti dati in modo diverso.
Firebase Realtime Database	un database ospitato nel cloud. Firebase archivia i dati come JSON e si sincronizza in tempo reale con ogni client connesso. Quando crei app multipiattaforma con gli SDK Google, iOS, Android e JavaScript, tutti i tuoi clienti condividono un'unica istanza del database in tempo reale e ricevono automaticamente gli aggiornamenti con i dati più recenti.
Database open source	I partner di Google offrono diversi database open source, tra cui MongoDB, MariaDB e Redis.
AlloyDB per PostgreSQL	Un servizio di database completamente gestito compatibile con PostgreSQL per i carichi di lavoro aziendali più complessi. Fornisce prestazioni fino a 4 volte più veloci per carichi di lavoro transazionali e query analitiche 100 volte più veloci rispetto a PostgreSQL standard. AlloyDB per PostgreSQL semplifica la gestione con i sistemi Autopilot abilitati per il machine learning.

Selezione database

Questa sezione fornisce le best practice per scegliere un database per supportare il tuo sistema.

Valuta la possibilità di utilizzare un servizio di database gestito

Valuta i servizi di database gestiti di Google Cloud prima di installare il tuo database o cluster di database. L'installazione del tuo database comporta un overhead di manutenzione che comprende l'installazione di patch e aggiornamenti e la gestione delle attività operative quotidiane come il monitoraggio e l'esecuzione dei backup.

Utilizza requisiti delle applicazioni funzionali e non funzionali per favorire la selezione del database. Prendi in considerazione l'accesso a bassa latenza, l'elaborazione dei dati di serie temporali, il ripristino di emergenza e la sincronizzazione dei client mobili.

Per eseguire la migrazione dei database, utilizza uno dei prodotti descritti nella seguente tabella:

Prodotto per la migrazione dei database	Description
Cloud SQL	Un servizio a livello di regione che supporta repliche di lettura nelle regioni remote, letture a bassa latenza e ripristino di emergenza.
Spanner	Un'offerta multiregionale che offre coerenza esterna, replica globale e un accordo sul livello del servizio (SLA) a cinque nove.
Bigtable	Un servizio di database NoSQL scalabile e completamente gestito per carichi di lavoro analitici e operativi di grandi dimensioni con una disponibilità fino al 99, 999%.
Memorystore	Un servizio di database completamente gestito che fornisce una versione gestita di due popolari soluzioni di memorizzazione nella cache open source: Redis e Memcached.
Firebase Realtime Database	Firebase Realtime Database è un database NoSQL ospitato nel cloud che consente di archiviare e sincronizzare i dati tra gli utenti in tempo reale.
Firestore	un database di documenti NoSQL creato per offrire scalabilità automatica, prestazioni elevate e facilità di sviluppo delle applicazioni.
Open source	Opzioni di database alternative, tra cui MongoDB e MariaDB.

Migrazione dei database

Per assicurarti che gli utenti non riscontrino tempi di inattività delle applicazioni quando esegui la migrazione dei carichi di lavoro esistenti in Google Cloud, è importante scegliere tecnologie di database che supportino i tuoi requisiti. Per informazioni sulle opzioni e sulle best practice per la migrazione dei database, consulta Soluzioni di migrazione dei database e Best practice per migrazioni di database omogenei.

La pianificazione per una migrazione di database include quanto segue:

• Valutazione e scoperta del database attuale.
• Definizioni dei criteri di successo della migrazione.
• Configurazione dell'ambiente per la migrazione e del database di destinazione.
• Creazione dello schema nel database di destinazione.
• Migrazione dei dati nel database di destinazione.
• Convalida della migrazione per verificare che tutti i dati siano stati migrati correttamente e che siano presenti nel database.
• Creazione di una strategia di rollback.

Scegli una strategia di migrazione

La selezione del database di destinazione appropriato è una delle chiavi per una migrazione riuscita. La tabella seguente presenta le opzioni di migrazione per alcuni casi d'uso:

Caso d'uso	Consiglio
Nuovo sviluppo in Google Cloud.	Seleziona uno dei database gestiti creati per il cloud (Cloud SQL, Spanner, Bigtable o Firestore) per soddisfare i requisiti del tuo caso d'uso.
Migrazione lift and shift.	Scegli un servizio di database gestito compatibile come Cloud SQL, MYSQL, PostgreSQL o SQLServer.
La tua applicazione richiede un accesso granulare a un database non supportato da Cloud SQL.	Esegui il tuo database su VM di Compute Engine.

Usa Memorystore per supportare il livello di memorizzazione nella cache del tuo database

Memorystore è un database Redis e Memcached completamente gestito che supporta una latenza di sottomillisecondi. Memorystore è completamente compatibile con Redis e Memcached open source. Se utilizzi questi database di memorizzazione nella cache nelle tue applicazioni, puoi utilizzare Memorystore senza apportare modifiche a livello di applicazione nel tuo codice.

Usa server Bare Metal per eseguire un database Oracle

Se i carichi di lavoro richiedono un database Oracle, utilizza server Bare Metal forniti da Google Cloud. Questo approccio rientra in una strategia di migrazione lift and shift.

Se vuoi spostare il carico di lavoro in Google Cloud ed eseguire la modernizzazione dopo che il carico di lavoro di base è in funzione, valuta la possibilità di utilizzare opzioni di database gestiti come Spanner, Bigtable e Firestore.

I database creati per il cloud sono database gestiti moderni che vengono creati dal basso verso l'alto nell'infrastruttura cloud. Questi database offrono funzionalità predefinite esclusive, come scalabilità e disponibilità elevata, difficilmente accessibili se si esegue un database personale.

Modernizza il tuo database

Pianifica la tua strategia di database nelle prime fasi del processo di progettazione del sistema, che tu stia progettando una nuova applicazione nel cloud o migrando un database esistente al cloud. Google Cloud offre opzioni di database gestite per database open source come Cloud SQL per MySQL e Cloud SQL per PostgreSQL. Ti consigliamo di utilizzare la migrazione come opportunità per modernizzare il tuo database e prepararlo per supportare le future esigenze aziendali.

Usa database fissi con applicazioni standard

Le applicazioni commerciali pronte all'uso (COTS) richiedono un tipo fisso di database e una configurazione fissa. Il lift and shift è in genere l'approccio di migrazione più appropriato per le applicazioni COTS.

Verificare le competenze del tuo team per la migrazione dei database

Scegli un approccio di migrazione dei database cloud basato sulle capacità di migrazione dei database e sulle competenze del tuo team. Utilizza Google Cloud Partner Advantage per trovare un partner che ti offra assistenza durante il tuo percorso di migrazione.

Progetta il tuo database perché sia conforme ai requisiti di HA e RE

Quando progetti i tuoi database per soddisfare i requisiti di alta disponibilità (HA) e ripristino di emergenza (RE), valuta i compromessi tra affidabilità e costi. I servizi di database creati per il cloud creano più copie dei tuoi dati all'interno di una o più regioni, a seconda del database e della configurazione.

Alcuni servizi Google Cloud hanno varianti per più regioni, ad esempio BigQuery e Spanner. Per garantire la resilienza contro gli errori a livello di regione, utilizza questi servizi multiregionali nella tua progettazione, ove possibile.

Se progetti il tuo database su VM di Compute Engine anziché utilizzare database gestiti su Google Cloud, assicurati di eseguire più copie dei tuoi database. Per ulteriori informazioni, consulta Progettare per la scalabilità e la disponibilità elevata nella categoria Affidabilità.

Specifica le regioni cloud per supportare la residenza dei dati

Per residenza dei dati si intende il luogo in cui risiedono fisicamente i dati at-rest. Valuta la possibilità di scegliere regioni cloud specifiche per il deployment dei database in base ai requisiti di residenza dei dati.

Se esegui il deployment dei database in più regioni, le due regioni potrebbero presentare una replica dei dati, a seconda di come li configuri. Seleziona la configurazione che mantiene i dati at-rest all'interno delle regioni desiderate. Alcuni database, come Spanner, offrono una replica multiregionale predefinita. Puoi anche applicare la residenza dei dati impostando un criterio dell'organizzazione che includa i vincoli per le località delle risorse. Per maggiori informazioni, consulta Limitazione delle località delle risorse.

Includi il ripristino di emergenza nella progettazione della residenza dei dati

Includi RTO (Recovery Time Objective) e RPO (Recovery Point Objective) nei piani di residenza dei dati e considera il compromesso tra RTO/RPO e i costi della soluzione di ripristino di emergenza. Un RTO/RPO più basso comporta costi più elevati. Se vuoi che il tuo sistema si riprenda più rapidamente dalle interruzioni, l'esecuzione del sistema avrà un costo maggiore. Inoltre, valuta la soddisfazione dei clienti nel tuo approccio di ripristino di emergenza per assicurarti che i tuoi investimenti per l'affidabilità siano appropriati. Per ulteriori informazioni, consulta L'affidabilità al 100% è il target sbagliato e Guida alla pianificazione del ripristino di emergenza.

Rendi il tuo database compatibile con Google Cloud

Quando scegli un database per il tuo carico di lavoro, assicurati che il servizio selezionato soddisfi la conformità per la regione geografica in cui operi e in cui sono fisicamente archiviati i tuoi dati. Per ulteriori informazioni sulle certificazioni e gli standard di conformità di Google, consulta la sezione Offerte relative alla conformità.

Crittografia

Questa sezione fornisce le best practice per identificare i requisiti di crittografia e scegliere una strategia per le chiavi di crittografia a supporto del tuo sistema.

Determina i requisiti di crittografia

I requisiti di crittografia dipendono da diversi fattori, tra cui i criteri di sicurezza aziendali e i requisiti di conformità. Tutti i dati archiviati in Google Cloud sono criptati at-rest per impostazione predefinita, senza che sia richiesta alcuna azione da parte tua, mediante l'algoritmo AES256. Per maggiori informazioni, consulta Crittografia at-rest in Google Cloud.

Scegli una strategia per le chiavi di crittografia

Decidi se vuoi gestire autonomamente le chiavi di crittografia o se vuoi utilizzare un servizio gestito. Google Cloud supporta entrambi gli scenari. Se vuoi che un servizio completamente gestito per gestire le tue chiavi di crittografia su Google Cloud, scegli Cloud Key Management Service (Cloud KMS). Se vuoi gestire le tue chiavi di crittografia per mantenere un maggiore controllo sul ciclo di vita di una chiave, utilizza le chiavi di crittografia gestite dal cliente (CMEK).

Per creare e gestire le chiavi di crittografia al di fuori di Google Cloud, scegli una delle seguenti opzioni:

• Se utilizzi una soluzione di un partner per gestire le chiavi, utilizza Cloud External Key Manager.
• Se gestisci le chiavi on-premise e vuoi utilizzarle per criptare i dati su Google Cloud, import in Cloud KMS come chiavi KMS o chiavi HSM (Hardware Key Module). Usa queste chiavi per criptare i dati su Google Cloud.

Progettazione e scalabilità del database

Questa sezione fornisce le best practice per la progettazione e la scalabilità di un database per supportare il tuo sistema.

Usa le metriche di monitoraggio per valutare le esigenze di scalabilità

Utilizza le metriche degli ambienti e degli strumenti di monitoraggio esistenti per stabilire una comprensione di base dei requisiti di dimensione e scalabilità del database, ad esempio dimensionamento ottimale e progettazione di strategie di scalabilità per l'istanza di database.

Per i nuovi progetti di database, determina i numeri di scalabilità in base ai modelli di carico e traffico previsti dall'applicazione di gestione. Per ulteriori informazioni, consulta Monitoraggio delle istanze Cloud SQL, Monitoraggio con Cloud Monitoring e Monitoraggio di un'istanza.

Networking e accesso

Questa sezione fornisce le best practice per la gestione del networking e dell'accesso al tuo sistema.

Esegui i database all'interno di una rete privata

Esegui i tuoi database all'interno della tua rete privata e concedi l'accesso limitato solo ai client che devono interagire con il database. Puoi creare istanze Cloud SQL all'interno di un VPC. Google Cloud fornisce inoltre Controlli di servizio VPC per i database Cloud SQL, Spanner e Bigtable per garantire che l'accesso a queste risorse sia limitato solo ai client all'interno di reti VPC autorizzate.

Concedi privilegi minimi agli utenti

Identity and Access Management (IAM) controlla l'accesso ai servizi Google Cloud, inclusi i servizi di database. Per ridurre al minimo il rischio di accessi non autorizzati, concedi il numero minimo di privilegi ai tuoi utenti. Per l'accesso ai tuoi database a livello di applicazione, utilizza gli account di servizio con il numero minimo di privilegi.

Automazione e dimensionamento ottimale

Questa sezione fornisce le best practice per definire l'automazione e il dimensionamento ottimale per supportare il tuo sistema.

Definisci le istanze di database come codice

Uno dei vantaggi della migrazione a Google Cloud è la capacità di automatizzare l'infrastruttura e altri aspetti del carico di lavoro, come i livelli di calcolo e database. Google Deployment Manager e strumenti di terze parti come Terraform Cloud consentono di definire le istanze di database come codice, in modo da applicare un approccio coerente e ripetibile alla creazione e all'aggiornamento dei database.

Usa Liquibase per controllare la versione del database

I servizi di database di Google come Cloud SQL e Spanner supportano Liquibase, uno strumento di controllo della versione open source per i database. Liquibase consente di monitorare le modifiche allo schema del database, eseguirne il rollback delle modifiche ed eseguire migrazioni ripetibili.

Testa e ottimizza il database per supportare la scalabilità

Esegui test di carico sulla tua istanza di database e ottimizzala in base ai risultati del test per soddisfare i requisiti della tua applicazione. Determina la scala iniziale del tuo database eseguendo test di carico sugli indicatori chiave di prestazione (KPI) o utilizzando i KPI di monitoraggio derivati dal database attuale.

Quando crei istanze di database, inizia con una dimensione basata sui risultati dei test o sulle metriche di monitoraggio storico. Testa le istanze di database con il carico previsto nel cloud. Quindi ottimizza le istanze fino a quando non ottieni i risultati desiderati per il carico previsto sulle istanze del database.

Scegli il database giusto per i tuoi requisiti di scalabilità

La scalabilità dei database è diversa dalla scalabilità dei componenti del livello di computing. I database hanno uno stato. Quando un'istanza del database non è in grado di gestire il carico, considera la strategia appropriata per scalare le istanze del database. Le strategie di scalabilità variano a seconda del tipo di database.

Utilizza la seguente tabella per informazioni sui prodotti Google che rispondono ai casi d'uso relativi alla scalabilità.

Caso d'uso	Prodotto consigliato	Description
Scala orizzontalmente l'istanza del database aggiungendo nodi al database quando devi fare lo scale up della capacità di gestione e dello spazio di archiviazione.	Spanner	Un database relazionale creato per il cloud.
Aggiungi nodi per scalare il database.	Bigtable	Servizio di database di big data NoSQL completamente gestito.
Gestisci automaticamente la scalabilità del database.	Firestore	Database flessibile e scalabile per lo sviluppo su dispositivi mobili, web e server.
Per gestire più query, fai lo scale up delle istanze di database Cloud SQL in verticale, in modo da aumentare la capacità di calcolo e memoria. In Cloud SQL, il livello di archiviazione è disaccoppiato dall'istanza del database. Puoi scalare automaticamente il livello di archiviazione quando si avvicina alla capacità.	Cloud SQL	Servizio di database completamente gestito che semplifica la configurazione, la manutenzione, la gestione e l'amministrazione dei database relazionali su Google Cloud.

Suite operativa

Questa sezione fornisce le best practice per le operazioni che supportano il sistema.

Usa Cloud Monitoring per monitorare e configurare avvisi per il tuo database

Utilizza Cloud Monitoring per monitorare le istanze di database e configurare avvisi per notificare gli eventi ai team appropriati. Per informazioni sulle best practice per avvisi efficienti, consulta Creare avvisi efficienti.

Tutti i database creati per il cloud forniscono metriche di logging e monitoraggio. Ogni servizio fornisce una dashboard per visualizzare le metriche di logging e monitoraggio. Le metriche di monitoraggio per tutti i servizi si integrano con l'osservabilità di Google Cloud. Spanner fornisce strumenti di introspezione delle query come Key Visualizer per il debug e l'analisi delle cause principali. Key Visualizer offre le seguenti funzionalità:

• Aiuta ad analizzare i pattern di utilizzo di Spanner generando report visivi per i tuoi database. I report mostrano i pattern di utilizzo per intervalli di righe nel tempo.
• Fornisce insight sui pattern di utilizzo su larga scala.

Bigtable fornisce anche uno strumento di diagnostica Key Visualizer che consente di analizzare i pattern di utilizzo delle istanze Bigtable.

Licenze

Questa sezione fornisce le best practice relative alle licenze per supportare il tuo sistema.

Scegli tra licenze on demand ed esistenti

Se utilizzi Cloud SQL per SQL Server, il servizio Bring Your Own License non è supportato; i costi delle licenze si basano sull'utilizzo per core/ora.

Se vuoi utilizzare licenze Cloud SQL per SQL Server esistenti, valuta la possibilità di eseguire Cloud SQL per SQL Server su VM di Compute Engine. Per saperne di più, consulta Licenze Microsoft e Scegliere tra le licenze on demand e portare le licenze esistenti.

Se utilizzi Oracle ed esegui la migrazione a Bare Metal Solution per Oracle, puoi utilizzare le tue licenze Bring Your Own License. Per maggiori informazioni, consulta Pianificare una soluzione Bare Metal.

Cronologia, metodologia e set di strumenti della migrazione

Questa sezione fornisce le best practice per pianificare e supportare la migrazione del database al fine di supportare il sistema.

Determina l'idoneità alla modernizzazione dei database

Valuta se la tua organizzazione è pronta per modernizzare i database e utilizzare database creati per il cloud.

Valuta la modernizzazione dei database quando pianifichi le tempistiche della migrazione dei carichi di lavoro, perché è probabile che la modernizzazione abbia un impatto sul lato applicazione.

Coinvolgere gli stakeholder rilevanti nella pianificazione della migrazione

Per eseguire la migrazione di un database, devi completare le seguenti attività:

• Configura i database di destinazione.
• Converti lo schema.
• Configura la replica dei dati tra il database di origine e quello di destinazione.
• Eseguire il debug dei problemi non appena si presentano durante la migrazione.
• Stabilisci la connettività di rete tra il livello dell'applicazione e il database.
• Implementa la sicurezza dei database di destinazione.
• Assicurati che le applicazioni si connettano ai database di destinazione.

Queste attività spesso richiedono competenze diverse e più team collaborano all'interno dell'organizzazione per completare la migrazione. Quando pianifichi la migrazione, includi gli stakeholder di tutti i team, ad esempio sviluppatori di app, amministratori del database e team di infrastruttura e sicurezza.

Se il tuo team non ha le competenze per supportare questo tipo di migrazione, i partner di Google possono aiutarti a eseguirle. Per ulteriori informazioni, consulta Google Cloud Partner Advantage.

Identificare i set di strumenti per migrazioni omogene ed eterogenee

Una migrazione omogenea è una migrazione di database tra i database di origine e di destinazione della stessa tecnologia di database. Una migrazione eterogenea è una migrazione il cui database di destinazione è diverso da quello di origine.

Le migrazioni eterogenee di solito comportano passaggi aggiuntivi di conversione dello schema dal database di origine al tipo di motore del database di destinazione. I team del database devono valutare le sfide relative alla conversione dello schema perché dipendono dalla complessità dello schema del database di origine.

Testare e convalidare ogni passaggio della migrazione dei dati

Le migrazioni dei dati prevedono più passaggi. Per ridurre al minimo gli errori di migrazione, testa e convalida ogni passaggio prima di andare a quello successivo. I seguenti fattori guidano il processo di migrazione:

• Indica se la migrazione è omogenea o eterogenea.
• Che tipo di strumenti e competenze hai a disposizione per eseguire la migrazione?
• Per le migrazioni eterogenee, la tua esperienza con il motore del database di destinazione.

Determinare i requisiti di replica continua dei dati

Crea un piano per la migrazione iniziale dei dati e poi la replica continua dei dati dall'origine al database di destinazione. Continua la replica finché il target non si stabilizza e viene eseguita la migrazione completa dell'applicazione nel nuovo database. Questo piano ti aiuta a identificare potenziali tempi di inattività durante il trasferimento del database e a pianificare di conseguenza.

Se prevedi di eseguire la migrazione dei motori di database da Cloud SQL, Cloud SQL per MySQL o Cloud SQL per PostgreSQL, utilizza Database Migration Service per automatizzare questo processo in un modo completamente gestito. Per informazioni sugli strumenti di terze parti che supportano altri tipi di migrazioni, consulta Cloud Marketplace.

Suggerimenti

Per applicare al tuo ambiente le indicazioni contenute nel framework dell'architettura, ti consigliamo di procedere come segue:

• La multitenancy per i database comporta l'archiviazione dei dati di più clienti su un'infrastruttura condivisa, in questo caso un database. Se offri ai tuoi clienti un'offerta basata su Software as a Service (SaaS), assicurati di comprendere come isolare logicamente set di dati appartenenti a diversi clienti e supportare i relativi requisiti di accesso. Inoltre, valuta i tuoi requisiti in base ai livelli di separazione.

  Per i database relazionali come Spanner e Cloud SQL, esistono diversi approcci, come isolare i dati dei tenant a livello di istanza di database, di database, di schema o di tabella di database. Come per altre decisioni di progettazione, esiste un compromesso tra il grado di isolamento e altri fattori come costo e prestazioni. I criteri IAM controllano l'accesso alle istanze del tuo database.

• Scegli il database giusto per i requisiti del tuo modello dei dati.

• Scegli valori delle chiavi che evitino l'hotspotting. Un hotspot è una località all'interno di una tabella che riceve molte più richieste di accesso rispetto ad altre località. Per ulteriori informazioni sugli hotspot, consulta le best practice per la progettazione degli schemi.

• Dove possibile, esegui lo sharding della tua istanza di database.

• Utilizza le best practice per la gestione delle connessioni, come il pooling delle connessioni e il backoff esponenziale.

• Evita transazioni di dimensioni particolarmente grandi.

• Progetta e testa la risposta della tua applicazione agli aggiornamenti di manutenzione sui database.

• Proteggi e isola le connessioni al tuo database.

• Dimensiona il database e le aspettative di crescita per assicurarti che il database supporti i tuoi requisiti.

• Testare le strategie di failover ad alta disponibilità e RE.

• Esegui backup e ripristino, nonché esportazioni e importazioni per acquisire familiarità con il processo.

Suggerimenti per Cloud SQL

• Utilizza il networking di indirizzi IP privati (VPC). Per maggiore sicurezza, considera quanto segue:
  • Utilizza il proxy di autenticazione Cloud SQL per supportare il networking privato.
  • Limita l'accesso all'indirizzo IP pubblico constraints/sql.restrictPublicIp.
• Se hai bisogno di networking di indirizzi IP pubblici, considera quanto segue:
  • Utilizza il firewall integrato con un elenco di indirizzi IP limitato o ristretto e assicurati che le istanze Cloud SQL richiedano che le connessioni in entrata utilizzino SSL. Per ulteriori informazioni, consulta Configurazione dei certificati SSL/TLS.
• Per maggiore sicurezza, considera quanto segue:
  • Non concedere accesso generalizzato, usa piuttosto il proxy di autenticazione Cloud SQL.
  • Limita reti autorizzate constraints/sql.restrictAuthorizedNetworks.
• Usa privilegi limitati per gli utenti del database.

Passaggi successivi

Scopri le best practice per l'analisi dei dati, tra cui:

• Scopri i principi principali di analisi dei dati e i servizi principali di Google Cloud.
• Scopri di più sul ciclo di vita dei dati.
• Scopri come importare dati.
• Scegliere e gestire l'archiviazione dei dati.
• Elabora e trasforma i dati.

Esplora altre categorie nel framework dell'architettura come affidabilità, eccellenza operativa e sicurezza, privacy e conformità.

Analizzare i dati

Questo documento nel framework dell'architettura Google Cloud illustra alcuni dei principi fondamentali e delle best practice per l'analisi dei dati in Google Cloud. Scoprirai alcuni dei servizi chiave di analisi dei dati e come possono essere utili nelle varie fasi del ciclo di vita dei dati. Queste best practice ti aiutano a soddisfare le tue esigenze di analisi dei dati e a creare la progettazione del tuo sistema.

Principi fondamentali

Le attività vogliono analizzare i dati e generare insight strategici a partire da questi dati. Google Cloud offre vari servizi che ti aiutano nell'intero ciclo di vita dei dati, dall'importazione dati ai report e alla visualizzazione. La maggior parte di questi servizi è completamente gestita e alcuni sono serverless. Puoi anche creare e gestire un ambiente di analisi dei dati su VM di Compute Engine, ad esempio ospitando autonomamente Apache Hadoop o Beam.

La tua particolare attenzione, le competenze del tuo team e la tua visione strategica ti aiutano a determinare quali servizi Google Cloud adotti per supportare le tue esigenze di analisi dei dati. Ad esempio, Dataflow ti consente di scrivere trasformazioni complesse in un approccio serverless, ma devi fare affidamento su una versione "guidata" delle configurazioni per le esigenze di calcolo ed elaborazione. In alternativa, Dataproc ti consente di eseguire le stesse trasformazioni, ma di gestire i cluster e perfezionare i job in autonomia.

Nella progettazione del sistema, pensa alla strategia di elaborazione utilizzata dai tuoi team, ad esempio estrazione, trasformazione, caricamento (ETL) o estrazione, caricamento e trasformazione (ELT). La progettazione del sistema deve anche valutare se sia necessario elaborare analisi in batch o dei flussi. Google Cloud fornisce una piattaforma dati unificata e ti consente di creare un data lake o un data warehouse per soddisfare le tue esigenze aziendali.

Servizi chiavi

La seguente tabella offre una panoramica generale dei servizi di analisi di Google Cloud:

Servizio Google Cloud	Description
Pub/Sub	Base semplice, affidabile e scalabile per l'analisi dei flussi e sistemi di calcolo basati su eventi.
Dataflow	Un servizio completamente gestito per trasformare e arricchire i dati in modalità flusso (in tempo reale) e batch (storico).
Dataprep di Trifacta	Servizio dati intelligente per esplorare in modo visivo, pulire e preparare dati strutturati e non strutturati per l'analisi.
Dataproc	Servizio cloud completamente gestito, veloce e facile da usare per eseguire i cluster Apache Spark e Apache Hadoop.
Cloud Data Fusion	Servizio di integrazione dei dati completamente gestito, creato per il cloud, che consente di creare e gestire pipeline di dati ETL/ELT. Cloud DataFusion offre un'interfaccia grafica e un'ampia libreria open source di trasformazioni e connettori preconfigurati.
BigQuery	Data warehouse serverless a basso costo e completamente gestito che scala in base alle tue esigenze di archiviazione e potenza di calcolo. BigQuery è un database a colonne e SQL ANSI in grado di analizzare da terabyte a petabyte di dati.
Cloud Composer	Servizio di orchestrazione del flusso di lavoro completamente gestito che consente di creare, pianificare e monitorare pipeline su cloud e data center on-premise.
Catalogo dati	Servizio di gestione dei metadati completamente gestito e scalabile che ti aiuta a scoprire, gestire e comprendere tutti i tuoi dati.
Looker Studio	Servizio di analisi visiva completamente gestito che può aiutarti a estrarre insight dai dati tramite dashboard interattive.
Looker	Piattaforma aziendale che connette, analizza e visualizza i dati in ambienti multi-cloud.
Dataform	Prodotto completamente gestito per aiutarti a collaborare, creare ed eseguire il deployment di pipeline di dati, nonché per garantire la qualità dei dati.
Dataplex	Servizio data lake gestito che gestisce, monitora e regolamenta centralmente i dati nei vari data lake, data warehouse e data mart utilizzando controlli coerenti.
AnalyticsHub	Piattaforma che scambia in modo efficiente e sicuro gli asset di analisi dei dati all'interno della tua organizzazione per affrontare le sfide di affidabilità e costi dei dati.

Ciclo di vita dei dati

Quando crei la progettazione del tuo sistema, puoi raggruppare i servizi di analisi dei dati di Google Cloud in base allo spostamento generale dei dati in qualsiasi sistema o al ciclo di vita dei dati.

Il ciclo di vita dei dati include le fasi e i servizi di esempio seguenti:

• Importazione include servizi come Pub/Sub, Storage Transfer Service, Transfer Appliance e BigQuery.
• Archiviazione include servizi come Cloud Storage, Bigtable, Memorystore e BigQuery.
• Elaborazione e trasformazione include servizi come Dataflow, Dataproc, Dataprep, Sensitive Data Protection e BigQuery.
• Analisi e warehousing include servizi come BigQuery.
• Reporting e visualizzazione include servizi come Looker Studio e Looker.

Le fasi e i servizi seguenti si applicano all'intero ciclo di vita dei dati:

• L'integrazione dei dati include servizi come Data Fusion.
• Gestione e governance dei metadati include servizi come Data Catalog.
• Gestione dei flussi di lavoro include servizi come Cloud Composer.

Importazione dati

Applica le seguenti best practice per l'importazione dati al tuo ambiente.

Determina l'origine per l'importazione dei dati

I dati in genere provengono da un altro cloud provider o servizio o da una località on-premise:

• Per importare i dati da altri cloud provider, in genere utilizzi Cloud Data Fusion, Storage Transfer Service o BigQuery Transfer Service.

• Per l'importazione dati on-premise, considera il volume di dati da importare e le competenze del tuo team. Se il tuo team preferisce un approccio GUI (Graphic User Interface) con poco codice, utilizza Cloud Data Fusion con un connettore appropriato, ad esempio Java Database Connectivity (JDBC). Per grandi volumi di dati, puoi utilizzare Transfer Appliance o Storage Transfer Service.

Valuta come vuoi elaborare i dati dopo l'importazione. Ad esempio, Storage Transfer Service scrive dati solo in un bucket Cloud Storage e BigQuery Data Transfer Service scrive i dati solo in un set di dati BigQuery. Cloud Data Fusion supporta più destinazioni.

Identifica le origini dati in flussi o batch

Valuta come utilizzare i dati e identifica i casi d'uso in modalità flusso o batch. Ad esempio, se esegui un servizio globale di streaming con requisiti di latenza bassi, puoi utilizzare Pub/Sub. Se hai bisogno dei tuoi dati per l'analisi e i report, puoi trasmettere i flussi di dati in BigQuery.

Se devi trasmettere flussi di dati da un sistema come Apache Kafka in un ambiente on-premise o in un altro ambiente cloud, utilizza il modello Dataflow da Kafka a BigQuery. Per i carichi di lavoro batch, la prima cosa da fare in genere consiste nell'importare dati in Cloud Storage. Utilizza lo strumento gsutil o Storage Transfer Service per importare i dati.

Importa i data con strumenti automatizzati

Lo spostamento manuale dei dati da altri sistemi al cloud può rappresentare una sfida. Se possibile, utilizza strumenti che ti consentono di automatizzare i processi di importazione dati. Ad esempio, Cloud Data Fusion fornisce connettori e plug-in per importare i dati da origini esterne con una GUI di trascinamento. Se i tuoi team vogliono scrivere del codice, Flusso di dati o BigQuery possono aiutare ad automatizzare limportazione dati. Pub/Sub può essere utile sia nell'approccio low code che in quello code-first. Per importare i dati nei bucket di archiviazione, utilizza gsutil per dimensioni dei dati fino a 1 TB. Per importare quantità di dati superiori a 1 TB, utilizza Storage Transfer Service.

Usa gli strumenti di migrazione per importare da un altro data warehouse

Se devi eseguire la migrazione da un altro sistema di data warehouse, come Teradata, Netezza o Redshift, puoi utilizzare l'assistenza per la migrazione di BigQuery Data Transfer Service. BigQuery Data Transfer Service fornisce anche trasferimenti di terze parti che ti consentono di importare i dati da origini esterne in base a una pianificazione. Per ulteriori informazioni, consulta gli approcci dettagliati alla migrazione per ciascun data warehouse.

Stima le tue esigenze di importazione di dati

Il volume di dati da importare consente di determinare quale servizio utilizzare nella progettazione del tuo sistema. Per l'importazione di flussi di dati, Pub/Sub scala fino a decine di gigabyte al secondo. I requisiti di capacità, archiviazione e regione per i tuoi dati ti aiutano a determinare se Pub/Sub Lite è un'opzione migliore per la progettazione del tuo sistema. Per maggiori informazioni, consulta la pagina relativa alla scelta di Pub/Sub o Pub/Sub Lite.

Per l'importazione batch dei dati, stima la quantità di dati da trasferire in totale e la velocità da eseguire. Esamina le opzioni di migrazione disponibili, tra cui una stima nel tempo e il confronto dei trasferimenti online e offline.

Usa gli strumenti adeguati per l'importazione regolare di dati in base a una pianificazione

Storage Transfer Service e BigQuery Data Transfer Service consentono entrambi di pianificare i job di importazione. Per un controllo granulare delle tempistiche di importazione o del sistema di origine e di destinazione, utilizza un sistema di gestione dei flussi di lavoro come Cloud Composer. Se vuoi un approccio più manuale, puoi utilizzare Cloud Scheduler e Pub/Sub per attivare una funzione Cloud Functions.
Se vuoi gestire l'infrastruttura di computing, puoi utilizzare il comando gsutil con cron per trasferire dati fino a 1 TB. Se utilizzi questo approccio manuale anziché Cloud Composer, segui le best practice per i trasferimenti in produzione di script.

Esamina le esigenze di importazione di dati da server FTP/SFTP

Se hai bisogno di un ambiente senza codice per importare i dati da un server FTP/SFTP, puoi utilizzare i plug-in per la copia di FTP. Se vuoi modernizzare e creare una soluzione di flusso di lavoro a lungo termine, Cloud Composer è un servizio completamente gestito che ti consente di leggere e scrivere da varie origini e sink.

Usa connettori Apache Kafka per importare i dati

Se utilizzi Pub/Sub, Dataflow o BigQuery, puoi importare i dati utilizzando uno dei connettori Apache Kafka. Ad esempio, il connettore open source Pub/Sub Kafka consente di importare i dati da Pub/Sub o Pub/Sub Lite.

Risorse aggiuntive

• Best practice per l'agente Cloud Storage Transfer Service
• Come importare i dati in BigQuery per analizzarli
• Importazione di dati clinici e operativi con Cloud Data Fusion
• Ottimizzazione dell'importazione su larga scala di eventi e log di analisi

Archiviazione dei dati

Applica le seguenti best practice per l'archiviazione dei dati al tuo ambiente.

Scegli il datastore appropriato per le tue esigenze

Per scegliere il tipo di soluzione di archiviazione da utilizzare, esamina e comprendi l'utilizzo downstream dei tuoi dati. I seguenti casi d'uso comuni per i tuoi dati forniscono suggerimenti su quale prodotto Google Cloud utilizzare:

Caso d'uso dei dati	Consiglio sui prodotti
Basato su file	Filestore
Basato sugli oggetti	Cloud Storage
Bassa latenza	Bigtable
Serie temporale	Bigtable
Cache online	Memorystore
Elaborazione delle transazioni	Cloud SQL
Business intelligence (BI) e analisi	BigQuery
Elaborazione dei dati in modalità batch	Cloud Storage Bigtable se i dati in entrata sono serie temporali e hai bisogno di accedervi a bassa latenza. BigQuery se utilizzi SQL.

Esamina le tue esigenze di struttura dei dati

Per la maggior parte dei dati non strutturati, come documenti e file di testo, file audio e video o log, l'archivio basato su oggetti è la scelta più adatta. Puoi quindi caricare ed elaborare i dati dall'archiviazione di oggetti quando ne hai bisogno.

Per i dati semi-strutturati, come XML o JSON, i tuoi casi d'uso e i pattern di accesso ai dati ti aiutano a indirizzare la scelta. Puoi caricare questi set di dati in BigQuery per il rilevamento automatico dello schema. Se hai requisiti di bassa latenza, puoi caricare i tuoi dati JSON in Bigtable. Se hai requisiti legacy o se le tue applicazioni funzionano con database relazionali, puoi anche caricare set di dati in un archivio di relazioni.

Per i dati strutturati, ad esempio CSV, Parquet, Avro o ORC, puoi utilizzare BigQuery se hai requisiti di BI e analisi che utilizzano SQL. Per maggiori informazioni, consulta Come caricare i dati in batch. Se vuoi creare un data lake su tecnologie e standard aperti, puoi utilizzare Cloud Storage.

Esegui la migrazione dei dati e riduci i costi per HDFS

Cerca modi per spostare i dati di Hadoop Distributed File System (HDFS) da on-premise o da un altro cloud provider a un sistema di archiviazione di oggetti più economico. Cloud Storage è la scelta più comune effettuata dalle aziende come datastore alternativo. Per informazioni sui vantaggi e sugli svantaggi di questa scelta, consulta HDFS e Cloud Storage.

Puoi trasferire i dati con un metodo push o pull. Entrambi i metodi utilizzano il comando hadoop distcp. Per maggiori informazioni, consulta Migrazione dei dati HDFS da on-premise a Google Cloud.

Puoi anche utilizzare il connettore Cloud Storage open source per consentire a job Hadoop e Spark di accedere ai dati in Cloud Storage. Il connettore è installato per impostazione predefinita sui cluster Dataproc e può essere installato manualmente su altri cluster.

Usa l'archiviazione a oggetti per creare un data lake coerente

Un data lake è un repository centralizzato progettato per archiviare, elaborare e proteggere grandi quantità di dati strutturati, semistrutturati e non strutturati. Puoi utilizzare Cloud Composer e Cloud Data Fusion per creare un data lake.

Per creare una piattaforma dati moderna, puoi utilizzare BigQuery come origine dati centrale anziché Cloud Storage. BigQuery è un data warehouse moderno con separazione tra archiviazione e computing. Un data lake basato su BigQuery consente di eseguire analisi tradizionali da BigQuery nella console Cloud. Ti consente inoltre di accedere ai dati archiviati da altri framework come Apache Spark.

Risorse aggiuntive

• Best practice per Cloud Storage
• Best practice per l'ottimizzazione dei costi di Cloud Storage
• Best practice per garantire la privacy e la sicurezza dei tuoi dati in Cloud Storage
• Best practice per Memorystore
• Ottimizzare lo spazio di archiviazione in BigQuery
• Progettazione dello schema di Bigtable

Elabora e trasforma i dati

Applica le seguenti best practice di analisi dei dati al tuo ambiente quando elabori e trasformi i dati.

Esplora i software open source che puoi utilizzare in Google Cloud

Molti servizi Google Cloud utilizzano software open source per facilitare la transizione. Google Cloud offre soluzioni gestite e serverless con API aperte e compatibili con framework open source per ridurre i vincoli al fornitore.

Dataproc è un servizio gestito compatibile con Hadoop che ti consente di ospitare software open source con un carico operativo minimo. Dataproc include il supporto per Spark, Hive, Pig, Presto e Zookeeper. Fornisce inoltre Hive Metastore come servizio gestito per rimuovere se stesso come single point of failure nell'ecosistema Hadoop.

Puoi eseguire la migrazione a Dataflow se al momento utilizzi Apache Beam come motore di elaborazione in modalità flusso e batch. Dataflow è un servizio completamente gestito e serverless che utilizza Apache Beam. Usa Dataflow per scrivere job in Beam, ma lascia che Google Cloud gestisca l'ambiente di esecuzione.

Se utilizzi CDAP come piattaforma di integrazione dei dati, puoi eseguire la migrazione a Cloud Data Fusion per un'esperienza completamente gestita.

Determina le tue esigenze di elaborazione dei dati ETL o ELT

L'esperienza e le preferenze del tuo team aiutano a determinare la progettazione del sistema per l'elaborazione dei dati. Google Cloud consente di utilizzare sistemi di trattamento dati ETL tradizionale o ELT più moderni.

• Per le pipeline ETL, puoi utilizzare Data Fusion, Dataproc o Dataflow.

  • Per i nuovi ambienti, consigliamo Dataflow per avere un modo unificato per creare applicazioni in modalità flusso e batch.
  • Per un approccio completamente gestito, Data Fusion fornisce una GUI di trascinamento per aiutarti a creare pipeline.

• Per le pipeline ELT, utilizza BigQuery, che supporta il caricamento dei dati in modalità batch e flusso. Una volta che i dati sono in BigQuery, utilizza SQL per eseguire tutte le trasformazioni e ricavare nuovi set di dati per i tuoi casi d'uso aziendali.

• Se vuoi modernizzare e passare dall'ETL a ELT, puoi utilizzare Dataform.

Usa il framework appropriato per il tuo caso d'uso dei dati

I casi d'uso dei dati determinano quali strumenti e framework utilizzare. Alcuni prodotti Google Cloud sono progettati per gestire tutti i seguenti casi d'uso dei dati, mentre altri supportano al meglio un solo caso d'uso particolare.

• Per un sistema di elaborazione dati in batch, puoi elaborare e trasformare i dati in BigQuery con un'interfaccia SQL familiare. Se hai una pipeline esistente in esecuzione su Apache Hadoop o Spark on-premise o su un altro cloud pubblico, puoi utilizzare Dataproc.
  • Puoi usare Dataflow se vuoi un'interfaccia di programmazione unificata per i casi d'uso in modalità flusso e batch. Ti consigliamo di modernizzare e utilizzare Dataflow per ETL e BigQuery per ELT.

• Per le pipeline di flussi di dati, utilizzi un servizio gestito e serverless come Dataflow che fornisce windowing, scalabilità automatica e modelli. Per ulteriori informazioni, consulta Creazione di pipeline di dati pronte per la produzione utilizzando Dataflow.

  • Se disponi di team e capacità incentrati sull'analisi e su SQL, puoi anche trasmettere i flussi di dati in BigQuery.

• Per i casi d'uso in tempo reale, come l'analisi di serie temporali o l'analisi dei video in streaming, utilizza Dataflow.

Mantieni il controllo futuro sul tuo motore di esecuzione

Per ridurre al minimo i vincoli al fornitore e poter utilizzare in futuro una piattaforma diversa, utilizza il modello di programmazione Apache Beam e Dataflow come soluzione serverless gestita. Il modello di programmazione Beam ti consente di modificare il motore di esecuzione sottostante, ad esempio passando da Dataflow ad Apache Flink o Apache Spark.

Usa Dataflow per importare dati da più origini

Per importare i dati da più origini, come Pub/Sub, Cloud Storage, HDFS, S3 o Kafka, utilizza Dataflow. Dataflow è un servizio serverless gestito che supporta i modelli Dataflow, che consente ai tuoi team di eseguire modelli da diversi strumenti.

Dataflow Prime fornisce la scalabilità automatica orizzontale e verticale delle macchine utilizzate nel processo di esecuzione di una pipeline. Offre anche diagnostica e consigli intelligenti che identificano i problemi e suggeriscono come correggerli.

Scopri, identifica e proteggi i dati sensibili

Utilizza Sensitive Data Protection per esaminare e trasformare dati strutturati e non strutturati. Sensitive Data Protection funziona per i dati che si trovano ovunque in Google Cloud, ad esempio Cloud Storage o nei database. Puoi classificare, mascherare e tokenizzare i dati sensibili per continuare a utilizzarli in modo sicuro per l'elaborazione downstream. Utilizza la protezione dei dati sensibili per eseguire azioni come scansionare i dati BigQuery o anonimizzare e reidentificare le PII in set di dati su larga scala.

Modernizza i tuoi processi di trasformazione dei dati

Utilizza Dataform per scrivere trasformazioni dei dati come codice e per iniziare a utilizzare il controllo della versione per impostazione predefinita. Puoi anche adottare le best practice per lo sviluppo di software come CI/CD, test delle unità e controllo della versione per il codice SQL. Dataform supporta tutti i principali prodotti e database di data warehouse su cloud, come PostgreSQL.

Risorse aggiuntive

• Dataproc
  • Guida alle best practice
  • Suggerimenti per i cluster a lunga esecuzione
  • Utilizzo di Apache Hive su Dataproc
  • Best practice per l'esecuzione in produzione
  • Best practice per l'utilizzo di Apache Ranger
  • Suggerimenti per la configurazione della scalabilità automatica
  • Guida per i job Hadoop/Spark lenti
• Dataflow:
  • Sposta le pipeline in produzione
  • Casi d'uso comuni
• Data Fusion
  • Rendimento della pipeline
• BigQuery
  • Ottimizzare le prestazioni delle query
• Dataform
  • Best practice per la gestione dei progetti
• Protezione dei dati sensibili
  • Tieni sotto controllo i costi
  • Ispeziona lo spazio di archiviazione e i database per l'individuazione di dati sensibili
  • Ispezionare il testo per l'individuazione di dati sensibili

Analisi dei dati e data warehouse

Applica le seguenti best practice per l'analisi dei dati e il warehouse al tuo ambiente.

Rivedi le tue esigenze di archiviazione dei dati

I data lake e i data warehouse non si escludono a vicenda. I data lake sono utili per l'elaborazione e l'archiviazione di dati non strutturati e semi-strutturati. I data warehouse sono i migliori per analisi e BI.

Esamina le tue esigenze di dati per determinare dove archiviare i tuoi dati e quale prodotto Google Cloud è il più appropriato per elaborare e analizzare i tuoi dati. Prodotti come BigQuery sono in grado di elaborare PB di dati e crescere di pari passo con le tue esigenze.

Identifica le opportunità per la migrazione da un data warehouse tradizionale a BigQuery

Esamina i data warehouse tradizionali attualmente in uso nel tuo ambiente. Per ridurre la complessità e, potenzialmente, i costi, identifica le opportunità di migrazione dei tuoi data warehouse tradizionali a un servizio Google Cloud come BigQuery. Per ulteriori informazioni e per scenari di esempio, consulta Migrazione dei data warehouse in BigQuery.

Pianifica l'accesso federato ai dati

Esamina i requisiti dei tuoi dati e le possibili interazioni con altri prodotti e servizi. Identifica le tue esigenze di federazione dei dati e crea una progettazione di sistema appropriata.

Ad esempio, BigQuery consente di definire tabelle esterne che possono leggere i dati da altre origini, come Bigtable, Cloud SQL, Cloud Storage o Google Drive. Puoi unire queste origini esterne a tabelle archiviate in BigQuery.

Usa gli slot flessibili di BigQuery per fornire capacità burst on demand

A volte hai bisogno di capacità aggiuntiva per eseguire analisi sperimentali o esplorative che richiedono molte risorse di calcolo. BigQuery ti consente di ottenere capacità di calcolo aggiuntiva sotto forma di slot flessibili. Questi slot flessibili sono utili in caso di periodo di domanda elevata o quando vuoi completare un'analisi importante.

Comprendi le differenze nello schema se esegui la migrazione a BigQuery

BigQuery supporta gli schemi star e snowflake, ma per impostazione predefinita utilizza i campi nidificati e ripetuti. I campi nidificati e ripetuti possono essere più facili da leggere e correlare rispetto ad altri schemi. Se i dati sono rappresentati in uno schema a stella o a fiocco di neve e vuoi eseguire la migrazione a BigQuery, esamina la progettazione del sistema per individuare eventuali modifiche necessarie a processi o analisi.

Risorse aggiuntive

• Best practice per i carichi di lavoro multi-tenant su BigQuery
• Best practice per la sicurezza a livello di riga in BigQuery
• Best practice per le viste materializzate in BigQuery

Report e visualizzazione

Applica le seguenti best practice per i report e la visualizzazione al tuo ambiente.

Usa BigQuery BI Engine per visualizzare i tuoi dati

BigQuery BI Engine è un servizio di analisi in memoria rapido. Puoi utilizzare BI Engine per analizzare i dati archiviati in BigQuery con tempi di risposta alle query di frazioni di secondo e con elevata contemporaneità. BI Engine è integrato nell'API BigQuery. Utilizza la capacità prenotata di BI Engine per gestire i prezzi on demand o a costo fisso per le tue esigenze. BI Engine può anche funzionare con altre applicazioni di BI o dashboard personalizzate che richiedono tempi di risposta di frazioni di secondo.

Modernizza i tuoi processi di BI con Looker

Looker è una piattaforma aziendale moderna per BI, applicazioni di dati e analisi incorporate. Puoi creare modelli dei dati coerenti sulla base dei tuoi dati in modo rapido e preciso e accedere ai dati all'interno di datastore transazionali e analitici. Looker può anche analizzare i dati su più database e cloud. Se disponi di processi e strumenti BI esistenti, ti consigliamo di modernizzare e utilizzare una piattaforma centralizzata come Looker.

Risorse aggiuntive

• Migrazione dei data warehouse in BigQuery: report e analisi
• Architettura per la connessione del software di visualizzazione a Hadoop su Google Cloud
• Velocizzare le piccole query in BigQuery con BI Engine

Usa strumenti di gestione del flusso di lavoro

L'analisi dei dati coinvolge molti processi e servizi. I dati si spostano tra strumenti e pipeline di elaborazione diversi durante il ciclo di vita dell'analisi dei dati. Per gestire e mantenere pipeline di dati end-to-end, utilizza strumenti di gestione dei flussi di lavoro appropriati. Cloud Composer è uno strumento di gestione del flusso di lavoro completamente gestito basato sul progetto open source Apache Airflow.

Puoi utilizzare Cloud Composer per avviare pipeline Dataflow e per utilizzare modelli di flusso di lavoro Dataproc. Cloud Composer può anche aiutarti a creare una pipeline CI/CD per testare, sincronizzare ed eseguire il deployment di DAG oppure utilizzare una pipeline CI/CD per i flussi di lavoro di elaborazione dati. Per saperne di più, guarda il video Cloud Composer: Development Best Practices.

Risorse per la migrazione

Se utilizzi già una piattaforma di analisi dei dati e vuoi eseguire la migrazione di alcuni o di tutti i carichi di lavoro in Google Cloud, consulta le seguenti risorse di migrazione per conoscere best practice e indicazioni:

• Indicazioni generali sulla migrazione
  • Migrazione a Google Cloud: scelta del percorso di migrazione.
  • Esempio di modernizzazione della piattaforma di analisi del coinvolgimento con gli annunci di Twitter.
• Migrazione a Cloud Storage
  • Migrazione dei dati HDFS da on-premise a Google Cloud.
  • Trasferimento di dati da Amazon S3 a Cloud Storage utilizzando Controlli di servizio VPC e Storage Transfer Service.
• Migrazione di Pub/Sub
  • Migrazione da Kafka a Pub/Sub.
• Migrazione di Bigtable
  • Migrazione dei dati da HBase a Bigtable.
  • Migrazione da Aerospike a Bigtable.
• Migrazione di Dataproc
  • Migrazione dell'infrastruttura Hadoop on-premise a Google Cloud.
  • Costi e suggerimenti della migrazione Hadoop.
  • Hadoop in Dataproc.
  • Job Hadoop on-premise a Dataproc.
  • Da Spark a Dataproc.
  • External Hive Metastore in Dataproc Metastore.
• Migrazione a BigQuery
  • Sfide di migrazione dei data warehouse legacy.
  • Migrazione dei data warehouse in BigQuery.
  • BigQuery per i professionisti dei data warehouse.
• Migrazione di Composer
  • Esegui la migrazione degli ambienti a Airflow 2.

Passaggi successivi

Scopri le best practice di progettazione del sistema per l'IA e il machine learning di Google Cloud, tra cui:

• Scopri di più sui servizi di IA e machine learning di Google Cloud che supportano la progettazione del sistema.
• Scopri le best practice per l'elaborazione dei dati ML.
• Scopri le best practice per lo sviluppo e l'addestramento di modelli.

Esplora altre categorie nel framework dell'architettura come affidabilità, eccellenza operativa e sicurezza, privacy e conformità.

Implementazione del machine learning

Questo documento nel framework dell'architettura Google Cloud illustra alcuni dei principi fondamentali e delle best practice per l'analisi dei dati in Google Cloud. Scoprirai alcuni dei principali servizi di AI e machine learning (ML) e come possono essere utili durante le varie fasi del ciclo di vita di AI e ML. Queste best practice ti aiutano a soddisfare le tue esigenze di AI e ML e a creare la progettazione del tuo sistema. Questo documento presuppone la conoscenza di concetti AI e ML di base.

Per semplificare il processo di sviluppo e ridurre al minimo l'overhead quando crei modelli ML su Google Cloud, prendi in considerazione il massimo livello di astrazione adatto al tuo caso d'uso. Il livello di astrazione è definito come la quantità di complessità con cui un sistema viene visualizzato o programmato. Più alto è il livello di astrazione, minore è il dettaglio disponibile per lo spettatore.

Per selezionare i servizi IA e ML di Google in base alle tue esigenze aziendali, utilizza la seguente tabella:

Utente tipo	Servizi Google
Utenti aziendali	Soluzioni standard come Contact Center AI Insights, Document AI, Discovery AI e API Cloud Healthcare.
Sviluppatori con esperienza di ML minima	Le API preaddestrate eseguono attività percettive comuni come visione artificiale, video e linguaggio naturale. Queste API sono supportate da modelli preaddestrati e forniscono rilevatori predefiniti. Sono pronte per l'uso, senza alcuna esperienza in materia di ML o di sviluppo di modelli. Le API preaddestrate includono: API Vision, API Video, API Natural Language, API Speech-to-Text, API Text-to-Speech e API Cloud Translation.
IA generativa per sviluppatori	Vertex AI Search and Conversation consente agli sviluppatori di utilizzare le sue funzionalità predefinite per creare ed eseguire il deployment di chatbot in pochi minuti e motori di ricerca in poche ore. Gli sviluppatori che vogliono combinare più funzionalità nei flussi di lavoro aziendali possono utilizzare l'API Gen App Builder per l'integrazione diretta.
Sviluppatori e data scientist	AutoML consente lo sviluppo di modelli personalizzati con i tuoi dati immagine, video, di testo o tabulari. AutoML accelera lo sviluppo dei modelli con la ricerca automatica nella raccolta di modelli di Google per ottenere l'architettura dei modelli con le migliori prestazioni, in modo da non dover creare il modello. AutoML gestisce automaticamente le attività più comuni, come la scelta di un'architettura del modello, l'ottimizzazione degli iperparametri e il provisioning delle macchine per l'addestramento e la gestione.
Data scientist e ML engineer	Gli strumenti per modelli personalizzati di Vertex AI consentono di addestrare e gestire modelli personalizzati e rendere operativi il flusso di lavoro ML. Puoi anche eseguire il tuo carico di lavoro ML su un computing autogestito come le VM di Compute Engine.
Data scientist e machine learning engineer	Il supporto dell'IA generativa su Vertex AI (noto anche come genai) fornisce l'accesso ai grandi modelli di IA generativa di Google per consentirti di testare, ottimizzare ed eseguire il deployment dei modelli nelle tue applicazioni basate sull'IA.
Data engineer, data scientist e analisti di dati che hanno familiarità con le interfacce SQL	BigQuery ML ti consente di sviluppare modelli basati su SQL sulla base dei dati archiviati in BigQuery.

Servizi chiavi

La tabella seguente fornisce una panoramica generale dei servizi AI e ML:

Servizio Google	Description
Cloud Storage e BigQuery	Offri opzioni di archiviazione flessibili per dati e artefatti di machine learning.
BigQuery ML	Consente di creare modelli di machine learning direttamente da dati ospitati in BigQuery.
Pub/Sub, Dataflow, Cloud Data Fusion e Dataproc	Supporta l'importazione e l'elaborazione dei dati in batch e in tempo reale. Per ulteriori informazioni, consulta Analisi di dati.
Vertex AI	Offre a data scientist e machine learning engineer un'unica piattaforma per creare, addestrare, testare, monitorare, ottimizzare ed eseguire il deployment di modelli ML per qualsiasi attività, dall'AI generativa alle MLOps. Gli strumenti includono quanto segue: Etichettatura dei dati Vertex per ottenere etichette dati accurate. Deep Learning Containers per creare ed eseguire il deployment di modelli in un ambiente portabile e coerente. Vertex AI Workbench per un ambiente JupyterLab gestito o gestito dall'utente. Addestramento Vertex per un servizio completamente gestito. Vertex AI TensorBoard per il monitoraggio degli esperimenti. Vertex AI Vizier per l'ottimizzazione degli iperparametri. Previsioni Vertex per un framework di deployment unificato che supporta modelli BigQuery ML e AutoML con addestramento personalizzato. Vertex Explainable AI per mostrare spiegazioni per le previsioni di modelli. Esperimenti Vertex per accelerare il deployment dei modelli in produzione. Ora con una selezione più rapida dei modelli. Strumenti MLOps come Vertex AI Pipelines per l'orchestrazione e Vertex AI Feature Store per un repository di funzionalità completamente gestito.
Vertex AI Search and Conversation	Consente di creare chatbot e motori di ricerca per i siti web e per l'utilizzo nei dati aziendali. L'IA conversazionale su Vertex AI Search and Conversation può aiutare a reinventare le interazioni di clienti e dipendenti con chatbot e assistenti digitali basati sull'IA generativa. Ad esempio, con questi strumenti puoi fornire più di semplici informazioni abilitando le transazioni dall'interno dell'esperienza di chat. Enterprise Search on Vertex AI Search and Conversation consente alle aziende di creare esperienze di ricerca per clienti e dipendenti sui loro siti web pubblici o privati. Oltre a fornire risultati di ricerca multimodali di alta qualità, Enterprise Search può anche riassumere i risultati e fornire le citazioni corrispondenti con lAI generativa.
IA generativa su Vertex AI	Consente di accedere ai modelli di IA generativa di grandi dimensioni di Google in modo da testarli, ottimizzarli ed eseguirne il deployment per l'uso nelle applicazioni basate sull'IA. L'IA generativa su Vertex AI è nota anche come genai. I modelli di AI generativa, noti anche come modelli di base, sono classificati in base al tipo di contenuti per cui sono progettati. Questi contenuti includono testi e chat, immagini, codici e incorporamenti di testo. Vertex AI Studio consente di prototipare e testare rapidamente modelli di IA generativa nella console Google Cloud. Puoi testare i prompt di esempio, progettare i tuoi prompt e personalizzare i modelli di base per gestire attività che soddisfano le esigenze della tua applicazione. Ottimizzazione dei modelli: consente di personalizzare i modelli di base per casi d'uso specifici ottimizzandoli utilizzando un set di dati di esempi di input-output. Model Garden fornisce modelli di base di livello enterprise, modelli specifici per le attività e API.
API preaddestrate	Le API preaddestrate includono API Vision, API Video, API Natural Language, API Speech-to-Text, API Text-to-Speech e API Cloud Translation.
AutoML	Fornisce strumenti per modelli personalizzati per creare, eseguire il deployment e scalare i modelli ML. Gli sviluppatori possono caricare i propri dati e usare il servizio AutoML applicabile per creare un modello. AutoML Image: esegue la classificazione delle immagini e il rilevamento di oggetti sui dati delle immagini. AutoML Video: esegue il rilevamento degli oggetti, la classificazione e il riconoscimento delle azioni sui dati video. AutoML Text: esegue la classificazione dei linguaggi, l'estrazione delle entità e l'analisi del sentiment sui dati di testo. AutoML Translation: rileva e traduce tra coppie di lingue. Tabulare AutoML: consente di creare un modello di regressione, classificazione o previsione. Destinato ai dati strutturati.
AI infrastructure	Consente di utilizzare acceleratori di AI per elaborare carichi di lavoro ML su larga scala. Questi acceleratori consentono di addestrare e ottenere inferenze da modelli di deep learning e da modelli di machine learning in modo conveniente. Le GPU possono essere utili per l'inferenza economica e per l'addestramento con scale up o scale out per i modelli di deep learning. Le Tensor Processing Unit (TPU) sono ASIC personalizzati per addestrare ed eseguire reti neurali profonde.
Dialogflow	Fornisce agenti virtuali che offrono un'esperienza di conversazione.
Contact Center AI	Fornisce un'esperienza di contact center automatizzata e ricca di insight con la funzionalità Agent Assist per agenti umani.
Document AI	Offre una comprensione dei documenti su larga scala per documenti in generale e per tipi di documenti specifici, come quelli relativi al prestito e all'approvvigionamento.
Lending DocAI	Automatizza l'elaborazione di documenti relativi ai mutui. Riduce i tempi di elaborazione e semplifica l'acquisizione dei dati supportando al contempo i requisiti normativi e di conformità.
Procurement DocAI	Automatizza l'acquisizione dei dati di approvvigionamento su larga scala trasformando documenti non strutturati (come fatture e ricevute) in dati strutturati per aumentare l'efficienza operativa, migliorare l'esperienza del cliente e informare i processi decisionali.
Suggerimenti	Fornisce consigli personalizzati sui prodotti.
AI Healthcare Natural Language	Consente di rivedere e analizzare documenti medici.
API Media Translation	Consente la traduzione del parlato in tempo reale dai dati audio.

Trattamento dati

Applica le seguenti best practice per il trattamento dei dati al tuo ambiente.

Assicurati che i dati soddisfino i requisiti di ML

I dati utilizzati per il machine learning devono soddisfare determinati requisiti di base, indipendentemente dal tipo di dati. Questi requisiti includono la capacità dei dati di prevedere il target, la coerenza nella granularità tra i dati utilizzati per l'addestramento e quelli utilizzati per la previsione e i dati etichettati con precisione per l'addestramento. I dati dovrebbero inoltre essere sufficienti in termini di volume. Per scoprire di più, consulta Trattamento dati.

Archivia i dati tabulari in BigQuery

Se utilizzi dati tabulari, valuta la possibilità di archiviare tutti i dati in BigQuery e di utilizzare l'API BigQuery Storage per leggerne i dati. Per semplificare l'interazione con l'API, utilizza uno dei seguenti strumenti aggiuntivi, a seconda di dove vuoi leggere i dati:

• Se utilizzi Dataflow, utilizza il connettore I/O di BigQuery.
• Se utilizzi TensorFlow o Keras, usa il lettoretf.data.dataset per BigQuery.
• Se usi dati non strutturati come immagini o video, valuta la possibilità di archiviare tutti i dati in Cloud Storage.

Il tipo di dati di input determina inoltre gli strumenti disponibili per lo sviluppo del modello. Le API preaddestrate, AutoML e BigQuery ML possono fornire ambienti di sviluppo più convenienti ed efficienti in termini di tempo per determinati casi d'uso di immagini, video, testo e dati strutturati.

Assicurati di avere dati sufficienti a sviluppare un modello di ML

Per sviluppare un modello di ML utile, devi avere abbastanza dati. Per prevedere una categoria, il numero consigliato di esempi per ogni categoria è dieci volte il numero di caratteristiche. Più categorie vuoi prevedere, più dati avrai bisogno. I set di dati non bilanciati richiedono ancora più dati. Se non hai a disposizione un volume sufficiente di dati etichettati, prendi in considerazione l'apprendimento semi-supervisionato.

Le dimensioni del set di dati influiscono anche sull'addestramento e sulla pubblicazione: se disponi di un set di dati di piccole dimensioni, puoi addestrarlo direttamente all'interno di un'istanza Notebooks; se disponi di set di dati più grandi che richiedono l'addestramento distribuito, utilizza il servizio di addestramento personalizzato Vertex AI. Se vuoi che Google addestra il modello per i tuoi dati, utilizza AutoML.

Prepara i dati per il consumo

Una buona preparazione dei dati può accelerare lo sviluppo del modello. Quando configuri la tua pipeline di dati, assicurati che possa elaborare dati sia in modalità flusso che in batch, in modo da ottenere risultati coerenti da entrambi i tipi di dati.

Sviluppo e addestramento di modelli

Applica le seguenti best practice per lo sviluppo e l'addestramento di modelli al tuo ambiente.

Scegli lo sviluppo di modelli gestiti o con addestramento personalizzato

Quando crei il tuo modello, considera il massimo livello di astrazione possibile. Quando possibile, usa AutoML per gestire le attività di sviluppo e addestramento. Per i modelli con addestramento personalizzato, scegli opzioni gestite per scalabilità e flessibilità, anziché opzioni autogestite. Per scoprire di più sulle opzioni di sviluppo dei modelli, consulta Utilizzare gli strumenti e i prodotti consigliati.

Prendi in considerazione il servizio di addestramento Vertex AI anziché l'addestramento autogestito sulle VM di Compute Engine o i container Deep Learning VM. Per un ambiente JupyterLab, prendi in considerazione Vertex AI Workbench, che fornisce ambienti JupyterLab gestiti e gestiti dall'utente. Per maggiori informazioni, consulta Sviluppo del machine learning e Addestramento operativo.

Usa container predefiniti o personalizzati per i modelli con addestramento personalizzato

Per i modelli con addestramento personalizzato su Vertex AI, puoi utilizzare container predefiniti o personalizzati a seconda del framework e della versione del framework di machine learning. I container predefiniti sono disponibili per le applicazioni di addestramento Python create per versioni specifiche di TensorFlow, scikit-learn, PyTorch e XGBoost.

In alternativa, puoi scegliere di creare un container personalizzato per il job di addestramento. Ad esempio, utilizza un container personalizzato se vuoi addestrare il modello con un framework ML Python non disponibile in un container predefinito, oppure se vuoi eseguire l'addestramento con un linguaggio di programmazione diverso da Python. Nel tuo container personalizzato, preinstalla l'applicazione di addestramento e tutte le sue dipendenze su un'immagine che esegue il job di addestramento.

Considera i requisiti di addestramento distribuito

Considera i tuoi requisiti di addestramento distribuito. Alcuni framework di ML, come TensorFlow e PyTorch, consentono di eseguire codice di addestramento identico su più macchine. Questi framework coordinano automaticamente la divisione del lavoro in base alle variabili di ambiente impostate su ogni macchina. Altri framework potrebbero richiedere un'ulteriore personalizzazione.

Passaggi successivi

Per saperne di più su AI e machine learning, consulta quanto segue:

• Best practice per l'implementazione del machine learning su Google Cloud.
• Guida a MLOps per i professionisti: un framework per la distribuzione continua e l'automazione del machine learning.

Esplora altre categorie nel framework dell'architettura come affidabilità, eccellenza operativa e sicurezza, privacy e conformità.

Progetta per la sostenibilità ambientale

Questo documento nel framework dell'architettura Google Cloud riassume come puoi affrontare la sostenibilità ambientale per i tuoi carichi di lavoro in Google Cloud. e include informazioni su come ridurre al minimo l'impronta di carbonio su Google Cloud.

Comprendere la propria impronta di carbonio

Per comprendere l'impatto ambientale derivante dall'utilizzo di Google Cloud, utilizza la dashboard Carbon Footprint. La dashboard di Carbon Footprint attribuisce le emissioni ai progetti Google Cloud di tua proprietà e ai servizi cloud che utilizzi.

Per ulteriori informazioni, consulta Comprendere la tua impronta di carbonio in "Ridurre l'impronta di carbonio di Google Cloud".

Scegli le regioni cloud più adatte

Un modo semplice ed efficace per ridurre le emissioni di anidride carbonica è scegliere regioni cloud con emissioni di anidride carbonica più basse. Per aiutarti a scegliere, Google pubblica i dati sulle emissioni di anidride carbonica per tutte le regioni Google Cloud.

Quando scegli una regione, potresti dover bilanciare la riduzione delle emissioni con altri requisiti, come i prezzi e la latenza di rete. Per selezionare una regione, utilizza il selettore della regione di Google Cloud.

Per ulteriori informazioni, consulta Scegliere le regioni cloud più adatte in "Ridurre l'impronta di carbonio di Google Cloud".

Scegli i servizi cloud più adatti

Per ridurre l'impronta di carbonio esistente, valuta la possibilità di eseguire la migrazione dei carichi di lavoro delle VM on-premise a Compute Engine.

Inoltre, tieni presente che molti carichi di lavoro non richiedono VM. Spesso è possibile utilizzare un'offerta serverless. Questi servizi gestiti possono ottimizzare l'utilizzo delle risorse cloud, spesso automaticamente, il che riduce contemporaneamente i costi del cloud e l'impatto ambientale.

Per maggiori informazioni, consulta Scegliere i servizi cloud più adatti in "Ridurre l'impronta di carbonio di Google Cloud".

Riduci al minimo le risorse cloud inattive

Le risorse inattive comportano costi ed emissioni inutili. Alcune cause comuni delle risorse inattive sono:

• Risorse cloud attive inutilizzate, ad esempio istanze VM inattive.
• Risorse in overprovisioning, ad esempio istanze di VM più grandi tipi di macchine rispetto a quelle necessarie per un carico di lavoro.
• Architetture non ottimali, come le migrazioni lift and shift che non sono sempre ottimizzate per l'efficienza. Valuta la possibilità di apportare miglioramenti incrementali a queste architetture.

Di seguito sono riportate alcune strategie generali per aiutare a ridurre al minimo lo spreco di risorse cloud:

• Identifica le risorse inattive o con overprovisioning e poi eliminale o ridimensionandole.
• Refactoring dell'architettura per incorporare un design più ottimale.
• Migrazione dei carichi di lavoro a servizi gestiti.

Per ulteriori informazioni, consulta Ridurre al minimo le risorse cloud inattive in "Ridurre l'impronta di carbonio di Google Cloud".

Riduci le emissioni per i carichi di lavoro batch

Esegui carichi di lavoro batch in regioni con minori emissioni di anidride carbonica. Per ulteriori riduzioni, esegui i carichi di lavoro in orari che coincidono con una minore intensità di carbonio della rete, se possibile.

Per maggiori informazioni, consulta Ridurre le emissioni per i carichi di lavoro batch in "Ridurre l'impronta di carbonio di Google Cloud".

Passaggi successivi

• Scopri come utilizzare i dati di Carbon Footprint per misurare, registrare e ridurre le emissioni di anidride carbonica del cloud.
• Scopri come ridurre l'impronta di carbonio di Google Cloud.

Framework dell'architettura Google Cloud: eccellenza operativa

Questa categoria nel framework dell'architettura Google Cloud mostra come gestire i servizi in modo efficiente su Google Cloud. Descrive come eseguire, gestire e monitorare i sistemi che apportano valore aziendale. Esamina inoltre i prodotti e le funzionalità di Google Cloud che supportano l'eccellenza operativa. L'utilizzo dei principi di eccellenza operativa consente di creare le basi per l'affidabilità. Per farlo, imposta elementi fondamentali come osservabilità, automazione e scalabilità.

Questo framework dell'architettura descrive le best practice, fornisce suggerimenti per l'implementazione e spiega alcuni prodotti e servizi disponibili che ti aiutano a raggiungere l'eccellenza operativa. Il framework mira ad aiutarti a progettare il deployment di Google Cloud in modo che si adatti al meglio alle tue esigenze aziendali.

Nella categoria di eccellenza operativa del framework dell'architettura imparerai a:

• Automatizza i deployment
• Configura monitoraggio, avvisi e logging
• Creazione di processi di assistenza e escalation nel cloud
• Gestione di capacità e quota
• Pianificare gli eventi di traffico di picco e di lancio
• Crea una cultura dell'automazione

Automazione dei deployment

Questo documento nel framework dell'architettura Google Cloud fornisce le best practice per l'automazione di build, test e deployment.

L'Automation ti aiuta a standardizzare build, test e deployment eliminando gli errori causati dall'uomo per processi ripetuti come gli aggiornamenti del codice. Questa sezione descrive come utilizzare vari controlli e protezioni durante l'automazione. Un processo standardizzato controllato da macchina garantisce l'applicazione sicura. Fornisce inoltre un meccanismo per ripristinare i deployment precedenti in base alle esigenze senza influire notevolmente sull'esperienza utente.

Archivia il tuo codice nei repository di codici centrali

Archivia il tuo codice in repository di codice centrali che includono un sistema di controllo della versione con tagging e la possibilità di eseguire il rollback delle modifiche al codice. Il controllo della versione consente di organizzare i file e controllare l'accesso, gli aggiornamenti e l'eliminazione nei team e nelle organizzazioni.

Per diverse fasi dello sviluppo, versioni ed etichetta i repository in base alle esigenze. Ad esempio, le etichette potrebbero essere test, dev e prod.

In Google Cloud puoi archiviare il codice in Cloud Source Repositories, creare versioni e integrarle con altri prodotti Google Cloud. Se stai creando applicazioni containerizzate, utilizza Artifact Registry, un registro gestito per i container.

Per maggiori dettagli sul controllo della versione, consulta Controllo della versione. Per maggiori dettagli sull'implementazione dello sviluppo basato su trunk con i tuoi repository, consulta Sviluppo basato su trunk.

Utilizza l'integrazione e il deployment continui

Automatizza i deployment utilizzando un approccio di integrazione e deployment continui (CI/CD). Un approccio CI/CD è una combinazione di pipeline configurate e processi seguiti dal tuo team di sviluppo.

L'approccio CI/CD aumenta la velocità di deployment aumentando la produttività del team di sviluppo software. Questo approccio consente agli sviluppatori di apportare modifiche più piccole e più frequenti che vengono testate in modo approfondito, riducendo al contempo il tempo necessario per il deployment di tali modifiche.

Nell'ambito del tuo approccio CI/CD, automatizza tutti i passaggi che fanno parte della creazione, del test e del deployment del codice. Ad esempio:

• Ogni volta che viene eseguito il commit di un nuovo codice nel repository, fai in modo che il commit richiami automaticamente la pipeline di creazione e test.
• Automatizza i test di integrazione.
• Automatizza il deployment in modo che le modifiche vengano implementate dopo che la build soddisfa criteri di test specifici.

In Google Cloud, puoi utilizzare Cloud Build e Cloud Deploy per le tue pipeline CI/CD.

Usa Cloud Build per definire le dipendenze e le versioni che puoi utilizzare per la pacchettizzazione e la creazione di un pacchetto dell'applicazione. Versione della configurazione della build per assicurarti che tutte le build siano coerenti e per assicurarti di poter eseguire il rollback a una configurazione precedente, se necessario.

Usa Cloud Deploy per il deployment delle tue applicazioni in ambienti specifici su Google Cloud e per gestire le pipeline di deployment.

Per maggiori dettagli sull'implementazione di CI/CD, consulta Integrazione continua e Automazione del deployment.

Esegui il provisioning e la gestione dell'infrastruttura utilizzando Infrastructure as Code

Infrastructure as Code è l'uso di un modello descrittivo per gestire l'infrastruttura, ad esempio VM, e configurazioni, ad esempio le regole firewall. Infrastructure as Code ti consente di:

• Crea automaticamente le tue risorse cloud, compresi gli ambienti di deployment o test per la pipeline CI/CD.
• Gestisci le modifiche all'infrastruttura come quelle alle applicazioni. Ad esempio, assicurati che le modifiche alla configurazione vengano esaminate, testate e possano essere controllate.
• Avere un'unica versione della verità per la tua infrastruttura cloud.
• Replica il tuo ambiente cloud in base alle esigenze.
• Se necessario, esegui il rollback a una configurazione precedente.

Questo concetto di Infrastructure as Code si applica anche ai progetti in Google Cloud. Puoi utilizzare questo approccio per definire risorse come la connettività VPC condiviso o l'accesso Identity and Access Management (IAM) nei tuoi progetti. Per un esempio di questo approccio, consulta il modulo Terraform per la fabbrica di progetti Google Cloud.

Gli strumenti di terze parti, come Terraform, ti consentono di creare automaticamente la tua infrastruttura su Google Cloud. Per saperne di più, consulta Gestire l'infrastruttura come codice con Terraform, Cloud Build e GitOps.

Prendi in considerazione l'utilizzo delle funzionalità di Google Cloud, come i blocchi dei progetti, i criteri di conservazione di Cloud Storage e i blocchi dei bucket di Cloud Storage, per proteggere le risorse critiche dall'eliminazione accidentale o dolosa.

Incorpora test durante tutto il ciclo di vita della distribuzione del software

I test sono fondamentali per avviare correttamente il software. I test continui aiutano i team a creare più velocemente software di alta qualità e a migliorarne la stabilità.

Tipi di test:

• Test delle unità. I test delle unità sono veloci e consentono di eseguire deployment in tempi rapidi. Tratta i test delle unità come parte del codebase e includili come parte del processo di compilazione.
• Test di integrazione. I test di integrazione sono importanti, soprattutto per i carichi di lavoro progettati per la scalabilità e che dipendono da più di un servizio. Questi test possono diventare complessi quando esegui il test dell'integrazione con i servizi interconnessi.
• Test del sistema. I test di sistema sono complessi e dispendiosi in termini di tempo, ma aiutano a identificare i casi limite e a risolvere i problemi prima del deployment.
• Altri test. Devi eseguire altri test, tra cui test statici, test di carico, test di sicurezza, test di convalida dei criteri e altri. Esegui questi test prima di eseguire il deployment dell'applicazione in produzione.

Per incorporare i test:

• Esegui tutti i tipi di test continuamente per tutto il ciclo di vita di distribuzione del software.
• Automatizza questi test e includili nella pipeline CI/CD. Fai in modo che la pipeline abbia esito negativo se uno o più test hanno esito negativo.
• Aggiorna e aggiungi continuamente nuovi test per migliorare e mantenere l'integrità operativa del deployment.

Per i tuoi ambienti di test:

• Utilizza progetti Google Cloud separati per ogni ambiente di test di cui disponi. Per ogni applicazione, utilizza un ambiente di progetto distinto. Questa separazione fornisce una chiara demarcazione tra le risorse dell'ambiente di produzione e le risorse degli ambienti inferiori. Questa separazione garantisce che le modifiche in un ambiente non influiscano accidentalmente su altri ambienti.
• Automatizza la creazione di ambienti di test. Un modo per farlo è utilizzare Infrastructure as Code.
• Utilizza un ambiente di produzione sintetico per testare le modifiche. Questo ambiente offre un ambiente simile alla produzione per testare l'applicazione ed eseguire vari tipi di test sui carichi di lavoro, tra cui test end-to-end e test delle prestazioni.

Per saperne di più sull'implementazione dei test continui, consulta Testare l'automazione.

Avvia gradualmente i deployment

Scegli la strategia di deployment in base a parametri importanti, come interruzione minima per gli utenti finali, aggiornamenti in sequenza, strategie di rollback e strategie di test A/B. Per ogni carico di lavoro, valuta questi requisiti e scegli una strategia di deployment tra tecniche collaudate come aggiornamenti in sequenza, deployment blu/verde e deployment canary.

Consenti ai processi CI/CD di apportare modifiche ed eseguirne il push nel tuo ambiente di produzione.

Prendi in considerazione l'utilizzo di un'infrastruttura immutabile. Un'infrastruttura immutabile è un'infrastruttura che non viene modificata o aggiornata. Quando devi eseguire il deployment di un nuovo codice o modificare qualsiasi altra configurazione nel tuo ambiente, devi sostituire l'intero ambiente (ad esempio una raccolta di VM o pod) con il nuovo ambiente. I deployment blu/verde sono un esempio di infrastruttura immutabile.

Ti consigliamo di eseguire i test canary e osservare il sistema per rilevare eventuali errori durante il deployment delle modifiche. Questo tipo di osservazione è più semplice se disponi di un solido sistema di monitoraggio e avviso. Per eseguire i test A/B o canary, puoi utilizzare i gruppi di istanze gestite di Google Cloud. Poi potrai eseguire un'implementazione lenta o un ripristino, se necessario.

Valuta la possibilità di utilizzare Cloud Deploy per automatizzare i deployment e gestire la pipeline di deployment. Inoltre, puoi utilizzare molti strumenti di terze parti, come Spinnaker e Tekton, su Google Cloud, sia per i deployment automatici sia per la creazione di pipeline di deployment.

Ripristina facilmente le release precedenti

Definire la strategia di ripristino come parte della strategia di deployment. Assicurati di poter eseguire il rollback di un deployment o di una configurazione dell'infrastruttura a una versione precedente del codice sorgente. Il ripristino di un deployment stabile precedente è un passaggio importante nella gestione degli incidenti sia per l'affidabilità che per gli incidenti di sicurezza.

Assicurati inoltre di poter ripristinare l'ambiente allo stato in cui si trovava prima dell'avvio del processo di deployment. Questi possono includere:

• Possibilità di annullare qualsiasi modifica al codice nell'applicazione.
• Possibilità di ripristinare qualsiasi modifica alla configurazione apportata all'ambiente.
• Utilizzando un'infrastruttura immutabile e garantendo che i deployment non modifichino l'ambiente. Queste pratiche semplificano il ripristino delle modifiche alla configurazione.

Monitora le pipeline CI/CD

Per garantire un'esecuzione ottimale dei processi automatizzati di creazione, test e deployment, monitora le pipeline CI/CD. Imposta avvisi che indicano quando un elemento non funziona in una pipeline. Ogni passaggio della pipeline deve scrivere istruzioni di log appropriate in modo che il team possa eseguire l'analisi delle cause principali in caso di errore della pipeline.

In Google Cloud, tutti i servizi CI/CD sono integrati con l'osservabilità di Google Cloud. Ad esempio:

• Cloud Source Repositories è integrato con il servizio Pub/Sub.
• Cloud Build è integrato con Pub/Sub e archivia anche gli audit log e i log di build. Puoi impostare avvisi per determinate parole chiave nei log di build e per molte altre metriche utilizzando il servizio Cloud Monitoring.
• Cloud Deploy archivia gli audit log.

Per maggiori dettagli su monitoraggio e logging, consulta Configurare il monitoraggio, gli avvisi e il logging.

Esegui il deployment delle applicazioni in sicurezza

Consulta la sezione Esegui il deployment delle applicazioni in modo sicuro della categoria Sicurezza, conformità e privacy del Framework dell'architettura.

Stabilire linee guida per la gestione delle release delle versioni

Per aiutare i tecnici a evitare di commettere errori e consentire la distribuzione del software ad alta velocità, assicurati che le linee guida di gestione per il rilascio di nuove versioni del software siano documentate in modo chiaro.

I tecnici del rilascio controllano il modo in cui il software viene creato e distribuito. Il sistema di release engineering è guidato da quattro pratiche:

• Modalità self-service. Stabilisci delle linee guida per aiutare gli ingegneri software a evitare errori comuni. Queste linee guida sono generalmente codificate in processi automatizzati.

• Release frequenti. L'alta velocità aiuta a risolvere i problemi e a risolverli più facilmente. Le release frequenti si basano su test automatici delle unità.

• Creazioni ermetiche. Garantisci la coerenza con i tuoi strumenti di creazione. Versione dei compilatori di build che utilizzi per creare le versioni adesso rispetto a un mese fa.

• Applicazione delle norme. Tutte le modifiche richiedono una revisione del codice, preferibilmente con una serie di linee guida e criteri. L'applicazione dei criteri migliora la revisione del codice, la risoluzione dei problemi e il test di una nuova release.

Passaggi successivi

• Configura monitoraggio, avvisi e logging (documento successivo di questa serie)
• Esegui il deployment delle applicazioni in modo sicuro dalla categoria Sicurezza, conformità e Privacy del Framework dell'architettura
• Consulta le best practice per la creazione dei container
• Scopri di più sulle funzionalità tecniche
• Esplora altre categorie nel framework dell'architettura, come progettazione del sistema, sicurezza, privacy e conformità, affidabilità, ottimizzazione dei costi e ottimizzazione delle prestazioni.

Configurazione di monitoraggio, avvisi e logging

Questo documento nel framework dell'architettura Google Cloud mostra come configurare il monitoraggio, gli avvisi e il logging in modo da poter agire in base al comportamento del sistema. Ciò include l'identificazione di metriche significative da monitorare e la creazione di dashboard per semplificare la visualizzazione delle informazioni sui sistemi.

Il programma di ricerca DevOps Resource and Assessment (DORA) definisce il monitoraggio come:

"Processo di raccolta, analisi e utilizzo delle informazioni per monitorare applicazioni e infrastrutture al fine di guidare le decisioni aziendali. Il monitoraggio è una funzionalità fondamentale perché ti offre insight sui tuoi sistemi e sul tuo lavoro."

Il monitoraggio consente ai proprietari dei servizi di:

• Prendere decisioni informate quando le modifiche al servizio influiscono sulle prestazioni
• Applicare un approccio scientifico alla risposta agli eventi
• Misura l'allineamento del servizio agli obiettivi commerciali

Con il monitoraggio, il logging e gli avvisi attivi, puoi:

• Analizzare le tendenze a lungo termine
• Confronta gli esperimenti nel tempo
• Definisci avvisi sulle metriche critiche
• Crea dashboard pertinenti in tempo reale
• Eseguire un'analisi retrospettiva
• Monitora sia le metriche basate sull'attività che le metriche di integrità del sistema
  • Le metriche basate su business ti aiutano a capire in che misura i tuoi sistemi supportano la tua attività. Ad esempio, utilizza le metriche per monitorare quanto segue:
    • Il costo di un'applicazione per servire un utente
    • La variazione del volume del traffico sul sito in seguito a una riprogettazione
    • Il tempo impiegato dal cliente per acquistare un prodotto sul tuo sito
  • Le metriche di integrità del sistema consentono di capire se i sistemi funzionano correttamente e con livelli di prestazioni accettabili.

Utilizza i seguenti quattro segnali aurei per monitorare il tuo sistema:

• Latenza. Il tempo necessario per gestire una richiesta.
• Traffico. A quanta domanda deve far fronte il tuo sistema.
• Errori. Quantità delle richieste che non vanno a buon fine. L'errore può essere esplicito (ad esempio, HTTP 500), implicito (ad esempio, una risposta riuscita HTTP 200 abbinata ai contenuti sbagliati) o per criterio (ad esempio, se ti impegni a rispettare tempi di risposta di un secondo, qualsiasi richiesta superiore a un secondo è un errore).
• Saturazione. Livello di completezza del tuo servizio. La saturazione è una misura della frazione del sistema, enfatizzando le risorse con più vincoli (ovvero, in un sistema con memoria limitata, mostra la memoria; in un sistema con vincoli di I/O, mostra I/O).

Crea un piano di monitoraggio

Crea un piano di monitoraggio in linea con la missione della tua organizzazione e la sua strategia operativa. Includi la pianificazione del monitoraggio e dell'osservabilità durante lo sviluppo delle applicazioni. Includere un piano di monitoraggio nelle prime fasi dello sviluppo delle applicazioni può portare un'organizzazione verso l'eccellenza operativa.

Includi i seguenti dettagli nel piano di monitoraggio:

• Includi tutti i tuoi sistemi, comprese le risorse on-premise e le risorse cloud.
• Includi il monitoraggio dei costi del cloud per assicurarti che la scalabilità degli eventi non causi il superamento delle soglie di budget.
• Crea diverse strategie di monitoraggio per misurare le prestazioni dell'infrastruttura, l'esperienza utente e gli indicatori chiave di prestazione (KPI) aziendali. Ad esempio, le soglie statiche potrebbero essere efficaci per misurare le prestazioni dell'infrastruttura, ma non rispecchiare realmente l'esperienza dell'utente.

Aggiorna il piano man mano che le tue strategie di monitoraggio maturano. Ripeti il piano per migliorare l'integrità dei tuoi sistemi.

Definisci metriche che misurano tutti gli aspetti della tua organizzazione

Definisci le metriche necessarie per misurare il comportamento del deployment. Ecco come fare:

• Definisci i tuoi scopi commerciali.
• Identifica le metriche e i KPI che possono fornirti informazioni quantificabili per misurare le prestazioni. Assicurati che le definizioni delle metriche si trasformino in tutti gli aspetti della tua organizzazione, dalle esigenze aziendali, compresi i costi del cloud, ai componenti tecnici.
• Utilizza queste metriche per creare indicatori del livello del servizio (SLI) per le tue applicazioni. Per maggiori informazioni, consulta Scegliere gli SLI appropriati.

Metriche comuni per vari componenti

Le metriche vengono generate a tutti i livelli di servizio, dall'infrastruttura al networking alla logica di business. Ad esempio:

• Metriche dell'infrastruttura:
  • Statistiche delle macchine virtuali, tra cui istanze, CPU, memoria, utilizzo e conteggi
  • Statistiche basate su container, tra cui utilizzo del cluster, capacità del cluster, utilizzo a livello di pod
  • Statistiche di networking, tra cui traffico in entrata/in uscita, larghezza di banda tra componenti, latenza e velocità effettiva
  • Richieste al secondo, misurate dal bilanciatore del carico
  • Blocchi totali del disco letti, per disco
  • Pacchetti inviati su una determinata interfaccia di rete
  • Dimensioni dello heap di memoria per un determinato processo
  • Distribuzione delle latenze di risposta
  • Numero di query non valide rifiutate da un'istanza di database
• Metriche dell'applicazione:
  • Comportamento specifico dell'applicazione, incluse query al secondo, scritture al secondo e messaggi inviati al secondo
• Metriche delle statistiche sui servizi gestiti:
  • QPS, velocità effettiva, latenza, utilizzo per i servizi gestiti da Google (API o prodotti come BigQuery, App Engine e Bigtable)
• Metriche delle statistiche relative alla connettività di rete:
  • Statistiche relative a VPN/interconnessione sulla connessione a sistemi on-premise o esterni a Google Cloud.
• SLI
  • Metriche associate all'integrità complessiva del sistema.

Configura il monitoraggio

Configura il monitoraggio per monitorare sia le risorse on-premise che le risorse cloud.

Scegli una soluzione di monitoraggio che:

• È indipendente dalla piattaforma
• Offre funzionalità uniformi per il monitoraggio di ambienti on-premise, ibridi e multi-cloud,

L'utilizzo di un'unica piattaforma per consolidare i dati di monitoraggio provenienti da diverse origini consente di creare metriche e dashboard di visualizzazione uniformi.

Quando configuri il monitoraggio, automatizza le attività di monitoraggio, se possibile.

Monitoraggio con Google Cloud

Utilizzare un servizio di monitoraggio, come Cloud Monitoring, è più semplice che creare autonomamente un servizio di monitoraggio. Il monitoraggio di un'applicazione complessa è di per sé un lavoro ingegneristico importante. Nonostante l'infrastruttura esistente per la strumentazione, la raccolta, la visualizzazione e gli avvisi, è un lavoro a tempo pieno che deve essere creato e gestito da qualcuno.

Prendi in considerazione l'utilizzo di Cloud Monitoring per ottenere visibilità su prestazioni, disponibilità e integrità delle tue applicazioni e della tua infrastruttura sia per le risorse on-premise che per quelle cloud.

Cloud Monitoring è un servizio gestito che fa parte dell'osservabilità di Google Cloud. Puoi usare Cloud Monitoring per monitorare i servizi e le metriche personalizzate di Google Cloud. Cloud Monitoring fornisce un'API per l'integrazione con strumenti di monitoraggio di terze parti.

Cloud Monitoring aggrega metriche, log ed eventi dall'infrastruttura basata su cloud del sistema. Questi dati offrono a sviluppatori e operatori un ricco set di indicatori osservabili che possono velocizzare l'analisi delle cause principali e ridurre il tempo medio di risoluzione. Puoi utilizzare Cloud Monitoring per definire avvisi e metriche personalizzate che soddisfino i tuoi scopi commerciali e ti aiutino ad aggregare, visualizzare e monitorare l'integrità del sistema.

Cloud Monitoring offre dashboard predefinite per servizi per applicazioni cloud e open source. Utilizzando il modello delle metriche, puoi definire dashboard personalizzate con potenti strumenti di visualizzazione e configurare grafici in Metrics Explorer.

Configura avvisi

Un buon sistema di avviso migliora la tua capacità di rilasciare funzionalità. Consente di confrontare le prestazioni nel tempo per determinare la velocità delle release delle funzionalità o la necessità di eseguire il rollback di una release di funzionalità. Per informazioni sui rollback, vedi Ripristinare le release precedenti senza problemi.

Quando imposti gli avvisi, mappali direttamente alle metriche critiche. Queste metriche critiche includono:

• I quattro segnali aurei:
  • Latenza
  • Traffico
  • Errori
  • Saturazione
• Integrità del sistema
• Utilizzo del servizio
• Eventi di sicurezza
• Esperienza utente

Rendi utilizzabili gli avvisi per ridurre al minimo i tempi di risoluzione. A questo scopo, per ogni avviso:

• Includi una descrizione chiara, ad esempio indicando cosa viene monitorato e il suo impatto sull'attività.
• Fornisci tutte le informazioni necessarie per intervenire immediatamente. Se per comprendere gli avvisi sono necessari pochi clic e una navigazione agevole, il personale di pronto intervento risulta difficile.
• Definire i livelli di priorità per i vari avvisi.
• Identifica in modo chiaro la persona o il team responsabile di rispondere all'avviso.

Per le applicazioni e i servizi critici, integra azioni di riparazione automatica negli avvisi attivati a causa di condizioni di errore comuni, come errore di integrità dei servizi, modifica della configurazione o picchi di velocità effettiva.

Mentre imposti gli avvisi, cerca di eliminare il lavoro manuale. Ad esempio, puoi eliminare il lavoro manuale eliminando errori frequenti o automatizzando le correzioni di questi errori, in modo da evitare che venga attivato un avviso. L'eliminazione del lavoro manuale consente a chi è disponibile di concentrarsi sull'affidabilità dei componenti operativi dell'applicazione. Per scoprire di più, consulta Creare una cultura dell'automazione.

Crea dashboard di monitoraggio e avvisi

Una volta attivato il monitoraggio, crea dashboard pertinenti e non complicate che includano informazioni dei tuoi sistemi di monitoraggio e avviso.

Scegliere un modo appropriato per visualizzare la dashboard può essere difficile da collegare ai tuoi obiettivi di affidabilità. Crea dashboard per visualizzare entrambe:

• Analisi a breve termine e in tempo reale
• Analisi a lungo termine

Per ulteriori informazioni sull'implementazione della gestione visiva, consulta l'articolo sulle funzionalità Gestione visiva.

Abilita il logging per le applicazioni critiche

I servizi di logging sono fondamentali per il monitoraggio dei sistemi. Mentre le metriche costituiscono la base degli elementi specifici da monitorare, i log contengono informazioni preziose necessarie per il debug, l'analisi relativa alla sicurezza e i requisiti di conformità.

La registrazione dei dati generati dai sistemi aiuta a garantire un'efficace strategia di sicurezza. Per ulteriori informazioni su logging e sicurezza, consulta Implementare il logging e i controlli di rilevamento nella categoria di sicurezza del framework dell'architettura.

Cloud Logging è un servizio di logging integrato che puoi utilizzare per archiviare, cercare, analizzare, monitorare e creare avvisi su dati di log ed eventi. Logging raccoglie automaticamente i log dai servizi di Google Cloud e di altri cloud provider. Puoi utilizzare questi log per creare metriche per il monitoraggio e per creare esportazioni di logging verso servizi esterni come Cloud Storage, BigQuery e Pub/Sub.

Configurare un audit trail

Per rispondere a domande come "chi ha fatto cosa, dove e quando" nei tuoi progetti Google Cloud, utilizza Cloud Audit Logs.

Cloud Audit Logs acquisisce diversi tipi di attività, tra cui:

• I log delle attività di amministrazione contengono voci di log per le chiamate API o altre azioni amministrative che modificano la configurazione o i metadati delle risorse. I log delle attività di amministrazione sono sempre abilitati.
• Gli audit log di accesso ai dati registrano le chiamate API che creano, modificano o leggono i dati forniti dall'utente. Gli audit log di accesso ai dati sono disabilitati per impostazione predefinita in quanto possono essere molto grandi. Puoi configurare quali servizi Google Cloud producono log di accesso ai dati.

Per un elenco dei servizi Google Cloud che scrivono audit log, consulta Servizi Google con audit log. Utilizza i controlli di Identity and Access Management (IAM) per limitare gli utenti che possono visualizzare gli audit log.

Passaggi successivi

• Stabilire i processi di escalation e di assistenza cloud (documento successivo di questa serie).
• Esplora l'osservabilità di Google Cloud.
• Esegui il deployment di Cloud Monitoring per ottenere visibilità su prestazioni, disponibilità e integrità delle tue applicazioni e della tua infrastruttura.
• Scopri di più su monitoraggio e osservabilità.
• Esplora altre categorie nel framework dell'architettura, come progettazione del sistema, sicurezza, privacy e conformità, affidabilità, ottimizzazione dei costi e ottimizzazione delle prestazioni.

Definizione dei processi di escalation e assistenza Cloud

Questo documento nel framework dell'architettura Google Cloud mostra come definire un processo di escalation efficace. Stabilire l'assistenza del tuo cloud provider o di altri provider di servizi di terze parti è una parte fondamentale di una gestione efficace dell'escalation.

Google Cloud ti offre vari canali di assistenza, tra cui l'assistenza in tempo reale o tramite indicazioni pubblicate come le community di sviluppatori o la documentazione del prodotto. Un'offerta dell'assistenza clienti Google Cloud ti garantisce di poter lavorare con Google Cloud per eseguire i tuoi carichi di lavoro in modo efficiente.

Stabilisci l'assistenza dai tuoi provider

Acquista un contratto di assistenza dal tuo cloud provider o da altri fornitori di servizi di terze parti. L'assistenza è fondamentale per rispondere prontamente e risolvere vari problemi operativi.

Per lavorare con l'assistenza clienti Google Cloud, puoi acquistare un'offerta di assistenza clienti che includa l'Assistenza Standard, Avanzata o Premium. Valuta la possibilità di utilizzare l'Assistenza Avanzata o Premium per i tuoi principali ambienti di produzione.

Definisci il tuo processo di escalation

Un processo di escalation ben definito è fondamentale per ridurre l'impegno e il tempo necessari per identificare e risolvere eventuali problemi nei tuoi sistemi. Sono inclusi i problemi che richiedono assistenza per i prodotti Google Cloud o per altri cloud producer o servizi di terze parti.

Per creare il percorso di riassegnazione:

• Definisci quando e come riassegnare i problemi internamente.
• Definisci quando e come creare richieste di assistenza con il tuo cloud provider o un altro fornitore di servizi di terze parti.
• Scopri come collaborare con i team che ti forniscono assistenza. Per Google Cloud, tu e i tuoi team operativi dovete consultare le best practice per la collaborazione con l'assistenza clienti. Incorpora queste pratiche nel tuo percorso di riassegnazione.
• Trova o crea documenti che descrivono la tua architettura. Assicurati che questi documenti includano informazioni utili per i tecnici dell'assistenza.
• Definisci il modo in cui i tuoi team comunicano durante un'interruzione.
• Assicurati che le persone che hanno bisogno di supporto dispongano di livelli appropriati di autorizzazioni per l'assistenza per accedere a Google Cloud Support Center o per comunicare con altri fornitori di assistenza. Per ulteriori informazioni sull'utilizzo di Google Cloud Support Center, consulta Procedure di assistenza.
• Configura monitoraggio, avvisi e logging in modo da avere le informazioni necessarie per intervenire in caso di problemi.
• Crea modelli per la segnalazione degli incidenti. Per informazioni da includere nei report sugli incidenti, consulta Best practice per l'utilizzo dell'assistenza clienti.
• Documenta il processo di riassegnazione della tua organizzazione. Assicurati di adottare azioni chiare e ben definite per risolvere le riassegnazioni.
• Includi un piano per insegnare ai nuovi membri del team come interagire con l'assistenza.

Testa regolarmente il processo di riassegnazione internamente. Testa il processo di escalation prima di eventi importanti, come migrazioni, lanci di nuovi prodotti ed eventi di picco di traffico. Se utilizzi l'Assistenza clienti Premium di Google Cloud, il tuo tecnico account manager può aiutarti a esaminare il processo di riassegnazione e a coordinare i tuoi test con l'assistenza clienti Google Cloud.

Assicurati di ricevere comunicazioni dall'assistenza

Assicurarsi che gli amministratori ricevano comunicazioni dai provider cloud e dai servizi di terze parti. Queste informazioni consentono agli amministratori di prendere decisioni informate e risolvere i problemi prima che causino problemi più grandi. Assicurati che siano vere le seguenti condizioni:

• Gli amministratori di sicurezza, rete e sistema sono configurati per ricevere email critiche da Google Cloud e dagli altri tuoi provider o servizi.
• Gli amministratori di sicurezza, rete e sistema possono ricevere avvisi di sistema generati da strumenti di monitoraggio come Cloud Monitoring.
• I proprietari del progetto dispongono di nomi utente instradabili tramite email per poter ricevere le email più importanti.

Per informazioni sulla gestione delle notifiche da Google Cloud, consulta Gestione dei contatti per le notifiche.

Stabilire processi di revisione

Stabilisci una revisione o processi post mortem. Segui queste procedure dopo aver sollevato un nuovo ticket di assistenza o dopo aver riassegnato un ticket di assistenza esistente. Come parte del post mortem, documenta le lezioni apprese e monitora le misure correttive. Man mano che esegui la revisione, promuovi una cultura post mortem senza colpa.

Per ulteriori informazioni sui post mortem, consulta Cultura post mortem: apprendimento dagli errori.

Costruisci centri di eccellenza

Può essere utile acquisire informazioni, esperienza e modelli della tua organizzazione in una knowledge base interna come un wiki, un sito Google o un sito intranet. Poiché in Google Cloud vengono continuamente implementati nuovi prodotti e funzionalità, queste conoscenze possono aiutarti a capire perché hai scelto una particolare progettazione per le tue applicazioni e i tuoi servizi. Per maggiori informazioni, consulta Dati decisionali dell'architettura.

È inoltre buona norma nominare esperti e campioni di Google Cloud nella tua organizzazione. Sono disponibili una serie di opzioni di formazione e certificazione per aiutare i campioni candidati a crescere nella loro area di competenza. I team possono rimanere al passo con le ultime notizie, gli annunci e le storie dei clienti iscrivendosi al blog di Google Cloud.

Passaggi successivi

• Gestisci capacità e quota (documento successivo di questa serie)
• Esplora altre categorie nel framework dell'architettura, come progettazione del sistema, sicurezza, privacy e conformità, affidabilità, ottimizzazione dei costi e ottimizzazione delle prestazioni.

Gestione di capacità e quota

Questo documento nel framework dell'architettura Google Cloud mostra come valutare e pianificare la capacità e la quota sul cloud.

Nei data center convenzionali, di solito cicli di spesa ogni trimestre per rivedere i requisiti attuali delle risorse e prevedere quelli futuri. È necessario considerare aspetti fisici, logistici e relativi alle risorse umane. Preoccupazioni come spazio rack, raffreddamento, elettricità, larghezza di banda, cavi, tempi di approvvigionamento, tempi di spedizione e numero di ingegneri disponibili per montare e impilare nuove apparecchiature devono essere prese in considerazione. Inoltre, devi gestire attivamente le distribuzioni della capacità e dei carichi di lavoro in modo che i job che richiedono molte risorse, come le pipeline Hadoop, non interferiscano con servizi come i server web, che devono essere ad alta disponibilità.

Al contrario, quando utilizzi Google Cloud, cedi la maggior parte della pianificazione delle capacità a Google. Utilizzando il cloud, non devi eseguire il provisioning e la manutenzione delle risorse inattive quando non sono necessarie. Ad esempio, puoi creare e fare lo scale up e fare lo scale down delle istanze VM in base alle tue esigenze. Poiché paghi per ciò che utilizzi, puoi ottimizzare la tua spesa, inclusa la capacità in eccesso che ti serve solo nei momenti di picco del traffico. Per aiutarti a risparmiare, Compute Engine fornisce suggerimenti sul tipo di macchina se rileva che hai istanze VM sottoutilizzate che possono essere ridimensionate o eliminate.

Valuta i tuoi requisiti di capacità del cloud

Per gestire la tua capacità in modo efficace, devi conoscere i requisiti di capacità della tua organizzazione.

Per valutare i requisiti di capacità, inizia identificando i tuoi carichi di lavoro cloud principali. Valuta gli utilizzi medi e di picco di questi carichi di lavoro e le loro esigenze attuali e future in termini di capacità.

Identifica i team che utilizzano questi carichi di lavoro principali. Collabora con loro per definire un processo di pianificazione della domanda interno. Utilizza questo processo per comprendere le esigenze attuali e previste in materia di risorse cloud.

Analizza il pattern di carico e la distribuzione delle chiamate. Utilizza fattori come il picco orario, il picco orario e il picco al minuto degli ultimi 30 giorni.

Valuta la possibilità di utilizzare Cloud Monitoring per ottenere visibilità su prestazioni, uptime e integrità complessiva delle tue applicazioni e della tua infrastruttura.

Visualizza le metriche di utilizzo dell'infrastruttura

Per semplificare la pianificazione della capacità, raccogli e archivia i dati storici sull'utilizzo delle risorse cloud da parte della tua organizzazione.

Assicurati di avere visibilità sulle metriche di utilizzo dell'infrastruttura. Ad esempio, per i carichi di lavoro principali, valuta quanto segue:

• Utilizzo medio e picco
• Picchi nei pattern di utilizzo
• Picchi stagionali in base ai requisiti aziendali, ad esempio periodi di festività per i retailer
• Quanto è necessario l'over-provisioning per prepararsi agli eventi di picco e gestire rapidamente i potenziali picchi di traffico

Assicurati che la tua organizzazione abbia configurato degli avvisi che inviino una notifica automatica quando ti avvicini ai limiti di quota e capacità.

Utilizza gli strumenti di monitoraggio di Google per ottenere informazioni sull'utilizzo e sulla capacità delle applicazioni. Ad esempio, puoi definire metriche personalizzate con Monitoring. Usate queste metriche personalizzate per definire le tendenze di avviso. Monitoring offre anche dashboard flessibili e strumenti di visualizzazione avanzati per identificare i problemi.

Crea un processo per la pianificazione della capacità

Definisci un processo per la pianificazione della capacità e documenta questo piano.

Quando crei questo piano:

1. Esegui test di carico per determinare il carico che il sistema è in grado di gestire mentre raggiunge gli obiettivi di latenza, data una quantità fissa di risorse. I test di carico devono utilizzare un mix di tipi di richieste corrispondenti ai profili di traffico di produzione degli utenti dal vivo. Non utilizzare una combinazione uniforme o casuale di operazioni. Includi picchi di utilizzo nel tuo profilo di traffico.
2. Crea un modello di capacità. Un modello di capacità è un insieme di formule per calcolare le risorse incrementali necessarie per l'aumento delle unità del carico del servizio, come determinato dai test di carico.
3. Prevedere il traffico futuro e tenere conto della crescita. Consulta l'articolo Misurare il carico futuro per un riepilogo di come Google crea le previsioni di traffico.
4. Applica il modello di capacità alla previsione per determinare le esigenze future in termini di risorse.
5. Stima il costo delle risorse di cui la tua organizzazione ha bisogno. Poi, ottieni l'approvazione del budget dalla tua organizzazione finanziaria. Questo passaggio è essenziale perché l'azienda può scegliere tra costi rispetto a compromessi in termini di rischio su una vasta gamma di prodotti. Questi compromessi possono comportare l'acquisizione di capacità inferiore o superiore al fabbisogno previsto per un determinato prodotto in base alle priorità aziendali.
6. Collabora con il tuo cloud provider per ottenere la quantità corretta di risorse al momento giusto con quote e prenotazioni. Coinvolgere i team dell'infrastruttura per la pianificazione della capacità e fare in modo che le operazioni creino piani di capacità con intervalli di confidenza.
7. Ripeti i passaggi precedenti ogni trimestre o due.

Per indicazioni più dettagliate sul processo di pianificazione della capacità e ottimizzare al contempo l'utilizzo delle risorse, consulta Pianificazione della capacità.

Assicurati che le quote corrispondano ai requisiti di capacità

Google Cloud utilizza le quotas per limitare la quantità di una determinata risorsa Google Cloud condivisa che puoi utilizzare. Ogni quota rappresenta una risorsa specifica conteggiabile, come le chiamate API a un determinato servizio, il numero di bilanciatori del carico utilizzati contemporaneamente dal tuo progetto o il numero di progetti che puoi creare. Ad esempio, le quote assicurano che alcuni clienti o progetti non possano monopolizzare i core della CPU in una regione o zona specifica.

Quando esamini la quota, considera questi dettagli:

• Pianifica in anticipo i requisiti di capacità dei tuoi progetti per evitare una limitazione inaspettata del consumo di risorse.
• Configura la tua quota e la tua capacità per gestire gli errori dell'intera regione.
• Usa le quote per limitare il consumo di una determinata risorsa. Ad esempio, puoi impostare una quota massima per l'utilizzo giornaliero delle query sull'API BigQuery per assicurarti che un progetto non spenda troppo su BigQuery.
• Pianifica i picchi di utilizzo e includi questi picchi nella pianificazione delle quote. Sono prevedibili picchi di utilizzo durante la giornata, eventi di picco imprevisti del traffico o eventi di picco noti di traffico e lancio. Per dettagli su come pianificare gli eventi di picco di traffico e di lancio, leggi la sezione successiva in Eccellenza operativa: Pianificare gli eventi di picco di traffico e di lancio.

Se le tue quote attuali non sono sufficienti, puoi gestire la quota utilizzando la console Google Cloud. Se hai bisogno di una capacità elevata, contatta il team di vendita di Google Cloud. Tuttavia, è opportuno tenere presente che molti servizi presentano limiti non correlati al sistema di quote. Consulta Utilizzo delle quote per ulteriori informazioni.

Controlla regolarmente le tue quote. Invia le richieste di quota prima che siano necessarie. Per maggiori dettagli su come vengono valutate le richieste di quota e su come vengono approvate o rifiutate, consulta Utilizzo delle quote.

Esistono diversi modi per visualizzare e gestire la tua quota Google Cloud:

• Utilizzare la console Google Cloud
• Utilizzo di Google Cloud CLI
• Utilizzo dell'API Service Usage
• Utilizzo di Monitoring per visualizzare le metriche relative alle quotazioni
• Per gestire le quote in molti progetti Google Cloud all'interno di un'organizzazione o di una cartella, puoi implementare la soluzione dashboard di monitoraggio delle quote.

Passaggi successivi

• Pianificare gli eventi di traffico di picco e di lancio (documento successivo di questa serie)
• Esplora altre categorie nel framework dell'architettura, come progettazione del sistema, sicurezza, privacy e conformità, affidabilità, ottimizzazione dei costi e ottimizzazione delle prestazioni.

Pianificazione degli eventi di traffico di picco e di lancio

Questo documento nel framework dell'architettura Google Cloud mostra come pianificare i picchi di traffico e gli eventi di lancio per evitare interruzioni della tua attività.

Gli eventi di picco sono eventi aziendali importanti che causano un forte aumento del traffico oltre la base di riferimento standard dell'applicazione. Questi eventi di picco richiedono una scalabilità pianificata.

Ad esempio, le attività di vendita al dettaglio con una presenza online possono avere eventi di picco durante le festività. Il Black Friday, giorno dopo il Ringraziamento negli Stati Uniti, è uno dei giorni più impegnativi dell'anno per lo shopping. Per il settore sanitario negli Stati Uniti, i mesi di ottobre e novembre possono avere eventi di picco a causa dei picchi di traffico online per la registrazione dei benefit.

Gli eventi di lancio sono implementazioni o migrazioni sostanziali di nuove funzionalità in produzione. ad esempio una migrazione da on-premise al cloud o il lancio di un nuovo prodotto o di una nuova funzionalità.

Se stai lanciando un nuovo prodotto, dovresti aspettarti un aumento del carico sui tuoi sistemi durante l'annuncio e potenzialmente anche dopo. Questi eventi possono spesso causare aumenti del carico di 5-20 volte (o superiori) sui sistemi frontend. L'aumento del carico aumenta anche il carico sui sistemi di backend. Spesso questi caricamenti di frontend e backend sono caratterizzati da una rapida scalabilità in un breve periodo di tempo all'apertura dell'evento per il traffico web. Gli eventi di lancio comportano una riduzione finale del traffico a livelli normali. Questa diminuzione è solitamente più lenta rispetto alla scala al picco.

Gli eventi di picco e di lancio comprendono tre fasi:

• Pianificazione e preparazione del lancio o dell'evento di picco di traffico
• Lancio dell'evento
• Esaminare il rendimento degli eventi e l'analisi post evento

Le pratiche descritte in questo documento possono aiutare ciascuna di queste fasi a funzionare correttamente.

Crea una guida pratica generale per il lancio e gli eventi di picco

Crea una guida pratica generale con una visione a lungo termine degli eventi di picco attuali e futuri. Continua ad aggiungere al documento le lezioni apprese in modo che possa fungere da riferimento per futuri eventi di picco.

Pianifica il lancio e gli eventi di picco

Pianifica per tempo. Creare proiezioni aziendali per i lanci imminenti e per gli eventi di picco previsti (e imprevisti). La preparazione del sistema per i picchi di scalabilità dipende dalla comprensione delle proiezioni aziendali. Più informazioni sulle previsioni precedenti, più precise saranno le nuove previsioni di business. Queste nuove previsioni sono input critici per prevedere la domanda prevista sul tuo sistema.

Anche stabilire una gestione del programma e una pianificazione coordinata, all'interno della tua organizzazione e con fornitori di terze parti, è una chiave del successo. Prepara questi team per tempo, in modo che il team di gestione dei programmi possa impostare tempistiche, budget sicuri e raccogliere risorse per infrastruttura aggiuntiva, assistenza per i test e formazione.

È importante impostare canali di comunicazione chiari. La comunicazione è fondamentale per tutte le fasi di un lancio o di un evento di picco. Discuti dei rischi e delle aree di interesse precoci e dei problemi di massa prima che diventino ostacoli. Crea la documentazione per la pianificazione degli eventi. Condensa le informazioni più importanti sull'evento di picco e distribuiscile. In questo modo le persone possono assorbire le informazioni di pianificazione e risolvere le domande di base. Questo documento consente di aggiornare le nuove persone sulla pianificazione degli eventi di picco.

Documenta il tuo piano per ogni evento. Quando documenti il piano, assicurati di fare quanto segue:

• Identificare eventuali ipotesi, rischi e fattori sconosciuti.
• Esamina gli eventi passati per determinare le informazioni pertinenti per il prossimo lancio o evento di picco. Determinate quali dati sono disponibili e il valore che i dati hanno fornito in passato.
• Descrivi il piano di rollback per gli eventi di lancio e migrazione.
• Esegui una revisione dell'architettura:
  • Documentare le risorse chiave e i componenti dell'architettura.
  • Utilizza il framework dell'architettura per esaminare tutti gli aspetti dell'ambiente per individuare rischi e problemi di scalabilità.
  • Crea un diagramma che mostri come sono collegati i componenti principali dell'architettura. Un esame del diagramma può aiutarti a isolare i problemi e accelerarne la risoluzione.
• Se opportuno, configura il servizio in modo che utilizzi azioni di avviso per il riavvio automatico in caso di errore. Quando utilizzi Compute Engine, valuta la possibilità di utilizzare la scalabilità automatica per gestire i picchi di velocità effettiva.
• Per assicurarti che le risorse Compute Engine siano disponibili quando ne hai bisogno, utilizza Prenotazioni. Le prenotazioni offrono un altissimo livello di garanzia per l'ottenimento di capacità per le risorse di zona di Compute Engine. Puoi utilizzare le prenotazioni per assicurarti che il progetto abbia risorse disponibili.
• Identifica le metriche e gli avvisi da monitorare:
  • Identifica le metriche di sistema e aziendali da monitorare per l'evento. Se non vengono raccolti metriche o indicatori del livello del servizio (SLI), modifica il sistema in modo da raccogliere questi dati.
  • Assicurati di disporre di capacità di monitoraggio e avviso sufficienti e di aver esaminato i modelli di traffico di picco normali e precedenti. Assicurati che gli avvisi siano impostati correttamente. Utilizza gli strumenti di Google Cloud Monitoring per visualizzare l'utilizzo delle applicazioni, la capacità e l'integrità complessiva delle applicazioni e dell'infrastruttura.
  • Assicurati che le metriche di sistema vengano acquisite con i livelli di interesse di monitoraggio e avviso.
• Esamina l'aumento dei requisiti di capacità con il team dedicato all'account Google Cloud e pianifica la gestione della quota richiesta. Per maggiori dettagli, consulta la pagina Assicurati che le quote corrispondano ai requisiti di capacità.
• Assicurati di disporre di livelli di assistenza cloud appropriati, che il tuo team sappia come aprire richieste di assistenza e di avere stabilito un percorso di escalation. Per maggiori dettagli, consulta Stabilire processi di escalation e assistenza cloud.
• Definisci un piano di comunicazione, una tempistica e le responsabilità:
  • Coinvolgere stakeholder interfunzionali per coordinare la comunicazione e la pianificazione del programma. Questi stakeholder possono includere persone appropriate di team tecnici, operativi e direttivi e di fornitori di terze parti.
  • Stabilire una sequenza temporale non ambigua contenente le attività critiche e i team proprietari.
  • Stabilisci una matrice di assegnazione responsabilità (RACI) per comunicare la proprietà per team, responsabili dei team, stakeholder e parti responsabili.
  • Puoi utilizzare il servizio di gestione degli eventi dell'Assistenza Premium per eventi di picco pianificati. Con questo servizio, l'assistenza clienti collabora con il tuo team per creare un piano e fornire indicazioni durante l'evento.

Stabilire processi di revisione

Al termine dell'evento di picco di traffico o di lancio, esamina l'evento per documentare le lezioni apprese. Quindi, aggiorna il playbook con queste lezioni. Infine, applica ciò che hai imparato al prossimo evento importante. Imparare dagli eventi precedenti è importante, soprattutto quando evidenziano i vincoli al sistema quando si è sotto stress.

Le revisioni retrospettive, chiamate anche post mortem, per gli eventi di picco di traffico o gli eventi di avvio sono una tecnica utile per acquisire dati e comprendere gli incidenti che si sono verificati. Esegui questa revisione per gli eventi di traffico di picco e di lancio che si sono verificati come previsto, nonché per eventuali incidenti che hanno causato problemi. Man mano che procedi, promuovi una cultura della colpevolezza.

Per ulteriori informazioni sui post mortem, consulta Cultura post mortem: apprendimento dagli errori.

Passaggi successivi

• Crea una cultura dell'automazione (documento successivo di questa serie)
• Esplora altre categorie nel framework dell'architettura, come progettazione del sistema, sicurezza, privacy e conformità, affidabilità, ottimizzazione dei costi e ottimizzazione delle prestazioni.

Creazione di una cultura dell'automazione

Questo documento nel framework dell'architettura Google Cloud mostra come valutare il lavoro manuale e mitigarne l'impatto sui tuoi sistemi e sui tuoi team.

Il lavoro manuale è un lavoro ripetitivo senza valore duraturo, che aumenta man mano che il servizio cresce. Punta sempre a ridurre o eliminare il lavoro manuale. In caso contrario, il lavoro operativo può sovraccaricare gli operatori e qualsiasi aumento dell'uso o della complessità dei prodotti può richiedere l'assunzione di personale aggiuntivo.

L'Automation è un modo fondamentale per ridurre al minimo il lavoro manuale. L'Automation migliora anche la velocità di rilascio e riduce al minimo gli errori causati dall'uomo.

Per saperne di più, consulta la sezione Eliminare il lavoro manuale.

Crea un inventario e valuta il costo del lavoro manuale

Inizia creando un inventario e valutando il costo del lavoro manuale dei team che gestiscono i tuoi sistemi. Rendi questo processo continuo, seguito da un investimento nell'automazione personalizzata per estendere i servizi già forniti dai partner e dai servizi Google Cloud. Spesso puoi modificare l'automazione di Google Cloud, ad esempio il gestore della scalabilità automatica di Compute Engine.

Dai la priorità all'eliminazione del lavoro manuale

L'Automation è utile, ma non è una soluzione a tutti i problemi operativi. Come primo passo per affrontare il lavoro manuale noto, ti consigliamo di rivedere il tuo inventario del lavoro manuale esistente e di dare la priorità a eliminare il più possibile lavoro manuale. Poi puoi concentrarti sull'automazione.

Automatizza il lavoro manuale necessario

Parte del lavoro manuale nei tuoi sistemi non può essere eliminato. Come secondo passaggio per gestire il lavoro manuale noto, automatizza questo lavoro utilizzando le soluzioni fornite da Google Cloud tramite l'automazione configurabile.

Di seguito sono riportate alcune aree in cui l'automazione configurabile o personalizzata può aiutare la tua organizzazione a eliminare il lavoro manuale:

• Gestione delle identità, ad esempio Cloud Identity and Identity and Access Management.
• Soluzioni ospitate da Google Cloud, anziché soluzioni personalizzate, ad esempio gestione dei cluster (Google Kubernetes Engine (GKE)), gestione di database relazionali (Cloud SQL), gestione del data warehouse (BigQuery) e gestione delle API (Apigee).
• Servizi Google Cloud e provisioning dei tenant, ad esempio Terraform e Cloud Foundation Toolkit.
• Orchestrazione automatica del flusso di lavoro per operazioni in più fasi, ad esempio Cloud Composer.
• Il provisioning della capacità aggiuntivo, ad esempio diversi prodotti Google Cloud, come Compute Engine e GKE, offrono una scalabilità automatica configurabile. Valuta i servizi Google Cloud che stai utilizzando per determinare se includono la scalabilità automatica configurabile.
• Pipeline CI/CD con deployment automatizzato, ad esempio Cloud Build.
• analisi canary per convalidare i deployment.
• Addestramento automatico di modelli (per il machine learning), ad esempio AutoML.

Se un prodotto o servizio Google Cloud soddisfa solo parzialmente le tue esigenze tecniche quando automatizza o elimini i flussi di lavoro manuali, valuta la possibilità di inviare una richiesta di funzionalità tramite il rappresentante del tuo account Google Cloud. Il tuo problema potrebbe essere una priorità per altri clienti o potrebbe già far parte della nostra roadmap. In tal caso, conoscere la priorità e le tempistiche della funzionalità aiuta a valutare meglio i compromessi tra la creazione di una soluzione personalizzata e l'attesa per utilizzare una funzionalità di Google Cloud.

Crea o acquista soluzioni per il lavoro manuale ad alto costo

Il terzo passaggio, che può essere completato in parallelo al primo e al secondo, prevede la valutazione della creazione o dell'acquisto di altre soluzioni se il costo del lavoro manuale rimane elevato, ad esempio se il lavoro manuale richiede molto tempo ai team che gestiscono i sistemi di produzione.

Quando crei o acquisti soluzioni, considera i costi di integrazione, sicurezza, privacy e conformità. La progettazione e l'implementazione di una tua automazione comporta costi di manutenzione e rischi per l'affidabilità al di là dei costi di sviluppo e configurazione iniziali, pertanto considera questa opzione come ultima risorsa.

Passaggi successivi

Esplora altre categorie nel framework dell'architettura, come progettazione del sistema, sicurezza, privacy e conformità, affidabilità, ottimizzazione dei costi e ottimizzazione delle prestazioni.

Framework dell'architettura Google Cloud: sicurezza, privacy e conformità

Questa categoria nel framework dell'architettura Google Cloud mostra come progettare e gestire servizi sicuri su Google Cloud. Scoprirai inoltre i prodotti e le funzionalità di Google Cloud che supportano la sicurezza e la conformità.

Il framework dell'architettura descrive le best practice, fornisce consigli per l'implementazione e spiega alcuni dei prodotti e servizi disponibili. Il framework aiuta a progettare il deployment di Google Cloud in modo che soddisfi le tue esigenze aziendali.

Lo spostamento dei carichi di lavoro in Google Cloud richiede una valutazione dei requisiti aziendali, dei rischi, degli obblighi di conformità e dei controlli di sicurezza. Questo documento ti aiuta a prendere in considerazione le best practice chiave relative alla progettazione di una soluzione sicura in Google Cloud.

I principi fondamentali di Google includono la difesa approfondita, su larga scala e per impostazione predefinita. In Google Cloud, dati e sistemi sono protetti attraverso difese a più livelli mediante criteri e controlli configurati in IAM, crittografia, networking, rilevamento, logging e monitoraggio.

Google Cloud include molti controlli di sicurezza che puoi utilizzare come base, ad esempio:

• Proteggere le opzioni per i dati in transito e la crittografia predefinita per i dati at-rest.
• Funzionalità di sicurezza integrate per i prodotti e i servizi Google Cloud.
• Un'infrastruttura globale progettata per la ridondanza geografica, con controlli di sicurezza durante tutto il ciclo di vita dell'elaborazione delle informazioni.
• funzionalità di Automation che utilizzano sistemi di protezione Infrastructure as Code (IaC) e di configurazione.

Per ulteriori informazioni sulla strategia di sicurezza di Google Cloud, consulta il documento sulla sicurezza di Google e la panoramica sulla progettazione della sicurezza dell'infrastruttura Google. Per un esempio di ambiente sicuro per impostazione predefinita, consulta il progetto di base per le basi aziendali di Google Cloud.

Nella categoria Sicurezza del framework dell'architettura, imparerai a fare quanto segue:

• Esaminare la responsabilità condivisa e il destino condiviso su Google Cloud
• Comprendere i principi di sicurezza
• Gestire i rischi con i controlli
• Gestire gli asset
• Gestisci identità e accesso
• Implementare la sicurezza di computing e container
• Proteggi la tua rete
• Implementare la sicurezza dei dati
• Eseguire il deployment della sicurezza delle applicazioni
• Gestire gli obblighi di conformità
• Implementare i requisiti di residenza e sovranità dei dati
• Implementare i requisiti di privacy
• Implementare il logging e i controlli di rilevamento

Responsabilità condivise e destino condiviso su Google Cloud

Questo documento descrive le differenze tra il modello di responsabilità condivisa e il destino condiviso in Google Cloud. Parla delle sfide e delle sfumature del modello di responsabilità condivisa. Questo documento descrive il destino condiviso e come collaboriamo con i nostri clienti per affrontare le sfide della sicurezza nel cloud.

Comprendere il modello di responsabilità condivisa è importante per determinare come proteggere al meglio dati e carichi di lavoro su Google Cloud. Il modello di responsabilità condivisa descrive le attività che svolgi in relazione alla sicurezza nel cloud e le differenze tra queste attività per i provider di servizi cloud.

Comprendere una responsabilità condivisa, tuttavia, può essere difficile. Il modello richiede una comprensione approfondita di ogni servizio utilizzato, delle opzioni di configurazione fornite da ciascun servizio e di ciò che Google Cloud fa per proteggere il servizio. Ogni servizio ha un profilo di configurazione diverso e può essere difficile determinare la configurazione di sicurezza migliore. Il modello di responsabilità condivisa si ferma prima di aiutare i clienti cloud a ottenere risultati migliori in termini di sicurezza. Anziché una responsabilità condivisa, crediamo nel fato condiviso.

Il destino condiviso include la creazione e la gestione di una piattaforma cloud affidabile per i tuoi carichi di lavoro. Offriamo indicazioni sulle best practice e un codice di infrastruttura sicuro e attestato che puoi utilizzare per eseguire il deployment dei tuoi carichi di lavoro in modo sicuro. Rilasciamo soluzioni che combinano vari servizi Google Cloud per risolvere problemi di sicurezza complessi e offriamo opzioni assicurative innovative per aiutarti a misurare e mitigare i rischi che devi accettare. Il destino condiviso ci comporta un'interazione più stretta con te man mano che proteggi le tue risorse su Google Cloud.

Responsabilità condivisa

Sei esperto nel conoscere i requisiti normativi e di sicurezza per la tua azienda e i requisiti per la protezione di risorse e dati riservati. Quando esegui i tuoi carichi di lavoro su Google Cloud, devi identificare i controlli di sicurezza che devi configurare in Google Cloud per proteggere i tuoi dati riservati e ogni carico di lavoro. Per decidere quali controlli di sicurezza implementare, è necessario considerare i seguenti fattori:

• Obblighi di conformità normativa
• Gli standard di sicurezza e il piano di gestione dei rischi della tua organizzazione
• Requisiti di sicurezza dei clienti e dei fornitori

Definito dai carichi di lavoro

Tradizionalmente, le responsabilità sono definite in base al tipo di carico di lavoro in esecuzione e ai servizi cloud richiesti. I servizi cloud includono le seguenti categorie:

Servizio cloud	Description
Infrastructure as a Service (IaaS)	I servizi IaaS includono Compute Engine, Cloud Storage e servizi di networking come Cloud VPN, Cloud Load Balancing e Cloud DNS. IaaS fornisce servizi di computing, archiviazione e rete on demand con pagamento a consumo. Puoi utilizzare IaaS se prevedi di eseguire la migrazione nel cloud di un carico di lavoro on-premise esistente utilizzando il lift and shift o se vuoi eseguire l'applicazione su determinate VM, utilizzando configurazioni di rete o database specifici. In IaaS, la maggior parte delle responsabilità in materia di sicurezza spetta a te e le nostre responsabilità si concentrano sull'infrastruttura sottostante e sulla sicurezza fisica.
Platform as a service (PaaS)	I servizi PaaS includono App Engine, Google Kubernetes Engine (GKE) e BigQuery. PaaS fornisce l'ambiente di runtime in cui puoi sviluppare ed eseguire le tue applicazioni. Puoi utilizzare PaaS se stai creando un'applicazione (ad esempio un sito web) e vuoi concentrarti sullo sviluppo e non sull'infrastruttura sottostante. In PaaS, siamo responsabili di più controlli rispetto a IaaS, inclusi i controlli di rete. Condividi la responsabilità con noi per i controlli a livello di applicazione e la gestione IAM. Sei responsabile della sicurezza dei dati e della protezione dei clienti.
Software as a Service (SaaS)	Le applicazioni SaaS includono Google Workspace, Chronicle e le applicazioni SaaS di terze parti disponibili in Google Cloud Marketplace. SaaS offre applicazioni online a cui puoi abbonarti o a cui pagare. Puoi utilizzare le applicazioni SaaS quando la tua azienda non dispone delle competenze interne o dei requisiti aziendali per creare le applicazioni da sole, ma richiede la capacità di elaborare i carichi di lavoro. Nel Software come servizio, la maggior parte delle responsabilità in materia di sicurezza è di nostra proprietà. Sei comunque responsabile dei controlli di accesso e dei dati che scegli di archiviare nell'applicazione.
Function as a Service (FaaS) o serverless	FaaS offre agli sviluppatori la piattaforma per eseguire piccoli codici a uso specifico (chiamati funzioni) che vengono eseguiti in risposta a determinati eventi. Puoi usare FaaS quando vuoi che avvengano cose particolari in base a un particolare evento. Ad esempio, puoi creare una funzione da eseguire ogni volta che i dati vengono caricati in Cloud Storage in modo da poter essere classificati. FaaS ha un elenco di responsabilità condivise simile a quello di SaaS. Cloud Functions è un'applicazione FaaS.

Il seguente diagramma mostra i servizi cloud e definisce le modalità di condivisione delle responsabilità tra il provider cloud e il cliente.

Come mostrato nel diagramma, il cloud provider rimane sempre responsabile della rete e dell'infrastruttura sottostanti e i clienti rimangono sempre responsabili dei propri dati e criteri di accesso.

Definito dal settore e dal quadro normativo

Vari settori dispongono di quadri normativi che definiscono i controlli di sicurezza che devono essere messi in atto. Quando sposti i tuoi carichi di lavoro nel cloud, devi conoscere quanto segue:

• Quali controlli di sicurezza sono di tua responsabilità
• Quali controlli di sicurezza sono disponibili nell'ambito dell'offerta cloud
• Quali controlli di sicurezza predefiniti vengono ereditati

I controlli di sicurezza ereditati (come la nostra crittografia predefinita e i controlli dell'infrastruttura) sono che puoi fornire a revisori e regolatori come parte della prova della tua strategia di sicurezza. Ad esempio, lo standard PCI DSS (Payment Card Industry Data Security Standard) definisce le normative per gli elaboratori dei pagamenti. Quando sposti la tua azienda nel cloud, queste normative vengono condivise tra te e il tuo CSP. Per comprendere in che modo le responsabilità PCI DSS vengono condivise tra te e Google Cloud, consulta Google Cloud: Matrice di responsabilità condivisa PCI DSS.

Come ulteriore esempio, negli Stati Uniti la normativa HIPAA (Health Insurance Portability and Accountability Act) ha definito standard per la gestione dei dati PHI elettronici. Queste responsabilità sono inoltre condivise tra l'utente e il CSP. Per ulteriori informazioni su come Google Cloud soddisfa le nostre responsabilità ai sensi dell'HIPAA, consulta la pagina Conformità HIPAA.

Anche altri settori, come quello finanziario o manifatturiero, hanno normative che definiscono le modalità di raccolta, elaborazione e archiviazione dei dati. Per ulteriori informazioni sulla responsabilità condivisa in merito e su come Google Cloud soddisfa le nostre responsabilità, consulta il Centro risorse per la conformità.

Definito in base alla località

A seconda dello scenario aziendale, potresti dover prendere in considerazione le tue responsabilità in base alla posizione degli uffici della tua azienda, ai tuoi clienti e ai tuoi dati. Diversi paesi e regioni hanno creato normative che regolano il modo in cui puoi elaborare e archiviare i dati dei tuoi clienti. Ad esempio, se la tua attività ha clienti che risiedono nell'Unione Europea, potrebbe dover rispettare i requisiti descritti nel Regolamento generale sulla protezione dei dati (GDPR) e potresti avere l'obbligo di conservare i dati dei tuoi clienti nell'UE stessa. In questa circostanza, è tua responsabilità assicurarti che i dati che raccogli rimangano nelle regioni di Google Cloud nell'UE. Per ulteriori informazioni su come adempiere ai nostri obblighi GDPR, consulta la pagina GDPR e Google Cloud.

Per informazioni sui requisiti relativi alla tua regione, consulta Offerte relative alla conformità. Se il tuo scenario è particolarmente complicato, ti consigliamo di rivolgerti al nostro team di vendita o a uno dei nostri partners per valutare le tue responsabilità in materia di sicurezza.

Sfide della responsabilità condivisa

Sebbene la responsabilità condivisa contribuisca a definire i ruoli di sicurezza assegnati a te o al cloud provider, affidarti a una responsabilità condivisa può comunque creare problemi. Considera i seguenti scenari:

• La maggior parte delle violazioni alla sicurezza nel cloud è il risultato diretto di errori di configurazione (indicati come numero 3 nel report Pandemic 11 di Cloud Security Alliance) e questa tendenza è destinata ad aumentare. I prodotti cloud sono in continua evoluzione e ne vengono lanciati costantemente di nuovi. Stare al passo con i continui cambiamenti può sembrare un'impresa ardua. I clienti hanno bisogno che i provider di servizi cloud forniscano best practice utili per stare al passo con il cambiamento, a partire dalle best practice predefinite e da una configurazione di base sicura.
• Sebbene sia utile suddividere gli elementi per servizi cloud, molte aziende hanno carichi di lavoro che richiedono più tipi di servizi cloud. In questa circostanza, devi considerare come interagiscono i vari controlli di sicurezza per questi servizi, inclusa la loro sovrapposizione tra e tra i servizi. Ad esempio, potresti avere un'applicazione on-premise di cui stai eseguendo la migrazione a Compute Engine, utilizzare Google Workspace per l'email aziendale e anche eseguire BigQuery per analizzare i dati e migliorare i tuoi prodotti.
• La tua attività e i tuoi mercati cambiano continuamente; man mano che le normative cambiano, man mano che entri in nuovi mercati o acquisisci altre aziende. I tuoi nuovi mercati potrebbero avere requisiti diversi e la tua nuova acquisizione potrebbe ospitare i relativi carichi di lavoro su un altro cloud. Per gestire i cambiamenti costanti, devi rivalutare costantemente il tuo profilo di rischio ed essere in grado di implementare rapidamente nuovi controlli.
• Come e dove gestire le chiavi di crittografia dei dati è una decisione importante che dipende dalle tue responsabilità in relazione alla protezione dei dati. L'opzione che scegli dipende dai requisiti normativi, dal fatto che tu stia eseguendo un ambiente cloud ibrido o comunque un ambiente on-premise, e dalla sensibilità dei dati elaborati e archiviati.
• La gestione degli incidenti è un'area importante e spesso trascurata in cui le responsabilità e quelle del cloud provider non sono facilmente definite. Molti incidenti richiedono la collaborazione e il supporto stretti del provider cloud per indagare e mitigare. Altri incidenti possono derivare da risorse cloud configurate in modo errato o da credenziali rubate e assicurarsi di rispettare le best practice per la protezione delle risorse e degli account può essere molto difficile.
• Le minacce persistenti avanzate (APT) e le nuove vulnerabilità possono influire sui tuoi carichi di lavoro in modi che non potresti prendere in considerazione all'avvio della trasformazione cloud. È difficile assicurarsi di essere sempre aggiornati sull'evoluzione del panorama e di chi è responsabile della mitigazione delle minacce, in particolare se l'azienda non ha un grande team di sicurezza.

Destino condiviso

Abbiamo stabilito il destino condiviso in Google Cloud per iniziare ad affrontare le sfide che il modello di responsabilità condivisa non affronta. Il destino condiviso si concentra sul modo in cui tutte le parti possono interagire meglio per migliorare continuamente la sicurezza. Il destino condiviso si basa sul modello di responsabilità condivisa perché considera la relazione tra il cloud provider e il cliente come una partnership continua per migliorare la sicurezza.

Il destino condiviso prevede che ci assumiamo la responsabilità di rendere Google Cloud più sicuro. Il destino condiviso include l'aiutarti a iniziare a creare una zona di destinazione sicura ed essere chiaro, improntato e trasparente in merito ai controlli di sicurezza, alle impostazioni e alle best practice associate. tra cui l'aiutarti a quantificare e gestire meglio il rischio con l'assicurazione informatica, attraverso il nostro programma di protezione dai rischi. Utilizzando il destino condiviso, vogliamo evolverci dal framework di responsabilità condivisa standard a un modello migliore che ti aiuti a proteggere la tua attività e creare fiducia in Google Cloud.

Le seguenti sezioni descrivono vari elementi del destino condiviso.

Un aiuto per iniziare

Un componente chiave del destino condiviso sono le risorse che mettiamo a disposizione per aiutarti a iniziare, in una configurazione sicura in Google Cloud. Iniziare da una configurazione sicura aiuta a ridurre il problema degli errori di configurazione, che è la causa principale della maggior parte delle violazioni della sicurezza.

Le nostre risorse includono:

• Progetto di base aziendale che illustra i principali problemi di sicurezza e i nostri principali consigli.

• Progetti sicuri che ti consentono di eseguire il deployment di soluzioni sicure e di gestirle utilizzando Infrastructure as Code (IaC). I suggerimenti di sicurezza sono abilitati per i progetti base per impostazione predefinita. Molti progetti sono creati dai team di sicurezza di Google e gestiti come prodotti. Questo tipo di assistenza implica che vengono aggiornati regolarmente, vengono sottoposti a un rigoroso processo di test e ricevono attestazioni da gruppi di test di terze parti. I progetti includono il progetto di base aziendale, il progetto di data warehouse sicuro e il progetto di blocchi note di Vertex AI Workbench.

• del framework dell'architettura che fornisce i principali consigli per integrare la sicurezza nei tuoi progetti. Il framework dell'architettura include una sezione sulla sicurezza e una zona della community che puoi utilizzare per entrare in contatto con esperti e colleghi.

• Guide alla navigazione nelle zone di destinazione che illustrano le decisioni principali da prendere per creare una base sicura per i carichi di lavoro, tra cui gerarchia delle risorse, onboarding delle identità, gestione di sicurezza e chiavi e struttura di rete.

Programma di protezione dai rischi

Il destino condiviso include anche il Programma di protezione dai rischi (attualmente in anteprima), che consente di utilizzare la potenza di Google Cloud come piattaforma per gestire i rischi, anziché considerare i carichi di lavoro cloud come un'altra fonte di rischio da gestire. Il Risk Protection Program è una collaborazione tra Google Cloud e due principali compagnie assicurative informatiche, Monaco Re e Allianz Global & Corporate Speciality.

Il programma di protezione dai rischi include Risk Manager, che fornisce insight basati sui dati che puoi utilizzare per comprendere meglio la tua strategia di sicurezza cloud. Se stai cercando una copertura assicurativa informatica, puoi condividere questi insight da Risk Manager direttamente con i nostri partner assicurativi per ottenere un preventivo. Per maggiori informazioni, consulta la pagina relativa al programma di protezione dai rischi di Google Cloud ora in anteprima.

Guida per deployment e governance

Il destino condiviso aiuta anche con la continua governance del tuo ambiente. Ad esempio, ci concentriamo su prodotti quali:

• Assured Workloads, che ti aiuta a rispettare gli obblighi di conformità.
• Security Command Center Premium, che utilizza l'intelligence sulle minacce, il rilevamento delle minacce, la scansione web e altri metodi avanzati per monitorare e rilevare le minacce. Offre anche un modo per risolvere molte di queste minacce in modo rapido e automatico.
• Criteri dell'organizzazione e impostazioni delle risorse che consentono di configurare criteri nell'intera gerarchia di cartelle e progetti.
• Strumenti di Policy Intelligence che forniscono insight sull'accesso ad account e risorse.
• Confidential Computing, che consente di criptare i dati in uso.
• Sovereign Cloud, disponibile in Germania e che implementa i requisiti di residenza dei dati.

Mettere in pratica una responsabilità condivisa e un destino condiviso

Nell'ambito del processo di pianificazione, prendi in considerazione le seguenti azioni per comprendere e implementare controlli di sicurezza appropriati:

• Crea un elenco del tipo di carichi di lavoro che ospiti in Google Cloud e se richiedono servizi IaaS, PaaS e SaaS. Puoi utilizzare il diagramma di responsabilità condivisa come elenco di controllo per assicurarti di conoscere i controlli di sicurezza da prendere in considerazione.
• Crea un elenco dei requisiti normativi da rispettare e accedi alle risorse relative a tali requisiti nel Centro risorse per la conformità.
• Esamina l'elenco dei progetti e delle architetture disponibili nel Centro architetture per conoscere i controlli di sicurezza richiesti per i tuoi carichi di lavoro specifici. I progetti forniscono un elenco di controlli consigliati e il codice IaC di cui hai bisogno per eseguire il deployment di quell'architettura.
• Utilizza la documentazione delle zone di destinazione e i suggerimenti della guida agli elementi di base aziendali per progettare una gerarchia delle risorse e un'architettura di rete che soddisfino i tuoi requisiti. Puoi utilizzare i progetti base per i carichi di lavoro, come il data warehouse sicuro, per accelerare il processo di sviluppo.
• Dopo aver eseguito il deployment dei carichi di lavoro, verifica di soddisfare le tue responsabilità di sicurezza utilizzando servizi come Gestore rischi, Assured Workloads, strumenti di Policy Intelligence e Security Command Center Premium.

Per ulteriori informazioni, consulta il documento della guida alla trasformazione cloud del CISO.

Passaggi successivi

• Consulta i principi di sicurezza (prossimo documento di questa serie).
• Ricevi aggiornamenti sulle risorse di destino condivise.
• Acquisisci familiarità con i progetti disponibili, tra cui il progetto delle piattaforme di sicurezza e gli esempi di carichi di lavoro come il data warehouse sicuro.
• Scopri di più sul destino condiviso.
• Per saperne di più sulla nostra infrastruttura sicura sottostante, consulta la panoramica sulla progettazione della sicurezza dell'infrastruttura di Google.
• Leggi come implementare le best practice del NIST Cybersecurity Framework in Google Cloud (PDF).

Principi di sicurezza

Questo documento nel framework dell'architettura Google Cloud spiega i principi fondamentali per l'esecuzione di servizi sicuri e conformi su Google Cloud. Molti dei principi di sicurezza che conosci nel tuo ambiente on-premise si applicano agli ambienti cloud.

Crea un approccio alla sicurezza a più livelli

Implementa la sicurezza a ogni livello nella tua applicazione e nell'infrastruttura applicando un approccio di difesa in profondità. Utilizza le funzionalità di ogni prodotto per limitare l'accesso e configurare la crittografia dove appropriato.

Progettazione di sistemi disaccoppiati protetti

Semplifica la progettazione del sistema per garantire la flessibilità, ove possibile, e i requisiti di sicurezza dei documenti per ogni componente. un solido meccanismo di sicurezza per tenere conto della resilienza e del recupero.

Automatizza il deployment di attività sensibili

Elimina le persone dal flusso di lavoro automatizzando il deployment e altre attività amministrative.

Automatizza il monitoraggio della sicurezza

Utilizza strumenti automatizzati per monitorare l'applicazione e l'infrastruttura. Per analizzare l'infrastruttura per rilevare eventuali vulnerabilità e rilevare incidenti di sicurezza, utilizza la scansione automatica nelle pipeline di integrazione continua e deployment continuo (CI/CD).

Soddisfa i requisiti di conformità per le tue regioni

Tieni presente che potresti dover offuscare o oscurare le informazioni che consentono l'identificazione personale (PII) per soddisfare i requisiti normativi. Ove possibile, automatizza le attività di conformità. Ad esempio, utilizza Sensitive Data Protection e Dataflow per automatizzare il job di oscuramento delle PII prima che i nuovi dati vengano archiviati nel sistema.

Rispetto dei requisiti di localizzazione e sovranità dei dati

Potresti avere requisiti interni (o esterni) che richiedono di controllare le località di archiviazione e trattamento dei dati. Questi requisiti variano in base agli obiettivi di progettazione dei sistemi, alle normative di settore, alla legislazione nazionale, alle implicazioni fiscali e alla cultura. La residenza dei dati indica dove vengono archiviati i dati. Per soddisfare i requisiti di localizzazione dei dati, Google Cloud ti consente di controllare dove vengono archiviati i dati, le modalità di accesso ai dati e il modo in cui vengono elaborati.

Spostamento della sicurezza nelle fasi iniziali del processo di sviluppo

L'automazione DevOps e del deployment consentono all'organizzazione di aumentare la velocità di distribuzione dei prodotti. Per garantire la sicurezza dei tuoi prodotti, incorpora i processi di sicurezza fin dall'inizio del processo di sviluppo. Ad esempio, puoi eseguire queste operazioni:

• Testare la presenza di problemi di sicurezza nel codice nelle prime fasi della pipeline di deployment.
• Esegui costantemente l'analisi delle immagini container e dell'infrastruttura cloud.
• Automatizza il rilevamento di configurazioni errate e di anti-pattern di sicurezza. Ad esempio, utilizza l'automazione per cercare secret hardcoded nelle applicazioni o nella configurazione.

Passaggi successivi

Scopri di più sui principi di sicurezza fondamentali nelle seguenti risorse:

• Gestire i rischi con i controlli (documento successivo di questa serie)
• Progetto delle basi aziendali di Google Cloud
• Documento sulla sicurezza di Google
• Panoramica sulla progettazione della sicurezza dell'infrastruttura Google
• Crea un processo collaborativo di gestione degli incidenti
• Progetti di cui è possibile eseguire il deployment per settori specifici

Gestisci i rischi con i controlli

Questo documento nel framework dell'architettura Google Cloud descrive le best practice per la gestione dei rischi in un deployment cloud. Un'attenta analisi dei rischi applicabili alla tua organizzazione consente di determinare i controlli di sicurezza di cui hai bisogno. Devi completare l'analisi del rischio prima di eseguire il deployment dei carichi di lavoro su Google Cloud e in seguito regolarmente in base alle esigenze aziendali, ai requisiti normativi e alle minacce pertinenti per la tua organizzazione.

Identificare i rischi per la tua azienda

Prima di creare ed eseguire il deployment di risorse su Google Cloud, completa una valutazione dei rischi per determinare le funzionalità di sicurezza di cui hai bisogno per soddisfare i requisiti di sicurezza interni e i requisiti normativi esterni. La valutazione del rischio fornisce un catalogo dei rischi pertinenti per te e ti mostra quanto è in grado la tua organizzazione nel rilevare e contrastare le minacce alla sicurezza.

I rischi in un ambiente cloud sono diversi da quelli in un ambiente on-premise per via dell'accordo di responsabilità condivisa stipulato con il provider cloud. Ad esempio, in un ambiente on-premise devi attenuare le vulnerabilità dello stack hardware. Al contrario, in un ambiente cloud, questi rischi sono a carico del cloud provider.

Inoltre, i rischi variano a seconda di come prevedi di utilizzare Google Cloud. Stai trasferendo alcuni carichi di lavoro in Google Cloud o tutti? Utilizzi Google Cloud solo a scopo di ripristino di emergenza? Stai configurando un ambiente cloud ibrido?

Ti consigliamo di utilizzare un framework di valutazione del rischio standard di settore, valido per gli ambienti cloud e per i requisiti normativi. Ad esempio, Cloud Security Alliance (CSA) fornisce la Cloud Controls Matrix (CCM). Inoltre, esistono modelli di minaccia, come la definizione del modello di minaccia per le applicazioni OWASP, che forniscono un elenco di potenziali lacune e che suggeriscono azioni per risolvere le eventuali lacune. Puoi controllare la nostra directory dei partner per un elenco di esperti nella conduzione di valutazioni dei rischi per Google Cloud.

Per catalogare i rischi, prendi in considerazione Risk Manager, che fa parte del Programma di protezione dai rischi. (al momento questo programma è in anteprima). Risk Manager scansiona i carichi di lavoro per aiutarti a comprendere i rischi aziendali. I suoi report dettagliati forniscono una base di sicurezza per la sicurezza. Inoltre, puoi utilizzare i report di Gestore rischi per confrontare i tuoi rischi con i rischi descritti nel Benchmark del Center for Internet Security (CIS).

Dopo aver catalogato i rischi, devi determinare come gestirli, ovvero se vuoi accettarli, evitare, trasferirli o mitigarli. La seguente sezione descrive i controlli per la mitigazione.

Riduci i rischi

Puoi mitigare i rischi utilizzando controlli tecnici, protezioni contrattuali e verifiche o attestazioni di terze parti. La tabella seguente elenca come puoi utilizzare queste mitigazioni quando adotti nuovi servizi cloud pubblico.

Attenuazione	Descrizione
Controlli tecnici	I controlli tecnici si riferiscono alle funzionalità e alle tecnologie che utilizzi per proteggere il tuo ambiente. Questi includono controlli di sicurezza integrati del cloud, come firewall e logging. I controlli tecnici possono anche includere l'uso di strumenti di terze parti per rafforzare o supportare la strategia di sicurezza. Esistono due categorie di controlli tecnici: Google Cloud include vari controlli di sicurezza per attenuare i rischi che si applicano a te. Ad esempio, se hai un ambiente on-premise, puoi utilizzare Cloud VPN e Cloud Interconnect per proteggere la connessione tra le risorse on-premise e le risorse cloud. Google dispone di solidi controlli interni e audit per proteggere i dati dei clienti dall'accesso degli addetti ai lavori. I nostri audit log forniscono ai nostri clienti log quasi in tempo reale degli accessi degli amministratori Google su Google Cloud.
Tutele contrattuali	Per protezioni contrattuali si intendono gli impegni legali assunti da noi in merito ai servizi Google Cloud. Google si impegna a mantenere ed espandere il proprio portafoglio di prodotti per la conformità. Il documento Cloud Data Processing Addendum (ATDC) definisce il nostro impegno a mantenere le certificazioni ISO 27001, 27017 e 27018 e ad aggiornare i report SOC 2 e SOC 3 ogni 12 mesi. Il documento DPST illustra anche i controlli di accesso messi in atto per limitare l'accesso da parte dei tecnici dell'Assistenza Google agli ambienti dei clienti e descrive la nostra rigorosa procedura di logging e approvazione. Ti consigliamo di rivedere i controlli contrattuali di Google Cloud con i tuoi esperti legali e normativi e verificare che soddisfino i tuoi requisiti. Per ulteriori informazioni, contatta il rappresentante tecnico dell'account.
Verifiche o attestazioni di terze parti	Per verifiche o attestazioni di terze parti si intende il fatto che un fornitore di terze parti controlli il cloud provider per assicurarsi che il provider soddisfi i requisiti di conformità. Ad esempio, Google è stata sottoposta a verifica da una terza parte per verificare la conformità alla norma ISO 27017. Puoi visualizzare le certificazioni Google Cloud e le lettere di attestazione attuali nel Centro risorse per la conformità.

Passaggi successivi

Scopri di più sulla gestione dei rischi consultando le seguenti risorse:

• Gestisci le tue risorse (documento successivo di questa serie)

• Programma di protezione dai rischi

• Centro risorse per la conformità

• Governance del rischio della trasformazione digitale nel cloud (PDF)

Gestione degli asset

Questo documento nel framework dell'architettura Google Cloud fornisce le best practice per la gestione degli asset.

La gestione delle risorse è una parte importante dell'analisi dei requisiti aziendali. Devi sapere quali asset disponi e avere una buona conoscenza di tutti i tuoi asset, del loro valore e di eventuali percorsi critici o processi correlati. Devi disporre di un inventario accurato degli asset prima di poter progettare qualsiasi tipo di controlli di sicurezza per proteggere i tuoi asset.

Per gestire gli incidenti di sicurezza e soddisfare i requisiti normativi della tua organizzazione, hai bisogno di un inventario degli asset accurato e aggiornato che includa un modo per analizzare i dati storici. Devi essere in grado di monitorare gli asset, compreso il modo in cui la loro esposizione al rischio potrebbe cambiare nel tempo.

Il passaggio a Google Cloud significa che devi modificare i processi di gestione degli asset per adattarli a un ambiente cloud. Ad esempio, uno dei vantaggi del passaggio al cloud è l'aumento della capacità dell'organizzazione di scalare rapidamente. Tuttavia, la scalabilità rapida può causare problemi di shadow IT, in cui i dipendenti creano risorse cloud non correttamente gestite e protette. Pertanto, i processi di gestione delle risorse devono fornire ai dipendenti una flessibilità sufficiente per svolgere il proprio lavoro, fornendo al contempo controlli di sicurezza adeguati.

Utilizzare gli strumenti di gestione degli asset cloud

Gli strumenti di gestione degli asset di Google Cloud sono pensati appositamente per il nostro ambiente e per i principali casi d'uso dei clienti.

Uno di questi strumenti è Cloud Asset Inventory, che fornisce informazioni in tempo reale sullo stato attuale delle risorse e una cronologia di cinque settimane. Utilizzando questo servizio, puoi ottenere uno snapshot dell'inventario a livello di organizzazione per una vasta gamma di risorse e criteri di Google Cloud. Gli strumenti di Automation possono quindi utilizzare l'istantanea per il monitoraggio o l'applicazione dei criteri oppure archiviare l'istantanea per il controllo della conformità. Se vuoi analizzare le modifiche agli asset, l'inventario degli asset ti consente anche di esportare la cronologia dei metadati.

Per ulteriori informazioni su Cloud Asset Inventory, consulta gli articoli Soluzione personalizzata per rispondere alle modifiche degli asset e Controlli di rilevamento.

Automatizza la gestione degli asset

L'Automation consente di creare e gestire rapidamente gli asset in base ai requisiti di sicurezza che hai specificato. Puoi automatizzare gli aspetti del ciclo di vita degli asset nei seguenti modi:

• Esegui il deployment della tua infrastruttura cloud con strumenti di automazione come Terraform. Google Cloud fornisce il progetto di base per le aziende, che consente di configurare risorse di infrastruttura in grado di soddisfare le best practice per la sicurezza. Inoltre, configura le modifiche degli asset e le notifiche di conformità alle norme in Cloud Asset Inventory.
• Esegui il deployment delle tue applicazioni utilizzando strumenti di automazione come Cloud Run e Artifact Registry.

Monitorare le deviazioni dai criteri di conformità.

Le deviazioni dai criteri possono verificarsi durante tutte le fasi del ciclo di vita degli asset. Ad esempio, gli asset potrebbero essere creati senza i controlli di sicurezza adeguati o è possibile che i relativi privilegi vengano riassegnati. Analogamente, è possibile che gli asset vengano abbandonati senza che vengano seguite le appropriate procedure di fine ciclo di vita.

Per evitare questi scenari, ti consigliamo di monitorare gli asset per rilevare eventuali deviazioni dalla conformità. L'insieme di asset che monitori dipende dai risultati della valutazione del rischio e dai requisiti aziendali. Per saperne di più sul monitoraggio delle risorse, consulta Monitoraggio delle modifiche agli asset.

Integrare con i sistemi di monitoraggio per la gestione degli asset esistenti

Se utilizzi già un sistema SIEM o un altro sistema di monitoraggio, integra i tuoi asset Google Cloud con questo sistema. L'integrazione assicura che l'organizzazione disponga di una visualizzazione unica e completa su tutte le risorse, indipendentemente dall'ambiente. Per ulteriori informazioni, consulta Esportare i dati di sicurezza di Google Cloud nel tuo sistema SIEM e Scenari per l'esportazione di dati di Cloud Logging: Splunk.

Utilizza l'analisi dei dati per arricchire il monitoraggio

Puoi esportare l'inventario in una tabella BigQuery o in un bucket di Cloud Storage per ulteriori analisi.

Passaggi successivi

Scopri di più sulla gestione degli asset con le seguenti risorse:

• Gestisci identità e accesso (documento successivo di questa serie)
• Gestione delle risorse
• Progettazione del sistema

Gestione di identità e accessi

Questo documento nel framework dell'architettura Google Cloud fornisce le best practice per la gestione di identità e accessi.

La pratica della gestione di identità e accessi (generalmente definita IAM) ti aiuta a garantire che le persone giuste possano accedere alle risorse giuste. IAM si occupa dei seguenti aspetti dell'autenticazione e dell'autorizzazione:

• Gestione dell'account, incluso il provisioning
• Governance dell'identità
• Autenticazione
• Controllo dell'accesso (autorizzazione)
• Federazione delle identità

La gestione di IAM può essere difficile quando hai ambienti diversi o utilizzi più provider di identità. Tuttavia, è fondamentale configurare un sistema in grado di soddisfare le tue esigenze aziendali e di ridurre i rischi.

I suggerimenti in questo documento ti aiutano a esaminare i tuoi criteri e procedure IAM attuali e determinare quali di questi potresti dover modificare per i tuoi carichi di lavoro in Google Cloud. Ad esempio, devi esaminare quanto segue:

• Se puoi utilizzare i gruppi esistenti per gestire l'accesso o se devi crearne di nuovi.
• I tuoi requisiti di autenticazione (ad esempio autenticazione a più fattori (MFA) mediante un token).
• L'impatto degli account di servizio sui criteri attuali.
• Se utilizzi Google Cloud per il ripristino di emergenza, mantieni un'adeguata separazione dei compiti.

In Google Cloud, utilizzi Cloud Identity per autenticare i tuoi utenti e le risorse e il prodotto Identity and Access Management (IAM) di Google per determinare l'accesso alle risorse. Gli amministratori possono limitare l'accesso a livello di organizzazione, cartella, progetto e risorsa. I criteri IAM di Google determinano chi può fare cosa su quali risorse. I criteri IAM configurati correttamente contribuiscono a proteggere il tuo ambiente impedendo l'accesso non autorizzato alle risorse.

Per saperne di più, consulta la panoramica della gestione di identità e accessi.

Utilizzare un singolo provider di identità.

Molti dei nostri clienti dispongono di account utente gestiti e di cui viene eseguito il provisioning da provider di identità esterni a Google Cloud. Google Cloud supporta la federazione con la maggior parte dei provider di identità e con le directory on-premise come Active Directory.

La maggior parte dei provider di identità consente di abilitare il Single Sign-On (SSO) per gli utenti e i gruppi. Per le applicazioni di cui esegui il deployment su Google Cloud e che utilizzano il tuo provider di identità esterno, puoi estendere il provider a Google Cloud. Per maggiori informazioni, consulta Architetture di riferimento e Pattern per l'autenticazione degli utenti aziendali in un ambiente ibrido.

Se non hai un provider di identità esistente, puoi utilizzare Cloud Identity Premium o Google Workspace per gestire le identità per i tuoi dipendenti.

Proteggere l'account super amministratore

L'account super amministratore (gestito da Google Workspace o Cloud Identity) ti consente di creare la tua organizzazione Google Cloud. Questo account amministratore dispone quindi di privilegi elevati. Ecco alcune best practice per questo account:

• Crea un nuovo account a questo scopo; non utilizzare un account utente esistente.
• Crea e proteggi gli account di backup.
• Attiva MFA.

Per ulteriori informazioni, consulta le Best practice per gli account super amministratore.

Pianifica l'utilizzo degli account di servizio

Un account di servizio è un Account Google che le applicazioni possono utilizzare per chiamare l'API Google di un servizio.

A differenza degli account utente, gli account di servizio vengono creati e gestiti all'interno di Google Cloud. Inoltre, l'autenticazione degli account di servizio è diversa rispetto agli account utente:

• Per consentire a un'applicazione in esecuzione su Google Cloud di eseguire l'autenticazione utilizzando un account di servizio, puoi collegare un account di servizio alla risorsa di computing su cui viene eseguita l'applicazione.
• Per consentire a un'applicazione in esecuzione su GKE di eseguire l'autenticazione utilizzando un account di servizio, puoi utilizzare Workload Identity.
• Per consentire alle applicazioni in esecuzione al di fuori di Google Cloud di eseguire l'autenticazione con un account di servizio, puoi utilizzare Federazione delle identità per i carichi di lavoro

Quando utilizzi gli account di servizio, devi valutare una segregazione adeguata dei compiti durante il processo di progettazione. Prendi nota delle chiamate API che devi effettuare e determina gli account di servizio e i ruoli associati richiesti dalle chiamate API. Ad esempio, se stai configurando un data warehouse BigQuery, probabilmente hai bisogno di identità per almeno i seguenti processi e servizi:

• Cloud Storage o Pub/Sub, a seconda che tu stia fornendo un file batch o creando un servizio di streaming.
• Dataflow e Sensitive Data Protection per anonimizzare i dati sensibili.

Per ulteriori informazioni, consulta le best practice per l'utilizzo degli account di servizio.

Aggiorna i processi di identità per il cloud

La governance dell'identità consente di tenere traccia degli accessi, dei rischi e delle violazioni dei criteri in modo da poter soddisfare i requisiti normativi. Questa governance richiede la presenza di processi e criteri in modo da poter concedere e controllare ruoli e autorizzazioni per il controllo dell'accesso agli utenti. I processi e i criteri devono riflettere i requisiti dei tuoi ambienti, ad esempio test, sviluppo e produzione.

Prima di eseguire il deployment dei carichi di lavoro su Google Cloud, rivedi i processi di identità attuali e aggiornali, se opportuno. Assicurati di pianificare in modo appropriato i tipi di account di cui la tua organizzazione ha bisogno e di aver compreso bene il loro ruolo e i requisiti di accesso.

Per aiutarti a verificare le attività IAM di Google, Google Cloud crea audit log, che includono quanto segue:

• Attività dell'amministratore. Questo logging non può essere disabilitato.
• Attività di accesso ai dati. Devi enable questo logging.

Se necessario per scopi di conformità o se vuoi configurare l'analisi dei log (ad esempio con il tuo sistema SIEM), puoi esportare i log. Poiché i log possono aumentare i requisiti di archiviazione, potrebbero influire sui costi. Assicurati di registrare solo le azioni richieste e di impostare pianificazioni di conservazione appropriate.

Configurare SSO e MFA.

Il tuo provider di identità gestisce l'autenticazione degli account utente. Le identità federate possono eseguire l'autenticazione su Google Cloud utilizzando SSO. Per gli account con privilegi, come i super amministratori, è necessario configurare MFA. I token di sicurezza Titan sono token fisici che puoi utilizzare per l'autenticazione a due fattori (2FA) per prevenire gli attacchi di phishing.

Cloud Identity supporta la MFA utilizzando vari metodi. Per maggiori informazioni, consulta Applicare l'MFA uniforme alle risorse di proprietà dell'azienda.

Google Cloud supporta l'autenticazione per le identità dei carichi di lavoro mediante il protocollo OAuth 2.0 o i token web JSON (JWT) firmati. Per ulteriori informazioni sull'autenticazione dei carichi di lavoro, consulta Panoramica dell'autenticazione.

Implementare il privilegio minimo e la separazione dei compiti.

Devi assicurarti che le persone giuste accedano solo alle risorse e ai servizi di cui hanno bisogno per svolgere il proprio lavoro. In altre parole, devi seguire il principio del privilegio minimo. Inoltre, devi assicurarti che esista una separazione dei compiti adeguata.

Il provisioning eccessivo dell'accesso utente può aumentare il rischio di minacce interne, risorse configurate in modo errato e non conformità con i controlli. Le autorizzazioni di provisioning insufficiente possono impedire agli utenti di accedere alle risorse di cui hanno bisogno per completare le proprie attività.

Un modo per evitare l'overprovisioning è implementare l'accesso privilegiato just-in-time, ovvero fornire l'accesso con privilegi solo se necessario e concederlo solo temporaneamente.

Tieni presente che, quando viene creata un'organizzazione Google Cloud, a tutti gli utenti del tuo dominio vengono assegnati per impostazione predefinita i ruoli Creatore account di fatturazione e Autore progetto. Identificare gli utenti che svolgeranno queste mansioni e revocare i ruoli di altri utenti. Per saperne di più, consulta Creazione e gestione delle organizzazioni.

Per ulteriori informazioni su come funzionano i ruoli e le autorizzazioni in Google Cloud, consulta la Panoramica e la Panoramica dei ruoli nella documentazione di IAM. Per maggiori informazioni sull'applicazione del privilegio minimo, consulta Applicare il privilegio minimo con i suggerimenti sui ruoli.

Controlla l'accesso

Per monitorare le attività degli account con privilegi per rilevare eventuali deviazioni dalle condizioni approvate, utilizza Cloud Audit Logs. Cloud Audit Logs registra le azioni che i membri della tua organizzazione Google Cloud hanno eseguito nelle tue risorse Google Cloud. Puoi utilizzare vari tipi di log di controllo nei servizi Google. Per maggiori informazioni, consulta Using Cloud Audit Logs to Help Manage Insider Risk (video).

Utilizza il motore per suggerimenti IAM per tenere traccia dell'utilizzo e per modificare le autorizzazioni dove appropriato. I ruoli consigliati dal motore per suggerimenti IAM possono aiutarti a determinare quali ruoli concedere a un utente in base al suo comportamento passato e ad altri criteri. Per saperne di più, consulta le best practice per i suggerimenti sui ruoli.

Per controllare e controllare l'accesso alle risorse da parte del personale tecnico e dell'Assistenza Google, puoi utilizzare Access Transparency. Access Transparency registra le azioni intraprese dal personale di Google. Utilizza Access Approval, che fa parte di Access Transparency, per concedere l'approvazione esplicita ogni volta che viene eseguito l'accesso ai contenuti dei clienti. Per maggiori informazioni, vedi Controllare l'accesso ai dati da parte degli amministratori cloud.

Automatizza i controlli dei criteri

Imposta le autorizzazioni di accesso in modo programmatico, quando possibile. Per le best practice, consulta la sezione Vincoli dei criteri dell'organizzazione. Gli script Terraform per il progetto di base per le piattaforme aziendali si trovano nel repository di base di esempio.

Google Cloud include Policy Intelligence, che consente di rivedere e aggiornare automaticamente le autorizzazioni di accesso. Policy Intelligence include gli strumenti Motore per suggerimenti, Strumento per la risoluzione dei problemi relativi ai criteri e Analizzatore criteri che:

• Fornisci suggerimenti per l'assegnazione dei ruoli IAM.
• Monitora e contribuisci a prevenire criteri IAM eccessivamente permissivi.
• Offre assistenza per la risoluzione dei problemi relativi al controllo dell'accesso.

Imposta limitazioni sulle risorse

Google IAM si concentra su chi e ti consente di autorizzare chi può agire su risorse specifiche in base alle autorizzazioni. Il servizio Criteri dell'organizzazione si concentra su cosa e ti consente di impostare restrizioni sulle risorse per specificare come possono essere configurate. Ad esempio, puoi utilizzare un criterio dell'organizzazione per:

• Limita la condivisione delle risorse in base al dominio.
• Limita l'utilizzo degli account di servizio.
• Limita la località fisica delle risorse appena create.

Oltre a utilizzare i criteri dell'organizzazione per queste attività, puoi limitare l'accesso alle risorse utilizzando uno dei seguenti metodi:

• Utilizza i tag per gestire l'accesso alle risorse senza definire le autorizzazioni di accesso per ogni risorsa. Aggiungi invece il tag e poi imposta la definizione di accesso per il tag stesso.
• Utilizza le condizioni IAM per il controllo condizionale dell'accesso alle risorse basato su attributi.
• Implementa la difesa in profondità utilizzando i Controlli di servizio VPC per limitare ulteriormente l'accesso alle risorse.

Per saperne di più sulla gestione delle risorse, consulta Gestione delle risorse.

Passaggi successivi

Scopri di più su IAM con le seguenti risorse:

• Implementare la sicurezza di computing e container (documento successivo di questa serie)

• Utilizzo sicuro di IAM

• Architetture di riferimento

• Motore per suggerimenti IAM: privilegio minimo con meno sforzo

• Privacy dei dati cloud

• Panoramica della gestione di identità e accessi

Implementazione della sicurezza di computing e container

Google Cloud include controlli per proteggere le risorse di calcolo e le risorse container di Google Kubernetes Engine (GKE). Questo documento nel framework dell'architettura Google Cloud descrive i controlli chiave e le best practice per il loro utilizzo.

Utilizzare immagini VM protette e curate

Google Cloud include la VM schermata, che consente di proteggere le istanze VM. La Shielded VM è progettata per impedire il caricamento di codice dannoso durante il ciclo di avvio. Fornisce sicurezza di avvio, monitora l'integrità e utilizza il Virtual Trusted Platform Module (vTPM). Utilizza Shielded VM per carichi di lavoro sensibili.

Oltre a utilizzare Shielded VM, puoi usare le soluzioni dei partner Google Cloud per proteggere ulteriormente le tue VM. Molte soluzioni dei partner offerte su Google Cloud si integrano con Security Command Center, che offre funzioni di rilevamento delle minacce di eventi e monitoraggio dello stato di integrità. Puoi utilizzare i partner per l'analisi avanzata delle minacce o per una maggiore sicurezza di runtime.

Utilizzare Confidential Computing per l'elaborazione dei dati sensibili.

Per impostazione predefinita, Google Cloud cripta i dati at-rest e in transito attraverso la rete, ma i dati non vengono criptati quando sono in uso in memoria. Se la tua organizzazione gestisce dati riservati, devi mitigare le minacce che compromettono la riservatezza e l'integrità dell'applicazione o dei dati nella memoria di sistema. I dati riservati includono informazioni che consentono l'identificazione personale (PII), dati finanziari e informazioni sanitarie.

Confidential Computing si basa su Shielded VM. Protegge i dati in uso eseguendo il calcolo in un ambiente di esecuzione affidabile basato su hardware. Questo tipo di ambiente sicuro e isolato consente di impedire l'accesso o la modifica non autorizzata di applicazioni e dati mentre questi sono in uso. Un ambiente di esecuzione affidabile aumenta anche le garanzie di sicurezza per le organizzazioni che gestiscono dati sensibili e regolamentati.

In Google Cloud, puoi abilitare Confidential Computing eseguendo Confidential VM o Confidential GKE Node. Attiva Confidential Computing quando elabora carichi di lavoro riservati o quando hai dati riservati (ad esempio secret) che devono essere esposti durante l'elaborazione. Per ulteriori informazioni, consulta il Confidential Computing Consortium.

Protezione di VM e container

OS Login consente ai dipendenti di connettersi alle VM utilizzando le autorizzazioni di Identity and Access Management (IAM) come fonte attendibile invece di fare affidamento su chiavi SSH. Non è quindi necessario gestire le chiavi SSH in tutta l'organizzazione. OS Login lega l'accesso di un amministratore al ciclo di vita dei dipendenti. Ciò significa che se i dipendenti passano a un altro ruolo o lasciano l'organizzazione, il loro accesso viene revocato con l'account. OS Login supporta anche l'autenticazione a due fattori, che aggiunge un ulteriore livello di sicurezza agli attacchi di violazione degli account.

In GKE, App Engine esegue istanze dell'applicazione all'interno dei container Docker. Per abilitare un profilo di rischio definito e impedire ai dipendenti di apportare modifiche ai container, assicurati che i container siano stateless e immutabili. Il principio di immutabilità implica che i dipendenti non modificano il container o non vi accedono in modo interattivo. Se deve essere modificata, crei una nuova immagine ed esegui nuovamente il deployment. Abilita l'accesso SSH ai container sottostanti solo in scenari di debug specifici.

Disattiva gli indirizzi IP esterni se non sono necessari

Per disabilitare l'allocazione degli indirizzi IP esterni (video) per le VM di produzione e impedire l'utilizzo di bilanciatori del carico esterni, puoi utilizzare i criteri dell'organizzazione. Se hai bisogno che le tue VM accedano a internet o al tuo data center on-premise, puoi abilitare un gateway Cloud NAT.

Puoi eseguire il deployment di cluster privati in GKE. In un cluster privato, i nodi hanno solo indirizzi IP interni, il che significa che nodi e pod sono isolati da internet per impostazione predefinita. Puoi anche definire un criterio di rete per gestire la comunicazione tra pod nel cluster. Per maggiori informazioni, consulta Opzioni di accesso privato per i servizi.

Monitorare l'istanza di computing e l'utilizzo di GKE

Gli audit log di Cloud vengono abilitati automaticamente per Compute Engine e GKE. Gli audit log consentono di acquisire automaticamente tutte le attività del cluster e monitorare eventuali attività sospette.

Puoi integrare GKE con i prodotti dei partner per la sicurezza del runtime. Puoi integrare queste soluzioni con Security Command Center per avere un'unica interfaccia per il monitoraggio delle applicazioni.

Mantieni aggiornate le immagini e i cluster

Google Cloud fornisce immagini del sistema operativo selezionate con patch regolarmente. Puoi portare immagini personalizzate ed eseguirle su Compute Engine, ma se decidi di farlo, devi applicare le patch autonomamente. Google Cloud aggiorna regolarmente le immagini del sistema operativo per mitigare le nuove vulnerabilità come descritto nei bollettini sulla sicurezza e fornisce soluzioni per correggere le vulnerabilità dei deployment esistenti.

Se utilizzi GKE, ti consigliamo di abilitare l'upgrade automatico dei nodi per consentire a Google di aggiornare i nodi del cluster con le patch più recenti. Google gestisce i piani di controllo GKE, a cui vengono aggiornate e applicate automaticamente patch. Inoltre, per il deployment utilizza immagini ottimizzate per i container curate da Google. Google corregge e aggiorna regolarmente queste immagini.

Controlla l'accesso alle immagini e ai cluster

È importante sapere chi può creare e avviare le istanze. Puoi controllare questo accesso utilizzando IAM. Per informazioni su come determinare le esigenze dei carichi di lavoro di accesso, consulta Pianificare le identità dei carichi di lavoro.

Inoltre, puoi utilizzare Controlli di servizio VPC per definire quote personalizzate sui progetti in modo da limitare gli utenti che possono avviare le immagini. Per ulteriori informazioni, consulta la sezione Proteggere la rete.

Per garantire la sicurezza dell'infrastruttura per il tuo cluster, GKE ti consente di utilizzare IAM con controllo dell'accesso basato sui ruoli (RBAC) per gestire l'accesso al cluster e agli spazi dei nomi.

Isolare i container in una sandbox

Utilizza GKE Sandbox per eseguire il deployment di applicazioni multi-tenant che richiedono un ulteriore livello di sicurezza e di isolamento dal kernel host. Ad esempio, usa GKE Sandbox quando esegui codice sconosciuto o non attendibile. GKE Sandbox è una soluzione di isolamento dei container che fornisce un secondo livello di difesa fra i carichi di lavoro containerizzati su GKE.

GKE Sandbox è stato creato per applicazioni che hanno requisiti di I/O bassi, ma con una scalabilità elevata. Questi carichi di lavoro containerizzati devono mantenere velocità e prestazioni, ma potrebbero anche includere codice non attendibile che richiede maggiore sicurezza. Utilizza gVisor, una sandbox per il runtime dei container, per fornire un ulteriore isolamento di sicurezza tra le applicazioni e il kernel host. gVisor fornisce controlli di integrità aggiuntivi e limita l'ambito di accesso per un servizio. Non è un servizio di protezione avanzata dei container per proteggerlo da minacce esterne. Per maggiori informazioni su gVisor, consulta gVisor: protezione degli utenti GKE e serverless nel mondo reale.

Passaggi successivi

Scopri di più sulla sicurezza di computing e container con le seguenti risorse:

• Proteggi la tua rete (documento successivo di questa serie)
• Perché la sicurezza dei container è importante (PDF)
• Elenco di controllo per il lancio di Google Cloud
• Verifica dell'identità delle istanze
• Identità del carico di lavoro
• VM schermata
• Best practice per disco permanente permanenti
• Best practice per la gestione delle immagini

Protezione della rete

Questo documento nel framework dell'architettura Google Cloud fornisce le best practice per la protezione della rete.

L'estensione della rete esistente ad ambienti cloud ha molte implicazioni per la sicurezza. Il tuo approccio on-premise alle difese a più livelli prevede che preveda un perimetro distinto tra internet e la tua rete interna. Probabilmente proteggerai il perimetro utilizzando firewall fisici, router, sistemi di rilevamento delle intrusioni e così via. Poiché il confine è chiaramente definito, puoi facilmente monitorare le intrusioni e rispondere di conseguenza.

Quando passi al cloud (completamente o con un approccio ibrido), passi al perimetro della rete on-premise. Questo documento descrive i modi in cui puoi continuare a proteggere i dati e i carichi di lavoro della tua organizzazione su Google Cloud. Come menzionato in Gestione dei rischi con i controlli, il modo in cui configuri e proteggi la tua rete Google Cloud dipende dai requisiti aziendali e dalla propensione al rischio.

Questa sezione presuppone che tu abbia letto la sezione Networking nella categoria Progettazione del sistema e che tu abbia già creato un diagramma dell'architettura di base dei componenti di rete di Google Cloud. Per un diagramma di esempio, consulta Hub-and-spoke.

Esegui il deployment di reti Zero Trust

Il passaggio al cloud significa che il modello di attendibilità della rete deve cambiare. Poiché i tuoi utenti e i tuoi carichi di lavoro non si trovano più dietro il tuo perimetro on-premise, non puoi utilizzare le protezioni perimetrali allo stesso modo per creare una rete interna affidabile. Il modello di sicurezza Zero Trust indica che nessuno è considerato attendibile per impostazione predefinita, sia all'interno che all'esterno della rete dell'organizzazione. Durante la verifica delle richieste di accesso, il modello di sicurezza Zero Trust richiede la verifica sia dell'identità dell'utente che del contesto. A differenza di una VPN, i controlli di accesso vengono spostati dal perimetro di rete agli utenti e ai dispositivi.

In Google Cloud, puoi utilizzare BeyondCorp Enterprise come soluzione Zero Trust. BeyondCorp Enterprise offre protezione dai dati e dalle minacce e controlli dell'accesso aggiuntivi. Per ulteriori informazioni su come configurarlo, consulta la guida introduttiva a BeyondCorp Enterprise.

Oltre a BeyondCorp Enterprise, Google Cloud include Identity-Aware Proxy (IAP). IAP consente di estendere la sicurezza Zero Trust alle applicazioni sia in Google Cloud che on-premise. IAP utilizza i criteri di controllo dell'accesso per fornire l'autenticazione e l'autorizzazione agli utenti che accedono alle tue applicazioni e alle tue risorse.

Proteggere le connessioni agli ambienti on-premise o multi-cloud.

Molte organizzazioni hanno carichi di lavoro sia in ambienti cloud che on-premise. Inoltre, per la resilienza, alcune organizzazioni utilizzano soluzioni multi-cloud. In questi scenari, è fondamentale proteggere la connettività tra tutti gli ambienti.

Google Cloud include metodi di accesso privato per le VM supportati da Cloud VPN o Cloud Interconnect, tra cui:

• Utilizza Cross-Cloud Interconnect come servizio gestito per collegare le tue reti VPC ad altri cloud provider supportati tramite connessioni dirette ad alta velocità. Con Cross-Cloud Interconnect, non devi fornire il tuo router o collaborare con un fornitore di terze parti.
• Utilizza Dedicated Interconnect e Partner Interconnect per collegare le tue reti VPC al tuo data center on-premise o ad altri cloud provider tramite connessioni dirette ad alta velocità.
• Utilizza le VPN IPsec per collegare le tue reti Virtual Private Cloud (VPC) al tuo data center on-premise o ad altri cloud provider.
• Utilizza gli endpoint Private Service Connect per accedere ai servizi pubblicati forniti dalla tua organizzazione o da un altro provider.
• Utilizza gli endpoint Private Service Connect per consentire alle VM di accedere alle API di Google utilizzando indirizzi IP interni. Con Private Service Connect, le VM non devono avere indirizzi IP esterni per accedere ai servizi Google.
• Se utilizzi GKE Enterprise, considera i gateway in uscita da Anthos Service Mesh. Se non utilizzi GKE Enterprise, utilizza un'opzione di terze parti.

Per un confronto tra i prodotti, vedi Scegliere un prodotto per la connettività di rete.

Disattiva reti predefinite

Quando crei un nuovo progetto Google Cloud, viene eseguito automaticamente il provisioning di una rete Google Cloud VPC predefinita con indirizzi IP in modalità automatica e regole firewall precompilate. Per i deployment di produzione, ti consigliamo di eliminare le reti predefinite nei progetti esistenti e disabilitare la creazione di reti predefinite nei nuovi progetti.

Le reti Virtual Private Cloud consentono di utilizzare qualsiasi indirizzo IP interno. Per evitare conflitti di indirizzi IP, ti consigliamo di pianificare prima la rete e l'allocazione degli indirizzi IP nei deployment connessi e nei progetti. Un progetto consente più reti VPC, ma di solito conviene limitarle a una per progetto al fine di applicare in modo efficace controllo dell'accesso dell'accesso.

Proteggi il perimetro

In Google Cloud puoi utilizzare vari metodi per segmentare e proteggere il perimetro cloud, inclusi firewall e Controlli di servizio VPC.

Utilizza un VPC condiviso per creare un deployment di produzione che ti fornisca un'unica rete condivisa e che isola i carichi di lavoro in singoli progetti che possono essere gestiti da team diversi. Il VPC condiviso offre deployment, gestione e controllo centralizzati delle risorse di sicurezza di rete e di rete in più progetti. Il VPC condiviso è costituito da progetti host e di servizio che eseguono le seguenti funzioni:

• Un progetto host contiene le risorse relative alla sicurezza di rete e di rete, ad esempio reti VPC, subnet, regole firewall e connettività ibrida.
• Un progetto di servizio viene collegato a un progetto host. Consente di isolare i carichi di lavoro e gli utenti a livello di progetto utilizzando Identity and Access Management (IAM), mentre condivide le risorse di networking dal progetto host gestito centralmente.

Definisci criteri e regole firewall a livello di organizzazione, cartella e rete VPC. Puoi configurare regole firewall per consentire o negare il traffico da o verso le istanze VM. Ad esempio, consulta Esempi di criteri firewall di rete globali e a livello di regione ed Esempi di criteri firewall gerarchici. Oltre a definire le regole in base a indirizzi IP, protocolli e porte, puoi gestire il traffico e applicare regole firewall in base all'account di servizio utilizzato da un'istanza VM o utilizzando tag protetti.

Per controllare lo spostamento dei dati nei servizi Google e per configurare la sicurezza del perimetro basata sul contesto, prendi in considerazione Controlli di servizio VPC. I Controlli di servizio VPC forniscono un ulteriore livello di sicurezza per i servizi Google Cloud, indipendente da regole e criteri IAM e firewall. Ad esempio, Controlli di servizio VPC consente di configurare perimetri tra dati riservati e non riservati, in modo da poter applicare controlli che aiutano a prevenire l'esfiltrazione di dati.

Utilizza i criteri di sicurezza di Google Cloud Armor per consentire, negare o reindirizzare le richieste al bilanciatore del carico delle applicazioni esterno a livello perimetrale di Google Cloud, il più vicino possibile alla sorgente del traffico in entrata. Questi criteri impediscono al traffico indesiderato di consumare risorse o di entrare nella rete.

Utilizza Secure Web Proxy per applicare criteri di accesso granulari al traffico web in uscita e per monitorare l'accesso a servizi web non attendibili.

Esaminare il traffico di rete

Puoi utilizzare Cloud IDS e Mirroring pacchetto per garantire la sicurezza e la conformità dei carichi di lavoro in esecuzione in Compute Engine e Google Kubernetes Engine (GKE).

Utilizza Cloud Intrusion Detection System (attualmente in anteprima) per ottenere visibilità sul traffico in entrata e in uscita dalle reti VPC. Cloud IDS crea una rete in peering gestita da Google che ha VM con mirroring. Le tecnologie di protezione dalle minacce di Palo Alto Networks eseguono il mirroring e l'ispezione del traffico. Per maggiori informazioni, consulta la panoramica di Cloud IDS.

Il Mirroring pacchetto clona il traffico di istanze VM specificate nella rete VPC e lo inoltra per la raccolta, la conservazione e l'esame. Dopo aver configurato il servizio Mirroring pacchetto, puoi utilizzare Cloud IDS o strumenti di terze parti per raccogliere e analizzare il traffico di rete su larga scala. L'ispezione del traffico di rete in questo modo consente di rilevare le intrusioni e monitorare le prestazioni delle applicazioni.

Usare un web application firewall

Per i servizi e le applicazioni web esterni, puoi abilitare Google Cloud Armor per fornire funzionalità di protezione DDoS (Distributed Denial of Service) e Firewall delle applicazioni web (WAF Application Firewall). Google Cloud Armor supporta i carichi di lavoro Google Cloud esposti utilizzando il bilanciamento del carico HTTP(S) esterno, il bilanciamento del carico del proxy TCP o il bilanciamento del carico del proxy SSL.

Google Cloud Armor è offerto in due livelli di servizio, Standard e Managed Protection Plus. Per sfruttare al massimo le funzionalità avanzate di Google Cloud Armor, devi investire in Managed Protection Plus per i tuoi carichi di lavoro chiave.

Automatizza il provisioning dell'infrastruttura

L'Automation consente di creare un'infrastruttura immutabile, il che significa che non può essere modificata dopo il provisioning. Questa misura fornisce al team operativo uno stato valido noto, un rollback veloce e funzionalità di risoluzione dei problemi. Per l'automazione, puoi utilizzare strumenti come Terraform, Jenkins e Cloud Build.

Per aiutarti a creare un ambiente che utilizza l'automazione, Google Cloud fornisce una serie di progetti di sicurezza a loro volta basati sul progetto di base aziendale. Il progetto della piattaforma di sicurezza fornisce il design "guidato" di Google per un ambiente applicativo sicuro e descrive passo dopo passo come configurare ed eseguire il deployment della tua proprietà Google Cloud. Utilizzando le istruzioni e gli script che fanno parte del progetto della piattaforma di sicurezza, puoi configurare un ambiente che soddisfi le nostre best practice e linee guida per la sicurezza. Puoi basarti su quel progetto con altri progetti oppure creare la tua automazione.

Per maggiori informazioni sull'automazione, consulta Utilizzare una pipeline CI/CD per i flussi di lavoro di elaborazione dati.

Monitorare la rete

Monitora la rete e il traffico utilizzando la telemetria.

I log di flusso VPC e il logging delle regole firewall forniscono visibilità quasi in tempo reale sul traffico e sull'utilizzo del firewall nel tuo ambiente Google Cloud. Ad esempio, il logging delle regole firewall registra il traffico da e verso le istanze VM di Compute Engine. Se combini questi strumenti con Cloud Logging e Cloud Monitoring, puoi monitorare, avvisare e visualizzare i pattern di traffico e accesso per migliorare la sicurezza operativa del deployment.

Firewall Insights ti consente di esaminare quali regole firewall corrispondono alle connessioni in entrata e in uscita e se le connessioni sono state consentite o negate. La funzionalità delle regole con shadowing ti aiuta a ottimizzare la configurazione del firewall mostrandoti quali regole non vengono mai attivate, in quanto un'altra regola viene sempre attivata per prima.

Utilizza Network Intelligence Center per scoprire le prestazioni della tua topologia e dell'architettura di rete. Puoi ottenere insight dettagliati sulle prestazioni della rete e quindi ottimizzare il deployment per eliminare eventuali colli di bottiglia nel tuo servizio. I test di connettività forniscono insight sulle regole e sui criteri firewall applicati al percorso di rete.

Per maggiori informazioni sul monitoraggio, consulta Implementare il logging e i controlli di rilevamento.

Passaggi successivi

Scopri di più sulla sicurezza della rete nelle seguenti risorse:

• Implementare la sicurezza dei dati (documento successivo di questa serie)
• Best practice e architetture di riferimento per la progettazione di VPC
• Ruoli IAM per amministrare i Controlli di servizio VPC
• Onboarding in qualità di partner di Security Command Center
• Visualizzazione di vulnerabilità e minacce in Security Command Center
• Mirroring pacchetto: visualizza e protegge la rete cloud
• Usare Mirroring pacchetto per il rilevamento delle intrusioni
• Utilizzare il mirroring pacchetto con una soluzione IDS partner

Implementazione della sicurezza dei dati

Questo documento nel framework dell'architettura Google Cloud fornisce le best practice per l'implementazione della sicurezza dei dati.

Nell'ambito dell'architettura di deployment, devi considerare quali dati prevedi di elaborare e archiviare in Google Cloud e la sensibilità dei dati. Progetta i tuoi controlli per contribuire a proteggere i dati durante il loro ciclo di vita, a identificarne la proprietà e la classificazione e a proteggerli dall'uso non autorizzato.

Per un progetto di sicurezza che esegue il deployment di un data warehouse BigQuery con le best practice per la sicurezza descritte in questo documento, vedi Proteggere un data warehouse BigQuery che archivia dati riservati.

Classifica automaticamente i tuoi dati

Eseguire la classificazione dei dati il prima possibile nel ciclo di vita della gestione dei dati, idealmente quando i dati vengono creati. Di solito, gli sforzi di classificazione dei dati richiedono solo poche categorie, tra cui:

• Pubblico: dati approvati per l'accesso pubblico.
• Interno: dati non sensibili che non vengono rilasciati al pubblico.
• Riservato: dati sensibili disponibili per la distribuzione interna generale.
• Con restrizioni: dati altamente sensibili o regolamentati che richiedono una distribuzione limitata.

Utilizza Sensitive Data Protection per scoprire e classificare i dati nel tuo ambiente Google Cloud. Sensitive Data Protection dispone del supporto integrato per la scansione e la classificazione dei dati sensibili in Cloud Storage, BigQuery e Datastore. Dispone inoltre di API di streaming per supportare origini dati aggiuntive e carichi di lavoro personalizzati.

Sensitive Data Protection può identificare i dati sensibili utilizzando infoType integrati. Può classificare, mascherare, tokenizzare e trasformare automaticamente elementi sensibili (come i dati PII) per consentirti di gestire il rischio di raccolta, archiviazione e utilizzo dei dati. In altre parole, può integrarsi con i processi del ciclo di vita dei dati per garantire che i dati in ogni fase siano protetti.

Per maggiori informazioni, consulta Anonimizzazione e reidentificazione delle PII in set di dati su larga scala utilizzando Sensitive Data Protection.

Gestisci la governance dei dati utilizzando i metadati

La governance dei dati è una combinazione di processi che garantiscono che i dati siano sicuri, privati, accurati, disponibili e utilizzabili. Anche se sei responsabile della definizione di una strategia di governance dei dati per la tua organizzazione, Google Cloud fornisce strumenti e tecnologie per aiutarti a mettere in pratica la tua strategia. Google Cloud fornisce anche un framework per la governance dei dati (PDF) nel cloud.

Utilizza Data Catalog per trovare, selezionare e utilizzare metadati per descrivere i tuoi asset di dati nel cloud. Puoi utilizzare Data Catalog per cercare asset di dati e contrassegnarli con i metadati. Per accelerare le iniziative di classificazione dei dati, integra Data Catalog con Sensitive Data Protection per identificare automaticamente i dati riservati. Dopo aver taggato i dati, puoi utilizzare Google Identity and Access Management (IAM) per limitare i dati che gli utenti possono eseguire query o utilizzare tramite le viste di Data Catalog.

Utilizza Dataproc Metastore o il metastore Hive per gestire i metadati per i carichi di lavoro. Data Catalog dispone di un connettore hive che consente al servizio di rilevare i metadati all'interno di un metastore hive.

Utilizza Dataprep di Trifacta per definire e applicare le regole sulla qualità dei dati tramite una console. Puoi utilizzare Dataprep da Cloud Data Fusion oppure utilizzare Dataprep come servizio autonomo.

Proteggi i dati in base alla fase del ciclo di vita e alla classificazione

Dopo aver definito i dati nel contesto del loro ciclo di vita e classificati in base alla sensibilità e al rischio, puoi assegnare i controlli di sicurezza adeguati per proteggerli. Devi assicurarti che i controlli offrano protezioni adeguate, soddisfino i requisiti di conformità e riducono i rischi. Passando al cloud, esamina la tua strategia attuale e scopri dove potresti dover modificare i processi attuali.

La seguente tabella descrive tre caratteristiche di una strategia di sicurezza dei dati nel cloud.

Caratteristica	Descrizione
Identificazione	Scopri l'identità di utenti, risorse e applicazioni mentre creano, modificano, archiviano, utilizzano, condividono ed eliminano i dati. Utilizza Cloud Identity e IAM per controllare l'accesso ai dati. Se le tue identità richiedono dei certificati, prendi in considerazione Certificate Authority Service. Per saperne di più, consulta Gestire identità e accesso.
Confine e accesso	Configura controlli relativi alle modalità di accesso ai dati, da chi e in quali circostanze. I limiti di accesso ai dati possono essere gestiti a questi livelli: Accesso al livello di rete mediante controlli come Cloud Firewall. Per ulteriori informazioni sul livello della tua rete, utilizza il Network Intelligence Center. Utilizza Controlli di servizio VPC per creare perimetri che proteggono le risorse e i dati dei servizi da te specificati. Controlli dell'accesso IAM utilizzando IAM. Per informazioni sulla gestione dei ruoli IAM, consulta Utilizzo delle gerarchie di risorse per il controllo dell'accesso.
Visibilità	Puoi verificare l'utilizzo e creare report che dimostrano in che modo viene controllato e accessibile i dati. Google Cloud Logging e Access Transparency forniscono insight sulle attività dei tuoi amministratori cloud e del personale Google. Per ulteriori informazioni, vedi Monitorare i dati.

Cripta i dati

Per impostazione predefinita, Google Cloud cripta i dati dei clienti archiviati at-rest, senza che sia necessario alcun intervento da parte tua. Oltre alla crittografia predefinita, Google Cloud offre opzioni per la gestione delle chiavi di crittografia envelope e di crittografia. Ad esempio, i dischi permanenti di Compute Engine vengono criptati automaticamente, ma puoi fornire o gestire le tue chiavi.

Devi identificare le soluzioni più adatte ai tuoi requisiti per la generazione, l'archiviazione e la rotazione delle chiavi, che tu stia scegliendo le chiavi per l'archiviazione, per il calcolo o per i carichi di lavoro dei big data.

Google Cloud include le seguenti opzioni per la crittografia e la gestione delle chiavi:

• Chiavi di crittografia gestite dal cliente (CMEK). Puoi generare e gestire le chiavi di crittografia utilizzando Cloud Key Management Service (Cloud KMS). Utilizza questa opzione se hai determinati requisiti di gestione delle chiavi, come la necessità di ruotare regolarmente le chiavi di crittografia.
• Chiavi di crittografia fornite dal cliente (CSEK). Puoi creare e gestire le tue chiavi di crittografia e poi fornirle a Google Cloud quando necessario. Utilizza questa opzione se generi le tue chiavi utilizzando il sistema di gestione delle chiavi on-premise per utilizzare la tua chiave (BYOK). Se fornisci le tue chiavi utilizzando CSEK, Google le replica e le rende disponibili per i tuoi carichi di lavoro. Tuttavia, la sicurezza e la disponibilità della CSEK è una tua responsabilità perché le chiavi fornite dal cliente non sono archiviate nei modelli di istanza o nell'infrastruttura di Google. Se perdi l'accesso alle chiavi, Google non può aiutarti a recuperare i dati criptati. Pensa attentamente alle chiavi che vuoi creare e gestire autonomamente. Puoi usare CSEK solo per le informazioni più sensibili. Un'altra opzione è eseguire la crittografia lato client sui dati e poi archiviarli in Google Cloud, dove Google vengono nuovamente criptati da Google.
• Sistema di gestione delle chiavi di terze parti con Cloud External Key Manager (Cloud EKM). Cloud EKM protegge i dati at-rest utilizzando chiavi di crittografia archiviate e gestite in un sistema di gestione delle chiavi di terze parti, che puoi controllare al di fuori dell'infrastruttura di Google. Quando utilizzi questo metodo, hai la certezza che i tuoi dati non sono accessibili a nessuno al di fuori della tua organizzazione. Cloud EKM consente di creare un modello HYOK (hold-your-own-key) sicuro per la gestione delle chiavi. Per informazioni sulla compatibilità, consulta l'elenco dei servizi abilitati per Cloud EKM.

Cloud KMS consente inoltre di criptare i dati con chiavi di crittografia supportate da software o con moduli di sicurezza hardware (HSM) convalidati di livello 3 e convalidati dallo standard FIPS 140-2. Se utilizzi Cloud KMS, le tue chiavi di crittografia vengono archiviate nella regione in cui esegui il deployment della risorsa. Cloud HSM distribuisce le esigenze di gestione delle chiavi tra regioni, offrendo ridondanza e disponibilità globale delle chiavi.

Per informazioni sul funzionamento della crittografia envelope, consulta Crittografia at-rest in Google Cloud.

Controlla l'accesso degli amministratori cloud ai tuoi dati

Puoi controllare l'accesso al tuo ambiente su Google Cloud da parte del personale tecnico e dell'Assistenza Google. Access Approval consente di approvare esplicitamente l'accesso dei dipendenti Google ai tuoi dati o alle tue risorse su Google Cloud. Questo prodotto completa la visibilità fornita da Access Transparency, che genera log quando il personale Google interagisce con i tuoi dati. Questi log includono la posizione dell'ufficio e il motivo dell'accesso.

Se utilizzi questi prodotti insieme, puoi negare a Google per qualsiasi motivo la possibilità di decriptare i tuoi dati.

Configurare la posizione dei dati e dell'accesso degli utenti.

Puoi controllare le località di rete da cui gli utenti possono accedere ai dati utilizzando i Controlli di servizio VPC. Questo prodotto ti consente di limitare l'accesso agli utenti in una regione specifica. Puoi applicare questo vincolo anche se l'utente è autorizzato in base al tuo criterio Google IAM. Utilizzando i Controlli di servizio VPC, puoi creare un perimetro di servizio che definisce i confini virtuali da cui è possibile accedere a un servizio, impedendo così lo spostamento dei dati al di fuori di questi confini.

Per ulteriori informazioni, consulta le seguenti risorse:

• Automazione della classificazione dei dati caricati su Cloud Storage
• Governance dei dati nel cloud
• Governance dei dati dal data warehouse a BigQuery
• Mestore Cloud Hives ora disponibile

Gestire i segreti tramite Secret Manager.

Secret Manager ti consente di archiviare tutti i tuoi secret in una posizione centralizzata. I Secret sono informazioni di configurazione come password di database, chiavi API o certificati TLS. Puoi ruotare automaticamente i secret e puoi configurare le applicazioni in modo che utilizzino automaticamente la versione più recente di un secret. Ogni interazione con Secret Manager genera un audit log, in modo da visualizzare ogni accesso a ogni secret.

Sensitive Data Protection ha anche una categoria di rilevatori per aiutarti a identificare le credenziali e i secret nei dati che potrebbero essere protetti con Secret Manager.

Monitora i tuoi dati

Per visualizzare i log delle attività dell'amministratore e dell'utilizzo delle chiavi, utilizza Cloud Audit Logs. Per proteggere i dati, monitora i log con Cloud Monitoring per garantire l'utilizzo corretto delle chiavi.

Cloud Logging acquisisce gli eventi di Google Cloud e, se necessario, ti consente di aggiungere altre origini. Puoi segmentare i log per regione, archiviarli in bucket e integrare un codice personalizzato per l'elaborazione dei log. Per un esempio, consulta Soluzione personalizzata per l'analisi automatica dei log.

Puoi inoltre esportare i log in BigQuery per eseguire analisi di sicurezza e di accesso al fine di identificare modifiche non autorizzate e accessi inappropriati ai dati della tua organizzazione.

Security Command Center può aiutarti a identificare e risolvere i problemi di accesso non sicuro ai dati organizzativi sensibili archiviati nel cloud. Tramite un'unica interfaccia di gestione, puoi analizzare un'ampia gamma di vulnerabilità e rischi di sicurezza per la tua infrastruttura cloud. Ad esempio, puoi monitorare l'esfiltrazione di dati, eseguire la scansione dei sistemi di archiviazione per rilevare i dati riservati e rilevare quali bucket Cloud Storage sono aperti a internet.

Passaggi successivi

Scopri di più sulla sicurezza dei dati nelle seguenti risorse:

• Deployment delle applicazioni in modo sicuro (prossimo documento di questa serie)

• Proteggi un data warehouse BigQuery che archivia i dati riservati

• Progettare e implementare una strategia di sicurezza dei dati (PDF)

• Riservatezza dei dati del cliente garantita con Google Cloud (PDF)

• Criteri di conservazione che utilizzano il blocco di bucket

• Best practice per Cloud Storage

• Best practice per le istanze SQL Server

• Best practice per i datastore

• Data Catalog

Esegui il deployment delle applicazioni in sicurezza

Questo documento nel framework dell'architettura Google Cloud fornisce le best practice per il deployment sicuro delle applicazioni.

Per eseguire il deployment di applicazioni sicure, devi avere un ciclo di vita di sviluppo del software ben definito, con controlli di sicurezza adeguati durante le fasi di progettazione, sviluppo, test e deployment. Quando progetti un'applicazione, ti consigliamo un'architettura di sistema a più livelli che utilizza framework standardizzati per controllo dell'accesso dell'identità, dell'autorizzazione e dell'accesso.

Automatizzare le release sicure

Senza strumenti automatizzati, può essere difficile eseguire il deployment, aggiornare e applicare patch ad ambienti applicativi complessi per soddisfare requisiti di sicurezza coerenti. Ti consigliamo quindi di creare una pipeline CI/CD per queste attività, che può risolvere molti di questi problemi. Le pipeline automatizzate rimuovono gli errori manuali, forniscono cicli di feedback di sviluppo standardizzati e consentono iterazioni del prodotto rapide. Ad esempio, i pool privati di Cloud Build ti consentono di eseguire il deployment di una pipeline CI/CD gestita altamente sicura per settori altamente regolamentati, tra cui la finanza e la sanità.

Puoi utilizzare l'automazione per analizzare le vulnerabilità di sicurezza quando vengono creati gli artefatti. Puoi anche definire criteri per ambienti diversi (sviluppo, test, produzione e così via) in modo che venga eseguito il deployment solo degli artefatti verificati.

Assicurarsi che i deployment delle applicazioni seguano i processi approvati.

Se un utente malintenzionato compromette la pipeline CI/CD, può influire sull'intero stack. Per proteggere la pipeline, devi applicare un processo di approvazione stabilito prima di eseguire il deployment del codice in produzione.

Se prevedi di utilizzare Google Kubernetes Engine (GKE) o GKE Enterprise, puoi stabilire questi controlli e bilanciamenti utilizzando Autorizzazione binaria. Autorizzazione binaria associa le firme configurabili alle immagini container. Queste firme (chiamate anche attestations) aiutano a convalidare l'immagine. Al momento del deployment, Autorizzazione binaria utilizza queste attestazioni per determinare che un processo è stato completato in precedenza. Ad esempio, puoi utilizzare Autorizzazione binaria per:

• Verifica che un sistema di compilazione specifico o una pipeline di integrazione continua (CI) abbia creato un'immagine container.
• Convalidare che un'immagine container sia conforme a un criterio di firma delle vulnerabilità.
• Verificare che un'immagine container superi i criteri per la promozione nell'ambiente di deployment successivo, ad esempio dallo sviluppo al QA.

Analizza le vulnerabilità note prima del deployment

Ti consigliamo di utilizzare strumenti automatizzati in grado di eseguire continuamente analisi delle vulnerabilità sulle immagini container prima del deployment dei container in produzione.

Utilizza Artifact Analysis per scansionare automaticamente le vulnerabilità dei container archiviati in Artifact Registry e Container Registry. Questo processo prevede due attività: scansione e analisi continua.

Per iniziare, Artifact Analysis analizza le nuove immagini quando vengono caricate su Artifact Registry o Container Registry. La scansione estrae informazioni sui pacchetti di sistema nel container.

Artifact Analysis cerca quindi le vulnerabilità quando carichi l'immagine. Dopo la scansione iniziale, Artifact Analysis monitora continuamente i metadati delle immagini scansionate in Artifact Registry e Container Registry per rilevare nuove vulnerabilità. Quando Artifact Analysis riceve informazioni sulle vulnerabilità nuove e aggiornate da origini delle vulnerabilità, effettua quanto segue:

• Consente di aggiornare i metadati delle immagini scansionate per mantenerle aggiornate.
• Crea nuove occorrenze di vulnerabilità per le nuove note.
• Elimina le occorrenze di vulnerabilità non più valide.

Monitorare il codice dell'applicazione per verificare la presenza di vulnerabilità note.

La best practice prevede l'utilizzo di strumenti automatizzati in grado di monitorare costantemente il codice dell'applicazione per individuare vulnerabilità note come OWASP Top 10. Per una descrizione dei prodotti e delle funzionalità di Google Cloud che supportano le dieci principali tecniche di mitigazione OWASP, consulta Le dieci principali opzioni di mitigazione OWASP su Google Cloud.

Utilizza Web Security Scanner per identificare le vulnerabilità di sicurezza nelle applicazioni web di App Engine, Compute Engine e Google Kubernetes Engine. Lo scanner esegue la scansione dell'applicazione, seguendo tutti i link nell'ambito degli URL di avvio e tenta di utilizzare il maggior numero possibile di input utente e gestori di eventi. Può eseguire automaticamente la scansione e rilevare le vulnerabilità comuni, tra cui cross-site scripting (XSS), Flash injection, contenuti misti (HTTP in HTTPS) e librerie obsolete o non sicure. Web Security Scanner consente di identificare in anticipo questi tipi di vulnerabilità con un basso indice di falsi positivi.

Controlla lo spostamento dei dati attraverso i perimetri

Per controllare lo spostamento dei dati attraverso un perimetro, puoi configurare perimetri di sicurezza intorno alle risorse dei tuoi servizi gestiti da Google. Utilizza Controlli di servizio VPC per posizionare tutti i componenti e i servizi nella pipeline CI/CD (ad esempio Container Registry, Artifact Registry, Artifact Analysis e Autorizzazione binaria) all'interno di un perimetro di sicurezza.

Controlli di servizio VPC migliora la tua capacità di ridurre il rischio di copia o trasferimento non autorizzati di dati (esfiltrazione di dati) dai servizi gestiti da Google. Con i Controlli di servizio VPC, puoi configurare i perimetri di sicurezza intorno alle risorse dei tuoi servizi gestiti da Google per controllare lo spostamento dei dati attraverso il confine del perimetro. Quando viene applicato un perimetro di servizio, le richieste che violano il relativo criterio vengono rifiutate, ad esempio le richieste inviate ai servizi protetti dall'esterno di un perimetro. Quando un servizio è protetto da un perimetro in modalità di applicazione forzata, i Controlli di servizio VPC assicurano quanto segue:

• Un servizio non può trasmettere dati al di fuori del perimetro. I servizi protetti funzionano normalmente all'interno del perimetro, ma non possono inviare risorse e dati al di fuori del perimetro. Questa limitazione contribuisce a impedire l'esfiltrazione di dati da parte di utenti malintenzionati interni che potrebbero avere accesso ai progetti nel perimetro.
• Le richieste provenienti dall'esterno del perimetro al servizio protetto vengono rispettate solo se soddisfano i criteri dei livelli di accesso assegnati al perimetro.
• Un servizio può essere reso accessibile ai progetti in altri perimetri utilizzando i bridge perimetrali.

Cripta le immagini container

In Google Cloud, puoi criptare le immagini container utilizzando chiavi di crittografia gestite dal cliente (CMEK). Le chiavi CMEK sono gestite in Cloud Key Management Service (Cloud KMS). Quando utilizzi CMEK, puoi disabilitare temporaneamente o definitivamente l'accesso a un'immagine container criptata disattivando o distruggendo la chiave.

Passaggi successivi

Scopri di più sulla protezione della catena di fornitura e della sicurezza delle applicazioni con le seguenti risorse:

• Gestisci gli obblighi di conformità (documento successivo di questa serie)
• Eccellenza operativa
• Autorizzazione binaria
• Analisi degli artefatti
• Artifact Registry

Gestione degli obblighi di conformità

Questo documento nel framework dell'architettura Google Cloud fornisce le best practice per la gestione degli obblighi di conformità.

I requisiti normativi del cloud dipendono da una combinazione di fattori, tra cui:

• Le leggi e le normative che regolano le località fisiche della tua organizzazione.
• Le leggi e le normative che si applicano alle località fisiche dei clienti.
• I requisiti normativi del tuo settore.

Questi requisiti determinano molte delle decisioni che devi prendere in merito ai controlli di sicurezza da attivare per i tuoi carichi di lavoro in Google Cloud.

Un tipico percorso di conformità passa attraverso tre fasi: valutazione, correzione delle lacune e monitoraggio continuo. Questa sezione descrive le best practice che puoi utilizzare in ogni fase.

Valuta le tue esigenze di conformità

La valutazione della conformità inizia con una revisione approfondita di tutti gli obblighi normativi e di come la tua azienda li sta implementando. Per aiutarti nella valutazione dei servizi Google Cloud, utilizza il Centro risorse per la conformità. Questo sito fornisce dettagli su quanto segue:

• Assistenza ai servizi per diverse normative
• Certificazioni e attestati Google Cloud

Puoi chiedere di collaborare con un esperto di conformità di Google per comprendere meglio il ciclo di vita della conformità in Google e come possono essere soddisfatti i tuoi requisiti.

Per ulteriori informazioni, consulta l'articolo Assicurare la conformità nel cloud (PDF).

Deployment di Assured Workloads

Assured Workloads è lo strumento di Google Cloud che si basa sui controlli di Google Cloud per aiutarti a rispettare gli obblighi di conformità. Assured Workloads ti consente di:

• Seleziona il tuo regime di conformità. Lo strumento quindi imposta automaticamente i controlli di accesso del personale di riferimento.
• Imposta la località per i dati utilizzando i criteri dell'organizzazione in modo che i dati at-rest e le risorse rimangano solo in quella regione.
• Seleziona l'opzione di gestione delle chiavi (ad esempio, il periodo di rotazione della chiave) più adatta ai tuoi requisiti di sicurezza e conformità.
• Per determinati requisiti normativi, come FedRAMP Moderate, seleziona i criteri per l'accesso da parte del personale dell'Assistenza Google (ad esempio, se hanno completato i controlli dei precedenti appropriati).
• Assicurati che le chiavi di crittografia gestite da Google siano conformi allo standard FIPS-140-2 e supportino la conformità FedRAMP Moderate. Per un ulteriore livello di controllo e separazione dei compiti, puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK). Per ulteriori informazioni sulle chiavi, consulta Criptare i dati.

Esaminare i progetti base per i modelli e le best practice applicabili al proprio regime di conformità.

Google ha pubblicato progetti e guide alle soluzioni che descrivono le best practice e forniscono moduli Terraform per implementare un ambiente che ti aiuta a raggiungere la conformità. La seguente tabella elenca una selezione di progetti per la sicurezza e l'allineamento con i requisiti di conformità.

Standard	Descrizione
PCI	Progetto di sicurezza: PCI su GKE Conformità allo standard PCI Data Security Limitazione dell'ambito di conformità per gli ambienti PCI in Google Cloud Conformità PCI DSS su GKE
FedRAMP	Guida all'implementazione di FedRAMP di Google Cloud (PDF) Configurazione di un carico di lavoro a tre livelli allineato FedRAMP su Google Cloud
HIPAA	Protezione dei dati sanitari su Google Cloud (PDF) Configurazione di un carico di lavoro allineato a HIPAA utilizzando il Data Protection Toolkit (PDF)

Monitorare la conformità

La maggior parte delle normative richiede di monitorare attività specifiche, inclusi i controlli dell'accesso. Per eseguire il monitoraggio, puoi utilizzare quanto segue:

• Access Transparency, che fornisce log quasi in tempo reale quando gli amministratori di Google Cloud accedono ai tuoi contenuti.
• Logging delle regole firewall per registrare le connessioni TCP e UDP all'interno di una rete VPC per le regole che crei personalmente. Questi log possono essere utili per controllare l'accesso alla rete o per avvisare tempestivamente che la rete viene utilizzata in un modo non approvato.
• Log di flusso VPC per registrare i flussi di traffico di rete inviati o ricevuti dalle istanze VM.
• Security Command Center Premium per monitorare la conformità a diversi standard.
• OSSEC (o un altro strumento open source) per registrare l'attività delle persone che hanno accesso amministrativo al tuo ambiente.
• Key Access Justifications per visualizzare i motivi di una richiesta di accesso alle chiavi.

Automatizza la conformità

Per aiutarti a rimanere conforme alle normative in continua evoluzione, determina se esistono modi per automatizzare i criteri di sicurezza incorporandoli nei deployment Infrastructure as Code. Ad esempio, considera quanto segue:

• Usa i progetti di sicurezza per integrare i criteri di sicurezza nelle tue distribuzioni dell'infrastruttura.

• Configurare Security Command Center per ricevere avvisi quando si verificano problemi di non conformità. Ad esempio, puoi monitorare eventuali problemi quali la disattivazione della verifica in due passaggi da parte degli utenti o gli account di servizio con privilegi in eccesso. Per ulteriori informazioni, consulta la sezione Configurare le notifiche sui risultati.

• Imposta la correzione automatica per determinate notifiche. Per saperne di più, vedi Codice di Cloud Functions.

Per ulteriori informazioni sull'automazione della conformità, consulta la pagina dedicata alla soluzione Risk and Compliance as Code (RCaC).

Passaggi successivi

Scopri di più sulla conformità con le seguenti risorse:

• Implementare i requisiti di residenza e sovranità dei dati (documento successivo di questa serie)
• Centro risorse per la conformità
• White paper sulla sicurezza di Google (PDF)
• Assured Workloads

Implementare i requisiti di residenza e sovranità dei dati

Questo documento nel framework dell'architettura Google Cloud fornisce le best practice per l'implementazione dei requisiti di residenza e sovranità dei dati.

I requisiti di residenza e sovranità dei dati si basano sulle normative regionali e specifiche di settore e diverse organizzazioni potrebbero avere requisiti di sovranità dei dati diversi. Ad esempio, potresti avere i seguenti requisiti:

• Controllo su tutti gli accessi ai tuoi dati da parte di Google Cloud, incluso il tipo di personale che può accedere ai dati e da quale regione può accedervi.
• Ispezionabilità delle modifiche all'infrastruttura e ai servizi cloud, che può avere un impatto sull'accesso ai dati o sulla sicurezza dei dati. Le informazioni su questi tipi di modifiche aiutano a garantire che Google Cloud non sia in grado di eludere i controlli o di spostare i tuoi dati fuori dalla regione.
• Sopravvivenza dei tuoi carichi di lavoro per un periodo di tempo prolungato quando non riesci a ricevere aggiornamenti software da Google Cloud.

Gestisci la sovranità dei dati

La sovranità dei dati fornisce un meccanismo per impedire a Google di accedere ai tuoi dati. Approvi l'accesso solo per i comportamenti del provider che accetti.

Ad esempio, puoi gestire la sovranità dei dati nei seguenti modi:

• Archivia e gestisci le chiavi di crittografia al di fuori del cloud.
• Concedi l'accesso a queste chiavi solo in base a giustificazioni dettagliate di accesso.
• Protezione dei dati in uso.

Gestisci la sovranità operativa

La sovranità operativa garantisce che il personale Google non possa compromettere i carichi di lavoro.

Ad esempio, puoi gestire la sovranità operativa nei seguenti modi:

• Limita il deployment delle nuove risorse a regioni specifiche del provider.
• Limitare l'accesso del personale Google in base ad attributi predefiniti come cittadinanza o posizione geografica.

Gestisci la sovranità del software

La sovranità del software ti garantisce che puoi controllare la disponibilità dei tuoi carichi di lavoro ed eseguirli ovunque, senza dipendere (o essere vincolati a) un singolo cloud provider. La sovranità del software include la capacità di sopravvivere a eventi che richiedono di modificare rapidamente il luogo in cui vengono distribuiti i carichi di lavoro e il livello di connessione esterna consentito.

Ad esempio, Google Cloud supporta deployment ibridi e multi-cloud. Inoltre, GKE Enterprise consente di gestire ed eseguire il deployment delle applicazioni sia in ambienti cloud che on-premise.

Controlla la residenza dei dati

La residenza dei dati indica dove sono archiviati i dati at-rest. I requisiti di residenza dei dati variano in base agli obiettivi di progettazione dei sistemi, alle preoccupazioni normative del settore, alla legge nazionale, alle implicazioni fiscali e persino alla cultura.

Il controllo della residenza dei dati inizia con il seguente comando:

• Comprendere il tipo di dati e la loro posizione.
• Determinare i rischi per i tuoi dati e quali leggi e normative si applicano.
• Controllare dove si trovano i dati o dove vanno a finire.

Per aiutarti a soddisfare i requisiti di localizzazione dei dati, Google Cloud ti consente di controllare dove vengono archiviati i tuoi dati, come vi accedono e come vengono elaborati. Puoi utilizzare i criteri sulla località delle risorse per limitare i luoghi di creazione delle risorse e quelli di replica dei dati tra regioni. Puoi utilizzare la proprietà relativa alla località di una risorsa per identificare dove viene eseguito il deployment del servizio e chi lo gestisce.

Per informazioni sulla supportabilità, consulta Servizi supportati per le località delle risorse.

Passaggi successivi

Scopri di più sulla residenza e sulla sovranità dei dati nelle seguenti risorse:

• Implementare i requisiti di privacy (documento successivo di questa serie)
• Residenza dei dati, trasparenza operativa e privacy per i clienti europei su Google Cloud (PDF)
• Progettare e implementare una strategia di sicurezza dei dati (PDF)
• Cloud Key Management Service
• Riservatezza dei dati del cliente garantita con Google Cloud (PDF)
• Accesso con privilegi in Google
• Trasparenza degli accessi di Google Cloud

Implementazione dei requisiti di privacy

Questo documento nel framework dell'architettura Google Cloud fornisce best practice per l'implementazione dei requisiti di privacy.

Le normative sulla privacy aiutano a definire il modo in cui puoi ottenere, elaborare, archiviare e gestire i dati degli utenti. Molti controlli per la privacy (ad esempio, i controlli per i cookie, la gestione delle sessioni e l'ottenimento dell'autorizzazione degli utenti) sono una responsabilità dell'utente in quanto i dati, compresi quelli che ricevi dagli utenti, sono di tua proprietà.

Google Cloud include i seguenti controlli che promuovono la privacy:

• Crittografia predefinita di tutti i dati inattivi, in transito e durante l'elaborazione.
• Misure di protezione contro l'accesso degli addetti ai lavori.
• Supporto di numerose normative sulla privacy.

Per ulteriori informazioni, consulta l'articolo sugli impegni di Google Cloud per la privacy.

Classificare i dati riservati

Devi definire quali dati sono riservati e quindi assicurarti che siano protetti adeguatamente. I dati riservati possono includere numeri di carte di credito, indirizzi, numeri di telefono e altre informazioni che consentono l'identificazione personale (PII).

Utilizzando Sensitive Data Protection, puoi configurare le classificazioni appropriate. Puoi quindi taggare e tokenizzare i dati prima di archiviarli in Google Cloud. Per saperne di più, consulta Classificare automaticamente i tuoi dati.

Bloccare l'accesso ai dati sensibili

Inserisci i dati sensibili nel perimetro di servizio utilizzando i Controlli di servizio VPC e imposta i controlli di accesso di Google Identity and Access Management (IAM) per tali dati. Configurare l'autenticazione a più fattori (MFA) per tutti gli utenti che richiedono l'accesso a dati sensibili.

Per maggiori informazioni, vedi Controllare lo spostamento dei dati tra i perimetri e Configurare SSO ed MFA.

Monitora gli attacchi di phishing

Assicurati che il tuo sistema email sia configurato in modo da proteggere dagli attacchi di phishing, spesso utilizzati per attività fraudolente e attacchi malware.

Se la tua organizzazione utilizza Gmail, puoi utilizzare la protezione avanzata da phishing e malware. Questa raccolta di impostazioni fornisce controlli per mettere in quarantena le email, difendersi dai tipi di allegati anomali e contribuisce a proteggere dalle email di spoofing in entrata. La sandbox per la sicurezza rileva il malware negli allegati. Gmail viene aggiornato continuamente e automaticamente con le protezioni e i miglioramenti della sicurezza più recenti per proteggere le email della tua organizzazione.

Estendi la sicurezza Zero Trust alla tua forza lavoro ibrida

Un modello di sicurezza Zero Trust implica che nessuno sia considerato attendibile implicitamente, sia all'interno che all'esterno della rete dell'organizzazione. Quando i sistemi IAM verificano le richieste di accesso, una strategia di sicurezza Zero Trust significa che vengono presi in considerazione l'identità e il contesto dell'utente, ad esempio l'indirizzo IP o la località. A differenza di una VPN, la sicurezza Zero Trust sposta i controlli di accesso dal perimetro della rete agli utenti e ai loro dispositivi. La sicurezza Zero Trust consente di lavorare in modo più sicuro. Ad esempio, gli utenti possono accedere alle risorse dell'organizzazione dai propri laptop o dispositivi mobili da casa.

Su Google Cloud, puoi configurare BeyondCorp Enterprise e Identity-Aware Proxy (IAP) per abilitare Zero Trust per le risorse Google Cloud. Se i tuoi utenti utilizzano Google Chrome e abiliti BeyondCorp Enterprise, puoi integrare la sicurezza Zero Trust nei browser degli utenti.

Passaggi successivi

Scopri di più su sicurezza e privacy nelle seguenti risorse:

• Implementare il logging e i controlli di rilevamento (documento successivo di questa serie)
• Centro sulla privacy

• Informativa sulla privacy di Google Cloud

• Best practice relative alla privacy quando si collabora con l'assistenza Google Cloud

• In che modo Google protegge la sicurezza e la privacy della tua organizzazione

• Domande frequenti sulla privacy

Implementazione dei controlli di logging e rilevamento

Questo documento nel framework dell'architettura Google Cloud fornisce le best practice per l'implementazione dei controlli di logging e rilevamento.

I controlli di rilevamento utilizzano la telemetria per rilevare errori di configurazione, vulnerabilità e attività potenzialmente dannose in un ambiente cloud. Google Cloud ti consente di creare monitoraggio e controlli di rilevamento su misura per il tuo ambiente. Questa sezione descrive queste funzionalità aggiuntive e i consigli per il loro utilizzo.

Monitorare le prestazioni della rete

Network Intelligence Center ti offre visibilità sulle prestazioni della topologia e dell'architettura di rete. Puoi ottenere insight dettagliati sulle prestazioni della rete e utilizzare queste informazioni per ottimizzare il deployment eliminando i colli di bottiglia dei servizi. Connectivity Tests fornisce insight sulle regole e sui criteri firewall applicati al percorso di rete.

Monitorare e prevenire l'esfiltrazione dei dati.

L’esfiltrazione dei dati è una preoccupazione fondamentale per le organizzazioni. In genere, ciò si verifica quando una persona autorizzata estrae i dati da un sistema protetto e poi li condivide con una parte non autorizzata o li sposta in un sistema non sicuro.

Google Cloud offre funzionalità e strumenti utili per rilevare e prevenire l'esfiltrazione di dati. Per ulteriori informazioni, consulta Prevenire l'esfiltrazione di dati.

Centralizza il monitoraggio

Security Command Center offre visibilità sulle risorse disponibili in Google Cloud e sul relativo stato di sicurezza. Security Command Center consente di prevenire, rilevare e rispondere alle minacce. Fornisce una dashboard centralizzata che puoi utilizzare per identificare gli errori di configurazione della sicurezza nelle macchine virtuali, nelle reti, nelle applicazioni e nei bucket di archiviazione. Puoi risolvere questi problemi prima che causino danni o perdite all'azienda. Le funzionalità integrate di Security Command Center possono rilevare le attività sospette nei log di sicurezza di Cloud Logging o indicare macchine virtuali compromesse.

Puoi rispondere alle minacce seguendo suggerimenti attuabili o esportando i log nel tuo sistema SIEM per ulteriori indagini. Per informazioni sull'utilizzo di un sistema SIEM con Google Cloud, consulta Analisi dei log di sicurezza in Google Cloud.

Security Command Center fornisce inoltre più rilevatori che ti aiutano ad analizzare la sicurezza della tua infrastruttura. Questi rilevatori includono:

• Rilevamento delle minacce agli eventi
• SHA (Security Health Analytics)
• Servizio Azioni sensibili

Anche altri servizi Google Cloud, come i log di Google Cloud Armor, forniscono risultati da visualizzare in Security Command Center.

Abilita i servizi necessari per i carichi di lavoro, quindi monitora e analizza solo i dati importanti. Per ulteriori informazioni sull'abilitazione dei log per i servizi, consulta la sezione Abilitare i log in Analisi dei log di sicurezza in Google Cloud.

Monitora le minacce

Event Threat Detection è un servizio gestito facoltativo di Security Command Center Premium che rileva le minacce nel flusso di log. Con Event Threat Detection, puoi rilevare minacce costose e ad alto rischio come malware, cryptomining, accessi non autorizzati alle risorse Google Cloud, attacchi DDoS e attacchi di forza bruta SSH. Utilizzando le funzionalità dello strumento per sintetizzare volumi di dati di log, i team di sicurezza possono identificare rapidamente gli incidenti ad alto rischio e concentrarsi sulle attività di remediation.

Per contribuire a rilevare gli account utente potenzialmente compromessi nella tua organizzazione, utilizza i log di Cloud Platform per le azioni sensibili per identificare quando vengono intraprese azioni sensibili e per verificare che utenti validi abbiano eseguito tali azioni per scopi validi. Un'azione sensibile è un'azione, come l'aggiunta di un ruolo altamente privilegiato, che potrebbe danneggiare la tua attività se un autore malintenzionato prendesse l'azione. Utilizza Cloud Logging per visualizzare, monitorare ed eseguire query sui log di Sensitive Actions Cloud Platform. Puoi inoltre visualizzare le voci di log delle azioni sensibili con il Servizio Azioni sensibili, un servizio integrato di Security Command Center Premium.

Chronicle può archiviare e analizzare tutti i tuoi dati di sicurezza a livello centralizzato. Per aiutarti a vedere l'intera durata di un attacco, Chronicle può mappare i log in un modello comune, arricchirli e poi collegarli tra loro in cronologie. Inoltre, puoi utilizzare Chronicle per creare regole di rilevamento, configurare la corrispondenza degli indicatori di compromissione (IoC) ed eseguire attività di ricerca delle minacce. Le regole di rilevamento devono essere scritte nella lingua YARA-L. Per esempi di regole di rilevamento delle minacce in YARA-L, consulta il repository Community Security Analytics (CSA). Oltre a scrivere le tue regole, puoi sfruttare i rilevamenti selezionati in Chronicle. Questi rilevamenti selezionati sono un insieme di regole YARA-L predefinite e gestite che possono aiutarti a identificare le minacce.

Un'altra opzione per centralizzare i log per l'analisi della sicurezza, il controllo e l'indagine è l'utilizzo di BigQuery. In BigQuery puoi monitorare le minacce o gli errori di configurazione più comuni utilizzando query SQL (come quelle nel repository CSA) per analizzare le modifiche delle autorizzazioni, l'attività di provisioning, l'utilizzo dei carichi di lavoro, l'accesso ai dati e l'attività di rete. Per ulteriori informazioni sull'analisi dei log di sicurezza in BigQuery, dalla configurazione all'analisi, consulta Analisi dei log di sicurezza in Google Cloud.

Il seguente diagramma mostra come centralizzare il monitoraggio utilizzando sia le funzionalità integrate di rilevamento delle minacce di Security Command Center sia il rilevamento delle minacce eseguito in BigQuery, Chronicle o in una soluzione SIEM di terze parti.

Come mostrato nel diagramma, esistono diverse origini dati per la sicurezza che devi monitorare. Queste origini dati includono log di Cloud Logging, modifiche agli asset provenienti da Cloud Asset Inventory, log di Google Workspace o eventi provenienti da hypervisor o da un kernel guest. Il diagramma mostra che puoi utilizzare Security Command Center per monitorare queste origini dati. Questo monitoraggio viene eseguito automaticamente a condizione che tu abbia abilitato le funzionalità e i rilevatori di minacce appropriati in Security Command Center. Il diagramma mostra che puoi anche monitorare le minacce esportando i dati sulla sicurezza e i risultati di Security Command Center in uno strumento di analisi come BigQuery, Chronicle o SIEM di terze parti. Nel tuo strumento di analisi, il diagramma mostra che puoi eseguire ulteriori analisi e indagini utilizzando ed estendendo query e regole come quelle disponibili in CSA.

Passaggi successivi

Scopri di più su logging e rilevamento con le seguenti risorse:

• Cloud Logging

• Introduzione a Chronicle Detect di Google Cloud

• Crea un processo collaborativo di gestione degli incidenti

Framework dell'architettura Google Cloud: affidabilità

Questa categoria nel framework dell'architettura Google Cloud mostra come progettare e utilizzare servizi affidabili su una piattaforma cloud. Scoprirai inoltre alcuni dei prodotti e delle funzionalità di Google Cloud che supportano l'affidabilità.

Il framework dell'architettura descrive le best practice, fornisce consigli per l'implementazione e spiega alcuni dei prodotti e servizi disponibili. Il framework mira ad aiutarti a progettare il deployment di Google Cloud in modo che soddisfi al meglio le tue esigenze aziendali.

Per eseguire un servizio affidabile, la tua architettura deve includere quanto segue:

• Obiettivi di affidabilità misurabili, con deviazioni che correggi tempestivamente.
• Pattern di progettazione per scalabilità, alta disponibilità, ripristino di emergenza e gestione automatizzata dei cambiamenti.
• Componenti che si correggono autonomamente, ove possibile, e codice che include la strumentazione per l'osservabilità.
• Procedure operative che eseguono il servizio con lavoro manuale e carico cognitivo minimo sugli operatori, consentendo di rilevare e mitigare rapidamente gli errori.

L'affidabilità è una responsabilità di tutti gli addetti all'ingegneria, quali lo sviluppo, la gestione dei prodotti, le operazioni e i team SRE (Site Reliability Engineering). Tutti devono essere responsabili e comprendere gli obiettivi di affidabilità dell'applicazione e i budget di rischio ed errore. I team devono essere in grado di stabilire le priorità del lavoro in modo appropriato e di riassegnare i conflitti di priorità tra affidabilità e sviluppo delle funzionalità del prodotto.

Nella categoria di affidabilità del framework dell'architettura, imparerai a fare quanto segue:

• Informazioni sui principi di base dell'affidabilità
• Definisci i tuoi obiettivi di affidabilità
• Definire gli SLO
• Adotta gli SLO
• Integra l'osservabilità nell'infrastruttura e nell'applicazione
• Progetta per la scalabilità e la disponibilità elevata
• Crea processi operativi e strumenti affidabili
• Crea avvisi efficienti
• Crea un processo collaborativo di gestione degli incidenti

Principi di affidabilità

Questo documento nel framework dell'architettura illustra alcuni dei principi fondamentali per eseguire servizi affidabili su una piattaforma cloud. Questi principi aiutano a comprendere meglio le sezioni aggiuntive del Framework dell'architettura che mostrano come alcuni prodotti e funzionalità di Google Cloud supportano servizi affidabili.

Terminologia chiave

Esistono diversi termini comuni associati alle pratiche di affidabilità. Questi potrebbero essere familiari a molti lettori. Tuttavia, per un ripasso, consulta le descrizioni dettagliate alla pagina Terminologia.

Principi fondamentali

L'approccio di Google all'affidabilità si basa sui seguenti principi fondamentali.

L'affidabilità è la tua funzionalità principale

Le nuove funzionalità dei prodotti sono a volte la tua principale priorità nel breve periodo. Tuttavia, l'affidabilità è la principale caratteristica del prodotto sul lungo periodo perché, se il prodotto è troppo lento o non è disponibile per un lungo periodo di tempo, gli utenti potrebbero abbandonarlo, rendendo le altre funzionalità del prodotto non pertinenti.

L'affidabilità viene definita dall'utente

Per i carichi di lavoro rivolti agli utenti, misura l'esperienza utente. L'utente deve essere soddisfatto delle prestazioni del tuo servizio. Ad esempio, misura la percentuale di successo delle richieste degli utenti, non solo le metriche del server.

Per i carichi di lavoro in modalità flusso e batch, potrebbe essere necessario misurare gli indicatori chiave di prestazione (KPI) per la velocità effettiva dei dati, ad esempio le righe analizzate per finestra temporale, anziché le metriche del server come l'utilizzo del disco. I KPI per la velocità effettiva consentono di assicurare che un report giornaliero o trimestrale richiesto dall'utente venga completato in tempo.

L'affidabilità al 100% non è l'obiettivo corretto

I tuoi sistemi dovrebbero essere abbastanza affidabili da far sì che gli utenti siano soddisfatti, ma non eccessivamente affidabili da far sì che l'investimento sia ingiustificato. Definisci gli SLO che impostano la soglia di affidabilità desiderata, poi utilizza i budget di errore per gestire il tasso di modifica appropriato.

Applica a un prodotto i principi di progettazione e operativi di questo framework solo se lo SLO per il prodotto o l'applicazione giustifica il costo.

Affidabilità e innovazione rapida sono complementari

Utilizza i budget di errore per raggiungere un equilibrio tra stabilità del sistema e agilità dello sviluppatore. Le indicazioni seguenti ti aiutano a determinare quando muoverti velocemente o lentamente:

• Quando è disponibile un budget di errore adeguato, puoi innovare rapidamente e migliorare il prodotto o aggiungere funzionalità del prodotto.
• Quando il budget di errore viene ridotto, rallenta e concentrati sulle funzionalità di affidabilità.

Principi di progettazione e operativi

Per massimizzare l'affidabilità del sistema, si applicano i seguenti principi operativi e di progettazione. Ciascuno di questi principi è discusso in dettaglio nel resto della categoria di affidabilità del framework dell'architettura.

Definisci i tuoi obiettivi di affidabilità

Le best practice descritte in questa sezione del framework dell'architettura includono quanto segue:

• Scegli gli SLI appropriati.
• Imposta gli SLO in base all'esperienza utente.
• Migliora gli SLO in modo iterativo.
• Utilizza SLO interni rigidi.
• Usa i budget di errore per gestire la velocità di sviluppo.

Per maggiori informazioni, consulta Definire gli obiettivi di affidabilità nella categoria di affidabilità del framework dell'architettura.

Integra funzioni di osservabilità nell'infrastruttura e nelle applicazioni

Il seguente principio di progettazione è trattato in questa sezione del framework dell'architettura:

• Instrumenta il tuo codice per massimizzare l'osservabilità.

Per maggiori informazioni, consulta Integrare l'osservabilità nell'infrastruttura e nelle applicazioni nella categoria Affidabilità del framework dell'architettura.

Progetta per la scalabilità e la disponibilità elevata

In questa sezione del framework dell'architettura vengono trattati i seguenti principi di progettazione:

• Crea ridondanza per una maggiore disponibilità.
• Replica i dati tra le regioni per il ripristino di emergenza.
• Progetta un'architettura multiregionale per la resilienza alle interruzioni regionali.
• Elimina i colli di bottiglia della scalabilità.
• Esegui la riduzione controllata dei livelli di servizio in caso di sovraccarico.
• Previeni e attenua i picchi di traffico.
• Elimina e convalida gli input.
• Fail Safe in modo da preservare il funzionamento.
• Progetta chiamate API e comandi operativi in modo che siano ripetibili.
• Identifica e gestisci le dipendenze di sistema.
• Riduci al minimo le dipendenze critiche.
• Assicurati che si possa eseguire il rollback di ogni modifica.

Per ulteriori informazioni, consulta Progettare per la scalabilità e la disponibilità elevata nella categoria di affidabilità del framework dell'architettura.

Crea processi operativi e strumenti affidabili

In questa sezione del framework dell'architettura vengono trattati i seguenti principi operativi:

• Scegli nomi appropriati per applicazioni e servizi.
• Implementare implementazioni progressiva con procedure di test canary.
• Diffondi il traffico per promozioni e lanci a tempo.
• Automatizza il processo di creazione, test e deployment.
• Difenditi dall'errore dell'operatore.
• Testa le procedure di ripristino da errori.
• Esegui test di ripristino di emergenza.
• Esercitati con l'ingegneria del caos.

Per maggiori informazioni, consulta Creare processi e strumenti operativi affidabili nella categoria di affidabilità del framework dell'architettura.

Creazione di avvisi efficienti

In questa sezione del framework dell'architettura vengono trattati i seguenti principi operativi:

• Ottimizza il ritardo di avviso.
• Definisci gli avvisi in base ai sintomi non alle cause.
• Definisci gli avvisi sui valori anomali, non sui valori medi.

Per maggiori informazioni, consulta Creare avvisi efficienti nella categoria di affidabilità del framework dell'architettura.

Costruisci un processo collaborativo di gestione degli incidenti

In questa sezione del framework dell'architettura vengono trattati i seguenti principi operativi:

• Assegna una chiara proprietà del servizio.
• Riduci il tempo di rilevamento (TTD) con avvisi ottimizzati.
• Riduci i tempi di mitigazione (TTM) con piani di gestione e formazione per la gestione degli incidenti.
• Progetta layout e contenuti della dashboard per ridurre al minimo il tempo di attenuazione.
• Documentare le procedure diagnostiche e la mitigazione per scenari di interruzione noti.
• Usare dati post-mortem senza colpa per apprendere dalle interruzioni ed evitare che si ripetano.

Per maggiori informazioni, consulta Creare un processo collaborativo di gestione degli incidenti nella categoria di affidabilità del framework dell'architettura.

Passaggi successivi

• Definisci i tuoi obiettivi di affidabilità (prossimo documento di questa serie)

Esplora altre categorie nel framework dell'architettura come progettazione del sistema, eccellenza operativa, sicurezza, privacy e conformità.

Definisci i tuoi obiettivi di affidabilità

Questo documento nel framework dell'architettura Google Cloud fornisce best practice per definire modi appropriati per misurare l'esperienza cliente dei tuoi servizi in modo da poter eseguire servizi affidabili. Imparerai a eseguire l'iterazione degli obiettivi del livello di servizio (SLO) che definisci e a utilizzare i budget di errore per capire quando l'affidabilità potrebbe risentirne se rilasci ulteriori aggiornamenti.

Scegliere SLI appropriati

È importante scegliere indicatori del livello del servizio (SLI) appropriati per comprendere appieno le prestazioni del servizio. Ad esempio, se l'applicazione ha un'architettura multi-tenant tipica delle applicazioni SaaS utilizzate da più clienti indipendenti, acquisisci gli SLI a livello di tenant. Se gli SLI vengono misurati solo a livello aggregato globale, potresti non vedere problemi critici nell'applicazione che interessano un singolo cliente importante o una minoranza di clienti. Progetta invece l'applicazione in modo da includere un identificatore tenant in ogni richiesta dell'utente, quindi propaga l'identificatore a ogni livello dello stack. Questo identificatore consente al sistema di monitoraggio di aggregare statistiche a livello di tenant a ogni livello o microservizio lungo il percorso di richiesta.

Il tipo di servizio che esegui determina anche quali SLI monitorare, come mostrato negli esempi seguenti.

Sistemi di pubblicazione

I seguenti SLI sono tipici nei sistemi che gestiscono i dati:

• La disponibilità indica la frazione di tempo in cui un servizio è utilizzabile. Viene spesso definito in termini di frazione di richieste in formato corretto che hanno avuto esito positivo, ad esempio il 99%.
• La latenza indica la velocità con cui è possibile soddisfare una determinata percentuale di richieste. Viene spesso definito in termini di un percentile diverso dal 50°, ad esempio "99° percentile a 300 ms".
• Qualità indica la qualità di una determinata risposta. La definizione di qualità è spesso specifica per il servizio e indica in quale misura il contenuto della risposta a una richiesta varia rispetto al contenuto ideale della risposta. La qualità della risposta può essere binaria (buona o negativa) o espressa su una scala da 0% a 100%.

Sistemi di trattamento dati

I seguenti SLI sono tipici nei sistemi che elaborano i dati:

• Copertura indica la frazione di dati elaborati, ad esempio 99,9%.
• Il valore Correttezza indica la frazione dei dati di output considerata corretta, ad esempio 99,99%.
• Aggiornamento indica il grado di aggiornamento dei dati di origine o dei dati di output aggregati. Generalmente è l'aggiornamento più recente, meglio è, ad esempio, 20 minuti.
• La velocità effettiva indica la quantità di dati che vengono elaborati, ad esempio 500 MiB/sec o persino 1000 richieste al secondo (RPS).

Sistemi di archiviazione

I seguenti SLI sono tipici nei sistemi che archiviano i dati:

• Durabilità indica con quale probabilità i dati scritti nel sistema possono essere recuperati in futuro, ad esempio il 99,9999%. Qualsiasi incidente permanente di perdita di dati riduce la metrica di durabilità.
• Velocità effettiva e latenza sono anche SLI comuni per i sistemi di archiviazione.

Scegli gli SLI e imposta gli SLO in base all'esperienza utente

Uno dei principi fondamentali in questa sezione del framework dell'architettura è che l'affidabilità è definita dall'utente. Misura le metriche di affidabilità il più vicino possibile all'utente, ad esempio le seguenti opzioni:

• Se possibile, implementa il client web o mobile.
  • Ad esempio, utilizza il monitoraggio delle prestazioni di Firebase per ottenere insight sulle caratteristiche delle prestazioni delle tue app per iOS, Android e web.
• Se questo non è possibile, configura il bilanciatore del carico.
  • Ad esempio, utilizza Cloud Monitoring per il logging e il monitoraggio del bilanciatore del carico delle applicazioni esterno.
• Una misura dell'affidabilità sul server dovrebbe essere l'ultima opzione.
  • Ad esempio, monitora un'istanza di Compute Engine con Cloud Monitoring.

Imposta il tuo SLO in modo che sia abbastanza alto da far sì che quasi tutti gli utenti siano soddisfatti del tuo servizio e non oltre. A causa della connettività di rete o di altri problemi temporanei sul lato client, i clienti potrebbero non notare brevi problemi di affidabilità nell'applicazione, il che ti consente di ridurre lo SLO.

Per l'uptime e altre metriche fondamentali, punta a un target inferiore al 100%, ma vicino. I proprietari dei servizi dovrebbero valutare oggettivamente il livello minimo di prestazioni e disponibilità dei servizi che renderebbero felici la maggior parte degli utenti, non solo impostare obiettivi in base ai livelli contrattuali esterni.

La frequenza della modifica influisce sull'affidabilità del sistema. Tuttavia, la possibilità di apportare modifiche frequenti e di piccola entità ti consente di offrire funzionalità più rapidamente e con una qualità superiore. Gli obiettivi di affidabilità raggiungibili ottimizzati sulla customer experience aiutano a definire il ritmo e l'ambito massimi delle modifiche (velocità delle funzionalità) che i clienti possono tollerare.

Se non puoi misurare la customer experience e definire i relativi obiettivi, puoi eseguire un'analisi di benchmark della concorrenza. Se non esiste una concorrenza paragonabile, misura la customer experience, anche se non puoi ancora definire obiettivi. Ad esempio, puoi misurare la disponibilità del sistema o il tasso di transazioni significative e riuscite per il cliente. Puoi correlare questi dati con metriche o KPI aziendali come il volume degli ordini nella vendita al dettaglio o il volume delle chiamate e delle richieste di assistenza clienti e la relativa gravità. Durante un periodo di tempo, puoi utilizzare questi esercizi di correlazione per raggiungere una soglia ragionevole di soddisfazione del cliente. Questa soglia è il tuo SLO.

Migliora gli SLO in modo iterativo

Gli SLO non devono essere stabili. Rivedi gli SLO trimestralmente o almeno una volta all'anno e verifica che continuino a riflettere con precisione il livello di soddisfazione degli utenti e che siano ben correlate alle interruzioni del servizio. Assicurati che coprano le attuali esigenze aziendali e i nuovi percorsi degli utenti critici. Rivedi e aumenta i tuoi SLO in base alle esigenze dopo queste revisioni periodiche.

Usa SLO interni rigorosi

È buona norma avere SLO interni più rigidi rispetto agli SLA esterni. Poiché le violazioni dello SLA (accordo sul livello del servizio) tendono a richiedere l'emissione di un credito finanziario o rimborsi ai clienti, è consigliabile risolvere i problemi prima che abbiano un impatto finanziario.

Ti consigliamo di utilizzare questi SLO interni più rigidi con un processo post mortem senza colpa e revisioni degli incidenti. Per maggiori informazioni, consulta Creare un processo collaborativo di gestione degli incidenti nella categoria di affidabilità del Centro architetture.

Utilizza i budget di errore per gestire la velocità di sviluppo

I budget di errore indicano se il tuo sistema è più o meno affidabile di quanto necessario in un determinato periodo di tempo. I budget di errore vengono calcolati come 100% - SLO per un periodo di tempo, ad esempio 30 giorni.

Quando il budget di errore contiene ancora della capacità, puoi continuare ad implementare miglioramenti o nuove funzionalità rapidamente. Quando il budget di errore è vicino a zero, blocca o rallenta le modifiche al servizio e investi in risorse tecniche per migliorare le funzionalità di affidabilità.

L'osservabilità di Google Cloud include il monitoraggio degli SLO per ridurre al minimo l'impegno per la configurazione di SLO e budget di errore. I servizi includono una Graphic User Interface che consente di configurare gli SLO manualmente, un'API per la configurazione programmatica degli SLO e dashboard integrate per monitorare la burn rate del budget di errore. Per maggiori informazioni, scopri come creare uno SLO.

Suggerimenti

Per applicare al tuo ambiente le indicazioni contenute nel framework dell'architettura, segui questi suggerimenti:

• Definisci e misura gli SLI incentrati sul cliente, come la disponibilità o la latenza del servizio.
• Definisci un budget di errore incentrato sul cliente più rigoroso di quello dello SLA (accordo sul livello del servizio) esterno. Includere le conseguenze per le violazioni, come il blocco della produzione.
• Configura gli SLI di latenza per acquisire valori anomali, come il 90° o il 99° percentile, per rilevare le risposte più lente.
• Esamina gli SLO almeno una volta l'anno e conferma che siano adeguatamente correlati alla soddisfazione degli utenti e alle interruzioni del servizio.

Passaggi successivi

Scopri di più su come definire gli obiettivi di affidabilità con le seguenti risorse:

• Integra l'osservabilità nell'infrastruttura e nell'applicazione (prossimo documento di questa serie)
• Coursera - SRE: misurazione e gestione dell'affidabilità
• SLO dei capitoli del libro SRE e foglio di lavoro SRE per implementare gli SLO
• Ottimizzare le metriche SLI

Esplora altre categorie nel framework dell'architettura, come progettazione del sistema, eccellenza operativa e sicurezza, privacy e conformità.

Definisci gli SLO

Questo documento è la Parte 1 di due parti che mostrano in che modo i team che gestiscono servizi online possono iniziare a creare e adottare una cultura di Site Reliability Engineering (SRE) utilizzando gli obiettivi del livello di servizio (SLO). Uno SLO è un livello target di affidabilità per un servizio.

Nel Software as a Service (SaaS), esiste una tensione naturale tra la velocità di sviluppo del prodotto e la stabilità operativa. Più cambi il sistema, più è probabile che si rompa. Gli strumenti di monitoraggio e osservabilità possono aiutarti a mantenere la fiducia nella stabilità operativa man mano che aumenti la velocità di sviluppo. Tuttavia, sebbene questi strumenti, noti anche come strumenti di gestione delle prestazioni delle applicazioni (APM), siano importanti, una delle applicazioni più importanti di questi strumenti è l'impostazione degli SLO.

Se definito correttamente, uno SLO può aiutare i team a prendere decisioni operative basate sui dati che aumentano la velocità di sviluppo senza sacrificare la stabilità. Lo SLO può anche allineare i team operativi e di sviluppo intorno a un unico obiettivo concordato, che può ridurre la tensione naturale esistente tra i loro scopi, ovvero la creazione e l'iterazione dei prodotti (sviluppo) e il mantenimento dell'integrità del sistema (operazioni).

Gli SLO sono descritti in dettaglio in The SRE Book e The SRE Workbook, insieme ad altre pratiche SRE. Questa serie tenta di semplificare il processo di comprensione e sviluppo degli SLO per adottarli più facilmente. Dopo aver letto e compreso questi articoli, puoi trovare ulteriori informazioni nei libri.

Questa serie mira a mostrarti un percorso chiaro per implementare gli SLO nella tua organizzazione:

• Questo documento esamina gli SLO e come definirli per i tuoi servizi.
• L'adozione degli SLO copre diversi tipi di SLO in base ai tipi di carichi di lavoro, a come misurare questi SLO e a come sviluppare avvisi basati su questi SLO.

Questa serie è rivolta a SRE, team operativi, DevOps, amministratori di sistema e altri soggetti responsabili della stabilità e dell'affidabilità di un servizio online. Presuppone che tu abbia una conoscenza di come i servizi internet comunicano con browser web e dispositivi mobili e che tu abbia una conoscenza di base delle modalità di monitoraggio, deployment e risoluzione dei problemi dei servizi web.

Lo stato State of DevOps segnala le funzionalità identificate che favoriscono le prestazioni relative alla distribuzione del software. Questa serie ti aiuterà con le seguenti funzionalità:

• Monitoraggio e osservabilità
• Monitorare i sistemi per prendere decisioni aziendali oculate
• Notifica proattiva degli errori

Perché gli SLO?

Quando crei una cultura dell'SRE, perché iniziare con gli SLO? In breve, se non definisci un livello di servizio, è difficile misurare se i clienti sono soddisfatti del servizio. Anche se sai di poter migliorare il tuo servizio, la mancanza di un livello di servizio definito rende difficile determinare dove e quanto investire in miglioramenti.

Si può avere la tentazione di sviluppare SLO separati per ogni servizio, rivolto agli utenti o meno. Ad esempio, un errore comune consiste nel misurare due o più servizi separatamente, ad esempio un servizio di frontend e un datastore di backend, quando l'utente si basa su entrambi i servizi e non è a conoscenza della distinzione. Un approccio migliore consiste nello sviluppare SLO basati sul prodotto (la raccolta di servizi) e concentrarsi sulle interazioni più importanti degli utenti con il prodotto.

Di conseguenza, per sviluppare uno SLO efficace, l'ideale è comprendere le interazioni degli utenti con il tuo servizio, chiamate percorsi dell'utente critici (CUJ). Un CUJ prende in considerazione gli obiettivi dei tuoi utenti e il modo in cui utilizzano i tuoi servizi per raggiungere questi obiettivi. Il CUJ viene definito dal punto di vista del cliente, senza tenere conto dei limiti dei servizi. Se il CUJ viene soddisfatto, il cliente è soddisfatto e la soddisfazione dei clienti è un parametro fondamentale del successo di un servizio.

Un aspetto chiave per la soddisfazione dei clienti di un servizio è l'affidabilità del servizio. Non importa cosa fa un servizio se non è affidabile. Pertanto, l'affidabilità è la caratteristica più importante di qualsiasi servizio. Una metrica comune per l'affidabilità è il tempo di attività, che in modo convenzionale indica per quanto tempo un sistema è stato attivo. Tuttavia, preferiamo una metrica più utile e precisa: disponibilità. La funzionalità Disponibilità risponde comunque alla domanda se un sistema sia attivo, ma in modo più preciso rispetto alla misurazione del tempo trascorso da un sistema non attivo. Nei sistemi distribuiti odierni, i servizi possono risultare parzialmente inattivi, un fattore per cui l'uptime non va bene.

La disponibilità è spesso descritta in termini di nove, ad esempio il 99,9% di disponibilità (tre nove) o il 99,99% di disponibilità (quattro nove). Misurare uno SLO di disponibilità è uno dei modi migliori per misurare l'affidabilità del tuo sistema.

Oltre a definire il successo operativo, uno SLO può aiutarti a scegliere dove investire le risorse. Ad esempio, i libri di SRE spesso notano che ogni nove per cui lavori può comportare un costo incrementale con utilità marginale. Generalmente è risaputo che raggiungere i nove di disponibilità successivi costa dieci volte di più del precedente.

Scegli uno SLI

Per determinare se uno SLO è soddisfatto (ovvero se è riuscito), hai bisogno di una misurazione. Questa misurazione è chiamata indicatore del livello del servizio (SLI). Uno SLI misura il livello di un particolare servizio che offri al cliente. Idealmente, lo SLI è legato a un CUJ accettato.

Seleziona le metriche migliori

Il primo passaggio per lo sviluppo di uno SLI è scegliere una metrica da misurare, ad esempio richieste al secondo, errori al secondo, lunghezza delle code, la distribuzione dei codici di risposta in un determinato periodo di tempo o il numero di byte trasmessi.

Queste metriche tendono a essere i seguenti:

• Contatore. Ad esempio, il numero di errori che si sono verificati fino a un determinato punto di misurazione. Questo tipo di metrica può aumentare, ma non diminuire.
• Distribuzione. Ad esempio, il numero di eventi che completano un determinato segmento di misurazione per un determinato periodo di tempo. Puoi misurare quante richieste impiegano da 0 a 10 ms per essere completate, quante ne impiegano in 11-30 ms e quante ne impiegano in 31-100 ms. Il risultato è un conteggio per ogni bucket, ad esempio [0-10: 50], [11-30: 220], [31-100: 1103].
• Misura. Ad esempio, il valore effettivo di una parte misurabile del sistema (come la lunghezza della coda). Questo tipo di metrica può aumentare o diminuire.

Per ulteriori informazioni su questi tipi, consulta la documentazione relativa al progetto Prometheus e i tipi di metriche di Cloud Monitoring ValueType e MetricKind.

Una distinzione importante relativa agli SLI è che non tutte le metriche sono SLI. Infatti, il foglio di lavoro SRE stabilisce quanto segue (enfasi aggiunta):

"...in genere consigliamo di considerare lo SLI come il rapporto tra due numeri: il numero di eventi validi diviso per il numero totale di eventi..."

"Lo SLI va da 0% a 100%, dove 0% significa che non funziona nulla e 100% significa che non si rompe. Abbiamo trovato intuitiva questa scala e questo stile si adatta facilmente al concetto di budget di errore."

Molte aziende produttrici di software monitorano centinaia o migliaia di metriche; solo poche metriche sono considerate SLI. Oltre al rapporto tra eventi positivi e eventi totali, cosa definisce una metrica come un buon SLI? Una metrica SLI efficace ha le seguenti caratteristiche:

• La metrica è direttamente correlata alla soddisfazione degli utenti. Generalmente, gli utenti non sono soddisfatti se un servizio non si comporta come previsto, non funziona o è lento. Qualsiasi SLO basato su queste metriche può essere convalidato confrontando il tuo SLI con altri indicatori di soddisfazione degli utenti, ad esempio il numero di ticket di reclamo dei clienti, il volume di chiamate di assistenza, il feedback sui social media o le riassegnazioni. Se la tua metrica non corrisponde a queste altre metriche relative alla soddisfazione degli utenti, potrebbe non essere una buona metrica da usare come SLI.
• Il deterioramento delle metriche è correlato alle interruzioni. Una metrica che sembra corretta durante un'interruzione è quella sbagliata per uno SLI. Una metrica che non funziona durante il normale funzionamento è anche quella sbagliata per uno SLI.
• La metrica fornisce un buon rapporto segnale-rumore. Qualsiasi metrica che generi un numero elevato di falsi negativi o falsi positivi non è uno SLI valido.
• La metrica scala in modo monotonico e circa lineare, con la soddisfazione dei clienti. Man mano che la metrica migliora, la soddisfazione dei clienti aumenta.

Considera i grafici nel seguente diagramma. Nel tempo vengono rappresentate graficamente due metriche che possono essere utilizzate come SLI per un servizio. Il periodo in cui un servizio si deteriora è evidenziato in rosso, mentre il periodo in cui un servizio è buono è evidenziato in blu.

Nel caso di uno SLI non valido, l'infelicità dell'utente non corrisponde direttamente a un evento negativo (come un degrado del servizio, una lentezza o un'interruzione del servizio). Inoltre, lo SLI varia indipendentemente dalla soddisfazione dell'utente. Con uno SLI buono, lo SLI e la felicità dell'utente sono correlati, i diversi livelli di felicità sono chiari e ci sono molte meno fluttuazioni irrilevanti.

Seleziona il numero giusto di metriche

Di solito, un singolo servizio ha più SLI, soprattutto se il servizio esegue tipi di lavoro diversi o serve tipi diversi di utenti. Ad esempio, è consigliabile separare le richieste di lettura dalle richieste di scrittura, poiché queste richieste tendono ad agire in modi diversi. In questo caso, è meglio selezionare le metriche appropriate per ciascun servizio.

Al contrario, molti servizi eseguono tipi di attività simili all'interno di tutti i servizi, che possono essere direttamente paragonabili. Ad esempio, se hai un marketplace online, gli utenti potrebbero visualizzare una home page, una sottocategoria o un elenco dei primi 10, visualizzare una pagina dei dettagli o cercare elementi. Anziché sviluppare e misurare uno SLI separato per ciascuna di queste azioni, puoi combinarli in un'unica categoria SLI, ad esempio Esplora i servizi.

In realtà, le aspettative di un utente non cambiano molto tra un'azione di una categoria simile e l'altra. La loro soddisfazione non dipende dalla struttura dei dati che stanno sfogliando, dal fatto che i dati provengano da un elenco statico di elementi promossi o dal risultato generato dinamicamente di una ricerca assistita dal machine learning su un enorme set di dati. La loro felicità è quantificabile da una risposta a una domanda: "Ho visto velocemente una pagina intera di articoli?"

Idealmente, sarebbe preferibile utilizzare il minor numero possibile di SLI per rappresentare con precisione le tolleranze di un determinato servizio. In genere, un servizio dovrebbe avere tra due e sei SLI. Se gli SLI sono troppo pochi, potresti perderti indicatori preziosi. Se hai troppi SLI, il team di pronto intervento ha troppi SLI da monitorare, ma con un'utilità aggiuntiva marginale. Ricorda che gli SLI devono semplificare la comprensione dello stato della produzione e fornire un senso di copertura.

Scegli uno SLO

Uno SLO è composto dai seguenti valori:

• Uno SLI. Ad esempio, il rapporto tra il numero di risposte con il codice HTTP 200 e il numero totale di risposte.
• Una durata. Il periodo di tempo in cui viene misurata una metrica. Questo periodo può essere basato sul calendario (ad esempio dal primo giorno di un mese al primo giorno del mese successivo) o su una finestra temporale continua, ad esempio gli ultimi 30 giorni.
• Un target. Ad esempio, una percentuale target di eventi positivi rispetto al totale degli eventi (come il 99,9%) che prevedi di soddisfare per una determinata durata.

Durante lo sviluppo di uno SLO, definire la durata e il target può essere difficile. Un modo per iniziare il processo è identificare gli SLI e registrarli nel tempo. Se non riesci a decidere quale durata e target utilizzare, ricorda che il tuo SLO non deve essere subito perfetto. Probabilmente eseguirai l'iterazione dello SLO per assicurarti che sia in linea con la soddisfazione dei clienti e soddisfi le tue esigenze aziendali. Potresti provare a iniziare con due nove (99,0%) per un mese.

Man mano che monitori la conformità dello SLO durante eventi come deployment, interruzioni e pattern di traffico giornalieri, puoi ottenere insight su quale target è valido, non valido o anche tollerabile. Ad esempio, in un processo in background, potresti definire un successo del 75% come adeguato. Per le richieste mission critical, invece, potresti puntare a qualcosa di più aggressivo, come il 99,95%.

Naturalmente, non esiste un unico SLO che puoi applicare a ogni caso d'uso. Gli SLO dipendono da diversi fattori:

• aspettative dei clienti
• tipo di carico di lavoro
• infrastruttura per la gestione, l'esecuzione e il monitoraggio
• il dominio del problema

La Parte 2 di questa serie, Adotta gli SLO, si concentra sugli SLO indipendenti dal dominio. Gli SLO indipendenti dal dominio (come la disponibilità dei servizi) non sostituiscono gli indicatori di alto livello (come i widget venduti al minuto). Possono però aiutare a misurare se un servizio funziona a prescindere dal caso d'uso aziendale.

Gli indicatori indipendenti dal dominio possono essere spesso ridotti a una domanda, ad esempio "Il servizio è disponibile?" o "Il servizio è abbastanza veloce?" La risposta si trova più spesso in uno SLO che tiene conto di due fattori: disponibilità e latenza. Potresti descrivere uno SLO nei seguenti termini, dove X = 99,9% e Y = 800 ms:

X% delle richieste valide ha esito positivo e ha esito positivo più velocemente di Y ms.

Che cosa succede dopo?

• Leggi Adottare gli SLO, che esplora queste definizioni in maggiore dettaglio e introduce altri SLI che potrebbero essere più appropriati per vari tipi di carichi di lavoro.
• Consulta le altre risorse SRE:
  • Il libro SRE
  • Il foglio di lavoro SRE
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.
• Leggi le nostre risorse su DevOps.
• Scopri di più sulle funzionalità DevOps relative a questa serie:
  • Monitoraggio e osservabilità
  • Monitorare i sistemi per prendere decisioni aziendali oculate
  • Notifica proattiva degli errori
• Esegui il controllo rapido di DevOps per comprendere la tua posizione rispetto al resto del settore.

Adotta SLO

Questo documento definisce diversi obiettivi del livello di servizio (SLO) utili per diversi tipi di carichi di lavoro di servizio comuni. Questo documento è la Parte 2 di due parti. La Parte 1, Definire gli SLO, introduce gli SLO, mostra come gli SLO vengono derivati dagli indicatori del livello del servizio (SLI) e descrive cosa rende efficace un SLO.

Lo stato State of DevOps segnala le funzionalità identificate che favoriscono le prestazioni relative alla distribuzione del software. Questi due documenti ti aiuteranno con le seguenti funzionalità:

• Monitoraggio e osservabilità
• Monitorare i sistemi per prendere decisioni aziendali oculate
• Notifica proattiva degli errori

Cosa misurare

Indipendentemente dal dominio, molti servizi condividono funzionalità comuni e possono utilizzare SLO generici. La seguente discussione sugli SLO generici è organizzata per tipo di servizio e fornisce spiegazioni dettagliate sugli SLI che si applicano a ciascun SLO.

Servizi basati su richiesta

Un servizio basato su richiesta riceve una richiesta da un client (un altro servizio o un utente), esegue alcuni calcoli, invia potenzialmente richieste di rete a un backend e quindi restituisce una risposta al client. I servizi basati su richiesta sono misurati più spesso da SLI di disponibilità e latenza.

Disponibilità come SLI

Lo SLI per la disponibilità indica se il servizio funziona. Lo SLI per la disponibilità è definito come segue:

La proporzione di richieste valide pubblicate correttamente.

Devi innanzitutto definire lo stato valido. Alcune definizioni di base potrebbero essere "di lunghezza diversa da zero" o "adotta un protocollo client-server", ma è compito del proprietario del servizio definire cosa significano per valido. Un metodo comune per valutare la validità è usare un codice di risposta HTTP (o RPC). Ad esempio, spesso consideriamo gli errori HTTP 500 come errori del server che vengono conteggiati a fronte di uno SLO, mentre gli errori 400 sono errori del client che non vengono rilevati.

Dopo aver deciso cosa misurare, devi esaminare ogni codice di risposta restituito dal sistema per assicurarti che l'applicazione utilizzi questi codici in modo corretto e coerente. Quando utilizzi i codici di errore per gli SLO, è importante chiederti se un codice è un indicatore accurato dell'esperienza degli utenti con il tuo servizio. Ad esempio, se un utente cerca di ordinare un articolo non disponibile, il sito si interrompe e restituisce un messaggio di errore oppure il sito suggerisce prodotti simili? Per l'utilizzo con gli SLO, i codici di errore devono essere correlati alle aspettative degli utenti.

Gli sviluppatori possono utilizzare in modo improprio gli errori. Nel caso in cui un utente richieda un prodotto temporaneamente non disponibile, uno sviluppatore potrebbe programmare erroneamente un errore da restituire. Tuttavia, il sistema funziona effettivamente correttamente e non presenta errori. Il codice deve essere restituito senza errori, anche se l'utente non ha potuto acquistare l'articolo desiderato. Ovviamente, i proprietari di questo servizio devono sapere che un prodotto non è disponibile, ma l'impossibilità di concludere una vendita non è un errore dal punto di vista del cliente e non deve essere conteggiato ai fini di uno SLO. Tuttavia, se il servizio non riesce a connettersi al database per determinare se l'elemento è disponibile, si tratta di un errore che viene conteggiato ai fini del budget di errore.

Il servizio potrebbe essere più complesso. Ad esempio, il tuo servizio può gestire le richieste asincrone o fornire ai clienti un processo a lunga esecuzione. In questi casi, potresti esporre la disponibilità in un altro modo. Tuttavia, ti consigliamo di rappresentare comunque la disponibilità come proporzione di richieste valide che hanno esito positivo. Puoi definire la disponibilità come il numero di minuti di esecuzione del carico di lavoro di un cliente come richiesto. Questo approccio viene talvolta definito il metodo dei "minuti utili" per misurare la disponibilità. Nel caso di una macchina virtuale, puoi misurare la disponibilità in termini di proporzione di minuti dopo una richiesta iniziale per una VM a cui la VM è accessibile tramite SSH.

Latenza come SLI

Lo SLI per la latenza (a volte chiamato velocità) indica se il servizio è sufficientemente veloce. Lo SLI per la latenza è definito in modo simile alla disponibilità:

La proporzione di richieste valide pubblicate più velocemente di una soglia.

Puoi misurare la latenza calcolando la differenza tra l'avvio e l'interruzione di un timer per un determinato tipo di richiesta. La chiave è la percezione della latenza da parte dell'utente. Un errore comune è essere troppo precisi nella misurazione della latenza. In realtà, gli utenti non sono in grado di distinguere un aggiornamento di 100 millisecondi (ms) da un aggiornamento di 300 ms e potrebbero accettare qualsiasi punto compreso tra 300 ms e 1000 ms.

Ti consigliamo invece di sviluppare metriche incentrate sulle attività che tengano l'utente in primo piano, ad esempio nei seguenti processi:

• Interattivo: 1000 ms per il tempo in cui un utente attende un risultato dopo aver fatto clic su un elemento.
• Scrittura: 1500 ms per la modifica di un sistema distribuito sottostante. Sebbene questo periodo di tempo sia considerato lento per un sistema, gli utenti tendono ad accettarlo. Ti consigliamo di distinguere esplicitamente scritture e letture nelle metriche.
• Background: 5000 ms per un'azione non visibile all'utente, come un aggiornamento periodico dei dati o altre richieste asincrone.

La latenza viene comunemente misurata come distribuzione (consulta la sezione Scelta di uno SLI nella Parte 1 di questa serie). Data una distribuzione, puoi misurare i vari percentuali. Ad esempio, puoi misurare il numero di richieste più lente rispetto al 99° percentile storico. In questo caso, vengono considerati buoni eventi gli eventi più veloci di questa soglia, impostata esaminando la distribuzione storica. Puoi anche impostare questa soglia in base ai requisiti del prodotto. Puoi anche impostare più SLO di latenza, ad esempio tra latenza tipica e latenza di coda.

Ti consigliamo di non utilizzare solo la latenza media (o mediana) come SLI. Scoprire che la latenza mediana è troppo lenta significa che metà dei tuoi utenti è già insoddisfatta. In altre parole, puoi avere una cattiva latenza per giorni prima di scoprire una reale minaccia per il tuo budget di errore a lungo termine. Pertanto, ti consigliamo di definire il tuo SLO per la latenza di coda (95° percentile) e la latenza mediana (50° percentile).

Nell'articolo di ACM Metrics That Matter, Benjamin Treynor Sloss scrive quanto segue:

"Una buona regola pratica è che la latenza del 99° percentile non dovrebbe essere superiore a 3-5 volte la latenza mediana."

Treynor Sloss continua:

"Abbiamo notato che le misure di latenza del 50°, 95° e 99° percentile per un servizio sono preziose singolarmente e idealmente imposteremo gli SLO su ciascuno."

Un buon modello da seguire consiste nel determinare le soglie di latenza in base ai percentili storici, quindi misurare il numero di richieste che rientrano in ciascun bucket. Per maggiori dettagli, consulta la sezione sugli avvisi di latenza più avanti in questo documento.

Qualità come SLI

La qualità è uno SLI utile per servizi complessi progettati per non riuscire in modo controllato riducendo gradualmente le dipendenze quando le dipendenze sono lente o non disponibili. Lo SLI per la qualità è definito come segue:

La proporzione di richieste valide gestite senza riduzione del servizio.

Ad esempio, una pagina web potrebbe caricare i contenuti principali da un datastore e caricare asset accessori facoltativi di altri 100 servizi e datastore. Se un servizio facoltativo è fuori servizio o troppo lento, la pagina può comunque essere visualizzata senza gli elementi accessori. Se misuri il numero di richieste per cui viene generata una risposta con prestazioni ridotte (ovvero una risposta a cui manca almeno la risposta di un servizio di backend), puoi segnalare il rapporto di richieste errate. Puoi anche tenere traccia del numero di risposte all'utente per le quali manca una risposta da un singolo backend o perché mancano le risposte di più backend.

Servizi di elaborazione dei dati

Alcuni servizi non sono creati per rispondere alle richieste degli utenti, ma utilizzano i dati di un input, elaborano questi dati e generano un output. Il rendimento di questi servizi nei passaggi intermedi non è importante quanto il risultato finale. Con servizi come questi, i tuoi SLI più efficaci sono aggiornamento, copertura, corretta e velocità effettiva, non latenza e disponibilità.

Aggiornamento come SLI

Lo SLI per l'aggiornamento è definito come segue:

La proporzione di dati validi aggiornati più di recente rispetto a una soglia.

Nei sistemi di elaborazione batch, ad esempio, l'aggiornamento può essere misurato come il tempo trascorso da quando l'esecuzione di un'elaborazione è stata completata correttamente per un determinato output. Nei sistemi di elaborazione più complessi o in tempo reale, potresti monitorare l'età del record più recente elaborato in una pipeline.

Ad esempio, prendiamo in considerazione un gioco online che genera riquadri in tempo reale. Gli utenti potrebbero non notare la velocità con cui vengono creati i riquadri della mappa, ma potrebbero notare quando i dati della mappa mancano o non sono aggiornati.

In alternativa, prendi in considerazione un sistema che legga i record da un sistema di monitoraggio dei prodotti disponibili per generare il messaggio "X articoli disponibili" per un sito web di e-commerce. Potresti definire lo SLI per l'aggiornamento come segue:

La percentuale di visualizzazioni che hanno utilizzato informazioni sulle azioni aggiornate nell'ultimo minuto.

Puoi anche utilizzare una metrica per fornire dati non aggiornati allo SLI per la qualità.

Copertura come SLI

Lo SLI per la copertura è definito come segue:

La proporzione di dati validi elaborati correttamente.

Per definire la copertura, devi innanzitutto decidere se accettare un input come valido o se ignorarlo. Ad esempio, se un record di input è danneggiato o ha una lunghezza pari a zero e non può essere elaborato, potresti considerarlo non valido per la misurazione del sistema.

A questo punto, conteggia il numero di record validi. Puoi eseguire questo passaggio con un metodo count() semplice o un altro metodo. Questo è il numero totale di record.

Infine, per generare lo SLI per la copertura, conteggia il numero di record elaborati correttamente e confronta questo numero con il numero totale di record validi.

Correttezza come SLI

Lo SLI per la corretta è definito come segue:

La proporzione di dati validi che hanno prodotto un output corretto.

In alcuni casi, esistono metodi per determinare la correttezza di un output che possono essere utilizzati per convalidare l'elaborazione dell'output. Ad esempio, un sistema che ruota o colora un'immagine non dovrebbe mai produrre un'immagine a zero byte o un'immagine con lunghezza o larghezza pari a zero. È importante separare questa logica di convalida dalla logica di elaborazione stessa.

Un metodo per misurare uno SLI di correttezza è utilizzare dati di input di test noti, ovvero dati con un output corretto noto. I dati di input devono rappresentare i dati utente. In altri casi, è possibile che venga eseguito un controllo matematico o logico rispetto all'output, come nell'esempio precedente di rotazione di un'immagine. Un altro esempio potrebbe essere un sistema di fatturazione che determina se una transazione è valida controllando se la differenza tra il saldo prima della transazione e il saldo dopo la transazione corrisponde al valore della transazione stessa.

Velocità effettiva come SLI

Lo SLI per la velocità effettiva è definito come segue:

La proporzione di tempo in cui la velocità di elaborazione dei dati è stata superiore a una soglia.

In un sistema di elaborazione dati, la velocità effettiva è spesso più rappresentativa della soddisfazione degli utenti rispetto, ad esempio, a una singola misurazione della latenza per un determinato elemento di lavoro. Ad esempio, se la dimensione di ogni input varia drasticamente, potrebbe non avere senso confrontare il tempo necessario per il completamento di ogni elemento se un job procede a una velocità accettabile.

I byte al secondo sono un modo comune per misurare la quantità di lavoro necessaria per elaborare i dati a prescindere dalle dimensioni di un set di dati. Tuttavia, può andare bene qualsiasi metrica che scala approssimativamente in modo lineare rispetto al costo dell'elaborazione.

Potrebbe essere utile partizionare i sistemi di elaborazione dati in base alle percentuali di velocità effettiva previste oppure implementare un sistema di qualità di servizio per garantire che gli input ad alta priorità vengano gestiti e gli input a bassa priorità vengano gestiti in coda. In ogni caso, misurare la velocità effettiva come definita in questa sezione può aiutarti a determinare se il tuo sistema funziona come previsto.

Servizi di esecuzione pianificati

Per i servizi che devono eseguire un'azione a intervalli regolari, come i cron job di Kubernetes, puoi misurare il disallineamento e la durata dell'esecuzione. Di seguito è riportato un esempio di cron job Kubernetes pianificato:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "0 * * * *"

Inclina come SLI

Come SLI, il valore disallineamento è definito come segue:

La proporzione di esecuzioni che iniziano entro una finestra accettabile rispetto all'ora di inizio prevista.

Il disallineamento misura la differenza di tempo tra il momento in cui è pianificato l'avvio di un job e quello in cui inizia. Ad esempio, se il cron job Kubernetes precedente, impostato per iniziare al minuto zero di ogni ora, inizia tre minuti dopo l'ora, il disallineamento sarà pari a tre minuti. Quando un job viene eseguito in anticipo, esiste un disallineamento negativo.

Puoi misurare il disallineamento come una distribuzione nel tempo, con intervalli accettabili corrispondenti che definiscono il disallineamento positivo. Per determinare lo SLI, confronta il numero di esecuzioni che rientrano in un intervallo accettabile.

Durata di esecuzione come SLI

Come SLI, la durata di esecuzione è definita come segue:

La proporzione di esecuzioni completate entro la finestra di durata accettabile.

La durata dell'esecuzione indica il tempo necessario per completare un job. Per una determinata esecuzione, una modalità di errore comune prevede che la durata effettiva superi la durata pianificata.

Un caso interessante è come applicare questo SLI per catturare un lavoro infinito. Poiché questi job non vengono completati, devi registrare il tempo trascorso su un determinato job anziché attendere il completamento di un job. Questo approccio fornisce una distribuzione accurata del tempo necessario per completare il lavoro, anche negli scenari peggiori.

Come per il disallineamento, puoi monitorare la durata dell'esecuzione come distribuzione e definire limiti superiori e inferiori accettabili per eventi validi.

Tipi di metriche per altri sistemi

Molti altri carichi di lavoro hanno le proprie metriche che possono essere utilizzate per generare SLI e SLO. Considera i seguenti esempi:

• Sistemi di archiviazione: durabilità, velocità effettiva, time to first byte, disponibilità dei BLOB
• Contenuti multimediali/video: continuità della riproduzione del client, tempo di avvio della riproduzione, completezza dell'esecuzione del grafico di transcodifica
• Giochi: tempo per abbinare i giocatori attivi, tempo di generare una mappa

Come eseguire la misurazione

Dopo aver deciso cosa stai misurando, puoi decidere come effettuare la misurazione. Puoi raccogliere i tuoi SLI in diversi modi.

Logging lato server

Metodo per generare SLI

Elaborazione dei log lato server delle richieste o dei dati elaborati.

Considerazioni

Vantaggi:

• I log esistenti possono essere rielaborati per eseguire il backfill dei record SLI storici.
• Gli identificatori di sessione cross-service possono ricostruire percorsi dell'utente complessi in più servizi.

Svantaggi:

• Le richieste che non arrivano al server non vengono registrate.
• Le richieste che causano l'arresto anomalo di un server potrebbero non essere registrate.
• Il tempo necessario per elaborare i log può comportare SLI inattivi, che potrebbero essere dati inadeguati per una risposta operativa.
• La scrittura del codice per l'elaborazione dei log può essere un'attività soggetta a errori e dispendiosa in termini di tempo.

Metodi e strumenti di implementazione:

• BigQuery
• Dataflow, Apache Spark
• Splunk

Metriche dell'Application Server

Metodo per generare SLI

Esportare le metriche SLI dal codice che gestisce le richieste degli utenti o elabora i loro dati.

Considerazioni

Vantaggio:

• L'aggiunta di nuove metriche al codice è in genere rapida ed economica.

Svantaggi:

• Le richieste che non arrivano ai server delle applicazioni non vengono registrate.
• Le richieste multiservizio potrebbero essere difficili da tracciare.

Metodi e strumenti di implementazione:

• Cloud Monitoring
• Prometeo
• Prodotti APM di terze parti

Metriche dell'infrastruttura di frontend

Metodo per generare SLI

Utilizzare le metriche dell'infrastruttura di bilanciamento del carico (ad esempio, il bilanciatore del carico globale di livello 7 di Google Cloud).

Considerazioni

Vantaggi:

• Spesso sono già presenti metriche e dati storici, il che riduce lo sforzo tecnico per iniziare.
• Le misurazioni vengono effettuate nel punto più vicino al cliente, ma ancora all'interno dell'infrastruttura di gestione.

Svantaggi:

• Non utilizzabile per gli SLI di elaborazione dati.
• Può solo approssimare i percorsi degli utenti con più richieste.

Metodi e strumenti di implementazione:

• Cloud Monitoring
• Metriche CDN/LB o API di reporting (Cloudflare, Akamai, Fastly)

Client o dati sintetici

Metodo per generare SLI

Creazione di un client che invia richieste inventate a intervalli regolari e convalida le risposte. Per le pipeline di elaborazione dati, la creazione di dati di input sintetici noti e la convalida degli output.

Considerazioni

Vantaggi:

• Misura tutti i passaggi di un percorso dell'utente con più richieste.
• L'invio di richieste dall'esterno dell'infrastruttura acquisisce una parte maggiore del percorso di richiesta complessivo nello SLI.

Svantaggi:

• Approfondisce l'esperienza utente con le richieste sintetiche, che potrebbero essere ingannevoli (sia falsi positivi che falsi negativi).
• Non è facile coprire tutte le richieste di assistenza, ma può essere dedicato ai test di integrazione.
• Gli obiettivi ad alta affidabilità richiedono spesso indagini per una misurazione accurata.
• Il traffico dei probe può coprire il traffico reale.

Metodi e strumenti di implementazione:

• Controlli di uptime di Cloud Monitoring
• Soluzioni open source:
  • Cloud Prober
  • blackbox_exporter
• Soluzioni dei fornitori:
  • Monitoraggio sintetico catchpoint
  • Sintetici New Relic
  • Monitoraggio sintetico Datadog

Strumentazione client

Metodo per generare SLI

Aggiunta di funzionalità di osservabilità al client con cui l'utente interagisce e registrazione degli eventi all'infrastruttura di gestione che monitora gli SLI.

Considerazioni

Vantaggi:

• Fornisce la misura più accurata dell'esperienza utente.
• Può quantificare l'affidabilità di terze parti, ad esempio CDN o fornitori di servizi di pagamento.

Svantaggi:

• La latenza di importazione ed elaborazione dei log client rendono questi SLI non adatti all'attivazione di una risposta operativa.
• Le misurazioni SLI conterranno una serie di fattori altamente variabili potenzialmente fuori dal controllo diretto.
• La creazione della strumentazione nel cliente può comportare molte attività di progettazione.

Metodi e strumenti di implementazione:

• Google Analytics, Firebase
• Analisi utente: Amplitude e strumenti simili
• Monitoraggio mobile/frontend: New Relic Browser, Raygun Real User Monitoring, Sentry
• Client e server personalizzati da registrare e monitorare

Scegli un metodo di misurazione

Idealmente, devi scegliere un metodo di misurazione che corrisponda meglio all'esperienza del cliente con il tuo servizio e richieda il minimo sforzo da parte tua. Per ottenere questo risultato ideale, potresti dover utilizzare una combinazione dei metodi nelle tabelle precedenti. Ecco un approccio suggerito che puoi implementare nel tempo, in ordine di impegno:

1. Utilizzo delle esportazioni dei server delle applicazioni e delle metriche dell'infrastruttura. In genere, puoi accedere a queste metriche immediatamente e forniscono rapidamente un valore aggiunto. Alcuni strumenti APM includono strumenti SLO integrati.
2. Utilizzo della strumentazione del client. Poiché i sistemi legacy in genere non dispongono di una strumentazione incorporata del client per il client, la configurazione della strumentazione potrebbe richiedere un investimento significativo. Tuttavia, se utilizzi una suite APM o un framework frontend che fornisce la strumentazione del client, puoi ottenere rapidamente informazioni sulla soddisfazione dei tuoi clienti.
3. Utilizzo dell'elaborazione dei log. Se non riesci a implementare le esportazioni del server o la strumentazione client, ma esistono log, l'elaborazione dei log potrebbe essere la soluzione migliore. Un altro approccio è combinare le esportazioni e l'elaborazione dei log utilizzando le esportazioni come origine immediata per alcuni SLI (ad esempio la disponibilità immediata) e l'elaborazione dei log per indicatori a lungo termine (come gli avvisi di slow burn discussi più avanti nella guida su SLO e avvisi).
4. Implementazione dei test sintetici. Una volta acquisita una conoscenza di base di come i clienti utilizzano il tuo servizio, puoi testare il tuo livello di servizio. Ad esempio, puoi creare account di test con dati noti ed eseguire query su questi ultimi. Questi test possono aiutare a evidenziare modalità di errore che non sono facilmente osservabili, come nel caso di servizi a traffico ridotto.

Definisci i tuoi scopi

Uno dei modi migliori per stabilire gli obiettivi è creare un documento condiviso che descriva i tuoi SLO e come li hai sviluppati. Il tuo team può eseguire l'iterazione del documento mentre implementa e li ripete nel tempo.

Consigliamo ai proprietari di attività, ai proprietari dei prodotti e ai dirigenti di esaminare questo documento. Questi stakeholder possono fornire insight sulle aspettative in termini di servizio e sui compromessi in termini di affidabilità del prodotto.

Per i percorsi degli utenti (CUJ) più importanti della tua azienda, ecco un modello per lo sviluppo di uno SLO:

1. Scegli una specifica SLI (ad esempio disponibilità o aggiornamento).
2. Definire come implementare la specifica SLI.
3. Leggi il piano per assicurarti che i tuoi CUJ siano coperti.
4. Imposta gli SLO in base alle prestazioni o alle esigenze aziendali passate.

I CUJ non devono essere vincolati a un singolo servizio né a un singolo team di sviluppo o organizzazione. Se i tuoi utenti dipendono da centinaia di microservizi che operano al 99,5%, ma nessuno monitora la disponibilità end-to-end, è probabile che il cliente non sia soddisfatto.

Supponiamo di avere una query che dipende da cinque servizi che funzionano in sequenza: un bilanciatore del carico, un frontend, un mixer, un backend e un database.

Se ogni componente ha una disponibilità del 99,5%, la disponibilità nel peggiore dei casi per gli utenti è la seguente:

99,5% * 99,5% * 99,5% * 99,5% * 99,5% = 97,52%

Questa è la disponibilità nel caso peggiore per l'utente, perché si verifica un guasto dell'intero sistema se si verifica un errore in uno dei cinque servizi. Questo vale solo se tutti i livelli dello stack devono essere sempre disponibili immediatamente per gestire ogni richiesta dell'utente, senza fattori di resilienza come nuovi tentativi intermedi, cache o code. Un sistema con un accoppiamento così stretto tra i servizi non è una buona progettazione e va contro il modello di microservizi.

La semplice misurazione delle prestazioni rispetto allo SLO di un sistema distribuito in questo modo (servizio per servizio) non rispecchia accuratamente l'esperienza del tuo cliente e potrebbe comportare un'interpretazione troppo sensibile.

Dovresti invece misurare le prestazioni rispetto allo SLO al frontend per capire l'esperienza degli utenti. All'utente non importa se il servizio di un componente non va a buon fine, causando il nuovo tentativo automatico e corretto di una query, se la query dell'utente ha ancora esito positivo. Se hai condiviso servizi interni, questi servizi possono misurare separatamente le prestazioni rispetto ai relativi SLO, in quanto i servizi rivolti agli utenti agiscono come loro clienti. Dovresti gestire questi SLO separatamente l'uno dall'altro.

È possibile creare un servizio a disponibilità elevata (ad esempio il 99,99%) in aggiunta a un servizio meno disponibile (ad esempio il 99,9%) utilizzando fattori di resilienza come nuovi tentativi intelligenti, memorizzazione nella cache e code.

Come regola generale, chiunque abbia una conoscenza pratica delle statistiche dovrebbe essere in grado di leggere e comprendere il tuo SLO senza conoscere il servizio sottostante o il layout organizzativo.

Esempio di foglio di lavoro SLO

Quando sviluppi il tuo SLO, ricordati di fare quanto segue:

• Assicurati che gli SLI specifichino un evento, un criterio di successo e dove e come registrare i successi o gli errori.
• Definisci la specifica SLI in termini di proporzione di eventi positivi.
• Assicurati che lo SLO specifichi sia un livello target sia una finestra di misurazione.
• Descrivi i vantaggi e gli svantaggi del tuo approccio in modo che le parti interessate ne comprendano i compromessi e le sfumature.

Ad esempio, considera il seguente foglio di lavoro SLO.

CUJ: caricamento della home page

Tipo di SLI: latenza Specifica SLI: la proporzione di richieste di home page pubblicate in meno di 100 ms Implementazioni SLI: Proporzione di richieste di home page pubblicate in meno di 100 ms, misurata dalla colonna della latenza del log del server. (Svantaggio: questa misurazione non tiene conto delle richieste che non riescono a raggiungere il backend.) Percentuale di richieste di home page gestite in meno di 100 ms, misurata dai prober che eseguono JavaScript in un browser in esecuzione su una macchina virtuale. (Vantaggi e svantaggi: questa misurazione rileva gli errori quando le richieste non possono raggiungere la rete, ma potrebbero non rilevare problemi che interessano solo un sottoinsieme di utenti.) SLO: il 99% delle richieste di home page negli ultimi 28 giorni è stato pubblicato in meno di 100 ms

Nota: se non sei d'accordo come team a un livello target, scegli un livello e accetta di cambiarlo tra sei mesi. Scegliere il numero sbagliato è meglio che non scegliere nessun numero.

Che cosa succede dopo?

• Leggi The Art of SLOs, un workshop sviluppato dal team Customer Reliability Engineering di Google.
• Prova Site Reliability Engineering: Measurement and Managing Reliability, un corso online sulla creazione di SLO.
• Leggi Site Reliability Engineering: Implementing SLOs.
• Leggi Concetti relativi al monitoraggio dei servizi.
• Scopri di più sullo sviluppo di SLO con Cloud Monitoring.
• Prova il flessibile Generatore SLO dell'Organizzazione servizi professionali (PSO) di Google.
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.
• Leggi le nostre risorse su DevOps.
• Scopri di più sulle funzionalità DevOps relative a questa serie:
  • Monitoraggio e osservabilità
  • Monitorare i sistemi per prendere decisioni aziendali oculate
  • Notifica proattiva degli errori
• Esegui il controllo rapido di DevOps per comprendere la tua posizione rispetto al resto del settore.

Terminologia

Questo documento fornisce definizioni comuni dei termini relativi allo SLO utilizzati nella sezione Framework dell'architettura Google Cloud: affidabilità.

• livello di servizio: una misurazione del livello di efficacia di un determinato servizio rispetto al lavoro previsto per l'utente. Puoi descrivere questa misurazione in termini di felicità degli utenti e misurarla con vari metodi, a seconda di ciò che fa il servizio e di ciò che l'utente si aspetta che faccia o gli viene detto che può fare.

  Esempio: "Un utente si aspetta che il nostro servizio sia disponibile e veloce".

• percorso dell'utente critico (CUJ): un insieme di interazioni che un utente ha con un servizio per raggiungere un singolo obiettivo, ad esempio un clic o una pipeline in più passaggi.

  Esempio: "Un utente fa clic sul pulsante di pagamento e attende la risposta relativa all'elaborazione del carrello e alla restituzione di una ricevuta".

• indicatore del livello del servizio (SLI): un indicatore del livello di soddisfazione degli utenti che può essere misurato quantitativamente per un livello di servizio. In altre parole, per misurare un livello di servizio, devi misurare un indicatore che rappresenti la soddisfazione degli utenti in quel livello di servizio, ad esempio la disponibilità di un servizio. Uno SLI può essere considerato come una linea di un grafico che cambia nel tempo, man mano che il servizio migliora o si riduce. Tende a essere un segnale radio "buono" / "totale" espresso in percentuale senza unità. Utilizzando costantemente queste percentuali, i team possono comprendere lo SLI senza conoscere a fondo la sua implementazione

  Esempio: "Misura il numero di richieste riuscite negli ultimi 10 minuti diviso per il numero di tutte le richieste valide negli ultimi 10 minuti".

• Obiettivo del livello di servizio (SLO): il livello che ti aspetti che un servizio raggiunga nella maggior parte del tempo e in base al quale viene misurato uno SLI.

  Esempio: "Le risposte di servizio superano i 400 millisecondi (ms) per il 95% di tutte le richieste valide misurate nell'arco di 14 giorni."

  

• accordo sul livello del servizio (SLA): una descrizione di cosa deve accadere se non viene soddisfatto uno SLO. In genere, uno SLA è un accordo legale tra fornitori e clienti e potrebbe includere anche termini di risarcimento. Nelle discussioni tecniche sull'SRE, questo termine viene spesso evitato.

  Esempio: "Se il servizio non fornisce una disponibilità del 99,95% in un mese di calendario, il fornitore di servizi offre un compenso al cliente per ogni minuto non conforme".

• error budget: per quanto tempo o quanti eventi negativi puoi resistere prima di violare il tuo SLO. Questa misurazione indica quanti errori l'attività può aspettarsi o tollerare. Il budget di errore è fondamentale per aiutarti a prendere decisioni potenzialmente rischiose.

  Esempio: "Se il nostro SLO è disponibile al 99, 9%, consentiamo allo 0, 1% delle nostre richieste di gestire gli errori dovuti a incidenti, incidenti o sperimentazioni".

SLO e avvisi

Questo documento nella sezione Framework dell'architettura Google Cloud: affidabilità fornisce dettagli sugli avvisi relativi agli SLO.

Un approccio errato all'introduzione di un nuovo sistema di osservabilità come gli SLO consiste nell'utilizzare il sistema per sostituire completamente un sistema precedente. Dovresti invece vedere gli SLO come un sistema complementare. Ad esempio, anziché eliminare gli avvisi esistenti, ti consigliamo di eseguirli in parallelo con gli avvisi SLO introdotti qui. Questo approccio consente di scoprire quali avvisi legacy sono predittivi degli avvisi SLO, che si attivano in parallelo con quelli SLO e quali non vengono mai attivati.

Un principio della SRE è l'avviso in base ai sintomi, non alle cause. Gli SLO sono, per loro stessa natura, misurazioni dei sintomi. Quando adotti gli avvisi SLO, potresti scoprire che l'avviso di sintomi si attiva insieme ad altri avvisi. Se scopri che i tuoi avvisi precedenti basati sulla causa vengono attivati senza SLO o sintomi, è consigliabile disattivare completamente, trasformarli in avvisi di richiesta di assistenza o registrati per un riferimento futuro.

Per maggiori informazioni, consulta il foglio di lavoro SRE, capitolo 5.

Velocità di burn rate SLO

La frequenza di burnout di uno SLO misura la velocità con cui un'interruzione espone gli utenti agli errori ed esaurisce il budget di errore. Se misuri la burn rate, puoi determinare il tempo prima che un servizio violi il suo SLO. Gli avvisi basati sul burn rate SLO sono un approccio prezioso. Ricorda che lo SLO si basa su una durata, che potrebbe essere piuttosto lunga (settimane o anche mesi). Tuttavia, l'obiettivo è rilevare rapidamente una condizione che genera una violazione dello SLO prima che si verifichi effettivamente.

La tabella seguente mostra il tempo necessario per superare un obiettivo se il 100% delle richieste non riesce nell'intervallo specificato, supponendo che le query al secondo (QPS) siano costanti. Ad esempio, se hai uno SLO del 99,9% misurato nell'arco di 30 giorni, puoi resistere a 43,2 minuti di tempo di inattività completo durante quei 30 giorni. Ad esempio, questi tempi di inattività possono verificarsi contemporaneamente o distribuiti su più incidenti.

Scopo	90 giorni	30 giorni	7 giorni	1 giorno
90%	9 giorni	3 giorni	16,8 ore	2,4 ore
99%	21,6 ore	7,2 ore	1,7 ore	14,4 minuti
99,9%	2,2 ore	43,2 minuti	10,1 minuti	1,4 minuti
99,99%	13 minuti	4,3 minuti	1 minuto	8,6 secondi
99,999%	1,3 minuti	25,9 secondi	6 secondi	0,9 secondi

In pratica, non puoi permetterti incidenti di interruzione del 100% se vuoi ottenere percentuali di successo elevate. Tuttavia, molti sistemi distribuiti possono avere un guasto parziale o una riduzione controllata. Anche in questi casi, è comunque importante sapere se un essere umano deve intervenire, anche in questi errori parziali e gli avvisi SLO ti offrono un modo per determinarlo.

Quando attivare l'avviso

Una domanda importante è quando intervenire in base alla burn rate del tuo SLO. Di regola, se esaurisci il budget di errore entro 24 ore, il tempo necessario per contattare qualcuno e risolvere un problema è ora.

Misurare il tasso di insuccesso non è sempre semplice. Una serie di piccoli errori potrebbe sembrare terrificante al momento, ma rivelarsi di breve durata e avere un impatto irrilevante sul tuo SLO. Analogamente, se un sistema rimane leggermente inutilizzato per molto tempo, questi errori possono corrispondere a una violazione dello SLO.

Idealmente, il tuo team reagirà a questi indicatori in modo da farti spendere quasi tutto il budget di errore (ma non superarlo) per un determinato periodo di tempo. Una spesa eccessiva viola il tuo SLO. Se spendi troppo poco, non corri abbastanza rischi o potenzialmente esaurire i membri del tuo team disponibile.

Devi trovare un modo per stabilire quando un sistema è rotto a sufficienza da permettere a un essere umano di intervenire. Le sezioni seguenti illustrano alcuni approcci a questa domanda.

Bruciatura rapida

Un tipo di burnout SLO è l'operazione di burn SLO rapida perché elimina rapidamente il budget di errore e richiede che tu intervenga per evitare una violazione dello SLO.

Supponiamo che il tuo servizio operi normalmente a 1000 query al secondo (QPS) e che tu voglia mantenere una disponibilità del 99% misurata nell'arco di sette giorni alla settimana. Il budget di errore corrisponde a circa 6 milioni di errori consentiti (su circa 600 milioni di richieste). Ad esempio, se mancano 24 ore prima che il budget di errore si esaurisca, il limite è di circa 70 errori al secondo o di 252.000 errori in un'ora. Questi parametri si basano sulla regola generale secondo cui gli incidenti con pagine devono consumare almeno l'1% del budget di errore trimestrale.

Puoi scegliere di rilevare questa percentuale di errori prima che sia trascorsa un'ora. Ad esempio, dopo aver osservato una frequenza di 70 errori al secondo per 15 minuti, potresti decidere di contattare il tecnico di chiamata, come illustrato nel seguente diagramma.

Idealmente, il problema viene risolto prima di spendere un'ora del budget di 24 ore. Se si sceglie di rilevare questa frequenza in un periodo di tempo più breve (ad esempio, un minuto), è probabile che sia troppo soggetta a errori. Se il tempo target per il rilevamento è inferiore a 15 minuti, questo numero può essere modificato.

Ustioni lente

Un altro tipo di burn rate è la slow burn. Supponiamo che tu presenti un bug che riduce il budget di errore settimanale entro il quinto o il sesto giorno o il budget mensile entro la seconda settimana. Qual è la risposta migliore?

In questo caso, potresti introdurre un avviso di scrittura SLO lenta che indica che sei sulla buona strada per esaurire l'intero budget di errore prima della fine della finestra di avviso. Naturalmente, quell'avviso potrebbe restituire molti falsi positivi. Ad esempio, può verificarsi spesso una condizione in cui gli errori si verificano brevemente ma con una frequenza che consuma rapidamente il budget di errore. In questi casi, la condizione è un falso positivo perché dura solo per poco tempo e non minaccia il budget di errore a lungo termine. Ricorda che l'obiettivo non è eliminare tutte le fonti di errore, ma rimanere entro un intervallo accettabile non superare il budget di errore. Vuoi evitare di avvisare un essere umano di intervenire per eventi che non minacciano legittimamente il tuo budget di errore.

Ti consigliamo di avvisare la coda dei ticket (anziché il paging o l'invio di email) per gli eventi a bassa velocità. Questi eventi non sono emergenze, ma richiedono l'attenzione umana prima della scadenza del budget. Questi avvisi non devono essere email per un elenco di team, che diventano rapidamente una seccatura da ignorare. I biglietti devono essere monitorabili, assegnabili e trasferibili. I team dovrebbero sviluppare report per il carico delle richieste, i tassi di chiusura, l'azionabilità e i duplicati. Un numero eccessivo di richieste di assistenza non eseguibili è un ottimo esempio di faticamento.

Utilizzare in modo appropriato gli avvisi SLO può richiedere tempo e dipendere dalla cultura e dalle aspettative del tuo team. Ricorda che puoi perfezionare gli avvisi SLO nel tempo. Puoi anche avere più metodi di avviso, con finestre di avviso diverse, a seconda delle tue esigenze.

Avvisi di latenza

Oltre agli avvisi di disponibilità, puoi anche ricevere avvisi di latenza. Con gli SLO di latenza, misuri la percentuale di richieste che non soddisfano un target di latenza. Con questo modello, puoi usare lo stesso modello di avviso che utilizzi per rilevare le ustioni rapide o lente del budget di errore.

Come indicato in precedenza per gli SLO di latenza mediana, metà delle tue richieste può uscire dallo SLO. In altre parole, gli utenti possono subire una latenza scadente per giorni prima di rilevare l'impatto sul budget di errore a lungo termine. I servizi dovrebbero invece definire gli obiettivi di latenza della coda e gli obiettivi di latenza tipica. Suggeriamo di utilizzare il 90° percentile storico per definire i valori tipici e il 99° percentile per la coda. Dopo aver impostato questi target, puoi definire gli SLO in base al numero di richieste che ti aspetti di ricevere in ogni categoria di latenza e a quante sono troppo lente. Questo approccio è lo stesso di budget di errore e deve essere considerato allo stesso modo. Di conseguenza, alla fine potresti ottenere un'istruzione come "Il 90% delle richieste verrà gestito all'interno della latenza tipica e il 99,9% entro gli obiettivi di latenza della coda". Questi target assicurano che la maggior parte degli utenti sperimenta la latenza tipica e ti permettono comunque di tenere traccia di quante richieste sono più lente rispetto ai target di latenza di coda.

Per alcuni servizi potrebbero essere previsti runtime molto variabili. Ad esempio, le aspettative in termini di prestazioni della lettura da un sistema di datastore potrebbero essere notevolmente diverse da quelle della scrittura su un sistema di datastore. Anziché enumerare ogni possibile aspettativa, puoi introdurre i bucket di prestazioni di runtime, come mostrato nelle tabelle seguenti. Questo approccio presuppone che questi tipi di richieste siano identificabili e preclassificati in ciascun bucket. Non aspettarti di classificare le richieste in tempo reale.

Sito web rivolto agli utenti
Bucket	Runtime massimo previsto
Lettura	1 secondo
Scrivi / aggiorna	3 secondi

Sistemi di trattamento dati
Bucket	Runtime massimo previsto
Piccolo	10 secondi
Media	1 minuto
Di grandi dimensioni	5 minuti
Molto grande	1 ora
Enorme	8 ore

Se misuri il sistema così com'è, puoi capire quanto tempo richiede in genere l'esecuzione di queste richieste. Prendiamo come esempio un sistema per elaborare i caricamenti dei video. Se il video è molto lungo, i tempi di elaborazione dovrebbero richiedere più tempo. Possiamo utilizzare la durata del video in secondi per classificare queste operazioni in un bucket, come mostra la tabella seguente. La tabella registra il numero di richieste per bucket e vari percentili della distribuzione del runtime nel corso di una settimana.

Durata video	Numero di richieste misurato in una settimana	10%	90%	99,95%
Piccolo	0	-	-	-
Media	1,9 milioni	864 millisecondi	17 secondi	86 secondi
Di grandi dimensioni	25 milioni	1,8 secondi	52 secondi	9,6 minuti
Molto grande	4,3 milioni	2 secondi	43 secondi	23,8 minuti
Enorme	81.000	36 secondi	1,2 minuti	41 minuti

Da questa analisi puoi ricavare alcuni parametri per gli avvisi:

• fast_typical: al massimo, il 10% delle richieste è più veloce di questo periodo. Se troppe richieste sono più veloci di questo periodo, le destinazioni potrebbero essere errate o qualcosa nel sistema potrebbe essere cambiato.
• slow_typical: almeno il 90% delle richieste è più veloce di questo intervallo di tempo. Questo limite guida lo SLO di latenza principale. Questo parametro indica se la maggior parte delle richieste è abbastanza veloce.
• slow_tail: almeno il 99,95% delle richieste è più veloce di questo periodo. Questo limite garantisce che non ci siano troppe richieste lente.
• deadline: il momento in cui la RPC o l'elaborazione in background di un utente scade e non va a buon fine (un limite in genere è già impostato come hardcoded nel sistema). Queste richieste non saranno effettivamente lente, ma in realtà non andranno a buon fine con un errore e verranno conteggiate ai fini dello SLO di disponibilità.

Una linea guida nella definizione dei bucket è mantenere i valori fast_typical, slow_typical e slow_tail di un bucket entro un ordine di grandezza l'uno dall'altro. Questa linea guida garantisce che il tuo bucket non sia troppo ampio. Ti consigliamo di non cercare di evitare sovrapposizioni o intervalli tra i bucket.

Bucket	fast_typical	slow_typical	slow_tail	scadenza
Piccolo	100 millisecondi	1 secondo	10 secondi	30 secondi
Media	600 millisecondi	6 secondi	60 secondi (1 minuto)	300 secondi
Di grandi dimensioni	3 secondi	30 secondi	300 secondi (5 minuti)	10 minuti
Molto grande	30 secondi	6 minuti	60 minuti (1 ora)	3 ore
Enorme	5 minuti	50 minuti	500 minuti (8 ore)	12 ore

Questo comporta la creazione di una regola come api.method: SMALL => [1s, 10s]. In questo caso, il sistema di monitoraggio SLO vede una richiesta, determina il proprio bucket (ad esempio analizzando il nome del metodo o l'URI e confrontando il nome con una tabella di ricerca), quindi aggiorna la statistica in base al runtime di quella richiesta. Se l'operazione ha richiesto 700 millisecondi, rientra nel target slow_typical. Se è di 3 secondi, è all'interno di slow_tail. Se è di 22 secondi, è oltre slow_tail, ma non è ancora un errore.

In termini di soddisfazione degli utenti, puoi pensare alla mancanza di latenza di coda come a un'indisponibilità. Ciò significa che la risposta è così lenta da considerare un errore. Per questo motivo, ti consigliamo di utilizzare la stessa percentuale che utilizzi per la disponibilità, ad esempio:

Il 99,95% di tutte le richieste viene soddisfatto entro 10 secondi.

La latenza tipica spetta a te. Alcuni team di Google considerano che il 90% sia un buon obiettivo. Questi dati sono correlati alla tua analisi e alla modalità di scelta delle durate per slow_typical. Ad esempio:

Il 90% di tutte le richieste viene gestito entro 1 secondo.

Avvisi suggeriti

Date queste linee guida, la tabella seguente include un insieme di riferimento suggerito di avvisi SLO.

SLO	Finestra di misurazione	Velocità di combustione	Azione
Disponibilità, burnout rapida Latenza tipica Latenza coda	Finestra di 1 ora	Meno di 24 ore per la violazione dello SLO	Chiamare qualcuno
Disponibilità, Slow burn Latenza tipica, bruciatura lenta Latenza coda, bruciatura lenta	Finestra di 7 giorni	Più di 24 ore per la violazione dello SLO	Crea un ticket

Gli avvisi SLO sono una competenza il cui sviluppo può richiedere tempo. Le durate in questa sezione sono suggerimenti e puoi modificarle in base alle tue esigenze e al tuo livello di precisione. Collegare gli avvisi alla finestra di misurazione o alla spesa del budget di errore potrebbe essere utile oppure potresti aggiungere un ulteriore livello di avviso tra ustioni rapide e operazioni lente.

Integra funzioni di osservabilità nell'infrastruttura e nelle applicazioni

Questo documento nel framework dell'architettura Google Cloud fornisce best practice per aggiungere osservabilità ai servizi, in modo da poter comprendere meglio le prestazioni dei servizi e identificare rapidamente i problemi. L'osservabilità include monitoraggio, logging, tracciamento, profilazione, debug e sistemi simili.

Il monitoraggio è alla base della gerarchia di affidabilità dei servizi nel manuale di Google SRE. Senza un adeguato monitoraggio, non è possibile capire se un'applicazione funziona correttamente.

Fornisci strumenti al tuo codice per massimizzare l'osservabilità

Un sistema ben progettato mira ad avere la giusta quantità di osservabilità che inizia nella fase di sviluppo. Non aspettare che l'applicazione sia in produzione prima di iniziare a osservarla. Imposta il tuo codice e prendi in considerazione le seguenti indicazioni:

• Per eseguire il debug e risolvere i problemi in modo efficiente, pensa a quali voci di log e traccia scrivere e a quali metriche monitorare ed esportare. Stabilisci la priorità in base alle modalità di errore più probabili o frequenti del sistema.
• Controlla ed elimina periodicamente il tuo monitoraggio. Elimina dashboard, grafici, avvisi, tracciamento e logging inutilizzati o inutili per eliminare il disordine.

L'osservabilità di Google Cloud offre monitoraggio in tempo reale, monitoraggio e logging multi-cloud ibridi (ad esempio per AWS e Azure), oltre a tracciamento, profilazione e debug. L'osservabilità di Google Cloud può anche rilevare automaticamente e monitorare i microservizi in esecuzione su App Engine o in un mesh di servizi come Istio.

Se generi molti dati dell'applicazione, puoi ottimizzare l'importazione su larga scala di log di eventi di analisi con BigQuery. BigQuery è anche adatto per la persistenza e l'analisi dei dati con serie temporale ad alta cardinalità provenienti dal framework di monitoraggio. Questo approccio è utile perché ti consente di eseguire query arbitrarie a un costo inferiore, anziché provare a progettare il monitoraggio in modo perfetto fin dall'inizio, disaccoppiando il reporting dal monitoraggio. Puoi creare report dai dati utilizzando Looker Studio o Looker.

Suggerimenti

Per applicare al tuo ambiente le indicazioni contenute nel framework dell'architettura, segui questi suggerimenti:

• Implementa il monitoraggio in anticipo, ad esempio prima di avviare una migrazione o prima di eseguire il deployment di una nuova applicazione in un ambiente di produzione.
• Disambigua tra problemi delle applicazioni e problemi cloud sottostanti. Utilizza l'API Monitoring o altri prodotti Cloud Monitoring e la Dashboard dello stato di Google Cloud.
• Definisci una strategia di osservabilità oltre il monitoraggio che includa tracciamento, profilazione e debug.
• Elimina regolarmente gli artefatti di osservabilità che non utilizzi o che non forniscono valore, come gli avvisi per i quali non è possibile eseguire azioni.
• Se generi grandi quantità di dati di osservabilità, invia gli eventi applicazione a un sistema di data warehouse come BigQuery.

Passaggi successivi

• Progettare per la scalabilità e l'alta disponibilità (documento successivo di questa serie)

Esplora altre categorie nel framework dell'architettura come progettazione del sistema, eccellenza operativa, sicurezza, privacy e conformità.

Progetta per la scalabilità e la disponibilità elevata

Questo documento nel framework dell'architettura Google Cloud fornisce i principi di progettazione per progettare l'architettura dei tuoi servizi in modo che possano tollerare errori e fare lo scale in risposta alla domanda dei clienti. Un servizio affidabile continua a rispondere alle richieste dei clienti quando si verifica un'elevata domanda per il servizio o in caso di evento di manutenzione. I seguenti principi e best practice di progettazione dell'affidabilità dovrebbero far parte dell'architettura del sistema e del piano di deployment.

Crea ridondanza per una disponibilità superiore

I sistemi con esigenze di affidabilità elevate non devono avere single point of failure e le loro risorse devono essere replicate su più domini di errore. Un dominio in errore è un pool di risorse che possono causare errori in modo indipendente, ad esempio un'istanza VM, una zona o una regione. Quando esegui la replica tra i domini in errore, ottieni un livello aggregato di disponibilità più elevato rispetto a quello che potrebbe raggiungere le singole istanze. Per saperne di più, consulta Regioni e zone.

Come esempio specifico di ridondanza che potrebbe far parte dell'architettura del tuo sistema, per isolare gli errori nella registrazione DNS in singole zone, utilizza i nomi DNS di zona affinché le istanze sulla stessa rete possano accedere l'una all'altra.

Progetta un'architettura multizona con failover per una disponibilità elevata

Rendi la tua applicazione resiliente agli errori a livello di zona progettandola per utilizzare pool di risorse distribuiti in più zone con la replica dei dati, il bilanciamento del carico e il failover automatico tra zone. Esegui repliche a livello di zona di ogni livello dello stack di applicazioni ed elimina tutte le dipendenze tra zone nell'architettura.

Replica i dati tra regioni per il ripristino di emergenza

Replica o archivia i dati in una regione remota per abilitare il ripristino di emergenza in caso di interruzione regionale o perdita di dati. Quando viene utilizzata la replica, il ripristino è più rapido perché i sistemi di archiviazione nella regione remota contengono già dati quasi aggiornati, a parte la possibile perdita di una piccola quantità di dati a causa del ritardo di replica. Quando utilizzi l'archiviazione periodica anziché la replica continua, il ripristino di emergenza prevede il ripristino dei dati dai backup o dagli archivi in una nuova regione. Questa procedura di solito comporta tempi di inattività del servizio più lunghi rispetto all'attivazione di una replica del database aggiornata continuamente e potrebbe comportare una maggiore perdita di dati a causa del divario di tempo tra operazioni di backup consecutive. Qualunque sia l'approccio utilizzato, è necessario eseguire nuovamente il deployment dell'intero stack di applicazioni e avviarlo nella nuova regione, durante il quale il servizio non sarà disponibile.

Per una discussione dettagliata su concetti e tecniche di ripristino di emergenza, consulta Architettura del ripristino di emergenza in caso di interruzioni dell'infrastruttura cloud.

Progetta un'architettura multiregionale per la resilienza alle interruzioni regionali

Se il servizio deve essere eseguito ininterrottamente anche nel raro caso in cui un'intera regione non funzioni, progettalo in modo da utilizzare pool di risorse di calcolo distribuiti in diverse regioni. Esegui repliche a livello di regione di ogni livello dello stack delle applicazioni.

Utilizza la replica dei dati in più regioni e il failover automatico in caso di inattività di una regione. Alcuni servizi Google Cloud hanno varianti per più regioni, ad esempio Spanner. Per garantire la resilienza contro gli errori a livello di regione, utilizza questi servizi multiregionali nella tua progettazione, ove possibile. Per ulteriori informazioni sulle regioni e sulla disponibilità del servizio, consulta Località di Google Cloud.

Assicurati che non esistano dipendenze tra regioni in modo che l'impatto di un errore a livello di regione sia limitato a quella regione.

Elimina i single point of failure a livello di regione, ad esempio un database primario a livello di regione che potrebbe causare un'interruzione globale quando non è raggiungibile. Tieni presente che le architetture multiregionali spesso hanno un costo maggiore, quindi considera le esigenze aziendali rispetto al costo prima di adottare questo approccio.

Per ulteriori indicazioni sull'implementazione della ridondanza nei domini in errore, consulta il documento di sondaggio Deployment Archetypes for Cloud Applications (PDF).

Elimina i colli di bottiglia della scalabilità

Identifica i componenti del sistema che non possono crescere oltre i limiti delle risorse di una singola VM o di una singola zona. Alcune applicazioni scalano verticalmente, ovvero aggiungono più core della CPU, memoria o larghezza di banda di rete su una singola istanza VM per gestire l'aumento del carico. La scalabilità di queste applicazioni è limitata e spesso è necessario configurarle manualmente per far fronte alla crescita.

Se possibile, rinnova questi componenti per scalare orizzontalmente, ad esempio mediante il partizionamento o suddivisione in VM tra VM o zone. Per gestire l'aumento del traffico o dell'utilizzo, aggiungi altri shard. Utilizza tipi di VM standard che possono essere aggiunti automaticamente per gestire l'aumento del carico per shard. Per maggiori informazioni, consulta Pattern per app scalabili e resilienti.

Se non puoi riprogettare l'applicazione, puoi sostituire i componenti gestiti da te con servizi cloud completamente gestiti progettati per scalare orizzontalmente senza alcuna azione dell'utente.

Esegui la riduzione controllata dei livelli di servizio in caso di sovraccarico

Progetta i tuoi servizi in modo da tollerare il sovraccarico. I servizi dovrebbero rilevare il sovraccarico e restituire risposte di qualità inferiore all'utente o abbandonare parzialmente il traffico, non fallire completamente sotto sovraccarico.

Ad esempio, un servizio può rispondere alle richieste degli utenti con pagine web statiche e disattivare temporaneamente il comportamento dinamico più costoso da elaborare. Questo comportamento è descritto in dettaglio nel pattern di failover caldo da Compute Engine a Cloud Storage. In alternativa, il servizio può consentire operazioni di sola lettura e disattivare temporaneamente gli aggiornamenti dei dati.

Gli operatori devono essere avvisati di correggere la condizione di errore quando il servizio si riduce.

Previeni e riduci i picchi di traffico

Non sincronizzare le richieste tra i client. Troppi client che inviano traffico nello stesso istante causano picchi di traffico che potrebbero causare errori a cascata.

Implementa strategie di mitigazione dei picchi sul lato server come la limitazione, la queueing, l'eliminazione del carico o la interruzione dei circuiti, il degrado graduale e la priorità delle richieste critiche.

Le strategie di mitigazione sul client includono la limitazione lato client e il backoff esponenziale con tremolio.

Sanitizza e convalida gli input

Per evitare input errati, casuali o dannosi che causano interruzioni del servizio o violazioni della sicurezza, purifica e convalida i parametri di input per le API e gli strumenti operativi. Ad esempio, Apigee e Google Cloud Armor possono contribuire a proteggerti dagli attacchi di iniezione.

Usa regolarmente il fuzz test, in cui un test Bard chiama intenzionalmente le API con input casuali, vuoti o troppo grandi. Esegui questi test in un ambiente di test isolato.

Gli strumenti operativi devono convalidare automaticamente le modifiche alla configurazione prima dell'implementazione delle modifiche e devono rifiutare le modifiche se la convalida non va a buon fine.

Fail Safe in modo da preservare il funzionamento

Se si verifica un errore dovuto a un problema, i componenti di sistema non dovrebbero funzionare in modo da consentire all'intero sistema di continuare a funzionare. Questi problemi possono essere un bug del software, un input o una configurazione errati, un'interruzione non pianificata dell'istanza o un errore umano. Il processo dei servizi consente di determinare se dovresti essere eccessivamente permissivo o eccessivamente riduttivo, anziché eccessivamente restrittivo.

Considera i seguenti scenari di esempio e come rispondere in caso di errore:

• In genere è preferibile che un componente firewall con una configurazione non valida o vuota non venga aperto e consenta al traffico di rete non autorizzato di passare per un breve periodo di tempo mentre l'operatore corregge l'errore. Questo comportamento mantiene il servizio disponibile, anziché essere chiuso senza errori e bloccare il 100% del traffico. Il servizio deve basarsi su controlli di autenticazione e autorizzazione più in profondità nello stack delle applicazioni per proteggere le aree sensibili mentre tutto il traffico passa attraverso.
• Tuttavia, è preferibile che un componente server delle autorizzazioni che controlla l'accesso ai dati utente non venga chiuso correttamente e blocchi tutti gli accessi. Questo comportamento causa un'interruzione del servizio quando la configurazione è danneggiata, ma evita il rischio di fuga di dati utente riservati in caso di errore di apertura.

In entrambi i casi, l'errore dovrebbe generare un avviso ad alta priorità per consentire all'operatore di correggere la condizione di errore. I componenti del servizio non dovrebbero essere aperti correttamente, a meno che non comportino rischi estremi per l'azienda.

Progetta chiamate API e comandi operativi in modo che siano ripetibili

Le API e gli strumenti operativi devono rendere le chiamate sicure il più possibile per riprovare. Un approccio naturale a molte condizioni di errore è riprovare a eseguire l'azione precedente, ma potresti non sapere se il primo tentativo è riuscito.

L'architettura del sistema dovrebbe rendere le azioni idempotenti: se esegui l'azione identica su un oggetto due o più volte in successione, dovresti ottenere gli stessi risultati di una singola chiamata. Le azioni non idempotenti richiedono un codice più complesso per evitare il danneggiamento dello stato del sistema.

Identifica e gestisci le dipendenze del servizio

I designer e i proprietari dei servizi devono gestire un elenco completo delle dipendenze sugli altri componenti di sistema. La progettazione del servizio deve includere anche il ripristino da errori di dipendenza o una riduzione controllata se il ripristino completo non è fattibile. Tieni conto delle dipendenze dai servizi cloud utilizzati dal tuo sistema e da dipendenze esterne, ad esempio API di servizi di terze parti, riconoscendo che ogni dipendenza del sistema ha una percentuale di errori diversa da zero.

Quando imposti target di affidabilità, considera che lo SLO per un servizio è vincolato matematicamente dagli SLO di tutte le sue dipendenze critiche. Non puoi essere più affidabile dello SLO più basso di una delle dipendenze. Per ulteriori informazioni, consulta il calcolo della disponibilità dei servizi.

Dipendenze di avvio

All'avvio, i servizi si comportano in modo diverso rispetto a quelli in stato stazionario. Le dipendenze di avvio possono essere sensibilmente diverse da quelle in stato di runtime.

Ad esempio, all'avvio un servizio potrebbe dover caricare informazioni sull'utente o sull'account da un servizio di metadati utente che richiama raramente. Quando molte repliche di servizi si riavviano dopo un arresto anomalo o una manutenzione di routine, le repliche possono aumentare notevolmente il carico sulle dipendenze di avvio, soprattutto quando le cache sono vuote e devono essere ricompilate.

Testa l'avvio del servizio sotto carico ed esegui il provisioning delle dipendenze di avvio di conseguenza. Valuta una progettazione per eseguire la riduzione controllata salvando una copia dei dati recuperati da dipendenze di avvio critiche. Questo comportamento consente il riavvio del servizio con dati potenzialmente inattivi, anziché l'impossibilità di avviarsi quando una dipendenza critica ha un'interruzione. Il servizio può in seguito caricare dati aggiornati, ove possibile, per tornare al normale funzionamento.

Le dipendenze di avvio sono importanti anche quando esegui il bootstrap di un servizio in un nuovo ambiente. Progetta lo stack di applicazioni con un'architettura a più livelli, senza dipendenze cicliche tra i livelli. Le dipendenze cicliche possono sembrare tollerabili perché non bloccano le modifiche incrementali a una singola applicazione. Tuttavia, le dipendenze cicliche possono rendere difficile o impossibile il riavvio dopo che una emergenza ha rimosso l'intero stack di servizi.

Riduci al minimo le dipendenze critiche

Riduci al minimo il numero di dipendenze critiche per il tuo servizio, ovvero altri componenti i cui errori causeranno inevitabilmente interruzioni del servizio. Per rendere il tuo servizio più resiliente agli errori o alla lentezza degli altri componenti da cui dipende, considera le seguenti tecniche e principi di progettazione di esempio per convertire le dipendenze critiche in dipendenze non critiche:

• Aumenta il livello di ridondanza nelle dipendenze critiche. L'aggiunta di più repliche riduce la probabilità che un intero componente non sia disponibile.
• Utilizza le richieste asincrone ad altri servizi anziché bloccare una risposta o usa i messaggi di pubblicazione/sottoscrizione per disaccoppiare le richieste dalle risposte.
• Memorizza nella cache le risposte di altri servizi per recuperare dall'indisponibilità a breve termine delle dipendenze.

Per rendere gli errori o la lentezza del servizio meno dannosi per altri componenti che dipendono da questo, prendi in considerazione le tecniche e i principi di progettazione riportati di seguito:

• Utilizza code di richieste prioritarie e dai una priorità maggiore alle richieste in cui un utente sta aspettando una risposta.
• Pubblica le risposte fuori dalla cache per ridurre latenza e carico.
• Fail Safe in modo da preservare il funzionamento.
• Esegui la riduzione controllata in caso di sovraccarico di traffico.

Assicurati che sia possibile eseguire il rollback di ogni modifica

Se non esiste un modo ben definito per annullare determinati tipi di modifiche a un servizio, modifica il design del servizio per supportare il rollback. Testa periodicamente il processo di rollback. È necessario eseguire il controllo della versione delle API per ogni componente o microservizio, garantendo la compatibilità con le versioni precedenti affinché le generazioni precedenti dei client continuino a funzionare correttamente con l'evoluzione dell'API. Questo principio di progettazione è essenziale per consentire un'implementazione progressiva delle modifiche all'API, con rollback rapido quando necessario.

Il rollback può essere costoso da implementare per le app mobile. Firebase Remote Config è un servizio di Google Cloud che semplifica il rollback delle funzionalità.

Non puoi eseguire rapidamente il rollback delle modifiche allo schema del database, quindi eseguile in più fasi. Progetta ogni fase per consentire la lettura e l'aggiornamento degli schemi sicuri da parte della versione più recente dell'applicazione e di quella precedente. Questo approccio di progettazione consente di eseguire in sicurezza il rollback in caso di problemi con la versione più recente.

Suggerimenti

Per applicare al tuo ambiente le indicazioni contenute nel framework dell'architettura, segui questi suggerimenti:

• Implementa il backoff esponenziale con la randomizzazione nella logica dei nuovi tentativi di errore delle applicazioni client.
• Implementa un'architettura multiregionale con failover automatico per l'alta disponibilità.
• Utilizza il bilanciamento del carico per distribuire le richieste degli utenti tra shard e regioni.
• Progetta l'applicazione in modo da eseguire correttamente la riduzione in caso di sovraccarico. Fornisci risposte parziali o fornisci funzionalità limitate anziché fallire del tutto.
• Stabilire un processo basato sui dati per la pianificazione della capacità e utilizzare i test di carico e le previsioni di traffico per determinare quando eseguire il provisioning delle risorse.
• Stabilire procedure di ripristino di emergenza e testarle periodicamente.

Passaggi successivi

• Crea processi operativi e strumenti affidabili (prossimo documento di questa serie)

Esplora altre categorie nel framework dell'architettura, come progettazione del sistema, eccellenza operativa e sicurezza, privacy e conformità.

Crea processi operativi e strumenti affidabili

Questo documento nel framework dell'architettura Google Cloud fornisce i principi operativi per eseguire il tuo servizio in modo affidabile, ad esempio come eseguire il deployment degli aggiornamenti, eseguire servizi in ambienti di produzione e testare gli errori. Un'architettura per l'affidabilità dovrebbe coprire l'intero ciclo di vita del tuo servizio, non solo la progettazione del software.

Scegli nomi appropriati per applicazioni e servizi

Evita di utilizzare nomi in codice interni nei file di configurazione di produzione, perché potrebbero generare confusione, in particolare per i dipendenti più recenti, e aumentare potenzialmente i tempi di mitigazione (TTM) in caso di interruzioni. Scegli il più possibile nomi appropriati per tutte le tue applicazioni, i tuoi servizi e le tue risorse di sistema critiche, come VM, cluster e istanze di database, rispettando i rispettivi limiti di lunghezza dei nomi. Un nome appropriato descrive lo scopo dell'entità, è preciso, specifico e distintivo ed è significativo per chiunque lo vede. Un nome corretto evita acronimi, nomi in codice, abbreviazioni e terminologia potenzialmente offensiva e non creerebbe una risposta pubblica negativa anche se pubblicata esternamente.

Esegui implementazioni progressive con i test canary

Le modifiche globali istantanee ai programmi binari o alla configurazione dei servizi sono intrinsecamente rischiose. Implementa nuove versioni degli eseguibili e apporta modifiche alla configurazione in modo incrementale. Inizia con un ambito piccolo, ad esempio alcune istanze VM in una zona, ed espandi gradualmente l'ambito. Esegui rapidamente il rollback se la modifica non funziona come previsto o ha un impatto negativo sugli utenti in qualsiasi fase dell'implementazione. Il tuo obiettivo è identificare e risolvere i bug quando interessano solo una piccola parte del traffico degli utenti, prima di implementare la modifica a livello globale.

Configura un sistema di test canary che sia consapevole delle modifiche al servizio ed esegua il confronto A/B delle metriche dei server modificati con quelli dei server rimanenti. Il sistema deve segnalare comportamenti imprevisti o anomali. Se la modifica non genera il rendimento previsto, il sistema di test canary dovrebbe interrompere automaticamente le implementazioni. I problemi possono essere chiari, ad esempio errori utente, o poco visibili, come l'aumento dell'utilizzo della CPU o il sovraccarico della memoria.

È meglio interrompere ed eseguire il rollback al primo suggerimento e diagnosticare i problemi senza il carico di lavoro di un'interruzione. Dopo che la modifica ha superato i test canary, propagala gradualmente ad ambiti più grandi, ad esempio a una zona completa e poi a una seconda zona. Lascia al sistema cambiato il tempo di gestire volumi sempre più elevati di traffico degli utenti in modo da esporre eventuali bug latenti.

Per maggiori informazioni, consulta Strategie di test e deployment delle applicazioni.

Diffondi il traffico per promozioni e lanci a tempo

Potresti avere eventi promozionali, ad esempio saldi che iniziano a un orario specifico e incoraggiano molti utenti a connettersi contemporaneamente al servizio. Se sì, progetta il codice client in modo da distribuire il traffico in pochi secondi. Utilizza ritardi casuali prima che avviino le richieste.

Puoi anche preriscaldare l'impianto. Quando preriscalda il sistema, invii in anticipo il traffico utente previsto per assicurarti che funzioni come previsto. Questo approccio impedisce picchi di traffico istantanei che potrebbero causare l'arresto anomalo dei tuoi server all'ora di inizio pianificata.

Automatizza build, test e deployment

Elimina lo sforzo manuale dal processo di rilascio con l'uso di pipeline di integrazione continua e distribuzione continua (CI/CD). Esegui test di integrazione e deployment automatizzati. Ad esempio, crea un processo CI/CD moderno con GKE.

Per maggiori informazioni, consulta integrazione continua, distribuzione continua, automazione dei test e automazione del deployment.

Difenditi dall'errore dell'operatore

Progetta gli strumenti operativi in modo da rifiutare configurazioni potenzialmente non valide. Rileva e invia un avviso quando una versione della configurazione è vuota, parziale o troncata, danneggiata, logicamente errata o imprevista o non viene ricevuta nei tempi previsti. Gli strumenti dovrebbero inoltre rifiutare le versioni di configurazione che differiscono troppo rispetto alla versione precedente.

Non consentire le modifiche o i comandi con un ambito troppo ampio che sono potenzialmente distruttivi. Questi comandi generici potrebbero essere "Revoca le autorizzazioni per tutti gli utenti", "Riavvia tutte le VM in questa regione" o "Riformatta tutti i dischi in questa zona". Queste modifiche devono essere applicate solo se l'operatore aggiunge flag della riga di comando di override di emergenza o impostazioni delle opzioni durante il deployment della configurazione.

Gli strumenti devono mostrare l'impatto dei comandi rischiosi, ad esempio il numero di VM che incidono sulle modifiche, e devono richiedere un consenso esplicito dell'operatore prima che lo strumento prosegua. Puoi anche utilizzare funzionalità per bloccare le risorse critiche e impedirne l'eliminazione accidentale o non autorizzata, ad esempio i blocchi dei criteri di conservazione di Cloud Storage.

Test del ripristino da errori

Testa regolarmente le tue procedure operative per il ripristino in caso di errori del tuo servizio. Senza test regolari, le procedure potrebbero non funzionare quando ne hai bisogno se si verifica un errore reale. Gli elementi da testare periodicamente includono il failover regionale, il rollback di una release e il ripristino dei dati dai backup.

Esegui test di ripristino di emergenza

Come per i test di ripristino da errori, non aspettare l'evento di emergenza. Testa e verifica periodicamente le procedure e i processi di ripristino di emergenza.

Potresti creare un'architettura di sistema per fornire disponibilità elevata (HA). Questa architettura non si sovrappone completamente al ripristino di emergenza (RE), ma spesso è necessario tenere conto dell'alta disponibilità quando si pensa ai valori dell'RTO (Recovery Time Objective) e del Recovery Point Objective (RPO).

L'alta disponibilità consente di raggiungere o superare un livello concordato di prestazioni operative, come l'uptime. Quando esegui carichi di lavoro di produzione su Google Cloud, potresti eseguire il deployment di un'istanza in standby passivo o attivo in una seconda regione. Con questa architettura, l'applicazione continua a fornire servizio dalla regione non interessata in caso di emergenza nella regione principale. Per maggiori informazioni, consulta Architettura del ripristino di emergenza per le interruzioni del servizio cloud.

Esercitati con l'ingegneria del caos

Considera l'uso dell'ingegneria del caos nelle tue pratiche di test. Introduci guasti effettivi in diversi componenti dei sistemi di produzione sotto carico in un ambiente sicuro. Questo approccio aiuta a garantire che non ci sia alcun impatto complessivo sul sistema, perché il servizio gestisce correttamente gli errori a ogni livello.

Gli errori inseriti nel sistema possono includere attività in cui si verificano arresti anomali, errori e timeout sulle RPC o riduzioni della disponibilità delle risorse. Utilizza l'inserimento di errori casuali per testare gli errori intermittenti (flapping) nelle dipendenze del servizio. Questi comportamenti sono difficili da rilevare e mitigare in produzione.

L'ingegneria del caos assicura che le ricadute di questi esperimenti siano ridotte al minimo e contenute. Tratta questi test come pratica per le interruzioni effettive e utilizza tutte le informazioni raccolte per migliorare la risposta alle interruzioni.

Passaggi successivi

• Crea avvisi efficienti (prossimo documento di questa serie)

Esplora altre categorie nel framework dell'architettura, come progettazione del sistema, eccellenza operativa e sicurezza, privacy e conformità.

Creazione di avvisi efficienti

Questo documento nel framework dell'architettura Google Cloud fornisce i principi operativi per creare avvisi che consentono di eseguire servizi affidabili. Più informazioni hai sulle prestazioni del tuo servizio, più informate saranno le tue decisioni in caso di problemi. Progetta gli avvisi per un rilevamento tempestivo e accurato di tutti i problemi di sistema che incidono sugli utenti e riduci al minimo i falsi positivi.

Ottimizza il ritardo di avviso

Esiste un equilibrio tra gli avvisi inviati troppo presto, che sollecitano il team operativo, e quelli inviati troppo tardi, che causano lunghe interruzioni del servizio. Ottimizza il ritardo degli avvisi prima che il sistema di monitoraggio segnali un problema agli utenti per ridurre al minimo il tempo di rilevamento, massimizzando al contempo il segnale rispetto al rumore. Utilizza il tasso di consumo del budget di errore per ricavare la configurazione ottimale degli avvisi.

Definisci gli avvisi in base ai sintomi non alle cause

Consente di attivare avvisi in base all'impatto diretto sull'esperienza utente. La non conformità con SLO globali o per cliente indica un impatto diretto. Non creare avvisi su ogni possibile causa principale di un errore, soprattutto se l'impatto è limitato a una singola replica. Un sistema distribuito ben progettato si ripristina senza problemi da guasti a replica singola.

Avvisa in base ai valori anomali anziché alle medie

Quando monitori la latenza, definisci gli SLO e imposta gli avvisi per (scegline due su tre) la latenza al 90°, 95° o 99° percentile, non per la latenza media o al 50° percentile. Valori di latenza media o mediana buoni possono nascondere valori inaccettabilmente elevati al 90° percentile o oltre che causano esperienze utente molto negative. Dovresti quindi applicare questo principio di avviso sui valori anomali durante il monitoraggio della latenza per qualsiasi operazione critica, come un'interazione richiesta-risposta con un server web, il completamento batch in una pipeline di elaborazione dati o un'operazione di lettura o scrittura su un servizio di archiviazione.

Costruisci un processo collaborativo di gestione degli incidenti

Questo documento nel framework dell'architettura Google Cloud fornisce le best practice per gestire i servizi e definire i processi per rispondere agli incidenti. Poiché gli incidenti si verificano in tutti i servizi, è necessario disporre di un processo ben documentato per rispondere in modo efficiente a questi problemi e mitigarli.

Panoramica sulla gestione degli incidenti

È inevitabile che un sistema ben progettato alla fine non riesca a raggiungere gli SLO. In assenza di uno SLO, i clienti definiscono in modo approssimativo il livello di servizio accettabile in base alla loro esperienza passata. I clienti passano all'assistenza tecnica o a un gruppo simile, indipendentemente dai requisiti dello SLA (accordo sul livello del servizio).

Per servire adeguatamente i clienti, stabilisci e testa regolarmente un piano di gestione degli incidenti. Il piano può essere anche un elenco di controllo di una sola pagina con dieci elementi. Questo processo consente al tuo team di ridurre i tempi di rilevamento (TTD) e di mitigazione (TTM).

Il tempo di attenuazione è preferibile al tempo del TTR, dove la R per la riparazione o il ripristino è spesso utilizzata per indicare una correzione completa invece che la mitigazione. TTM mette in evidenza la mitigazione rapida per porre fine rapidamente all'impatto di un'interruzione sul cliente e quindi avviare una procedura, spesso molto più lunga, per risolvere completamente il problema.

Un sistema ben progettato in cui le operazioni sono eccellenti aumenta il tempo tra gli errori (TBF). In altri termini, i principi operativi di affidabilità, tra cui una buona gestione degli incidenti, mirano a ridurre la frequenza degli errori.

Per eseguire servizi affidabili, applica le seguenti best practice nel processo di gestione degli incidenti.

Assegna una chiara proprietà del servizio

Tutti i servizi e le loro dipendenze critiche devono avere proprietari chiari responsabili del rispetto dei relativi SLO. In caso di riorganizzazioni o abbandono di team, i responsabili tecnici devono assicurare che la proprietà venga esplicitamente trasferita a un nuovo team, insieme alla documentazione e alla formazione necessarie. I proprietari di un servizio devono essere facilmente rilevabili dagli altri team.

Riduci il tempo di rilevamento (TTD) con avvisi ottimizzati

Prima di poter ridurre il TTD, rivedi e implementa i suggerimenti nella sezione relativa all'implementazione dell'osservabilità nella tua infrastruttura e nelle tue applicazioni e le sezioni definite gli obiettivi di affidabilità della categoria di affidabilità del framework dell'architettura. Ad esempio, puoi fare chiarezza tra problemi delle applicazioni e problemi cloud sottostanti.

Un insieme ottimizzato di SLI avvisa il tuo team al momento giusto senza sovraccarico di avvisi. Per ulteriori informazioni, consulta la sezione Creare avvisi efficienti della categoria di affidabilità del framework dell'architettura o Ottimizzare le metriche SLI: lezioni sulla vita CRE.

Ridurre i tempi di mitigazione (TTM) con piani e formazione per la gestione degli incidenti

Per ridurre il tempo di attenuazione, definisci un piano di gestione degli incidenti documentato e ben sperimentato. Disporre di dati facilmente reperibili su cosa è cambiato nell'ambiente. Assicurati che i team conoscano le mitigazioni generiche da applicare rapidamente per ridurre al minimo il tempo di attenuazione. Queste tecniche di mitigazione includono lo svuotamento, il rollback delle modifiche, l'aumento delle risorse e il degrado della qualità del servizio.

Come discusso in un altro documento della categoria di affidabilità del framework dell'architettura, crea processi operativi e strumenti affidabili per supportare il rollback rapido e sicuro delle modifiche.

Progetta layout e contenuti della dashboard per ridurre al minimo il tempo di attenuazione

Organizza il layout e la navigazione della dashboard dei servizi in modo che un operatore possa determinare in un paio di minuti se il servizio e tutte le sue dipendenze critiche sono in esecuzione. Per individuare rapidamente le potenziali cause dei problemi, gli operatori devono essere in grado di analizzare tutti i grafici della dashboard per cercare rapidamente grafici che cambiano in modo significativo al momento dell'avviso.

Il seguente elenco di grafici di esempio potrebbe essere presente nella tua dashboard per aiutarti a risolvere i problemi. Coloro che rispondono agli eventi dovrebbero essere in grado di guardarli in un'unica vista:

• Indicatori del livello del servizio, come le richieste andate a buon fine diviso per il numero di richieste valide totali
• Configurazione e implementazioni binarie
• Richieste al sistema al secondo
• Risposte di errore al secondo dal sistema
• Richieste al secondo dal sistema alle sue dipendenze
• Risposte di errore al secondo al sistema dalle sue dipendenze

Altri grafici comuni per la risoluzione dei problemi includono la latenza, la saturazione, le dimensioni della richiesta, le dimensioni della risposta, il costo della query, l'utilizzo del pool di thread e le metriche di Java Virtual Machine (JVM), se applicabile. La saturazione si riferisce all'pienezza in base a un limite, ad esempio la quota o la dimensione della memoria di sistema. L'utilizzo del pool di Thread cerca le regressioni dovute all'esaurimento del pool.

Testa il posizionamento di questi grafici su alcuni scenari di interruzione del servizio per assicurarti che i grafici più importanti siano nella parte superiore e che l'ordine dei grafici corrisponda al tuo flusso di lavoro di diagnostica standard. Puoi anche applicare il machine learning e il rilevamento di anomalie statistiche per far emergere il sottoinsieme corretto di questi grafici.

Documentare le procedure diagnostiche e la mitigazione per gli scenari di interruzione noti

Scrivi i playbook e inserisci i link nelle notifiche di avviso. Se questi documenti sono accessibili dalle notifiche di avviso, gli operatori possono ottenere rapidamente le informazioni di cui hanno bisogno per risolvere e mitigare i problemi.

Usare dati post-mortem senza colpa per apprendere dalle interruzioni ed evitare che si ripetano

Stabilisci una coltura post mortem senza colpevolizza e un processo di revisione degli incidenti. Non responsabile significa che il tuo team valuta e documenta gli errori in modo oggettivo, senza bisogno di attribuirli.

Gli errori sono opportunità di apprendimento, non motivo di critiche. Cerca sempre di rendere il sistema più resiliente in modo che possa recuperare rapidamente gli errori umani o, ancora meglio, rilevare e prevenire errori umani. Estrai quante più informazioni possibili da ogni post mortem e follow-up diligentemente su ciascuna attività post mortem al fine di rendere le interruzioni meno frequenti, con un conseguente aumento del TBF.

Esempio di piano di gestione degli incidenti

Sono stati rilevati problemi di produzione, ad esempio tramite un avviso o una pagina, oppure riassegnati a me:

• Devo delegare a qualcun altro?
  • Sì, se tu e il tuo team non siete in grado di risolvere il problema.
• Si tratta di una violazione della privacy o della sicurezza?
  • In caso affermativo, delega il team al team responsabile della privacy o della sicurezza.
• Questo problema è un'emergenza o gli SLO sono a rischio?
  • In caso di dubbi, consideralo come un'emergenza.
• Devo coinvolgere più persone?
  • Sì, se interessa più del X% dei clienti o se la risoluzione richiede più di Y minuti. Nel dubbio, coinvolgi sempre più persone, soprattutto durante l'orario di lavoro.
• Definisci un canale di comunicazione principale, come IRC, Hangouts Chat o Slack.
• Delega i ruoli definiti in precedenza, ad esempio:
  • Incident Commander, responsabile del coordinamento generale.
  • Responsabile delle comunicazioni responsabile delle comunicazioni interne ed esterne.
  • Operations Lead responsabile di mitigare il problema.
• Definisci quando l'incidente è terminato. Questa decisione potrebbe richiedere il consenso di un rappresentante dell'assistenza o di altri team simili.
• Collabora all'incolpevole post mortem.
• Partecipa a una riunione per la revisione degli incidenti post mortem per discutere delle attività del personale.

Suggerimenti

Per applicare al tuo ambiente le indicazioni contenute nel framework dell'architettura, segui questi suggerimenti:

• Definire un piano di gestione degli incidenti e formare i team a utilizzarlo.
• Per ridurre il TTD, implementa i suggerimenti per integrare l'osservabilità dell'infrastruttura e delle applicazioni.
• Crea una dashboard "Che cosa è cambiato?" da poter analizzare in caso di incidente.
• snippet di query su documenti o crea una dashboard di Looker Studio con query di log frequenti.
• Valuta Firebase Remote Config per mitigare i problemi di implementazione per le app mobile.
• Testa il ripristino da errori, incluso il ripristino dei dati dai backup, per ridurre il tempo di attenuazione per un sottoinsieme di incidenti.
• Progetta e testa la configurazione e i rollback dei programmi binari.
• Replica i dati tra regioni per il ripristino di emergenza e utilizza i test di ripristino di emergenza per ridurre il tempo di attenuazione dopo interruzioni a livello di regione.
• Progetta un'architettura multiregionale per la resilienza alle interruzioni regionali se l'esigenza aziendale di disponibilità elevata giustifica i costi per aumentare il TBF.

Passaggi successivi

Scopri di più su come creare un processo collaborativo di gestione degli incidenti con le seguenti risorse:

• Dashboard dello stato di Google Cloud
• Gestione degli incidenti in Google
• Processo di risposta agli incidenti relativi ai dati
• Capitolo del libro SRE sulla gestione degli incidenti

Esplora altre categorie nel framework dell'architettura, come progettazione del sistema, eccellenza operativa e sicurezza, privacy e conformità.

Framework dell'architettura Google Cloud: guide sull'affidabilità del prodotto

Questa sezione del framework dell'architettura contiene linee guida sulle best practice specifiche del prodotto per l'affidabilità, la disponibilità e la coerenza di alcuni prodotti Google Cloud. Le guide forniscono inoltre suggerimenti per ridurre al minimo e recuperare gli errori e per scalare le applicazioni in modo ottimale sotto carico.

Nota: per saperne di più sui componenti di base a livello di piattaforma per l'affidabilità in Google Cloud (zone, regioni e risorse con ambito di località) e i livelli di disponibilità forniti, consulta la guida all'affidabilità dell'infrastruttura Google Cloud. Questa guida fornisce inoltre linee guida per valutare i requisiti di affidabilità dei carichi di lavoro e suggerimenti di architettura per la creazione e la gestione di infrastrutture affidabili in Google Cloud.

Le guide sull'affidabilità dei prodotti sono organizzate nelle seguenti aree:

• Computing
  • Compute Engine
  • Cloud Run
  • Cloud Functions
  • Google Kubernetes Engine
• Archiviazione e database
  • Cloud Storage
  • Firestore
  • Bigtable
  • Cloud SQL
  • Spanner
  • Filestore
  • Memorystore
• Networking
  • Cloud DNS
  • Cloud Load Balancing
  • Cloud CDN
• Analisi di dati
  • BigQuery
  • Dataflow
  • Dataproc

Guida all'affidabilità di Compute Engine

Compute Engine è un servizio di computing personalizzabile che consente agli utenti di creare ed eseguire macchine virtuali on demand sull'infrastruttura di Google.

best practice

• Best practice per l'API Compute Engine: best practice consigliate per l'utilizzo dell'API Compute Engine e la mitigazione degli effetti dei limiti di frequenza dell'API.
• Progettazione di sistemi resilienti: indicazioni dettagliate su come progettare l'architettura delle applicazioni Compute Engine per il ripristino in caso di errori o riavvii di una singola VM, nonché in caso di errori a livello di zona o di regione.
• Come aumentare la disponibilità con il provisioning eccessivo: aggiungi risorse ridondanti per mantenere l'applicazione operativa a causa di perdite di capacità dovute a interruzioni a livello di zona o di regione.
• Utilizzo del bilanciamento del carico per le applicazioni ad alta disponibilità: come utilizzare Cloud Load Balancing con Compute Engine per garantire alta disponibilità, anche durante un'interruzione di zona.
• Best practice per la selezione delle regioni di Compute Engine: come scegliere le regioni Google Cloud da utilizzare per le tue risorse Compute Engine al fine di ottimizzare la latenza per le tue applicazioni tenendo conto dei compromessi in termini di prezzo/prestazioni.
• Best practice per la migrazione delle VM con Migrate to Virtual Machines: come eseguire la migrazione delle VM da un ambiente di origine supportato a Compute Engine con Migrate to Virtual Machines, incluse valutazione, pianificazione ed esecuzione della migrazione. Inoltre, spiegheremo come risolvere problemi comuni che potrebbero sorgere con la migrazione.
• Pattern per l'utilizzo di indirizzi IP mobili in Compute Engine: come implementare indirizzi IP condivisi o virtuali in un ambiente Compute Engine modificando l'architettura in un pattern per il tuo caso d'uso. I pattern includono quelli che utilizzano il bilanciamento del carico, le route Google Cloud e la riparazione automatica.
• Best practice per disco permanente permanenti: crea snapshot più rapidamente e con maggiore affidabilità.
• Dischi permanenti e replica: la modalità di utilizzo dei dischi permanenti con Colossus per il backend di archiviazione e l'accesso ai dischi permanenti dalle VM. Inoltre, monitora la latenza dei disco permanente, replica di dischi permanenti tra regioni o zone e come vengono gestite le richieste di lettura e scrittura per le repliche.
• Configura i dischi per soddisfare i requisiti delle prestazioni: fattori che influiscono sulle prestazioni dei volumi di archiviazione a blocchi collegati alle istanze VM.
• Best practice per la gestione delle immagini: indicazioni dettagliate sulla gestione delle immagini Compute Engine, ad esempio sulla scelta di un'immagine di avvio, sulla personalizzazione delle immagini, sul ciclo di vita delle immagini e sulla loro condivisione tra progetti.
• Best practice per le famiglie di immagini: l'importanza di testare l'immagine più recente in una famiglia di immagini prima di utilizzarla in produzione e come configurare la procedura di test.
• Best practice per le istanze SQL Server: best practice per ottimizzare le istanze di Compute Engine che eseguono Microsoft SQL Server e ottimizzare SQL Server Enterprise Edition. Inoltre, viene spiegato come utilizzare le impostazioni di rete predefinite del sistema operativo e le attività operative per migliorare le prestazioni e la stabilità.

Guida all'affidabilità di Cloud Run

Cloud Run è una piattaforma di computing gestita, adatta al deployment di applicazioni containerizzate, ed è serverless. Cloud Run astrae tutta l'infrastruttura in modo che gli utenti possano concentrarsi sulla creazione delle applicazioni.

best practice

• Suggerimenti generali su Cloud Run: come implementare un servizio Cloud Run, avviare rapidamente i container, utilizzare le variabili globali e migliorare la sicurezza dei container.
• Best practice per i test di carico: come eseguire test di carico dei servizi Cloud Run, ad esempio risolvere problemi di contemporaneità prima del test di carico, gestire il numero massimo di istanze, scegliere la regione migliore per i test di carico e garantire la scalabilità dei servizi in base al carico.
• Scalabilità delle istanze: come scalare e limitare le istanze di container e ridurre al minimo i tempi di risposta mantenendo inattive alcune istanze anziché arrestarle.
• Utilizzando il numero minimo di istanze: specifica il numero minimo di istanze di container pronte per essere gestite e, se impostato in modo adeguato, riduci al minimo il tempo di risposta medio riducendo il numero di avvii a freddo.
• Ottimizzazione delle applicazioni Java per Cloud Run: comprendi i compromessi di alcune ottimizzazioni per i servizi Cloud Run scritti in Java e riduci i tempi di avvio e l'utilizzo della memoria.
• Ottimizzazione delle applicazioni Python per Cloud Run: ottimizza l'immagine container migliorando l'efficienza del server WSGI e ottimizza le applicazioni riducendo il numero di thread ed eseguendo le attività di avvio in parallelo.

Guida all'affidabilità di Cloud Functions

Cloud Functions è una piattaforma serverless, scalabile e basata su eventi che consente di creare e connettere servizi. Le funzioni Cloud Functions possono essere chiamate tramite richiesta HTTP o attivate in base a eventi in background.

best practice

• Best practice di Cloud Functions: linee guida su come utilizzare e interagire con Cloud Functions, implementare l'idempotenza, eseguire il deployment delle funzioni e ottimizzare le prestazioni.

Guida all'affidabilità di Google Kubernetes Engine

Google Kubernetes Engine (GKE) è un sistema per il funzionamento delle applicazioni containerizzate nel cloud, su larga scala. GKE esegue il deployment, gestisce ed esegue il provisioning delle risorse per le tue applicazioni containerizzate. L'ambiente GKE è composto da istanze di Compute Engine raggruppate per formare un cluster.

best practice

• Best practice per l'utilizzo dei container: come utilizzare i meccanismi di logging, garantire che i container siano stateless e immutabili, monitorare le applicazioni ed eseguire probe di attività e idoneità.
• Best practice per la creazione di container: come pacchettizzare una singola applicazione per container, gestire gli identificatori di processo (PID), ottimizzare per la cache delle build Docker e creare immagini più piccole per tempi di caricamento e download più rapidi.
• Best practice per il networking di Google Kubernetes Engine - Utilizza cluster nativi di VPC per scalare più facilmente, pianificare gli indirizzi IP, scalare la connettività dei cluster, utilizzare Google Cloud Armor per bloccare gli attacchi Distributed Denial-of-Service (DDoS), implementare il bilanciamento del carico nativo del container per una minore latenza, utilizzare la funzionalità di controllo di integrità degli Application Load Balancer esterni per un failover controllato e utilizzare i cluster a livello di regione per aumentare la disponibilità delle applicazioni in un cluster.
• Prepara le applicazioni Kubernetes basate su cloud: impara le best practice per pianificare la capacità dell'applicazione, far crescere l'applicazione orizzontalmente o verticalmente, impostare limiti delle risorse in base alle richieste di risorse per la memoria rispetto alla CPU, rendere i container più semplici per un avvio più rapido delle applicazioni e limitare l'interruzione di Pod impostando un Pod Disruption Budget (PDB). Inoltre, scopri come configurare probe di attività e probe di idoneità per un avvio controllato delle applicazioni, garantire arresti non improvvisi e implementare il backoff esponenziale sulle richieste ripetute per evitare picchi di traffico che sovraccaricano l'applicazione.
• Best practice per la multi-tenancy di GKE: come progettare un'architettura di cluster multi-tenant per alta disponibilità e affidabilità, utilizzare la misurazione dell'utilizzo di Google Kubernetes Engine (GKE) per le metriche di utilizzo per-tenant, fornire log specifici per il tenant e fornire il monitoraggio specifico per il tenant.

Guida all'affidabilità di Cloud Storage

Cloud Storage è un repository di oggetti durevole e ad alta disponibilità con funzionalità avanzate di sicurezza e condivisione. Questo servizio viene utilizzato per l'archiviazione e l'accesso ai dati nell'infrastruttura Google Cloud.

best practice

• Best practice per Cloud Storage: best practice generali per Cloud Storage, che includono suggerimenti per massimizzare la disponibilità e ridurre al minimo la latenza delle applicazioni, per migliorare l'affidabilità delle operazioni di caricamento e le prestazioni dell'eliminazione di dati su larga scala.
• Linee guida per tasso di richieste e distribuzione degli accessi: come ridurre al minimo la latenza e le risposte di errore durante le operazioni di lettura, scrittura ed eliminazione con tassi di richieste molto elevati grazie alla comprensione del funzionamento della scalabilità automatica di Cloud Storage.

Guida all'affidabilità di Firestore

Firestore è un database di documenti NoSQL che consente di archiviare, sincronizzare ed eseguire query sui dati per applicazioni web e mobile a livello globale.

best practice

• Best practice di Firestore: come selezionare la posizione del database per una maggiore affidabilità, ridurre al minimo gli errori di prestazioni nell'indicizzazione, migliorare le prestazioni delle operazioni di lettura e scrittura, ridurre la latenza per le notifiche delle modifiche e progettare per la scalabilità.

Guida all'affidabilità di Bigtable

Bigtable è un database NoSQL scalabile e completamente gestito per carichi di lavoro analitici e operativi di grandi dimensioni. È progettata come una tabella scarsamente popolata che può scalare fino a miliardi di righe e migliaia di colonne e supporta un'elevata velocità effettiva di lettura e scrittura con latenza ridotta.

best practice

• Comprendi le prestazioni di Bigtable: stima della velocità effettiva per Bigtable, come pianificare la capacità di Bigtable in base alla velocità effettiva e all'utilizzo dello spazio di archiviazione, in che modo l'abilitazione della replica influisce sulla velocità effettiva di lettura e scrittura in modo diverso e in che modo Bigtable ottimizza i dati nel tempo.
• Progettazione dello schema Bigtable: indicazioni sulla progettazione dello schema Bigtable, inclusi concetti di archivio chiave/valore, progettazione di chiavi di riga in base a richieste di lettura pianificate, gestione di colonne e righe e casi d'uso speciali.
• Panoramica della replica di Bigtable per informazioni su come replicare Bigtable in più zone o regioni, comprendere le implicazioni in termini di prestazioni della replica e in che modo Bigtable risolve i conflitti e gestisce i failover.
• Informazioni sui backup di Bigtable: come salvare una copia dello schema e dei dati di una tabella con i backup di Bigtable, che può aiutarti a recuperare dati danneggiati a livello di applicazione o errori degli operatori, come l'eliminazione accidentale di una tabella.

Guida all'affidabilità di Cloud SQL

Cloud SQL è un servizio di database relazionale completamente gestito per MySQL, PostgreSQL e SQL Server. Cloud SQL si integra facilmente con le applicazioni e i servizi Google Cloud esistenti come Google Kubernetes Engine e BigQuery.

best practice

• Alta disponibilità di Cloud SQL: una panoramica della configurazione ad alta disponibilità per Cloud SQL, tra cui la gestione delle repliche di lettura e il processo di failover. Include inoltre come controllare la tempistica degli eventi di manutenzione del database e come l'uso di un disco permanente a livello di regione nella configurazione ad alta disponibilità influisce sulle prestazioni del database. Questi contenuti sono suddivisi in tre sezioni:

  • Alta disponibilità MySQL
  • Alta disponibilità di PostgreSQL
  • Alta disponibilità di SQL Server

• Ripristino di emergenza del database Cloud SQL: una panoramica della configurazione del ripristino di emergenza per Cloud SQL utilizzando una replica di lettura tra regioni.

  • Ripristino di emergenza MySQL
  • Ripristino di emergenza di PostgreSQL
  • Ripristino di emergenza di SQL Server

• Best practice generali per Cloud SQL: indicazioni su come configurare le istanze, l'architettura dei dati, l'importazione e l'esportazione dei dati, nonché il backup e il ripristino. Questi contenuti sono suddivisi in tre sezioni:

  • Best practice per MySQL
  • Best practice per PostgreSQL
  • Best practice per SQL Server

• Best practice per l'importazione e l'esportazione dei dati: in quali circostanze non è possibile utilizzare i bucket Cloud Storage, comprimere i dati per ridurre i costi, limitazioni note per l'importazione e l'esportazione dei dati, come automatizzare le operazioni di esportazione e risolvere i problemi delle operazioni di importazione ed esportazione.

  • Best practice per MySQL
  • Best practice per PostgreSQL
  • Best practice per SQL Server

Guida all'affidabilità di Spanner

Spanner è un servizio di gestione e archiviazione di database SQL distribuito, con funzionalità come transazioni globali, scalabilità orizzontale ad alta disponibilità e coerenza transazionale.

best practice

• Backup e ripristino di Spanner: funzionalità principali di Backup e ripristino di Spanner, confronto di Backup e ripristino con importazione ed esportazione, dettagli di implementazione e come controllare l'accesso alle risorse Spanner.
• Configurazioni a livello di regione e più regioni: descrizione dei due tipi di configurazioni di istanza offerte da Spanner: configurazioni per regione e configurazioni per più regioni. La descrizione include le differenze e i compromessi tra ciascuna configurazione.
• Scalabilità automatica di Spanner: introduzione allo strumento del gestore della scalabilità automatica per Spanner, uno strumento open source che puoi utilizzare come strumento complementare a Cloud Spanner. Questo strumento consente di aumentare o ridurre automaticamente il numero di nodi o di unità di elaborazione in una o più istanze Spanner in base alle metriche di utilizzo di ciascuna istanza Spanner.
• Informazioni sul recupero point-in-time (PITR): descrizione del recupero point-in-time (PITR) di Spanner, una funzionalità che protegge dall'eliminazione o dalle scritture accidentali di dati Spanner. Ad esempio, un operatore scrive inavvertitamente dei dati o l'implementazione di un'applicazione danneggia il database. Il PITR consente di recuperare facilmente i dati da un momento specifico nel passato (fino a un massimo di sette giorni).
• Best practice di Spanner: indicazioni sul caricamento collettivo, sull'utilizzo del Data Manipulation Language (DML), sulla progettazione dello schema per evitare hotspot e best practice per SQL.

Guida all'affidabilità di Filestore

Filestore è un servizio gestito di archiviazione di file per le applicazioni Google Cloud, con un'interfaccia per il file system e un filesystem condiviso per i dati. Filestore offre Network Attached Storage (NAS) online su scala petabyte per istanze di Compute Engine e Google Kubernetes Engine.

best practice

• Prestazioni dell'archivio: impostazioni relative alle prestazioni e suggerimenti sul tipo di macchina di Compute Engine, opzioni di montaggio NFS per ottenere le migliori prestazioni sulle istanze VM del client Linux e utilizzo dello strumento fio per testare le prestazioni. Include suggerimenti per migliorare le prestazioni su più risorse Google Cloud.

• Backup di Filestore: descrizione dei backup di Filestore, casi d'uso comuni e best practice per creare e utilizzare i backup.

• Snapshot Filestore: descrizione degli snapshot di Filestore, casi d'uso comuni e best practice per la creazione e l'utilizzo degli snapshot.

• Networking Filestore: requisiti delle risorse di rete e IP necessari per utilizzare Filestore.

Guida all'affidabilità di Memorystore

Memorystore è un archivio in memoria completamente gestito che fornisce una versione gestita di due soluzioni open source di memorizzazione nella cache: Redis e Memcached. Memorystore è scalabile e automatizza attività complesse come il provisioning, la replica, il failover e l'applicazione di patch.

best practice

• Best practice generali di Redis: indicazioni sull'esportazione di backup di Redis Database (RDB), sulle operazioni che richiedono un uso intensivo delle risorse e sulle operazioni che richiedono di nuovo la connessione. Inoltre, sono disponibili informazioni su manutenzione, gestione della memoria e configurazione del connettore di accesso VPC serverless, nonché sulla modalità di connessione di accesso ai servizi privati, monitoraggio e avvisi.
• Best practice per la gestione della memoria Redis: concetti di gestione della memoria, ad esempio operazioni di capacità dell'istanza e configurazione di Maxmemory, esportazione, scalabilità e upgrade della versione, metriche di gestione della memoria e come risolvere una condizione di esaurimento della memoria.
• Redis esponenziale backoff: come funziona il backoff esponenziale, un algoritmo di esempio e come funzionano il backoff massimo e il numero massimo di nuovi tentativi.
• Best practice per la memorizzazione nella cache: come progettare un'applicazione per falle della cache, connettendosi direttamente agli indirizzi IP dei nodi e servizio di individuazione automatica Memcached. Inoltre, indicazioni su come configurare il parametro max-item-size, bilanciare i cluster e utilizzare Cloud Monitoring per monitorare le metriche essenziali.
• Best practice per la gestione della memoria Memcached: configurazione della memoria per un'istanza Memcached, configurazione della memoria riservata, quando aumentare la memoria riservata e metriche per l'utilizzo della memoria.

Guida all'affidabilità di Cloud DNS

Cloud DNS è un DNS (Domain Name System) a bassa latenza che consente di registrare, gestire e gestire i domini. Cloud DNS scala su un numero elevato di zone e record DNS ed è possibile creare e aggiornare milioni di record DNS tramite un'interfaccia utente.

best practice

• Best practice per Cloud DNS: scopri come gestire le zone private, configurare l'inoltro DNS e creare criteri per i server DNS. Include indicazioni sull'utilizzo di Cloud DNS in un ambiente ibrido.

Guida all'affidabilità di Cloud Load Balancing

Cloud Load Balancing è un servizio gestito completamente distribuito e software-defined, progettato per amministrare tutto il tuo traffico. Cloud Load Balancing offre inoltre scalabilità automatica senza interruzioni, bilanciamento del carico di livello 4 e 7 e il supporto di funzionalità come il bilanciamento del carico globale IPv6.

best practice

• Best practice sulle prestazioni: come distribuire il carico tra le istanze dell'applicazione per offrire prestazioni ottimali. Le strategie includono il posizionamento del backend nelle regioni più vicine al traffico, la memorizzazione nella cache, la selezione del protocollo delle regola di forwarding e la configurazione dell'affinità sessione.
• Utilizzo del bilanciamento del carico per le applicazioni ad alta disponibilità: come utilizzare Cloud Load Balancing con Compute Engine per garantire alta disponibilità, anche durante un'interruzione di zona.

Guida all'affidabilità di Cloud CDN

Cloud CDN (Content Delivery Network) è un servizio che accelera la distribuzione dei contenuti internet utilizzando la rete perimetrale di Google per portare i contenuti il più vicino possibile all'utente. Cloud CDN aiuta a ridurre latenza, costi e carico, semplificando la scalabilità dei servizi per gli utenti.

best practice

• Best practice per la distribuzione dei contenuti: come ottimizzare percentuale successi cache utilizzando le chiavi cache, garantire che HTTP/3 sia abilitato per ottenere prestazioni ottimali ed esaminare le metriche di monitoraggio utilizzando la dashboard di monitoraggio personalizzata di Cloud CDN. Inoltre, vedremo come esaminare i report relativi a disponibilità, latenza e velocità effettiva dei test delle prestazioni di terze parti.

Guida all'affidabilità di BigQuery

BigQuery è la piattaforma di data warehouse di Google Cloud per l'archiviazione e l'analisi dei dati su larga scala.

best practice

• Introduzione all'affidabilità: best practice per l'affidabilità e introduzione a concetti quali disponibilità, durabilità e coerenza dei dati.
• Disponibilità e durabilità: i tipi di domini in errore che possono verificarsi nei data center di Google Cloud, in che modo BigQuery fornisce ridondanza dello spazio di archiviazione in base alla località di archiviazione dei dati e perché i set di dati tra regioni migliorano il ripristino di emergenza.
• Best practice per i carichi di lavoro multi-tenant su BigQuery: pattern comuni utilizzati nelle piattaforme dati multi-tenant. Questi pattern includono la garanzia di affidabilità e isolamento per i clienti di fornitori di software as a service (SaaS), importanti quote e limiti di BigQuery per la pianificazione della capacità, l'utilizzo di BigQuery Data Transfer Service per copiare set di dati pertinenti in un'altra regione e altro ancora.
• Utilizza le viste materializzate: scopri come utilizzare le viste materializzate di BigQuery per eseguire query più rapide a costi inferiori, ad esempio eseguire query sulle viste materializzate, allineare le partizioni e comprendere l'ottimizzazione intelligente (riscrittura automatica delle query).

Guida all'affidabilità di Dataflow

Dataflow è un servizio di elaborazione dati completamente gestito che consente uno sviluppo rapido e semplificato di pipeline di dati in modalità flusso utilizzando librerie Apache Beam open source. Dataflow riduce al minimo la latenza, i tempi di elaborazione e i costi tramite la scalabilità automatica e l'elaborazione batch.

best practice

Creazione di pipeline di dati pronte per la produzione utilizzando Dataflow: una serie di documenti sull'utilizzo di Dataflow che include la pianificazione, lo sviluppo, il deployment e il monitoraggio delle pipeline Dataflow.

• Panoramica - introduzione alle pipeline Dataflow.
• Pianificazione: misurazione degli SLO, comprensione dell'impatto di origini dati e sink sulla scalabilità e le prestazioni delle pipeline e prendendo in considerazione l'alta disponibilità, il ripristino di emergenza e le prestazioni di rete quando si specificano le regioni in cui eseguire i job Dataflow.
• Sviluppo e test: configurazione degli ambienti di deployment, prevenzione della perdita di dati utilizzando code di messaggi non recapitabili per la gestione degli errori e riduzione della latenza e dei costi grazie alla riduzione delle costose operazioni per elemento. Inoltre, è possibile usare il batch per ridurre il sovraccarico delle prestazioni senza sovraccaricare i servizi esterni, eliminare i passaggi unificati in modo non appropriato in modo da separare i passaggi per migliorare le prestazioni ed eseguire test end-to-end in preproduzione per garantire che la pipeline continui a soddisfare i tuoi SLO e altri requisiti di produzione.
• Deployment: integrazione continua (CI) e distribuzione e deployment continui (CD), con considerazioni speciali per il deployment di nuove versioni di pipeline in modalità flusso. Inoltre, puoi vedere una pipeline CI/CD di esempio e alcune funzionalità per ottimizzare l'utilizzo delle risorse. Infine, una discussione sull'alta disponibilità, la ridondanza geografica e le best practice per l'affidabilità delle pipeline, tra cui l'isolamento a livello di regione, l'uso degli snapshot, la gestione degli errori di invio dei job e il ripristino da errori e interruzioni che incidono sulle pipeline in esecuzione.
• Monitoraggio: osserva gli indicatori del livello del servizio (SLI), che sono indicatori importanti delle prestazioni delle pipeline e definisci e misura gli obiettivi del livello del servizio (SLO).

Guida all'affidabilità di Dataproc

Dataproc è un servizio scalabile e completamente gestito per l'esecuzione di job Apache Hadoop e Spark. Con Dataproc, puoi personalizzare le macchine virtuali, nonché fare lo scale up e lo scale down in base alle tue esigenze. Dataproc si integra perfettamente con Cloud Storage, BigQuery, Bigtable e altri servizi Google Cloud.

best practice

• Modalità alta disponibilità di Dataproc: confronta la modalità ad alta disponibilità (HA) di Hadoop con la modalità non ad alta disponibilità predefinita in termini di nomi delle istanze, Apache ZooKeeper, Hadoop Distributed File System (HDFS) e Yet More Resource Negotiator (YARN). Inoltre, vediamo come creare un cluster ad alta disponibilità.
• Cluster a scalabilità automatica: quando utilizzare la scalabilità automatica di Dataproc, come creare un criterio di scalabilità automatica, utilizzo dei criteri multi-cluster, best practice di affidabilità per la configurazione della scalabilità automatica, metriche e log.
• Modalità di flessibilità avanzata (EFM) di Dataproc: esempi di utilizzo della modalità di flessibilità avanzata per ridurre al minimo i ritardi nell'avanzamento dei job, configurazioni avanzate come partizionamento e parallelismo e rimozione controllata YARN sui cluster EFM.
• Abbattimento automatico: uso di un ritiro controllato per ridurre al minimo l'impatto della rimozione dei worker da un cluster, come utilizzare questa funzionalità con i worker secondari ed esempi di comandi per un ritiro controllato.
• Job riavviabili: utilizzando le impostazioni facoltative, puoi impostare i job in modo che vengano riavviati in caso di errore per ridurre i tipi comuni di errori dei job, inclusi problemi di esaurimento della memoria e riavvii imprevisti delle macchine virtuali di Compute Engine.

Framework dell'architettura Google Cloud: ottimizzazione dei costi

Questa categoria del framework dell'architettura Google Cloud fornisce suggerimenti di progettazione e descrive le best practice per aiutare architect, sviluppatori, amministratori e altri professionisti del cloud a ottimizzare il costo dei carichi di lavoro in Google Cloud.

Lo spostamento dei carichi di lavoro IT nel cloud può aiutarti a innovare su larga scala, fornire funzionalità più rapidamente e rispondere alle esigenze in continua evoluzione dei clienti. Per eseguire la migrazione di carichi di lavoro esistenti o il deployment di applicazioni create per il cloud, è necessaria una topologia ottimizzata per sicurezza, resilienza, eccellenza operativa, costi e prestazioni.

Nella categoria Ottimizzazione dei costi del framework dell'architettura, imparerai a:

• Adotta e implementa FinOps: strategie per incoraggiare i dipendenti a considerare l'impatto sui costi durante il provisioning e la gestione delle risorse in Google Cloud.
• Monitoraggio e controllo dei costi: best practice, strumenti e tecniche per monitorare e controllare il costo delle risorse in Google Cloud.
• Ottimizzazione dei costi: computing, container e serverless: controlli di ottimizzazione dei costi specifici del servizio per Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions e App Engine.
• Ottimizza i costi: archiviazione: controlli per l'ottimizzazione dei costi per Cloud Storage, Persistent Disk e Filestore.
• Ottimizzazione dei costi: database e analisi intelligente: controlli per l'ottimizzazione dei costi per BigQuery, Bigtable, Spanner, Cloud SQL, Dataflow e Dataproc.
• Ottimizzazione dei costi: networking: controlli di ottimizzazione dei costi per le risorse di networking in Google Cloud.
• Ottimizzazione dei costi: operazioni cloud: suggerimenti per ottimizzare i costi di monitoraggio e gestione delle risorse in Google Cloud.

Adozione e implementazione di FinOps

Questo documento nel framework dell'architettura Google Cloud illustra le strategie per aiutarti a considerare l'impatto sui costi delle azioni e delle decisioni durante il provisioning e la gestione delle risorse in Google Cloud. Descrive FinOps, una pratica che combina persone, processi e tecnologia per promuovere la responsabilità finanziaria e la disciplina dell'ottimizzazione dei costi in un'organizzazione, indipendentemente dalle sue dimensioni o dalla sua maturità nel cloud.

Le indicazioni in questa sezione sono rivolte a CTO, CIO e dirigenti responsabili del controllo della spesa della propria organizzazione nel cloud. Le linee guida aiutano anche i singoli operatori cloud a comprendere e adottare FinOps.

Ogni dipendente della tua organizzazione può contribuire a ridurre il costo delle risorse in Google Cloud, a prescindere dal ruolo (analista, architetto, sviluppatore o amministratore). Nei team che in passato non dovevano monitorare i costi dell'infrastruttura, probabilmente era necessario informare i dipendenti sulla necessità di una responsabilità collettiva.

Un modello comune è destinato a un team FinOps centrale o al Cloud Center of Excellence (CCoE) per standardizzare il processo al fine di ottimizzare i costi in tutti i carichi di lavoro cloud. Questo modello presuppone che il team centrale abbia le conoscenze e le competenze necessarie per identificare opportunità di alto valore per migliorare l'efficienza.

Sebbene il controllo centralizzato dei costi possa funzionare bene nelle fasi iniziali dell'adozione del cloud quando l'utilizzo è ridotto, non scala bene quando l'adozione e l'utilizzo del cloud aumentano. Il team centrale potrebbe avere difficoltà con la scalabilità e i team di progetto potrebbero non accettare decisioni prese da soggetti esterni ai team.

Consigliamo al team centrale di delegare il processo decisionale per l'ottimizzazione delle risorse ai team di progetto. Il team centrale può promuovere gli sforzi più ampi per incoraggiare l'adozione di FinOps in tutta l'organizzazione. Per consentire ai singoli team di progetto di mettere in pratica FinOps, il team centrale deve standardizzare il processo, il reporting e gli strumenti per l'ottimizzazione dei costi. Il team centrale deve lavorare a stretto contatto con i team che non hanno familiarità con le pratiche FinOps e aiutarli a considerare i costi nei loro processi decisionali. Il team centrale deve anche fungere da intermediario tra il team finanziario e i singoli team di progetto.

Le prossime sezioni descrivono i principi di progettazione che consigliamo di promuovere al team centrale.

Incoraggia la responsabilità individuale

Qualsiasi dipendente che crea e utilizza risorse cloud influisce sull'utilizzo e sul costo di queste risorse. Affinché un'organizzazione riesca a implementare FinOps, il team centrale deve aiutare i dipendenti a passare dalla visualizzazione dei costi come responsabilità di un'altra persona alla gestione dei costi come una responsabilità individuale. Con questa transizione, i dipendenti possono prendere decisioni in merito ai costi appropriate per i loro carichi di lavoro, per il team e per l'organizzazione. Questa proprietà si estende all'implementazione di azioni di ottimizzazione dei costi basate sui dati.

Per incoraggiare la responsabilità per i costi, il team centrale può intraprendere le seguenti azioni:

• Istruisci gli utenti sulle opportunità e sulle tecniche di ottimizzazione dei costi.
• Premia i dipendenti che ottimizzano i costi ed elogiane il successo.
• Rendi i costi visibili in tutta l'organizzazione.

Rendi visibili i costi

Affinché i dipendenti possano considerare i costi durante il provisioning e la gestione delle risorse nel cloud, hanno bisogno di una visione completa dei dati pertinenti, il più vicino possibile al tempo reale. I dati nei report e nelle dashboard devono mostrare il costo e l'impatto sull'attività delle decisioni dei membri del team man mano che si verificano gli impatti pertinenti. I dati su utilizzo e costi di altri team possono fungere da base di riferimento per l'identificazione di pattern di deployment efficienti. Questi dati possono contribuire a promuovere una comprensione condivisa dei modi migliori per utilizzare i servizi cloud.

Se un'organizzazione non incoraggia e promuove la condivisione dei dati di costo, i dipendenti potrebbero essere riluttanti a condividerli. A volte, per motivi aziendali, un'organizzazione potrebbe non consentire la condivisione di dati di costo non elaborati. Anche in questi casi, ti consigliamo di evitare l'uso di un criterio predefinito che limita l'accesso alle informazioni sui costi.

Per rendere visibili i costi in tutta l'organizzazione, il team centrale può eseguire le seguenti azioni:

• Utilizza un unico metodo ben definito per calcolare i costi totali delle risorse cloud. Ad esempio, il metodo potrebbe considerare la spesa cloud totale corretta in base agli sconti acquistati e ai costi condivisi, come il costo dei database condivisi.
• Configurare dashboard che consentano ai dipendenti di visualizzare la spesa per il cloud quasi in tempo reale.
• Per motivare i singoli membri del team a tenere sotto controllo i costi, consenti un'ampia visibilità della spesa per il cloud tra i team.

Attiva comportamento collaborativo

Una gestione efficace dei costi per le risorse cloud richiede la collaborazione dei team per migliorare i processi tecnici e operativi. La cultura della collaborazione aiuta i team a progettare pattern di deployment economicamente vantaggiosi basati su un insieme coerente di fattori e obiettivi aziendali.

Per consentire un comportamento collaborativo, il team centrale può eseguire le seguenti azioni:

• Crea un processo di onboarding dei carichi di lavoro che aiuti a garantire l'efficienza dei costi in fase di progettazione tramite revisioni da parte di altri tecnici delle architetture proposte.
• Creare una knowledge base tra team dei modelli architetturali economici.

Stabilire una cultura senza colpe

Promuovere una cultura basata sull'apprendimento e sulla crescita che renda più sicuri i rischi, le correzioni quando necessario e l'innovazione. Tieni presente che errori, a volte costosi, possono verificarsi in qualsiasi fase della progettazione IT e del ciclo di vita del deployment, come in qualsiasi altra parte dell'azienda.

Anziché incolpare e offendere le persone che hanno speso troppo o hanno introdotto costi eccessivi, promuovi una cultura della colpevolezza che aiuti a identificare la causa di scostamenti dei costi e calcoli errati. È più probabile che i membri del team condividano punti di vista ed esperienze. Gli errori vengono resi anonimi e condivisi all'interno dell'attività per evitare che si ripetano.

Non confondere una cultura della colpevolezza con la mancanza di responsabilità. I dipendenti continuano a essere responsabili delle decisioni che prendono e del denaro che spendono. Quando si verificano errori, l'attenzione viene data all'opportunità di apprendimento per evitare che si ripetano.

Per stabilire una cultura della colpevolezza, il team centrale può intraprendere le seguenti azioni:

• Esegui post mortem senza attribuzione di colpe per i problemi di costo più gravi, concentrandoti sulla causa principale sistemica dei problemi, piuttosto che sulle persone coinvolte.
• Ringrazia i membri del team che reagiscono agli sforamenti dei costi e condividono le lezioni apprese. Incoraggia gli altri membri del team a condividere errori, azioni compiute e lezioni apprese.

Concentrati sul valore aziendale

Sebbene le pratiche di FinOps siano spesso incentrate sulla riduzione dei costi, un team centrale deve concentrarsi sul consentire ai team di progetto di prendere decisioni che massimizzano il valore aziendale delle loro risorse cloud. Si può avere la tentazione di prendere decisioni che riducono i costi a un livello tale da raggiungere i livelli minimi di servizio. Tuttavia, queste decisioni spesso spostano i costi su altre risorse, possono portare a costi di manutenzione più elevati e potrebbero aumentare il costo totale di proprietà. Ad esempio, per ridurre i costi, potresti decidere di utilizzare macchine virtuali (VM) anziché un servizio gestito. Tuttavia, una soluzione basata su VM richiede un maggiore impegno da mantenere rispetto a un servizio gestito, pertanto il servizio gestito potrebbe offrire un valore aziendale netto maggiore.

Le pratiche di FinOps possono fornire ai team di progetto la visibilità e gli insight necessari per prendere decisioni relative all'architettura e alle operazioni che massimizzano il valore aziendale delle loro risorse cloud.

Per aiutare i dipendenti a concentrarsi sul valore aziendale, il team centrale può eseguire le seguenti azioni:

• Utilizza servizi gestiti e architetture serverless per ridurre il costo totale di proprietà delle risorse di calcolo. Per ulteriori informazioni, consulta Scegliere una piattaforma di computing.

• Correla l'utilizzo del cloud a metriche di valore aziendale come efficienza dei costi, resilienza, velocità delle funzionalità e innovazione che favoriscono le decisioni di ottimizzazione dei costi. Per saperne di più sulle metriche per il valore aziendale, consulta il white paper di Cloud FinOps.

• Implementa il costo unitario per tutte le applicazioni e i servizi in esecuzione nel cloud.

Passaggi successivi

• Scopri di più su FinOps:
  • Massimizza il valore aziendale con Cloud FinOps
  • Inizia a utilizzare FinOps su Google Cloud
  • FinOps Foundation
  • Costo per unità nel cloud
• Monitorare e controllare i costi
• Ottimizza i costi per i servizi Google Cloud:
  • Ottimizzazione dei costi: computing, container e serverless
  • Ottimizza i costi: spazio di archiviazione
  • Ottimizzazione dei costi: database e analisi intelligente
  • Ottimizzazione dei costi: networking
  • Ottimizzazione dei costi: operazioni cloud
• Esplora le altre categorie del framework dell'architettura Google Cloud

Monitoraggio e controllo dei costi

Questo documento nel framework dell'architettura Google Cloud descrive best practice, strumenti e tecniche per aiutarti a monitorare e controllare il costo delle tue risorse in Google Cloud.

Le indicazioni in questa sezione sono rivolte agli utenti che eseguono il provisioning o la gestione delle risorse nel cloud.

Aree di interesse per la gestione dei costi

Il costo delle risorse in Google Cloud dipende dalla quantità di risorse utilizzate e dalla tariffa a cui ti vengono addebitate le risorse.

Per gestire il costo delle risorse cloud, ti consigliamo di concentrarti sulle seguenti aree:

• Visibilità dei costi
• Ottimizzazione delle risorse
• Ottimizzazione delle tariffe

Visibilità dei costi

Monitora quanto spendi e come vengono fatturati le risorse e i servizi, in modo da poter analizzare l'effetto del costo sui risultati aziendali. Ti consigliamo di seguire il modello operativo di FinOps, che suggerisce le seguenti azioni per rendere le informazioni sui costi visibili in tutta l'organizzazione:

• Assegna: assegna un proprietario per ogni elemento di costo.
• Report: rendi i dati di costo disponibili, fruibili e strategici.
• Previsione: stima e monitora la spesa futura.

Ottimizzazione delle risorse

Allinea il numero e le dimensioni delle risorse cloud ai requisiti del tuo carico di lavoro. Ove possibile, valuta l'utilizzo di servizi gestiti o la riprogettazione dell'architettura delle tue applicazioni. In genere, i singoli team di tecnici dispongono di più contesto rispetto al team centrale delle FinOps (operazioni finanziarie) su opportunità e tecniche per ottimizzare il deployment delle risorse. Consigliamo al team FinOps di collaborare con i singoli team di progettazione per identificare le opportunità di ottimizzazione delle risorse che possono essere applicate in tutta l'organizzazione.

Ottimizzazione delle tariffe

Il team di FinOps spesso prende le decisioni di ottimizzazione delle tariffe a livello centrale. Consigliamo ai singoli team di progettazione di collaborare con il team FinOps centrale per usufruire di sconti consistenti per prenotazioni, impegno di utilizzo, VM spot, prezzi a costo fisso e sconti per volume e contratti.

Suggerimenti di progettazione

Questa sezione suggerisce approcci che puoi utilizzare per monitorare e controllare i costi.

Consolidare la fatturazione e la gestione delle risorse

Per gestire la fatturazione e le risorse in Google Cloud in modo efficiente, ti consigliamo di utilizzare un unico account di fatturazione per la tua organizzazione e di utilizzare meccanismi interni di storno di addebito per allocare i costi. Utilizza più account di fatturazione per conglomerati vagamente strutturati e organizzazioni con entità che non si influenzano a vicenda. Ad esempio, i rivenditori potrebbero aver bisogno di account distinti per ogni cliente. L'utilizzo di account di fatturazione distinti può inoltre aiutarti a rispettare le normative fiscali specifiche del paese.

Un'altra best practice consigliata è spostare tutti i progetti che gestisci nell'organizzazione. Consigliamo di utilizzare Resource Manager per creare una gerarchia delle risorse che consenta di raggiungere i seguenti obiettivi:

• Stabilire una gerarchia di proprietà delle risorse in base alla relazione tra ciascuna risorsa e l'elemento padre diretto.
• Controlla il modo in cui i criteri di accesso e i tag o le etichette di allocazione dei costi vengono collegati ed ereditati dalle risorse nell'organizzazione.

Inoltre, ti consigliamo di allocare il costo dei servizi condivisi in modo proporzionale in base al consumo. Esamina e modifica periodicamente i parametri di allocazione dei costi in base ai cambiamenti dei tuoi obiettivi e priorità commerciali.

Monitorare e allocare i costi utilizzando tag o etichette

Tag ed etichette sono due metodi diversi che puoi utilizzare per annotare le risorse Google Cloud. I tag offrono più funzionalità delle etichette. Ad esempio, puoi implementare un controllo granulare sulle risorse creando criteri di Identity and Access Management (IAM) condizionali a seconda che un tag sia associato a una risorsa supportata. Inoltre, i tag associati a una risorsa vengono ereditati da tutte le risorse figlio nella gerarchia. Per ulteriori informazioni sulle differenze tra tag ed etichette, consulta la Panoramica dei tag.

Se stai creando un nuovo framework per l'allocazione e il monitoraggio dei costi, ti consigliamo di utilizzare i tag.

Per classificare i dati di costo con la granularità richiesta, stabilisci uno schema di tagging o etichettatura adatto al meccanismo di storno di addebito della tua organizzazione e che consenta di allocare i costi in modo appropriato. Puoi definire tag a livello di organizzazione o di progetto. Puoi assegnare etichette a livello di progetto e definire un insieme di etichette applicabili a tutti i progetti per impostazione predefinita.

Definire un processo per rilevare e correggere anomalie di tagging ed etichettatura e progetti non etichettati. Ad esempio, da Cloud Asset Inventory, puoi scaricare un inventario (file .csv) di tutte le risorse di un progetto e analizzarlo per identificare le risorse a cui non sono stati assegnati tag o etichette.

Per monitorare il costo di risorse e servizi condivisi (ad esempio datastore comuni, cluster multi-tenant e abbonamenti di assistenza), valuta la possibilità di utilizzare un tag o un'etichetta speciale per identificare i progetti che contengono risorse condivise.

Configura controllo dell'accesso alla fatturazione

Per controllare l'accesso a Fatturazione Cloud, consigliamo di assegnare il ruolo Amministratore account di fatturazione solo agli utenti che gestiscono i dati di contatto per la fatturazione. Ad esempio, i dipendenti dei settori finanziario, contabile e operativo potrebbero avere bisogno di questo ruolo.

Per evitare un single point of failure per l'assistenza per la fatturazione, assegna il ruolo Amministratore account di fatturazione a più utenti o a un gruppo. Solo gli utenti con il ruolo Amministratore account di fatturazione possono contattare l'assistenza. Per indicazioni dettagliate, consulta Esempi di controllo dell'accesso per la fatturazione Cloud e Ruoli importanti.

Per gestire l'accesso alla fatturazione, effettua le seguenti configurazioni:

• Per associare un account di fatturazione a un progetto, i membri devono disporre del ruolo Utente account di fatturazione per l'account di fatturazione e del ruolo Gestore fatturazione progetto per il progetto.
• Per consentire ai team di associare manualmente gli account di fatturazione ai progetti, puoi assegnare il ruolo Gestore fatturazione progetto a livello di organizzazione e il ruolo Utente account di fatturazione per l'account di fatturazione. Puoi automatizzare l'associazione degli account di fatturazione durante la creazione del progetto assegnando i ruoli Gestore fatturazione progetto e Utente account di fatturazione a un account di servizio. Ti consigliamo di limitare il ruolo Creatore account di fatturazione o rimuovere tutte le assegnazioni di questo ruolo.
• Per evitare interruzioni causate da modifiche involontarie allo stato di fatturazione di un progetto, puoi bloccare il collegamento tra il progetto e il relativo account di fatturazione. Per maggiori informazioni, consulta Proteggere il collegamento tra un progetto e il relativo account di fatturazione.

Configurare i report sulla fatturazione

Configura i report di fatturazione in modo da fornire dati per le metriche chiave da monitorare. Ti consigliamo di monitorare le seguenti metriche:

• Tendenze di costo
• Utenti che spendono di più (per progetto e per prodotto)
• Aree di spesa irregolare
• Insight chiave a livello di organizzazione, come segue:
  • Rilevamento delle anomalie
  • Tendenze nel tempo
  • Tendenze che si verificano in base a uno schema prestabilito (ad esempio su base mensile)
  • Confronto dei costi e analisi di benchmark tra carichi di lavoro interni ed esterni
  • Monitoraggio di casi aziendali e realizzazione del valore (ad esempio, costi del cloud rispetto al costo di risorse on-premise simili)
  • Convalida dell'accuratezza e delle fatture previste da Google Cloud

Analizzare le tendenze e prevedere i costi

Personalizza e analizza i report sui costi utilizzando l'esportazione della fatturazione di BigQuery e visualizza i dati di costo utilizzando Looker Studio. Valuta l'andamento dei costi effettivi e quanto potresti spendere utilizzando lo strumento di previsione.

Ottimizza l'utilizzo e i costi delle risorse

Questa sezione consiglia le best practice per aiutarti a ottimizzare l'utilizzo e i costi delle risorse in tutti i servizi Google Cloud.

Per evitare una spesa eccessiva, valuta la possibilità di configurare budget predefiniti e avvisi con soglie elevate per tutti i tuoi progetti. Per non superare il budget, ti consigliamo di procedere nel seguente modo:

• Configurare budget e avvisi per i progetti in cui sono necessari limiti di utilizzo assoluti, ad esempio progetti di addestramento o sandbox.

• Definisci i budget in base a quelli che devi monitorare. Ad esempio, se un reparto ha un budget cloud complessivo, imposta l'ambito del budget di Google Cloud in modo da includere i progetti specifici che devi monitorare.

• Per garantire che i budget vengano mantenuti, delega la responsabilità della configurazione di budget e avvisi ai team proprietari dei carichi di lavoro.

Per ottimizzare i costi, ti consigliamo inoltre di procedere nel seguente modo:

• Limita l'utilizzo dell'API nei casi in cui l'impatto sull'attività è minimo o nullo. La quota limite può essere utile per progetti sandbox o di addestramento e per progetti con budget fissi (ad esempio analisi ad hoc in BigQuery). L'applicazione di limiti non comporta la rimozione di tutte le risorse e di tutti i dati dai progetti associati.
• Usa le quotas per impostare limiti rigidi che limitano il deployment delle risorse. Le quote consentono di controllare i costi e prevenire l'uso dannoso o improprio delle risorse. Le quote vengono applicate a livello di progetto, per tipo di risorsa e località.
• Visualizza e implementa i suggerimenti per l'ottimizzazione dei costi nell'hub dei suggerimenti.
• Acquista sconti per impegno di utilizzo (CUD) per risparmiare denaro su risorse destinate a carichi di lavoro con esigenze prevedibili in termini di risorse.

Strumenti e tecniche

Il provisioning on demand e le caratteristiche di pagamento in base al consumo del cloud ti aiutano a ottimizzare la tua spesa IT. Questa sezione descrive gli strumenti offerti da Google Cloud e le tecniche che puoi utilizzare per monitorare e controllare il costo delle tue risorse nel cloud. Prima di utilizzare questi strumenti e tecniche, consulta i concetti di base della fatturazione Cloud.

Report sulla fatturazione

Google Cloud fornisce report di fatturazione all'interno della console Google Cloud per aiutarti a visualizzare la spesa attuale e prevista. I report di fatturazione consentono di visualizzare i dati di costo in un'unica pagina, scoprire e analizzare le tendenze, prevedere il costo di fine periodo e, se necessario, intraprendere azioni correttive.

I report di fatturazione forniscono i seguenti dati:

• I costi e le tendenze dei costi per un determinato periodo, organizzati come segue:
  • Per account di fatturazione
  • Per progetto
  • Per prodotto (ad esempio Compute Engine)
  • Da SKU (ad esempio indirizzi IP statici)
• I costi potenziali se sono stati esclusi sconti o crediti promozionali
• Spesa prevista

Esportazione dei dati in BigQuery

Puoi esportare i report di fatturazione in BigQuery e analizzare i costi utilizzando visualizzazioni storiche e granulari dei dati, inclusi i dati categorizzati utilizzando etichette o tag. Con BigQuery ML puoi eseguire analisi più avanzate. Ti consigliamo di abilitare l'esportazione dei report di fatturazione in BigQuery quando crei l'account di fatturazione Cloud. Il set di dati BigQuery contiene i dati di fatturazione a partire dalla data in cui hai configurato l'esportazione della fatturazione Cloud. Il set di dati non include dati per il periodo prima di aver abilitato l'esportazione.

Nota: i dati di fatturazione esportati potrebbero essere diversi da quelli delle fatture a causa di dati segnalati in ritardo, variazioni di timestamp, errori e aggiustamenti e tasse. Per saperne di più, consulta Differenze tra i dati esportati e le fatture.

Per visualizzare i dati di costo, puoi creare dashboard personalizzate che si integrano con BigQuery (modelli di esempio: Looker, Looker Studio).

Puoi utilizzare tag ed etichette come criteri per filtrare i dati di fatturazione esportati. Il numero di etichette incluse nell'esportazione della fatturazione è limitato. Vengono conservate fino a 1000 mappe di etichette in un periodo di un'ora. Le etichette non vengono visualizzate nel PDF o CSV delle fatture. Prendi in considerazione la possibilità di annotare le risorse utilizzando tag o etichette che indichino l'unità aziendale, l'unità di storno di addebito interna e altri metadati pertinenti.

Controllo dell'accesso alla fatturazione

Puoi controllare l'accesso alla fatturazione Cloud per risorse specifiche definendo i criteri di Identity and Access Management (IAM) per le risorse. Per concedere o limitare l'accesso a Fatturazione Cloud, puoi impostare un criterio IAM a livello di organizzazione, di account di fatturazione o di progetto.

Nota: sebbene gli account di fatturazione siano collegati ai progetti, questi non sono l'account padre dei progetti in IAM. I progetti non ereditano le autorizzazioni dall'account di fatturazione a cui sono collegati.

Il controllo dell'accesso per la fatturazione e la gestione delle risorse segue il principio di separazione dei compiti. Ogni utente dispone solo delle autorizzazioni necessarie per il suo ruolo aziendale. I ruoli Amministratore organizzazione e Amministratore fatturazione non hanno le stesse autorizzazioni.

Puoi impostare le autorizzazioni relative alla fatturazione a livello di account di fatturazione e di organizzazione. I ruoli comuni sono Amministratore account di fatturazione, Utente account di fatturazione e Visualizzatore account di fatturazione.

Ti consigliamo di utilizzare la fatturazione mensile non automatica o di configurare un metodo di pagamento alternativo. Mantieni le impostazioni di contatto e notifica per fatturazione e pagamento.

Budget, avvisi e quote

I budget ti consentono di monitorare i costi effettivi di Google Cloud rispetto alla spesa pianificata. Quando crei un budget, puoi configurare le regole di avviso per attivare le notifiche via email quando la spesa effettiva o prevista supera una soglia definita. Puoi anche utilizzare i budget per automatizzare le risposte al controllo dei costi.

I budget possono attivare avvisi per informarti sull'utilizzo delle risorse e sulle tendenze di costo, nonché chiederti di eseguire azioni per l'ottimizzazione dei costi. Tuttavia, i budget non impediscono l'utilizzo o la fatturazione dei servizi quando il costo effettivo raggiunge o supera il budget o la soglia. Per controllare automaticamente i costi, puoi utilizzare le notifiche del budget per disattivare in modo programmatico la fatturazione Cloud per un progetto. Puoi anche limitare l'utilizzo dell'API per interrompere l'addebito di costi dopo una soglia di utilizzo definita.

Puoi configurare avvisi per account di fatturazione e progetti. Configurare almeno un budget per un account.

Per impedire il provisioning delle risorse oltre un livello predeterminato o per limitare il volume di operazioni specifiche, puoi impostare le quotas a livello di risorsa o API. Di seguito sono riportati alcuni esempi di come utilizzare le quote:

• Controlla il numero di chiamate API al secondo.
• Limita il numero di VM create.
• Limita la quantità di dati sottoposti a query al giorno in BigQuery.

I proprietari del progetto possono ridurre la quantità di quota che può essere addebitata in base a un limite di quota utilizzando l'API Service Usage per applicare override del consumer a limiti di quota specifici. Per maggiori informazioni, consulta la pagina relativa alla creazione di un override della quota consumer.

Miglioramento dell'efficienza dei carichi di lavoro

Consigliamo le seguenti strategie per aiutarti a rendere i tuoi carichi di lavoro in Google Cloud economicamente vantaggiosi:

• Ottimizza l'utilizzo delle risorse migliorando l'efficienza dei prodotti.
• Riduci la frequenza con cui ti vengono addebitate le risorse.
• Controlla e limita l'utilizzo e la spesa delle risorse.

Quando selezioni le tecniche di riduzione dei costi e le funzionalità di Google Cloud, considera lo sforzo richiesto e i risparmi previsti, come mostrato nel seguente grafico:

Di seguito è riportato un riepilogo delle tecniche mostrate nel grafico precedente:

• Le seguenti tecniche potrebbero consentire un notevole risparmio con il minimo sforzo:
  • Sconti per impegno di utilizzo
  • Scalabilità automatica
  • Slot BigQuery
• Le seguenti tecniche possono generare risparmi elevati con uno sforzo medio-alto:
  • VM spot
  • Riprogettare l'architettura come applicazioni serverless o containerizzate
  • Re-platforming per l'utilizzo dei servizi gestiti
• Le seguenti tecniche potrebbero generare risparmi moderati con uno sforzo moderato:
  • Tipi di macchine personalizzate
  • Gestione del ciclo di vita di Cloud Storage
  • Dimensionamento ottimale
  • Recupero delle risorse inattive

Le tecniche spiegate nelle sezioni seguenti possono aiutarti a migliorare l'efficienza dei tuoi carichi di lavoro.

Refactoring o riprogettazione dell'architettura

Puoi ottenere notevoli risparmi sui costi con il refactoring o la riprogettazione del carico di lavoro in modo da utilizzare i prodotti Google Cloud. Ad esempio, il passaggio ai servizi serverless (come Cloud Storage, Cloud Run, BigQuery e Cloud Functions) che supportano la scalabilità fino a zero può contribuire a migliorare l'efficienza. Per valutare e confrontare il costo di questi prodotti, puoi utilizzare il Calcolatore prezzi.

Dimensionamento ottimale

Questa tecnica consente di garantire che la scalabilità dell'infrastruttura corrisponda all'utilizzo previsto. Questa strategia è pertinente principalmente per le soluzioni IaaS (Infrastructure as a Service), che prevedono il pagamento dell'infrastruttura sottostante. Ad esempio, hai eseguito il deployment di 50 VM, ma le VM non sono completamente utilizzate e stabilisci che i carichi di lavoro possano essere eseguiti in modo efficace su meno VM (o più piccole). In questo caso, puoi rimuovere o ridimensionare alcune delle VM. Google Cloud fornisce suggerimenti per il dimensionamento ottimale per aiutarti a rilevare opportunità di risparmio senza influire sulle prestazioni eseguendo il provisioning di VM più piccole. Il dimensionamento ottimale richiede meno impegno durante la fase di progettazione rispetto al deployment delle risorse in produzione.

Scalabilità automatica

Se i prodotti che utilizzi supportano la scalabilità automatica dinamica, valuta la possibilità di progettare i carichi di lavoro in modo da sfruttarla e ottenere vantaggi in termini di costi e prestazioni. Ad esempio, per i carichi di lavoro ad alta intensità di calcolo, puoi utilizzare gruppi di istanze gestite in Compute Engine o containerizzare le applicazioni ed eseguirne il deployment in un cluster Google Kubernetes Engine.

Consigli di Active Assist

Active Assist utilizza dati, intelligence e machine learning per ridurre la complessità del cloud e gli sforzi amministrativi. Active Assist semplifica l'ottimizzazione di sicurezza, prestazioni e costi della topologia cloud. Fornisce suggerimenti intelligenti per ottimizzare costi e utilizzo. Applicali per ottenere risparmi immediati sui costi e aumentare l'efficienza.

Di seguito sono riportati alcuni esempi di consigli forniti da Active Assist:

• Ridimensionamento delle risorse di Compute Engine: ridimensiona le istanze VM per ottimizzare costi e prestazioni in base all'utilizzo. Identifica ed elimina o esegui il backup delle VM inattive e dei dischi permanenti per ottimizzare i costi dell'infrastruttura.
• Sconto per impegno di utilizzo (CUD): Google Cloud analizza l'utilizzo storico, trova la quantità di impegno ottimale per i tuoi carichi di lavoro e fornisce suggerimenti pratici e di facile comprensione per risparmiare sui costi. Per maggiori informazioni, consulta il motore per suggerimenti sugli sconti per impegno di utilizzo.
• Progetti inattivi: individua i progetti inattivi nella tua organizzazione e rimuovili o recuperali. Per ulteriori informazioni, consulta il motore per suggerimenti di progetti inattivi.

Per un elenco completo, consulta i motori per suggerimenti.

Passaggi successivi

• Scopri i concetti di fatturazione Cloud
• Impostare budget e avvisi relativi al budget
• Ottimizza i costi di servizi di computing, archiviazione, database, networking e operazioni:
  • Ottimizzazione dei costi: computing, container e serverless
  • Ottimizza i costi: spazio di archiviazione
  • Ottimizzazione dei costi: database e analisi intelligente
  • Ottimizzazione dei costi: networking
  • Ottimizzazione dei costi: operazioni cloud
• Esplora le altre categorie del framework dell'architettura Google Cloud

Ottimizza i costi: computing, container e serverless

Questo documento nel framework dell'architettura Google Cloud fornisce suggerimenti per aiutarti a ottimizzare i costi delle tue macchine virtuali (VM), dei container e delle risorse serverless in Google Cloud.

Le indicazioni in questa sezione sono rivolte ad architect, sviluppatori e amministratori responsabili del provisioning e della gestione delle risorse di computing per i carichi di lavoro nel cloud.

Le risorse di calcolo sono la parte più importante dell'infrastruttura cloud. Quando esegui la migrazione dei tuoi carichi di lavoro in Google Cloud, in genere la prima scelta è Compute Engine, che consente di eseguire il provisioning e la gestione delle VM in modo efficiente nel cloud. Compute Engine offre un'ampia gamma di tipi di macchine ed è disponibile a livello globale in tutte le regioni di Google Cloud. I tipi di macchine predefinite e personalizzate di Compute Engine consentono di eseguire il provisioning di VM che offrono una capacità di calcolo simile a quella dell'infrastruttura on-premise, consentendoti di accelerare il processo di migrazione. Compute Engine ti offre il vantaggio di pagare solo per l'infrastruttura che utilizzi e offre risparmi significativi man mano che utilizzi più risorse di calcolo con sconti per utilizzo sostenuto.

Oltre a Compute Engine, Google Cloud offre container e servizi di computing serverless. L'approccio serverless può essere più conveniente per i nuovi servizi che non sono sempre in esecuzione (ad esempio API, elaborazione dati ed elaborazione di eventi).

Oltre ai suggerimenti generali, questo documento fornisce indicazioni per aiutarti a ottimizzare il costo delle risorse di computing quando utilizzi i seguenti prodotti:

• Compute Engine
• Google Kubernetes Engine (GKE)
• Cloud Run
• Cloud Functions
• App Engine

Consigli generali

I seguenti suggerimenti sono applicabili a tutti i servizi di computing, container e serverless in Google Cloud descritti in questa sezione.

Monitorare l'utilizzo e i costi

Utilizza i seguenti strumenti e tecniche per monitorare l'utilizzo e il costo delle risorse:

• Visualizza e rispondi ai suggerimenti per l'ottimizzazione dei costi nell'hub dei suggerimenti.
• Ricevi notifiche via email per potenziali aumenti nell'utilizzo e nei costi delle risorse configurando avvisi relativi al budget.
• Gestisci e rispondi agli avvisi in modo programmatico utilizzando i servizi Pub/Sub e Cloud Functions.

Controlla il provisioning delle risorse

Utilizza i seguenti suggerimenti per controllare la quantità di risorse di cui è stato eseguito il provisioning nel cloud e la località in cui vengono create:

• Per garantire che il consumo e il costo delle risorse non superino la previsione, utilizza le quotas delle risorse.
• Esegui il provisioning delle risorse nella regione a basso costo che soddisfa i requisiti di latenza del tuo carico di lavoro. Per controllare dove viene eseguito il provisioning delle risorse, puoi utilizzare il vincolo del criterio dell'organizzazione gcp.resourceLocations.

Usufruisci di sconti per impegno di utilizzo

Gli sconti per impegno di utilizzo (CUD) sono ideali per carichi di lavoro con esigenze prevedibili in termini di risorse. Dopo aver eseguito la migrazione del carico di lavoro a Google Cloud, trova la base di riferimento per le risorse richieste e ricevi sconti maggiori per l'utilizzo per impegno di utilizzo. Ad esempio, acquista un impegno di uno o tre anni e ricevi uno sconto sostanziale sui prezzi delle VM di Compute Engine.

Automatizza il monitoraggio dei costi utilizzando le etichette

Definisci e assegna le etichette in modo coerente. Di seguito sono riportati alcuni esempi di come utilizzare le etichette per automatizzare il monitoraggio dei costi:

• Alle VM utilizzate solo dagli sviluppatori durante l'orario di lavoro, assegna l'etichetta env: development. Puoi utilizzare Cloud Scheduler per configurare una Cloud Function serverless in modo da arrestare queste VM dopo l'orario di lavoro e riavviarle quando necessario.

• Per un'applicazione con diversi servizi Cloud Run e istanze Cloud Functions, assegna un'etichetta coerente a tutte le risorse Cloud Run e Cloud Functions. Identifica le aree ad alto costo e intervieni per ridurre i costi.

Personalizzare i report di fatturazione

Configura i tuoi report di fatturazione Cloud impostando i filtri richiesti e raggruppando i dati in base alle esigenze (ad esempio per progetti, servizi o etichette).

Promuovi una cultura del risparmio sui costi

Forma gli sviluppatori e gli operatori sulla tua infrastruttura cloud. Crea e promuovi programmi di apprendimento utilizzando corsi tradizionali o online, gruppi di discussione, revisioni dei compagni, programmazione di accoppiamento e giochi economici. Come dimostrato nella ricerca DORA di Google, la cultura organizzativa è un fattore chiave per migliorare le prestazioni, ridurre il rilavoramento e il burnout e ottimizzare i costi. Offrendo visibilità ai dipendenti, puoi aiutarli ad allineare le priorità e le attività agli scopi e ai vincoli aziendali.

Compute Engine

Questa sezione fornisce indicazioni per ottimizzare il costo delle risorse Compute Engine. Oltre a queste indicazioni, ti consigliamo di seguire i consigli generali discussi in precedenza.

Informazioni sul modello di fatturazione

Per conoscere le opzioni di fatturazione per Compute Engine, consulta Prezzi.

Analizza il consumo delle risorse

Per comprendere il consumo delle risorse in Compute Engine, esporta i dati di utilizzo in BigQuery. Esegui una query sul datastore BigQuery per analizzare le tendenze di utilizzo della CPU virtuale (vCPU) del progetto e determinare il numero di vCPU che puoi recuperare. Se hai definito le soglie per il numero di core per progetto, analizza le tendenze di utilizzo per individuare le anomalie e intraprendere azioni correttive.

Recupera risorse inattive

Utilizza i seguenti suggerimenti per identificare e recuperare le VM e i dischi inutilizzati, ad esempio le VM per i progetti proof of concept la cui priorità è stata ridotta:

• Utilizza il motore per suggerimenti VM inattive per identificare le VM non attive e i dischi permanenti in base alle metriche di utilizzo.
• Prima di eliminare le risorse, valuta il potenziale impatto dell'azione e pianifica di ricrearle, se necessario.
• Prima di eliminare una VM, ti consigliamo di creare uno snapshot. Quando elimini una VM, i dischi collegati vengono eliminati, a meno che tu non abbia selezionato l'opzione Conserva disco.
• Ove possibile, valuta la possibilità di arrestare le VM anziché eliminarle. Quando interrompi una VM, l'istanza viene terminata, ma i dischi e gli indirizzi IP vengono conservati finché non li scolleghi o li elimini.

Regola la capacità per soddisfare la domanda

Pianifica l'avvio e l'arresto automatico delle VM. Ad esempio, se una VM viene utilizzata solo otto ore al giorno per cinque giorni a settimana (ossia 40 ore alla settimana), puoi potenzialmente ridurre i costi del 75% arrestandola durante le 128 ore della settimana in cui non è in uso.

Scala automaticamente la capacità di calcolo in base alla domanda utilizzando i gruppi di istanze gestite. Puoi scalare automaticamente la capacità in base ai parametri importanti per la tua attività (ad esempio utilizzo della CPU o capacità di bilanciamento del carico).

Scegli tipi di macchina appropriati

Dimensiona le tue VM in modo che corrispondano ai requisiti di calcolo del tuo carico di lavoro utilizzando il motore per suggerimenti tipo di macchina VM.

Per carichi di lavoro con requisiti di risorse prevedibili, personalizza il tipo di macchina in base alle tue esigenze e risparmia denaro utilizzando VM personalizzate.

Per i carichi di lavoro di elaborazione batch a tolleranza di errore, valuta l'utilizzo di VM spot. Computing ad alte prestazioni (HPC), big data, transcodifica multimediale, pipeline di integrazione continua e distribuzione continua (CI/CD) e applicazioni web stateless sono esempi di carichi di lavoro di cui è possibile eseguire il deployment sulle VM spot. Per un esempio di come Descartes Labs abbia ridotto i costi di analisi utilizzando VM prerilasciabili (la versione precedente delle VM spot) per l'elaborazione delle immagini satellitari, consulta il case study di Descartes Labs.

Valuta le opzioni di licenza

Quando esegui la migrazione di carichi di lavoro di terze parti in Google Cloud, potresti riuscire a ridurre i costi applicando il modello BYOL (Bring Your Own License). Ad esempio, per eseguire il deployment delle VM di Microsoft Windows Server, invece di utilizzare un'immagine premium che comporta costi aggiuntivi per la licenza di terze parti, puoi creare e utilizzare un'immagine BYOL personalizzata di Windows. Quindi paghi solo per l'infrastruttura VM che utilizzi su Google Cloud. Questa strategia ti consente di continuare a trarre valore dagli investimenti esistenti in licenze di terze parti.

Se decidi di utilizzare un approccio BYOL, ti consigliamo di seguire questi passaggi:

• Esegui il provisioning del numero richiesto di core della CPU di calcolo indipendentemente dalla memoria utilizzando i tipi di macchine personalizzate e limita il costo delle licenze di terze parti al numero di core della CPU necessario.
• Riduci il numero di vCPU per core da 2 a 1 disabilitando il multithreading simultaneo (SMT) e riduci i costi delle licenze del 50%.

Se i tuoi carichi di lavoro di terze parti richiedono hardware dedicato per soddisfare i requisiti di sicurezza o conformità, puoi utilizzare le tue licenze nei nodi single-tenant.

Google Kubernetes Engine

Questa sezione fornisce indicazioni per aiutarti a ottimizzare il costo delle risorse GKE.

Oltre ai seguenti, consulta i consigli generali discussi in precedenza:

• Utilizza GKE Autopilot per consentire a GKE di massimizzare l'efficienza dell'infrastruttura del tuo cluster. Non è necessario monitorare l'integrità dei nodi, gestire il bin packing o calcolare la capacità necessaria per i carichi di lavoro.
• Perfeziona la scalabilità automatica di GKE utilizzando Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA), Cluster Autoscaler (CA) o provisioning automatico dei nodi in base ai requisiti del tuo carico di lavoro.
• Per i carichi di lavoro batch non sensibili alla latenza di avvio, utilizza il profilo di scalabilità automatica ottimizzazione-utilizzo per contribuire a migliorare l'utilizzo del cluster.
• Utilizza il provisioning automatico dei nodi per estendere il gestore della scalabilità automatica dei cluster GKE e per creare ed eliminare in modo efficiente i pool di nodi in base alle specifiche dei pod in attesa senza overprovisioning.
• Usa pool di nodi separati: un pool di nodi statico per carico statico e pool di nodi dinamici con gruppi di scalabilità automatica dei cluster per carichi dinamici.
• Utilizza le VM spot per i pool di nodi Kubernetes quando i pod sono a tolleranza di errore e possono terminare in modo controllato in meno di 25 secondi. Combinata con il gestore della scalabilità automatica dei cluster GKE, questa strategia ti aiuta a garantire che il pool di nodi con VM a costo inferiore (in questo caso, il pool di nodi con VM spot) venga scalato per primo.
• Scegli tipi di macchine convenienti (ad esempio: E2, N2D, T2D), che garantiscono un aumento del 20-40% in termini di prestazioni rispetto al prezzo.
• Utilizza la misurazione dell'utilizzo di GKE per analizzare i profili di utilizzo dei tuoi cluster per spazi dei nomi ed etichette. Identifica il team o l'applicazione che sta spendendo di più, l'ambiente o il componente che ha causato picchi di utilizzo o dei costi e il team che sta sprecando risorse.
• Utilizza le quote delle risorse nei cluster multi-tenant per impedire a qualsiasi tenant di utilizzare una quota di risorse del cluster superiore a quella assegnata.
• Pianifica il downscaling automatico degli ambienti di sviluppo e test dopo l'orario di lavoro.
• Segui le best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE.

Cloud Run

Questa sezione fornisce indicazioni per aiutarti a ottimizzare il costo delle risorse Cloud Run.

Oltre ai seguenti, consulta i consigli generali discussi in precedenza:

• Modifica l'impostazione relativa alla contemporaneità (valore predefinito: 80) per ridurre i costi. Cloud Run determina il numero di richieste da inviare a un'istanza in base all'utilizzo di CPU e memoria. Aumentando la contemporaneità delle richieste, puoi ridurre il numero di istanze richieste.
• Imposta un limite per il numero di istanze di cui è possibile eseguire il deployment.
• Stima il numero di istanze richieste utilizzando la metrica Tempo di istanza fatturabile. Ad esempio, se la metrica mostra 100s/s, sono state pianificate circa 100 istanze. Aggiungi un buffer del 30% per preservare le prestazioni, ovvero 130 istanze per 100 secondi di traffico.
• Per ridurre l'impatto degli avvii a freddo, configura un numero minimo di istanze. Quando queste istanze sono inattive, vengono fatturate a un decimo del prezzo.
• Monitora l'utilizzo della CPU e regola i limiti della CPU di conseguenza.
• Utilizza la gestione del traffico per determinare una configurazione ottimale per i costi.
• Valuta la possibilità di utilizzare Cloud CDN o Firebase Hosting per la pubblicazione di asset statici.
• Per le app Cloud Run che gestiscono le richieste a livello globale, valuta la possibilità di eseguire il deployment dell'app in più regioni, perché il trasferimento di dati tra continenti può essere costoso. Questa struttura è consigliata se utilizzi un bilanciatore del carico e una rete CDN.
• Riduci i tempi di avvio per le tue istanze, poiché anche il tempo di avvio è fatturabile.
• Acquista sconti per impegno di utilizzo e risparmia fino al 17% sul prezzo on demand per un impegno di un anno.

Cloud Functions

Questa sezione fornisce indicazioni per aiutarti a ottimizzare il costo delle risorse Cloud Functions.

Oltre ai seguenti, consulta i consigli generali discussi in precedenza:

• Osserva il tempo di esecuzione delle tue funzioni. Sperimenta e analizza la funzione più piccola che soddisfi la soglia di prestazioni richiesta.
• Se i carichi di lavoro di Cloud Functions sono eseguiti costantemente, ti consigliamo di utilizzare GKE o Compute Engine per la gestione dei carichi di lavoro. I container o le VM potrebbero essere opzioni più economiche per carichi di lavoro sempre in esecuzione.
• Limita il numero di istanze della funzione che possono coesistere.
• Confronta le prestazioni di runtime dei lingue di programmazione di Cloud Functions con il carico di lavoro della tua funzione. I programmi nei linguaggi compilati hanno avvii a freddo più lunghi, ma vengono eseguiti più velocemente. I programmi nei linguaggi interpretati sono più lenti, ma hanno un overhead di avvio a freddo inferiore. Le funzioni brevi e semplici, eseguite spesso, potrebbero costare meno in un linguaggio interpretato.
• Elimina i file temporanei scritti sul disco locale, che è un file system in memoria. I file temporanei consumano memoria allocata alla funzione e, a volte, rimangono invariati tra una chiamata e l'altra. Se non elimini questi file, potrebbe verificarsi un errore di esaurimento della memoria e attivare un avvio a freddo, che aumenta il tempo e i costi di esecuzione.

App Engine

Questa sezione fornisce indicazioni per ottimizzare il costo delle risorse App Engine.

Oltre ai seguenti, consulta i consigli generali discussi in precedenza:

• Imposta il numero massimo di istanze in base al traffico e alla latenza delle richieste. App Engine in genere scala la capacità in base al traffico ricevuto dalle applicazioni. Puoi controllare i costi limitando il numero di istanze che App Engine può creare.
• Per limitare la memoria o la CPU disponibile per la tua applicazione, imposta una classe di istanza. Per le applicazioni che consumano molta CPU, alloca più CPU. Prova alcune configurazioni per determinare la dimensione ottimale.
• Confronta il tuo carico di lavoro App Engine con diversi linguaggi di programmazione. Ad esempio, un carico di lavoro implementato in una lingua potrebbe richiedere meno istanze e costi inferiori per completare le attività in tempo rispetto allo stesso carico di lavoro programmato in un altro linguaggio.
• Ottimizza per meno avvii a freddo. Se possibile, riduci le attività che richiedono un uso intensivo della CPU o le attività a lunga esecuzione che si verificano in ambito globale. Prova a suddividere l'attività in operazioni più piccole che possono essere caricate tramite caricamento lento nel contesto di una richiesta.
• Se prevedi un traffico intenso, configura un numero minimo di istanze inattive in preparazione. Se non prevedi del traffico, puoi configurare il numero minimo di istanze inattive impostandole su zero.
• Per bilanciare prestazioni e costi, esegui un test A/B suddividendo il traffico tra due versioni, ciascuna con una configurazione diversa. Monitora le prestazioni e i costi di ogni versione, apporta le modifiche necessarie e decidi la configurazione a cui inviare il traffico.
• Configura la contemporaneità delle richieste e imposta il numero massimo di richieste in parallelo superiore a quello predefinito. Maggiore è il numero di richieste che ogni istanza è in grado di gestire contemporaneamente, più efficiente potrai utilizzare le istanze esistenti per gestire il traffico.

Passaggi successivi

• Scopri come ottimizzare il costo delle risorse GKE:
  • Esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE: best practice
  • Best practice per ridurre il provisioning eccessivo di GKE
  • Ottimizzare l'utilizzo delle risorse in un cluster GKE multi-tenant utilizzando il provisioning automatico dei nodi
  • Riduci i costi facendo lo scale down dei cluster GKE durante le ore di punta
  • Esegui applicazioni web su GKE utilizzando VM spot con ottimizzazione dei costi
  • Stima i costi di GKE nelle prime fasi del ciclo di sviluppo utilizzando GitLab
  • Serie di video: ottimizzazione dei costi di GKE
  • Formazione: ottimizzazione dei costi per GKE
• Scopri come ottimizzare il costo delle risorse Cloud Run e Cloud Functions:
  • Gestisci costi e affidabilità nelle applicazioni completamente gestite
  • Ottimizza per la gestione dei costi a lungo termine nelle applicazioni completamente gestite
  • Massimizza i tuoi investimenti su Cloud Run con nuovi sconti per impegno di utilizzo
• Ottimizza i costi per archiviazione, database, networking e operazioni:
  • Ottimizza i costi: spazio di archiviazione
  • Ottimizzazione dei costi: database e analisi intelligente
  • Ottimizzazione dei costi: networking
  • Ottimizzazione dei costi: operazioni cloud
• Esplora le altre categorie del framework dell'architettura Google Cloud

Ottimizza i costi: spazio di archiviazione

Questo documento nel framework dell'architettura Google Cloud fornisce suggerimenti per aiutarti a ottimizzare l'utilizzo e i costi delle risorse Cloud Storage, Persistent Disk e Filestore.

Le indicazioni contenute in questa sezione sono rivolte agli architect e agli amministratori responsabili del provisioning e della gestione dell'archiviazione per i carichi di lavoro nel cloud.

Nota: per indicazioni sulla selezione dei servizi di archiviazione appropriati per il tuo carico di lavoro, consulta Progettare una strategia di archiviazione ottimale per il tuo carico di lavoro cloud.

Cloud Storage

Quando pianifichi Cloud Storage per i tuoi carichi di lavoro, considera i tuoi requisiti in termini di prestazioni, conservazione dei dati e pattern di accesso.

Classe di archiviazione

Scegli una classe di archiviazione adatta ai requisiti di conservazione dei dati e di frequenza di accesso dei tuoi carichi di lavoro, come consigliato nella tabella seguente:

Requisito di spazio di archiviazione	Consiglio
Dati a cui si accede di frequente (analisi o data lake ad alta velocità effettiva, siti web, video in streaming e app mobile).	Standard Storage
Archiviazione a basso costo per dati a cui si accede raramente che possono essere archiviati per almeno 30 giorni (ad esempio, backup e contenuti multimediali long-tail).	Nearline Storage
Dati a cui si accede con poca frequenza che possono essere archiviati per almeno 90 giorni (ad esempio, repliche di dati per il ripristino di emergenza).	Coldline Storage
Archiviazione a basso costo per dati a cui si accede raramente che possono essere archiviati per almeno 365 giorni (ad esempio archivi legali e normativi).	Archive Storage

Nota: le classi di archiviazione Nearline, Coldline e Archive costano meno di quelle Standard Storage, ma prevedono costi più elevati per il recupero dei dati e una perdita di eliminazione anticipata.

Località

Seleziona la località per i tuoi bucket in base ai tuoi requisiti di prestazioni, disponibilità e ridondanza dei dati.

• Le regioni sono consigliate quando la regione è vicina agli utenti finali. Puoi selezionare una regione specifica e ottenere la ridondanza garantita all'interno della regione. Le regioni offrono uno spazio di archiviazione rapido, ridondante e conveniente per i set di dati a cui gli utenti di una determinata area geografica accedono di frequente.
• Più regioni offrono alta disponibilità per gli utenti distribuiti. Tuttavia, il costo di archiviazione è superiore a quello relativo alle regioni. I bucket multiregionali sono consigliati per i casi d'uso della distribuzione di contenuti e per i carichi di lavoro di analisi di fascia bassa.
• Le due regioni offrono alta disponibilità e ridondanza dei dati. Google consiglia bucket a due regioni per carichi di lavoro di analisi ad alte prestazioni e per i casi d'uso che richiedono veri bucket attivi-attivi con computing e archiviazione collocati in più località. La doppia regione ti consente di scegliere dove archiviare i dati, aiutandoti a soddisfare i requisiti di conformità. Ad esempio, puoi utilizzare un bucket a due regioni per soddisfare requisiti specifici di settore relativi alla distanza fisica tra le copie dei dati nel cloud.

Criteri di ciclo di vita

Ottimizza i costi di archiviazione per i tuoi oggetti in Cloud Storage definendo criteri del ciclo di vita. Questi criteri ti aiutano a risparmiare eseguendo automaticamente il downgrade della classe di archiviazione di oggetti specifici o eliminando oggetti in base alle conditions impostate.

Configurare criteri del ciclo di vita in base alla frequenza di accesso agli oggetti e al tempo necessario per conservarli. Di seguito sono riportati alcuni esempi di criteri del ciclo di vita:

• Criterio di downgrade: prevedi di accedere di frequente a un set di dati, ma solo per circa tre mesi. Per ottimizzare i costi di archiviazione per questo set di dati, utilizza Standard Storage e configura un criterio del ciclo di vita per eseguire il downgrade a Coldline Storage degli oggetti più vecchi di 90 giorni.

• Norme di eliminazione: un set di dati deve essere conservato per 365 giorni per soddisfare determinati requisiti legali, dopodiché può essere eliminato. Configurare un criterio per eliminare tutti gli oggetti più vecchi di 365 giorni.

  Per assicurarti che i dati che devono essere conservati per un determinato periodo (per la conformità legale o normativa) non vengano eliminati prima di questa data o ora, configura i blocchi dei criteri di conservazione.

Nota: le classi di archiviazione a lungo termine (Nearline, Coldline e Archive) prevedono addebiti per il recupero dei dati più elevati e una perdita di eliminazione anticipata rispetto all'archiviazione Standard. Se devi accedere di frequente ai dati archiviati in una classe di archiviazione a lungo termine, per evitare costi di accesso aumentati, puoi copiare i dati in un bucket di archiviazione Standard.

Responsabilità

Per aumentare la responsabilità per i costi operativi e di rete e per i costi di recupero dei dati, utilizza la configurazione Pagamenti a carico del richiedente dove appropriato. Con questa configurazione, i costi vengono addebitati al reparto o al team che utilizza i dati, anziché al proprietario.

Definisci e assegna le etichette di monitoraggio dei costi in modo coerente per tutti i bucket e gli oggetti. Automatizza l'etichettatura quando è possibile.

Ridondanza

Utilizza le seguenti tecniche per mantenere la ridondanza dello spazio di archiviazione richiesta senza duplicazione dei dati:

• Per mantenere la resilienza dei dati con un'unica fonte attendibile, utilizza un bucket a due regioni o più regioni anziché copie ridondanti dei dati in bucket diversi. I bucket a due o più regioni forniscono ridondanza tra regioni. I dati vengono replicati in modo asincrono in due o più località e sono protetti da interruzioni regionali.
• Se abiliti il controllo delle versioni degli oggetti, valuta la possibilità di definire i criteri del ciclo di vita per rimuovere la versione meno recente di un oggetto man mano che le versioni più recenti diventano non correnti. A ogni versione non corrente di un oggetto viene addebitata la stessa tariffa della versione live dell'oggetto.
• Disabilita i criteri di controllo delle versioni degli oggetti quando non sono più necessari.
• Esamina periodicamente i criteri di conservazione degli snapshot e di backup e modificali per evitare backup e conservazione dei dati non necessari.

Persistent Disk

Ogni istanza VM di cui esegui il deployment in Compute Engine ha un disco di avvio e (facoltativamente) uno o più dischi dati. I costi di ogni disco dipendono dalla dimensione, dalla regione e dal tipo di disco di cui è stato eseguito il provisioning. Qualsiasi snapshot dei tuoi dischi comporta un costo in base alle dimensioni dello snapshot.

Utilizza i seguenti suggerimenti operativi e di progettazione per ottimizzare il costo dei dischi permanenti:

• Non allocare uno spazio su disco eccessivo Non è possibile ridurre la capacità del disco dopo il provisioning. Inizia con un disco di piccole dimensioni e aumenta le dimensioni quando necessario. I dischi permanenti vengono fatturati per la capacità di cui è stato eseguito il provisioning, non per i dati archiviati sui dischi.

• Scegli un tipo di disco che corrisponda alle caratteristiche delle prestazioni del carico di lavoro. L'SSD offre un numero elevato di IOPS e velocità effettiva, ma costa di più rispetto ai dischi permanenti standard.

• Utilizza i dischi permanenti a livello di regione solo quando è essenziale proteggere i dati da interruzioni a livello di zona. I dischi permanenti a livello di regione vengono replicati in un'altra zona all'interno della regione, quindi ti vengono addebitati il doppio del costo dei dischi di zona equivalenti.

• Monitora l'utilizzo dei dischi permanenti con Cloud Monitoring e configura avvisi per i dischi con utilizzo ridotto.

• Elimina i dischi che non ti servono più.

• Per i dischi che contengono dati che potrebbero servirti in futuro, considera l'archiviazione dei dati su Cloud Storage a basso costo e poi l'eliminazione dei dischi.

• Cerca e rispondi ai consigli nell'hub dei suggerimenti.

Prendi in considerazione anche l'utilizzo di hyperdisk per un'archiviazione ad alte prestazioni e di dischi temporanei (SSD locali) per l'archiviazione temporanea.

Gli snapshot del disco sono incrementali per impostazione predefinita e vengono compressi automaticamente. Considera i seguenti suggerimenti per ottimizzare il costo degli snapshot del disco:

• Se possibile, organizza i dati in dischi permanenti separati. Puoi quindi scegliere di eseguire il backup dei dischi in modo selettivo e ridurre il costo degli snapshot del disco.
• Quando crei uno snapshot, seleziona una località in base ai requisiti di disponibilità e ai costi di rete associati.
• Se intendi utilizzare lo snapshot di un disco di avvio per creare più VM, crea un'immagine dallo snapshot, quindi utilizza l'immagine per creare le VM. Questo approccio consente di evitare addebiti di rete per i dati trasferiti tra la località dello snapshot e la località in cui li ripristini.
• Valuta la possibilità di configurare un criterio di conservazione per ridurre al minimo i costi di archiviazione a lungo termine per gli snapshot dei dischi.
• Elimina gli snapshot dei dischi che non ti servono più. Ogni snapshot di una catena potrebbe dipendere dai dati archiviati in uno snapshot precedente. Pertanto, l'eliminazione di uno snapshot non comporta necessariamente l'eliminazione di tutti i dati al suo interno. Per eliminare definitivamente i dati dagli snapshot, devi eliminare tutti gli snapshot nella catena.

Filestore

Il costo di un'istanza Filestore dipende dal livello di servizio, dalla capacità di cui è stato eseguito il provisioning e dalla regione in cui viene eseguito il provisioning dell'istanza. Di seguito sono riportati suggerimenti operativi e di progettazione per ottimizzare il costo delle istanze Filestore:

• Seleziona un livello di servizio e un tipo di archiviazione (HDD o SSD) appropriato per le tue esigenze di archiviazione.
• Non allocare capacità eccessiva. Inizia con una dimensione piccola e aumentala in un secondo momento quando necessario. La fatturazione di Filestore si basa sulla capacità di cui è stato eseguito il provisioning, non sui dati archiviati.
• Ove possibile, organizza i dati in istanze Filestore separate. Puoi quindi scegliere di eseguire il backup delle istanze in modo selettivo e ridurre i costi dei backup di Filestore.
• Quando scegli la regione e la zona, valuta la possibilità di creare istanze nella stessa zona dei client. Ti verrà addebitato il traffico di Data Transfer dalla zona dell'istanza Filestore.
• Quando decidi la regione in cui archiviare i backup di Filestore, prendi in considerazione gli addebiti di Data Transfer per l'archiviazione dei backup in una regione diversa dall'istanza di origine.
• Monitora l'utilizzo delle istanze Filestore con Cloud Monitoring e configura avvisi per le istanze con utilizzo ridotto.
• Fai lo scale down della capacità allocata per le istanze Filestore con un utilizzo ridotto. Puoi ridurre la capacità delle istanze, tranne il livello base.

Passaggi successivi

• Esamina le best practice per l'ottimizzazione dei costi di Cloud Storage (blog)
• Ottimizza i costi di servizi di computing, database, networking e operazioni:
  • Ottimizzazione dei costi: computing, container e serverless
  • Ottimizzazione dei costi: database e analisi intelligente
  • Ottimizzazione dei costi: networking
  • Ottimizzazione dei costi: operazioni cloud
• Esplora le altre categorie del framework dell'architettura Google Cloud

Ottimizzazione dei costi: database e analisi intelligente

Questo documento nel framework dell'architettura Google Cloud fornisce suggerimenti per aiutarti a ottimizzare il costo dei database e dei carichi di lavoro di analisi in Google Cloud.

Le indicazioni in questa sezione sono rivolte ad architect, sviluppatori e amministratori responsabili del provisioning e della gestione dei database e dei carichi di lavoro di analisi nel cloud.

Questa sezione include suggerimenti sull'ottimizzazione dei costi per i seguenti prodotti:

• Cloud SQL
• Spanner
• Bigtable
• BigQuery
• Dataflow
• Dataproc

Cloud SQL

Cloud SQL è un database relazionale completamente gestito per MySQL, PostgreSQL e SQL Server.

Monitora l'utilizzo

Esamina le metriche nella dashboard di monitoraggio e verifica che il deployment soddisfi i requisiti del carico di lavoro.

Ottimizza le risorse

Di seguito sono riportati alcuni suggerimenti per aiutarti a ottimizzare le risorse Cloud SQL:

• Progetta una strategia ad alta disponibilità e di ripristino di emergenza in linea con l'RTO (Recovery Time Objective) e l'RPO (Recovery Point Objective). A seconda del carico di lavoro, consigliamo quanto segue:
  • Per i carichi di lavoro che richiedono un RTO e un RPO brevi, utilizza la configurazione ad alta disponibilità e le repliche per il failover a livello di regione.
  • Per i carichi di lavoro in grado di tollerare un RTO e un RPO più lunghi, utilizza backup automatici e on demand, il cui ripristino in seguito a un errore può richiedere più tempo.
• Esegui il provisioning del database con la capacità di archiviazione minima richiesta.
• Per scalare automaticamente la capacità di archiviazione di pari passo con l'aumento dei dati, abilita la funzionalità di aumento automatico dello spazio di archiviazione.
• Scegli il tipo di archiviazione, unità a stato solido (SSD) o disco rigido (HDD), appropriato per il tuo caso d'uso. SSD è la scelta più efficiente ed economica per la maggior parte dei casi d'uso. HDD potrebbe essere appropriato per set di dati di grandi dimensioni (> 10 TB) non sensibili alla latenza o a cui si accede raramente.

Ottimizza i tassi

Prendi in considerazione l'acquisto di sconti per impegno di utilizzo per carichi di lavoro con esigenze prevedibili in termini di risorse. Puoi risparmiare il 25% dei prezzi on demand per un impegno di 1 anno e il 52% per un impegno di 3 anni.

Spanner

Spanner è un database cloud-native, a scalabilità illimitata e a elevata coerenza, che offre una disponibilità fino al 99,999%.

Monitora l'utilizzo

Di seguito sono riportati alcuni suggerimenti per aiutarti a monitorare l'utilizzo delle risorse di Spanner:

• Monitora il deployment e configura il numero dei nodi in base ai suggerimenti per le CPU.
• Imposta avvisi sui tuoi deployment per ottimizzare le risorse di archiviazione. Per determinare la configurazione appropriata, fai riferimento ai limiti per nodo consigliati.

Ottimizza le risorse

Di seguito sono riportati alcuni suggerimenti utili per ottimizzare le risorse Spanner:

• Esegui carichi di lavoro più piccoli su Spanner a costi molto inferiori eseguendo il provisioning delle risorse con le unità di elaborazione (PU) rispetto ai nodi. Un nodo Spanner equivale a 1000 PU.
• Migliora le prestazioni di esecuzione delle query con lo strumento di ottimizzazione delle query.
• Crea istruzioni SQL utilizzando le best practice per la creazione di piani di esecuzione efficienti.
• Gestire l'utilizzo e le prestazioni dei deployment Spanner utilizzando lo strumento Gestore della scalabilità automatica. Lo strumento monitora le istanze, aggiunge o rimuove automaticamente i nodi e ti aiuta a garantire che le istanze rimangano entro i limiti di CPU e spazio di archiviazione consigliati.
• Proteggiti da eliminazioni o scritture accidentali utilizzando il recupero point-in-time (PITR). I database con periodi di conservazione delle versioni più lunghi (in particolare quelli che sovrascrivono spesso i dati) utilizzano più risorse di sistema e hanno bisogno di più nodi.
• Esamina la tua strategia di backup e scegli una delle seguenti opzioni:
  • Backup e ripristino
  • Esporta e importa

Ottimizza i tassi

Quando decidi la località dei tuoi nodi Spanner, considera le differenze di costo tra le regioni Google Cloud. Ad esempio, un nodo di cui è stato eseguito il deployment nella regione us-central1 costa molto meno all'ora rispetto a un nodo nella regione southamerica-east1.

Bigtable

Bigtable è un archivio NoSQL a colonne larghe cloud-native per carichi di lavoro a bassa latenza su larga scala.

Monitora l'utilizzo

Di seguito sono riportati alcuni suggerimenti per aiutarti a monitorare l'utilizzo delle risorse Bigtable:

• Analizza le metriche di utilizzo per identificare le opportunità di ottimizzazione delle risorse.
• Identifica hotspot e tasti di scelta rapida nel tuo cluster Bigtable utilizzando lo strumento di diagnostica Key Visualizer.

Ottimizza le risorse

Di seguito sono riportati alcuni suggerimenti utili per ottimizzare le risorse Bigtable:

• Per aiutarti a garantire utilizzo di CPU e disco in modo da trovare un equilibrio tra latenza e capacità di archiviazione, valuta e regola il numero e le dimensioni dei nodi del cluster Bigtable.
• Mantieni le prestazioni al minor costo possibile scalando in modo programmatico il cluster Bigtable per regolare automaticamente il numero dei nodi.

• Valuta il tipo di archiviazione (HDD o SSD) più conveniente per il tuo caso d'uso in base alle seguenti considerazioni:

  • L'archiviazione HDD costa meno di SSD, ma ha prestazioni inferiori.
  • L'archiviazione SSD costa più dell'HDD, ma offre prestazioni più rapide e prevedibili.

  I risparmi sui costi dell'HDD sono minimi rispetto al costo dei nodi nel cluster Bigtable, a meno che non vengano archiviate grandi quantità di dati. L'archiviazione HDD a volte è appropriata per set di dati di grandi dimensioni (> 10 TB) non sensibili alla latenza o a cui si accede raramente.

• Rimuovi i dati scaduti e obsoleti utilizzando la garbage collection.

• Per evitare hotspot, applica le best practice per la progettazione delle chiavi di riga.

• Progetta un piano di backup conveniente in linea con il tuo RPO.

• Per ridurre l'utilizzo del cluster e ridurre il numero dei nodi, valuta l'aggiunta di una cache di capacità per le query memorizzabili nella cache utilizzando Memorystore.

Letture aggiuntive

• Blog: introduzione all'ottimizzazione dei costi di Bigtable
• Blog: Best practice per le prestazioni e l'ottimizzazione dei costi di Bigtable

BigQuery

BigQuery è un data warehouse multi-cloud serverless, a scalabilità elevata e dai costi contenuti, progettato per l'agilità aziendale.

Monitora l'utilizzo

Di seguito sono riportati alcuni suggerimenti utili per monitorare l'utilizzo delle risorse BigQuery:

• Visualizza i costi BigQuery segmentati per progetti e utenti. Identifica le query più costose e ottimizzale.
• Analizza l'utilizzo degli slot tra progetti, job e prenotazioni utilizzando le tabelle di metadati INFORMATION_SCHEMA.

Ottimizza le risorse

Di seguito sono riportati alcuni suggerimenti utili per ottimizzare le risorse BigQuery:

• Imposta le scadenze a livello di set di dati, di tabella o di partizione per i dati in base alla strategia di conformità.
• Limita i costi delle query limitando il numero di byte fatturati per query. Per evitare errori umani accidentali, abilita il controllo dei costi a livello di utente e di progetto.
• Esegui query solo sui dati di cui hai bisogno. Evita scansioni complete delle query. Per esplorare e comprendere la semantica dei dati, utilizza le opzioni di anteprima dei dati senza costi.
• Per ridurre i costi di elaborazione e migliorare le prestazioni, esegui il partizionamento e il clustering delle tabelle, se possibile.
• Filtra la tua query il prima possibile e il più spesso possibile.
• Durante l'elaborazione dei dati da più origini (come Bigtable, Cloud Storage, Google Drive e Cloud SQL), evita di duplicare i dati utilizzando un modello di dati di accesso federato ed eseguendo query sui dati direttamente dalle origini.
• Sfrutta il backup di BigQuery anziché duplicare i dati. Consulta la pagina Scenari di ripristino di emergenza per i dati.

Ottimizza i tassi

Di seguito sono riportati alcuni suggerimenti per aiutarti a ridurre le tariffe di fatturazione per le tue risorse BigQuery:

• Valuta come modificare i dati e sfrutta prezzi di archiviazione a lungo termine più bassi.
• Esamina le differenze tra i pricing a costo fisso e on demand e scegli un'opzione adatta alle tue esigenze.
• Valuta se puoi utilizzare il caricamento in batch anziché l'inserimento di flussi di dati per i flussi di lavoro relativi ai dati. Utilizza l'inserimento di flussi di dati se i dati caricati in BigQuery vengono consumati immediatamente.
• Per aumentare le prestazioni e ridurre i costi di recupero dei dati, utilizza i risultati delle query memorizzati nella cache.

Letture aggiuntive

• Controllo dei costi di BigQuery
• Best practice per l'ottimizzazione dei costi per BigQuery
• Informazioni sui principi di ottimizzazione dei costi (PDF)

Dataflow

Dataflow è un servizio serverless veloce e conveniente per l'elaborazione unificata dei dati in modalità flusso e batch.

Monitora l'utilizzo

Di seguito sono riportati alcuni suggerimenti per aiutarti a monitorare l'utilizzo delle risorse Dataflow:

• Prevedi il costo dei job Dataflow eseguendo piccoli esperimenti di carico, individuando le prestazioni ottimali del job ed estrapolando il fattore di velocità effettiva.
• Aumenta la visibilità sulla velocità effettiva e sull'utilizzo della CPU tramite le dashboard di osservabilità.
• Osserva le metriche delle pipeline relative a prestazioni, esecuzione e integrità utilizzando l'interfaccia di monitoraggio di Dataflow.

Ottimizza le risorse

Di seguito sono riportati alcuni suggerimenti per aiutarti a ottimizzare le risorse Dataflow:

• Valuta Dataflow Prime per elaborare i big data in modo efficiente.
• Riduci i costi di elaborazione batch utilizzando FlexRS (FlexRS) per le pipeline in batch con scalabilità automatica. FlexRS utilizza pianificazione avanzata, shuffle Dataflow e una combinazione di VM prerilasciabili e VM normali per ridurre i costi delle pipeline batch.
• Migliora le prestazioni utilizzando il servizio di shuffling in memoria anziché il Persistent Disk e i nodi worker.
• Per una scalabilità automatica più reattiva e per ridurre il consumo di risorse, usa Streaming Engine, che sposta l'esecuzione della pipeline dalle VM worker al backend del servizio Dataflow.
• Se la pipeline non ha bisogno dell'accesso da e verso internet e altre reti Google Cloud, disabilita gli indirizzi IP pubblici. La disattivazione dell'accesso a internet consente di ridurre i costi di rete e di migliorare la sicurezza delle pipeline.
• Segui le best practice per una pipeline efficiente con Dataflow.

Dataproc

Dataproc è un servizio Apache Spark e Apache Hadoop gestito per elaborazione batch, query, inserimento di flussi e machine learning.

Di seguito sono riportati alcuni suggerimenti per aiutarti a ottimizzare il costo delle risorse Dataproc:

• Scegli i tipi di macchina appropriati per il tuo carico di lavoro.
• Scala automaticamente per soddisfare la domanda utilizzando cluster con scalabilità automatica e paga solo per le risorse di cui hai bisogno.
• Se al completamento del job è possibile eliminare un cluster, valuta la possibilità di eseguire il provisioning di un cluster temporaneo utilizzando un modello di flusso di lavoro in cluster gestito.
• Per evitare addebiti per un cluster inattivo, utilizza l'eliminazione pianificata, che consente di eliminare un cluster dopo un determinato periodo di inattività, in un orario o dopo un periodo specificato.
• Segui le best practice per la creazione di cluster di lunga durata su Dataproc.
• Acquista sconti per impegno di utilizzo per carichi di lavoro sempre attivi.

Passaggi successivi

• Ottimizza i costi di servizi di computing, archiviazione, networking e operazioni:
  • Ottimizzazione dei costi: computing, container e serverless
  • Ottimizza i costi: spazio di archiviazione
  • Ottimizzazione dei costi: networking
  • Ottimizzazione dei costi: operazioni cloud
• Esplora le altre categorie del framework dell'architettura Google Cloud

Ottimizza i costi: networking

Questo documento nel framework dell'architettura Google Cloud fornisce suggerimenti per aiutarti a ottimizzare il costo delle risorse di networking in Google Cloud.

Le indicazioni contenute in questa sezione sono rivolte ad architect e amministratori responsabili del provisioning e della gestione del networking per i carichi di lavoro nel cloud.

Note sul layout

Una differenza fondamentale tra le reti on-premise e cloud è il modello di costo dinamico e basato sull'utilizzo nel cloud, rispetto al costo fisso delle reti nei data center tradizionali.

Quando si pianificano reti cloud, è fondamentale comprendere il modello di pricing, che si basa sulla direzione del traffico, come segue:

• Non ti viene addebitato alcun costo per il traffico in entrata verso Google Cloud. Le risorse che elaborano il traffico in entrata, come Cloud Load Balancing, prevedono dei costi.
• Per il traffico di Data Transfer, che include sia il traffico tra macchine virtuali (VM) in Google Cloud sia il traffico da Google Cloud a internet e agli host on-premise, i prezzi si basano sui seguenti fattori:
  • Utilizzo di un indirizzo IP interno o esterno
  • Superamento di confini a livello di zona o di regione
  • Traffico in uscita da Google Cloud
  • Distanza percorsa dal traffico prima di lasciare Google Cloud

Quando due VM o risorse cloud all'interno di Google Cloud comunicano, il traffico in ciascuna direzione viene designato come trasferimento di dati in uscita all'origine e al trasferimento di dati in entrata a destinazione e i prezzi vengono calcolati di conseguenza.

Prendi in considerazione i seguenti fattori per la progettazione di reti cloud ottimali in termini di costi:

• Geolocalizzazione
• Layout di rete
• Opzioni di connettività
• Livelli di servizi di rete
• Logging

Questi fattori sono discussi in modo più dettagliato nelle sezioni seguenti.

Geolocalizzazione

I costi di Networking possono variare a seconda della regione Google Cloud in cui viene eseguito il provisioning delle risorse. Per analizzare la larghezza di banda della rete tra le regioni, puoi utilizzare i log di flusso VPC e Network Intelligence Center. Per il traffico che scorre tra le regioni Google Cloud, il costo può variare a seconda della località delle regioni anche se il traffico non passa attraverso internet.

Oltre alla regione Google Cloud, considera le zone in cui viene eseguito il deployment delle risorse. A seconda dei requisiti di disponibilità, potresti essere in grado di progettare le tue applicazioni in modo che comunichino senza costi all'interno di una zona tramite indirizzi IP interni. Nel valutare un'architettura a zona singola, valuta i potenziali risparmi nei costi del networking con l'impatto sulla disponibilità.

Layout di rete

Analizza il layout di rete, il modo in cui il traffico scorre tra le tue applicazioni e gli utenti e la larghezza di banda consumata da ogni applicazione o utente. Lo strumento Network Topology offre una visibilità completa del deployment globale di Google Cloud e della sua interazione con la rete internet pubblica, compresa una visualizzazione della topologia a livello di organizzazione e le metriche delle prestazioni della rete associate. Puoi identificare i deployment inefficienti e intraprendere le azioni necessarie per ottimizzare i costi di trasferimento dei dati a livello di regione e intercontinentale.

Opzioni di connettività

Quando devi eseguire spesso il push di un grande volume di dati (TB o PB) da ambienti on-premise a Google Cloud, valuta la possibilità di utilizzare Dedicated Interconnect o Partner Interconnect. Una connessione dedicata può essere più economica rispetto ai costi associati all'attraversamento della rete internet pubblica o all'utilizzo di una VPN.

Se possibile, utilizza l'accesso privato Google per ridurre i costi e migliorare la strategia di sicurezza.

Network Service Tiers

Per impostazione predefinita, l'infrastruttura di rete premium di Google (livello Premium) viene utilizzata per tutti i servizi. Per le risorse che non hanno bisogno delle prestazioni elevate e della bassa latenza offerte dal livello Premium, puoi scegliere il livello Standard, che costa meno.

Quando scegli un livello di servizio, considera le differenze tra i livelli e le limitazioni del livello Standard. Perfeziona la rete in base alle esigenze della tua applicazione e riduci potenzialmente i costi di networking per i servizi che possono tollerare una maggiore latenza e non richiedono uno SLA.

Logging

I log di flusso VPC, il logging delle regole firewall e il logging di Cloud NAT consentono di analizzare i log di rete e identificare opportunità per ridurre i costi.

Per i log di flusso VPC e Cloud Load Balancing, puoi anche abilitare il campionamento, che può ridurre il volume dei log scritti nel database. Puoi variare la frequenza di campionamento da 1,0 (tutte le voci di log vengono conservate) a 0,0 (nessun log viene conservato). Per la risoluzione dei problemi o casi d'uso personalizzati, puoi scegliere di raccogliere sempre i dati di telemetria per una determinata rete o subnet VPC oppure monitorare un'istanza VM o un'interfaccia virtuale specifiche.

Suggerimenti di progettazione

Per ottimizzare il traffico di rete, consigliamo quanto segue:

• Progetta le tue soluzioni per avvicinare le applicazioni alla tua base utenti. Utilizza Cloud CDN per ridurre il volume del traffico e la latenza e sfrutta i prezzi più bassi di CDN per pubblicare contenuti a cui ti aspetti l'accesso frequente da molti utenti.
• Evita di sincronizzare i dati a livello globale tra regioni lontane dall'utente finale o che possono comportare costi di networking elevati. Se un'applicazione viene utilizzata solo all'interno di una regione, evita il trattamento dati tra regioni.
• Assicurati che la comunicazione tra le VM all'interno di una zona sia instradata tramite i relativi indirizzi IP interni e non esternamente.
• Riduci i costi di trasferimento di dati e la latenza del client comprimendo l'output dei dati.
• Analizza i pattern di spesa e identifica le opportunità per controllare i costi osservando i flussi di traffico in uscita e in entrata per i progetti critici utilizzando i log di flusso VPC.
• Durante la progettazione delle reti nel cloud, considera il compromesso tra l'alta disponibilità offerta da una rete distribuita e i risparmi sui costi derivanti dalla centralizzazione del traffico all'interno di una singola zona o regione.

Per ottimizzare il prezzo che paghi per i servizi di networking, ti consigliamo quanto segue:

• Se la località del server non è vincolata, valuta il costo in base alle diverse regioni e seleziona quella più conveniente. Per il traffico generale in uscita, come i contenuti pubblicati da un gruppo di server web, i prezzi possono variare a seconda della regione in cui viene eseguito il provisioning dei server.
• Per ridurre i costi per lo spostamento frequente di elevati volumi di dati nel cloud, utilizza una connessione diretta tra le reti on-premise e Google Cloud. Valuta la possibilità di utilizzare Dedicated Interconnect o Partner Interconnect.
• Scegli un livello di servizio appropriato per ogni ambiente, ovvero il livello Standard per gli ambienti di sviluppo e test e il livello Premium per la produzione.

Passaggi successivi

• Esaminare le informazioni sui prezzi della rete
• Esamina le best practice per l'ottimizzazione dei costi del networking
• Ottimizza i costi di servizi di computing, archiviazione, database e operazioni:
  • Ottimizzazione dei costi: computing, container e serverless
  • Ottimizza i costi: spazio di archiviazione
  • Ottimizzazione dei costi: database e analisi intelligente
  • Ottimizzazione dei costi: operazioni cloud
• Esplora le altre categorie del framework dell'architettura Google Cloud

Ottimizzazione dei costi: operazioni cloud

Questo documento nel framework dell'architettura Google Cloud fornisce suggerimenti per aiutarti a ottimizzare i costi di monitoraggio e gestione delle risorse in Google Cloud.

Le indicazioni in questa sezione sono rivolte agli utenti del cloud responsabili del monitoraggio e del controllo dell'utilizzo e dei costi delle risorse della propria organizzazione nel cloud.

Google Cloud Observability è una raccolta di servizi gestiti che puoi utilizzare per monitorare, risolvere i problemi e migliorare le prestazioni dei tuoi carichi di lavoro in Google Cloud. Questi servizi includono Cloud Monitoring, Cloud Logging, Error Reporting, Cloud Trace e Cloud Profiler. Uno dei vantaggi dei servizi gestiti in Google Cloud è che si basano sull'utilizzo. Paghi solo per ciò che utilizzi e in base al volume di dati, con allocazioni mensili gratuite per l'utilizzo dei dati e accesso illimitato alle metriche e agli audit log di Google Cloud.

Cloud Logging

Di seguito sono riportati alcuni suggerimenti per aiutarti a ottimizzare il costo delle operazioni di logging:

• Filtra i report di fatturazione per visualizzare i costi di Logging.
• Riduci il volume dei log importati e archiviati escludendo o filtrando le voci di log non necessarie.
• Verifica che i filtri di esclusione siano adeguati monitoring le metriche billing/bytes_ingested e billing/monthly_bytes_ingested nella console Google Cloud.
• Esegui l'offload ed esporta i log in uno spazio di archiviazione a costi inferiori.
• Quando crei un flusso di dati nei log da applicazioni di terze parti, riduci i volumi dei log utilizzando l'agente di logging solo sulle istanze di produzione o configurandolo per inviare meno dati.

Cloud Monitoring

Di seguito sono riportati alcuni suggerimenti per aiutarti a ottimizzare i costi delle operazioni di monitoraggio:

• Ottimizza le metriche e l'utilizzo delle etichette limitando il numero di etichette. Evita etichette con cardinalità elevata. Ad esempio, se utilizzi un indirizzo IP come etichetta, ogni indirizzo IP avrà una serie di etichette con un singolo elemento, che si traducono in numerose etichette quando si dispone di molte VM.
• Riduci il volume delle metriche dettagliate per le applicazioni che non le richiedono o rimuovi l'agente di monitoraggio, soprattutto per gli ambienti non essenziali.
• Riduci al minimo il volume di importazione riducendo il numero di metriche personalizzate inviate dall'applicazione.

Cloud Trace

Di seguito sono riportati alcuni suggerimenti per aiutarti a ottimizzare il costo delle operazioni di Trace:

• Se utilizzi Trace come destinazione di esportazione per le tracce OpenCensus, riduci il volume delle tracce importate utilizzando la funzionalità di campionamento in OpenCensus.
• Limita l'utilizzo di Trace e controlla i costi tramite le quote. Puoi applicare le quote di intervalli utilizzando la pagina delle quote specifica dell'API nella console Google Cloud.

Passaggi successivi

• Ottimizzare i costi per l'osservabilità di Google Cloud
• Video: Gestire i costi per l'osservabilità di Google Cloud
• Ottimizza i costi di servizi di computing, archiviazione, database e networking:
  • Ottimizzazione dei costi: computing, container e serverless
  • Ottimizza i costi: spazio di archiviazione
  • Ottimizzazione dei costi: database e analisi intelligente
  • Ottimizzazione dei costi: networking
• Esplora le altre categorie del framework dell'architettura Google Cloud

Framework dell'architettura Google Cloud: ottimizzazione delle prestazioni

Questa categoria nel framework dell'architettura Google Cloud descrive il processo di ottimizzazione delle prestazioni e le best practice per ottimizzare le prestazioni dei carichi di lavoro in Google Cloud.

Le informazioni contenute in questo documento sono rivolte ad architect, sviluppatori e amministratori che pianificano, progettano, eseguono il deployment e gestiscono i carichi di lavoro in Google Cloud.

L'ottimizzazione delle prestazioni dei carichi di lavoro nel cloud può aiutare la tua organizzazione a operare in modo efficiente, migliorare la soddisfazione del cliente, aumentare le entrate e ridurre i costi. Ad esempio, quando il tempo di elaborazione di un'applicazione diminuisce, gli utenti riscontrano tempi di risposta più rapidi, il che può portare a una maggiore fidelizzazione degli utenti e a maggiori entrate.

Potrebbero esserci dei compromessi tra prestazioni e costi. A volte, però, l'ottimizzazione del rendimento può aiutarti a ridurre i costi. Ad esempio, la scalabilità automatica contribuisce a offrire prestazioni prevedibili quando il carico aumenta, garantendo che le risorse non siano sovraccaricate. La scalabilità automatica consente inoltre di ridurre i costi durante i periodi di basso carico rimuovendo le risorse inutilizzate.

In questa categoria del framework dell'architettura, imparerai a fare quanto segue:

• Implementa il processo di ottimizzazione del rendimento.
• Monitorare e analizzare il rendimento.
• Ottimizza le prestazioni di computing.
• Ottimizzare le prestazioni dello spazio di archiviazione.
• Ottimizzare le prestazioni del networking.
• Ottimizza le prestazioni del database.
• Ottimizzare il rendimento dell'analisi.

Procedura di ottimizzazione delle prestazioni

Questo documento nel framework dell'architettura Google Cloud fornisce una panoramica del processo di ottimizzazione delle prestazioni.

L'ottimizzazione delle prestazioni è un processo continuo, non un'attività una tantum. Il seguente diagramma mostra le fasi del processo di ottimizzazione delle prestazioni:

Di seguito è riportata una panoramica delle fasi del processo di ottimizzazione del rendimento:

Definisci i requisiti di prestazioni

Prima di iniziare a progettare e sviluppare le applicazioni di cui intendi eseguire il deployment o la migrazione al cloud, determina i requisiti delle prestazioni. Definisci i requisiti nel modo più granulare possibile per ogni livello dello stack di applicazioni: bilanciamento del carico frontend, server web o delle applicazioni, database e archiviazione. Ad esempio, per il livello di archiviazione dello stack, decidi la velocità effettiva e le operazioni di I/O al secondo (IOPS) necessarie per le tue applicazioni.

Progetta ed esegui il deployment delle tue applicazioni

Progetta le tue applicazioni utilizzando pattern di progettazione elastici e scalabili che possano aiutarti a soddisfare i requisiti di prestazioni. Considera le seguenti linee guida per progettare applicazioni elastiche e scalabili:

• Architettare i carichi di lavoro per un posizionamento ottimale dei contenuti.
• Isolare il traffico di lettura e scrittura.
• Isolare il traffico statico e dinamico.
• Implementare la memorizzazione nella cache dei contenuti. Usare le cache di dati per i livelli interni.
• Utilizza servizi gestiti e architetture serverless.

Google Cloud fornisce strumenti open source che puoi utilizzare per confrontare le prestazioni dei servizi Google Cloud con altre piattaforme cloud.

Monitorare e analizzare il rendimento

Dopo aver eseguito il deployment delle applicazioni, monitora costantemente le prestazioni utilizzando log e avvisi, analizza i dati e identifica i problemi di prestazioni. Man mano che le applicazioni crescono e si evolvono, rivaluta i tuoi requisiti di prestazioni. Potresti dover riprogettare alcune parti delle applicazioni per mantenere o migliorare le prestazioni.

Ottimizzazione del rendimento

In base alle prestazioni delle tue applicazioni e ai cambiamenti dei requisiti, configura le risorse cloud per soddisfare gli attuali requisiti di prestazioni. Ad esempio, ridimensiona le risorse o configura la scalabilità automatica. Quando configuri le risorse, valuta le opportunità di utilizzare funzionalità e servizi Google Cloud rilasciati di recente che possono contribuire a ottimizzare ulteriormente le prestazioni.

Il processo di ottimizzazione del rendimento non termina a questo punto. Continua il ciclo di monitoraggio delle prestazioni, rivalutazione dei requisiti se necessario e modifica delle risorse cloud per mantenere e migliorare le prestazioni.

Passaggi successivi

• Monitorare e analizzare il rendimento.
• Ottimizza le prestazioni di computing.
• Ottimizzare le prestazioni dello spazio di archiviazione.
• Ottimizzare le prestazioni del networking.
• Ottimizza le prestazioni del database.
• Ottimizzare il rendimento dell'analisi.

Monitorare e analizzare il rendimento

Questo documento nel framework dell'architettura Google Cloud descrive i servizi di osservabilità di Google Cloud che puoi utilizzare per registrare, monitorare e analizzare le prestazioni dei tuoi carichi di lavoro.

Monitorare le metriche sul rendimento

Utilizza Cloud Monitoring per analizzare le tendenze delle metriche sulle prestazioni, analizzare gli effetti degli esperimenti, definire gli avvisi per le metriche critiche ed eseguire analisi retrospettive.

Registra dati ed eventi critici

Cloud Logging è un servizio di logging integrato che puoi utilizzare per archiviare, analizzare, monitorare e impostare avvisi per dati di log ed eventi. Cloud Logging può raccogliere i log dai servizi di Google Cloud e di altri cloud provider.

Analizzare le prestazioni del codice

Il codice con prestazioni scarse può aumentare la latenza delle applicazioni e i costi di esecuzione. Cloud Profiler ti aiuta a identificare e risolvere i problemi di prestazioni analizzando continuamente le prestazioni delle funzioni che utilizzano la CPU o la memoria in modo intensivo.

Raccogliere dati sulla latenza

In stack di applicazioni complessi e architetture basate su microservizi, valutare la latenza nella comunicazione tra i servizi e identificare i colli di bottiglia delle prestazioni può essere difficile. Gli strumenti Cloud Trace e OpenTelemetry consentono di raccogliere dati sulla latenza dai deployment su larga scala. Questi strumenti aiutano anche ad analizzare i dati sulla latenza in modo efficiente.

Monitorare le prestazioni della rete

La dashboard sulle prestazioni del Network Intelligence Center offre una visione completa delle metriche delle prestazioni per la rete Google e le risorse nel progetto. Queste metriche possono aiutarti a determinare la causa dei problemi di prestazioni della rete. Ad esempio, puoi identificare se un problema di prestazioni è il risultato di un problema nel tuo progetto o nella rete Google.

Passaggi successivi

• Scopri le best practice per il monitoraggio delle risorse cloud.
• Consulta le best practice per ottimizzare le prestazioni delle tue risorse Google Cloud:
  • Ottimizza le prestazioni di computing.
  • Ottimizzare le prestazioni dello spazio di archiviazione.
  • Ottimizzare le prestazioni del networking.
  • Ottimizza le prestazioni del database.
  • Ottimizzare il rendimento dell'analisi.

Ottimizza le prestazioni di computing

Questo documento nel framework dell'architettura Google Cloud fornisce suggerimenti per ottimizzare le prestazioni di Compute Engine, Google Kubernetes Engine (GKE) e delle risorse serverless.

Compute Engine

Questa sezione fornisce indicazioni per ottimizzare le prestazioni delle risorse di Compute Engine.

Scalabilità automatica delle risorse

I gruppi di istanze gestite (MIG) ti consentono di scalare in modo efficiente le app stateless di cui è stato eseguito il deployment nelle VM di Compute Engine. La scalabilità automatica consente alle app di continuare a offrire prestazioni prevedibili quando il carico aumenta. In un gruppo di istanze gestite, viene avviato un gruppo di VM di Compute Engine in base a un modello definito da te. Nel modello, configurerai un criterio di scalabilità automatica che specifica uno o più indicatori utilizzati dal gestore della scalabilità automatica per scalare il gruppo. Gli indicatori di scalabilità automatica possono essere basati sulla pianificazione, ad esempio ora di inizio o durata, oppure su metriche di destinazione come l'utilizzo medio della CPU. Per maggiori informazioni, consulta Scalabilità automatica dei gruppi di istanze.

Disabilita SMT

Ogni CPU virtuale (vCPU) allocata a una VM di Compute Engine viene implementata come un singolo multithread hardware. Per impostazione predefinita, due vCPU condividono un core CPU fisico. Questa architettura è chiamata SMT (simultaneous multi-threading).

Per i carichi di lavoro altamente paralleli o che eseguono calcoli in virgola mobile (come transcodifica, simulazioni Monte Carlo, analisi di sequenze genetiche e modellazione del rischio finanziario), puoi migliorare le prestazioni disattivando SMT. Per maggiori informazioni, consulta Impostare il numero di thread per core.

Utilizza GPU

Per carichi di lavoro quali machine learning e visualizzazione, puoi aggiungere unità di elaborazione grafica (GPU) alle tue VM. Compute Engine fornisce GPU NVIDIA in modalità passthrough, in modo che le VM abbiano il controllo diretto sulle GPU e sulla memoria associata. Per i carichi di lavoro che richiedono molta grafica come la visualizzazione 3D, puoi utilizzare le workstation virtuali NVIDIA RTX. Dopo aver eseguito il deployment dei carichi di lavoro, monitora l'utilizzo della GPU e rivedi le opzioni per ottimizzare le prestazioni della GPU.

Utilizza tipi di macchine ottimizzate per il calcolo

Carichi di lavoro come giochi, transcodifica multimediale e computing ad alte prestazioni (HPC) richiedono prestazioni costantemente elevate per core CPU. Google consiglia di utilizzare tipi di macchine ottimizzate per il calcolo per le VM che eseguono questi carichi di lavoro. Le VM ottimizzate per il calcolo sono basate su un'architettura che utilizza funzionalità come l'accesso alla memoria non uniforme (NUMA) per prestazioni ottimali e affidabili.

I carichi di lavoro HPC a stretto accoppiamento hanno un insieme unico di requisiti per raggiungere la massima efficienza in termini di prestazioni. Per ulteriori informazioni, consulta la seguente documentazione:

• File system paralleli per carichi di lavoro HPC
• Architettura: file system Lustre in Google Cloud utilizzando DDN EXAScaler

Scegli lo spazio di archiviazione appropriato

Google Cloud offre un'ampia gamma di opzioni di archiviazione per le VM di Compute Engine: dischi permanenti, unità a stato solido (SSD) locali, Filestore e Cloud Storage. Per suggerimenti di progettazione e best practice per ottimizzare le prestazioni di ciascuna di queste opzioni di archiviazione, consulta Ottimizzare le prestazioni dello spazio di archiviazione.

Google Kubernetes Engine

Questa sezione fornisce indicazioni per ottimizzare le prestazioni delle risorse Google Kubernetes Engine (GKE).

Scalabilità automatica delle risorse

Puoi ridimensionare automaticamente i pool di nodi in un cluster GKE in modo che corrispondano al carico attuale utilizzando la funzionalità di gestore della scalabilità automatica dei cluster. La scalabilità automatica consente alle app di continuare a offrire prestazioni prevedibili quando il carico aumenta. Il gestore della scalabilità automatica dei cluster ridimensiona automaticamente i pool di nodi in base alle richieste di risorse (anziché all'utilizzo effettivo delle risorse) dei pod in esecuzione sui nodi. L'uso della scalabilità automatica può avere un compromesso tra prestazioni e costi. Rivedi le best practice per configurare in modo efficiente la scalabilità automatica dei cluster.

Nota: con i cluster Autopilot, non devi preoccuparti del provisioning dei nodi o della gestione dei pool di nodi. Il provisioning e la scalabilità dei pool di nodi vengono eseguiti automaticamente in base ai requisiti dei tuoi carichi di lavoro.

Usa VM C2D

Puoi migliorare le prestazioni dei carichi di lavoro containerizzati ad alta intensità di calcolo utilizzando i tipi di macchine C2D. Puoi aggiungere nodi C2D ai tuoi cluster GKE scegliendo un tipo di macchina C2D nei pool di nodi.

Disabilita SMT

Il multi-threading simultaneo (SMT) può aumentare significativamente la velocità effettiva delle applicazioni per attività di computing generiche e per carichi di lavoro che richiedono un I/O elevato. Tuttavia, per i carichi di lavoro in cui entrambi i core virtuali sono vincolati al calcolo, la SMT può causare prestazioni incoerenti. Per ottenere prestazioni migliori e più prevedibili, puoi disabilitare SMT per i nodi GKE impostando il numero di vCPU per core su 1.

Utilizza GPU

Per carichi di lavoro ad alta intensità di calcolo, come il riconoscimento delle immagini e la transcodifica di video, puoi accelerare le prestazioni creando pool di nodi che utilizzano GPU. Per ulteriori informazioni, consulta la pagina Esecuzione di GPU.

Utilizza il bilanciamento del carico nativo del container

Il bilanciamento del carico nativo del container consente ai bilanciatori del carico di distribuire il traffico direttamente e in modo uniforme ai pod. Questo approccio offre migliori prestazioni di rete e visibilità sulla latenza di rete tra il bilanciatore del carico e i pod. Per via di questi vantaggi, il bilanciamento del carico nativo del container è la soluzione consigliata per il bilanciamento del carico tramite in entrata.

Definisci un criterio di posizionamento compatto

I carichi di lavoro batch ad alto accoppiamento richiedono una bassa latenza di rete tra i nodi nel pool di nodi GKE. Puoi eseguire il deployment di questi carichi di lavoro in pool di nodi a zona singola e assicurarti che i nodi siano fisicamente vicini l'uno all'altro definendo un criterio di posizionamento compatto. Per maggiori informazioni, consulta Definire un posizionamento compatto per i nodi GKE.

Servizi di computing serverless

Questa sezione fornisce indicazioni per aiutarti a ottimizzare le prestazioni dei servizi di computing serverless in Google Cloud: Cloud Run e Cloud Functions. Questi servizi forniscono funzionalità di scalabilità automatica, in cui l'infrastruttura sottostante gestisce la scalabilità. Utilizzando questi servizi serverless, puoi ridurre lo sforzo di scalabilità dei microservizi e delle funzioni e concentrarti sull'ottimizzazione delle prestazioni a livello di applicazione.

Per ulteriori informazioni, consulta la seguente documentazione:

• Ottimizzazione delle prestazioni per i servizi Cloud Run
• Ottimizzazione delle applicazioni Java per Cloud Run
• Ottimizzazione delle prestazioni in Cloud Functions

Passaggi successivi

Esamina le best practice per ottimizzare le prestazioni delle risorse di archiviazione, networking, database e analisi:

• Ottimizzare le prestazioni dello spazio di archiviazione.
• Ottimizzare le prestazioni del networking.
• Ottimizza le prestazioni del database.
• Ottimizzare il rendimento dell'analisi.

Ottimizza le prestazioni dello spazio di archiviazione

Questo documento nel framework dell'architettura Google Cloud fornisce suggerimenti per aiutarti a ottimizzare le prestazioni delle risorse di archiviazione in Google Cloud.

Cloud Storage

Questa sezione fornisce best practice per aiutarti a ottimizzare le prestazioni delle operazioni di Cloud Storage.

Valuta le prestazioni del bucket

Valuta le prestazioni dei bucket Cloud Storage utilizzando il comando gsutil perfdiag. Questo comando verifica le prestazioni del bucket specificato inviando una serie di richieste di lettura e scrittura con file di dimensioni diverse. Puoi ottimizzare il test in modo che corrisponda al pattern di utilizzo delle tue applicazioni. Utilizza il report diagnostico generato dal comando per impostare le aspettative di prestazioni e identificare i potenziali colli di bottiglia.

Memorizza nella cache gli oggetti a cui si accede di frequente

Per migliorare la latenza di lettura per gli oggetti a cui si accede di frequente e che sono accessibili pubblicamente, puoi configurare tali oggetti in modo che vengano memorizzati nella cache. Anche se la memorizzazione nella cache può migliorare le prestazioni, potrebbero essere pubblicati contenuti inattivi se una cache contiene la versione precedente di un oggetto.

Scalabilità efficiente delle richieste

Con l'aumento del tasso di richieste per un bucket, Cloud Storage aumenta automaticamente la capacità di I/O per il bucket distribuendo il carico delle richieste su più server. Per ottenere prestazioni ottimali durante la scalabilità delle richieste, segui le best practice per aumentare i tassi di richieste e distribuire il carico in modo uniforme.

Abilita multi-threading e multielaborazione

Quando utilizzi gsutil per caricare numerosi file di piccole dimensioni, puoi migliorare le prestazioni dell'operazione utilizzando l'opzione -m. Questa opzione fa sì che la richiesta di caricamento venga implementata come un'operazione in batch parallela (ovvero multi-thread e multielaborazione). Usa questa opzione solo quando esegui operazioni con una connessione di rete veloce. Per ulteriori informazioni, consulta la documentazione relativa all'opzione -m in Opzioni globali della riga di comando.

Carica file di grandi dimensioni come elementi compositi

Per caricare file di grandi dimensioni, puoi utilizzare una strategia chiamata caricamenti composti paralleli. Con questa strategia, il file di grandi dimensioni viene suddiviso in blocchi, che vengono caricati in parallelo e ricomposti nel cloud. I caricamenti composti paralleli possono essere più rapidi delle normali operazioni di caricamento quando la larghezza di banda della rete e la velocità del disco non sono fattori limitanti. Tuttavia, questa strategia presenta alcune limitazioni e implicazioni in termini di costi. Per ulteriori informazioni, consulta Caricamenti combinati paralleli.

Dischi permanenti e SSD locali

Questa sezione fornisce best practice per aiutarti a ottimizzare le prestazioni dei dischi permanenti e delle SSD locali collegati alle VM di Compute Engine.

Le prestazioni dei dischi permanenti e degli SSD locali dipendono dal tipo e dalle dimensioni del disco, dal tipo di macchina VM e dal numero di vCPU. Utilizza le seguenti linee guida per gestire le prestazioni dei dischi permanenti e degli SSD locali:

• Quando esegui il provisioning dell'archiviazione a blocchi per le tue VM, scegli i tipi di disco e le dimensioni del disco appropriati per il tuo carico di lavoro. Per ulteriori informazioni, consulta Configurare i dischi per soddisfare i requisiti delle prestazioni.
• Confronta le prestazioni dell'archiviazione a blocchi. Per ulteriori informazioni, consulta la seguente documentazione:
  • Benchmarking disco permanente permanenti
  • Benchmarking delle prestazioni degli SSD locali
• Ottimizza le prestazioni dei tuoi dischi permanenti e degli SSD locali. Per saperne di più, consulta la seguente documentazione:
  • Ottimizzazione disco permanente permanenti
  • Ottimizzazione delle prestazioni degli SSD locali

Filestore

Questa sezione fornisce best practice per aiutarti a ottimizzare le prestazioni delle istanze Filestore. Puoi utilizzare Filestore per eseguire il provisioning di file server di rete NFS (Network File System) completamente gestiti per le VM di Compute Engine e i cluster GKE.

• Quando esegui il provisioning di un'istanza Filestore, scegli un livello di servizio che soddisfi i requisiti di prestazioni e capacità del tuo carico di lavoro.
• Per le VM client che eseguono carichi di lavoro dipendenti dalla cache, utilizza un tipo di macchina che consenta di ottimizzare le prestazioni di rete dell'istanza Filestore. Per maggiori informazioni, consulta Tipo di macchina client consigliato.
• Per ottimizzare le prestazioni delle istanze Filestore per le VM client che eseguono Linux, Google consiglia impostazioni di montaggio NFS specifiche. Per maggiori informazioni, vedi Opzioni di montaggio del client Linux.
• Per ridurre al minimo la latenza di rete, esegui il provisioning delle istanze Filestore in regioni e zone vicine a dove prevedi di utilizzare le istanze.
• Monitora le prestazioni delle tue istanze Filestore e configura gli avvisi utilizzando Cloud Monitoring.

Passaggi successivi

Esamina le best practice per ottimizzare le prestazioni delle risorse di calcolo, networking, database e analisi:

• Ottimizza le prestazioni di computing.
• Ottimizzare le prestazioni del networking.
• Ottimizza le prestazioni del database.
• Ottimizzare il rendimento dell'analisi.

Ottimizza le prestazioni di networking e API

Questo documento nel framework dell'architettura Google Cloud fornisce suggerimenti per ottimizzare le prestazioni delle risorse di networking e delle API in Google Cloud.

Network Service Tiers

Network Service Tiers ti consente di ottimizzare i costi e le prestazioni di rete dei tuoi carichi di lavoro. Puoi scegliere tra i seguenti livelli:

• Il livello Premium utilizza la struttura backbone globale ad alta affidabilità di Google per aiutarti a ridurre al minimo la perdita di pacchetti e la latenza. Il traffico entra ed esce dalla rete Google in un punto di presenza (POP) perimetrale globale, vicino all'utente finale. Ti consigliamo di utilizzare il livello Premium come livello predefinito per ottenere prestazioni ottimali. Il livello Premium supporta indirizzi IP esterni sia a livello regionale che globale per VM e bilanciatori del carico.
• Il livello Standard è disponibile solo per le risorse che utilizzano indirizzi IP esterni a livello di regione. Il traffico entra ed esce dalla rete Google in corrispondenza del PoP perimetrale più vicino alla località Google Cloud in cui viene eseguito il tuo carico di lavoro. I prezzi del livello Standard sono inferiori rispetto al livello Premium. Il livello Standard è adatto per il traffico non sensibile alla perdita di pacchetti e che non ha requisiti di bassa latenza.

Puoi visualizzare la latenza di rete per il livello Standard e il livello Premium per ogni regione cloud nella dashboard sulle prestazioni di Network Intelligence Center.

Jumbo frame

Le reti Virtual Private Cloud (VPC) hanno un'unità di trasmissione massima (MTU) predefinita di 1460 byte. Tuttavia, puoi configurare le tue reti VPC in modo da supportare una MTU fino a 8896 (frame jumbo).

Con una MTU più elevata, la rete ha bisogno di meno pacchetti per inviare la stessa quantità di dati, riducendo così la larghezza di banda utilizzata dalle intestazioni TCP/IP. Ciò porta a una maggiore larghezza di banda effettiva per la rete.

Per ulteriori informazioni sulle MTU intra-VPC e sulla MTU massima delle altre connessioni, consulta la pagina Unità massima di trasmissione nella documentazione del VPC.

Prestazioni della VM

Le VM di Compute Engine hanno una larghezza di banda in uscita massima che in parte dipende dal tipo di macchina. Nella scelta del tipo di macchina appropriato, devi considerare quanto traffico ti aspetti che la VM generi.

La pagina Larghezza di banda della rete contiene una discussione e una tabella di larghezze di banda di rete per i tipi di macchine di Compute Engine.

Se i tuoi requisiti di larghezza di banda tra le VM sono molto elevati, prendi in considerazione le VM che supportano il networking di Tier_1.

Cloud Load Balancing

Questa sezione fornisce best practice per aiutarti a ottimizzare le prestazioni delle istanze di Cloud Load Balancing.

Esegui il deployment delle applicazioni nelle vicinanze degli utenti

Esegui il provisioning dei backend dell'applicazione vicini alla località in cui prevedi che il traffico degli utenti arrivi al bilanciatore del carico. Più gli utenti o le applicazioni client sono vicini ai server dei carichi di lavoro, minore è la latenza di rete tra gli utenti e il carico di lavoro. Per ridurre al minimo la latenza per i client in diverse parti del mondo, potrebbe essere necessario eseguire il deployment dei backend in più regioni. Per saperne di più, consulta Best practice per la selezione delle regioni di Compute Engine.

Scegli un tipo di bilanciatore del carico appropriato

Il tipo di bilanciatore del carico che scegli per la tua applicazione può determinare la latenza dell'esperienza utente. Per informazioni sulla misurazione e sull'ottimizzazione della latenza delle applicazioni per i diversi tipi di bilanciatori del carico, consulta Ottimizzazione della latenza delle applicazioni con il bilanciamento del carico.

Abilita memorizzazione nella cache

Per accelerare la pubblicazione di contenuti, abilita la memorizzazione nella cache e Cloud CDN come parte della configurazione predefinita del bilanciatore del carico HTTP esterno. Assicurati che i server di backend siano configurati per inviare le intestazioni della risposta necessarie per la memorizzazione nella cache delle risposte statiche.

Utilizza HTTP quando HTTPS non è necessario

Google cripta automaticamente il traffico tra backend e bilanciatori del carico proxy a livello di pacchetto. La crittografia a livello di pacchetto rende ridondante la crittografia di livello 7 tramite HTTPS tra il bilanciatore del carico e i backend nella maggior parte degli scopi. Prendi in considerazione l'utilizzo di HTTP anziché HTTPS o HTTP/2 per il traffico tra il bilanciatore del carico e i tuoi backend. Con HTTP, puoi anche ridurre l'utilizzo della CPU delle VM di backend. Tuttavia, quando il backend è un gruppo di endpoint della rete internet (NEG), utilizza HTTPS o HTTP/2 per il traffico tra il bilanciatore del carico e il backend. Ciò contribuisce a garantire che il traffico sia sicuro sulla rete internet pubblica. Per prestazioni ottimali, consigliamo di eseguire il benchmarking sui modelli di traffico della tua applicazione.

Network Intelligence Center

Il Network Intelligence Center di Google Cloud offre una visione completa delle prestazioni della rete Google Cloud in tutte le regioni. Network Intelligence Center ti aiuta a determinare se i problemi di latenza sono causati da problemi nel progetto o nella rete. Puoi utilizzare queste informazioni anche per selezionare le regioni e le zone in cui eseguire il deployment dei tuoi carichi di lavoro al fine di ottimizzare le prestazioni della rete.

Utilizza i seguenti strumenti forniti da Network Intelligence Center per monitorare e analizzare le prestazioni della rete per i carichi di lavoro in Google Cloud:

• La dashboard sulle prestazioni mostra la latenza tra le regioni Google Cloud e tra singole regioni e località su internet. Performance Dashboard può aiutarti a determinare dove posizionare i carichi di lavoro per la migliore latenza e a determinare quando un problema dell'applicazione potrebbe essere dovuto a problemi di rete sottostanti.

• Network Topology mostra una visualizzazione visiva delle reti Virtual Private Cloud (VPC), della connettività ibrida con le reti on-premise e della connettività ai servizi gestiti da Google. Network Topology fornisce metriche operative in tempo reale che puoi utilizzare per analizzare e comprendere le prestazioni della rete e identificare pattern di traffico insoliti.

• Network Analyzer è uno strumento di monitoraggio e diagnostica della configurazione automatica. Verifica le configurazioni di rete VPC per regole firewall, route, dipendenze di configurazione e connettività per servizi e applicazioni. Aiuta a identificare gli errori di rete e fornisce analisi delle cause principali e suggerimenti. Network Analyzer fornisce insight prioritari per aiutarti ad analizzare i problemi relativi alla configurazione di rete, come l'utilizzo elevato degli indirizzi IP in una subnet.

Gateway API e Apigee

Questa sezione fornisce suggerimenti per ottimizzare le prestazioni delle API di cui esegui il deployment in Google Cloud utilizzando Gateway API e Apigee.

API Gateway consente di creare e gestire le API per i backend serverless di Google Cloud, tra cui Cloud Functions, Cloud Run e App Engine. Questi servizi sono servizi gestiti e scalano automaticamente. Tuttavia, poiché le applicazioni di cui viene eseguito il deployment su questi servizi sono scalabili, potrebbe essere necessario aumentare le quote e i limiti di frequenza per API Gateway.

Nota: l'esposizione delle applicazioni o dell'infrastruttura a più traffico può causare colli di bottiglia delle prestazioni al livello successivo nello stack delle applicazioni.

Apigee offre le seguenti dashboard di analisi per aiutarti a monitorare le prestazioni delle API gestite:

• Dashboard prestazioni proxy API: monitora i modelli di traffico proxy API e i tempi di elaborazione.
• Target Performance Dashboard (Dashboard prestazioni di destinazione): visualizza i modelli di traffico e le metriche sulle prestazioni per i target di backend del proxy API.
• Dashboard delle prestazioni della cache: monitora le metriche sulle prestazioni della cache di Apigee, come la percentuale di hit media della cache e il tempo medio nella cache.

Se utilizzi l'integrazione Apigee, considera i limiti di configurazione del sistema quando crei e gestisci le tue integrazioni.

Passaggi successivi

Esamina le best practice per ottimizzare le prestazioni delle risorse di calcolo, archiviazione, database e analisi:

• Ottimizza le prestazioni di computing.
• Ottimizzare le prestazioni dello spazio di archiviazione.
• Ottimizza le prestazioni del database.
• Ottimizzare il rendimento dell'analisi.

Ottimizza le prestazioni del database

Questo documento nel framework dell'architettura Google Cloud fornisce suggerimenti per aiutarti a ottimizzare le prestazioni dei tuoi database in Google Cloud.

Cloud SQL

I seguenti suggerimenti ti aiutano a ottimizzare le prestazioni delle istanze Cloud SQL che eseguono database SQL Server, MySQL e PostgreSQL.

• Per i database SQL Server, Google consiglia di modificare determinati parametri e conservare i valori predefiniti per alcuni parametri.
• Quando scegli il tipo di archiviazione per i database MySQL o PostgreSQL, considera il scomparto in termini di costi e prestazioni tra archiviazione SSD e HDD.
• Per identificare e analizzare i problemi di prestazioni dei database PostgreSQL, utilizza la dashboard di Approfondimenti di Cloud SQL.
• Per diagnosticare le prestazioni scadenti durante l'esecuzione di query SQL, utilizza l'istruzione EXPLAIN.

Per ulteriori informazioni, consulta la seguente documentazione:

• Ottimizzazione delle prestazioni: SQL Server
• Ottimizzare il rendimento: MySQL
• Ottimizzare il rendimento: PostgreSQL

Bigtable

Questa sezione fornisce suggerimenti per ottimizzare le prestazioni delle istanze Bigtable.

Pianifica la capacità in base ai requisiti di prestazioni

Puoi utilizzare Bigtable in una vasta gamma di applicazioni, ognuna con un obiettivo di ottimizzazione diverso. Ad esempio, per i job di elaborazione dati in batch, la velocità effettiva potrebbe essere più importante della latenza. Per un servizio online che soddisfa le richieste degli utenti, potrebbe essere necessario dare priorità alla velocità effettiva inferiore a latenza inferiore. Quando pianifichi la capacità per i tuoi cluster Bigtable, considera i compromessi tra velocità effettiva e latenza. Per maggiori informazioni, consulta Pianificare la capacità di Bigtable.

Seguire le best practice per la progettazione dello schema

Le tabelle possono scalare fino a miliardi di righe e migliaia di colonne, consentendoti di archiviare petabyte di dati. Quando progetti lo schema per le tabelle Bigtable, prendi in considerazione le best practice per la progettazione dello schema.

Monitora il rendimento e apporta le modifiche necessarie

Monitora l'utilizzo di CPU e disco per le tue istanze, analizza le prestazioni di ogni cluster ed esamina i suggerimenti di dimensionamento mostrati nei grafici di monitoraggio.

Spanner

Questa sezione fornisce suggerimenti per ottimizzare le prestazioni delle istanze Spanner.

Scegli una chiave primaria che impedisca un hotspot

Un hotspot è un singolo server forzato a gestire molte richieste. Quando scegli la chiave primaria per il tuo database, segui le best practice per la progettazione dello schema per evitare un hotspot.

Segui le best practice per la programmazione SQL

Il compilatore SQL in Spanner converte ogni istruzione SQL dichiarativa che scrivi in un piano di esecuzione delle query imperativo. Spanner utilizza il piano di esecuzione per eseguire l'istruzione SQL. Quando crei istruzioni SQL, segui le best practice SQL per assicurarti che Spanner utilizzi piani di esecuzione che offrono prestazioni ottimali.

Utilizza le opzioni di query per gestire lo strumento di ottimizzazione delle query SQL

Spanner utilizza un ottimizzatore di query SQL per trasformare le istruzioni SQL in piani di esecuzione efficienti delle query. Il piano di esecuzione delle query prodotto dall'ottimizzatore potrebbe variare leggermente con l'evoluzione dello strumento di ottimizzazione delle query o quando le statistiche del database vengono aggiornate. Puoi ridurre al minimo il potenziale di regressione delle prestazioni quando lo strumento di ottimizzazione delle query o le statistiche del database cambiano utilizzando le opzioni di query.

Visualizza e ottimizza la struttura dei piani di esecuzione delle query

Per analizzare i problemi di prestazioni delle query, puoi visualizzare e ottimizzare la struttura dei piani di esecuzione delle query utilizzando il visualizzatore dei piani di query.

Utilizza le API Operations per gestire le operazioni a lunga esecuzione

Per determinate chiamate a metodi, Spanner crea operazioni a lunga esecuzione, il cui completamento potrebbe richiedere molto tempo. Ad esempio, quando ripristini un database, Spanner crea un'operazione a lunga esecuzione per monitorare l'avanzamento del ripristino. Per aiutarti a monitorare e gestire le operazioni a lunga esecuzione, Spanner fornisce le API operative. Per maggiori informazioni, consulta Gestione delle operazioni a lunga esecuzione.

Segui le best practice per il caricamento collettivo

Spanner supporta diverse opzioni per il caricamento collettivo di grandi quantità di dati. Le prestazioni di un'operazione di caricamento collettivo dipendono da fattori quali la partizionamento, il numero di richieste di scrittura e le dimensioni di ogni richiesta. Per caricare grandi quantità di dati in modo efficiente, segui le best practice per il caricamento collettivo.

Monitora e controlla l'utilizzo della CPU

L'utilizzo della CPU dell'istanza Spanner può influire sulle latenze delle richieste. Un server di backend sovraccarico può causare latenze di richieste più elevate. Spanner fornisce metriche di utilizzo della CPU per aiutarti a indagare sull'utilizzo elevato della CPU. Per le applicazioni sensibili alle prestazioni, potrebbe essere necessario ridurre l'utilizzo della CPU aumentando la capacità di calcolo.

Analizzare e risolvere i problemi di latenza

Quando un client effettua una chiamata di procedura remota a Spanner, la richiesta API viene prima preparata dalle librerie client. La richiesta passa quindi attraverso il frontend Google e il frontend dell'API Cloud Spanner prima di raggiungere il database Spanner. Per analizzare e risolvere i problemi di latenza, devi misurare e analizzare la latenza per ogni segmento del percorso attraversato dalla richiesta API. Per ulteriori informazioni, consulta la guida alla latenza end-to-end di Spanner.

Avvia le applicazioni dopo che il database ha raggiunto lo stato caldo

Man mano che il tuo database Spanner cresce, divide lo spazio delle chiavi dei dati in split. Ogni suddivisione è un intervallo di righe che contiene un sottoinsieme della tabella. Per bilanciare il carico complessivo sul database, Spanner sposta dinamicamente le singole sezioni in modo indipendente e le assegna a server diversi. Quando le divisioni vengono distribuite tra più server, il database viene considerato in stato caldo. Un database caldo può massimizzare il parallelismo e migliorare le prestazioni. Prima di avviare le applicazioni, ti consigliamo di riavviare il database con i caricamenti dei dati di test.

Passaggi successivi

Consulta le best practice per ottimizzare le prestazioni delle risorse di calcolo, archiviazione, networking e analisi:

• Ottimizza le prestazioni di computing.
• Ottimizzare le prestazioni dello spazio di archiviazione.
• Ottimizzare le prestazioni del networking.
• Ottimizzare il rendimento dell'analisi.

Ottimizza il rendimento dell'analisi

Questo documento nel framework dell'architettura Google Cloud fornisce suggerimenti per aiutarti a ottimizzare le prestazioni dei carichi di lavoro di analisi in Google Cloud.

BigQuery

Questa sezione fornisce suggerimenti per ottimizzare le prestazioni delle query in BigQuery.

Ottimizza la progettazione delle query

Le prestazioni delle query dipendono da fattori come il numero di byte lette e scritte da queste ultime e il volume di dati trasmessi tra gli slot. Per ottimizzare le prestazioni delle query in BigQuery, applica le best practice descritte nella seguente documentazione:

• Introduzione all'ottimizzazione delle prestazioni delle query
• Gestione dei dati di input e delle origini dati
• Ottimizzare la comunicazione tra gli slot
• Ottimizzare il calcolo delle query
• Gestire gli output delle query
• Evitare gli anti-pattern SQL

Definire e utilizzare le viste materializzate in modo efficiente

Per migliorare le prestazioni dei carichi di lavoro che utilizzano query comuni e ripetute, puoi utilizzare le viste materializzate. Esistono dei limiti al numero di viste materializzate che puoi creare. Non creare una vista materializzata distinta per ogni permutazione di una query. Definisci invece le viste materializzate da usare per più pattern di query.

Migliora il rendimento di JOIN

Puoi utilizzare le viste materializzate per ridurre i costi e la latenza di una query che esegue l'aggregazione su una JOIN. Considera un caso in cui unisci una tabella dei fatti di grandi dimensioni con alcune tabelle di dimensioni piccole e poi esegui un'aggregazione sopra il join. Potrebbe essere pratico riscrivere la query per eseguire prima l'aggregazione nella tabella dei fatti con chiavi esterne come chiavi di raggruppamento. Poi, unisci il risultato alle tabelle delle dimensioni. Infine, esegui una post-aggregazione.

Dataflow

Questa sezione fornisce suggerimenti per ottimizzare le prestazioni delle query delle pipeline di Dataflow.

Quando crei ed esegui il deployment di pipeline, puoi configurare i parametri di esecuzione, come il tipo di macchina Compute Engine da utilizzare per le VM worker Dataflow. Per ulteriori informazioni, consulta Opzioni della pipeline.

Dopo il deployment delle pipeline, Dataflow gestisce le risorse Compute Engine e Cloud Storage necessarie per eseguire i tuoi job. Inoltre, le seguenti funzionalità di Dataflow aiutano a ottimizzare le prestazioni delle pipeline:

• Parallelizzazione: Dataflow partiziona automaticamente i dati e distribuisce il codice worker alle istanze di Compute Engine per l'elaborazione parallela. Per maggiori informazioni, consulta Parallelizzazione e distribuzione.
• Ottimizzazione: Dataflow utilizza il codice della pipeline per creare un grafico di esecuzione che rappresenta gli oggetti PCollection e le transforms nella pipeline. Quindi ottimizza il grafico per ottenere prestazioni e utilizzo delle risorse più efficienti. Inoltre, Dataflow ottimizza automaticamente le operazioni potenzialmente costose, come le aggregazioni di dati. Per ulteriori informazioni, consulta Ottimizzazione della fusione e Combinare l'ottimizzazione.
• Ottimizzazione automatica: Dataflow ottimizza dinamicamente i job mentre sono in esecuzione utilizzando Scalabilità automatica orizzontale, Scalabilità automatica verticale e Ribilanciamento dinamico del lavoro.

Puoi monitorare le prestazioni delle pipeline Dataflow utilizzando l'interfaccia di monitoraggio basata sul web o l'interfaccia a riga di comando gcloud di Dataflow.

Nota: puoi anche utilizzare Cloud Profiler per identificare le parti del codice della pipeline che consumano più risorse. Per maggiori informazioni, consulta Monitoraggio delle prestazioni della pipeline.

Dataproc

Questa sezione descrive le best practice per ottimizzare le prestazioni dei cluster Dataproc.

Scalabilità automatica dei cluster

Per assicurarti che i tuoi cluster Dataproc offrano prestazioni prevedibili, puoi abilitare la scalabilità automatica. Dataproc utilizza le metriche di memoria Hadoop YARN e un criterio di scalabilità automatica da te definita per regolare automaticamente il numero di VM worker in un cluster. Per ulteriori informazioni su come utilizzare e configurare la scalabilità automatica, consulta Scalabilità automatica dei cluster.

Esegui il provisioning dello spazio di archiviazione appropriato

Scegli un'opzione di archiviazione appropriata per il tuo cluster Dataproc in base ai tuoi requisiti di prestazioni e costi:

• Se hai bisogno di un file system (HCFS) compatibile con Hadoop a basso costo da cui i job Hadoop e Spark possono leggere e scrivere con modifiche minime, utilizza Cloud Storage. I dati archiviati in Cloud Storage sono permanenti e sono accessibili da altri cluster Dataproc e altri prodotti come BigQuery.
• Se hai bisogno di un HDFS (Hadoop Distributed File System) a bassa latenza per il tuo cluster Dataproc, utilizza dischi permanenti di Compute Engine collegati ai nodi worker. I dati archiviati nell'archiviazione HDFS sono temporanei e il costo dell'archiviazione è superiore rispetto all'opzione Cloud Storage.
• Per sfruttare i vantaggi in termini di prestazioni dei dischi permanenti di Compute Engine e i vantaggi in termini di costi e durabilità di Cloud Storage, puoi combinare entrambe le opzioni di archiviazione. Ad esempio, puoi archiviare i set di dati di origine e finali in Cloud Storage ed eseguire il provisioning di una capacità HDFS limitata per i set di dati intermedi. Quando decidi le dimensioni e il tipo dei dischi per l'archiviazione HDFS, tieni conto dei suggerimenti contenuti nella sezione Dischi permanenti e SSD locali.

Ridurre la latenza quando si utilizza Cloud Storage

Per ridurre la latenza quando accedi ai dati archiviati in Cloud Storage, ti consigliamo di:

• Crea il bucket Cloud Storage nella stessa regione del cluster Dataproc.
• Disabilita auto.purge per le tabelle gestite da Apache Hive archiviate in Cloud Storage.
• Quando utilizzi Spark SQL, valuta la possibilità di creare cluster Dataproc con le versioni più recenti delle immagini disponibili. Utilizzando la versione più recente, puoi evitare problemi di prestazioni che potrebbero persistere nelle versioni precedenti, ad esempio prestazioni INSERT OVERWRITE lente in Spark 2.x.
• Per ridurre al minimo la possibilità di scrivere molti file di dimensioni diverse o piccole in Cloud Storage, puoi configurare i parametri SQL di Spark spark.sql.shuffle.partitions e spark.default.parallelism o il parametro di Hadoop mapreduce.job.reduces.

Monitora e regola il carico e la capacità dello spazio di archiviazione

I dischi permanenti collegati ai nodi worker in un cluster Dataproc contengono shuffling dei dati. Per garantire prestazioni ottimali, i nodi worker hanno bisogno di spazio su disco sufficiente. Se i nodi non hanno spazio su disco sufficiente, vengono contrassegnati come UNHEALTHY nel log YARN NodeManager. Se si verifica questo problema, aumenta la dimensione del disco per i nodi interessati o esegui meno job contemporaneamente.

Attiva EFM

Quando i nodi worker vengono rimossi da un cluster Dataproc in esecuzione, ad esempio a causa del downscaling o del prerilascio, i dati di shuffling potrebbero andare persi. Per ridurre al minimo i ritardi dei job in questi scenari, ti consigliamo di abilitare la modalità di flessibilità avanzata (EFM) per i cluster che utilizzano VM prerilasciabili o che scalano automaticamente solo il gruppo di worker secondario.

Passaggi successivi

Esamina le best practice per ottimizzare le prestazioni delle risorse di calcolo, archiviazione, networking e database:

• Ottimizza le prestazioni di computing.
• Ottimizzare le prestazioni dello spazio di archiviazione.
• Ottimizzare le prestazioni del networking.
• Ottimizza le prestazioni del database.

Novità nel framework dell'architettura

Questo documento elenca le modifiche significative al framework dell'architettura Google Cloud.

28 novembre 2023

• Categoria di affidabilità:
  • Abbiamo riorganizzato i contenuti per migliorare leggibilità e coerenza:
  • Definire gli SLO: è stata spostata la sezione "Terminologia" in una nuova pagina: Terminologia
  • Adotta gli SLO: la sezione "SLO e avvisi" è stata spostata in una nuova pagina: SLO e avvisi

9 novembre 2023

• Categoria di progettazione del sistema:
  • Sono state aggiunte indicazioni per aiutare i Cloud Architect a scegliere gli archetipi di deployment per i carichi di lavoro in Google Cloud.

8 settembre 2023

• Categoria di ottimizzazione dei costi:

  • Sono state aggiunte informazioni sull'utilizzo dei tag per l'allocazione dei costi e la governance.
  • Sono state aggiornate le indicazioni per identificare le anomalie di etichettatura.

  Per maggiori informazioni, consulta Monitorare e allocare i costi utilizzando tag o etichette.

28 agosto 2023

• Categoria di progettazione del sistema:
  • È stato aggiornato l'elenco dei servizi di IA e ML in Google Cloud.

23 agosto 2023

• Categoria di ottimizzazione dei costi:
  • Sono state aggiunte indicazioni sull'ottimizzazione dell'utilizzo delle risorse di Spanner per carichi di lavoro di dimensioni ridotte utilizzando le unità di elaborazione anziché i nodi.

18 agosto 2023

• Categoria Sicurezza, privacy e conformità:
  • Sono state aggiunte linee guida relative all'HIPAA.
• Categoria di eccellenza operativa:
  • Sono state aggiornate le best practice per la pianificazione degli eventi di picco di traffico.

9 agosto 2023

• Categoria di affidabilità:
  • Sono stati aggiunti link alla documentazione relativa all'affidabilità per i seguenti prodotti:
    • Dataproc
    • Bigtable
    • Cloud SQL
    • Spanner

13 luglio 2023

• Progettazione del sistema:
  • È stato aggiunto AlloyDB per PostgreSQL all'elenco dei servizi di database in Google Cloud.
• Ottimizzazione dei costi:
  • Sono state aggiunte indicazioni su Google Cloud Hyperdisk e sugli SSD locali nella sezione Persistent Disk.

23 giugno 2023

• Ottimizzazione delle prestazioni:
  • Sono state aggiunte indicazioni sull'ottimizzazione dell'utilizzo della larghezza di banda tramite jumbo frame e tipi di macchine appropriati per le VM.

15 giugno 2023

• Sicurezza, privacy e conformità:
  • Sono state aggiunte indicazioni su come proteggere le connessioni ad ambienti on-premise e multi-cloud utilizzando Cross-Cloud Interconnect.
  • Sono state aggiunte indicazioni sulla protezione del perimetro dei carichi di lavoro cloud tramite l'utilizzo di criteri e regole firewall e Secure Web Proxy.

30 marzo 2023

• Sono stati aggiunti due articoli aggiuntivi sullo SLO al framework:
  • Definire gli SLO
  • Adotta gli SLO

16 settembre 2022

• Importante espansione della categoria ottimizzazione del rendimento.

10 agosto 2022

• Modifiche nella categoria Design del sistema:
  • Sono stati aggiunti i principi fondamentali della progettazione del sistema.
  • Sono stati aggiunti consigli per utilizzare i servizi di consulenza di Google Cloud e interagire con i nostri partner.

4 agosto 2022

• Sono state aggiunte informazioni sulle seguenti funzionalità nella categoria ottimizzazione dei costi:

  • Evitare interruzioni dovute a problemi di fatturazione bloccando il collegamento tra un progetto e il relativo account di fatturazione. Per ulteriori informazioni, consulta Configurare il controllo dell'accesso alla fatturazione.

  • Ridurre la quota utilizzando l'API Service Usage. Per ulteriori informazioni, consulta Budget, avvisi e quote.

  • Identificare e rimuovere i progetti inattivi. Per ulteriori informazioni, consulta i consigli di Active Assist.

13 luglio 2022

• Modifiche nella categoria di eccellenza operativa:

  • È stata aggiunta una best practice su come creare un centro di eccellenza.
  • È stata aggiunta una best practice su come configurare un audit trail.

27 giugno 2022

• Sono state aggiunte informazioni sulle responsabilità condivise e sul destino condiviso in Google Cloud nella categoria Sicurezza.

13 giugno 2022

• Sono stati aggiunti suggerimenti per aiutarti a progettare carichi di lavoro cloud per la sostenibilità ambientale nella categoria progettazione del sistema.

1° giugno 2022

• Sono state aggiunte informazioni sulle VM spot nella sezione Ottimizzare i costi: computing, container e serverless.

7 maggio 2022

• Sono state aggiunte informazioni sulle località in due regioni nelle best practice per l'ottimizzazione dei costi per Cloud Storage.

4 maggio 2022

• Sono state aggiunte guide sull'affidabilità del prodotto. Queste guide includono best practice per l'affidabilità per i seguenti prodotti:

  • Computing: Compute Engine, Cloud Run, Cloud Functions e Google Kubernetes Engine

  • Archiviazione e database: Cloud Storage, Firestore

  • Networking: Cloud DNS e Cloud Load Balancing

  • Analisi dei dati: BigQuery

25 febbraio 2022

• Modifiche alla categoria di sicurezza:

  • Sono state aggiornate le best practice per la conformità per discutere dell'automazione.

15 dicembre 2021

• Lancio dello spazio Framework dell'architettura nella community Google Cloud.

25 ottobre 2021

• Modifiche nella categoria affidabilità:

  • Sono state aggiunte best practice per replicare i dati in più regioni per il ripristino di emergenza e progettare un'architettura multiregionale per la resilienza alle interruzioni a livello di regione.
  • È stato aggiunto un esempio di come calcolare i budget di errore.
  • È stata aggiunta una best practice per la scelta dei nomi corretti per applicazioni e servizi.

7 ottobre 2021

• Importante aggiornamento di tutte le categorie.

---

1. Anna Berenberg e Brad Calder, Deployment Archetypes for Cloud Applications, ACM Computing Surveys, volume 55, numero 3, n. articolo: 61, pp. 1-48 ↩