Best practice per i carichi di lavoro 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 Google Cloud prodotti come Media CDN, l'API Live Stream, l'API Transcoder e l'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 un elevato utilizzo di risorse di calcolo e spesso utilizzano le GPU per il computing ad alte prestazioni. Spesso, i dati relativi ai media che risiedono 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 la scalabilità della velocità effettiva di lettura e scrittura aggregata da Cloud Storage a un cluster di calcolo con un tempo di inattività della GPU inferiore. Richiedono anche latenze di lettura e scrittura basse, in quanto è fondamentale ridurre la latenza di coda.
  • Gestione degli asset multimediali: include l'organizzazione degli asset multimediali per un'archiviazione, un recupero e un utilizzo efficienti.
  • Distribuzione e pubblicazione dei contenuti: include lo streaming di contenuti multimediali agli utenti, inclusi i servizi di video on demand (VOD) e live streaming. Durante il VOD, quando gli utenti richiedono contenuti che non sono memorizzati nella cache della rete CDN (Content Delivery Network), 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 uno spazio di archiviazione on-premise, a Cloud Storage. Storage Transfer Service consente di spostare i dati senza problemi tra i sistemi di archiviazione di oggetti e file. Per i trasferimenti più piccoli, scegli il servizio per trasferire i dati da e verso Cloud Storage o tra i file system in base allo scenario di trasferimento.

Posizione segmento

Per i carichi di lavoro che richiedono risorse di calcolo come la produzione multimediale, devi creare bucket nella stessa regione o nelle stesse regioni doppie 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 posizione del bucket, consulta Considerazioni sulla posizione del bucket.

Classe di archiviazione

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

  • Per la gestione degli asset multimediali, ad esempio 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 con esigenze di disponibilità o accesso diverse.
  • Per i carichi di lavoro di produzione multimediale e distribuzione 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 gli asset 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 aiutare a gestire i costi.

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

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

Per i carichi di lavoro VOD e 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, le letture del traffico dei clienti devono 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 CDN (Content Delivery Network) 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) riducendo i costi della larghezza di banda, ottimizzando l'utilizzo delle risorse e migliorando le prestazioni. L'utilizzo di Media CDN consente di ridurre il TCO per la pubblicazione dei contenuti agli utenti finali, poiché il costo di riempimento della cache per Media CDN è 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 ai provider selezionati di stabilire link di peering diretti con la rete edge di Google in varie località. Il traffico di rete in uscita da Google Cloud uno di questi link beneficia della connettività diretta ai provider CDN supportati e viene fatturato automaticamente con prezzi ridotti. Per un elenco dei provider approvati, consulta Provider di servizi approvati da Google.

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

Seleziona la località dello scudo di origine

La località dello scudo di origine è una cache tra la CDN e Cloud Storage. Se la tua CDN ti consente di selezionare la località dello scudo di origine, segui le linee guida della CDN per sapere se è consigliabile scegliere lo scudo di origine più vicino alla regione del bucket Cloud Storage o alla località di concentrazione del traffico degli utenti finali. Uno scudo di origine è una misura di protezione che protegge il server di origine dal sovraccarico. 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 edge a più livelli, progettata per ridurre al minimo il riempimento della cache quando possibile.

Abilita il raggruppamento delle richieste

Assicurati che la compressione delle richieste sia abilitata per la tua CDN. La compressione di più richieste in un'unica 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 comprimere più richieste degli utenti finali in un'unica richiesta all'origine. Ad esempio, Media CDN comprime attivamente più richieste di riempimento della cache guidate dall'utente per la stessa chiave cache in un'unica richiesta di origine per nodo edge, riducendo così il numero di richieste effettuate ai bucket.

Configura il comportamento di ripetizione dei tentativi sulla CDN

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

Opzioni di località per la distribuzione dei contenuti

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

Ottimizzare la durata dei segmenti video per i live streaming

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

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 sono lontani dalla posizione del bucket, ti 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 dei tentativi e la copertura delle richieste per le scritture sui transcodificatori per ridurre le latenze di coda superiori a due secondi per le scritture in Cloud Storage e di sperimentare tempi di buffer più lunghi di circa dieci secondi.

Aumentare gradualmente il valore 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 carichi di lavoro 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 il 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 un valore QPS più elevato, devi implementare la scalabilità sul tuo bucket pre-riscaldando il bucket o abilitando lo spazio dei nomi gerarchico sul bucket. Prima di implementare la scalabilità sul bucket, devi eseguire le seguenti attività:

Stima il valore QPS per l'origine

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

Monitora il valore QPS e risolvi eventuali errori di scalabilità

Devi monitorare il valore QPS e risolvere eventuali errori di scalabilità. Per ulteriori informazioni, consulta Panoramica del monitoraggio in Cloud Storage . Per monitorare le richieste di lettura e scrittura, osserva rispettivamente il grafico Numero totale di richieste di lettura/elenco/recupero e il grafico Numero totale di richieste di scrittura nella Google Cloud console. Se aumenti il valore QPS sui bucket più rapidamente delle linee guida di aumento 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 valore QPS più elevato dopo aver stimato il valore QPS per l'origine.

Implementare la scalabilità QPS sul bucket pre-riscaldando il bucket

Puoi velocizzare il processo di scalabilità prima di un evento in live streaming pre-riscaldando il bucket. Prima dell'evento in live streaming, genera traffico sintetico verso il bucket che corrisponda al valore QPS massimo previsto che il server di origine della CDN riceverà per l'evento, più un buffer aggiuntivo del 50% tenendo conto della percentuale di successo della cache prevista della CDN. Ad esempio, se hai stimato che il valore QPS per l'origine è di 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 pubblicato dell'evento precedente, ad esempio segmenti e manifest, o file di test. Assicurati di avere file distinti durante l'intero processo di pre-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 target. Assegna un tempo sufficiente prima dell'evento per raggiungere il carico stimato. Ad esempio, per raggiungere 15.000 richieste al secondo, raddoppiando il carico ogni 20 minuti da un valore iniziale di 5000 richieste al secondo, ci vogliono 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 in live streaming, ti consigliamo di simulare il traffico prima di ogni evento.

Utilizzare i bucket con lo spazio dei nomi gerarchico abilitato per un valore QPS iniziale elevato

I bucket Cloud Storage con lo spazio dei nomi gerarchico abilitato forniscono un valore QPS iniziale fino a otto volte superiore rispetto ai bucket senza HNS. Il valore QPS iniziale più elevato semplifica la scalabilità dei carichi di lavoro che richiedono un uso intensivo dei dati e offre una velocità effettiva maggiore. Per informazioni sulle limitazioni dei bucket con lo spazio dei nomi gerarchico abilitato, consulta Limitazioni.

Evitare nomi sequenziali per i segmenti video per la scalabilità 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 ai nomi sequenziali offre la migliore distribuzione del carico. Tuttavia, se vuoi utilizzare numeri o timestamp sequenziali come parte dei nomi degli oggetti, introduci la 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 ulteriori informazioni, consulta Utilizzare una convenzione di denominazione che distribuisce il carico in modo uniforme tra gli intervalli di chiavi. Se non puoi evitare la denominazione sequenziale per i segmenti video, utilizza i bucket con lo spazio dei nomi gerarchico abilitato per ottenere un valore 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 in modo efficace il carico di lettura e scrittura senza raggiungere i limiti di I/O per il bucket. L'utilizzo di bucket diversi per ogni live streaming riduce le latenze anomale elevate dovute ai ritardi di scalabilità.

Passaggi successivi