Bilanciamento di server obsoleti

Obsolescenza non programmata
Quando si lavora per aziende che lavorano su software ormai consolidati, spesso capita di trovare programmi scritti in linguaggi ormai morti e sepolti che, nella pur giurassica età anagrafica, reggono ancora egregiamente il peso dell'azienda sulle loro spalle.

In questi casi il problema non è di funzionalità: nel bene o nel male fanno tutto quello che serve, il problema più che altro è prestazionale: è difficile che un programma pensato e progettato da più di 10-15 anni si possa facilmente scalare.

Questo significa che, aumentando gli utilizzatori ed arrivando al limite di utenti paralleli, difficilmente si riuscirà a far lavorare altre persone sullo stesso programma.

L'assunto vale sia per quanto riguarda i vecchi "fat client", che per le prime applicazioni web, che magari erano pensate e configurate per poche persone, ma che col tempo hanno iniziato a servire un numero sempre più alto di utenti, fino ad arrivare al punto di collasso.

Natale
Chi gestisce siti di ecommerce sa che, in certi periodi dell'anno, ci sono dei picchi d'accesso da parte dei propri utenti.
Uno dei picchi maggiori è dato dal Natale.
In questi momenti i siti peggio pensati o strutturati per un traffico molto minore, subiscono dei vistosi rallentamenti.

Solo per parlare di storia recente, mi viene in mente la sera in cui Gnammo ha partecipato a Shark Tank. Per alcune ore il sito è diventato inaccessibile.

Un caso? Non credo
Questo è solo un esempio, ma capite quanto sia grave il problema su un sito di ecommerce oppure su un gestionale che deve reggere l'intera azienda.

Possibili soluzioni
Anche in questo caso mi sono trovato di fronte a un'applicazione non scalabile: la progettazione di parecchi anni prima non aveva previsto una evoluzione così importante sul numero di utilizzatori: quando superavano una certa soglia, la memoria si saturava, rallentando ogni operazione e bloccando l'operatività di qualsiasi utilizzatore.

Come potevo risolvere il problema?

* Aumentare la memoria: purtroppo questa soluzione non poteva essere messa in atto, dato che l'applicazione utilizzava già la massima ram che il linguaggio utilizzato poteva indirizzare.

* Aggiornare la versione di linguaggio dell'applicazione: anche in questo caso non si poteva fare, dato che l'applicazione era fortemente legata ad una vecchia versione di Jboss (3.2.1), quindi occorreva aggiornare sia il linguaggio che l'application server. Attività che non poteva concludersi in poche giornate di lavoro: occorreva ricontrollare tutto in modo che fosse garantita la piena retrocompatibilità.

Vi era quindi un forte vincolo che non ci permetteva di modificare l'applicazione nel breve tempo e potevamo lavorare solamente a livello di infrastruttura.

YouPorn
Anche se a molti la cosa può far ridere, Youporn è uno dei siti meglio gestiti al mondo: il suo traffico è di circa 300000 richieste al secondo, anche se le slide sono di 3 anni fa, vi consiglio una veloce lettura

La cosa affascinante di Youporn è data dal fatto che riescono a fare l'upgrade dei propri servizi senza avere un down del sistema.
Questo significa che, mentre navigo sul loro sito (anche se probabilmente sono distratto da altro), i sistemisti della piattaforma sono in grado di aggiornarmi l'intera infrastruttura senza darmi un disservizio (almeno in teoria).

La domanda è: come possono fare questa cosa?

La risposta è: usando i giusti prodotti software.

HAProxy
Nel loro stack applicativo un elemento molto interessante è dato da HAProxy, un bilanciatore in grado di dividere il traffico HTTP fra macchine diverse.

Fra la moltitudine quasi infinita di parametri che è in grado di gestire HAProxy, c'è anche la possibilità di bilanciare i servizi in base alla sessione attiva sul client.

Cosa vuol dire questo? Che posso bilanciare il traffico fra più server, completamente svincolati fra di loro, e HAProxy andrà a scegliere la macchina corretta, in base a dove, i vari client, hanno ricevuto la sessione.

Per esempio, se creo una rete con il server A e il server B e un client C inizia una sessione con A, HAProxy memorizza questa informazione e utilizzare sempre A per tutte le chiamate di C.

In questo modo non sono costretto a condividere le sessioni fra server diversi e soprattutto supero gli eventuali problemi che potrei avere con un round robin puro fra i server A e B, dove la sessione di A non è conosciuta da B

Ripensiamo al nostra problema
Nel nostro caso dove, lato applicativo, non potevamo toccare nulla, è bastato crearne un server gemello, su un'altra macchina, e bilanciare il traffico su sessione.

In questo modo abbiamo scalato la potenza di elaborazione del programma, senza toccarlo, ma semplicemente aggiungendo un elemento software fra i client remoti e il vecchio server, che in questo modo poteva continuare ad effettuare il suo lavoro.

Conclusioni
A volte l'ottimizzazione di un prodotto web può passare da una modifica di architettura, senza modificare il comportamento applicativo e permettendo, a costi estremamente contenuti, di ottenere un sistema più veloce e in grado di fornire un servizio a un numero di client molto maggiori rispetto a quelli per il quale era stato pensato.

Se anche tu hai questi problemi col tuo sito, non esitare a contattarmi, studieremo insieme come risolverli

ciao
Matteo