In qualità di architetto del cloud o responsabile decisionale, quando prevedi di eseguire il deployment di un'applicazione su Google Cloud, devi scegliere un archetipo di deployment1 adatto alla tua applicazione. Questa guida descrive sei archetipi di deployment: zonale, regionale, multiregionale, globale, ibrido e multicloud e presenta casi d'uso e considerazioni di progettazione per ciascun archetipo di deployment. La guida fornisce anche un'analisi comparativa per aiutarti a scegliere gli archetipi di implementazione che soddisfano i tuoi requisiti di disponibilità, costi, prestazioni ed efficienza operativa.
Che cos'è un archetipo di distribuzione?
Un'archetipo di deployment è un modello astratto indipendente dal provider che viene utilizzato come base per creare architetture di deployment specifiche per l'applicazione chesoddisfano i requisiti tecnici e aziendali. Ogni archetipo di deployment specifica una combinazione di domini di errore in cui può essere eseguita un'applicazione. Questi domini di errore possono essere una o più zone o regioni Google Cloud, e possono essere estesi in modo da includere i tuoi data center on-premise o i domini di errore in altri provider cloud.
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 mostrato nel diagramma precedente, in un'architettura che utilizza l'archetipo di deployment ibrido o multicloud, la topologia del cloud si basa su uno degli archetipi di base: zonale, regionale, multiregionale o globale. In questo senso, gli archetipi di deployment ibridi e multi-cloud possono essere considerati come archetipi di deployment composti che includono uno degli archetipi di base.
La scelta di un'archetipo di implementazione consente di semplificare le decisioni successive relative ai prodotti e alle funzionalità di Google Cloud da utilizzare. Ad esempio, per un'applicazione containerizzata ad alta disponibilità, se scegli l'archetipo di deployment regionale, i cluster Google Kubernetes Engine (GKE) regionali sono più appropriati dei cluster GKE zonali.
Quando scegli un'archetipo di deployment per un'applicazione, devi prendere in considerazione i compromessi tra fattori quali disponibilità, costo e complessità operativa. Ad esempio, se un'applicazione serve utenti in più paesi e richiede un'elevata disponibilità, puoi scegliere l'archetipo di implementazione multiregionale. Tuttavia, per un'applicazione interna utilizzata dai dipendenti in un'unica regione geografica, potresti dare la priorità al costo rispetto alla disponibilità e, di conseguenza, scegliere l'archetipo di implementazione regionale.
Panoramica degli archetipi di deployment
Le seguenti schede forniscono le definizioni degli archetipi di implementazione e un riepilogo dei casi d'uso e delle considerazioni di progettazione per ciascuno.
A livello di zona
L'applicazione viene eseguita in un'unica zona Google Cloud, come mostrato nel seguente diagramma:
| Casi d'uso |
|
|---|---|
| Note sul layout |
|
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Regionale
L'applicazione viene eseguita in modo indipendente in due o più zone all'interno di un'unica regione Google Cloud, come mostrato nel seguente diagramma:
| Casi d'uso |
|
|---|---|
| Note sul layout |
|
| Ulteriori informazioni | Consulta le seguenti sezioni: |
A più regioni
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 regionali. I bilanciatori del carico regionali distribuiscono quindi il traffico alle repliche zonali dell'applicazione, come mostrato nel seguente diagramma:
| Casi d'uso |
|
|---|---|
| Note sul layout |
|
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Globale
L'applicazione viene eseguita nelle regioni Google Cloud di tutto il mondo come uno stack distribuito a livello globale (non consapevole della posizione) o come stack isolati a livello di regione. Un bilanciatore del carico anycast globale distribuisce il traffico alla regione più vicina all'utente. Anche altri componenti dello stack dell'applicazione possono essere globali, ad esempio il database, la cache e l'object store.
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 un lo 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 implementazione globale con stack di applicazioni isolate 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 |
|
|---|---|
| Note sul layout | Costi per il trasferimento e la replica dei dati tra regioni. |
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Ibrido
Alcune parti dell'applicazione vengono implementate in Google Cloud, mentre altre vengono eseguite on-premise, come mostrato nel seguente diagramma. La topology in Google Cloud può utilizzare l'archetipo di deployment a livello di zona, regionale, multiregionale o globale.
| Casi d'uso |
|
|---|---|
| Note sul layout |
|
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Multi-cloud
Alcune parti dell'applicazione vengono implementate in Google Cloud, mentre altre in altre piattaforme cloud, come mostrato nel seguente diagramma. La topologia in ogni piattaforma cloud può utilizzare l'archetipo di deployment zonale, regionale, multiregionale o globale.
| Casi d'uso |
|
|---|---|
| Note sul layout |
|
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Collaboratori
Autore: Kumar Dhanagopal | Sviluppatore di soluzioni cross-product
Altri collaboratori:
- Anna Berenberg | Engineering Fellow
- Anshu Kak | Distinguished Engineer
- Jeff Welsch | Director, Product Management
- Marwan Al Shawi | Partner Customer Engineer
- Sekou Page | Product Manager outbound
- Steve McGhee | Proponente dell'affidabilità
- Victor Moreno | Product Manager, Cloud Networking
-
Anna Berenberg e Brad Calder, Deployment Archetypes for Cloud Applications, ACM Computing Surveys, Volume 55, Issue 3, Article No.: 61, pp 1-48 ↩