Questa sezione della guida sugli archetipi di deployment di Google Cloud descrive l'archetipo di deployment a livello di regione.
In un'architettura cloud che utilizza l'archetipo di deployment a livello di regione, le istanze dell'applicazione vengono eseguite in due o più zone all'interno di una singola regione Google Cloud. 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 regione Google Cloud:
Il diagramma precedente mostra un'applicazione con componenti frontend e backend eseguiti in modo indipendente in tre zone in una regione di 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 tra le zone. In caso di interruzione di una zona, il database esegue il failover su una replica in un'altra zona.
La topologia nel diagramma precedente è affidabile per le interruzioni delle zone, ma non per quelle delle regioni. Per poter eseguire il ripristino in seguito a interruzioni della regione, devi aver eseguito il deployment di una replica passiva dell'applicazione in una seconda regione (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 instradano 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 seguenti sezioni forniscono esempi di casi d'uso per cui l'archetipo di deployment a livello di regione è una scelta appropriata.
Applicazione a disponibilità elevata con utenti in un'area geografica
Consigliamo l'archetipo di deployment a livello di regione per le applicazioni che hanno bisogno di solidità contro le interruzioni delle zone, ma possono tollerare alcuni tempi di inattività causati da interruzioni delle regioni. In caso di errore di una parte dello stack dell'applicazione, l'applicazione continua a essere eseguita se in ogni livello è presente almeno un componente funzionante con capacità adeguata. In caso di interruzione di una zona, lo stack di applicazioni 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 a livello di regione 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 regione Google Cloud più vicina ai tuoi utenti.
Networking a bassa latenza tra componenti delle applicazioni
Un'architettura a regione singola potrebbe essere adatta per applicazioni come il calcolo batch che richiedono connessioni di rete a bassa latenza e ad alta larghezza di banda tra i nodi di calcolo. Tutte le risorse si trovano in una singola regione Google Cloud, quindi il traffico di rete tra le risorse rimane all'interno della regione. La latenza della rete tra risorse è bassa e non ti vengono addebitati costi di trasferimento dei dati tra regioni. Si applicano comunque i costi di rete all'interno della regione.
Conformità con i requisiti di residenza e sovranità dei dati
L'archetipo di deployment a livello di regione può aiutarti a soddisfare i requisiti normativi per la situazione dei dati e la sovranità operativa. Ad esempio, un paese europeo potrebbe richiedere che tutti i dati utente siano archiviati e accessibili in data center che si trovano fisicamente all'interno del paese. Per 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 a livello di regione, considera i fattori di progettazione riportati di seguito.
Tempo di riposo durante le interruzioni della regione
Quando si verifica un'interruzione di una regione, l'applicazione non funziona. Puoi ridurre i tempi di inattività causati da interruzioni della regione mantenendo una replica passiva (failover) dello stack di infrastruttura in un'altra regione Google Cloud. Se un'interruzione si verifica nella regione principale, puoi attivare lo stack nella regione di failover e utilizzare i criteri di routing DNS per instradare il traffico al bilanciatore del carico nella regione di failover.
Costo delle risorse ridondanti
Un'architettura multizona ha in genere più risorse cloud rispetto a un deployment a zona singola. Considera il costo di queste risorse cloud quando crei la tua architettura. Per le applicazioni che richiedono solidità contro le interruzioni delle zone, il vantaggio della disponibilità di un'architettura multizona potrebbe giustificare il costo più elevato.
Architettura di riferimento
Per un'architettura di riferimento da utilizzare per progettare un deployment a livello di regione sulle VM di Compute Engine, consulta Deployment a livello di regione su Compute Engine.