Best practice per la scelta delle regioni di Compute Engine

Questo articolo descrive i criteri da prendere in considerazione quando scegli le regioni Google Cloud da utilizzare per le risorse Compute Engine, una decisione che in genere viene presa da architetti cloud o dal management dell'engineering. Questo documento si concentra principalmente sull'aspetto della latenza della procedura di selezione e si rivolge alle app a cui accedono i consumatori, come giochi o app mobile o web, ma molti dei concetti possono essere applicati ad altri scenari di utilizzo.

Google offre più regioni in tutto il mondo per eseguire il deployment delle risorse Compute Engine. Diversi fattori influiscono sulla scelta delle regioni:

  • Limitazioni specifiche per regione
  • Latenza utente per regione
  • Requisiti di latenza dell'app
  • Grado di controllo sulla latenza
  • Equilibrio tra bassa latenza e semplicità

Terminologia

regione
Un'area geografica indipendente in cui esegui le tue risorse. Ogni regione è composta da zone, in genere almeno tre.
zona
Un'area di deployment per le risorse Google Cloud all'interno di una regione. Posizionare le risorse in zone diverse di una regione riduce il rischio di un'interruzione dell'infrastruttura che colpisca tutte le risorse contemporaneamente.
Risorse Compute Engine
Le risorse in Compute Engine, come le istanze di macchine virtuali, vengono di solito implementate in una zona all'interno di una regione. Altri prodotti, come Google Kubernetes Engine e Dataflow, utilizzano risorse Compute Engine e, pertanto, possono essere dipiazzati nelle stesse regioni o zone.
tempo di round trip (RTT)
Il tempo necessario per inviare un pacchetto IP e ricevere il relativo riconoscimento.

Quando scegliere le regioni Compute Engine

All'inizio della fase di architettura di un'app, decidi quante e quali regioni Compute Engine utilizzare. La tua scelta potrebbe influire sulla tua app, ad esempio:

  • L'architettura dell'app potrebbe cambiare se sincronizzi alcuni dati tra le copie perché gli stessi utenti potrebbero connettersi tramite regioni diverse in momenti diversi.
  • Il prezzo varia in base alla regione.
  • La procedura per spostare un'app e i relativi dati tra regioni è complessa e talvolta onerosa, pertanto deve essere evitata una volta che l'app è pubblicata.

Fattori da considerare quando si selezionano le regioni

È normale che le persone eseguino il deployment in una regione in cui si trovano, ma non considerano se questa è l'esperienza utente migliore. Supponiamo che tu risieda in Europa e abbia una base utenti globale e voglia eseguire il deployment in una singola regione. La maggior parte delle persone prenderebbe in considerazione il deployment in una regione europea, ma in genere è meglio ospitare questa app in una delle regioni degli Stati Uniti, perché gli Stati Uniti sono la regione più collegata alle altre regioni.

Diversi fattori influiscono sulla scelta del luogo in cui implementare la tua app.

Latenza

Il fattore principale da considerare è la latenza che gli utenti sperimentano. Tuttavia, si tratta di un problema complesso perché la latenza dell'utente è influenzata da più aspetti, come la memorizzazione nella cache e i meccanismi di bilanciamento del carico.

Nei casi d'uso aziendali, la latenza per i sistemi on-premise o per un determinato sottoinsieme di utenti o partner è più critica. Ad esempio, la scelta della regione più vicina ai tuoi sviluppatori o dei servizi di database on-premise interconnessi con Google Cloud potrebbe essere il fattore decisivo.

Prezzi

I costi delle risorse Google Cloud variano in base alla regione. Per stimare il prezzo sono disponibili le seguenti risorse:

Se decidi di eseguire il deployment in più regioni, tieni presente che sono previsti addebiti per il trasferimento di dati per i dati sincronizzati tra le regioni.

Colocation con altri servizi Google Cloud

Se possibile, colloca le risorse Compute Engine insieme ad altri servizi Google Cloud. Sebbene la maggior parte dei servizi sensibili alla latenza sia disponibile in ogni regione, alcuni sono disponibili solo in località specifiche.

Disponibilità del tipo di macchina

Non tutte le piattaforme CPU e i tipi di macchine sono disponibili in ogni regione. La disponibilità di piattaforme CPU o tipi di istanze specifiche varia in base alla regione e persino alla zona. Se vuoi eseguire il deployment di risorse utilizzando determinati tipi di macchine, scopri la disponibilità zonale di queste risorse.

Quote delle risorse

La tua capacità di eseguire il deployment delle risorse Compute Engine è limitata dalle quote di risorse regionali, quindi assicurati di richiedere una quota sufficiente per le regioni in cui prevedi di eseguire il deployment. Se stai pianificando un deployment particolarmente grande, collabora in anticipo con il team di vendita per discutere delle tue scelte di selezione delle regioni in modo da assicurarti di disporre di una quota sufficiente.

Percentuale di energia a zero emissioni di CO2

Per alimentare ogni regione Google Cloud, Google utilizza l'elettricità della rete elettrica in cui si trova la regione. Questa elettricità genera più o meno emissioni di anidride carbonica, a seconda del tipo di centrali elettriche che generano elettricità per la rete e del momento in cui Google la consuma. Di recente Google si è prefissato l'obiettivo di utilizzare energia a zero emissioni di CO2 per alimentare le tue applicazioni nel momento e nel luogo in cui ti servono, 24 ore al giorno, in ogni regione Google Cloud, entro il 2030.

Fino al raggiungimento di questo obiettivo, ogni regione Google Cloud verrà rifornita ogni ora da una combinazione di fonti di energia basate sul carbonio e a zero emissioni di carbonio. Chiamiamo questa metrica percentuale di energia a zero emissioni di CO2 (CFE%) e la pubblichiamo per le regioni Google Cloud. Per le nuove applicazioni su Google Cloud, puoi utilizzare questa tabella per iniziare a incorporare l'impatto sul carbonio nelle tue decisioni di architettura. Se scegli una regione con una percentuale di energia a zero emissioni di CO2 più elevata, in media la tua applicazione verrà alimentata con energia a zero emissioni di CO2 per una percentuale più elevata delle ore di esecuzione, riducendo le emissioni di anidride carbonica lorde dell'applicazione.

Valutare i requisiti di latenza

La latenza è spesso un fattore chiave per la scelta della regione, perché una latenza elevata degli utenti può comportare un'esperienza utente di qualità inferiore. Puoi influire su alcuni aspetti della latenza, ma altri sono fuori dal tuo controllo.

Quando eseguono l'ottimizzazione in base alla latenza, molti architetti di sistema prendono in considerazione solo la latenza o la distanza della rete tra l'ISP dell'utente e l'istanza della macchina virtuale. Tuttavia, questo è solo uno dei molti fattori che influiscono sulla latenza dell'utente, come puoi vedere nel seguente diagramma.

Valutare la latenza nella scelta della regione di Compute Engine

In qualità di architetto di app, puoi ottimizzare la selezione della regione e la latenza dell'app, ma non hai alcun controllo sull'ultimo miglio e sulla latenza degli utenti ai Point of Presence (POP) di Google Edge più vicini.

La selezione della regione può influire solo sulla latenza per la regione Compute Engine e non sull'intera latenza. A seconda del caso d'uso, questa potrebbe essere solo una piccola parte della latenza complessiva. Ad esempio, se i tuoi utenti utilizzano principalmente reti cellulari, potrebbe non essere utile provare a ottimizzare le regioni, in quanto ciò influisce poco sulla latenza totale degli utenti.

Latenza dell'ultimo miglio

La latenza di questo segmento varia a seconda della tecnologia utilizzata per accedere a internet. Ad esempio, la latenza tipica per raggiungere un ISP è di 1-10 ms sulle reti moderne. Al contrario, le latenze tipiche su una rete mobile 3G sono 100-500 ms. L'intervallo di latenza per i fornitori di servizi DSL e via cavo è di circa 10-60 ms.

Latenza del frontend e del POP di confine di Google

A seconda del modello di implementazione, è importante anche la latenza all'edge della rete di Google. È qui che i prodotti di bilanciamento del carico globale terminano le sessioni TCP e SSL e da cui Cloud CDN pubblica i risultati memorizzati nella cache. In base ai contenuti pubblicati, molti viaggi di andata e ritorno potrebbero già terminare qui perché solo una parte dei dati deve essere recuperata per l'intero percorso. Questa latenza potrebbe essere notevolmente superiore se utilizzi il livello di servizio di rete standard.

Latenza della regione Compute Engine

La richiesta dell'utente entra nella rete di Google nel POP di confine. La regione Compute Engine è la posizione in cui si trovano le richieste di gestione delle risorse Google Cloud. Questo segmento corrisponde alla latenza tra il POP perimetrale e la regione Compute Engine e si trova interamente all'interno della rete globale di Google.

Latenza delle app

Si tratta della latenza della risposta dell'app alle richieste, incluso il tempo necessario all'app per elaborare la richiesta.

App diverse hanno requisiti di latenza diversi. A seconda dell'app, gli utenti sono più tolleranti nei confronti dei problemi di latenza. Le app che interagiscono in modo asincrono o le app mobile con una soglia di latenza elevata (100 millisecondi o più) possono essere implementate in un'unica regione senza degradare l'esperienza utente. Tuttavia, per app come i giochi in tempo reale, alcuni millisecondi di latenza possono avere un effetto maggiore sull'esperienza utente. Esegui il deployment di questi tipi di app in più regioni vicine agli utenti.

Pattern di deployment globali

Questa sezione spiega in che modo i vari modelli di implementazione influiscono sui fattori di latenza.

Deployment in una singola regione

L'immagine seguente mostra un deployment in una singola regione.

Latenza del deployment di un singolo frontend

Anche se la tua app serve una base utenti globale, in molti casi una singola regione è ancora la scelta migliore. I vantaggi della latenza più bassa potrebbero non compensare la complessità aggiuntiva del deployment multi-regione. Anche con un deployment in una sola regione, puoi comunque utilizzare ottimizzazioni, come Cloud CDN e il bilanciamento del carico globale, per ridurre la latenza degli utenti. Puoi scegliere di utilizzare una seconda regione per motivi di backup e ripristino di emergenza, ma questo non influisce sul percorso di pubblicazione dell'app e, di conseguenza, non influisce sulla latenza dell'utente.

Frontend distribuito in più regioni e backend in una singola regione

Il seguente diagramma mostra un modello di implementazione in cui il frontend viene distribuito su più regioni, ma il backend è limitato a una singola regione. Questo modello offre il vantaggio di una latenza inferiore per i server frontend, senza dover sincronizzare i dati in più regioni.

Latenza del deployment del frontend distribuito

Questo modello di implementazione offre una bassa latenza utente in scenari in cui la richiesta media dell'utente non comporta richieste di dati o comporta solo alcune richieste di dati al backend centrale prima che l'app possa produrre un risultato. Un esempio è un'app che implementa un livello di memorizzazione nella cache intelligente sul frontend o che gestisce le scritture dei dati in modo asincrono. Un'app che effettua molte richieste che richiedono un percorso completo al backend potrebbe non trarre vantaggio da questo modello.

Frontend e backend distribuiti in più regioni

Un modello di implementazione in cui distribuisci il frontend e il backend in più regioni consente di ridurre al minimo la latenza dell'utente perché l'app può rispondere completamente a qualsiasi richiesta localmente. Tuttavia, questo modello presenta una maggiore complessità perché tutti i dati devono essere archiviati e accessibili localmente. Per rispondere a tutte le richieste degli utenti, i dati devono essere completamente replicati in tutte le regioni.

Latenza del deployment multi distribuito

Spanner, l'offerta di database gestito coerente a livello globale, ha un'opzione multiregionale su tre continenti, in cui, oltre alle repliche di lettura/scrittura negli Stati Uniti, sono presenti due repliche di lettura in Europa e Asia. Questa opzione fornisce accesso in lettura a bassa latenza ai dati per le istanze di calcolo situate negli Stati Uniti, in Europa o in Asia. Se il tuo servizio ha come target gli Stati Uniti, è disponibile anche un'opzione multiregionale con replica all'interno degli Stati Uniti.

Se decidi di eseguire il tuo servizio di database su Compute Engine, devi eseguire la replica dei dati autonomamente. Questa replica è un'impresa significativa perché mantenere i dati sincronizzati in modo coerente a livello globale è difficile. È più facile da gestire se il database viene scritto in una sola regione tramite scritture asincrone e le altre regioni ospitano repliche di sola lettura del database.

La replica dei database tra regioni è complessa e consigliamo di rivolgersi a un partner affidabile con esperienza in questo campo, ad esempio Datastax per la replica di Cassandra.

Più app parallele

A seconda della natura della tua app, con una variante dell'approccio precedente, puoi mantenere la bassa latenza utente riducendo al contempo la necessità di una replica costante dei dati. Come illustrato nell'immagine seguente, esistono più app parallele, tutte composte da un frontend e un backend, e gli utenti vengono indirizzati all'app corretta. Solo una piccola parte dei dati viene condivisa tra i siti.

Latenza delle app parallele

Ad esempio, se gestisci un'attività di vendita al dettaglio, potresti pubblicare annunci per gli utenti di regioni diverse tramite domini di paesi diversi ed eseguire siti paralleli in tutte queste regioni, sincronizzando i dati di prodotti e utenti solo se necessario. I siti locali mantengono aggiornata la disponibilità delle scorte locali e gli utenti si connettono a un sito ospitato localmente selezionando un dominio del paese. Quando un utente visita un dominio di un altro paese, viene reindirizzato al dominio corretto.

Un altro esempio è nei giochi in tempo reale. Potresti avere solo un servizio lobby globale in cui gli utenti scelgono una stanza di gioco o un mondo vicino alla loro posizione e queste stanze o questi mondi non condividono dati tra loro.

Un terzo esempio è l'offerta di Software-as-a-Service (SaaS) in regioni diverse, dove la posizione dei dati viene selezionata al momento della creazione dell'account in base alla posizione dell'utente o alla sua scelta. Dopo aver eseguito l'accesso, l'utente viene reindirizzato a un sottodominio specifico per località e utilizza il servizio a livello di regione.

Ottimizzare la latenza tra utenti e regioni

Indipendentemente dal modello di implementazione, puoi combinare i metodi di ottimizzazione per ridurre la latenza visibile all'utente finale. Alcuni di questi metodi sono funzionalità di Google Cloud, mentre altri richiedono di modificare l'app.

Utilizzare la rete di livello Premium

Google offre livelli di servizio di rete premium (predefinito) e standard. Il traffico del livello Standard viene inviato tramite ISP di transito dalle regioni Google Cloud, mentre il livello Premium offre una latenza inferiore inviando il traffico tramite la rete privata globale di Google. La rete di livello Premium riduce la latenza dell'utente e deve essere utilizzata per tutte le parti dell'app nel percorso di pubblicazione. La rete di livello Premium è necessaria anche per utilizzare i prodotti di bilanciamento del carico globale di Google.

Utilizzare Cloud Load Balancing e Cloud CDN

Cloud Load Balancing, ad esempio il bilanciamento del carico HTTP(S), TCP e proxy SSL, consente di reindirizzare automaticamente gli utenti alla regione più vicina in cui sono presenti backend con capacità disponibili.

Anche se la tua app si trova in una sola regione, l'utilizzo di Cloud Load Balancing offre comunque una latenza utente inferiore perché le sessioni TCP e SSL vengono terminate all'edge della rete. Termina facilmente il traffico utente con HTTP/2 e QUIC (Quick UDP Internet Connections). Puoi anche integrare Cloud CDN con il bilanciamento del carico HTTP(S) per caricare gli asset statici direttamente dall'edge della rete, riducendo ulteriormente la latenza per gli utenti.

Memorizza nella cache localmente

Quando le posizioni del frontend sono diverse da quelle del backend, assicurati di memorizzare nella cache le risposte dei servizi di backend, se possibile. Quando il frontend e il backend si trovano nella stessa regione, la latenza dell'app si riduce perché anche le query che richiedono molto tempo vengono ridotte. Memorystore for Redis è un datastore in memoria completamente gestito che puoi utilizzare.

Ottimizza il client dell'app o il frontend web

Puoi utilizzare tecniche lato client, un'app mobile o il frontend web, per ottimizzare la latenza dell'utente. Ad esempio, precaricare alcuni asset o memorizzare nella cache i dati all'interno dell'app.

Puoi anche ottimizzare il modo in cui la tua app recupera le informazioni riducendo il numero di richieste e recuperando le informazioni in parallelo, se possibile.

Misurare la latenza dell'utente

Dopo aver stabilito una base di riferimento per i requisiti di latenza, esamina la tua base di utenti per decidere il posizionamento migliore delle risorse Google Cloud. A seconda che si tratti di un'app nuova o esistente, esistono diverse strategie da adottare.

Utilizza le seguenti strategie per misurare la latenza per i partner a cui accedi durante la pubblicazione dell'app o per misurare la latenza per la tua rete on-premise che potrebbe essere interconnessa al tuo progetto Google Cloud utilizzando Cloud VPN o Dedicated Interconnect.

Stima la latenza per i nuovi workload

Se non hai un'app esistente con una base utenti simile alla tua nuova app, stima la latenza da varie regioni Google Cloud in base alla distribuzione approssimativa della località della tua base utenti prevista.

Stimare 1 ms di latenza di andata e ritorno per ogni 100 km percorsi. Poiché le reti non seguono un percorso ideale dalla sorgente alla destinazione, in genere puoi supporre che la distanza effettiva sia circa 1,5-2 volte la distanza misurata su una mappa. Naturalmente, in alcune regioni meno densamente popolate, le reti potrebbero seguire un percorso ancora meno ideale. La latenza aggiunta tramite le apparecchiature attive all'interno delle reti degli ISP è solitamente trascurabile se si considerano distanze tra regioni.

Questi numeri possono aiutarti a stimare la latenza per i nodi POP di edge e Cloud CDN, nonché per le regioni Compute Engine in tutto il mondo, come elencato nella mappa di rete.

Misurare la latenza per gli utenti esistenti

Se hai già un'app con una base utenti simile, esistono diversi strumenti che puoi utilizzare per stimare meglio le latenze.

  • Utenti rappresentativi: se hai utenti o partner che rappresentano una sezione trasversale delle tue distribuzioni geografiche e che sono disposti a collaborare con te o dipendenti in questi paesi, chiedi loro di misurare la latenza per le varie regioni di Google Cloud. Siti web di terze parti come Google Cloud ping possono aiutarti a ottenere alcune misurazioni.
  • Log degli accessi: se hai un'app attiva ospitata al di fuori di Google Cloud, utilizza i dati dei log degli accessi per ottenere una panoramica approssimativa degli utenti. I log potrebbero fornire informazioni su paesi o città, che ti consentono anche di stimare le latenze.
  • Indirizzo IP: se hai accesso agli indirizzi IP dei tuoi utenti, crea script per testare la raggiungibilità e le latenze da varie regioni Google Cloud. Se il firewall blocca i tuoi controlli, prova a randomizzare l'ultimo ottetto IP per ricevere una risposta da un altro dispositivo con una latenza simile alla tua app.

  • Informazioni sulla latenza di Google Cloud: se hai già un'app in Google Cloud, esistono diversi modi per raccogliere informazioni sulla latenza.

Connettività globale

Quando stimerai la latenza, tieni presente la topologia della rete globale di Google.

  • POP: punti in cui il traffico degli utenti entra nella rete.
  • Nodi Cloud CDN: dove viene memorizzato nella cache il traffico.
  • Regioni: indica dove possono trovarsi le risorse.
  • Connettività: tra i PoP e le regioni.

Puoi trovare un elenco delle località in cui Google si interconnette con altri ISP in PeeringDB.

Assicurati di prendere in considerazione la topologia interregionale quando decidi in quali regioni eseguire il deployment. Ad esempio, se vuoi implementare un'app con una base utenti globale in un'unica regione, in genere è meglio ospitarla in una delle regioni degli Stati Uniti, perché gli Stati Uniti sono collegati alla maggior parte delle altre regioni. Sebbene esista una connettività diretta tra molti continenti, in alcuni casi non è presente, ad esempio tra Europa e Asia, quindi il traffico tra Europa e Asia passa per gli Stati Uniti.

Se la tua app è ospitata in più regioni e devi sincronizzare i dati, tieni presente la latenza tra queste regioni. Sebbene questa latenza possa cambiare nel tempo, in genere è stabile. Misura la latenza autonomamente avviando istanze di test in tutte le potenziali regioni oppure utilizza siti web di terze parti per farti un'idea delle latenze attuali tra le regioni.

Riassumendo

Ora che hai preso in considerazione i requisiti di latenza, i potenziali modelli di implementazione e la distribuzione geografica della tua base utenti, sai in che modo questi fattori influiscono sulla latenza in determinate regioni. È arrivato il momento di decidere in quali regioni lanciare la tua app.

Anche se non esiste un modo giusto per valutare i diversi fattori, la seguente metodologia passo passo potrebbe aiutarti a decidere:

  1. Verifica se esistono fattori non correlati alla latenza che ti impediscono di eseguire il deployment in regioni specifiche, ad esempio il prezzo o il colocation. Rimuovile dall'elenco delle regioni.
  2. Scegli un modello di implementazione in base ai requisiti di latenza e all'architettura generale dell'app. Per la maggior parte delle app mobile e di altro tipo con latenza non critica, un'implementazione in una singola regione con la pubblicazione di contenuti cacheabili tramite Cloud CDN e la terminazione SSL all'edge potrebbe essere la scelta ottimale.

  3. In base al modello di implementazione, scegli le regioni in base alla distribuzione geografica della tua base utenti e alle misurazioni della latenza:

    • Per un deployment in una singola regione:

      • Se hai bisogno di accedere alle sedi aziendali con bassa latenza, esegui il deployment nella regione più vicina a questa località.
      • Se i tuoi utenti provengono principalmente da un paese o una regione, esegui il deployment in una regione più vicina ai tuoi utenti rappresentativi.
      • Per una base utenti globale, esegui il deployment in una regione degli Stati Uniti.

    • Per un deployment multiregione:

      • Scegli le regioni vicine ai tuoi utenti in base alla loro distribuzione geografica e al requisito di latenza dell'app. A seconda dell'app, esegui l'ottimizzazione in base a una latenza mediana specifica o assicurati che il 95-99% degli utenti riceva una latenza target specifica. Gli utenti in determinate località geografiche spesso hanno una tolleranza più elevata alla latenza a causa delle limitazioni dell'infrastruttura.

  4. Se la latenza degli utenti è simile in più regioni, il prezzo potrebbe essere il fattore decisivo.

Quando selezioni le regioni Compute Engine, la latenza è uno dei fattori più importanti da prendere in considerazione. Valuta e misura i requisiti di latenza per offrire un'esperienza utente di qualità e ripeti la procedura se la distribuzione geografica della tua base utenti cambia.

Passaggi successivi