Best practice per i workload multimediali

Questa pagina descrive le best practice per l'utilizzo di Cloud Storage per i carichi di lavoro multimediali. Questi carichi di lavoro spesso includono vari prodotti Google Cloud come Media CDN, API Live Stream, API Transcoder e API Video Stitcher.

Panoramica

Google Cloud offre soluzioni per ottimizzare i seguenti tipi di carichi di lavoro multimediali:

  • Produzione multimediale: include carichi di lavoro come la post-produzione di film, incluso il montaggio video, che richiedono molte risorse di calcolo e spesso utilizzano le GPU per l'elaborazione ad alte prestazioni. Spesso, i dati correlati ai contenuti multimediali presenti in Cloud Storage vengono elaborati da applicazioni in esecuzione in Compute Engine o Google Kubernetes Engine e l'output di questo processo viene riscritto in Cloud Storage. Questi carichi di lavoro richiedono di scalare la velocità effettiva di lettura e scrittura aggregata da Cloud Storage a un cluster di calcolo con un tempo di inattività della GPU inferiore. Inoltre, richiedono latenze di lettura e scrittura basse, in quanto sono fondamentali per ridurre la latenza di coda.
  • Gestione degli asset multimediali: include l'organizzazione degli asset multimediali per un'archiviazione, un recupero e un utilizzo efficienti.
  • Pubblicazione e distribuzione di contenuti: include lo streaming di contenuti multimediali agli utenti, inclusi i servizi di video on demand (VOD) e live streaming. Durante la VOD, quando gli utenti richiedono contenuti che non sono memorizzati nella cache della rete di distribuzione dei contenuti (CDN), i contenuti vengono recuperati dai bucket Cloud Storage. Per le richieste di live streaming, i contenuti vengono scritti nel bucket Storage e letti dalla CDN contemporaneamente.

Best practice per i carichi di lavoro multimediali

Per le best practice applicabili ai carichi di lavoro multimediali, consulta le sezioni seguenti.

Trasferimento di dati

Utilizza Storage Transfer Service per caricare più di 1 TiB di file multimediali non elaborati da un'origine on-premise, ad esempio una videocamera o un archivio on-premise, a Cloud Storage. Storage Transfer Service consente lo spostamento dei dati senza problemi tra i sistemi di archiviazione di oggetti e file. Per i trasferimenti più piccoli, scegli il servizio per trasferire dati da e verso Cloud Storage o tra file system in base allo scenario di trasferimento.

Località bucket

Per i carichi di lavoro che richiedono risorse di calcolo come la produzione multimediale, devi creare bucket nella stessa regione o in due regioni delle risorse di calcolo. Questo metodo consente di ottimizzare le prestazioni riducendo le latenze di lettura e scrittura per i carichi di lavoro di elaborazione, i costi e la larghezza di banda. Per ulteriori indicazioni sulla scelta della località del bucket, consulta Considerazioni sulla località del bucket.

Classe di archiviazione

A seconda del tipo di carico di lavoro multimediale, la classe di archiviazione da selezionare varia. I tipi di classe di archiviazione consigliati per diversi carichi di lavoro multimediali sono i seguenti:

  • Per la gestione delle risorse multimediali, come i video di archivio, la classe di archiviazione predefinita di un bucket deve essere Archive Storage. Puoi specificare una classe di archiviazione diversa per gli oggetti che hanno esigenze di disponibilità o accesso diverse.
  • Per i carichi di lavoro di produzione multimediale e pubblicazione di contenuti, poiché i dati vengono letti di frequente da un bucket Cloud Storage, devi archiviarli in Standard Storage.

Per ulteriori indicazioni sulla scelta della classe di archiviazione per il bucket, consulta Classe di archiviazione.

Gestione del ciclo di vita dei dati

Per gestire le risorse multimediali, devi gestire il ciclo di vita degli oggetti per i tuoi bucket definendo una configurazione del ciclo di vita. Con la funzionalità Gestione del ciclo di vita degli oggetti, puoi gestire il ciclo di vita dei dati, inclusa l'impostazione di una durata (TTL) per gli oggetti, la conservazione delle versioni non correnti degli oggetti e il downgrade delle classi di archiviazione degli oggetti per aiutarti a gestire i costi.

Quando i modelli di accesso ai dati sono prevedibili, puoi impostare la configurazione del ciclo di vita per un bucket. Per pattern di accesso sconosciuti o imprevedibili per i tuoi dati, puoi impostare la funzionalità Autoclass per il tuo bucket. Con Autoclass, Cloud Storage sposta automaticamente i dati a cui non si accede di frequente alle classi di archiviazione ad accesso meno frequente.

Best practice per i carichi di lavoro di distribuzione e pubblicazione dei contenuti

Per i carichi di lavoro VOD e di live streaming, l'obiettivo è evitare errori di riproduzione, ritardi nell'avvio della riproduzione o buffering durante la riproduzione di un video nel video player degli utenti finali. Questi carichi di lavoro richiedono anche la scalabilità delle letture per tenere conto di un numero elevato di spettatori simultanei. In tutti i casi, il traffico dei clienti deve passare attraverso una CDN.

Per le best practice applicabili ai carichi di lavoro di distribuzione e pubblicazione dei contenuti, consulta le sezioni seguenti.

Utilizzare la CDN in modo efficace

L'utilizzo di una rete Content Delivery Network (CDN) davanti al bucket Cloud Storage migliora l'esperienza dell'utente finale, in quanto la CDN memorizza nella cache i contenuti riducendo la latenza e aumentando l'efficienza della larghezza di banda. Una CDN ti consente di ridurre il costo totale di proprietà (TCO) diminuendo i costi della larghezza di banda, ottimizzando l'utilizzo delle risorse e migliorando le prestazioni. L'utilizzo di Media CDN contribuisce a ridurre il TCO per la pubblicazione dei contenuti agli utenti finali, in quanto il costo di riempimento della cache per Media CDN è pari a zero. Puoi utilizzare Media CDN come origine di altre CDN di terze parti. Con altre CDN, ottieni comunque una riduzione del TCO quando pubblichi i contenuti da questa cache di Media CDN anziché dall'origine.

Se utilizzi una CDN di terze parti, CDN Interconnect consente a fornitori selezionati di stabilire link di peering diretto con la rete edge di Google in varie località. Il traffico di rete in uscita da Google Cloud tramite uno di questi link beneficia della connettività diretta ai fornitori CDN supportati e viene fatturato automaticamente a prezzi ridotti. Per un elenco dei fornitori approvati, consulta Fornitori di servizi approvati da Google.

Di seguito sono elencate le opzioni da configurare durante la configurazione di una CDN:

Seleziona la posizione della protezione di origine

La posizione di Origin Shield è una cache tra la CDN e Cloud Storage. Se la tua CDN ti consente di selezionare la posizione di Origin Shield, segui le linee guida della CDN per stabilire se è consigliabile scegliere Origin Shield in modo che sia più vicino alla regione del tuo bucket Cloud Storage o alla posizione di concentrazione del traffico degli utenti finali. La protezione origine è una misura protettiva che impedisce il sovraccarico del server di origine. Le CDN con protezione dell'origine contribuiscono ad aumentare il trasferimento dell'origine aggiungendo una cache aggiuntiva tra l'origine e la CDN. Ad esempio, Media CDN fornisce un'infrastruttura perimetrale a più livelli, progettata per ridurre al minimo il riempimento della cache quando possibile.

Attiva l'unione delle richieste

Assicurati che il raggruppamento delle richieste sia abilitato per la tua CDN. Il raggruppamento di più richieste in una singola richiesta riduce il costo dell'operazione di classe B di Cloud Storage. Le CDN hanno cache distribuite in tutto il mondo, ma forniscono un modo per raggruppare più richieste degli utenti finali in un'unica richiesta all'origine. Ad esempio, Media CDN comprime attivamente più richieste di riempimento della cache basate sull'utente per la stessa chiave della cache in un'unica richiesta di origine per nodo perimetrale, riducendo così il numero di richieste effettuate ai bucket.

Configura il comportamento di ripetizione dei tentativi sulla CDN

Assicurati di configurare i nuovi tentativi per eventuali problemi del server con il codice di risposta HTTP 5xx (502, 503, 504) sulla CDN. Le CDN supportano i tentativi di ripetizione dell'origine, consentendo di riprovare le richieste non riuscite all'origine. La maggior parte delle CDN consente di specificare il numero di tentativi per l'origine corrente. Per informazioni sui tentativi ripetuti di richieste di origine in Media CDN, vedi Tentativi ripetuti di richieste di origine.

Opzioni di località per la distribuzione dei contenuti

Per i carichi di lavoro che leggono dati da Cloud Storage non memorizzati nella cache sulla CDN, ad esempio la pubblicazione e la distribuzione di contenuti di tipo VOD, considera i seguenti fattori quando selezioni una località per il bucket:

  • Per ottimizzare i costi, i bucket creati in una singola regione hanno il costo di archiviazione più basso.
  • Per ottimizzare per la disponibilità, considera quanto segue:
    • Per la maggior parte dei carichi di lavoro multimediali, è consigliabile utilizzare bucket dual-region perché replicano gli oggetti in due regioni per una migliore disponibilità.
    • Per i casi d'uso che richiedono la pubblicazione di contenuti e l'analisi con ridondanza geografica, utilizza i bucket in più regioni per la massima disponibilità.
  • Per ottimizzare la latenza e ridurre i costi di rete, valuta quanto segue:
    • Per i contenuti VOD, scegli le regioni più vicine alla maggior parte degli utenti finali o la regione con la maggiore concentrazione di traffico.
    • Durante lo streaming live, i bucket ricevono richieste di scrittura dai transcoder e richieste di lettura da una CDN che memorizza nella cache e distribuisce i contenuti agli utenti finali. Per prestazioni di streaming migliorate, scegli bucket regionali che si trovano nella stessa posizione delle risorse di calcolo utilizzate per la transcodifica.

Ottimizzare la durata dei segmenti video per i live streaming

Per le live streaming, la dimensione minima consigliata del segmento è di due secondi perché i segmenti video brevi sono più sensibili alle latenze di scrittura a coda lunga. Le latenze di scrittura long-tail si riferiscono alle operazioni di scrittura lente o ritardate per i contenuti a cui si accede di rado o che hanno un basso volume di richieste.

La distanza fisica tra la posizione del bucket e la posizione di riproduzione degli utenti finali influisce sul tempo di trasmissione. Se gli utenti finali si trovano lontano dalla posizione del bucket, consigliamo di utilizzare una dimensione del segmento video più lunga.

Per offrire agli spettatori la migliore esperienza, ti consigliamo di utilizzare la strategia di ripetizione e la richiesta di hedging per le scritture sui transcodificatori per ridurre le latenze di coda lunga superiori a due secondi per le scritture su Cloud Storage e di sperimentare tempi di buffer più lunghi di circa dieci secondi.

Aumenta gradualmente il numero di QPS

I bucket Cloud Storage hanno una capacità di I/O iniziale di 1000 scritture di oggetti al secondo e 5000 letture di oggetti al secondo. Per i workload di live streaming, la linea guida è di scalare gradualmente le richieste iniziando con 1000 scritture al secondo e 5000 letture al secondo e raddoppiando in modo incrementale la tasso di richieste ogni 20 minuti. Questo metodo consente a Cloud Storage di ridistribuire il carico su più server e migliora la disponibilità e la latenza del bucket riducendo le probabilità di problemi di riproduzione.

Per un evento in live streaming con QPS più elevato, devi implementare lo scaling sul bucket preparandolo o abilitando lo spazio dei nomi gerarchico. Prima di implementare lo scaling sul bucket, devi eseguire le seguenti operazioni:

Stima le QPS all'origine

Supponiamo che per un live streaming con un milione di spettatori, la CDN riceva un milione di QPS. Supponendo che la tua CDN abbia un tasso di successo della cache del 99%, il traffico risultante verso Cloud Storage sarà dell'1%. Il valore QPS sarà l'1% del totale degli spettatori (un milione), ovvero 10.000 QPS. Questo valore è superiore alla capacità iniziale dell'IO.

Monitora le QPS e risolvi eventuali errori di scalabilità

Devi monitorare le QPS e risolvere eventuali errori di scalabilità. Per maggiori informazioni, consulta la panoramica del monitoraggio in Cloud Storage . Per monitorare le richieste di lettura e scrittura, osserva i grafici Conteggio totale richieste di lettura/elenco/recupero e Conteggio totale richieste di scrittura rispettivamente nella consoleGoogle Cloud . Se aumenti il QPS sui bucket più rapidamente delle linee guida per l'incremento graduale specificate nella sezione precedente, potresti riscontrare l'errore 429 Troppe richieste. Scopri come risolvere l'errore 429 Troppe richieste.

Le sezioni seguenti descrivono come scalare il bucket per un QPS più elevato dopo aver stimato il QPS all'origine.

Implementa lo scaling QPS nel bucket eseguendo il pre-riscaldamento del bucket

Puoi accelerare il processo di scalabilità prima di un evento di live streaming preparando il bucket. Prima dell'evento di live streaming, genera traffico sintetico nel tuo bucket che corrisponda al QPS massimo previsto che riceverà il server di origine della CDN per l'evento, più un buffer aggiuntivo del 50% che tenga conto del tasso di hit della cache previsto della tua CDN. Ad esempio, se hai stimato che le QPS all'origine siano 10.000, il traffico simulato deve avere come target 15.000 richieste al secondo per preparare l'origine all'evento.

Per questo traffico simulato, puoi utilizzare i file del feed live dell'evento precedente, come segmenti e manifest, o i file di test. Assicurati di avere file distinti durante l'intero processo di riscaldamento.

Quando generi questo traffico simulato, segui un approccio di scalabilità graduale, iniziando con 5000 richieste al secondo e aumentando progressivamente fino a raggiungere il tuo obiettivo. Assegna un tempo sufficiente prima dell'evento per raggiungere il carico stimato. Ad esempio, raggiungere 15.000 richieste al secondo, raddoppiando il carico ogni 20 minuti da un valore iniziale di 5000 richieste al secondo, richiederà circa 30 minuti.

Il server di origine mantiene la capacità fino a quando il traffico non è coerente. La capacità del server di origine diminuisce gradualmente fino al livello di base nell'arco di 24 ore. Se il server di origine presenta intervalli di più ore tra gli eventi del live streaming, ti consigliamo di simulare il traffico prima di ogni evento.

Utilizza bucket con spazio dei nomi gerarchico abilitato per un numero elevato di QPS iniziali

I bucket Cloud Storage con lo spazio dei nomi gerarchico abilitato forniscono fino a otto volte le QPS iniziali rispetto ai bucket senza HNS. Il QPS iniziale più elevato semplifica lo scaling dei carichi di lavoro che richiedono un uso intensivo dei dati e fornisce una velocità effettiva migliorata. Per informazioni sulle limitazioni nei bucket con lo spazio dei nomi gerarchico abilitato, vedi Limitazioni.

Evita nomi sequenziali per i segmenti video per scalare le QPS

Con la scalabilità QPS, le richieste vengono ridistribuite su più server. Tuttavia, potresti riscontrare colli di bottiglia delle prestazioni quando tutti gli oggetti utilizzano un prefisso non randomizzato o sequenziale. L'utilizzo di nomi completamente casuali rispetto a nomi sequenziali offre la migliore distribuzione del carico. Tuttavia, se vuoi utilizzare numeri sequenziali o timestamp come parte dei nomi degli oggetti, introduci casualità nei nomi degli oggetti aggiungendo un valore hash prima del numero di sequenza o del timestamp. Ad esempio, se il nome dell'oggetto originale che vuoi utilizzare è my-bucket/2016-05-10-12-00-00/file1, puoi calcolare l'hash MD5 del nome dell'oggetto originale e aggiungere i primi sei caratteri dell'hash come prefisso al nome dell'oggetto. Il nuovo oggetto diventa my-bucket/2fa764-2016-05-10-12-00-00/file1. Per saperne di più, consulta Utilizzare una convenzione di denominazione che distribuisca il carico in modo uniforme tra gli intervalli di chiavi. Se non puoi evitare la denominazione sequenziale per i segmenti video, utilizza bucket con spazio dei nomi gerarchico abilitato per ottenere un QPS più elevato.

Utilizzare bucket diversi per ogni live streaming

Per i live streaming simultanei, l'utilizzo di bucket diversi per ogni live streaming ti aiuterà a scalare il carico di lettura e scrittura in modo efficace senza raggiungere i limiti di I/O per il bucket. L'utilizzo di bucket diversi per ogni live streaming riduce le latenze anomale di grandi dimensioni a causa dei ritardi di scalabilità.

Passaggi successivi