Che cos'è la scalabilità?
Nel mondo delle aziende la crescita può essere un beneficio. Quando, però, è repentina e l'azienda non si è adeguatamente preparata, la crescita può causare problemi. Uno di questi è l'impatto sull'affidabilità delle applicazioni e dei servizi che non sono stati progettati per gestire un aumento elevato del traffico.
Per clienti e utenti un'interruzione del servizio rimane tale. Poco importa che l'accesso al sito sia interdetto perché il codice del sito contiene bug oppure perché, nonostante il codice non contenga errori, un numero eccessivo di utenti prova contemporaneamente ad accedere al sito.
La scalabilità è la capacità di adattarsi a un incremento delle richieste oppure a esigenze mutevoli. Le applicazioni e i servizi devono riuscire a gestire un carico di lavoro più elevato per supportare la crescita. Le applicazioni scalabili possono infatti gestire un numero crescente di richieste nel tempo senza alcun impatto negativo sulla disponibilità o sulle prestazioni.
In questa unità verrà approfondita la relazione tra scalabilità e affidabilità, verranno fornite informazioni sull'importanza della pianificazione della capacità ai fini della scalabilità e verranno illustrati alcuni concetti e termini di base relativi al ridimensionamento.
Relazione tra scalabilità e affidabilità
La buona notizia è che rendere un'app più scalabile potrebbe anche renderla più affidabile. Se, ad esempio, per il sistema è impostato il ridimensionamento automatico, se si verifica il guasto di un componente in una singola macchina virtuale, il servizio di scalabilità automatica effettuerà il provisioning di un'altra istanza per soddisfare i requisiti minimi relativi al numero di macchine virtuali. Il sistema diventa più affidabile. In un altro esempio si usa un servizio di livello superiore, ad esempio Archiviazione di Azure intrinsecamente scalabile. Se si verifica un problema di archiviazione, il servizio viene compilato per essere affidabile, quindi i dati vengono replicati.
Ecco un'analogia: si pensi alle rampe di accessibilità che spesso si vedono all'esterno di edifici progettati inizialmente per ospitare persone in sedia a rotelle. Questo è il loro scopo. Tuttavia, vengono usati anche da genitori con bambini in passeggino o carrozzina o da bambini piccoli per i quali i gradini sono troppo profondi o alti. In tal caso, si tratta di un vantaggio secondario.
L'affidabilità è spesso un vantaggio secondario della scalabilità. Se si progettano i sistemi per la scalabilità, è probabile che siano anche più affidabili.
Scalabilità e pianificazione della capacità
La pianificazione della capacità implica l'individuazione delle risorse necessarie per soddisfare le esigenze attuali e future. A questo scopo, è possibile analizzare l'utilizzo corrente delle risorse e quindi prevedere la crescita futura.
Per stimare le esigenze di capacità future, è necessario considerare i fattori seguenti:
- Crescita aziendale prevista
- Fluttuazioni periodiche (stagionali e così via)
- Vincoli dell'applicazione
- Identificazione di colli di bottiglia e fattori di limitazione
È anche necessario impostare gli obiettivi del livello di servizio, in modo da creare un piano di gestione della capacità che soddisfi o superi in modo affidabile gli obiettivi in caso di modifiche del carico di lavoro e dell'ambiente.
La pianificazione della capacità è un processo iterativo. Andando avanti in questo modulo, si apprenderà come identificare i requisiti delle risorse per i componenti dell'applicazione.
Concetti e terminologia
Per poter comprendere appieno concetti e strategie illustrati in questo modulo, è necessaria la conoscenza preliminare di alcuni concetti di base e dei termini fondamentali correlati al ridimensionamento.
- Aumento delle prestazioni: aggiungere risorse a un componente in modo che possa gestire un carico di lavoro maggiore. È sinonimo di scalabilità verticale.
- Aumento delle risorse: aggiungere altri componenti o risorse per distribuire il carico in un'architettura distribuita. È ad esempio il caso di un'architettura semplice supportata da più back-end dietro un set di front-end. Con l'aumentare del carico, si aggiungono altri server back-end (e front-end) per gestirlo. È sinonimo di scalabilità orizzontale.
- Dimensionamento manuale: implica l'intervento umano per aumentare il numero di risorse.
- Scalabilità automatica: il sistema regola automaticamente la quantità di risorse in base al carico. Più chiaramente, il numero delle risorse viene aumentato o diminuito in base a un aumento o una diminuzione del carico.
- Scalabilità fai da te: consente di configurare il dimensionamento automatico in modo autonomo.
- Scalabilità intrinseca: si riferisce a servizi pensati per la scalabilità e che gestiscono il dimensionamento in background senza alcun intervento da parte dell'utente. Dal punto di vista dell'utente, sembrano quasi ridimensionabili all'infinito, in quanto l'utente può limitarsi a utilizzare le risorse senza doverne effettuare il provisioning manualmente.
architettura di Tailwind Traders
In questo modulo si userà un'architettura di esempio di una società di componenti hardware fittizia chiamata Tailwind Traders. La loro piattaforma di e-commerce è simile a quella illustrata di seguito:
Il diagramma appare complesso a prima vista, esaminiamolo. Il sito Web ha un front-end. Si tratta del servizio con cui si parla quando si accede al sito tailwindtraders.com.
Il front-end comunica con un set di servizi back-end. Questi servizi back-end includono elementi di uso comune, ad esempio un servizio di coupon, un servizio carrello acquisti, un servizio di inventario e così via. Tutto ciò è eseguito dal servizio Azure Kubernetes. L'applicazione include anche altri componenti e tecnologie, ma è sufficiente concentrarsi sul front-end e sui servizi back-end in esecuzione in Kubernetes.
Singoli punti di guasto
Dopo aver osservato l'architettura nel suo complesso, è opportuno esaminare i singoli punti di errore e le parti a cui prestare attenzione quando si pensa al ridimensionamento.
Tutti questi servizi rappresentano un singolo punto di errore e non sono pensati per la resilienza o la scalabilità. Se uno di essi viene sovraccaricato, è probabile che si verifichi un arresto anomalo e non esiste un modo semplice per risolvere il problema all'istante.
Più avanti in questo modulo verranno esaminati altri modi per progettare questi servizi perché siano più scalabili e affidabili.
Pre-provisioning della capacità
Diamo un'occhiata a un'altra questione che potrebbe rivelarsi problematica. Ecco i servizi/componenti per i quali è necessario effettuare il pre-provisioning della capacità:
Con Cosmos DB, ad esempio, si effettua il pre-provisioning della velocità effettiva. Se si superano questi limiti, i clienti riceveranno messaggi di errore. Con Servizi di Azure AI si seleziona un livello, al quale è assegnato un numero massimo di richieste al secondo. Dopo aver raggiunto uno di questi limiti, i clienti sono soggetti a limitazioni.
Un picco significativo del traffico, ad esempio l'avvio di un nuovo prodotto, farà raggiungere questi limiti? Al momento non lo si può sapere. Questo è un altro aspetto che verrà trattato più avanti in questo modulo.
Costi
Anche quando tutto è giusto, è comunque opportuno pianificare la crescita. Ecco i servizi con pagamento in base al consumo:
In questo caso si usano App per la logica di Azure e Funzioni di Azure, che sono entrambi esempi di tecnologia serverless. Ciò significa che questi servizi vengono dimensionati automaticamente e il pagamento avviene in base alla richiesta. I costi fatturati aumentano proporzionalmente alla base di clienti. È opportuno almeno essere consapevoli dell'impatto che eventi imminenti, come il lancio di un prodotto, potrebbero avere sulla spesa per il cloud. Vedremo più avanti in questo modulo anche come analizzare e prevedere la spesa per il cloud.