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.

Programmare pensando da Sistemista

 

linux-python-logoUna domanda che mi faccio da quando lavoro come sistemista e’ : “quale linguaggio di programmazione dovrei imparare ??“; e’ una domanda facile da formulare, che dovrebbe presupporre un’altrettanto facile risposta, ma ahimè non é così semplice, perlomeno non nel mio caso. Certo, i linguaggi di programmazione non mancano ed in giro ci sono dozzine di fonti di ottima qualità, ma penso comunque che per poter fornire un consiglio si dovrebbe sempre poter conoscere bene chi pone la domanda, ossia:

 

  • il suo background è scientifico o umanistico?
  • conosci bene l’inglese? (poiche’ la maggior parte delle fonti che consiglierei sono in inglese)
  • qual’è la tua età? ecc…!

…..insomma sono tanti i fattori da considerare e tutti hanno il loro peso da non sottovalutare.
In tempi non troppo lontani programmare significava conoscere il funzionamento dei computer a basso livello, comprendere a fondo la loro teoria e la loro struttura. Ma oggi è molto diverso. La gran parte dei programmatori (web 3.0) sono orientati alle applicazioni web/cloud ed i vecchi linguaggi macchina, tipo Assembly, li ha solo sentiti nominare a scuola. Questo anche perche’ i linguaggi ad alto livello (Java, Python…) ci permettono di concentrarci sulla soluzione dei problemi (gli algoritmi) delegando al compilatore la creazione delle istruzioni di basso livello.

Certo questa e’ una buona notizia ma, partendo da me stesso, se non fai il programmatore ed un linguaggio di programmazione ti serve per crearti scripts di ottimizzazione dei sistemi , non e’ pensabile dover conoscere 5/6 linguaggi diversi ecco perche’ in campo sistemistico resistono gli ottimi script Bash oppure l’ardimentoso Perl.

Se mi avete seguito e siete almeno parzialmente d’accordo con l’analisi fatta vi ricompenso con lo stesso consiglio che mi sono dato qualche settimana fa: Python.

Non mi voglio dilungare nella presentazione di questo linguaggio di cui credo abbiate per lo meno sentito nominare, le cui caratteristiche principali di funzionalita’, operabilita’, performance ecc… lo rendono tra i migliori da imparare anche per usi che esulano dalla programmazione allo stato puro; per altri dettagli od info potete leggere l’articolo dal seguente URL “caratteristiche del linguaggio Python“.

Quello che voglio segnalare e’ che molto spesso nella grande, a volte troppa, quantita’ di materiale recuperabile, spesso non si trova qualcosa adatto davvero alle nostre esigenze e che renda l’avvicinamento e la comprensione di un nuovo linguaggio facile, senza annoiare.

Pensare da Informatico e’ un libro che svolge bene il suo compito avvicinando i nuovi utenti a questo ottimo linguaggio in modo guidato e lineare proprio perche’ frutto delle esigenze di un’insegnante che voleva spiegare ai propri alunni un nuovo modo di programmare. Il libro originale e’ in inglese ma ne esiste un’ottima versione PDF tradotta in Italiano, questo e’ il link per il download PDF , mentre questo e’ il link per la versione WEB .

La versione originale “How to Think a Computer Scientist ” sottotitolo (Learning with Python) 3rd edizione e’ scritta da [Peter Wentworth, Jeffrey Elkner, Allen B. Downey, and Chris Meyers ] .

Buona lettura !

GreenSQL ora su AWS

Greensql_AWSbigGreenSQL offerta Database Secutiry su Amazon Web Services (AWS)

9 Luglio 2014, GreenSQL, azienda leader nelle soluzioni di sicurezza dei dati (DB), ha annunciato al mondo la disponibilita’ di una soluzione appositamente pensata per la piattaforma AWS, per l’appunto ” GreenSQL per AWS ” pronta a dare tutta la potenza ed i livelli di sicurezza certificati da GreenSQL sia in locale che ora anche nel Cloud.

Le caratteristiche principali sono le seguenti :

  • Versione del prodotto (ad oggi) 2.6.7
  • Sistema Operativo Linux / Unix, Linux Amazon 2.014,03
  • Architettura64-bit Amazon Macchina Image (AMI)
  • Servizi AWS AmazonEC2, AmazonEBS


Descrizione del prodotto
(alcuni interessanti video si possono trovare sul canale Youtube di GreenSQL)

GreenSQL fornisce soluzioni avanzate di sicurezza per database, proteggendoli da attacchi di SQL injection (ad esempio SSN, numeri di carte di credito, e-mail, password amministrative ecc…), mascherando i dati sensibili e monitorando costantemente la veridicita’ dei dati di accesso degli utenti che dovranno soddisfare vari livelli di conformita’ a normative quali PCI e HIPAA. Una volta installato come front-end delle vostre applicazioni web nel Cloud, GreenSQL sara’ in grado di mimetizzare perfettamente e proteggere le applicazioni, i database ed i dati in essi contenuti, questo poiche’ GreenSQL e in grado di individuare automaticamente e mascherare i dati sensibili memorizzati nel database.

Inoltre e’ in grado di:

– bloccare in tempo reale tutte le SQL injection rilevate;  

–  monitorare le attività sul database eseguite dagli amministratori di sistema e dai DBA

– attuare la separazione delle funzioni creando le regole base per le restrizioni di accesso ai dati filtrando ed accoppiando le utenze ad apposite liste d’indirizzi IP geografici ….

Se quello che avete letto vi incuriosisce e volete saperne di piu’ in merito vi invito a leggere gli articoli precedenti su GreenSQL quali :

DB fate largo ai No-SQL

nosql_logoI Database NoSQL

NO-SQL è un movimento che negli ultimi anni si è molto affermato, producendo dei risultati soddisfacenti con la creazione di progetti e iniziative utilizzate anche su larga scala. Tale movimento vuole “rompere” la storica linea dei database relazionali e definire delle nuove linee guida per l’implementazione di database che non utilizzano il linguaggio di interrogazione SQL e non siano strettamente legati ad una definizione “rigida” dello schema dati.
La filosofia del NO-SQL si può riassumere nei seguenti punti, partendo dalla domanda “Perchè avere altri DBMS se esistono quelli relazionali?”:

  1. I database relazionali sono troppo costosi e spesso, quelli che svolgono bene il loro lavoro, sono solo commerciali. NO-SQL abbraccia totalmente la filosofia open-source;
  2. NO-SQL è semplice da usare e non occorre uno specialista di DBMS. Il paradigma di programmazione è, infatti, ad oggetti;
  3. I dati sono altamente portabili su sistemi differenti, da Macintosh a DOS;
  4. Non definisce uno schema “rigido” (schemaless) e non occorre prototipare i campi, per cui non esistono limiti o restrizioni ai dati memorizzati nei database NO-SQL;
  5. Velocità di esecuzione, di interrogazione di grosse quantità di dati e possibilità di distribuirli su più sistemi eterogenei (replicazione dei dati), con un meccanismo totalmente trasparente all’utilizzatore;
  6. I DBMS NO-SQL si focalizzano su una scalabilità orizzontale e non verticale come quelli relazionali.

A questo punto passiamo a fare una comparazione tra quelli che attualmente sono tra i piu’ utilizzati , quali :

Cassandra, MongoDB, CouchDB, Redis, Riak, HBase, Membase e Neo4j :

** (vedi anche precedente articolo Not Only Sql)
– CouchDB

Scritto in: Erlang
Punto principale: Consistenza DB consistency, facilità d’uso
Licenza: Apache
Protocolli: HTTP/REST
Replicazione bidirezionale continua o ad-hoc con individuazione dei conflitti, replicazione master-master
MVCC – le operazioni di scrittura non bloccano le letture
Sono disponibili le versioni precedenti dei documenti
Progettazione crash-only (reliable)
Necessità di compattazioni nel tempo
Viste: embedded map/reduce
Viste formattate: lists & shows
Possibilità di validazione server-side dei documenti
Possibile autenticazione
Aggiornamenti real-time attraverso _changes (!)
Gestione degli allegati e, CouchApps (standalone js apps)
libreria jQuery inclusa
Utilizzo ideale: Per accumulazione dei dati con cambi occasionali sui quali vengono eseguite query predefinite. Situazioni in cui la gestione delle versioni è importante.
Per esempio: CRM, sistemi CMS. Situazioni in cui la replicazione master-master è una caratteristica interessante (ad esempio multisito).

– Redis

Scritto in: C/C++
Punto principale: Velocità
Licenza: BSD
Protocolli: Telnet-like
Disk-backed in-memory database,
In questo momento non include il disk-swap (VM e Diskstore sono stati abbandonati)
Replicazione master-slave
Recupero di valori semplici o intere tables a partire da una chiave
suppporto ad operazioni complesse come ZREVRANGEBYSCORE.
INCR (incremento) e  simili (molto utili per gestire limitazioni di valore e statistiche)
permette l’uso di insiemi (sets) e operazioni su essi (unione/differenza/intersezione)
permette l’uso di liste (lists) e  operazioni su esse (queue; blocking pop)
permette l’uso di hashes (oggetti dotati di campi)
permette l’uso di insiemi ordinati (utili per classifiche, e ricerche su range di valori)
Redis implementa correttamente le transazioni (!)
I valori memorizzati possono avere una scadenza temporale (sistemi di cache)
Implementa facilmente il messaging Publisher/Subscriber (!)
Utilizzo ideale: Adatto a moli di dati (residenti in memoria) di dimensione nota che cambiano frequentemente .
Per esempio: Quotazioni azionistiche. Analisi. Gestione dati in Real-time. Comunicazioni in Real-time.

– MongoDB

Scritto in: C++
Punto principale: Mantiene alcune proprietà utili del modello SQL (Query, index) molto facili da usare.
Licenza: AGPL (Drivers: Apache)
Protocollo: Specifico, binario (BSON)
Replica Master/slave (munita di  failover quando si usano i  “replica sets”)
Lo Sharding è parte integrante del sistema
Le intterrogazioni a db (queries) sono espressioni javascript
Permette l’uso di funzion i javascript lato server
Update-in-place migliore rispetto a CouchDB
Usa “memory mapped files” per la persistenza dei dati
Favorisce la velocità rispetto alle funzionalità implementate
Journaling (opzione –journal) fortemente consigliato
Sui sistemi a 32bit risente di una  limitazione sulla quantità di dati a circa 2.5Gb
Un database vuoto occupa comunque 192Mb
GridFS per la memorizzazione di “big data + metadata” (effettivamente non è un  FS)
Indicizzazione geospaziale Geospatial indexing
Utilizzo ideale: se si necessita di query dinamiche. Se si preferisce lavorare con gli indici rispetto ad usare algoritmi map/reduce. Buono se si ha bisogno di velocità quando si lavora con grandi moli di dati.  Adatto a tutti gli scenari in cui si usa CouchDB e non si può scegliere quest’ultimo perchè i dati cambiano troppo riempiendo la memoria fisica.
Per esempio: tutte le situazioni in cui si vorrebbe usare MySQL o PostgreSQL senza avere colonne definite a priori.

– Riak

Scritto in: Erlang & C, some Javascript
Punto principale: Fault tolerance
Licenza: Apache
Protocollo: HTTP/REST o custom binary
Trade-offs modulabili per replica e distribuzione (N, R, W)
Hooks di pre- e post-commit in JavaScript o Erlang, per la validazione e la sicurezza.
Map/reduce in JavaScript o Erlang
Links & link walking per utilizzarlo come database a grafi
Indici secondari: ricerca nei metadati
Supporto per oggetti di grandi dimensioni (Luwak)
Edizioni sia “open source” che “enterprise”
Ricerca full-text, indexing e querying con il Riak Search server (beta)
Sta migrando lo storing di backend da “Bitcask” al “LevelDB” di Google
La multi-site replication replication senza alcun master e il monitoring SNMP necessitano di una licenza commerciale
Utilizzo ideale: se si vuole qualcosa di simile a Cassandra (Dynamo), ma non si ha nessuna intenzione di avere a che fare con la realtiva inerente complessità. Se si ha bisogno di un’ottima scalabilità, disponibilità e fault-tolerance per un solo sito ma si è disposti a pagare per la replica multi-sito.
Per esempio: Raccolta dei dati di point-of-sales. Sistemi di controllo aziendali. Situazioni in cui anche il downtime di alcuni secondi può essere rilevante. Potrebbe essere anche utilizzato come un web server estremamente aggiornabile.

– Membase

Scritto in: Erlang & C
Punto principale: Compatibile con memcache ma con persistenza e clustering
Licenza: Apache 2.0
Protocollo: memcached con estensioni
Accesso molto veloce ai dati mediante chiave (200k+/sec)
Persistenza su disco
Tutti i nodi sono identici (replicazione master-master)
Fornisce un sistema a buckets simile a memcached
De-duplicazione delle scritture per ridurre IO
Interfaccia GUI per la gestione dei cluster molto interessante
Aggiornamento software senza mettere offline il database
Proxy di connessione per il pooling e il multiplexing (Moxi)
Utilizzo ideale: Qualsiasi applicazione dove un bassa latenza dell’accesso ai dati, un’alta concorrenzialità e un’alta disponibilità degli stessi sono requisiti chiave.
Per esempio: Casi in cui c’è necessità di bassa latenza come l’erogazione di servizi di pubblicità mirata (ad targeting)  o alta concorrenza come il giochi online (per esempio Zynga).

– Neo4j

Scritto in: Java
Punto principale: Database a grafi o dati connessi
Licenza: GPL, salcune caratterstiche con AGPL/commerciale
Protocollo: HTTP/REST (o incluso in  Java)
Standalone, o includibile nelle applicazioni Java
Piena conformità ACID (incluso i dati durable)
Sia i nodi che le releazioni possono avere dei metadati
Linquaggio di query basato su pattern-matching (“Cypher”)
Può anche essere usato il linguaggio di attraversamento dei gravi “Gremlin”
Indicizzazione dei nodi, delle chiavi e delle relazioni
Piacevole interfaccia di amministrazione web
Sono disponibili diversi algoritmi di ricerca dei percorsi
Ottimizzato per le letture
Ha le transazioni (nelle API Java)
Si può usare il linguaggio di scripting Groovy
Backup online, monitoraggio avanzato e alta disponibilità con licenza AGPL/commerciale
Utilizzo ideale: Per dati interconnessi, semplici o complessi, con struttura a grafo. In questo senso Neo4j is è un po’ diverso dagli altri database noSQL.
Per esempio: Relazioni sociali, collegamenti nei trasposti pubblici, mappe di strade, topologie di rete.

– Cassandra

Scritto in: Java
Punto principale: Migliore di BigTable e Dynamo
Licenza: Apache
Protocollo: Proprietario, binario (Thrift)
Distribuzione e replicazione attivabile (N, R, W)
Query possibili mediante colonne e insiemi di chiavi
Carattersitiche simili a BigTable: colonne, famiglie di colonne
Indici secondati
La scrittura è molto più veloce della lettura(!)
Mappatura e riduzione possibile mediante Apache Hadoop
I admit being a bit biased against it, because of the bloat and complexity it has partly because of Java (configuration, seeing exceptions, etc)
Utilizzo ideale: Quando si scrive più che leggere (logging). Se ogni componente del sistema deve essere in Java.
Per esempio: Sistemi bancari e industria finanziaria.
Inoltre, siccome le scritture sono più veloci delle letture, una nicchia naturale è l’analisi dei dati in tempo reale.

– HBase

Scritto in: Java
Punto principale: miliardi di righe con milioni di colonne
Licenza: Apache
Protocollo: HTTP/REST (anche Thrift)
Modellato dopo BigTable
Mappatura e riduzione con Hadoop
Costrutti query push down attraverso scansione lato server e con filtri per il get
ottimizzazione per le query in tempo reale
E’ un gateway Thrift con alte performance
HTTP supports XML, Protobuf, and binary
Cascading, hive, and pig source and sink modules
Shell basata su Jruby (JIRB)
Punti di ripristino multipli
Rolling restart for configuration changes and minor upgrades
L’accesso random ai dati è paragonabile a quello di MySQL
Utilizzo ideale: Se siete innamorati di BigTable.   e quando c’è la necessità di un accesso in lettura e scrittura, random e in tempo reale alla grande quantità di dati.
Per esempio: il database dei messaggi in Facebook.

 

La scelta e’ davvero varia a seconda del compito che vi serve maggiormente venga svolto dal DB che avrete prescelto, quindi perche’ non provarli ?