Definizione, catatteristiche e vantaggi dell’Autoscaling

Definizione, catatteristiche e vantaggi dell’Autoscaling

Autoscaling

In informatica, la quantità di risorse utilizzate da un servizio dipendono generalmente dal suo carico di lavoro, che può variare nel corso del tempo. Associare in modo statico e univoco delle risorse ad un servizio è controproducente per vari motivi. Le risorse assegnate rimarrebbero fruibili esclusivamente dal servizio associato che dovrebbe pagarle anche quando non sono utilizzate.

Per risolvere questo problema al momento viene utilizzata una metodologia chiamata autoscaling. L’autoscaling si divide in due tipologie: verticale e orizzontale. In entrambi i casi l’orchestratore controlla periodicamente dei parametri generici disponibili a livello infrastrutturale che indicano utilizzo delle risorse assegnate (ad esempio l’utilizzo di CPU di una macchina virtuale) e al verificarsi di alcune situazioni ritenute critiche (ad esempio il superamento di una determinata soglia) vengono eseguite alcune azioni generiche. Nel caso di autoscaling verticale, queste azioni generalmente prevedono l’incremento o la rimozione di una risorsa (ad esempio vengono incrementate le CPU disponibili ad una VM). L’autoscaling orizzontale invece prevede la creazione di un’ulteriore istanza che lavorerà in parallelo con l’istanza principale. Questa seconda ipotesi implica che il servizio sia predisposto a lavorare con più istanze attive contemporaneamente, eseguite in parallelo.

Definizione, catatteristiche e vantaggi dell'Autoscaling

 

Vantaggi e svantaggi dell’autoscaling

Il principale vantaggio dell’autoscaling è sicuramente la sua facile implementazione e configurazione. L’implementazione di questa metodologia va fatta esclusivamente nell’infrastruttura ed è completamente trasparente al servizio. Per configurare l’autoscaling è sufficiente definire i parametri da monitorare (utilizzo di CPU, RAM, ecc.), le soglie (ad esempio l’utilizzo della CPU al 50% per più di 10 secondi), le azioni da intraprendere (ad esempio incrementare i core CPU disponibili di una unità) ed eventualmente dei limiti (ad esempio fino ad un massimo di 4). Questi valori possono essere associati ad offerte commerciali che prevedono limiti massimi maggiori a fronte di un costo maggiore.

Il punto di forza dell’autoscaling è la sua generalità, che però risulta essere contemporaneamente un vantaggio e uno svantaggio. É da considerare un vantaggio perché la configurazione è sicuramente più semplice, così come la sua l’implementazione. É uno svantaggio perché la mancata considerazione della semantica del servizio implica il monitoraggio di parametri generici che, per loro natura, descrivono in modo approssimativo le necessità del servizio.

L’impossibilità di controllare parametri più indicativi (ad esempio il numero di utenti che attualmente connessi) è dovuta alla mancanza di comunicazione tra l’infrastruttura e il servizio e alla volontà di mantenere semplice l’implementazione dell’autoscaling. Tuttavia, questa limitazione impedisce all’infrastruttura di capire in modo accurato lo stato e le risorse necessarie al servizio, che devono essere quindi dedotte dai parametri generici.

Esiste inoltre l’impossibilità, da parte dell’infrastruttura, di informare il servizio circa la non disponibilità di una o più risorse necessarie e di notificare la presenza di alcuni malfunzionamenti (ad esempio latenza elevata tra due punti, ecc.). La mancanza di questa interazione impedisce al servizio di adattarsi alle criticità riscontrate dall’infrastruttura.

Primo esempio: Autoscaling basato su parametri generici

Supponiamo di essere il fornitore di un servizio che consente di convertire il formato di alcuni file. Vogliamo inoltre garantire un tempo massimo per la conversione di 1 ora (SLA). Il servizio viene realizzato tramite un software in esecuzione in una virtual-machine istanziata su di un’infrastruttura che supporta l’autoscaling. Il software che si occupa della conversione dei file è stato programmato in modo da utilizzare tutta la CPU disponibile al fine di velocizzare l’elaborazione.

Alla ricezione della prima richiesta di conversione, il software inizia a utilizzare tutta la CPU e l’infrastruttura di conseguenza reagisce aumentando ripetutamente la CPU disponibile fino a raggiungere un limite predefinito. Questi ripetuti incrementi di CPU velocizzano in modo significativo il processo di conversione. Questo però potrebbe non essere il comportamento desiderato. L’obbiettivo è fornire un servizio che rispetta gli SLA definiti che però non sono noti all’infrastruttura. Il software del servizio lavora alla massima velocità possibile perché non conosce lo stato dell’infrastruttura (ad esempio le risorse attuali potrebbero ad un certo punto diminuire o aumentare). L’infrastruttura a sua volta, non conosce le esigenze del servizio (SLA): non sa quante conversioni sono in corso, quando sono iniziate, entro quanto devono finire e come influiscono le risorse disponibili sulle conversioni in corso.

Il caso in esempio può essere esteso prevenendo due tipologie di utenti: free e premium. Quelli classificati come free non pagano nessun abbonamento ma non hanno SLA mentre quelli premium pagano un abbonamento più alto e richiedono uno SLA di 30 minuti. In questo caso, al fine di rispettare gli SLA degli utenti premium, il servizio potrebbe essere interessato anche a pagare un compenso extra all’infrastruttura (per ottenere le risorse necessarie al completamento delle attività nei tempi richiesti) rispetto al caso degli utenti free dove si vuole risparmiare economicamente il più possibile. Quest’ultima logica non può essere implementata con gli orchestratori attuali perché non riuscirebbero ad accedere e interpretare lo stato del servizio.

Secondo esempio: Mancata collaborazione del servizio con l’infrastruttura

Consideriamo un servizio composto esclusivamente da una macchina virtuale che ospita un webserver con il supporto alla compressione delle risposte HTTP. La macchina virtuale del servizio considerato viene istanziata su di un Host dove sono già in esecuzione altre macchine virtuali. In un determinato momento una macchina virtuale legata ad un altro servizio con priorità maggiore inizia a consumare tutta le risorse CPU disponibili sulla macchina Host.

Contemporaneamente, il server web del servizio che stiamo considerando, inizia a ricevere un elevato numero di richieste HTTP con compressione che saturano la CPU disponibile. L’autoscaling non riesce ad aumentare le risorse disponibili perché le risorse CPU sull’host sono esaurite. Quello che succede dunque è una degradazione della qualità del servizio offerto perché le richieste vengono soddisfatte in un tempo maggiore.

Se esistesse una collaborazione tra i servizi e l’infrastruttura, diverse potrebbero essere le soluzioni a questa problematica. Si potrebbe richiedere al servizio che sta consumando la maggior parte delle risorse sull’host di posticipare o dilazionare le attività nel tempo (consideriamo come attività ad esempio la compressione dei file di log o comunque qualsiasi attività non real-time di tipo batch), oppure si potrebbe chiedere al web-server di disattivare la compressione HTTP visto che l’infrastruttura sta affrontando una criticità. La qualità del servizio erogata sarà leggermente inferiore (ci sarà un maggior consumo di banda) ma complessivamente accettabile.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *