Alla CDN sviluppiamo continuamente modi nuovi e innovativi per aiutare la nostra infrastruttura a mantenere elevate prestazioni e resilienza in caso di improvvisi aumenti del carico. Questo spesso implica l’esplorazione di ottimizzazioni sulle tecniche esistenti che utilizziamo. Inoltre, la convalida di nuovi approcci è una parte importante di questo processo, in quanto garantisce che i nuovi cambiamenti abbiano gli impatti positivi attesi negli ambienti di produzione.
Quando i contenuti diventano popolari, li replichiamo su più server in un data center/punto di presenza (POP). Questo ci consente di bilanciare meglio il carico e gestire tali picchi, riducendo il rischio di sovraccarico dei server. Questo meccanismo di replica è chiamato «Hot Filing» e il contenuto più diffuso è chiamato «hot file». Di recente abbiamo sviluppato un’ottimizzazione ALB (Adaptive Load Balancing) che migliora la nostra archiviazione a caldo tradizionale rendendola più resiliente ai picchi di traffico. In particolare, decide dinamicamente la quantità di replica necessaria misurando il carico del server invece di basarsi su soglie statiche. In questo modo il carico viene distribuito in modo più uniforme tra tutti i server in un pop, aumentando la capacità complessiva di gestione delle richieste di qualsiasi POP e, di conseguenza, della CDN. Il nostro precedente articolo sulla valutazione di un sistema di bilanciamento del carico adattivo descrive in dettaglio la meccanica di questa ottimizzazione.
In questo post, convalidiamo l’impatto positivo di questa ottimizzazione nella produzione. Iniziamo definendo le metriche utilizzate per misurare l’impatto. Successivamente, mostreremo l’impatto dell’ottimizzazione su ciascuna di queste metriche attraverso esempi. Infine, mostriamo l’impatto aggregato dell’ottimizzazione in tutti i POP in cui è stata implementata. In sintesi, abbiamo riscontrato che il carico eccessivo dei server temporali totali oltre una soglia predefinita è stato ridotto di almeno il 70%, mentre quasi tutti i POP hanno registrato un miglioramento di questa metrica. Questa ottimizzazione è ora abilitata a livello globale per tutto il traffico dei clienti.
Definizione delle metriche
Per valutare l’impatto di questa nuova ottimizzazione nella produzione, abbiamo definito e monitorato tre metriche:
- Skewness del server: Questo è il rapporto tra il carico di un server e il carico mediano su tutti i server nel POP.
- Numero di file hot: Il numero di file replicati dal meccanismo Hot Filing in qualsiasi momento. Si prevede che il bilanciamento adattivo del carico aumenti il numero di file hot, poiché il riempimento a caldo è il meccanismo alla base della sua distribuzione del carico.
- I server di tempo trascorrono oltre la deviazione target: Questa metrica valuta l’efficacia del bilanciamento del carico adattivo. Quando impostiamo la soglia di skewness target su un determinato valore, vogliamo vedere che la maggior parte dei server è di solito inferiore a tale valore.
Impatto dell’ottimizzazione sulle metriche monitorate
RAGGIUNGIMENTO DELLO SFOCAMENTO DELL’OBIETTIVO
La figura seguente mostra due snapshot della distribuzione del carico dei server in un pop. Sulla sinistra (senza Adaptive Load Balancing), vediamo un numero di server che superano l’obiettivo di skewness (casella rossa) con un carico superiore a 1,8 volte la media del pop. Sulla destra (con il bilanciamento del carico adattivo), vediamo un maggiore equilibrio tra i server, senza che i server presentino un carico superiore a 1,8 volte la media.
Variazione nella distribuzione del carico con bilanciamento del carico adattivo. Si nota una riduzione del sovraccarico dei server.
NUMERO DI FILE HOT E DISTRIBUZIONE DEL CARICO
Successivamente, abbiamo esaminato l’impatto sul numero di file hot e le modifiche corrispondenti al carico su ciascun server. Il grafico seguente mostra che il numero di file hot è aumentato quando ALB è stato attivato su un pop. Questo comportamento era previsto poiché il meccanismo aumenta in modo selettivo le probabilità che i file vengano scaricati dai server con un carico maggiore.
Fondamentalmente, l’archiviazione a caldo e l’ALB riducono il carico sui singoli server aumentando il numero di server che forniscono servizi a determinati file. Ciò aumenta il carico di storage su ciascun server. Tuttavia, i file aggiuntivi scelti per essere replicati in un dato momento sono relativamente bassi rispetto ai file totali serviti dal POP, poiché sono selezionati solo da server esterni che richiedono l’offload. Nella maggior parte dei casi, lo spazio aggiuntivo della cache utilizzato è molto ridotto rispetto allo spazio totale su disco. Pertanto, il compromesso è utile ma importante da identificare e conoscere. Nella nostra implementazione, abbiamo incluso controlli di integrità per verificare che l’utilizzo della cache non sia influenzato negativamente da questa ottimizzazione.
Numero di file hot. Il numero aumenta quando il bilanciamento adattivo del carico è attivato (contrassegno rosso) poiché i server esterni vengono tentati di essere scaricati.
Il secondo grafico mostra il volume di traffico erogato da ciascun server nello stesso periodo di tempo in quel POP. Abbiamo osservato che quando è stato attivato il bilanciamento del carico adattivo (linea rossa tratteggiata), il carico tra i server è diventato più bilanciato. Ciò ha reso i server più resilienti al traffico in entrata e ridotto il rischio di sovraccarico dei server.
Distribuzione del carico (Mbps) in un pop tra il 05/02-05/04. Quando il bilanciamento adattivo del carico è attivato, la distribuzione diventa più fluida, con un numero maggiore di server che distribuiscono il traffico più vicino alla mediana. In questo modo si riduce il rischio che i server vengano sovraccaricati di nuovo traffico.
TEMPO PASSATO OLTRE LO SKEWNESS DEI BERSAGLI
Qui, abbiamo considerato un esperimento in cui un POP era impostato per mantenere un obiettivo inclinato di 1,6x. Nella figura seguente, la linea arancione mostra la distribuzione di “disallineamento del server” durante il periodo dell’esperimento. Confrontando questa distribuzione con la linea blu, che è la rispettiva distribuzione per il periodo di riferimento (senza bilanciamento adattivo del carico), abbiamo visto uno spostamento del carico verso la mediana. In particolare, anche la “coda” della distribuzione è stata ridotta in modo significativo, con il 99o percentile che è sceso da 2,12 a 1,52, al di sotto dell’inclinazione obiettivo.
Il bilanciamento adattivo del carico riduce il carico massimo del server e avvicina i carichi del server alla media.
Ridurre la “coda” nella distribuzione è l’obiettivo principale dell’ottimizzazione, poiché i server in quella coda, cioè quelli con il carico più elevato, corrono un rischio maggiore di essere sovraccarichi di nuovi picchi di traffico. Per quantificare ulteriormente questa riduzione, abbiamo anche misurato il numero di minuti per i quali qualsiasi server ha erogato traffico sul target durante i periodi di esperimento con/senza Adaptive Load Balancing:
Il bilanciamento adattivo del carico riduce il tempo che i server impiegano a fornire un carico oltre una soglia di destinazione.
In questo caso, abbiamo osservato una riduzione del 88% del tempo trascorso oltre l’oblio target in questo pop. Questo è un buon indicatore del fatto che il bilanciamento adattivo del carico può mantenere l’inclinazione della distribuzione del carico intorno al valore desiderato.
Risultati dell’implementazione globale
Dopo aver testato l’ottimizzazione su una manciata di POP selezionati e ottenuto buoni risultati sulle metriche misurate, abbiamo implementato il sistema in ogni POP per quantificare l’impatto aggregato nel tempo. Come in precedenza, abbiamo misurato il numero di minuti collettivi di server in un POP spesi per la distribuzione del traffico al di sopra dell’inclinazione specificata (impostato su un carico medio del server 1,8x in un POP). Il grafico successivo mostra due distribuzioni di minuti che i server hanno trascorso oltre tale soglia per 75 pop. La linea blu corrisponde a 4 giorni di dati di base e la linea arancione corrisponde a 4 giorni di dati di bilanciamento del carico adattivo. Lo spostamento complessivo della distribuzione a sinistra mostra che i server nei POP che eseguono il bilanciamento del carico adattivo impiegano meno minuti oltre la soglia.
Minuti aggregati spesi dai server per fornire un carico superiore alla soglia specificata (media di 1,8 *) nell’arco di 4 giorni per tutti i POP. Con il bilanciamento del carico adattivo, la distribuzione viene spostata a sinistra, indicando che il meccanismo mantiene i carichi del server al di sotto della deviazione target dalla media per periodi più lunghi.
Per comprendere ulteriormente gli effetti sui singoli POP, abbiamo anche registrato la variazione percentuale per questa metrica per ogni POP. I risultati hanno mostrato che la metà dei POP ha registrato una riduzione del 70-95% del tempo totale dei server al di sopra del target di scetticismo e quasi tutti i POP hanno registrato una riduzione del tempo trascorso al di sopra della soglia.
Nel nostro costante impegno per migliorare continuamente le prestazioni e l’affidabilità della nostra CDN, abbiamo recentemente implementato e valutato un’ottimizzazione nel modo in cui bilanciamo il carico del traffico all’interno di un POP. Questa ottimizzazione identifica i server caricati oltre una soglia specificata rispetto al resto del pop e li scarica, riducendo in particolare il rischio di impatto sulle prestazioni in caso di nuovi picchi di traffico. I risultati della produzione dimostrano miglioramenti significativi che sono stati coerenti con i precedenti risultati di simulazione, dimostrando l’efficienza dell’ottimizzazione nel mantenere la distribuzione del carico del server entro un’inclinazione desiderata. Di conseguenza, abbiamo ora attivato questa ottimizzazione a livello globale per tutto il traffico dei clienti.
Un ringraziamento speciale ad Angela Chen per aver lavorato all’attuazione e all’implementazione di questo meccanismo. Inoltre, grazie a Scott Yeager, Derek Shiell, Marcel Flores, Anant Shah e Reed Morrison per aver aiutato nelle discussioni generali, Colin Rasor, Richard Rymer e Olexandr Rybak per aver aiutato con la raccolta e la visualizzazione dei dati.
