Come comunicato nell’articolo precedente, DisqUS è diventata la nuova piattaforma per commentare i contenuti di AreaNetworking.it. Per chi è curioso, come me, di sapere come facciano a funzionare applicazioni di tali dimensioni ho raccolto qualche dato per capirne meglio le dinamiche.
Partiamo dall’inizio. DisqUS nasce circa 4 anni fa da un’idea di Daniel Ha e Jason Yan,offrendo una piattaforma di discussione centralizzata per siti web. Il team creato per questo progetto è composto da 16 persone di cui 8 sono ingegneri. Ogni ingegnere è product manager del codice da lui sviluppato, permettendo così una rapida messa in produzione delle patch e delle nuove feautures. Gli schemi di traffico raccolti negli anni raccontano un aumento mensile variabile dal 15-20%… insomma non è certo una passeggiata mantenere un sistema del genere.
Parlando di numeri la loro architettura sopporta 25.000 richieste al secondo di picco, 700.000 siti web lo utilizzano, conta 30.000.000 di profili utente, 170.000.000 di commenti e ben 500.000.000 di visitatori.
Questi dati sono di Marzo 2011 cioè praticamente raddopiati dai dati precedenti di Settembre 2010. La cosa interessante è che in questi 6 mesi il numero di server utilizzati nella loro infrastruttura non è cambiato, sono sempre 100. Questo grazie a una tecnica di diagonal scaling, ovvero andare a sostituire e a potenziare i server esistenti variandone anche la quantità (es. invece di aggiungere 3 server monoprocessore, se ne aggiunge soltanto uno biprocessore di potenza superiore).
Questi 100 server sono distribuiti in: 35% dedicati ad Apache + mod_wsgi, 15% dedicati all’esecuzone di batch e script in python, 20% dedicati ai database Redis,Membase e PostgreSQL,20% usati come bilanciatori di carico Haproxy+Heartbeat e il 10% come cache distribuita con Memcached e come proxycache con Varnish.
Le strategie utilizzate per far “resistere” l’applicazione a elevati picchi di utilizzo, derivanti per esempio da eventi di gossip o disastri, sono le seguenti:
- posizionamento degli indici dei database in memoria Ram
- loggare le query lente
- utilizzare il connection pooling
- lo schema dei dati è così rappresentato: utenti,forum,post e thread
- partizionamento verticale a livello di applicazione
- le join tra tabelle vengono eseguite in python e non sul database
- vengono utilizzate delle code per i task più lenti
Video: http://python.mirocommunity.org/video/1886/djangocon-2010-scaling-the-wor
