Questa sezione della Google Cloud guida agli archetipi di deployment confronta gli archetipi di deployment in termini di disponibilità, robustezza contro le interruzioni, costi e complessità operativa.
La tabella seguente riassume l'analisi comparativa per gli archetipi di deployment di base: a livello di zona, regionale, multiregionale e globale. Per le topologie ibride e multi-cloud, l'archetipo di deployment utilizzato per la Google Cloud parte della topologia influisce su disponibilità, robustezza contro le interruzioni, costi e complessità operativa.
| Considerazione sulla progettazione | Zonal | Regionale | A più regioni | Globale |
|---|---|---|---|---|
| Disponibilità dell'infrastruttura | 99,9% (tre 9) | 99,99% (quattro 9) | 99,999% (cinque 9) | 99,999% (cinque 9) |
| Robustezza dell'infrastruttura contro le interruzioni a livello 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 a livello di regione | 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 | Basso | Media | Alto | Medio |
| Complessità operativa | Più semplice rispetto agli altri archetipi di deployment | Più complesso rispetto a quello a livello di zona | Più complesso rispetto a quello regionale | Potenzialmente più semplice rispetto a quello multiregionale |
Le sezioni seguenti descrivono l'analisi comparativa riassunta nella tabella precedente.
Disponibilità dell'infrastruttura
Le sezioni seguenti descrivono le differenze di disponibilità dell'infrastruttura tra gli archetipi di deployment.
Archetipi di deployment a livello di zona, regionale, multiregionale e globale
Google Cloud L'infrastruttura è progettata per supportare una disponibilità target del 99,9% per il tuo workload quando utilizzi l'archetipo di deployment a livello di zona, 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 di applicazioni
- Contratti di livello di servizio (SLA) di uptime per i Google Cloud servizi utilizzati
- Quantità di risorse ridondanti
- Ambiti di località delle risorse
Per saperne di più, consulta Blocchi predefiniti di 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 Google Cloud, la disponibilità complessiva è inferiore alla disponibilità del componente che fornisce la disponibilità minima in tutti gli ambienti.
- Se ogni componente dell'applicazione viene sottoposto a deployment in modo ridondante in Google Cloud e on-premise o in altre piattaforme cloud, la ridondanza contribuisce a garantire un'alta affidabilità.
Robustezza dell'infrastruttura contro le interruzioni a livello 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 workload in caso di interruzioni a livello di Google Cloud zona e regione.
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 a livello di zona. Devi pianificare il ripristino dalle interruzioni a livello 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 come database principale e aggiornare il bilanciatore del carico per inviare il traffico al frontend nella zona di failover.
Archetipo di deployment regionale
Un'architettura che utilizza l'archetipo di deployment regionale è robusta contro le interruzioni a livello di zona. È improbabile che un errore in una zona influisca sull'infrastruttura in altre zone. L'RTO è quasi pari a zero se i dati vengono replicati in modo sincrono. Tuttavia, quando un'interruzione influisce su un'intera Google Cloud regione, 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 un'altra regione e attivarla durante le interruzioni a livello di 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. 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 robustezza di un'architettura ibrida e multi-cloud dipende dalla robustezza 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 in Google Cloud sia in un altro ambiente (on-premise o un'altra piattaforma cloud), l'applicazione è robusta contro qualsiasi Google Cloud interruzione. 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 Google Cloud le interruzioni dipende dalla robustezza dell'archetipo di deployment utilizzato per la Google Cloud parte dell'architettura.
Costo delle Google Cloud risorse
Il costo delle Google Cloud risorse richieste per un' applicazione dipende dai Google Cloud servizi utilizzati, dal numero di risorse di cui esegui il provisioning, dal periodo di conservazione o utilizzo delle risorse e dall'archetipo di deployment scelto. Per stimare il costo delle Google Cloud risorse in un'architettura basata su qualsiasi archetipo di deployment, puoi utilizzare il Google Cloud Calcolatore prezzi.
Le sezioni seguenti descrivono le differenze di costo delle Google Cloud risorse tra i vari archetipi di deployment.
Archetipi di deployment a livello di zona rispetto a quelli regionali e multiregionali
Rispetto a un'architettura che utilizza l'archetipo di deployment a livello di zona, 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 la possibilità di utilizzare risorse globali a disponibilità elevata, 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, in alcuni casi le risorse globali potrebbero comportare costi più elevati. Ad esempio, il bilanciatore del carico globale richiede la rete 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 multi-cloud, devi considerare i costi aggiuntivi oltre al costo delle risorse di cui esegui il provisioning. Ad esempio, considera i costi come la rete ibrida 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 oltre al costo delle Google Cloud risorse di cui esegui il provisioning. 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 Google Cloud risorse tra gli 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 serviti dall'applicazione o il numero di richieste elaborate.
Gestendo attentamente l'utilizzo delle Google Cloud risorse e adottando le best practice consigliate da Google, puoi ottimizzare il costo dei deployment cloud. Per saperne di più, 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 rispetto a quelli regionali e multiregionali
Un'architettura basata sull'archetipo di deployment a livello di zona è più facile da configurare e gestire rispetto alle altre architetture di deployment. Un'applicazione eseguita in modo ridondante in più zone o regioni richiede un maggiore impegno operativo per i seguenti motivi:
- Lo stato degli stack di applicazioni in più località deve essere monitorato, sia a livello di stack sia per ogni componente dell'applicazione.
- Se un componente diventa non 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 località.
Archetipo di deployment globale
L'archetipo di deployment globale ti consente di utilizzare risorse globali a disponibilità elevata, come un bilanciatore del carico globale e un database globale. L'impegno per configurare e gestire le risorse cloud può essere inferiore a quello di un deployment multiregionale in cui devi gestire più istanze di risorse regionali. Tuttavia, devi gestire attentamente 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 indipendente dalla località o di più stack isolati a livello regionale:
- Un'applicazione distribuita e indipendente dalla località può essere espansa e scalata con maggiore flessibilità. Ad esempio, se determinati componenti hanno requisiti di latenza per gli utenti finali critici solo in località specifiche, puoi eseguire il deployment di questi componenti nelle località richieste e gestire il resto dello stack in altre località.
- Un'applicazione di cui è stato eseguito il deployment come più stack isolati a livello regionale richiede un maggiore impegno per la gestione e la manutenzione, a causa dei seguenti fattori:
- Lo stato degli stack di applicazioni in più località deve essere monitorato, sia a livello di stack sia per ogni componente.
- Se un componente diventa non 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 località.
Archetipi di deployment ibridi e multi-cloud
Le topologie ibride o multi-cloud richiedono un maggiore impegno per la configurazione e la gestione rispetto a un'architettura che utilizza solo Google Cloud.
- Le risorse devono essere gestite in modo coerente nelle topologie on-premise e Google Cloud .
- Ti serve 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. Gli amministratori della sicurezza devono acquisire competenze ed esperienza per gestire la sicurezza delle risorse distribuite in tutte le piattaforme cloud che utilizzi.