Richiedi Informazioni

Ottimizzazione server dedicato grazie a MemCached

Spesso si tende a credere che i meccanismi di cache siano una panacea, che dalla loro implementazione non si debba temere problema alcuno: ovviamente non è così.

Specialmente se il tuo cloud è dedicato all’erogazione di siti/portali web di volumetria importante, l’utilizzo di memcached può sì aumentare le performance, ma può anche introdurre un nuovo point of failure, uno del genere che non ti aspetti.

Ad esempio, non ti aspetteresti che il un’istanza memcached possa rappresentare un collo di bottiglia, men che meno un pool di istanze bilanciate e, cosa ancor più singolare, che lo possano rappresentare a livello di networking, eppure succede.

Cos’è memcached, e come funziona?
Memcached è un sistema di caching distribuito: ha una struttura client/server che permette di servire i dati più richiesti direttamente dalla RAM, riducendo allo stesso tempo il carico sul database. Può essere di grande aiuto se hai necessità di gestire una quantità di dati importante da rendere disponibili ad un ampio bacino di utenti.

Il server funziona ricevendo una serie di coppie chiave-valore e mantenendole in RAM. In genere è compito della logica applicativa (del tuo script php, ruby, phyton, per intenderci) decidere se effettuare un’operazione di scrittura su memcached oppure di lettura.

È sempre compito dell’applicazione computare un hash delle key che invia a memcached ed inviare la coppia chiave-valore al server stesso. Nel caso di un cluster, l’applicazione deve determinare in base all’hash quale nodo memcached contiene quale valore.

Ora può succedere che alcune coppie chiavi-valore siano molto più utilizzate di altre, queste si definiscono in gergo “hot keys”. Può succedere inoltre, nel caso che il sito sia molto trafficato, che i front-end web interroghino con preferenza alcune coppie chiave-valore specifiche.

Ad esempio: immagina di dover gestire la home page di un quotidiano nazionale. Immagina che il codice che muove quel sito interroghi memcached per evitare che, ad ogni richiesta della home page, vengano fatte delle richieste al database. Immagina infine che la home page del tuo portale riceva un grosso picco di traffico completamente inatteso.

Man mano che il traffico aumenta, aumentano le richieste che i front-end devono effettuare al back-end memcached per evitare di interrogare i database. Per servire un sito di questo tipo, hai probabilmente predisposto una mezza dozzina di front-end applicativi, forse di più, ciascuno di questi chiama il tuo back-end memcache.

Man mano che il traffico servito lato pubblico scala verso le decine di Mbit/s, il traffico verso il tuo backend memcached aumenta con un moltiplicatore pari al numero di front-end e questo comincia a saturare la scheda di rete del tuo memcached.

Il traffico aumenta fintanto che la scheda di rete si satura, il sistema crolla, con buona pace di ottimizzazioni lato front-end, bilanciamento, e ottimizzazioni lato SQL.

Se parimenti hai un cluster memcached alle spalle il problema può comunque presentarsi perchè alcuni nodi del cluster potrebbero avere delle “hot-keys” un po più “hot” delle chiavi degli altri nodi.

Ora, può anche essere che i tuoi memcached contengano solo piccole porzioni di dato e quindi il traffico sulla NIC sia molto contenuto, ma se non sei tu ad aver scritto l’applicazione, non puoi esserne certo, quindi devi quantomeno monitorare la saturazione della NIC e l’eventuale presenza di hot keys sui server.

Come uscirne fuori?
Se la situazione non si è ancora deteriorata, potresti effettuare l’analisi del traffico in uscita dalla NIC con un packet sniffer e cercare di capire quale sia la chiave “incriminata” e i dati associati. Certo che però, se stai facendo passare qualche centinaio di Mbit/s su una NIC, un’attività del genere non deve essere una passeggiata anche solo per la mole di dati che devi processare.

In alternativa, può venirti in aiuto uno strumento come mctop, che mi permette di tracciare numero di chiamate, richieste al secondo, e l’uso della banda per ogni singolo pacchetto.

In questo modo, ti è molto più facile individuare le key che tendono a saturare la banda e indicarti dove i tuoi programmatori o tecnici devono intervenire.

Non è solo un problema lato server.

Come puoi immaginare, questo tipo di problemi va affrontato sia lato sistemi che lato sviluppo. Identificare una “hot key” manualmente, in emergenza, può anche andare bene, il punto è che il layer applicativo deve essere in grado di effettuare – per quanto possibile – questo tipo di operazione in autonomia.

Alternativamente è opportuno avere dei sistemi di monitoraggio e alert sui server che possono presentare saturazione lato NIC.

Unknown unknowns
Rimane infine vero che questo tipo di colli di bottiglia diventa apparente solo la prima volta che ti manda giù l’infrastruttura, specialmente se gli sviluppatori sono poco accorti e i tuoi sistemisti non sono a conoscenza della problematica o addirittura esternalizzati.

In pratica, problemi come la saturazione della NIC di un memcached possono rappresentare dei “problemi che non sai di avere”, degli unknown unknowns appunto.

Per questo motivo, se hai un portale web di elevata criticità per il tuo business, se quello che scrivo ti ispira fiducia, se hai bisogno di supporto, prova a contattarci. Non possiamo prometterti miracoli, ma qualche magia la sappiamo fare.