I Sistemi di Caching Globale

Come avvicinare i contenuti agli utenti finali, migliorando la qualità e riducendo il traffico sui transiti internazionali.

Rieccoci con un altro articolo particolarmente dedicato al mondo dei Service Provider, e con esso scopriamo un po’ di più com’è fatta la rete Internet e quali sono le tecniche adottate per portare rapidamente i contenuti agli utenti.

Come abbiamo visto nell’articolo “Il COVID-19 e la crescita del traffico Internet”, si è verificato un notevole aumento del traffico in Rete a partire da Marzo 2020 e la tendenza per il futuro sarà comunque quella di crescere, a prescindere dall’emergenza sanitaria.

Ci si domanda quindi: “Come possiamo gestire tutto questo scambio di dati ed evitare le saturazioni?”

I Sistemi di Caching Globale sono il metodo migliore per fare in modo che i contenuti vengano erogati da un punto fisicamente (o logicamente a seconda del design di una rete) molto vicino agli utenti finali, così da ridurre il traffico scambiato sui percorsi internazionali di lunga distanza.

Immaginiamo che un sito specializzato nell’erogazione di contenuti video (poniamo pure l’esempio di YouTube) mettesse a disposizione un nuovo video di particolare interesse e diventasse in poco tempo molto richiesto in tutto il mondo. Ipotizziamo ora che YouTube avesse un solo data center, ad esempio in California, questo vorrebbe dire che il traffico destinato ad utenti dislocati in tutto il mondo verrebbe erogato solo dai server dalla California. Il risultato credo sia facilmente immaginabile: avremmo saturazione sui percorsi internazionali, andando inoltre ad inficiare l’erogazione del contenuto stesso e di altri servizi: YouTube potrebbe ad esempio ridurre notevolmente la qualità dei video per evitare la congestione della Rete.

Immaginiamo invece che il data center di YouTube sia distribuito, con una piccola presenza di alcuni server con funzioni di replica, detta anche “caching”, presso quasi tutti gli Internet Service Provider (d’ora in poi ISP) del mondo; basterebbe trasferire una sola volta il video in questione dal data center centrale verso i cache server e da questi erogare il contenuto agli utenti finali.

I vantaggi di questo sistema sono molteplici:

1. Innanzitutto, come abbiamo detto, la riduzione del traffico sui transiti internazionali e questo va a vantaggio sia di chi eroga i contenuti, che dei Service Provider locali ai quali gli utenti finali sono connessi;
2. La possibilità di erogare contenuti con una qualità più alta (pensiamo sempre al video di prima diventato virale in poche ore);
3. L’eliminazione del “Single Point of Failure”: è più facile che si verifichi un disservizio in un singolo Data Center, che non simultaneamente in molti, soprattutto se gestiti da diversi ISP e geograficamente distribuiti;
4. La riduzione dei costi da parte di chi eroga i contenuti: tutti gli Application Service Provider che distribuiscono Cache Server, spediscono gratuitamente i server già configurati, ma l’energia elettrica e la connettività vengono messi a disposizione dall’ISP che li ospita. Ci guadagnano comunque tutti e gli utenti finali hanno un servizio migliore e più reattivo, evitando lamentele all’incolpevole ISP;
5. Aggiornamento in tempi molto rapidi dei contenuti delle Cache in base ad un punteggio: più un contenuto è richiesto e più verrà distribuito in maniera capillare;
6. Distribuzione dei contenuti in cache su base “Regionale”: ogni Cache nel mondo non avrà il medesimo contenuto, bensì avrà i contenuti più richiesti dai clienti dell’ISP che lo ospita. Questo riduce ulteriormente il traffico tra il Data Center primario e la periferia, perché con questo sistema vengono “alimentati” con un determinato contenuto solo i Cache Server vicini agli utenti che ne stanno facendo richiesta;
7. Re-direzione degli utenti su altri Cache server nel caso di fermo di uno o più server.

Vediamo ora un po’ più in dettaglio come funziona il sistema. La domanda è: “Quando vado su www.youtube.com, come fa Google a riconoscermi ed indirizzarmi verso il server più vicino?”

La risposta è nella seguente immagine:

1. L’utente invia la richiesta di risoluzione di www.youtube.com al server DNS (server per la risoluzione die nomi) del proprio ISP; 
2. A sua volta il DNS dell’ISP inoltra la richiesta ai DNS Google;
3. I DNS Google, appoggiandosi ai database dei 5 Registri Internet Regionali (ma non solo), identificano l’area di provenienza della richiesta e forniscono al DNS dell’ISP l’indirizzo del Cache server più vicino;
4. A sua volta il DNS dell’ISP inoltra l’informazione all’utente;
5. L’utente si collega al Cache Server più vicino;
6. Se il contenuto richiesto non è disponibile, viene richiesto al Server di Back-end che lo copia sulla Cache;
7. L’utente finale preleva il contenuto dalla Cache in maniera trasparente.

Possiamo trovare una spiegazione del funzionamento del caching Google a questo link: Google Edge Network.

Ho portato come esempio quello di Google e YouTube semplicemente perché è uno di quelli meglio documentati, ma esistono molti altri Application Provider che forniscono sistemi di caching: Netflix, Microsoft, Akamai, CloudFlare, Apple, Facebook, ecc.

Esistono poi i sistemi cosiddetti: “General Purpose”, che non sono legati ad un solo Application Provider, ma sono in grado di fare caching generico analizzando il numero di richieste che transitano in Rete per il medesimo contenuto. Come gli altri, vengono posti all’interno degli ISP e quando viene sorpassata una soglia prestabilita di richieste per il medesimo contenuto, questo viene messo nella cache generica ed erogato all’utente finale senza prelevarlo dal fornitore originale. Chiaramente il sistema funziona in simbiosi con i DNS dell’ISP, mentre se l’utente finale si appoggia ad altri DNS (esterni all’ISP), potrebbe non funzionare in modo efficace. Infine c’è anche tutta una questione legata ai certificati SSL, tale per cui il produttore della cache General Purpose deve aver stretto degli accordi con gli Application Provider al fine di potersi presentare agli utenti finali con il medesimo certificato dell’Application Provider in modo da essere “trusted”.

Facciamo brevemente un esempio sul suo funzionamento: ammettiamo che nessun ISP abbia le cache di Apple o che semplicemente la casa di Cupertino non le fornisca. Apple rilascia l’ultima versione di iOS, quasi contemporaneamente, tutti gli utenti di un ISP iniziano a scaricare il file (circa 5GB), sempre lo stesso file, centinaia e centinaia di volte o addirittura milioni a seconda di quanti utenti ha un ISP. Ogni volta il file viene prelevato dai Data Center Apple e visto che probabilmente il percorso preferito da un ISP per raggiungere Apple sarà sempre lo stesso (o al massimo un paio), tutto il traffico si concentrerà sul medesimo collegamento andando molto probabilmente a saturarlo. Con una cache General Purpose, dopo i primi download, il contenuto verrebbe messo in cache ed erogato dal punto più vicino agli utenti finali, lasciando i transiti internazionali liberi.

Le opinioni sull’uso delle cache General Purpose sono molto discordanti, c’è chi le trova molti utili per contenere il traffico ed evitare potenziali lamentele da parte dei clienti e chi invece ritiene che non siano un investimento vantaggioso, ma dovrebbero essere gli Application Provider a preoccuparsi di fornire i contenuti in maniera adeguata ai propri utenti in collaborazione con gli ISP e che quest’ultimi non debbano sopperire alle mancanze dei primi investendo di tasca propria su sistemi che potrebbero risultare poco efficienti.

Entrambe le visioni sono corrette e come al solito non c’è mai una scelta che si dimostrerà giusta al 100%, sicuramente le cache General Purpose non sono un investimento vantaggioso per un piccolo ISP, mentre possono tornare utili in uno molto grande, dove i volumi di traffico che potrebbero generare gli utenti sono enormi e non facilmente prevedibili, quindi per non rischiare di trovarsi impreparato e subire lamentele o richieste di rimborsi causa disservizi, un grande ISP potrebbe decidere di fare un investimento in tal senso.