La qualità dello streaming video dipende da milioni di cose che vanno bene, come la gestione di un carico di lavoro costantemente fluttuante o la gestione di “folle improvvise” quando un gran numero di spettatori entra in uno streaming contemporaneamente. È per questo motivo che offrire un flusso video affidabile e di alta qualità come parte di un servizio a pagamento, in cui gli spettatori si aspettano un’esperienza simile a quella televisiva, richiede strumenti e metriche per articolare accuratamente le sfide delle prestazioni, in modo da poter sapere dove e come risolvere i problemi.
Le CDN sono una soluzione indispensabile per lo streaming video perché offrono scalabilità on demand a bassa latenza in tutto il mondo. Oltre alle ottimizzazioni che migliorano il modo, la CDN bilancia la caotica crescita del pubblico che può accompagnare un live streaming, per offrire ottime prestazioni all’utente finale è necessario un ulteriore livello di visibilità, metriche, strumenti e automazione.
In questo post, esamineremo esempi di recenti ottimizzazioni delle prestazioni che abbiamo fatto per un grande servizio di streaming vMVPD nordamericano, tra cui:
- Metriche che utilizziamo per migliorare/risolvere i problemi di prestazioni
- Come definire le prestazioni e come misurarle
- Ottimizzazioni continue per migliorare le prestazioni video
Numeri dei sistemi autonomi: La complessità dietro il sipario
Il Web moderno è costruito intorno a più livelli interconnessi di reti note come ASN (numeri di sistema autonomi), ciascuno costituito da grandi gruppi di indirizzi IP accoppiati a CDN (reti per la distribuzione dei contenuti) che riducono la congestione rendendo i contenuti disponibili all’edge della rete. Essenzialmente, come mostrato di seguito, Internet è costituito da una rete di reti, ciascuna con il suo modello di business e le sue priorità uniche.
Fonte: Research Gate
Insieme alla complessità intrinseca degli ASN che interagiscono tra loro, la loro portata e la loro portata sono enormi. Lo strumento vizAS tenta di visualizzare le interconnessioni tra i numerosi ASN paese per paese. Ad esempio, solo negli Stati Uniti, ci sono 16.979 ASN e 24.905 relazioni di peering nelle reti. A livello globale, ci sono più di 90.000 ASN.
https://stats.apnic.net/vizas/index.html
Dal nostro punto di vista di provider di CDN, la complessità della connessione a migliaia di ASN è aggravata dalla necessità di soddisfare i requisiti di prestazioni, il profilo di utilizzo, il tipo di traffico e molti altri fattori di ciascun cliente. Ad esempio, un servizio come Twitter avrà un profilo di utilizzo o un footprint molto diverso rispetto a un’azienda di gaming che distribuisce un aggiornamento importante. Allo stesso modo, un’emittente che trasmette in streaming un evento sportivo dal vivo ha un profilo diverso rispetto a un servizio di streaming on demand. Anche due servizi di live streaming hanno probabilmente profili diversi, ognuno dei quali richiede un’ottimizzazione personalizzata delle performance.
Dietro le quinte, abbiamo un gran numero di impostazioni di configurazione che possiamo regolare e ottimizzare per aiutare i clienti a raggiungere i loro obiettivi di prestazioni e requisiti. Per alcuni, le prestazioni possono essere quello che si aspettavano (o meglio) dalla partenza, e non abbiamo bisogno di cambiare nulla. Altri potrebbero avere obiettivi specifici, come Faster TTFB (Time To First byte), una metrica importante per i servizi di streaming, che devono essere affrontati.
Data la complessità e le dimensioni di Internet, è impossibile fornire miglioramenti delle prestazioni utili e coerenti attraverso approcci “whack-a-mole” o scattershot. I vantaggi reali derivano dalla raccolta completa dei dati e dall’analisi intensiva dei dati per identificare la causa principale di un problema o per ottenere informazioni proattive sulle modifiche alla configurazione della rete che andranno maggiormente a vantaggio del cliente.
Fornire informazioni RTT con Stargazer
Una delle metriche più importanti per determinare la latenza di rete e lo stato complessivo delle prestazioni è l’RTT (tempo di round-trip). Questa è definita come la durata, misurata in millisecondi, che richiede un pacchetto per spostarsi dall’origine alla destinazione e una risposta per essere inviata all’origine. Può essere utilizzato per diagnosticare e migliorare le prestazioni di rete su diversi vettori, tra cui congestione, problemi hardware, configurazioni errate e problemi di instradamento.
Data l’importanza di questa metrica, abbiamo creato un sistema interno chiamato Stargazer che utilizziamo per aggregare i dati RTT da varie fonti, inclusi i nostri sensori, i dati che importiamo dai clienti e terze parti che monitorano anche le informazioni RTT. Stargazer monitora i tempi di risposta in uscita diretti al client. Altre fonti di dati possono includere tabelle BGP (Border Gateway Protocol) dai router, mappatura dei router alle posizioni geografiche, registri RTT per le connessioni dai client e informazioni sul volume di traffico. Inoltre, il sistema può eseguire sonde attive come tracciati e ping, se necessario.
Dietro l’attività di monitoraggio, Stargazer, insieme ad altri strumenti che abbiamo sviluppato, ci permette di interrogare tutti i dati che abbiamo raccolto e di eseguire analisi approfondite che aprono le porte a continui miglioramenti. I nostri amministratori di rete possono utilizzare queste informazioni per isolare i problemi e identificare percorsi o configurazioni di rete per ottimizzare le prestazioni in base a specifici obiettivi e requisiti del cliente. E, come verrà discusso più avanti, è anche utile per comprendere l’effetto che le nuove tecnologie, come il protocollo BBR (larghezza di banda collo di bottiglia e tempo di propagazione round-trip), hanno sulle prestazioni.
Ottimizzazione di un server di origine
Per fornire maggiori informazioni sul funzionamento pratico dell’ottimizzazione delle prestazioni, esaminiamo un esempio che coinvolge un cliente di streaming video live aggiunto di recente che aveva bisogno di ottimizzare per un’architettura multi-CDN . In un’architettura client CDN tradizionale, il client effettua una richiesta a uno dei nostri POP e la cache POP si riempie dall’origine, come mostrato di seguito.
Tuttavia, questo cliente ha scelto di sfruttare un’architettura multi-CDN per aumentare la ridondanza e la resilienza e potenzialmente aumentare le prestazioni. Questa funzione è attivata dall’architettura Origin Shield illustrata nella Figura 4. Origin Shield offre un maggiore controllo su come il traffico dei vari client può essere instradato per ottenere le migliori prestazioni.
A differenza di una tradizionale relazione CDN, tutto il traffico, incluso quello servito dalla seconda CDN, ritorna a uno dei nostri POP (AGA) situati ad Atlanta per il riempimento della cache. Il POP AGA funge quindi da origine, o più specificamente, da scudo di origine, alleggerendo il notevole onere del server di origine del cliente. Il POP AGA è stato scelto come posizione dello shield di origine a causa del suo rapporto cache-hit e delle prestazioni più elevate rispetto al secondo CDN. Una delle principali preoccupazioni, tuttavia, è stata l’ottimizzazione delle prestazioni tra le due CDN.
Il primo passo del processo è stato quello di esaminare l’ottimizzazione delle rotte che la seconda CDN ha intrapreso verso AGA, fungendo da scudo di origine. Un problema immediatamente evidente è stato rappresentato dalle prestazioni scadenti tra le CDN e da un elevato numero di timeout di connessione che hanno avuto un impatto sul TTFB. Per approfondire i problemi di prestazioni, abbiamo utilizzato Stargazer per inviare un traceroute da AGA alla destinazione prevista e catturare gli ASN utilizzati per ogni hop.
Come illustrato nella sintesi che segue, un traceroute è stato inviato da AGA a un indirizzo IP presso la seconda CDN, simulando il percorso del cliente.
Abbiamo notato che diversi luppoli erano all’interno della ASN 7018, che non era la strada preferita perché coinvolgeva più luppolo e aveva più traffico. Utilizzando Stargazer, abbiamo rapidamente confermato il problema e apportato le opportune modifiche alla rete. Come mostra il riepilogo traceroute riportato di seguito, dopo aver apportato la modifica alla rete, abbiamo ridotto il numero di hop e migliorato RTT passando a ASN 7922, che ha anche risolto il problema dei timeout TTFB.
In un altro esempio, abbiamo utilizzato lo strumento Stargazer per determinare il miglior percorso di scudo dell’origine al server di origine di un cliente situato sulla costa orientale. Per ridurre in modo efficace il carico sull’origine di un cliente e migliorare le prestazioni di consegna, il pop di protezione dell’origine deve essere vicino all’origine. A volte, non è necessariamente il pop fisico più vicino che funziona meglio. È una combinazione del minor numero di ASN, la minore quantità di congestione, e bassi tempi RTT. Come si può vedere nella prima e dopo la tabella seguente, un traceroute Stargazer ha mostrato che il passaggio dal pop NYA (New York) al pop DCC (Washington, D.C.) ha ridotto il numero di hop a tre, con un conseguente miglioramento complessivo delle prestazioni RTT.
Analisi più approfondita con Sweeper Fish
Con oltre 7.000 interconnessioni e oltre 300 pop in tutta la nostra CDN a livello globale, c’è un sacco di lavoro continuo di ottimizzazione. Per evitare di far girare le ruote su attività che potrebbero non fare molta differenza, avevamo bisogno di un modo efficiente per dare priorità alle azioni intraprese dai nostri team operativi. Questo bisogno ha portato allo sviluppo di uno strumento complementare per Stargazer chiamato Sweeper Fish che segna i luoghi in cui esistono i problemi e ci permette di ribollirli in modo prioritario.
Sweeper Fish è anche utile per determinare se un percorso è congestionato e se è probabile che causi problemi. Tornando all’esempio multi-CDN, abbiamo usato Sweeper Fish per scoprire quali percorsi avevano una congestione. A tale scopo, Sweeper Fish ha misurato il delta tra il 25° e il 75° percentile per I dati RUM (Real User Measurement) per tutti i clienti su tutti i percorsi verso il POP AGA, concentrandosi sul percorso della seconda CDN verso di noi, ASN7922. La deviazione standard per tutto il traffico su questo ASN è mostrata di seguito.
Abbiamo anche confermato che la configurazione precedente tramite ASN7018 non era la strada da percorrere. L’analisi Sweeper Fish ha mostrato che l’IQR (interquartile Range) è aumentato da 20-60 a millisecondi (cfr. Figura 9) a causa della congestione su questo percorso. IQR, chiamato anche midspread o middle 50%, fornisce un modo utile per analizzare un percorso e segnalare rapidamente i problemi. Più basso è l’IQR, meglio è.
Al contrario, il POP AGA è stato costantemente compreso tra 10-22 millisecondi sul percorso che abbiamo utilizzato, ASN7922, come mostrato di seguito. Confrontando diversi ASN, Sweeper Fish ci consente di scegliere il percorso migliore e meno congestionato e/o di identificare i problemi da risolvere.
Sintonizzazione TCP
La congestione provoca anche l’eliminazione e la ritrasmissione dei pacchetti. Questo si verifica quando i percorsi tra pop sono distanti e l’algoritmo TCP non è ottimizzato. Poiché l’AGA è stata l’origine del nostro esempio, è stato possibile che i pop lontani che hanno raggiunto l’AGA abbiano questo problema. Sebbene siano presenti in molti pop, i registri CDN aggregati riportati di seguito ci hanno permesso di identificare le aree problematiche come indicato dalle caselle.
Figura 11. I registri dei server aggregati identificano rapidamente le aree problematiche in cui i pacchetti vengono eliminati e ritrasmessi.
Valutazione BBR
BBR (Bottleneck Bandwidth and Round-trip propagation Time) è un algoritmo alternativo di controllo della congestione TCP sviluppato da Google che ha iniziato a guadagnare una certa trazione. Si differenzia dagli algoritmi di controllo della congestione basati sulle perdite, come l’onnipresente TCP-Cubic, e introduce un diverso paradigma operativo. Aggiorna continuamente la quantità di dati che possono essere in volo in base al minimo RTT osservato finora dalla sessione per evitare il gonfiore del buffer.
La nostra analisi ha rilevato che il BBR è utile per migliorare le prestazioni RTT, ma non rappresenta una soluzione universale. Ci sono alcune volte in cui vuoi usarlo e altre volte in cui non lo fai Stargazer ci aiuta a determinare quando vogliamo utilizzarlo tracciando il profilo coerente degli RTT verso le destinazioni nel corso dei periodi. Ciò ci consente di determinare i punti migliori in cui applicare BBR per ridurre le ritrasmissioni e migliorare il controllo del flusso.
Sulla base dell’analisi mostrata nelle tabelle seguenti, abbiamo concluso che il passaggio al BBR migliorerebbe leggermente le prestazioni del POP AGA verso il secondo CDN e l’origine del cliente. La prima serie di grafici mostra che il passaggio da TCP-Cubic a TCP BBR ha comportato una diminuzione delle ritrasmissioni, mentre la seconda serie di grafici indica che il passaggio a BBR ha fornito un leggero aumento del throughput medio.
Figura 12. In questo esempio, il passaggio da TCP-Cubic a TCP BBR ha comportato una diminuzione delle ritrasmissioni
Figura 13. In questo esempio, il passaggio a BBR per il controllo del flusso da TCP-Cubic per AGA POP ha ridotto le ritrasmissioni e migliorato leggermente il throughput medio.
Conclusione
Internet è vasto e complesso – è essenzialmente una rete di reti. Per Edgecast, ora Edgio, ottimizzare le prestazioni per i casi di utilizzo dei clienti sarebbe quasi impossibile senza analisi approfondite per ottenere informazioni sulle aree problematiche e testare eventuali modifiche alla configurazione. Per migliorare le prestazioni dei nostri clienti, abbiamo sviluppato un solido set di strumenti per monitorare continuamente gli RTT, in modo da poter apportare miglioramenti in modo rapido ed efficiente in tutta la nostra rete. Per un servizio di streaming video live, abbiamo trovato modi per ottimizzare le prestazioni in base ai loro requisiti specifici, valutando al contempo l’uso di BBR per la loro applicazione. Il risultato è stata una soluzione di streaming ad alte prestazioni che sfruttava due CDN. E non abbiamo ancora finito. Poiché la congestione della rete continua ad aumentare, non smetteremo mai di ottimizzare la nostra rete per garantire ai nostri clienti e ai loro clienti la migliore esperienza online possibile.
