Questa sezione della guida sugli archetipi di deploymentGoogle Cloud confronta gli archetipi di deployment in termini di disponibilità, robustezza contro le interruzioni, costi e complessità operativa.
La seguente tabella riassume l'analisi comparativa per gli archetipi di deployment di base: zonale, regionale, multiregionale e globale. Per le topologie ibride e multicloud, l'archetipo di deployment utilizzato per la parteGoogle Cloud della topologia influisce su disponibilità, robustezza contro le interruzioni, costi e complessità operativa.
| Considerazione sulla progettazione | A livello di zona | Regionale | A più regioni | Globale |
|---|---|---|---|---|
| Disponibilità dell'infrastruttura | 99,9% (tre nove) | 99,99% (quattro nove) | 99,999% (cinque 9) | 99,999% (cinque 9) |
| Robustezza dell'infrastruttura contro le interruzioni di zona | RTO di ore o giorni | RTO quasi pari a zero se la replica è sincrona | RTO quasi pari a zero se la replica è sincrona | RTO quasi pari a zero se la replica è sincrona |
| Robustezza dell'infrastruttura contro le interruzioni regionali | RTO di ore o giorni | RTO di ore o giorni | RTO quasi pari a zero se la replica è sincrona | RTO quasi pari a zero se la replica è sincrona |
| Costo delle Google Cloud risorse | Bassa | Media | Alta | Media |
| Complessità operativa | Più semplice rispetto agli altri archetipi di deployment | Più complesso di quello zonale | Più complesso di quello regionale | Potenzialmente più semplice della configurazione multiregionale |
Le sezioni seguenti descrivono l'analisi comparativa riassunta nella tabella precedente.
Disponibilità dell'infrastruttura
Le seguenti sezioni descrivono le differenze nella disponibilità dell'infrastruttura tra gli archetipi di deployment.
Archetipi di deployment zonali, regionali, multiregionali e globali
L'infrastrutturaGoogle Cloud è progettata per supportare una disponibilità target del 99,9% per il tuo workload quando utilizzi l'archetipo di deployment zonale, del 99,99% per i deployment regionali e del 99,999% per i deployment multiregionali e globali. Questi numeri di disponibilità sono target per l'infrastruttura a livello di piattaforma.
La disponibilità che puoi aspettarti da un'applicazione di cui è stato eseguito il deployment in Google Cloud dipende dai seguenti fattori, oltre all'archetipo di deployment:
- Progettazione dell'applicazione
- Numero di livelli interdipendenti nello stack dell'applicazione
- Tempo di attività Accordi sul livello del servizio (SLA) per i Google Cloud servizi utilizzati
- Quantità di risorse ridondanti
- Ambiti geografici delle risorse
Per ulteriori informazioni, consulta Elementi costitutivi dell'affidabilità in Google Cloud.
Archetipi di deployment ibridi e multi-cloud
Per una topologia ibrida o multi-cloud, la disponibilità complessiva dipende dall'infrastruttura in ogni ambiente e dalle interdipendenze tra gli ambienti.
- Se esistono interdipendenze critiche tra i componenti in Google Cloud e i componenti esterni a Google Cloud, la disponibilità complessiva è inferiore alla disponibilità del componente che offre la disponibilità minima in tutti gli ambienti.
- Se ogni componente dell'applicazione viene implementato in modo ridondante inGoogle Cloud e on-premise o in altre piattaforme cloud, la ridondanza garantisce un'elevata disponibilità.
Robustezza dell'infrastruttura contro le interruzioni di zona e regione
Le sezioni seguenti descrivono le differenze tra gli archetipi di deployment in termini di capacità dell'infrastruttura di continuare a supportare i tuoi carichi di lavoro in caso di interruzioni di zona e regione. Google Cloud
Archetipo di deployment a livello di zona
Un'architettura che utilizza l'archetipo di deployment di base a zona singola non è robusta contro le interruzioni di zona. Devi pianificare il recupero dalle interruzioni di zona in base al Recovery Point Objective (RPO) e al Recovery Time Objective (RTO). Ad esempio, puoi mantenere una replica passiva o ridimensionata dell'infrastruttura in un'altra zona (di failover). Se si verifica un'interruzione nella zona principale, puoi promuovere il database nella zona di failover a database principale e aggiornare il bilanciatore del carico per inviare traffico al frontend nella zona di failover.
Archetipo di deployment regionale
Un'architettura che utilizza l'archetipo di deployment regionale è solida contro le interruzioni di zona. È improbabile che un errore in una zona influisca sull'infrastruttura di altre zone. L'RTO è quasi pari a zero se i dati vengono replicati in modo sincrono. Tuttavia, quando un'interruzione interessa un'intera regione Google Cloud , l'applicazione non è più disponibile. Pianifica il ripristino dalle interruzioni in base a RPO e RTO per l'applicazione. Ad esempio, puoi eseguire il provisioning di una replica passiva dell'infrastruttura in una regione diversa e attivarla durante le interruzioni della regione.
Archetipi di deployment globali e multiregionali
Un'architettura che utilizza l'archetipo di deployment multiregionale o globale è robusta contro le interruzioni di zone e regioni. L'RTO è quasi pari a zero se i dati vengono replicati in modo sincrono. Un'architettura in cui l'applicazione viene eseguita come stack distribuito a livello globale e indipendente dalla località offre il massimo livello di robustezza contro le interruzioni a livello di regione.
Archetipi di deployment ibridi e multi-cloud
La solidità di un'architettura ibrida e multicloud dipende dalla solidità di ogni ambiente (Google Cloud, on-premise e altre piattaforme cloud) e dalle interdipendenze tra gli ambienti.
Ad esempio, se ogni componente di un'applicazione viene eseguito in modo ridondante sia su Google Cloud che in un altro ambiente (on-premise o un'altra piattaforma cloud), l'applicazione è resiliente a qualsiasi interruzione diGoogle Cloud . Se esistono interdipendenze critiche tra i componenti in Google Cloud e i componenti di cui è stato eseguito il deployment on-premise o su altre piattaforme cloud, la robustezza contro le interruzioni Google Cloud dipende dalla robustezza dell'archetipo di deployment che utilizzi per la parteGoogle Cloud dell'architettura.
Costo delle Google Cloud risorse
Il costo delle risorse Google Cloud necessarie per un'applicazione dipende dai servizi Google Cloud che utilizzi, dal numero di risorse che esegui il provisioning, dal periodo di conservazione o utilizzo delle risorse e dall'archetipo di deployment che scegli. Per stimare il costo delle risorseGoogle Cloud in un'architettura basata su qualsiasi archetipo di deployment, puoi utilizzare il Google Cloud Calcolatore prezzi.
Le seguenti sezioni descrivono le differenze di costo delle risorseGoogle Cloud tra i vari archetipi di deployment.
Archetipi di deployment a livello di zona, di regione e multiregionale
Rispetto a un'architettura che utilizza l'archetipo di deployment zonale, un'architettura che utilizza l'archetipo di deployment multiregionale potrebbe comportare costi aggiuntivi per lo spazio di archiviazione ridondante. Inoltre, per qualsiasi traffico di rete che attraversa i confini delle regioni, devi considerare i costi di trasferimento dei dati tra regioni.
Archetipo di deployment globale
Con questo archetipo, hai l'opportunità di utilizzare risorse globali ad alta disponibilità, come un bilanciatore del carico globale. Il costo di configurazione e gestione delle risorse cloud può essere inferiore a quello di un deployment multiregionale in cui esegui il provisioning e la configurazione di più istanze di risorse regionali. Tuttavia, le risorse globali potrebbero comportare costi più elevati in alcuni casi. Ad esempio, il bilanciatore del carico globale richiede il networking di livello Premium, ma per i bilanciatori del carico regionali puoi scegliere il livello Standard.
Archetipi di deployment ibridi e multi-cloud
In un'architettura di deployment ibrida o multicloud, devi considerare i costi aggiuntivi insieme al costo delle risorse di cui esegui il provisioning. Ad esempio, considera i costi di networking ibrido o cross-cloud e il costo di monitoraggio e gestione delle risorse in più ambienti.
Considerazioni per tutti gli archetipi di deployment
Quando valuti il costo di esecuzione di un workload cloud, devi considerare i costi aggiuntivi insieme al costo delle risorse di cui esegui il provisioning. Google Cloud Ad esempio, considera le spese per il personale e i costi generali per progettare, creare e gestire il deployment cloud.
Per confrontare il costo delle risorse Google Cloud nei vari archetipi di deployment, considera anche il costo per unità di lavoro eseguita dall'applicazione. Identifica le unità di lavoro che riflettono i fattori aziendali dell'applicazione, ad esempio il numero di utenti a cui l'applicazione fornisce servizi o il numero di richieste elaborate.
Gestendo attentamente l'utilizzo delle risorse Google Cloud e adottando le best practice consigliate da Google, puoi ottimizzare il costo dei tuoi deployment cloud. Per ulteriori informazioni, consulta Google Cloud Well-Architected Framework: ottimizzazione dei costi.
Complessità operativa
Le sezioni seguenti descrivono le differenze di complessità operativa tra gli archetipi di deployment, che dipende dal numero di risorse dell'infrastruttura, funzionalità e stack di applicazioni che devi gestire.
Archetipi di deployment a livello di zona, di regione e multiregionale
Un'architettura basata sull'archetipo di deployment zonale è più facile da configurare e gestire rispetto alle altre architetture di deployment. Un'applicazione che viene eseguita in modo ridondante in più zone o regioni richiede un maggiore sforzo operativo per i seguenti motivi:
- Lo stato degli stack di applicazioni in più posizioni deve essere monitorato sia a livello di stack sia per ogni componente dell'applicazione.
- Se un componente non è più disponibile in una località, le richieste in corso devono essere gestite in modo controllato.
- Le modifiche all'applicazione devono essere implementate con attenzione.
- I database devono essere sincronizzati in tutte le posizioni.
Archetipo di deployment globale
L'archetipo di deployment globale ti consente di utilizzare risorse globali ad alta disponibilità come un bilanciatore del carico globale e un database globale. L'impegno per configurare e gestire le risorse cloud può essere inferiore rispetto a un deployment multiregionale in cui devi gestire più istanze di risorse regionali. Tuttavia, devi gestire con attenzione le modifiche alle risorse globali.
L'impegno per gestire un'architettura che utilizza l'archetipo di deployment globale dipende anche dal fatto che tu esegua il deployment di uno stack distribuito senza distinzione di località o di più stack isolati a livello regionale:
- Un'applicazione distribuita e indipendente dalla posizione può essere espansa e scalata con maggiore flessibilità. Ad esempio, se determinati componenti hanno requisiti di latenza critici per gli utenti finali solo in località specifiche, puoi eseguire il deployment di questi componenti nelle località richieste e utilizzare il resto dello stack in altre località.
- Un'applicazione di cui viene eseguito il deployment come più stack isolati a livello regionale richiede un maggiore impegno per il funzionamento e la manutenzione, a causa dei seguenti fattori:
- Lo stato degli stack di applicazioni in più posizioni deve essere monitorato, sia a livello di stack che per ogni componente.
- Se un componente non è più disponibile in una località, le richieste in corso devono essere gestite in modo controllato.
- Le modifiche all'applicazione devono essere implementate con attenzione.
- I database devono essere sincronizzati in tutte le posizioni.
Archetipi di deployment ibridi e multi-cloud
Le topologie ibride o multi-cloud richiedono più impegno per la configurazione e il funzionamento rispetto a un'architettura che utilizza solo Google Cloud.
- Le risorse devono essere gestite in modo coerente nelle topologie on-premise e Google Cloud .
- Hai bisogno di un modo per eseguire il provisioning e gestire in modo efficiente le risorse su più piattaforme. Strumenti come Terraform possono contribuire a ridurre l'impegno di provisioning.
- Le funzionalità e gli strumenti di sicurezza non sono standard nelle piattaforme cloud. I tuoi amministratori della sicurezza devono acquisire competenze ed esperienza per gestire la sicurezza delle risorse distribuite su tutte le piattaforme cloud che utilizzi.