Questa sezione della guida sugli archetipi di deployment di Google Cloud confronta gli archetipi di deployment in termini di disponibilità, robustezza rispetto alle interruzioni, costi e complessità operativa.
La seguente tabella riassume l'analisi comparativa per gli archetipi di deployment di base: a livello di zona, a livello di regione, multiregionale e globale. Per le topologie ibride e multi-cloud, l'archetipo di deployment utilizzato per la parte della topologia Google Cloud influenza la disponibilità, la robustezza in caso di interruzioni, i costi e la complessità operativa.
| Progetta la considerazione | Zonale | Regionale | Multiregionale | Globale |
|---|---|---|---|---|
| Disponibilità dell'infrastruttura | 99,9% (3 nove) | 99,99% (4 nove) | 99,999% (5 nove) | 99,999% (5 nove) |
| Robustezza dell'infrastruttura contro le interruzioni delle zone | RTO di ore o giorni | RTO vicino allo zero se la replica è sincrona | RTO vicino allo zero se la replica è sincrona | RTO vicino allo zero se la replica è sincrona |
| Robustezza dell'infrastruttura contro le interruzioni della regione | RTO di ore o giorni | RTO di ore o giorni | RTO vicino allo zero se la replica è sincrona | RTO vicino allo zero se la replica è sincrona |
| Costo delle risorse Google Cloud | Bassa | Media | Alta | Media |
| Complessità operativa | Più semplice degli altri archetipi di deployment | Più complessa di quella a livello di zona | Più complessa rispetto a quella regionale | Potenzialmente più semplice rispetto a più regioni |
Le seguenti sezioni 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 a livello di zona, di una regione, di più regioni e globali
L'infrastruttura Google Cloud è progettata per supportare una disponibilità target del 99,9% per il carico di lavoro quando utilizzi l'archetipo di deployment a livello di zona, del 99,99% per i deployment regionali e del 99,999% per i deployment globali e in più regioni. Questi valori sulla disponibilità sono i target per l'infrastruttura a livello di piattaforma.
La disponibilità prevista 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 di applicazioni
- Accordo sul livello del servizio (SLA) di uptime per i servizi Google Cloud utilizzati
- Quantità di risorse ridondanti
- Ambiti di località delle risorse
Per ulteriori informazioni, consulta Componenti di base per l'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 ciascun 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 fornisce la disponibilità minima in tutti gli ambienti.
- Se il deployment di ogni componente dell'applicazione viene eseguito in modo ridondante su Google Cloud e on-premise o in altre piattaforme cloud, la ridondanza garantisce l'alta disponibilità.
Solidità dell'infrastruttura in caso di interruzioni di zone e regioni
Le seguenti sezioni descrivono le differenze tra gli archetipi di deployment in termini di capacità dell'infrastruttura di continuare a supportare i carichi di lavoro in caso di interruzioni della zona e della regione Google Cloud.
Archetipo di deployment a livello di zona
Un'architettura che utilizza l'archetipo di deployment a zona singola di base non è solida contro le interruzioni di zona. Devi pianificare il ripristino in seguito alle interruzioni di zona in base all'RPO (Recovery Point Objective) e al Recovery Time Objective (RTO). Ad esempio, puoi mantenere una replica passiva o scale down dell'infrastruttura in un'altra zona (failover). Se si verifica un'interruzione nella zona principale, puoi promuovere il database nella zona di failover in modo che diventi il database principale e aggiornare il bilanciatore del carico in modo che invii il traffico al frontend nella zona di failover.
Archetipo di deployment a livello di regione
Un'architettura che utilizza l'archetipo di deployment a livello di regione è solida contro le interruzioni di zona. È improbabile che un guasto in una zona influisca sull'infrastruttura in altre zone. L'RTO è vicino allo zero 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 ripristino dalle interruzioni in base all'RPO e all'RTO dell'applicazione. Ad esempio, puoi eseguire il provisioning di una replica passiva dell'infrastruttura in una regione diversa e attivare la replica durante le interruzioni della regione.
Archetipi di deployment multiregionali e globali
Un'architettura che utilizza l'archetipo di deployment multiregionale o globale è solida in caso di interruzioni di zone e regioni. L'RTO è vicino allo zero se i dati vengono replicati in modo sincrono. Un'architettura in cui l'applicazione viene eseguita come uno stack distribuito a livello globale e non sensibile alla località fornisce il massimo livello di solidità in caso di interruzioni della regione.
Archetipi di deployment ibridi e multi-cloud
La solidità 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 che su un altro ambiente (on-premise o un'altra piattaforma cloud), l'applicazione è solida contro qualsiasi interruzione del servizio Google 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 solidità contro le interruzioni di Google Cloud dipende dalla solidità dell'archetipo di deployment che viene utilizzato per la parte dell'architettura di Google Cloud.
Costo delle risorse Google Cloud
Il costo delle risorse Google Cloud necessarie per un'applicazione dipende dai servizi Google Cloud utilizzati, 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, di una o più regioni
Rispetto a un'architettura che utilizza l'archetipo di deployment a livello di zona, un'architettura che utilizza questo archetipo di deployment su più regioni potrebbe comportare costi aggiuntivi per l'archiviazione ridondante. Inoltre, per tutto il traffico di rete che attraversa i confini regionali, devi considerare i costi del trasferimento di 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 rispetto a un deployment multiregionale in cui esegui il provisioning e la configurazione di più istanze di risorse a livello di regione. Tuttavia, le risorse globali potrebbero comportare costi più elevati in alcuni casi. Ad esempio, il bilanciatore del carico globale richiede il networking del livello Premium, ma per i bilanciatori del carico a livello di regione puoi scegliere il livello Standard.
Archetipi di deployment ibridi e multi-cloud
In un'architettura di deployment ibrida o multi-cloud, devi considerare costi aggiuntivi oltre al costo delle risorse di cui esegui il provisioning. Ad esempio, considera costi come il networking ibrido o cross-cloud e il costo del monitoraggio e della gestione delle risorse in più ambienti.
Considerazioni su tutti gli archetipi di deployment
Quando valuti il costo dell'esecuzione di un carico di lavoro cloud, devi considerare costi aggiuntivi oltre al costo delle risorse Google Cloud di cui esegui il provisioning. Ad esempio, considera le spese del personale e i costi generali per la progettazione, la creazione e la gestione del deployment cloud.
Per confrontare il costo delle risorse Google Cloud tra gli archetipi di deployment, considera anche il costo per unità di lavoro eseguita dall'applicazione. Identifica le unità di lavoro che riflettono i driver aziendali dell'applicazione, come il numero di utenti serviti dall'applicazione o il numero di richieste elaborate.
Una gestione attenta dell'utilizzo delle tue risorse Google Cloud e l'adozione delle best practice consigliate da Google ti consentono di ottimizzare il costo dei deployment cloud. Per ulteriori informazioni, consulta Framework dell'architettura Google Cloud: ottimizzazione dei costi.
Complessità operativa
Le seguenti sezioni descrivono le differenze in termini di complessità operativa tra gli archetipi di deployment, che dipendono dal numero di risorse, funzionalità e stack di applicazioni dell'infrastruttura che devono essere gestite.
Archetipi di deployment a livello di zona, di una o più regioni
Un'architettura basata sull'archetipo di deployment a livello di zona è più facile da configurare e utilizzare rispetto alle altre architetture di deployment. Un'applicazione eseguita in modo ridondante in più zone o regioni richiede un impegno operativo maggiore, per i seguenti motivi:
- Lo stato degli stack di applicazioni in più località deve essere monitorato, sia a livello di stack che per ciascun componente dell'applicazione.
- Se un componente diventa non disponibile in qualsiasi località, le richieste in-process devono essere gestite in modo controllato.
- Le modifiche all'applicazione devono essere implementate con attenzione.
- I database devono essere sincronizzati tra tutte le località.
Archetipo di deployment globale
L'archetipo di deployment globale consente di utilizzare risorse globali a disponibilità elevata, come un bilanciatore del carico globale e un database globale. L'impegno per la configurazione e l'utilizzo delle risorse cloud può essere inferiore a quello di un deployment su più regioni in cui è necessario gestire più istanze di risorse a livello di regione. Tuttavia, devi gestire con attenzione le modifiche alle risorse globali.
Lo sforzo per gestire un'architettura che utilizza l'archetipo di deployment globale dipende anche dal deployment di uno stack distribuito non sensibile alla località o di più stack isolati a livello di regione:
- Un'applicazione distribuita e che non riconosce la località può essere espansione e scalata con maggiore flessibilità. Ad esempio, se alcuni componenti hanno requisiti critici di latenza per l'utente finale 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 il cui deployment è stato eseguito come più stack isolati a livello di regione richiede un impegno maggiore per l'operatività e la manutenzione, a causa dei seguenti fattori:
- È necessario monitorare lo stato degli stack di applicazioni in più località, sia a livello di stack che per ciascun componente.
- Se un componente diventa non disponibile in qualsiasi località, le richieste in-processo devono essere gestite in modo controllato.
- Le modifiche all'applicazione devono essere implementate con attenzione.
- I database devono essere sincronizzati tra tutte le località.
Archetipi di deployment ibridi e multi-cloud
La configurazione e il funzionamento delle topologie ibride o multi-cloud richiedono uno sforzo maggiore rispetto a un'architettura che utilizza solo Google Cloud.
- Le risorse devono essere gestite in modo coerente nelle topologie on-premise e in Google Cloud. Per gestire le applicazioni ibride containerizzate, puoi utilizzare soluzioni come GKE Enterprise, che è un modello operativo cloud unificato per eseguire il provisioning, l'aggiornamento e l'ottimizzazione dei cluster Kubernetes in più località.
- Hai bisogno di un modo per eseguire il provisioning e la gestione efficiente delle risorse su più piattaforme. Strumenti come Terraform possono aiutare a ridurre le attività 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.