Questa sezione della Google Cloud guida agli archetipi di deployment descrive l'archetipo di deployment regionale.
In un'architettura cloud che utilizza l'archetipo di deployment regionale, le istanze dell'applicazione vengono eseguite in due o più zone all'interno di una singola Google Cloud regione. Tutte le istanze dell'applicazione utilizzano un repository condiviso di file di configurazione gestito centralmente. I dati dell'applicazione vengono replicati in modo sincrono in tutte le zone dell'architettura.
Il seguente diagramma mostra la topologia cloud per un'applicazione ad alta disponibilità che viene eseguita in modo indipendente in tre zone all'interno di una singola Google Cloud regione:
Il diagramma precedente mostra un'applicazione con componenti frontend e backend che vengono eseguiti in modo indipendente in tre zone di una Google Cloud regione. 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 tra le zone. Se si verifica un'interruzione della zona, il database esegue il failover a una replica in un'altra zona.
La topologia nel diagramma precedente è robusta contro le interruzioni di zona, ma non contro le interruzioni di regione. Per poter eseguire il ripristino in caso di interruzioni di 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 in the regione di failover e utilizzare policy di routing DNS per indirizzare 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 eseguendo il deployment di meno risorse.
Casi d'uso
Le sezioni seguenti forniscono esempi di casi d'uso per i quali l'archetipo di deployment regionale è una scelta appropriata.
Applicazione ad alta disponibilità con utenti all'interno di un'area geografica
Ti consigliamo l'archetipo di deployment regionale per le applicazioni che richiedono robustezza contro le interruzioni di zona, ma possono tollerare alcuni tempi di inattività causati da interruzioni di regione. Se una parte dello stack dell'applicazione non funziona, l'applicazione continua a essere eseguita se in ogni livello esiste almeno un componente funzionante con capacità adeguata. Se si verifica un'interruzione di zona, lo stack dell'applicazione continua a essere eseguito nelle altre zone.
Bassa latenza per gli utenti dell'applicazione
Se gli utenti di un'applicazione si trovano all'interno di un'area geografica, ad esempio un singolo paese, l'archetipo di deployment regionale può contribuire a migliorare le prestazioni dell'applicazione percepite dall'utente. Puoi ottimizzare la latenza di rete per le richieste degli utenti eseguendo il deployment dell'applicazione nella Google Cloud regione più vicina agli utenti.
Networking a bassa latenza tra i componenti dell'applicazione
Un'architettura a singola regione potrebbe essere adatta ad applicazioni come il batch computing che richiedono connessioni di rete a bassa latenza e banda larga tra i nodi di calcolo. Tutte le risorse si trovano in una singola Google Cloud regione, quindi il traffico di rete tra le risorse rimane all'interno della regione. La latenza di rete tra le risorse è bassa e non vengono addebitati costi di trasferimento dei dati tra regioni. Si applicano comunque i costi di rete all'interno della regione.
Rispetto dei requisiti di localizzazione e sovranità dei dati
L'archetipo di deployment regionale può aiutarti a soddisfare i requisiti normativi per la residenza dei dati e la sovranità operativa. Ad esempio, un paese in Europa potrebbe richiedere che tutti i dati utente vengano archiviati e accessibili nei data center situati fisicamente all'interno del paese. Per soddisfare questo requisito, puoi eseguire il deployment dell'applicazione in una Google Cloud regione in Europa.
Note sul layout
Quando crei un'architettura basata sull'archetipo di deployment regionale, tieni presente i seguenti fattori di progettazione.
Tempi di inattività durante le interruzioni di regione
Quando si verifica un'interruzione di regione, l'applicazione non è disponibile. Puoi ridurre i tempi di inattività causati dalle interruzioni di regione mantenendo una replica passiva (di failover) di stack dell'infrastruttura in un'altra Google Cloud regione. Se si verifica un'interruzione nella regione principale, puoi attivare lo stack nella regione di failover e utilizzare le policy di routing DNS per indirizzare il traffico al bilanciatore del carico nella regione di failover.
Costo delle risorse ridondanti
Un'architettura multi-zona in genere ha più risorse cloud rispetto a un deployment a singola zona. Tieni presente il costo di queste risorse cloud quando crei l'architettura. Per le applicazioni che richiedono robustezza contro le interruzioni di zona, il vantaggio 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 regionale sulle VM Compute Engine, consulta Deployment regionale su Compute Engine.