Home Articoli tecnici Come ottenere personale con milioni di persone scalando la manipolazione del manifesto
Applications

Come ottenere personale con milioni di persone scalando la manipolazione del manifesto

About The Author

Outline

Le esperienze di visualizzazione personalizzate a un livello 1:1, stanno trasformando l’esperienza TV. Invece di adattarsi a tutti, gli spettatori ricevono pubblicità mirata e altamente pertinente, contenuti personalizzati, consigli per nuovi programmi e una gestione precisa di DRM/blackout, il tutto in base al tipo di dispositivo, alla posizione, alla cronologia, ai dati demografici e ad altri dati degli spettatori.

Ma scalare i flussi video personalizzati a milioni di spettatori, soprattutto per la programmazione live come lo sport, è quasi altrettanto impegnativo quanto colpire il ciclo nel baseball. I volumi degli spettatori possono oscillare vertiginosamente, aumentando di centinaia di migliaia nei momenti da non perdere, come il calcio d’inizio, gli straordinari e durante le partite ravvicinate. Supponiamo che la vostra infrastruttura per supportare la personalizzazione non sia sufficientemente adattabile e scalabile. In tal caso, la tua esperienza personalizzata sarà un gioco da ragazzi e l’intera azienda potrebbe essere a rischio nel mondo OTT.

Il ruolo centrale del server manifesto nella personalizzazione

La personalizzazione OTT dipende dalle prestazioni del server manifesto per generare una playlist unica di contenuti, annunci e istruzioni di riproduzione. Il server manifesto deve gestire le seguenti dipendenze:

  • Latenza del server pubblicitario: La comunicazione con i server pubblicitari può aggiungere latenza che deve essere presa in considerazione nel flusso di lavoro, soprattutto quando sono coinvolti più hop.
  • Monetizzazione/reporting : Una volta riprodotto l’annuncio, è necessario inviare un beacon ai server degli annunci per misurare le impressioni degli annunci e abilitare la monetizzazione.
  • Aspetti stateless di Internet : Affinché i manifesti personalizzati possano funzionare su larga scala, lo stato deve essere mantenuto su più richieste per ogni spettatore.
  • DRM/autenticazione : Il server manifesto deve tenere sotto controllo la gestione dei diritti digitali (DRM), la crittografia a livello di sessione e l’autenticazione.
  • Diritti e restrizioni di blackout/contenuti : In base alla posizione di un utente, lo streaming di contenuti può essere soggetto a varie regole di blackout, tutte da gestire con precisione.
  • Consigli sui contenuti : Gli spettatori online si aspettano che tu li conosca e personalizzi i tuoi consigli per aiutarli nel processo di ricerca e scoperta.
  • Localizzazione dei contenuti : Per gli eventi più importanti, è fondamentale fornire agli utenti le variazioni regionali appropriate, tra cui tracce audio, sottotitoli e sottotitoli.

Personalizzazione dei flussi in tempo reale

Come illustrato nella parte 1 di questa serie di blog, un feed live o VOD viene acquisito, codificato e confezionato dalla nostra applicazione software Slicer. I confini degli annunci possono essere inseriti per consentire ai proprietari dei contenuti di personalizzare l’esperienza dello spettatore. Man mano che gli annunci vengono acquisiti, vengono elaborati anche tramite un’affettatrice in esecuzione nel cloud per un’esperienza di riproduzione più simile a quella di trasmissione.

Quando l’affettatrice inizia ad acquisire il flusso live o VOD, comunica continuamente con la nostra infrastruttura back-end, mantenendo aggiornato il database sul numero di segmenti disponibili. I server manifesti utilizzano tali dati per personalizzare l’esperienza di ciascun visualizzatore. Quando un lettore richiede un flusso, il server manifesto determina quali segmenti audio e video devono essere elencati nel file manifesto, che funge da playlist. La possibilità di modificare o personalizzare dinamicamente il manifesto a livello di utente consente di personalizzare l’esperienza visiva. Nel caso di video live, viene richiesto un nuovo manifesto ogni pochi secondi, consentendo l’applicazione dinamica delle regolazioni da parte dei server manifesti al variare delle condizioni di visualizzazione.

Il ruolo centrale del server manifesto nella personalizzazione dei flussi video

Come mostrato sopra, al centro della personalizzazione manifesta c’è la comunicazione. Con la maggior parte dei requisiti aziendali OTT, ciò significa comunicazioni con i server pubblicitari per fornire annunci personalizzati e mirati in tempo reale. I singoli dati, compresi l’indirizzo IP, la posizione e il tipo di dispositivo di un visualizzatore, essenzialmente tutte le informazioni che possiamo acquisire pur rispettando rigide norme e normative PII, vengono forniti al sistema decisionale dell’annuncio. La soluzione risultante è abbastanza robusta da capire cosa è importante per uno spettatore quando distribuisce annunci durante i live streaming. Il sistema è inoltre abbastanza robusto da affrontare sfide quali la gestione delle restrizioni di blackout e dei diritti di contenuti per utente, supportando al contempo importanti funzionalità di personalizzazione, come i consigli sui contenuti e altre localizzazioni.

Architettura di un’infrastruttura manifesta su scala

Nella nostra piattaforma video, il server manifest è responsabile della generazione di un manifesto di streaming personalizzato per ogni visualizzatore. Deve inoltre essere consapevole di altri requisiti sopra indicati, come le restrizioni sui contenuti e le raccomandazioni. In questo modello, inviamo un flusso integrato, il che significa che non ci sono problemi di “ruota buffer” mentre i client sono in attesa che gli annunci vengano caricati nel mezzo del flusso.

Per creare un sistema di distribuzione dei manifesti resiliente, gestiamo cluster di server di generazione dei manifesti nel cloud distribuiti in diverse regioni geografiche in tutto il mondo. Negli Stati Uniti, ad esempio, questi server sono organizzati in cinque regioni in tutto il paese. Quando arriva una richiesta di un nuovo flusso da un giocatore statunitense, tale richiesta viene instradata in modo casuale in una delle zone statunitensi.

La sfida della «mandria del tufo»

Ciò può sembrare controintuitivo, ma viene fatto per evitare le modalità di errore a cascata. La maggior parte degli spettatori statunitensi si trova nella parte orientale del paese. Se dovessimo indirizzarli tutti verso la zona più vicina a loro e il nostro provider di servizi cloud ha riscontrato un fallimento in quella regione, la maggior parte dei nostri spettatori sperimenterebbe tale fallimento. A questo proposito, se tutti gli spettatori aggiornassero il flusso e ora stiamo indirizzando gli spettatori verso la loro prossima zona sana più vicina, si verificherebbe un problema di “gregge fragoroso” in cui tutti gli spettatori della zona fallita ora si spostano nella prossima zona più vicina. Il conseguente picco di traffico imprevisto potrebbe causare un guasto secondario finché i nostri sistemi nella nuova zona non saranno in grado di scalare per soddisfare la domanda aggiuntiva.

Invece, distribuendo casualmente i nostri spettatori statunitensi aiuta a mitigare l’effetto di qualsiasi guasto iniziale e ci consente di distribuire uniformemente il traffico di failover al resto delle zone sane.

Nella nostra piattaforma di streaming, distribuiamo il carico del server manifest in tutte le zone. In questo modo si evita di sovraccaricare una zona specifica durante i picchi di pubblico, soprattutto se gli spettatori vengono improvvisamente spostati in una zona adiacente durante il failover.

Ciascuna delle nostre zone dispone di un archivio dati separato dedicato alla memorizzazione dei dati di sessione associati. Una volta che un visualizzatore viene indirizzato a una zona, creiamo una sessione per quel visualizzatore e la salviamo nel cluster di sessioni della zona. La sessione è una serie di dati sul visualizzatore e i parametri forniti dal cliente su come desidera personalizzare la sessione per quel visualizzatore. Per superare la sfida presentata dalla natura stateless di Internet, i server manifesti costruiscono URL per ogni sessione inclusa nel manifesto restituiti al giocatore. Le richieste successive dal giocatore vengono indirizzate direttamente alla zona in cui la sessione del visualizzatore è stata creata e memorizzata (invece di instradare casualmente a una delle altre zone).

Come mostrato nei tre grafici seguenti, eventi diversi possono avere molti requisiti diversi a seconda delle dimensioni del pubblico e se il pubblico è locale o geograficamente dislocato. Date un’occhiata ai tre esempi che illustrano le sfide infrastrutturali che le emittenti devono affrontare nel supportare eventi live.

Nel primo scenario, presentiamo un concorso alimentare (sì, ne abbiamo uno in streaming live) perché illustra una dimensione del pubblico distribuita ma ridotta. Forse arriverà il giorno in cui i concorsi alimentari diventeranno mainstream, ma per ora rimangono un evento di nicchia che attira un piccolo numero di spettatori in un’ampia area geografica. Il carico del server manifest è distribuito facilmente tra più zone e cluster di server manifest. Ecco dove il valore della personalizzazione diventa evidente rendendo facile l’inserimento di annunci appropriati per ogni regione e anche la gestione di diritti e blackout.

Lo scenario cambia considerevolmente per i campionati di football dello stato del Texas, dove un gran numero di spettatori si trova nella stessa area geografica. CE ne occupiamo in un paio di modi. Come discusso in precedenza, abbiamo scoperto che possiamo assegnare gli spettatori a server manifesti situati in zone al di fuori della geografia immediata senza influire sull’esperienza dello spettatore. Inoltre, abbiamo un sistema che monitora i livelli di visualizzazione in ogni zona e può attivare automaticamente i server di generazione manifesti secondo necessità per ogni zona.

Potremmo eseguire il pre-scale in base alle visualizzazioni previste per grandi eventi come le finali NBA. Tuttavia, abbiamo avuto più eventi in cui i nostri sistemi di scalabilità automatica gestivano quasi un milione di spettatori senza richiedere alcun pre-riscaldamento. Oltre ad aumentare la scalabilità, la possibilità di distribuire istantaneamente il carico tra i server manifesti in modo indipendente dalla zona migliora significativamente l’affidabilità e la ridondanza in tutta la rete.

Richieste del giocatore e creazione di annunci pubblicitari

Una serie di cambiamenti e tendenze in tutto il settore stanno rendendo la scalabilità del cloud più importante che mai. Un fattore principale è l’intervallo di restringimento tra le richieste del giocatore. “La nostra richiesta standard live-lineare di 8 secondi “What’s Next” viene portata a 5 secondi e può essere breve come ogni 2 secondi per i flussi in cui la bassa latenza è importante.” Ciò influisce principalmente sull’utilizzo della CPU perché il server deve rispondere a richieste 4 volte più numerose (a intervalli di 2 secondi rispetto a intervalli di 8 secondi). Inoltre, è necessario controllare con maggiore frequenza anche i messaggi di blackout e i contenuti consigliati per evitare errori.

Allo stesso modo, il mondo ad-tech sta diventando sempre più complesso ed esigente. Per ogni annuncio inserito in un flusso, un server pubblicitario avrà almeno cinque beacon utilizzati a scopo di reporting. È necessaria una soluzione SSAI (Server-side ad insertion) per garantire che invii tali beacon in modo che i clienti vengano pagati dai loro inserzionisti. Anche se cinque beacon sono il minimo, CE ne possono essere molti altri. In effetti, abbiamo visto casi in cui un singolo annuncio ha da 30 a 100 beacon su cui riferire.

Inoltre, reti complesse di server pubblicitari stanno diventando sempre più comuni nelle campagne dei nostri clienti. Più salti di rete pubblicitari possono iniziare a causare problemi di latenza. “Ad esempio, la rete n. 1 potrebbe dire “Ecco l’elenco degli annunci in questa interruzione”, solo per scoprire che l’annuncio n. 2 in quella interruzione richiede una richiesta a un’altra rete.” L’annuncio #3 introduce altri due luppoli e così via.

Nell’esempio precedente, le interruzioni degli annunci possono raddoppiare o triplicare l’utilizzo della CPU. Le richieste dei lettori video in tempo reale possono comporre questo fattore del 10-30%.

‍Looking Ahead: Microservizi e scalabilità

Con l’aumento della complessità, uno dei passi che abbiamo intrapreso è separare i diversi carichi di lavoro precedentemente gestiti dai server manifesti in microservizi più piccoli. Il primo passo che abbiamo fatto è spostare le comunicazioni del server pubblicitario e il beaconing sul proprio servizio, contribuendo ad affrontare la sfida della latenza del server pubblicitario. Questo servizio proxy per gli annunci offre diverse funzionalità avanzate che verranno discusse in modo più approfondito in un prossimo post sul blog.

In futuro, continueremo a sviluppare altri microservizi per rimuovere più lavoro dai server manifesti e offrire un approccio più mirato alla scalabilità. Presto, aggiungeremo zone di più provider cloud per diventare resilienti ai fallimenti di uno qualsiasi.

Abbinando SSAI scalabile ai microservizi, possiamo ottimizzare i costi dei server, la struttura della nostra base di codice e altre caratteristiche specifiche del traffico pubblicitario. Inoltre, siamo in grado di superare diverse sfide chiave, tra cui la latenza del server pubblicitario, le restrizioni di blackout e la monetizzazione. Allo stesso tempo, distribuendo il carico di elaborazione in più zone, il nostro servizio di streaming video live è in grado di scalare ampiamente e superare le sfide principali, consentendoci di distribuire in modo affidabile milioni di flussi personalizzati simultanei senza mettere a dura prova la nostra rete di distribuzione.