Twemproxy il proxy per Memcached

twemproxy2

Twemproxy (repository GitHub) è un proxy server che consente di ridurre il numero di connessioni aperte verso un server Memcached o Redis. Per cosa può essere utile questo strumento?

 

 

Le caratteristiche principali sono :

– ridurre il numero di connessioni al cache server agendo come un proxy;

– sharding di dati automatico tra più cache server;

– supporto per l’hash con diverse strategie e funzioni di hashing;

– configurabile per disabilitare i nodi caduti;

– esecuzione di istanze multiple, consentendo al client di connettersi al primo proxy server disponibile;

– pipelining e batching di richieste con risparmio di round-trip;

– configurabile per disabilitare i nodi non più funzionanti, e richiamarli successivamente, dopo un po’ di tempo;

Twemproxy è stato reso open source da Twitter (che lo ha sviluppato per le proprie esigenze) all’inizio del 2012, con il supporto a memcached, e recentemente ha aggiunto anche il supporto a Redis. Twitter fa uso estensivo dei cache server ed il sistema sul quale gira Twemproxy, per Twitter, è di dimensioni impressionanti; immaginate che i sistemisti devono gestire centinaia di cache server, che a loro volta amministrano svariati TB di dati ciascuno per oltre trenta servizi diversi, in-memory, inclusa la memorizzazione dei tweet. Parliamo di almeno due milioni di miliardi di query al giorno, ossia più di ventitré milioni di query al secondo, per un’infrastruttura che, peraltro, continua a crescere in maniera esponenziale.

Leggi anche articolo (“Ottimizzazre grazie a Memcached“)

 

Ottimizzare grazie a Memcached

theflash_memcachedOttimizzazione server dedicato grazie a MemCached

Spesso si e’ portati a credere che i meccanismi di cache siano una specie di Panacea, e che dalla loro implementazione non si debba temere alcun  problema : ovviamente non è così.
Specialmente se il tuo cloud è dedicato all’erogazione di siti/portali web con volumi importanti l’utilizzo di memcached può sicuramente aumentare le performance di quest’ultimo;  ma può anche introdurre un nuovo point of failure, uno di quelli che non ti aspetti.
Facciamo un esempio, non ti aspetteresti che un’istanza memcached possa rappresentare un collo di bottiglia !, men che meno un pool di istanze bilanciate e, cosa forse ancor più singolare, che lo possano rappresentare a livello di networking. Eppure succede!

Cos’è memcached, e come funziona?
Memcached è un sistema di caching distribuito ed ha una struttura client/server che permette di servire i dati più richiesti direttamente dalla RAM, riducendo cosi al tempo stesso il carico sul database.
Questo può essere di grande aiuto se si ha la necessità di gestire una quantità di dati davvero importante.
Sfruttare elaborazioni già effettuate: questo è il punto di forza di Memcached; infatti raggruppando la cache dei nodi crea una memoria a breve termine che serve per ottimizzare le operazioni ripetute.

Memcached è semplice ma potente. Il suo design semplice promuove un’implementazione veloce, facilità di sviluppo, e risolve molti dei problemi che ci si trova ad affrontare quando si ha a che fare con grandi cache di dati.

Il server funziona ricevendo una serie di coppie chiave-valore e mantenendole in RAM.
In genere è compito della logica applicativa (quindi della programmazione degli scripts php, ruby, phyton ecc…) decidere se effettuare un’operazione di scrittura su memcached oppure di lettura, ed e’sempre compito dell’applicazione computare un hash delle key che invia a memcached e, successivamente, 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.
Facciamo un’altro esempio: immaginiamo di dover gestire la home page di un quotidiano nazionale (a me e’ capitato).
Immaginiamo che il codice che muove quel sito interroghi memcached per evitare che, ad ogni richiesta della home page, vengano fatte delle richieste al database.
Immaginiamo infine che la home page del tuo portale riceva un grosso picco di traffico completamente inatteso (per esempio un terremoto).
Man mano che il traffico aumenta, aumentano le richieste che i front-end devono effettuare al back-end memcached per evitare di interrogare continuamente i database.
Per servire un sito di questo tipo, si sono probabilmente predisposti una mezza dozzina di front-end applicativi, o forse di più, e ciascuno di questi chiama il back-end memcache.
Man mano che il traffico da servire lato pubblico scala verso le decine di Mbit/s, il traffico verso il backend memcached aumenta con un moltiplicatore pari al numero di front-end e questo comincia a saturare la scheda di rete del memcached.
Il traffico aumenta fintanto che la scheda di rete si satura, il sistema crolla, con buona pace di ottimizzazioni lato front-end, bilanciatori di carico, e ottimizzazioni lato SQL.

Se avessimo configurato un cluster memcached alle spalle dei front-end il problema potrebbe comunque presentarsi perchè alcuni nodi del cluster potrebbero avere delle “hot-keys” un po più “hot” delle chiavi degli altri nodi.

Ora, potrebbe anche essere che i memcached contengano solo piccole porzioni di dato e quindi il traffico sulla NIC sia molto contenuto, ma se non siete stati voi ad aver scritto l’applicazione, non potrete esserne certi, quindi si dovra’ quantomeno monitorare la saturazione della NIC e l’eventuale presenza di differenti hot keys sui server.

Come uscirne fuori?
Se la situazione non si è ancora deteriorata del tutto, potreste 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 ad essa associati.
Ma c’e’ da dire che state 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 si deve processare.
In alternativa, può venirci in aiuto uno strumento come mctop, che permette di tracciare il numero di chiamate, richieste al secondo, e l’uso della banda per ogni singolo pacchetto.
In questo modo, sara’ molto più facile individuare le key che tendono a saturare la banda ed indicare dove ai programmatori o tecnici dove devono intervenire.

Non è solo un problema lato server.
Come si puo’ immaginare, questo tipo di problemi va affrontato sia lato sistemi che lato sviluppo
In una situazione di emergenza identificare una “hot key” manualmente, potra’ anche andare bene, ma il punto è che dal lato sviluppo applicativo dovranno mettere mano al codice ed essere in grado di effettuare, per quanto possibile, questo tipo di operazione in autonomia migliorando le fasi di test e di pre produzione.
Diventa cosi’ davvero opportuno avere nella propria infrastruttura, dei sistemi di monitoraggio e di alert, che possano segnalare per tempo gli status ed i possibili rischi di saturazione lato NIC.