Best practice per i carichi di lavoro multimediali

Cloud Storage ti consente di archiviare e pubblicare asset audio e video ottimizzando le prestazioni di streaming, riducendo al minimo la latenza di riproduzione e gestendo i costi. Per supportare i flussi di lavoro multimediali, puoi integrare Cloud Storage con i prodottiGoogle Cloud come Media CDN, l'API Live Stream, l'API Transcoder e l'API Video Stitcher. Questo documento descrive le best practice per l'utilizzo di Cloud Storage per i workload multimediali.

Panoramica dei workload multimediali

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

  • Produzione multimediale: include workload come la post-produzione di film, tra cui l'editing video, che richiedono un'elevata potenza di calcolo e spesso utilizzano GPU per il computing ad alte prestazioni. Spesso, i dati relativi ai contenuti multimediali 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 workload richiedono la scalabilità della velocità effettiva di lettura e scrittura aggregata da Cloud Storage a un cluster di computing con un tempo di inattività della GPU inferiore. Inoltre, richiedono basse latenze di lettura e scrittura, in quanto ciò è fondamentale 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 i 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 contemporaneamente dalla CDN.

Best practice per i workload multimediali

Per le best practice che si applicano ai workload 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, in Cloud Storage. Storage Transfer Service consente lo spostamento dei dati senza interruzioni tra sistemi di archiviazione di oggetti e file. Per trasferimenti più piccoli, scegli il servizio per trasferire i dati da e verso Cloud Storage o tra file system in base allo scenario di trasferimento.

Località del bucket

Per i workload che richiedono risorse di computing, come la produzione di contenuti multimediali, devi creare bucket nella stessa regione o in due regioni delle risorse di computing. Questo metodo aiuta a ottimizzare le prestazioni riducendo le latenze di lettura e scrittura per i workload 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

La classe di archiviazione da selezionare varia a seconda del tipo di workload multimediale. I tipi di classe di archiviazione consigliati per i diversi workload multimediali sono i seguenti:

  • Per la gestione degli asset 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 con esigenze di disponibilità o accesso diverse.
  • Per i workload 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 tuo bucket, consulta Classe di archiviazione.

Gestione del ciclo di vita dei dati

Per gestire i tuoi 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, tra cui l'impostazione di una durata (TTL) per gli oggetti, la conservazione delle versioni non attuali 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 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 nelle classi di archiviazione ad accesso meno frequente.

Best practice per i workload di distribuzione e pubblicazione dei contenuti

Per i workload di VOD e live streaming, l'obiettivo è evitare errori di riproduzione, ritardi nell'avvio della riproduzione o buffering durante la riproduzione di un video sul video player degli utenti finali. Questi workload 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 che si applicano ai workload di distribuzione e pubblicazione dei contenuti, consulta le sezioni seguenti.

Utilizza 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, poiché la CDN memorizza i contenuti nella cache 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 distribuzione dei contenuti agli utenti finali, poiché 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 i contenuti vengono pubblicati 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 diretto con la rete perimetrale di Google in varie località. Il traffico di rete in uscita da Google Cloudtramite uno di questi link beneficia della connettività diretta ai provider CDN supportati e viene fatturato automaticamente con 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 località di Origin Shield

La località di Origin Shield è una cache tra la CDN e Cloud Storage. Se la tua CDN ti consente di selezionare la località di Origin Shield, segui le linee guida della CDN per capire se è consigliabile scegliere Origin Shield in modo che sia più vicino alla regione del tuo bucket Cloud Storage o alla località di concentrazione del traffico degli utenti finali. Un Origin Shield è una misura di protezione che protegge il server di origine dal sovraccarico. Le CDN con protezione dell'origine contribuiscono ad aumentare l'offload 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.

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 delle operazioni 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 raggruppa 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 dei nuovi 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 tua CDN. Le CDN supportano i nuovi tentativi di origine, consentendo di riprovare le richieste non riuscite all'origine. La maggior parte delle CDN consente di specificare il numero di nuovi tentativi per l'origine corrente. Per informazioni su come riprovare le richieste di origine in Media CDN, consulta Riprova le richieste di origine.

Opzioni di località per la distribuzione dei contenuti

Per i workload che leggono dati da Cloud Storage che non sono memorizzati nella cache della CDN, ad esempio la distribuzione di contenuti di tipo VoD, tieni conto dei 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 la disponibilità, tieni presente quanto segue:
    • Per la maggior parte dei workload multimediali, è consigliabile utilizzare bucket a due regioni perché replicano gli oggetti in due regioni per una migliore disponibilità.
    • Per i casi d'uso che richiedono l'erogazione di contenuti e i dati e analisi con ridondanza geografica, utilizza i bucket multiregione per la massima disponibilità.
  • Per ottimizzare la latenza e ridurre i costi di rete, tieni presente quanto segue:
    • Per i VOD, scegli le regioni più vicine alla maggior parte dei tuoi utenti finali o la regione con la maggiore concentrazione di traffico.
    • Durante il live streaming, 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 collocati insieme alle risorse di computing utilizzate per la transcodifica.

Ottimizza la durata dei segmenti video per i live streaming

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

La distanza fisica tra la località del bucket e la località di riproduzione degli utenti finali influisce sul tempo di trasmissione. Se gli utenti finali sono lontani dalla località del bucket, ti consigliamo di utilizzare una dimensione del segmento video più lunga.

Per offrire agli spettatori la migliore esperienza, è consigliabile utilizzare la strategia di ripetizione e l'hedging delle richieste per le scritture sui transcoder, in modo da mitigare le latenze della coda lunga di oltre due secondi per le scritture su Cloud Storage e sperimentare intervalli di buffering più lunghi, di circa dieci secondi.

Aumenta gradualmente le 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 è 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 QPS più elevate, devi implementare la scalabilità sul tuo bucket eseguendo il preriscaldamento del bucket o abilitando lo spazio dei nomi gerarchico sul bucket. Prima di implementare la scalabilità nel bucket, devi eseguire le seguenti attività:

Stima le QPS verso l'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 una percentuale di successo della cache del 99,0%, il traffico risultante verso Cloud Storage sarà dell'1%. Le QPS saranno l'1% del totale degli spettatori (un milione), ovvero 10.000 QPS. Questo valore è superiore alla capacità di IO iniziale.

Monitora le QPS e risolvi eventuali errori di scalabilità

Devi monitorare le QPS e risolvere eventuali errori di scalabilità. Per saperne di più, 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/richiesta GET e il grafico Numero totale di richieste di scrittura nella consoleGoogle Cloud . Se scali le QPS sui bucket più velocemente delle linee guida per l'incremento specificate nella sezione precedente, potresti riscontrare l'errore 429 Too many requests. Scopri come risolvere l'errore 429 Too many requests.

Le sezioni seguenti descrivono come scalare il bucket per ottenere un numero di QPS più elevato dopo aver stimato le QPS per l'origine.

Implementa la scalabilità delle QPS nel bucket eseguendo il preriscaldamento del bucket

Puoi accelerare il processo di scalabilità prima di un evento in live streaming preriscaldando il bucket. Prima dell'evento in live streaming, genera traffico sintetico verso il tuo bucket che corrisponda al numero massimo di QPS previsto che il server di origine della CDN riceverà per l'evento, più un buffer aggiuntivo del 50% che tiene conto del tasso di successo della cache previsto della CDN. Ad esempio, se hai stimato che il QPS per l'origine sia 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 il 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 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 a partire da un valore iniziale di 5000 richieste al secondo, saranno necessari circa 30 minuti.

Il server di origine mantiene la capacità finché il traffico non è costante. 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 di live streaming, ti consigliamo di simulare il traffico prima di ogni evento.

Utilizza bucket con spazio dei nomi gerarchico abilitato per QPS iniziali elevate

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 valore QPS iniziale più elevato semplifica la scalabilità dei workload che richiedono un uso intensivo dei dati e fornisce un throughput migliorato. Per informazioni sulle limitazioni nei bucket con namespace gerarchico abilitato, consulta Limitazioni.

Evita nomi sequenziali per i segmenti video per scalare le QPS

Con la scalabilità delle 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 anziché sequenziali offre la migliore distribuzione del carico. Tuttavia, se vuoi utilizzare numeri sequenziali o timestamp 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 saperne di più, consulta Utilizza 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 i bucket con lo spazio dei nomi gerarchico abilitato per ottenere QPS più elevate.

Utilizza 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 a ritardi di scalabilità.

Passaggi successivi