Panoramica di Cloud CDN

Cloud CDN (Content Delivery Network) utilizza la rete perimetrale globale di Google per distribuire i contenuti nelle aree più vicine agli utenti al fine di velocizzare i siti web e le applicazioni.

Cloud CDN utilizza il bilanciatore del carico HTTP(S) esterno globale o il bilanciatore del carico HTTP(S) esterno classico (classico) per fornire contenuti agli utenti. Il bilanciatore del carico HTTP(S) esterno fornisce indirizzi e porte IP frontend che ricevono le richieste e i backend che rispondono alle richieste.

I contenuti di Cloud CDN possono essere derivati da vari tipi di backend:

In Cloud CDN, questi backend sono chiamati anche server di origine. La figura seguente illustra come le risposte dai server di origine in esecuzione su istanze VM passano attraverso un bilanciatore del carico HTTP(S) prima di essere consegnate da Cloud CDN.

Le risposte passano dai server di origine attraverso Cloud CDN ai client
Flusso di risposta di Cloud CDN

Come funziona Cloud CDN

Quando un utente richiede contenuti da un bilanciatore del carico HTTP(S) esterno, la richiesta arriva a un Google Front End (GFE), che si trova sul perimetro della rete di Google, il più vicino possibile all'utente.

Se la mappa URL del bilanciatore del carico indirizza il traffico a un servizio di backend o a un bucket di backend in cui è configurato Cloud CDN, il GFE utilizza Cloud CDN.

Hit della cache e fallimenti della cache

La cache è un gruppo di server che archivia e gestisce i contenuti, in modo da poter gestire più rapidamente le richieste future. I contenuti memorizzati nella cache sono una copia dei contenuti memorizzabili nella cache che vengono archiviati sui server di origine.

Se il GFE cerca nella cache di Cloud CDN e trova una risposta memorizzata nella cache alla richiesta dell'utente, GFE invia la risposta memorizzata nella cache all'utente. chiamato hit da cache. Quando si verifica un hit della cache, il GFE cerca i contenuti in base alla sua chiave cache e risponde direttamente all'utente, riducendo il tempo di round trip e salvando il server di origine dal dover elaborare la richiesta.

Un hit parziale si verifica quando una richiesta viene pubblicata parzialmente dalla cache e in parte da un backend. Questo può accadere se solo una parte dei contenuti richiesti è archiviata in una cache di Cloud CDN, come descritto in Supporto per le richieste di intervalli di byte.

La prima volta che viene richiesto un contenuto, il GFE stabilisce che non può soddisfare la richiesta dalla cache. denominato mancata cache. Quando si verifica un errore di cache, il GFE inoltra la richiesta al bilanciatore del carico HTTP(S) esterno. Il bilanciatore del carico inoltra la richiesta a uno dei tuoi server di origine. Quando la cache riceve i contenuti, il GFE li inoltra all'utente.

Se la risposta del server di origine a questa richiesta è memorizzabile nella cache, Cloud CDN archivia la risposta nella cache di Cloud CDN per le richieste future. Il trasferimento di dati da una cache a un client è chiamato in uscita dalla cache. Il trasferimento di dati a una cache è chiamato riempimento della cache.

La figura seguente mostra un hit e un errore della cache:

  1. I server di origine in esecuzione su istanze VM inviano risposte HTTP(S).
  2. Il bilanciatore del carico HTTP(S) esterno distribuisce le risposte a Cloud CDN.
  3. Cloud CDN fornisce le risposte agli utenti finali.
La risposta iniziale viene fornita dal server di origine mentre le risposte successive vengono pubblicate dal GFE dalla cache.
hit e errori della cache

Per i costi relativi agli hit e ai fallimenti della cache, consulta la sezione Prezzi.

Nessun reindirizzamento URL

Cloud CDN non esegue alcun reindirizzamento URL. La cache di Cloud CDN si trova all'interno del GFE. Ciò significa che:

  • Indipendentemente dal fatto che Cloud CDN sia abilitato, l'URL richiesto da un client rimane lo stesso.
  • Indipendentemente dal fatto che esista o meno un hit della cache, l'URL rimane lo stesso URL.

Percentuale successi cache

Il rapporto sugli hit della cache è la percentuale di volte in cui un oggetto richiesto viene pubblicato dalla cache. Se il rapporto di successo della cache è pari al 60%, significa che l'oggetto richiesto viene pubblicato dalla cache per il 60% delle volte e deve essere recuperato dall'origine il 40% delle volte.

Per informazioni su come le chiavi cache possono influire sul rapporto hit della cache, consulta la sezione Utilizzare le chiavi cache. Per informazioni sulla risoluzione dei problemi, consulta la sezione Il rapporto cache corrispondenze è basso.

Visualizzare il rapporto sugli hit della cache per un periodo di tempo ridotto

Per visualizzare il rapporto sugli hit della cache per un periodo di tempo ridotto (ultimi minuti):

  1. In Google Cloud Console, vai alla pagina Cloud CDN.

    Vai a Cloud CDN

  2. Per ogni origine, consulta la colonna Rapporto sugli hit della cache.

    n/d indica che i contenuti con bilanciamento del carico non sono attualmente memorizzati nella cache o non sono stati richiesti di recente.

Visualizzare il rapporto hit della cache per un periodo di tempo più lungo

Per visualizzare il rapporto sugli hit della cache per un periodo di tempo compreso tra 1 ora e 30 giorni:

  1. In Google Cloud Console, vai alla pagina Cloud CDN.

    Vai a Cloud CDN

  2. Nella colonna Bilanciatori del carico associati, fai clic sul nome del bilanciatore del carico.
  3. Fai clic sulla scheda Monitoraggio.
  4. Seleziona un backend specifico.
  5. Seleziona un periodo di tempo.
  6. Se il rapporto di hit non è n/d, nella parte inferiore della scheda Monitoraggio viene visualizzato un rapporto di hit dalla cache.

Inserimento di contenuti nella cache

La memorizzazione nella cache è reattiva, in quanto un oggetto viene memorizzato in una determinata cache se una richiesta passa attraverso la cache e se la risposta è memorizzabile nella cache. Un oggetto archiviato in una cache non viene replicato automaticamente in altre cache; il riempimento della cache avviene solo in risposta a una richiesta avviata dal client. Non puoi precaricare le cache, ma le singole cache non rispondono alle richieste.

Quando il server di origine supporta le richieste di intervalli di byte, Cloud CDN può avviare più richieste di riempimento della cache in reazione a una singola richiesta client.

Pubblicazione di contenuti da una cache

Dopo aver abilitato Cloud CDN, la memorizzazione nella cache avviene automaticamente per tutti i contenuti memorizzabili nella cache. Il server di origine utilizza intestazioni HTTP per indicare quali risposte sono memorizzate nella cache. Puoi anche controllare la memorizzazione nella cache utilizzando le modalità cache.

Quando utilizzi un bucket di backend, il server di origine è Cloud Storage. Quando utilizzi le istanze VM, il server di origine è il software server web che esegui su tali istanze.

Cloud CDN utilizza le cache in diverse località in tutto il mondo. A causa della natura delle cache, è impossibile prevedere se una particolare richiesta viene gestita fuori da una cache. Tuttavia, puoi aspettarti che le richieste più frequenti per i contenuti memorizzabili nella cache vengano pubblicate la maggior parte del tempo nella cache, con conseguente riduzione delle latenze, costi ridotti e carico ridotto sui server di origine.

Per ulteriori informazioni sugli elementi memorizzati nella cache di Cloud CDN e per quanto tempo, consulta la Panoramica sulla memorizzazione nella cache.

Per vedere che Cloud CDN sta pubblicando da una cache, puoi visualizzare i log.

Rimozione di contenuti dalla cache

Per rimuovere un elemento da una cache, puoi invalidare i contenuti memorizzati nella cache. Per ulteriori informazioni, consulta:

Ignora cache

Per ignorare Cloud CDN, puoi richiedere un oggetto direttamente da un bucket Cloud Storage o da una VM Compute Engine. Ad esempio, un URL per un oggetto bucket Cloud Storage ha il seguente aspetto:

https://storage.googleapis.com/STORAGE_BUCKET/FILENAME

Rimozione e scadenza

Per pubblicare i contenuti da una cache, i contenuti devono essere stati inseriti nella cache, non devono essere eliminati e non devono essere scaduti.

Evizione e scadenza sono due concetti diversi. Entrambi influiscono sui contenuti pubblicati, ma non sussistono direttamente.

Rimozione

Se stai testando la memorizzazione nella cache di contenuti con un numero limitato di richieste, potresti notare che i contenuti vengono rimossi.

Ogni cache ha un limite di quanto può contenere. Tuttavia, Cloud CDN aggiunge contenuti alla cache anche dopo che sono stati completamente caricati. Per inserire contenuti in una cache completa, la cache rimuove prima un altro elemento per liberare spazio. Si parla in questo caso di rimozione. Le cache di solito sono piene, quindi eliminano continuamente i contenuti. In genere vengono rimossi i contenuti a cui non è stato eseguito l'accesso di recente, indipendentemente dalla data di scadenza dei contenuti. I contenuti rimossi potrebbero essere scaduti e potrebbero non esserlo. L'impostazione di una data di scadenza non influisce sulla rimozione.

Contenuti impopolari indica i contenuti che non sono stati accessibili da un po' di tempo. A while e unpopular sono entrambi relativi alla maggior parte degli altri elementi nella cache. Più progetti Google Cloud condividono un pool comune di spazi di cache perché i progetti sono gestiti dallo stesso set di GFE. La popolarità relativa dei contenuti viene confrontata tra più progetti, non solo all'interno di un singolo progetto.

Poiché le cache ricevono più traffico, eliminano anche più contenuti memorizzati nella cache.

Come per tutte le cache su larga scala, i contenuti possono essere eliminati in modo imprevisto, quindi non è garantita la pubblicazione di una richiesta specifica dalla cache.

Scadenza

I contenuti delle cache HTTP(S) possono avere una data di scadenza configurabile. La data di scadenza indica alla cache di non pubblicare contenuti precedenti, anche se i contenuti non sono stati rimossi.

Ad esempio, considera un URL immagine dell'ora. Le relative risposte dovrebbero essere impostate in modo che scadano in meno di un'ora. In caso contrario, i contenuti pubblicati potrebbero essere una vecchia immagine di una cache.

Per informazioni sui tempi di scadenza per l'ottimizzazione, consulta la pagina relativa all'utilizzo delle impostazioni e degli override TTL.

Richieste avviate da Cloud CDN

Quando il tuo server di origine supporta le richieste di intervalli di byte, Cloud CDN può inviare più richieste al server di origine in reazione a una singola richiesta del client. Come descritto nella sezione Supporto per le richieste di intervalli di byte, Cloud CDN può avviare due tipi di richieste: richieste di convalida e richieste di intervalli di byte.

Impostazioni della località dei dati di altri servizi Cloud Platform

Utilizzando Cloud CDN, i dati possono essere archiviati in località di servizio all'esterno dell'area geografica o della zona del server di origine. È normale e come funziona la memorizzazione nella cache HTTP su Internet. In base ai Termini specifici di servizio dei Termini di servizio di Google Cloud Platform, l'impostazione relativa alla località dei dati disponibile per alcuni servizi di Cloud Platform non si applica ai dati dei clienti principali per il servizio Cloud Platform corrispondente, se utilizzato con altri prodotti e servizi Google (in questo caso, il servizio Cloud CDN). Se non vuoi ottenere questo risultato, non utilizzare il servizio Cloud CDN.

Supporto per i certificati SSL gestiti da Google

Puoi utilizzare i certificati gestiti da Google quando Cloud CDN è abilitato.

Google Cloud Armor con Cloud CDN

Google Cloud Armor con Cloud CDN prevede due tipi di criteri di sicurezza:

  • Criteri di sicurezza sul bordo. Questi criteri possono essere applicati ai server di origine abilitati per Cloud CDN. Vengono applicate a tutto il traffico, prima della ricerca CDN.
  • Criteri di sicurezza di backend. Questi criteri vengono applicati soltanto per le richieste di contenuti dinamici, i fallimenti della cache o altre richieste destinate al tuo server di origine.

Per ulteriori informazioni, consulta la documentazione di Google Cloud Armor.

Passaggi successivi