Scalabilità. Architettura dei Sistemi Software. Luca Cabibbo. dispensa asw260 marzo Fonti

Transcript

1 Luca Cabibbo Architettura dei Sistemi Software dispensa asw260 marzo 2019 Rule 50 Be Competent. Martin L. Abbott and Michael T. Fisher 1 - Fonti Abbott, M.L. and Fisher, M.T. The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise, second edition. Addison-Wesley, Abbott, M.L. and Fisher, M.T. Scalability Rules: 50 Principles for Scaling Web Sites. Addison-Wesley, [SAP] Chapter 12, Other Important Quality Attributes [SSA] Chapter 26, The Performance and Scalability Perspective 2

2 Obiettivi - Obiettivi e argomenti presentare la qualità della scalabilità illustrare alcune attività, principi e regole di progettazione per la scalabilità Argomenti scalabilità progettare per la scalabilità discussione 3 * (scalability) la capacità del sistema di gestire volumi di elaborazione crescenti nel futuro, se richiesto molti sistemi sono infatti soggetti a un qualche tipo di incremento nel carico di lavoro un incremento di carico può riguardare, ad es., un incremento del numero di utenti del sistema, oppure del numero di richieste fatte dagli utenti al sistema, oppure della mole di dati che il sistema dove gestire la scalabilità riguarda la capacità del sistema di accettare questi incrementi di carico, senza un impatto negativo nei confronti di altre qualità (in particolare, di prestazioni e disponibilità) 4

3 Un aumento del carico di lavoro, se non viene opportunamente gestito, può infatti avere un impatto negativo dapprima sulle prestazioni all aumentare del carico di lavoro, aumenta il livello di carico delle diverse risorse del sistema quando il livello di utilizzazione della risorsa del sistema più critica (il cosiddetto collo di bottiglia) si avvicina alla sua capacità (ovvero, quando quella risorsa è satura), allora il comportamento della risorsa peggiora, più o meno improvvisamente, e fa degradare le prestazioni dell intero sistema poi sulla disponibilità la saturazione delle risorse può poi provocare anche un interruzione di servizio che, se il carico non diminuisce, può ripresentarsi anche se si tenta di riavviare il servizio 5 Rilevanza della scalabilità La scalabilità è importante soprattutto quando un organizzazione usa il proprio sistema software per offrire i propri servizi direttamente ai propri clienti finali è infatti profondamente diverso realizzare un sistema software rivolto ai soli impiegati di un organizzazione (che sono in genere centinaia o migliaia) oppure direttamente ai clienti dell organizzazione (che possono essere diversi ordini di grandezza di più) peraltro, il contesto competitivo attuale impone a molte organizzazioni di realizzare sistemi software per trattare direttamente con i propri clienti la sopravvivenza di queste organizzazioni può essere legata a quanto riescono a fare per sostenere la scalabilità dei loro sistemi software 6

4 Requisiti di scalabilità I requisiti di scalabilità vengono di solito espressi in termini di incremento del carico di lavoro che il sistema deve essere in grado di assorbire in particolari periodi di tempo mentre i suoi requisiti relativi a prestazioni e disponibilità vengono ancora soddisfatti un incremento di carico può riguardare, ad esempio il numero degli utenti (concorrenti) del sistema il numero delle richieste, delle transazioni o dei messaggi da gestire (nell unità di tempo) il volume dei dati da gestire la complessità dei compiti da eseguire 7 Requisiti di scalabilità I requisiti di scalabilità vengono di solito espressi in termini di incremento del carico di lavoro che il sistema deve essere in grado di assorbire in particolari periodi di tempo mentre i suoi requisiti relativi a prestazioni e disponibilità vengono ancora soddisfatti inoltre, un incremento di carico può essere di lungo termine (ed anticipato nel suo arrivo) ad es., un incremento del numero delle transazioni del 20% ogni anno transiente (ed anticipato nel suo arrivo) ad es., un incremento del 100% del numero giornaliero di transazioni nel periodo natalizio rispetto al carico medio transiente ma non anticipato nel suo arrivo ad es., un incremento rapido ma temporaneo del numero di accessi a un sito di notizie in relazione ad una notizia importante 8

5 * Progettare per la scalabilità In questa dispensa, la trattazione sulla progettazione per la scalabilità si basa soprattutto su The Art of Scalability [Abbott and Fisher] anche [SSA] propone delle tattiche per la scalabilità nel contesto più ampio della prospettiva per le prestazioni e la scalabilità in effetti queste due qualità sono correlate fortemente, e progettare per le prestazioni è in qualche modo un prerequisito per la progettazione per la scalabilità la scalabilità è correlata fortemente anche alla disponibilità e diverse tattiche per la disponibilità possono sostenere anche la progettazione per la scalabilità qui ci concentriamo soprattutto sui principi e le regole di progettazione più specifiche per la scalabilità 9 - orizzontale e verticale Due approcci principali alla scalabilità scalabilità verticale (scaling up) sostituire i componenti hardware esistenti con dei componenti hardware simili ma più potenti ad es., sostituire un server con un server con più processori, più memoria, ecc. scalabilità orizzontale (scaling out) aggiungere più componenti simili a un insieme di componenti già in uso nel sistema ad es., aggiungere altri server ad un cluster di server 10

6 orizzontale e verticale Va notato che questi due approcci (migliorare le risorse oppure aggiungere risorse), da soli, non sono sufficienti a garantire la scalabilità l efficacia di una soluzione dipende da come il sistema software è in grado di utilizzare i componenti più potenti oppure aggiuntivi per accomodare l incremento nel carico di lavoro se il sistema software non è stato progettato per questo, allora non trarrà vantaggio dalla presenza delle nuove risorse in generale, ciascuno scenario per la scalabilità dovrà descrivere come ciascun incremento nel carico possa essere effettivamente gestito utilizzando degli opportuni componenti sostitutivi o aggiuntivi 11 orizzontale e verticale In pratica, l approccio della scalabilità orizzontale è in genere più efficace di quello della scalabilità verticale la scalabilità verticale ovvero sostituire un componente monolitico con un componente simile ma più potente può essere inefficace a fronte di incrementi molti rapidi del carico inoltre, in pratica può essere efficace solo nei casi in cui l incremento atteso del carico sia inferiore all evoluzione tecnologica attesa nello stesso periodo di riferimento (ad es., in relazione alla legge di Moore) viceversa, la scalabilità orizzontale basata sull aggiunta di componenti simili aggiuntivi ai componenti esistenti consente di perseguire anche una scalabilità quasi infinita l approccio della scalabilità orizzontale è di solito più adeguato di quello verticale e per questo consideriamo qui soprattutto la scalabilità orizzontale 12

7 Elasticità Un altro vantaggio della scalabilità orizzontale è che è compatibile con l elasticità (elasticity) o scalabilità elastica una forma di scalabilità orizzontale legata all aggiunta di risorse (di solito virtuali) acquisite rapidamente da un pool di risorse condivise soprattutto nel cloud 13 - Verificare la scalabilità I test di carico sono utili per fornire una base quantitativa nella progettazione per le prestazioni e la scalabilità i test per le prestazioni sono basati sulla simulazione del carico di lavoro atteso durante l esecuzione del test vengono misurati sia parametri per le prestazioni (come i tempi di risposta e il throughput) che il livello di utilizzazione delle diverse risorse computazionali questi test richiedono un ambiente di esecuzione il più possibile simile all ambiente di produzione 14

8 Verificare la scalabilità I test di carico sono utili per fornire una base quantitativa nella progettazione per le prestazioni e la scalabilità i test per la scalabilità sono analoghi, ma misurano le prestazioni e il livello di utilizzazione delle risorse anche a fronte di carichi di lavoro crescenti (ad es., nel numero di utenti concorrenti o nel volume delle transazioni) questi test possono essere eseguiti in un ambiente di esecuzione simile a quello di produzione per determinare i limiti di quell ambiente inoltre, questi test andrebbero ripetuti a fronte di ambienti di esecuzione di capacità via via crescente per determinare l efficacia della soluzione di scalabilità scelta (verticale oppure orizzontale) inoltre, i test di carico andrebbero ripetuti (come test di regressione) anche a fronte di ogni nuova versione del software 15 - Capacità residua La capacità residua (headroom) di un ambiente di esecuzione (in una sua certa configurazione) è una misura della quantità di capacità del sistema che non viene attualmente utilizzata e che è pertanto libera per servire un certo incremento del carico di lavoro è utile determinare la capacità residua proprio per comprendere l incremento di carico che quella configurazione del sistema può ancora sopportare e per capire quando potrebbero iniziare dei problemi se la configurazione non viene modificata 16

9 Capacità residua Consideriamo un semplice esempio un sistema potrebbe avere una capacità massima di 100 t/s (transazioni al secondo) determinata con un test di carico se il carico attuale è di 30 t/s (nell utilizzazione di picco), allora la capacità residua è di 70 t/s se è previsto un incremento del carico di lavoro di 10 t/s al trimestre, allora la capacità residua è di 7 trimestri 17 Capacità residua Consideriamo un esempio un pochino più complesso un sistema potrebbe avere una capacità massima (teorica) di 100 t/s un carico attuale (di picco) di 30 t/s la percentuale di utilizzo ideale potrebbe essere del 50% infatti non è mai una buona idea che il livello di utilizzazione di una risorsa raggiunga il 100% sono previste ottimizzazioni per ulteriori 20 t/s (teoriche) la capacità residua è (100+20)*50% - 30 = 30 t/s se è previsto un incremento del carico di 10 t/s al trimestre, allora la capacità residua è di soli 3 trimestri 18

10 - Principi architetturali per la scalabilità The Art of Scalability [Abbott and Fisher] presenta diversi principi di progettazione per la scalabilità i principi più importanti sono la scalabilità orizzontale va in genere preferita alla scalabilità verticale questo richiede di progettare per una distribuzione del carico su più nodi computazionali inoltre, affinché il carico di lavoro possa essere distribuito su più nodi computazionali in modo efficace ai fini della scalabilità, il sistema deve essere preferibilmente basato su interazioni asincrone servizi stateless anche il caching è utile ai fini della scalabilità queste idee sono discusse in maggior dettaglio nel seguito di questa dispensa 19 - Distribuzione del carico di lavoro Un idea fondamentale nella progettazione per la scalabilità orizzontale di un sistema software è suddividere i suoi compiti di lavoro in più parti per poterli distribuire tra più lavoratori l intuizione è che un sistema scalabile orizzontalmente deve essere formato da diversi lavoratori su cui viene distribuito il lavoro complessivo che il sistema deve svolgere in modo tale che, se la quantità di lavoro da svolgere aumenta, allora il sistema possa scalare aumentando il numero di lavoratori il lavoro da decomporre è formato da servizi e dati i lavoratori su cui viene decomposto il lavoro sono genericamente chiamati nodi (di solito sono dei server) ogni nodo è responsabile di alcuni servizi e/o alcuni dati ci sono più modi per decomporre, ai fini della scalabilità, un insieme di servizi e di dati su più nodi 20

11 Distribuzione del carico di lavoro Ai fini della scalabilità, ci sono più modi per decomporre un insieme di servizi e di dati su più nodi clienti clonare cose (X) separare cose diverse (Y) un nodo servizi e dati separare cose simili (Z) 21 - Cubo della scalabilità Il cubo della scalabilità [Abbott and Fisher] è un metodo per aiutare a suddividere e distribuire i servizi e i dati di un sistema software in più parti, per sostenere la scalabilità orizzontale del sistema gli assi del cubo della scalabilità (chiamati X, Y e Z) rappresentano modi diversi di decomporre servizi e dati su più nodi e costituiscono altresì dei criteri per l identificazione dei nodi da usare nel sistema e delle loro responsabilità il cubo della scalabilità è anche chiamato AKF Scale Cube dove AKF è il nome della società fondata da Abbott, Keeven e Fisher 22

12 Cubo della scalabilità Il cubo della scalabilità è un modello che rappresenta tre diversi modi per decomporre un sistema per la scalabilità ciascuna modalità di decomposizione è rappresentata da un diverso asse di scalabilità (X,Y,Z) Y axis Work Distributed by Type of Action near infinite scale X axis All Work Evenly Distributed 23 starting point Cubo della scalabilità Il cubo della scalabilità è un modello che rappresenta tre diversi modi per decomporre un sistema per la scalabilità l origine del sistema il punto di coordinate (0,0,0) rappresenta un sistema monolitico (non decomposto) è di solito il punto di partenza nella progettazione è un progetto che non è scalabile orizzontalmente ogni asse rappresenta un possibile modo per effettuare una decomposizione elementare del sistema per sostenerne la scalabilità la decomposizione può anche avvenire lungo più assi (che sono indipendenti tra loro) con un effetto benefico moltiplicativo sulla scalabilità [Abbott and Fisher] affermano che queste tre modalità di decomposizione (se applicate correttamente) consentono di scalare quasi qualunque sistema 24

13 Asse X del cubo clonare cose L asse X del cubo (clonare cose ) rappresenta la clonazione di tutti i servizi e i dati su più nodi senza nessuna preferenza o parzialità è una forma di duplicazione orizzontale, in cui ogni nodo eroga gli stessi servizi degli altri nodi ogni richiesta per un servizio da parte di un client può essere girata a un nodo qualunque del sistema è dunque necessario anche un load balancer anche i dati (o la base di dati) sono replicati dunque ci sono più copie dei dati, e ogni nodo contiene una copia di tutti i dati un operazione di lettura può essere svolta da un nodo qualunque le operazioni di scrittura vanno invece propagate a tutti i nodi è dunque necessario anche un meccanismo di replicazione dei dati 25 Asse Y del cubo separare cose diverse L asse Y del cubo (separare cose diverse) rappresenta una decomposizione delle responsabilità ai diversi nodi per tipo di servizio oppure per tipo di dati oppure per una loro combinazione è una forma di divisione per funzione, servizio o risorsa (dato) in una decomposizione orientata ai servizi, i componenti e i dati necessari per erogare un servizio sono separati dai componenti e dai dati necessari per erogare altri servizi esempi di decomposizioni in un sito di commercio elettronico separare le funzioni di (a) login, (b) consultazione del catalogo prodotti e (c) acquisto oppure separare i dati relativi ai (i) clienti da quelli relativi ai (ii) prodotti e agli (iii) acquisti in generale, questa decomposizione porta a separare sia i servizi che i dati su cui essi operano anche se la separazione non è sempre completa 26

14 Asse Z del cubo separare cose simili L asse Z del cubo (separare cose simili) rappresenta una decomposizione delle responsabilità relativa (in genere) ai clienti del sistema viene effettuato un partizionamento dei clienti in base a una qualche loro proprietà ad es., in genere in base alla loro posizione geografica, oppure in base al loro nome o ad un loro identificatore ciascun gruppo di clienti (shard) viene assegnato ad un nodo diverso i dati del sistema sono suddivisi sulla base dei gruppi di clienti anche se talvolta è necessario che alcuni dati vadano replicati su tutti i nodi invece, ciascun nodo deve in genere ospitare tutti i servizi del sistema tutte le operazioni richieste da un certo cliente vengono gestite dal nodo assegnato al suo gruppo 27 Cubo della scalabilità Tre diverse modalità elementari per decomporre un sistema per la scalabilità clonare cose (X) separare cose diverse (Y) separare cose simili (Z) 28

15 - dei servizi e dei dati Il cubo della scalabilità definisce un modello generale per la decomposizione dei servizi e dei dati di un sistema software è utile però fare anche delle considerazioni separate da una parte relativamente alla decomposizione dei servizi e delle applicazioni, e dall altra alla decomposizione dei dati e delle basi di dati infatti, in entrambi i contesti valgono lo stesso modello e gli stessi principi ma l implementazione della decomposizione relativa ai servizi e/o ai dati può variare in modo anche abbastanza significativo per dati si intendono soprattutto i dati persistenti del sistema i dati possono essere memorizzati in una base di dati relazionale o anche non relazionale (ad es., NoSQL) inizialmente consideriamo la decomposizione lungo un singolo asse la decomposizione lungo più assi è discussa dopo 29 Asse X per la scalabilità dei servizi L asse X del cubo rappresenta la clonazione di tutti i servizi applicativi negli N nodi in cui viene decomposto il sistema ogni nodo contiene dunque tutti i servizi ogni richiesta per un servizio può essere assegnata a uno qualunque degli N nodi di solito mediante un load balancer la decomposizione dei servizi lungo l asse X è di solito semplice da implementare se i servizi sono stateless, allora è sufficiente fare un load balancing di tutte le richieste dei clienti altrimenti, se i servizi sono stateful, è necessario gestire lo stato delle sessioni in modo opportuno (questo aspetto è discusso più avanti) 30

16 Asse X per la scalabilità dei dati L asse X del cubo rappresenta anche la clonazione di tutti i dati in N basi di dati ogni base di dati contiene una copia di tutti i dati è richiesto un meccanismo di replicazione dei dati nelle diverse basi di dati viene di solito adottata una replicazione asincrona infatti una replicazione sincrona avviata per ciascuna operazione di scrittura può limitare fortemente la scalabilità (questo aspetto è discusso più avanti) tuttavia, la replicazione asincrona ha degli inconvenienti da comprendere e da saper gestire se necessario ad es., poiché la replicazione non è istantanea, sono possibili dei transitori in cui più copie degli stessi dati (in nodi diversi) non sono allineati 31 Asse X per la scalabilità Benefici la decomposizione lungo l asse X è quella più semplice da concettualizzare e da implementare per sostenere la scalabilità i servizi non devono essere modificati molti sistemi di gestione dei dati forniscono meccanismi di replicazione il sistema scala a fronte di un aumento del volume delle transazioni ogni nodo riceve 1/N del carico di lavoro tuttavia l accesso ai dati scala solo se il rapporto letturescritture è alto sostiene la disponibilità in particolare, la tolleranza ai guasti i nodi sono tutti uguali hanno tutti la stessa configurazione dunque è facile aggiungere nuovi nodi sostiene la scalabilità elastica 32

17 Inconvenienti Asse X per la scalabilità la scalabilità è limitata dalla dimensione dei servizi e soprattutto dalla dimensione dei dati poiché ogni nodo deve ospitare tutti i servizi e tutti i dati l accesso ai dati non scala se il rapporto letture-scritture è basso se ci sono molte scritture, la necessità di replicare i dati nelle diverse copie ha un impatto negativo sulla scalabilità replicare grandi quantità di dati è costoso ci possono essere problemi di consistenza dei dati e di attualità dei dati in ciascuna copia della base di dati replicata sostiene la disponibilità solo in modo parziale non sostiene l isolamento dei guasti 33 Asse Y per la scalabilità dei servizi L asse Y del cubo rappresenta un partizionamento dei servizi applicativi negli N nodi in cui viene decomposto il sistema ogni nodo è responsabile solo di un servizio o di un sottoinsieme di servizi ogni richiesta per un servizio viene assegnata al nodo responsabile per quel servizio la decomposizione dei servizi lungo l asse Y richiede di aver separato le funzionalità del sistema ovvero che il sistema non sia monolitico 34

18 Asse Y per la scalabilità dei dati L asse Y del cubo rappresenta una separazione dei dati per significato, funzione o utilizzo i dati possono essere suddivisi in modo corrispondente a come sono suddivisi i servizi o le funzioni lungo l asse Y in questo caso, possono essere presenti delle sovrapposizioni nelle basi di dati poiché gli stessi dati possono essere di interesse per più servizi è anche possibile (ma in genere è meno consigliato) effettuare una decomposizione lungo l asse Y con riferimento soprattutto ai dati (risorse) e poi suddividere i servizi di conseguenza una doppia decomposizione effettuata separatamente sui servizi e sui dati (risorse) è invece sconsigliata poiché può ridurre la disponibilità dei servizi (intuitivamente, perché se un servizio deve accedere a diverse risorse, allora quel servizio è disponibile solo se lo sono anche tutte le risorse a cui deve accedere) 35 Benefici Asse Y per la scalabilità anche la decomposizione lungo l asse Y è semplice da concettualizzare ma è un po complessa da implementare il partizionamento dei servizi può indurre un partizionamento dei dati sui cui operano i servizi le prestazioni possono beneficiare dal partizionamento dei servizi e dei dati può sostenere sia la scalabilità nel volume delle transazioni che la scalabilità nell aumento del volume dei dati sostiene la disponibilità in particolare, l isolamento dei guasti, per far sì che il guasto di un servizio (non critico) non si propaghi ad altri servizi (critici) può favorire la produttività dei team di sviluppo, se ciascun team è dedicato ad un sottoinsieme dei servizi i diversi servizi possono essere rilasciati separatamente tra loro 36

19 Inconvenienti Asse Y per la scalabilità l implementazione è più costosa (può richiedere la decomposizione del sistema inizialmente monolitico) è necessario gestire più tipi di nodi richiede in genere di gestire più basi di dati (anziché una sola) può richiedere l uso di più sistemi per la gestione dei dati sostiene la disponibilità solo in modo parziale il guasto di un servizio critico può rendere il sistema non funzionante in modo completo 37 Asse Z per la scalabilità dei servizi L asse Z del cubo rappresenta un partizionamento basato su un valore (o una funzione) che viene valutato all arrivo di ogni richiesta di solito, il valore è relativo ad una proprietà del cliente che ha effettuato la richiesta se viene eseguita solo una divisione lungo l asse Z, allora ogni nodo contiene tutti i servizi ma solo i dati relativi ad uno specifico segmento di clienti ogni richiesta viene servita dal nodo responsabile per il gruppo di clienti a cui appartiene il cliente 38

20 Asse Z per la scalabilità dei dati L asse Z del cubo rappresenta un partizionamento dei dati in relazione a un certo tipo di dati e a una loro proprietà di solito il partizionamento è relativo ai clienti del sistema spesso rispetto alla loro identità oppure alla posizione dalla quale fanno le richieste questo in genere favorisce le prestazioni e l isolamento dei guasti il partizionamento può anche essere relativo ad altri criteri come i prodotti di un catalogo 39 Asse Z per la scalabilità Benefici la decomposizione lungo l asse Z è ancora semplice da concettualizzare secondo [Abbott and Fisher] è la soluzione che può favorire di più la scalabilità sia rispetto ad un aumento del volume delle transazioni che dei dati sostiene la disponibilità in particolare, l isolamento dei guasti fa sì che il guasto di un nodo non si ripercuota sugli utenti degli altri nodi sostiene la scalabilità nel volume delle transazioni è simile a quella di una divisione lungo l asse X (se le transazioni sono distribuite equamente tra i diversi nodi) con in più il vantaggio che non è necessario replicare tutti i dati sostiene la scalabilità nel numero dei clienti 40

21 Inconvenienti Asse Z per la scalabilità è la soluzione più complessa e costosa da implementare i nodi sono simili tra di loro ma hanno in genere configurazioni differenti dopo che il sistema è stato rilasciato, può essere difficile riassegnare ai nodi le responsabilità per i gruppi di clienti (ovvero, cambiare il partizionamento dei clienti) sostiene la disponibilità solo in modo parziale il guasto di un nodo rende il sistema indisponibile per tutti gli utenti di quel nodo 41 - Dividere lungo più assi La decomposizione lungo un solo asso del cubo potrebbe essere sufficiente nel caso di una crescita limitata e lenta del carico di lavoro tuttavia, se si prevede che un sistema possa crescere velocemente (o anche con una crescita inaspettata) è meglio progettare il sistema per una decomposizione lungo due o più assi inoltre, la suddivisione lungo più assi è utile anche per sostenere meglio la disponibilità 42

22 Dividere lungo più assi Si consideri un sistema che è stato inizialmente decomposto lungo l asse Z ad es., la decomposizione è stata effettuata rispetto alla locazione geografica dei clienti, e ciascuna area geografica viene gestita da un nodo diverso il fallimento di un nodo provoca un interruzione di servizio per un intera area geografica e tutti i suoi clienti pertanto, può essere utile una successiva decomposizione per clonazione (lungo l asse X) di ciascuno di questi nodi replicando anche ciascuna base di dati con un effetto ulteriore effetto benefico sulla scalabilità ma anche con un effetto benefico sulla disponibilità 43 Dividere lungo più assi Anche una decomposizione lungo il solo asse Y in servizi sono stati partizionati in N gruppi, con un nodo distinto per ciascun gruppo di servizi presenta problemi analoghi di disponibilità (tolleranza ai guasti) anche in questo caso, una successiva decomposizione per clonazione (lungo l asse X) risolve il problema della disponibilità oltre a sostenere ulteriormente la scalabilità inoltre, applicando prima una decomposizione lungo Y e poi una lungo X, è possibile replicare separatamente i diversi servizi, sulla base del carico effettivo di ciascun singolo servizio 44

23 Dividere lungo più assi Una decomposizione lungo l asse Y, da sola, non è in grado di gestire una crescita nel numero di clienti per questo, può essere accompagnata da una divisione anche lungo l asse Z la divisione lungo l asse Y può aver suggerito, ad es., di usare un nodo per un servizio di login una successiva divisione può suggerire di replicare il servizio di login su più nodi, usando un nodo per ciascun gruppo di clienti (ad es., in relazione all area geografica del cliente) se un cliente si trasferisce, il sistema può accorgersene e muovere i suoi dati nei nodi dedicati alla sua nuova area geografica ad es., un servizio di accesso al catalogo prodotti (asse Y) può essere suddiviso sulla base dell hash dell identificatore del prodotto (asse Z) la divisione lungo l asse Z infatti non va limitata solo ai clienti 45 - Cubo della scalabilità: Sommario 46 Ecco una sintesi dei tre assi di scalabilità l asse X si basa sulla clonazione di un insieme di servizi o dati aiuta a scalare rispetto al volume delle transazioni ma non scala con la crescita dei dati sostiene la disponibilità e la scalabilità elastica l asse Y si basa su una separazione delle responsabilità per tipo di servizio o tipo di dato aiuta a scalare rispetto al volume delle transazioni ma non scala con l aumento dei clienti l asse Z si basa su una separazione per cliente o tipo di cliente aiuta a scalare rispetto al volume delle transazioni e all aumento dei clienti ma non scala a fronte di una crescita dei dati specifici per una certa funzione o servizio è la soluzione più costosa e difficile da implementare è possibile suddividere un sistema lungo più assi di scalabilità

24 - Comunicazione asincrona e scalabilità La sincronizzazione si riferisce all uso e al coordinamento di più unità di esecuzione (thread o processi) simultanei che fanno parte di uno stesso compito complessivo in cui queste unità di esecuzione devono essere eseguite in ordine corretto al fine di evitare risultati erronei (o altre anomalie) il login è un esempio di compito in cui ci sono diverse attività da svolgere in modo sequenziale e sincronizzato la cifratura della password inserita dall utente il confronto tra questa password e la vera password cifrata dell utente nella base di dati l utente viene marcato come autenticato nella sua sessione viene generata e presentata la pagina dell utente ma, in un sistema, non tutti i compiti devono essere svolti in modo sincronizzato strettamente 47 Comunicazione sincrona e asincrona La comunicazione in un sistema software distribuito può essere basata su chiamate sincrone (request-reply) un processo chiama un altro processo, e rimane in attesa di una risposta comunicazione asincrona (send-and-forget) un processo lancia un nuovo processo, e poi termina immediatamente senza aspettare il completamento dell operazione richiesta nota: qui ci riferiamo ad una nozione piuttosto generale di comunicazione asincrona che include meccanismi come, ad es., la comunicazione asincrona basata sullo scambio di messaggi, ma anche le invocazioni remote asincrone chiaramente, l implementazione di un sistema (o di una sua funzionalità) basata su comunicazione asincrona sarà diversa da un implementazione basata su chiamate sincrone 48

25 Comunicazione sincrona e asincrona 49 Le chiamate sincrone se usate in modo eccessivo o non corretto possono avere un impatto negativo sulla scalabilità del sistema le chiamate sincrone possono diffondere rallentamenti e guasti a cascata di solito con un effetto moltiplicativo ad es., un problema nel chiamato può anche bloccare il chiamante il tempo di risposta aumenta, ma aumenta anche il tempo in cui sono state allocate le risorse al chiamante (anche quando è in attesa) dunque il sistema consuma più memoria, più connessioni e altre risorse questo aumento nell uso delle risorse può a sua volta bloccare altre chiamate fatte nel sistema con un impatto negativo dapprima sulle prestazioni e poi, eventualmente, sulla disponibilità e la scalabilità del sistema nel caso di chiamate asincrone, invece, un blocco nel chiamato non provoca anche un blocco nel chiamante il consumo complessivo di risorse è minore Comunicazione asincrona e scalabilità Pertanto, se la scalabilità è importante, la comunicazione asincrona dovrebbe essere preferita a quella sincrona l uso della comunicazione asincrona è un principio di progettazione fondamentale per la scalabilità la comunicazione asincrona va usata soprattutto per chiamate tra servizi e nodi diversi, oppure verso sistemi esterni, oppure se relativa all attivazione di elaborazioni lunghe detto in altro modo, questi sono i casi in cui va soprattutto evitata la comunicazione sincrona è spesso comune che un operazione debba restituire dei risultati ecco alcune opzioni accedi ai risultati in modo asincrono utilizza delle callback usa chiamate sincrone con timeout stringenti e una gestione opportuna delle eccezioni 50

26 Comunicazione asincrona e consistenza La comunicazione asincrona può avere però un effetto negativo sulla consistenza poiché non può garantire una consistenza forte informalmente, la consistenza si riferisce all esecuzione atomica di un certo insieme di azioni su un certo insieme di dati più precisamente, al fatto che questa esecuzione venga percepita (ad es., da un client) come se fosse stata atomica se un operazione deve essere eseguita in modo consistente (strong consistency) e i dati su cui opera sono distribuiti su più nodi, allora probabilmente quest operazione va implementata mediante chiamate sincrone (ed in modo transazionale) 51 Comunicazione asincrona e consistenza La comunicazione asincrona può avere però un effetto negativo sulla consistenza poiché non può garantire una consistenza forte in ogni caso, la comunicazione asincrona supporta alcune forme deboli di consistenza (che sono spesso accettabili in pratica) ad es., l eventual consistency garantisce che, se non vengono richiesti nuovi aggiornamenti su un certo dato, allora, prima o poi, gli accessi a quel dato restituiranno l ultimo valore che gli è stato assegnato questa forma di consistenza risulta adeguata, in pratica, per molte applicazioni reali (ma non tutte!) 52

27 - Stato dei servizi e scalabilità Un servizio è stateful se l esecuzione di un operazione dipende dallo stato della conversazione (o sessione) con il client che ha richiesto l operazione altrimenti il servizio è stateless se un servizio è stateful, allora il sistema deve gestire (da qualche sua parte) lo stato delle sessioni con i propri client i servizi stateful hanno un impatto negativo sulla scalabilità poiché il sistema deve dedicare risorse alla gestione dello stato delle sessioni, per tutta la loro durata e questo può limitare la scalabilità del sistema infatti, il sistema deve allocare risorse non solo per le richieste e gli utenti concorrenti, ma anche per le sessioni concorrenti (che di solito sono molte di più) pertanto, se la scalabilità è importante, allora i servizi dovrebbero essere preferibilmente stateless 53 Stato dei servizi e scalabilità In presenza di servizi stateful, il sistema deve allocare risorse non solo per le richieste e gli utenti concorrenti, ma anche per le sessioni concorrenti (che di solito sono molte di più) comportamento di un utente nell ambito di una sessione first request last request session timeout utenti e sessioni concorrenti 2 active users 5 sessions 54

28 e servizi stateless Se la scalabilità è importante, i servizi dovrebbero essere preferibilmente stateless l uso di servizi stateless è un altro principio di progettazione fondamentale per la scalabilità molti servizi scalabili di successo sono stateless ad es., si pensi a Google Search 55 e servizi stateful Tuttavia, non sempre è possibile utilizzare solo servizi stateless infatti, molti servizi richiedono la gestione di uno stato ad es., circa l identità dell utente, le sue preferenze, lo stato di avanzamento del caso d uso, ecc. mantenere queste informazioni in memoria può essere più economico che non ripetere, ad ogni richiesta dell utente, l autenticazione e l accesso a questi dati nella base di dati nel caso di servizi stateful per prima cosa, bisogna cercare di evitare lo stato delle sessioni e provare a rendere il servizio stateless se non è possibile, bisogna cercare di minimizzare la dimensione dello stato da mantenere per ciascuna sessione inoltre, bisogna conoscere quali sono le alternative per la gestione dello stato e il loro impatto sulla scalabilità per poter scegliere l alternativa meno peggiore 56

29 Gestione dello stato dei servizi Alcune opzioni per la gestione dello stato nei servizi gestire lo stato delle sessioni nell application server ad es., usando delle tecnologie stateful (come i session bean di tipo stateful o componenti con scope session) in caso di clonazione del servizio, è possibile evitare di replicare lo stato delle sessioni su tutti i nodi replicati, se tutte le richieste di un client vengono servite da uno stesso nodo (sticky session o session affinity) questo è possibile, ad es., con il supporto del load balancer tuttavia, questo limita la disponibilità del servizio se le sessioni sono gestite dai nodi solo in memoria e un nodo fallisce, allora falliscono tutte le sue sessioni se invece le sessioni sono gestite in modo persistente e un nodo fallisce, allora il ripristino delle sessioni è possibile, ma ci sarà una qualche interruzione di servizio 57 Gestione dello stato dei servizi Alcune opzioni per la gestione dello stato nei servizi gestire lo stato delle sessioni come cookie nel browser dell utente una soluzione semplice le diverse richieste di uno stesso client possono essere servite da nodi differenti ma introduce un overhead di comunicazione, poiché richiede di muovere ripetutamente lo stato della sessione da e verso il browser dell utente (che in rete può essere lontano ) per questo è importante minimizzare le dimensioni dello stato della sessione inoltre può sollevare problemi di sicurezza 58

30 Gestione dello stato dei servizi Alcune opzioni per la gestione dello stato nei servizi gestire lo stato delle sessioni in un repository (distribuito e condiviso dai nodi dell app. server) una base di dati oppure una cache condivisa (una object cache, discussa più avanti) anche in questo caso, le diverse richieste di uno stesso client possono essere servite da nodi differenti anche in questo caso, lo stato della sessione viene mosso ripetutamente da e verso il repository ma questo è in genere meno costoso che non muovere i dati da e verso il browser dell utente in genere è preferibile gestire lo stato delle sessioni in una cache condivisa anziché in una base di dati condivisa infatti il costo degli accessi ad una base di dati (relazionale) è di solito maggiore che non ad una cache una cache deve essere dimensionata opportunamente 59 - Caching per la scalabilità Un altro approccio per gestire un volume grande di richieste consiste nel cercare di evitare di gestire le richieste (almeno in parte) minimizzando il lavoro che essere svolto dai componenti funzionali del sistema questo obiettivo può essere perseguito mediante l uso di cache cercando di far servire alle cache delle richieste che altrimenti dovrebbero essere gestite dai componenti funzionali del sistema i tipi di cache più rilevanti per l architettura del software sono le object cache, le application cache e le content delivery network 60

31 Cache In generale, una cache è una memoria usata da un dispositivo o da un applicazione per la memorizzazione temporanea di dati che probabilmente devono essere usati di nuovo una cache è di solito un insieme di coppie chiave-valore l accesso al valore associato a una chiave può produrre un cache hit (il dato è stato trovato nella cache) oppure un cache miss (il dato non è stato trovato, va computato altrove e poi memorizzato nella cache) l efficacia di una cache è data dall hit ratio (che dovrebbe essere alto) se invece è basso, la cache potrebbe addirittura avere un impatto negativo sulle prestazioni i dati in una cache possono diventare obsoleti ovvero, una cache può restituire stale data possono essere necessari meccanismi di invalidazione e/o di aggiornamento della cache una cache è di solito di dimensione limitata sono anche necessari meccanismi per deallocare dati dalla cache 61 Object cache Una object cache ha lo scopo di memorizzare oggetti dell applicazione che devono essere riusati un sistema di uso comune è Memcached con operazioni per aggiungere, cercare, aggiornare e cancellare oggetti individuali dalla cache gli oggetti sono di solito memorizzati in una forma serializzata una object cache può essere posta tra l application server e la base di dati tra il web server e l application server un altro uso comune è la gestione dello stato delle sessioni che possono essere memorizzate in una object cache distribuita e replicata questo consente di evitare che l application server debba gestire lo stato dei servizi stateful questa soluzione è in genere più efficace che non gestire lo stato delle sessioni in una base di dati relazionale 62

32 Object cache 63 Application cache Una application cache è invece una cache posta davanti all intera applicazione tra l utente e l applicazione di solito si occupa di memorizzare richieste-risposte HTTP ma attenzione a specificare le pagine di cui non va fatto caching! ci sono due tipi principali di application cache una proxy cache (o forward proxy cache o proxy server) viene di solito fornita separatamente da ciascun ISP (Internet Service Provider) per ottimizzare l accesso a tutte le applicazioni web ma solo per gli utenti di quell ISP una reverse proxy cache (o gateway cache) viene invece gestita direttamente davanti ad una specifica applicazione web con lo scopo di ottimizzare solo l accesso a quell applicazione, ma per tutti gli utenti dell applicazione in pratica, esistono moltissimi tipi di application cache che variano nelle finalità e nei dettagli 64

33 Application cache Proxy cache Reverse proxy cache 65 Content Delivery Network Una Content Delivery Network (CDN) ha lo scopo di muovere vicino all utente finale i contenuti statici di un applicazione web in modo da ridurre il tempo di risposta per quei contenuti e di ridurre il numero di richieste nella parte server di un sistema software di solito una CDN viene realizzata come una rete di gateway cache collocate in diverse aree geografiche e dunque posizionate ai margini di Internet il dominio di una CDN viene poi indicato nei DNS come alias per il dominio dell applicazione in modo tale che gli utenti dell applicazione provino prima ad accedere alla CDN anziché ai server originali dell applicazione una CDN può anche interagire periodicamente con i server originali dell applicazione per rinfrescare i propri contenuti 66

34 * Discussione La scalabilità è la capacità di un sistema di gestire volumi di elaborazione crescenti questa dispensa ha presentato alcune opzioni di progettazione principali per la scalabilità i principi fondamentali sono quelli relativi alla scalabilità orizzontale (la distribuzione del carico e il cubo della scalabilità), alla comunicazione asincrona e ai servizi stateless ma anche il caching alcuni aspetti importanti per la scalabilità sono stati solo accennati oppure sono trattati in altre dispense come la valutazione della scalabilità e della capacità residua, la scalabilità elastica, il monitoraggio e l automatizzazione dei rilasci (preferibilmente piccoli) questi diversi aspetti non vanno considerati in isolamento piuttosto bisogna considerarli insieme anche ad altre qualità come le prestazioni, la disponibilità, la consistenza dei dati e la sicurezza ed identificare e valutare eventuali compromessi 67