Tumblr, come gestire 23000 richieste di blog al secondo

Di fronte alle statistiche operative di Tumblr non si può restare impassibili e capire le configurazioni operative dei server diventa interessante

Di recente, abbiamo avuto modo di valutare come Bitly sia capace di gestire oltre 6 miliardi di clic al mese con un’infrastruttura abbastanza snella, performante e continuativa dal punto di vista operativo. Vogliamo però porre l’attenzione su un altro portale ad alto traffico come Tumblr, che ha risolto le esigenze operative in modo egregio, mostrando come l’esperienza possa insegnare ad affinare le configurazioni con un mix di tecnologie oggi disponibili nei diversi rami del settore IT.Tumblr, come gestire 23000 richieste di blog al secondo

La sezione dei blog afferente a Tumblr riesce a gestire oltre 23 mila richieste al secondo, soddisfacendo con tempistiche accettabili ed estrema rapidità tutti gli esiti di operazioni eseguirte dagli utenti.

E non si tratta di poco! Infatti, come dicevamo, le statistiche parlano di oltre 23 mila richieste al secondo, oltre 6500 eventi di purge cache per secondo su un’infrastruttura che conta oltre 196 milioni di blog e oltre 93 miliardi di post.

Tutto Tumblr è basato su circa 2800 server, di cui solo il 20 percento è però dedicato alle funzionalità del blog e circa 278 sono i dipendenti totali dedicati all’intero progetto Tumblr.

Di fronte a questi numeri non possiamo restare impassabili e la curiosità su come l’operatività venga garantita è alta.

In principio, il blog di Tumblr si basava su un nodo attivo e su un server proxy in standby, in modalità Varnish. Entrambi erano semplici da gestire e monitorare e in qualche modo garantivano la continuità operativa e l’alta disponibilità dell’infrastruttura utile in quel momento.

Con l’evoluzione e la crescita del blog di Tumblr, la soluzione indicata aveva raggiunto ben presto i suoi limiti operativi e gli ingegneri si sono trovati ad affrontare in modo rapido la situazione, prima che il network andasse in downtime a causa della crescente popolarità.

Valutata l’opportunità di agire a livello DNS e con TTL inferiori, per ridurre i costi e i tempi dedicati alla crescita del livello proxy, in Tumblr hanno pensato di operare a livello di scalabilità dei nodi Varnish. Duplicare i nodi non era la via giusta, in quanto questa scelta operativa avrebbe ridotto il rapporto cache-richieste, avrebbe portato le richieste di purging cache a livelli più intensivi e non avrebbe aumentato lo spazio di lavoro della cache, ma lo avrebbe semplicemente duplicato.

Tumblr, fra Varnish e la codifica hash di HAProxy

La via più semplice da percorrere è stata quindi quella del partizionamento statico tra due nodi Varnish.

Questa scelta indicava la giusta direzione, ma al crescere del traffico veniva introdotta una granularità di partizionamento troppo importante che doveva essere in qualche modo risolta. Gli ingegneri in Tumblr hanno quindi pensato di agire sui valori ECMP per meglio garantire l’hashing delle richieste e quindi la loro gestione.

Confrontando le differenti tecnologie di hashing come SDBM, CRC, MD5, DJB2, e così via, gli ingegneri Tumlbr hanno determinato che il protocollo DJB2 offriva le migliori condizioni di distribuzione. Di fronte a questo risultato, la ricerca di una soluzione tecnologica efficace si è dovuta scontrare con la limitatezza del servizio HAProxy, che in modalità operativa predefinita utilizzava la funzione di hashing SDMB. A risolvere il problema sono stati gli ingegneri Blake Matheny e Andrew Terng che hanno programmato una patch per HAProxy capace di rendere la funzione di hash configurabile e permettendo così a Tumblr di utilizzare la codifica DJB2.

A Varnish e HAProxy è stato infine aggiunto Bird, per consentire un routing efficace fra i differenti proxy.