Questa sezione della guida agli archetipi di deployment di Google Cloud descrive l'archetipo di deployment regionale.
In un'architettura cloud che utilizza l'archetipo di distribuzione regionale, le istanze dell'applicazione vengono eseguite in due o più zone all'interno di un'unica regione Google Cloud. Tutte le istanze dell'applicazione utilizzano un repository condiviso gestito centralmente di file di configurazione. I dati dell'applicazione vengono replicati in modo sincrono in tutte le zone dell'architettura.
Il seguente diagramma mostra la topologia cloud di un'applicazione ad alta disponibilità che viene eseguita in modo indipendente in tre zone all'interno di una singola regione Google Cloud:
Il diagramma precedente mostra un'applicazione con componenti frontend e backend che vengono eseguiti in modo indipendente in tre zone di una regione Google Cloud. Un bilanciatore del carico esterno inoltra le richieste degli utenti a uno dei frontend. Un bilanciatore del carico interno inoltra il traffico dai frontend ai backend. L'applicazione utilizza un database replicato nelle varie zone. Se si verifica un'interruzione di servizio in una zona, il database esegue il failover su una replica in un'altra zona.
La topologia nel diagramma precedente è solida contro le interruzioni nelle zone, ma non contro quelle nelle regioni. Per poter recuperare da interruzioni nella regione, devi aver eseguito il deployment di una replica passiva dell'applicazione in una seconda regione (di failover), come mostrato nel seguente diagramma:
Quando si verifica un'interruzione nella regione principale, devi promuovere il database nella regione di failover e lasciare che i criteri di routing DNS indirizzino il traffico al bilanciatore del carico nella regione di failover.
Per ottimizzare il costo dell'infrastruttura di failover, puoi utilizzare la regione di failover a una capacità inferiore implementando meno risorse.
Casi d'uso
Le sezioni seguenti forniscono esempi di casi d'uso per i quali l'archetipo di implementazione regionale è una scelta appropriata.
Applicazione ad alta disponibilità con utenti all'interno di un'area geografica
Consigliamo l'archetipo di implementazione regionale per le applicazioni che richiedono robustezza contro le interruzioni del servizio nelle zone, ma che possono tollerare un certo tempo di inattività causato da interruzioni del servizio nelle regioni. Se una parte dello stack dell'applicazione non va a buon fine, l'applicazione continua a essere eseguita se in ogni livello esiste almeno un componente funzionante con una capacità adeguata. Se si verifica un'interruzione del servizio in una zona, lo stack delle applicazioni continua a funzionare nelle altre zone.
Bassa latenza per gli utenti dell'applicazione
Se gli utenti di un'applicazione si trovano in un'area geografica, ad esempio un singolo paese, l'archetipo di deployment regionale può contribuire a migliorare le prestazioni percepite dall'utente dell'applicazione. Puoi ottimizzare la latenza della rete per le richieste degli utenti eseguendo il deployment dell'applicazione nella regione Google Cloud più vicina ai tuoi utenti.
Networking a bassa latenza tra i componenti dell'applicazione
Un'architettura a singola regione potrebbe essere adatta per applicazioni come il calcolo batch che richiedono connessioni di rete a bassa latenza e a larghezza di banda elevata tra i nodi di calcolo. Tutte le risorse si trovano in una singola regione Google Cloud, pertanto il traffico di rete tra risorse rimane all'interno della regione. La latenza di rete tra le risorse è bassa e non si applicano costi di trasferimento dei dati tra regioni. Si applicano comunque i costi di rete all'interno della regione.
Conformità ai requisiti di localizzazione e sovranità dei dati
L'archetipo di implementazione regionale può aiutarti a soddisfare i requisiti normativi per la residenza e la sovranità operativa dei dati. Ad esempio, un paese europeo potrebbe richiedere che tutti i dati utente vengano archiviati e accessibili in data center fisicamente all'interno del paese. Per contribuire a soddisfare questo requisito, puoi eseguire il deployment dell'applicazione in una regione Google Cloud in Europa.
Note sul layout
Quando crei un'architettura basata sull'archetipo di deployment regionale, prendi in considerazione i seguenti fattori di progettazione.
Tempo di riposo durante le interruzioni della regione
Quando si verifica un'interruzione nella regione, l'applicazione non è disponibile. Puoi ridurre il tempo di riposo causato da interruzioni della regione mantenendo una replica passiva (di failover) dello stack dell'infrastruttura in un'altra regione Google Cloud. Se si verifica un'interruzione nella regione principale, puoi attivare lo stack nella regione di failover e utilizzare i criteri di routing DNS per indirizzare il traffico al bilanciatore del carico nella regione di failover.
Costo delle risorse ridondanti
Un'architettura multizona in genere ha più risorse cloud rispetto a un deployment monozona. Tieni conto del costo di queste risorse cloud quando crei la tua architettura. Per le applicazioni che richiedono robustezza contro le interruzioni delle zone, il vantaggio in termini di disponibilità di un'architettura multi-zona potrebbe giustificare il costo più elevato.
Architettura di riferimento
Per un'architettura di riferimento che puoi utilizzare per progettare un deployment a livello di regione sulle VM Compute Engine, consulta Deployment a livello di regione su Compute Engine.