In qualità di Cloud Architect o responsabile delle decisioni, quando prevedi di eseguire il deployment di un'applicazione in Google Cloud, devi scegliere un archetipo di deployment1 adatto alla tua applicazione. Questa guida descrive sei archetipi di deployment: a livello di zona, a livello di regione, multiregionale, globale, ibrido e multi-cloud, e presenta casi d'uso e considerazioni sulla progettazione per ogni archetipo di deployment. La guida fornisce anche un'analisi comparativa per aiutarti a scegliere gli archetipi di deployment che soddisfano i tuoi requisiti di disponibilità, costi, prestazioni ed efficienza operativa.
Cos'è un archetipo di deployment?
Un archetipo di deployment è un modello astratto indipendente dal provider che puoi utilizzare come base per creare architetture di deployment specifiche dell'applicazione che soddisfino i tuoi requisiti aziendali e tecnici. Ogni archetipo di deployment specifica una combinazione di domini in errore in cui può essere eseguita un'applicazione. Questi domini in errore possono essere una o più zone o regioni Google Cloud e possono estendersi per includere i tuoi data center on-premise o i domini in errore in altri cloud provider.
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 mostra il diagramma precedente, in un'architettura che utilizza l'archetipo di deployment ibrido o multi-cloud, la topologia cloud si basa su uno degli archetipi di base: a livello di zona, a livello di regione, multiregionale o globale. In questo senso, gli archetipi di deployment ibrido e multi-cloud possono essere considerati come archetipi di deployment compositi che includono uno degli archetipi di base.
La scelta di un archetipo di deployment consente di semplificare le decisioni successive relative ai prodotti e alle funzionalità di Google Cloud da utilizzare. Ad esempio, per un'applicazione containerizzata a disponibilità elevata, se scegli l'archetipo di deployment a livello di regione, i cluster Google Kubernetes Engine (GKE) regionali sono più appropriati dei cluster GKE a livello di zona.
Quando scegli un archetipo di deployment per un'applicazione, devi considerare dei compromessi tra fattori quali disponibilità, costo e complessità operativa. Ad esempio, se un'applicazione serve gli utenti in più paesi e ha bisogno di un'alta disponibilità, puoi scegliere l'archetipo di deployment multiregionale. Tuttavia, per un'applicazione interna utilizzata da dipendenti di una singola area geografica, potresti dare la priorità al costo rispetto alla disponibilità e, di conseguenza, scegliere l'archetipo di deployment a livello di regione.
Panoramica degli archetipi di deployment
Le seguenti schede forniscono le definizioni degli archetipi di deployment e un riepilogo dei casi d'uso e le considerazioni sulla progettazione per ciascuno.
Zonale
L'applicazione viene eseguita all'interno di una singola 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 una singola regione Google Cloud, come mostrato nel seguente diagramma:
| Casi d'uso |
|
|---|---|
| Note sul layout |
|
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Multiregionale
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 a livello di regione. I bilanciatori del carico a livello di regione distribuiscono quindi il traffico alle repliche a livello di zona 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 stack distribuito a livello globale (senza rilevare la posizione) o come stack isolati a livello di regione. Un bilanciatore del carico anycast globale distribuisce il traffico nella regione più vicina all'utente. Anche altri componenti dello stack di applicazioni possono essere globali, ad esempio database, cache e archivio di oggetti.
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 uno 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 deployment globale con stack di applicazioni isolati 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 dei dati e la replica dei dati tra regioni. |
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Ibrido
Il deployment di alcune parti dell'applicazione viene eseguito in Google Cloud, mentre altre vengono eseguite on-premise, come mostrato nel diagramma seguente. La topologia in Google Cloud può utilizzare l'archetipo di deployment a livello di zona, di regione, multiregionale o globale.
| Casi d'uso |
|
|---|---|
| Note sul layout |
|
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Multi-cloud
Il deployment di alcune parti della tua applicazione viene eseguito in Google Cloud, mentre altre in altre piattaforme cloud, come illustrato nel seguente schema. La topologia in ogni piattaforma cloud può utilizzare l'archetipo di deployment a livello di zona, a livello di regione, multiregionale o globale.
| Casi d'uso |
|
|---|---|
| Note sul layout |
|
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Collaboratori
Autore: Kumar Dhanagopal | Cross-Product Solution Developer
Altri collaboratori:
- Anna Berenberg | Engineering Fellow
- Anshu Kak | Ingegnere distinto
- Jeff Welsch | Direttore, Product Management
- Marwan Al Shawi | Partner Customer Engineer
- Pagina Sekou | Outbound Product Manager
- Steve McGhee | Avvocato dell'affidabilità
- Victor Moreno | Product Manager, Cloud Networking
-
Anna Berenberg e Brad Calder, Deployment Archetypes for Cloud Applications, ACM Computing Surveys, volume 55, numero 3, n. articolo: 61, pp. 1-48 ↩