In qualità di cloud architect o decision maker, 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 multi-cloud) 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 deployment archetype è un modello astratto, indipendente dal provider, 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 in errore in cui un'applicazione può essere eseguita. Questi domini in errore possono essere una o più zone o regioniGoogle Cloud e possono estendersi fino a includere i tuoi data center on-premise o i domini in errore di 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 mostrato nel 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, regionale, multiregionale o globale. In questo senso, gli archetipi di deployment ibrido e multi-cloud 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 ai prodotti e alle funzionalità Google Cloud che dovresti utilizzare. Ad esempio, per un'applicazione containerizzata ad alta affidabilità, se scegli l'archetipo di deployment regionale, i cluster Google Kubernetes Engine (GKE) regionali sono più appropriati dei cluster GKE 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 un'alta affidabilità, puoi scegliere l'archetipo di deployment 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 deployment regionale.
Panoramica degli archetipi di deployment
Le schede seguenti forniscono le definizioni degli archetipi di deployment e un riepilogo dei casi d'uso e delle considerazioni di progettazione per ciascuno.
A livello di zona
L'applicazione viene eseguita all'interno di una singola zona Google Cloud , come mostrato nel seguente diagramma:
| Casi d'uso |
|
|---|---|
| Considerazioni sulla progettazione |
|
| Ulteriori informazioni | Consulta le sezioni seguenti: |
Regionale
La tua applicazione viene eseguita in modo indipendente in due o più zone all'interno di una singola regioneGoogle Cloud , come mostrato nel seguente diagramma:
| Casi d'uso |
|
|---|---|
| Considerazioni sulla progettazione |
|
| Ulteriori informazioni | Consulta le sezioni seguenti: |
Multiregionale
La tua applicazione viene eseguita in modo indipendente in più zone in due o più regioniGoogle Cloud . Puoi utilizzare le policy di routing DNS per instradare il traffico in entrata ai bilanciatori del carico regionali. I bilanciatori del carico regionali distribuiscono poi 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 sezioni seguenti: |
Globale
La tua applicazione viene eseguita in Google Cloudregioni in tutto il mondo, come stack distribuito a livello globale (indipendente dalla località) 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'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 |
|
|---|---|
| Considerazioni sulla progettazione | Costi per il trasferimento di dati tra regioni e la replica dei dati. |
| Ulteriori informazioni | Consulta le sezioni seguenti: |
Ibrido
Alcune parti dell'applicazione sono 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, regione, multiregione o globale.
| Casi d'uso |
|
|---|---|
| Considerazioni sulla progettazione |
|
| Ulteriori informazioni | Consulta le sezioni seguenti: |
Multi-cloud
Alcune parti della tua applicazione sono di cui è stato eseguito il deployment in Google Cloud, mentre altre sono di cui è stato eseguito il 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, regione, multiregionale o globale.
| Casi d'uso |
|
|---|---|
| Considerazioni sulla progettazione |
|
| Ulteriori informazioni | Consulta le sezioni seguenti: |
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 ↩