Best practice per la selezione delle regioni di Compute Engine

Questo articolo descrive i criteri da considerare nella scelta delle aree geografiche di Google Cloud da utilizzare per le risorse Compute Engine, una decisione che in genere viene presa dai Cloud Architect o dal management engineering. Questo documento si concentra principalmente sull'aspetto della latenza del processo di selezione ed è destinato alle app a cui accedono i consumatori, come app mobile, web o giochi, ma molti dei concetti possono essere applicati ad altri casi d'uso.

Google offre più regioni in tutto il mondo per il deployment delle risorse Compute Engine. Diversi fattori sono coinvolti nella scelta delle regioni:

  • Limitazioni specifiche per regione
  • Latenza utente per regione
  • Requisiti di latenza dell'app
  • Livello 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, di solito almeno tre.
zona
Un'area di deployment per le risorse Google Cloud all'interno di una regione. L'inserimento delle risorse in zone diverse di una regione riduce il rischio di un'interruzione dell'infrastruttura che colpisce tutte le risorse contemporaneamente.
Risorse Compute Engine
Il deployment delle risorse in Compute Engine, ad esempio le istanze di macchine virtuali, viene eseguito in una zona all'interno di una regione. Altri prodotti, come Google Kubernetes Engine e Dataflow, utilizzano le risorse di Compute Engine, pertanto possono essere sottoposti a deployment nelle stesse regioni o zone.
tempo di round trip (RTT)
Il tempo necessario per inviare un pacchetto IP e per ricevere la conferma.

Quando scegliere le regioni di Compute Engine

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

  • L'architettura della tua app potrebbe cambiare se sincronizzi alcuni dati tra le copie perché gli stessi utenti possono connettersi attraverso regioni diverse in momenti diversi.
  • Il prezzo varia in base alla regione.
  • Il processo di spostamento di un'app e dei relativi dati tra regioni è ingombrante e, a volte costoso, quindi dovrebbe essere evitato una volta che l'app è attiva.

Fattori da considerare durante la selezione delle regioni

È comune che gli utenti eseguano il deployment in una regione in cui si trovano, ma non valutano se questa sia la migliore esperienza utente. Supponiamo che ti trovi in Europa con una base utenti globale e voglia eseguire il deployment in un'unica regione. La maggior parte delle persone prende in considerazione il deployment in una regione europea, ma di solito è la scelta migliore per ospitare questa app in una delle regioni degli Stati Uniti, perché gli Stati Uniti sono la più connessa ad altre regioni.

Sono diversi i fattori che influiscono su dove decidi di eseguire il deployment dell'app.

Latenza

Il fattore principale da considerare è la latenza delle esperienze utente. Tuttavia, questo è 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 verso i sistemi on-premise o per un determinato sottoinsieme di utenti o partner è più critica. Ad esempio, il fattore decisivo potrebbe essere la scelta dell'area geografica più vicina ai tuoi sviluppatori o ai servizi di database on-premise interconnessi con Google Cloud.

Prezzi

I costi delle risorse Google Cloud variano in base alla regione. Per una stima del 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 regioni.

Colocation con altri servizi Google Cloud

Sposta le tue risorse Compute Engine insieme ad altri servizi Google Cloud, ove possibile. 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 tutti i tipi di piattaforma e di macchina della CPU sono disponibili in ogni regione. La disponibilità di piattaforme CPU specifiche o di tipi di istanza specifici varia in base alla regione e alla zona. Se vuoi eseguire il deployment di risorse utilizzando determinati tipi di macchine, scopri di più sulla disponibilità a livello di zona di queste risorse.

Quote delle risorse

La tua capacità di eseguire il deployment delle risorse Compute Engine è limitata dalle quote delle risorse a livello di regione, quindi assicurati di richiedere una quota sufficiente per le regioni in cui prevedi di eseguire il deployment. Se stai pianificando un'implementazione di dimensioni particolarmente voluminose, collabora con il team di vendita per discutere delle opzioni di selezione della regione per assicurarti di disporre di una capacità di quota sufficiente.

Percentuale di energia a zero emissioni di CO2

Per alimentare ogni regione Google Cloud, Google utilizza l'elettricità della rete 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 quella rete e quando Google la consuma. Di recente, Google ha fissato l'obiettivo di un'elettricità a zero emissioni di CO2 che alimenterà le tue applicazioni entro il 2030 nel momento e nei luoghi in cui ne hai bisogno, 24 ore al giorno, in ogni regione Google Cloud.

Fino a quando questo obiettivo non verrà raggiunto, ogni regione Google Cloud sarà alimentata da un mix di fonti di energia a base di carbonio e a zero emissioni di CO2 ogni ora. Questa metrica è chiamata percentuale di energia a zero emissioni di CO2 (% CFE) e pubblichiamo CFE% per le regioni di Google Cloud. Per le nuove applicazioni su Google Cloud, puoi utilizzare questa tabella per iniziare a incorporare l'impatto delle emissioni di carbonio nelle tue decisioni di architettura. La scelta di una regione con una percentuale di CFE più alta significa che, in media, la tua applicazione sarà alimentata con energia a zero emissioni di CO2 per una percentuale maggiore delle ore di funzionamento, riducendo le emissioni lorde di anidride carbonica dell'applicazione.

Valutare i requisiti di latenza

La latenza è spesso un fattore chiave per la selezione della regione, perché un'elevata latenza degli utenti può portare a un'esperienza utente inferiore. Puoi influire su alcuni aspetti della latenza, ma alcuni non sono sotto il tuo controllo.

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

Valuta la latenza nella selezione della regione di Compute Engine

In qualità di architetto delle app, puoi ottimizzare la selezione della regione e la latenza delle app, ma non hai alcun controllo sull'ultimo miglio e sulla latenza degli utenti fino ai punti di presenza (POP) perimetrali di Google più vicini.

La selezione della regione può influenzare solo la latenza nell'area geografica di Compute Engine e non la latenza complessiva. A seconda del caso d'uso, potrebbe essere solo una piccola parte della latenza complessiva. Ad esempio, se i tuoi utenti usano principalmente le reti cellulari, potrebbe non essere utile cercare di ottimizzare le regioni perché questo influisce raramente sulla latenza totale degli utenti.

Latenza 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 è 1-10 ms sulle reti moderne. Al contrario, le latenze tipiche su una rete mobile 3G sono comprese tra 100 e 500 ms. L'intervallo di latenza per i provider DSL e via cavo è di circa 10-60 ms.

Latenza POP perimetrale e frontend Google

A seconda del modello di deployment, anche la latenza sul perimetro della rete Google è importante. È qui che i prodotti di bilanciamento del carico globale terminano le sessioni TCP e SSL e da cui Cloud CDN fornisce risultati memorizzati nella cache. In base ai contenuti pubblicati, molti round trip potrebbero terminare qui perché solo una parte dei dati deve essere recuperata completamente. Questa latenza potrebbe essere notevolmente superiore se utilizzi il livello di servizio di rete standard.

Latenza regione di Compute Engine

La richiesta dell'utente entra nella rete Google a livello perimetrale del POP. La regione di Compute Engine è quella in cui si trovano le risorse Google Cloud che gestiscono le richieste. Questo segmento rappresenta la latenza tra la regione POP perimetrale e Compute Engine e si trova interamente all'interno della rete globale di Google.

Latenza app

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

App diverse hanno requisiti di latenza diversi. A seconda dell'app, gli utenti sono più propensi a risolvere i problemi di latenza. App che interagiscono in modo asincrono o app mobile con una soglia di latenza elevata (almeno 100 millisecondi) possono essere implementate in una singola regione senza compromettere l'esperienza utente. Tuttavia, pochi millisecondi di latenza per app come i giochi in tempo reale 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 deployment influiscono sui fattori di latenza.

Deployment a regione singola

L'immagine seguente illustra il deployment di un'unica regione.

Latenza del deployment singolo frontend

Anche se la tua app serve una base utenti globale, in molti casi una singola regione è comunque la scelta migliore. I vantaggi in termini di latenza inferiore potrebbero non superare la complessità aggiuntiva del deployment in più regioni. Anche con il deployment di una singola regione, puoi comunque utilizzare ottimizzazioni come Cloud CDN e 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 questa operazione non influisce sul percorso di pubblicazione dell'app e, di conseguenza, non influirà sulla latenza dell'utente.

Frontend distribuito in più regioni e backend in un'unica regione

Il seguente diagramma mostra un modello di deployment in cui distribuisci il frontend in più regioni, ma limiti il backend 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 deployment fornisce una bassa latenza dell'utente in scenari in cui la richiesta media dell'utente non prevede richieste di dati o prevede solo alcune richieste di dati al backend centrale prima che l'app possa produrre un risultato. Un esempio è un'app che esegue il deployment di un livello di memorizzazione nella cache intelligente sul frontend o che gestisce le scritture di dati in modo asincrono. Un'app che effettua molte richieste che richiedono un round trip completo al backend potrebbe non trarre vantaggio da questo modello.

Frontend e backend distribuiti in più regioni

Un modello di deployment in cui distribuisci il frontend e il backend in più regioni consente di ridurre al minimo la latenza degli utenti 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 di multi-deployment distribuito

Spanner, l'offerta di database gestiti coerenti a livello globale, ha un'opzione multiregionale in tre continenti che, oltre alle repliche di lettura e scrittura negli Stati Uniti, si trovano in Europa e Asia. Questa opzione fornisce accesso in lettura a bassa latenza ai dati per calcolare le istanze situate negli Stati Uniti, in Europa o in Asia. Se il servizio è destinato agli Stati Uniti, esiste anche un'opzione per più regioni con replica all'interno degli Stati Uniti.

Se decidi di eseguire il tuo servizio di database su Compute Engine, sarai tu a rispondere ai dati. Questa replica è un compito significativo perché è difficile mantenere i dati costantemente sincronizzati a livello globale. È 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 ti consigliamo di rivolgerti a un partner solido con esperienza in quest'area, ad esempio Datastax per la replica Cassandra.

Più app in parallelo

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

Latenza di app parallele

Ad esempio, quando gestisci un'attività di vendita al dettaglio, potresti servire gli utenti di diverse regioni tramite domini di paesi diversi e gestire siti paralleli in tutte quelle regioni, sincronizzando i dati di prodotto e utente solo quando necessario. I siti locali mantengono il proprio inventario locale e gli utenti si connettono a un sito ospitato localmente selezionando il dominio di un paese. Quando un utente visita il dominio di un altro paese, viene reindirizzato al dominio corretto.

Un altro esempio è nei giochi in tempo reale. Potresti avere solo un servizio di hall globale in cui gli utenti scelgono una sala giochi o un mondo vicino alla propria posizione in cui le stanze o i mondi non condividono i dati tra loro.

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

Ottimizza la latenza tra utenti e regioni

Indipendentemente dal modello di deployment, puoi combinare 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 la tua app.

Utilizza il networking del livello Premium

Google offre Network Service Tiers premium (predefiniti) e standard. Il traffico del livello Standard viene distribuito tramite ISP in transito dalle regioni di Google Cloud, mentre il livello Premium offre una latenza inferiore fornendo il traffico attraverso la rete privata globale di Google. Il networking del livello Premium riduce la latenza degli utenti e dovrebbe essere utilizzato per tutte le parti dell'app nel percorso di pubblicazione. Il networking del livello Premium è necessario anche per utilizzare i prodotti di bilanciamento del carico globale di Google.

Utilizza Cloud Load Balancing e Cloud CDN

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

Anche se la tua app si trova in una sola regione, l'utilizzo di Cloud Load Balancing garantisce comunque una latenza inferiore agli utenti perché le sessioni TCP e SSL vengono terminate sul perimetro della rete. Termina facilmente il traffico degli utenti con le connessioni HTTP/2 e QUIC (Rapid UDP Internet Connections). Puoi inoltre integrare Cloud CDN con il bilanciamento del carico HTTP(S) per distribuire asset statici direttamente dal perimetro della rete, riducendo ulteriormente la latenza degli utenti.

Memorizzazione nella cache in locale

Quando le località del frontend sono diverse da quelle del backend, assicurati di memorizzare nella cache le risposte dei servizi di backend, ove possibile. Quando il frontend e il backend si trovano nella stessa regione, la latenza delle app si riduce perché si riducono anche le query dispendiose in termini di tempo. Memorystore for Redis è un datastore in memoria completamente gestito che puoi utilizzare.

Ottimizza il client dell'app o il frontend web

Puoi utilizzare tecniche sul lato client, che si tratti di un'app mobile o del frontend web, per ottimizzare la latenza degli utenti. Ad esempio, precarica alcuni asset o memorizza nella cache i dati dell'app.

Puoi anche ottimizzare il modo in cui l'app recupera le informazioni riducendo il numero di richieste e recuperando le informazioni in parallelo, ove possibile.

Misurare la latenza degli utenti

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

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

Stimare la latenza per i nuovi carichi di lavoro

Se non hai un'app esistente con una base utenti simile a quella della tua nuova app, stima la latenza da varie regioni di Google Cloud in base alla distribuzione approssimativa delle 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 dall'origine alla destinazione, in genere puoi indovinare che la distanza effettiva sia circa 1,5 o 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 apparecchiature attive all'interno delle reti ISP è generalmente trascurabile se si considerano le distanze tra regioni.

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

Misura la latenza per gli utenti esistenti

Se hai già un'app con una base utenti simile, hai a disposizione diversi strumenti 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 lavorare con te o con dipendenti nei paesi in questione, chiedi loro di misurare la latenza su varie regioni Google Cloud. I siti web di terze parti, come il ping di Google Cloud, 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 sezione approssimativa degli utenti. I log potrebbero fornire informazioni su paese o città, che consentono anche di stimare le latenze.
  • Indirizzo IP: se hai accesso agli indirizzi IP degli utenti, crea script per testare la connettività e le latenze da diverse aree geografiche di Google Cloud. Se il firewall blocca i probe, prova a randomizzare l'ultimo ottetto IP per ottenere una risposta da un altro dispositivo con latenza simile a quella della tua app.

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

Connettività globale

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

  • POP: dove il traffico degli utenti entra nella rete.
  • Nodi Cloud CDN: dove il traffico viene memorizzato nella cache.
  • Regioni: dove si trovano le risorse.
  • Connettività: tra POP e regioni.

Consulta un elenco di 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 eseguire il deployment di un'app con una base utenti globale in una singola regione, in genere è preferibile che l'app sia ospitata in una delle regioni degli Stati Uniti, perché gli Stati Uniti sono connessi alla maggior parte delle altre regioni. Sebbene esista una connettività diretta tra molti continenti, ci sono casi in cui manca, ad esempio, tra Europa e Asia, quindi il traffico tra l'Europa e l'Asia passa attraverso gli Stati Uniti.

Se la tua app è ospitata in più regioni e devi sincronizzare i dati, presta attenzione alla latenza tra queste regioni. Anche se questa latenza può cambiare nel tempo, di solito è stabile. Puoi misurare autonomamente la latenza attivando le istanze di test in tutte le potenziali regioni o utilizzare siti web di terze parti per avere un'idea delle latenze attuali tra le regioni.

Organizzazione dei risultati in corso...

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

Sebbene non esista un modo corretto per valutare i diversi fattori, la seguente metodologia passo passo potrebbe aiutarti a decidere:

  1. Controlla se sono presenti fattori correlati alla non latenza che ti impediscono di eseguire il deployment in regioni specifiche, come prezzo o colocation. Rimuovile dall'elenco delle regioni.
  2. Scegli un modello di deployment in base ai requisiti di latenza e all'architettura generale dell'app. Per la maggior parte delle app mobile e di altre app critiche per la latenza, un deployment a regione singola con distribuzione di Cloud CDN di contenuti memorizzabili nella cache e terminazione SSL a livello perimetrale potrebbe essere la scelta ottimale.

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

    • Per il deployment di una singola regione:

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

    • Per un deployment su più regioni:

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

  4. Se la latenza per gli utenti è simile in più regioni, il prezzo potrebbe essere il fattore determinante.

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

Passaggi successivi