Questa sezione della guida agli archetipi di deployment di Google Cloud confronta gli archetipi di deployment in termini di disponibilità, robustezza contro le interruzioni del servizio, 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 parte di Google Cloud della topologia influisce sulla disponibilità, sulla robustezza contro le interruzioni, sui costi e sulla complessità operativa.
| Considerazione sul design | A livello di zona | Regionale | A più regioni | Globale |
|---|---|---|---|---|
| Disponibilità dell'infrastruttura | 99,9% (tre nove) | 99,99% (4 nove) | 99,999% (5 nove) | 99,999% (5 nove) |
| Robustezza dell'infrastruttura contro le interruzioni nelle zone | RTO di ore o giorni | RTO quasi nullo se la replica è sincrona | RTO quasi nullo se la replica è sincrona | RTO quasi nullo se la replica è sincrona |
| Robustezza dell'infrastruttura contro le interruzioni regionali | RTO di ore o giorni | RTO di ore o giorni | RTO quasi nullo se la replica è sincrona | RTO quasi nullo se la replica è sincrona |
| Costo delle risorse Google Cloud | Bassa | Media | Alta | Medio |
| Complessità operativa | Più semplice rispetto agli altri archetipi di deployment | Più complessa di quella zonale | Più complessa di quella regionale | Potenzialmente più semplice di quello multiregionale |
Le sezioni che seguono 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 implementazione.
Archetipi di deployment zonali, regionali, multiregionali e globali
L'infrastruttura Google Cloud è progettata per supportare una disponibilità target del 99,9% per il tuo carico di lavoro 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 delle applicazioni
- Uptime Accordi sul livello del servizio (SLA) per i servizi Google Cloud utilizzati
- Quantità di risorse ridondanti
- Ampiezze di località delle risorse
Per ulteriori informazioni, consulta Componenti 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 di Google Cloud e i componenti esterni a Google Cloud, la disponibilità complessiva è inferiore alla disponibilità del componente che offre la minore disponibilità in tutti gli ambienti.
- Se ogni componente dell'applicazione viene implementato in modo ridondante su Google Cloud e on-premise o su altre piattaforme cloud, la ridondanza garantisce un'alta disponibilità.
Resistenza dell'infrastruttura alle interruzioni di zone e regioni
Le sezioni che seguono 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 della zona e della regione Google Cloud.
Archetipo di deployment zonale
Un'architettura che utilizza l'archetipo di implementazione di base a zona singola non è sufficientemente robusta contro le interruzioni della zona. Devi pianificare il recupero dalle interruzioni delle zone in base al tuo RPO (Recovery Point Objective) e al tuo RTO (Recovery Time Objective). Ad esempio, puoi mantenere una replica passiva o ridotta dell'infrastruttura in un'altra zona (di failover). Se si verifica un'interruzione nella zona principale, puoi promuovere il database nella zona di failover come database principale e aggiornare il bilanciatore del carico in modo che invii il traffico al frontend nella zona di failover.
Archetipo di deployment regionale
Un'architettura che utilizza l'archetipo di deployment regionale è solida contro le interruzioni delle zone. È improbabile che un errore in una zona influisca sull'infrastruttura in altre zone. Il RTO è quasi nullo se i dati vengono replicati in modo sincrono. Tuttavia, quando un'interruzione interessa un'intera regione Google Cloud, l'applicazione diventa non disponibile. Pianifica il recupero 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 multiregionali e globali
Un'architettura che utilizza l'archetipo di deployment multiregionale o globale è robusta contro le interruzioni a livello di zona e regione. Il RTO è vicino allo zero se i dati vengono replicati in modo sincrono. Un'architettura in cui l'applicazione viene eseguita come uno stack location-unware distribuito a livello globale offre il massimo livello di affidabilità contro le interruzioni delle regioni.
Archetipi di deployment ibridi e multi-cloud
La robustezza di un'architettura ibrida e multi-cloud dipende dalla robustezza di ciascun 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 sia in un altro ambiente (on-premise o un'altra piattaforma cloud), l'applicazione è solida contro qualsiasi interruzione di Google Cloud. Se esistono interdipendenze critiche tra i componenti di Google Cloud e i componenti di cui è stato eseguito il deployment on-premise o su altre piattaforme cloud, la robustezza contro le interruzioni di Google Cloud dipende dalla robustezza dell'archetipo di deployment utilizzato per la parte di Google Cloud dell'architettura.
Costo delle risorse Google Cloud
Il costo delle risorse Google Cloud necessarie per un'applicazione dipende dai servizi Google Cloud che utilizzi, dal numero di risorse di cui esegui il provisioning, dal periodo per cui conservi o utilizzi le risorse e dall'archetipo di deployment che scegli. Per stimare il costo delle risorse Google Cloud in un'architettura basata su qualsiasi archetipo di deployment, puoi utilizzare il Calcolatore prezzi di Google Cloud.
Le seguenti sezioni descrivono le differenze nel costo delle risorse Google Cloud tra i vari archetipi di deployment.
Archetipi di deployment a livello di zona, regionale 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 regionali, devi considerare i costi di trasferimento dei dati tra regioni.
Archetipo di deployment globale
Con questo archetipo, hai la possibilità di utilizzare risorse globali di 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 multi-regionale in cui esegui il provisioning e la configurazione di più istanze di risorse regionali. Tuttavia, in alcuni casi le risorse globali potrebbero comportare costi più elevati. Ad esempio, il bilanciatore del carico globale richiede la rete Premium Tier, ma per i bilanciatori del carico regionali puoi scegliere Standard Tier.
Archetipi di deployment ibridi e multi-cloud
In un'architettura di implementazione ibrida o multicloud, devi prendere in considerazione i costi aggiuntivi oltre al costo delle risorse di cui esegui il provisioning. Ad esempio, prendi in considerazione i costi come la rete ibrida o cross-cloud e il costo del monitoraggio e della gestione delle risorse in più ambienti.
Considerazioni per tutti gli archetipi di deployment
Quando valuti il costo di esecuzione di un workload cloud, devi prendere in considerazione i costi aggiuntivi oltre al costo delle risorse Google Cloud che esegui il provisioning. Ad esempio, tieni conto delle spese per il personale e dei costi generali per progettare, creare e gestire il tuo deployment sul cloud.
Per confrontare il costo delle risorse Google Cloud negli archetipi di deployment, tieni conto anche del costo per unità di lavoro eseguita dall'applicazione. Identifica le unità di lavoro che riflettono i fattori determinanti dell'attività dell'applicazione, ad esempio il numero di utenti serviti dall'applicazione o il numero di richieste elaborate.
Gestisci attentamente l'utilizzo delle risorse Google Cloud e adotta le best practice consigliate da Google per ottimizzare i costi dei deployment cloud. Per ulteriori informazioni, consulta Framework dell'architettura Google Cloud: ottimizzazione dei costi.
Complessità operativa
Le sezioni seguenti descrivono le differenze di complessità operativa tra gli archetipi di deployment, che dipendono dal numero di risorse di infrastruttura, funzionalità e stack di applicazioni che devi gestire.
Archetipi di deployment a livello di zona, regionale e multiregionale
Un'architettura basata sull'archetipo di implementazione zonale è più facile da configurare e utilizzare rispetto alle altre architetture di implementazione. Un'applicazione che viene eseguita in modo ridondante in più zone o regioni richiede un impegno operativo maggiore per i seguenti motivi:
- È necessario monitorare lo stato degli stack di applicazioni in più sedi, sia a livello di stack sia per ogni componente dell'applicazione.
- Se un componente non è più disponibile in nessuna località, le richieste in corso devono essere gestite in modo corretto.
- Le modifiche alle applicazioni devono essere implementate con attenzione.
- I database devono essere sincronizzati in tutte le sedi.
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. Lo sforzo necessario per configurare e gestire le risorse cloud può essere inferiore a quello di un deployment multiregionale in cui è necessario gestire più istanze di risorse regionali. Tuttavia, devi gestire attentamente le modifiche alle risorse globali.
Lo sforzo per gestire un'architettura che utilizza l'archetipo di deployment globale dipende anche dal fatto che tu esegui il deployment di uno stack distribuito non consapevole della posizione o di più stack isolati a livello di regione:
- Un'applicazione distribuita e non consapevole della 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 implementare questi componenti nelle località richieste e utilizzare il resto dello stack in altre località.
- Un'applicazione di cui è stato eseguito il deployment come più stack isolati a livello di regione richiede un maggiore impegno per il funzionamento e la manutenzione, a causa dei seguenti fattori:
- È necessario monitorare lo stato degli stack di applicazioni in più località, sia a livello di stack sia per ogni componente.
- Se un componente diventa non disponibile in qualsiasi località, le richieste in elaborazione devono essere gestite in modo corretto.
- Le modifiche alle applicazioni devono essere implementate con attenzione.
- I database devono essere sincronizzati in tutte le sedi.
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. Per gestire le applicazioni ibride containerizzate, puoi utilizzare soluzioni come GKE Enterprise, che è un modello operativo cloud unificato per il provisioning, l'aggiornamento e l'ottimizzazione di cluster Kubernetes in più località.
- 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 lo sforzo di provisioning.
- Le funzionalità e gli strumenti di sicurezza non sono standard nelle diverse piattaforme cloud. Gli amministratori della sicurezza devono acquisire competenze e conoscenze per gestire la sicurezza delle risorse distribuite su tutte le piattaforme cloud che utilizzi.