In questo articolo parliamo di scalabilità, un termine ampiamente diffuso e di uso quotidiano, cercando di capire di cosa si tratta soprattutto nell’ambito di applicazioni web.

Il termine scalabilità rimanda al concetto di scala di misura. Ad esempio se ci riferiamo alle distanze un conto è parlare di centimetri, un altro di metri o di chilometri. Abbiamo delle scale diverse applicate a differenti situazioni.

In informatica il concetto è simile e in generale si dice che un'applicazione è scalabile quando è in grado di adattarsi al carico applicativo.

Consideriamo un'applicazione web in quanto più facilmente raggiungibile da un elevato numero di utenti (migliaia, centinaia di migliaia o addirittura milioni in situazioni particolari) come nel caso dei motori di ricerca o dei big del commercio elettronico.

Tale software gira su una infrastruttura predisposta per gestire un certo carico massimo, ad esempio mille connessioni contemporanee al minuto.

Finché non si raggiunge questa soglia tutto funziona correttamente.

Tuttavia ci sono delle situazioni in cui possono verificarsi dei picchi di richieste: per esempio se si tratta di una applicazione di e-commerce e siamo prossimi alle festività piuttosto che ad eventi come il Black Friday, oppure nel caso di un sito di informazione e c'è una notizia particolare che desta molto interesse. Di conseguenza anziché avere mille connessioni al minuto possiamo averne diecimila o addirittura centomila e oltre.

Cosa succede in questo caso?

Ci sono di fatto due possibilità:

1. l’applicazione va in crash o meglio non è in grado di rispondere, mostrando la famigerata schermata di errore tanto temuta soprattutto dai siti di commercio elettronico ma in generale da chiunque abbia un’attività sul web, perché una situazione del genere rischia di allontanare il potenziale utente/cliente che si trova di fronte ad un servizio inaccessibile

2. l'applicazione è in grado di adeguarsi a questa situazione, cioè può scalare e gestire il crescente numero di richieste.

Ma come si realizza questa scalabilità?

Diciamo che dipende dall'infrastruttura su cui gira il software, ma in linea di massima anche in questo caso abbiamo due possibili alternative: ricorrere alla scalabilità verticale oppure a quella orizzontale.

La scalabilità verticale, che era tipica o meglio era l’unica alternativa per i sistemi di qualche decennio fa, consiste semplicemente nel potenziare l’hardware del server su cui gira l'applicazione.

Soprattutto in passato i server erano allocati presso le aziende oppure presso i provider dove veniva portata fisicamente la propria macchina o ne veniva affittata una in loco.

In ogni caso questa macchina fisica ha determinate caratteristiche, ovvero una certa potenza, che le consente di gestire un certo numero di connessioni, ad esempio le mille di cui abbiamo parlato in precedenza.

Nel momento in cui si verificano dei picchi di richieste l'unica soluzione possibile è il potenziamento della macchina, ossia incrementare la memoria, montare se possibile un processore più potente, aggiungere maggiore spazio di storage ecc.

In parole povere migliorare l'hardware sostituendo la macchina con una di livello superiore.

Si tratta di una situazione che non permette di gestire degli interventi in real time perché occorre del tempo sia per operare direttamente sulla macchina, che per predisporne un’altra più potente.

In entrambi i casi c’è un conseguente fermo del servizio durante l’operazione, che nella migliore delle ipotesi può essere di qualche ora ma in altri casi richiedere molto più tempo. Se in passato una soluzione del genere poteva andar bene, oggi non sarebbe assolutamente accettabile per l’interruzione del servizio richiesta.

L’alternativa è di sovradimensionare in partenza la macchina, cioè fare una valutazione preliminare ipotizzando le solite mille connessioni, ma di fatto predisporre un hardware in grado di reggerne diecimila o anche centomila.

Anche questa non è una soluzione adeguata perché da un lato non garantisce la copertura di tutte le casistiche (cosa fare nel caso di un milione di connessioni?), dall’altro significa spendere dei soldi rischiando di utilizzare la macchina per una frazione della sua potenza di calcolo, non ammortizzando l'investimento.

L’'avvento del cloud ha permesso di non avere più dell'hardware in casa ma di poterlo affittare all'interno dei datacenter dei provider.

In effetti il cloud non è altro che la possibilità di utilizzare delle infrastrutture che non sono di nostra proprietà nè all'interno della nostra azienda, della nostra casa o del nostro ufficio, ma collocate presso un provider che ci concede il loro utilizzo per far girare le nostre applicazioni. Il vantaggio è enorme nel senso che non dobbiamo acquistare tutto l'hardware e quindi non dobbiamo investire enormi capitali nè occuparci della gestione che è affidata ad esperti del settore.

Fare tutto in casa è sempre possibile ma richiederebbe comunque degli investimenti anche in termini di personale e di competenze, senza considerare altri costi come l’energia elettrica, la sicurezza anche fisica delle infrastrutture, gli aggiornamenti, le riparazioni in caso di guasti.

Con il cloud tutto ciò è a carico del provider e si ha un costo che può essere mensile, orario e basato sulla quantità di risorse utilizzate. Spesso sono disponibili dei pacchetti che permettono risparmi sostanziosi.

Tutto sommato si delega al provider la gestione dell'infrastruttura e inoltre, con l'avvento della virtualizzazione, è possibile avere delle macchine virtuali che emulano in qualche modo l'hardware sottostante. Si tratta di veri e propri processi in esecuzione che, anziché corrispondere a un singolo programma che sta girando (videoscrittura, grafica ecc.), rappresentano l'equivalente di un intero computer all'interno del quale girano delle altre applicazioni.

Tutto ciò ha consentito l’introduzione della scalabilità orizzontale che utilizza un approccio completamente diverso nel senso che, anziché potenziare l’hardware di un server al crescere del carico, possiamo affiancare ulteriori istanze (fisiche o virtuali che siano) così da aumentare le capacità di calcolo e distribuire opportunamente le richieste attraverso un load balancer.

Per tornare al nostro esempio, se abbiamo un server che gestisce mille richieste e in un certo istante ci ritroviamo con duemila di esse possiamo semplicemente aggiungere un nuovo nodo che replica in tutto il server di base, così da duplicare la potenza di calcolo. Ovviamente possiamo aggiungere altre istanze in una modalità potenzialmente infinita.

In un certo senso il picco viene “rilevato” mediante opportune metriche che analizzano costantemente il carico del singolo nodo. Generalmente si considerano l’utilizzo della CPU, della memoria, della rete.

Quando si superano dei valori soglia (che mantengono sempre un margine di operatività per il nodo stesso) in automatico, attraverso il cosiddetto autoscaling, si crea un nuovo nodo speculare rispetto all’altro (ovvero con la stessa configurazione hw e sw), e si distribuisce il carico.

Il tutto senza un limite superiore, salvo eventuali impostazioni adottare per esempio per limitare i costi. Ovvero si può decidere di avere un massimo di X nodi, dopo di che il sistema non accetterà ulteriori richieste segnalando all’utente l’indisponibilità del servizio.

La scalabilità orizzontale è flessibile anche nel verso opposto: ossia al decrescere del carico, quando si scende al di sotto di una soglia minima di utilizzo del nodo, quest’ultimo viene rilasciato così da pagare solo le risorse effettivamente impiegate.

Un grosso vantaggio in termini economici:

1. non ci sono costi iniziali di acquisizione dell’infrastruttura
2. si adegua l’infrastruttura all’effettivo carico applicativo.
3. si pagano solo le risorse utilizzate (quantità e tempo).

[VIDEO YOUTUBE]

[LINKS]

• Concetti di Informatica - Guida facile per tutti
• Tutorial di Spring Boot
• Esercitazioni di Spring Boot
• Corso JPA Java Persistence API
• Flashcards Anki per lo studio
• Libri consigliati