In qualità di architetto cloud o decisore, quando pianifichi 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, regionale, multiregionale, globale, ibrido e multicloud e presenta casi d'uso e considerazioni sulla progettazione per ciascun 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.
Che cos'è un archetipo di deployment?
Un archetipo di deployment è un modello astratto e indipendente dal fornitore che utilizzi come base per creare architetture di deployment specifiche per l'applicazione che soddisfano i tuoi requisiti aziendali e tecnici. Ogni archetipo di deployment specifica una combinazione di domini di errore in cui un'applicazione può essere eseguita. Questi domini di errore possono essere una o più Google Cloud zone o regioni, e possono estendersi fino a includere i data center on-premise o i domini di errore di altri fornitori di servizi 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 cloud si basa su uno degli archetipi di base: a livello di zona, regionale, multiregionale o globale. In questo senso, gli archetipi di deployment ibrido e multicloud possono essere considerati archetipi di deployment compositi che includono uno degli archetipi di base.
La scelta di un archetipo di deployment semplifica le decisioni successive relative a i Google Cloud prodotti e alle funzionalità da utilizzare. Ad esempio, per un'applicazione containerizzata a disponibilità elevata, se scegli l'archetipo di deployment regionale, 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 i compromessi tra fattori come disponibilità, costi e complessità operativa. Ad esempio, se un'applicazione serve utenti in più paesi e richiede una disponibilità elevata, potresti scegliere l'archetipo di deployment multiregionale. Tuttavia, per un'applicazione interna utilizzata dai dipendenti in una singola regione geografica, potresti dare la priorità al costo rispetto alla disponibilità e, di conseguenza, scegliere l'archetipo di deployment regionale.
Panoramica degli archetipi di deployment
Le seguenti schede forniscono le definizioni degli archetipi di deployment e un riepilogo dei casi d'uso e delle considerazioni sulla progettazione per ciascuno.
Zonal
L'applicazione viene eseguita in una singola Google Cloud zona, come mostrato nel seguente diagramma:
| Casi d'uso |
|
|---|---|
| Considerazioni sulla progettazione |
|
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Regionale
L'applicazione viene eseguita in modo indipendente in due o più zone all'interno di una singola Google Cloud regione, come mostrato nel seguente diagramma:
| Casi d'uso |
|
|---|---|
| Considerazioni sulla progettazione |
|
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Multiregionale
L'applicazione viene eseguita in modo indipendente in più zone in due o più Google Cloud regioni. Puoi utilizzare le policy 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 a livello di zona dell'applicazione, come mostrato nel seguente diagramma:
| Casi d'uso |
|
|---|---|
| Considerazioni sulla progettazione |
|
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Globale
L'applicazione viene eseguita in Google Cloud regioni di tutto il mondo, come stack distribuito a livello globale (indipendente dalla località) o come stack isolati a livello regionale. 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, come il database, la cache e l'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 regionale. 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 singolo database replicato a livello globale.
| Casi d'uso |
|
|---|---|
| Considerazioni sulla progettazione | Costi per il trasferimento di dati tra regioni e la replica dei dati. |
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Ibrido
Alcune parti dell'applicazione vengono sottoposte a deployment in Google Cloud, mentre altre vengono eseguite on-premise, come mostrato nel seguente diagramma. La topologia in Google Cloud può utilizzare l'archetipo di deployment a livello di zona, regionale, multiregionale o globale.
| Casi d'uso |
|
|---|---|
| Considerazioni sulla progettazione |
|
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Multicloud
Alcune parti dell'applicazione vengono sottoposte a deployment in Google Cloud, mentre altre vengono sottoposte a deployment in altre piattaforme cloud, come mostrato nel seguente diagramma. La topologia in ogni piattaforma cloud può utilizzare l'archetipo di deployment a livello di zona, regionale, multiregionale o globale.
| Casi d'uso |
|
|---|---|
| Considerazioni sulla progettazione |
|
| Ulteriori informazioni | Consulta le seguenti sezioni: |
Collaboratori
Autore: Kumar Dhanagopal | Cross-Product Solution Developer
Altri collaboratori:
- Anna Berenberg | Engineering Fellow
- Anshu Kak | Distinguished Engineer
- Jeff Welsch | Director, Product Management
- Marwan Al Shawi | Partner Customer Engineer
- Sekou Page | Outbound Product Manager
- Steve McGhee | Reliability Advocate
- 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 ↩