L’attuale tendenza alla segregazione delle componenti ed alla scalabilità si traduce nell’introduzione della difficoltà di mantenere operativi “stateful system“, vale a dire sistemi che hanno consapevolezza dello stato ed hanno tutte le informazioni per gestirlo e mantenerlo. Nella pratica uno “stateful system” ha spesso database condivisi, sempre più complessi a causa della necessità di scalabilità e di archiviazione di qualsiasi informazione al fine di conoscere lo stato.
Mantenendo alcune componenti, di fatto, monolotiche per poterne condividere lo stato ci si espone a diversi rischi:
- quasi certi maggiori costi perchè sono necessarie enormi risorse per mantenere l’operatività;
- esposizione a possibili attacchi di tipo Denial of Service(DoS);
- scarsa flessibilità dell’architettura.
Contattaci subito e senza impegno per superare questi rischi.
Autoscaling Stateful System: i problemi da affrontare
Quando si affronta l’implementazione della scalabilità negli statetul system occorre rispondere a domande come: dove applico la scalabilità? Come effettuo la scalabilità? Come muovo i dati tra i servizi scalati? Come i vari nodi possono raggiungere il consenso e quindi la parifica dei dati?
In pratica, se vuoi realizzare l’autoscaling negli stateful system, devi affrontare i seguenti problemi:
- consenso: qualsiasi sistema distribuito che archivia uno stato deve essere d’accordo con quale sia il nuovo stato valido. E’ un problema noto e sono nati algoritmi come Ark, Raft e BDR che sono rispettivamente le tecnologie di costruzione del consenso di MongoDB, Redis e PostgreSQL.
- autoscaling: seppur numerosi provider offrano l’autoscaling con un click, nel caso degli stateful system non ti è possibile mantenere completamente uno statetul system perchè l’autoscaling è legato alle risorse computazionali e non ai dati;
- tempi per la data migration: un modo comune di scalare è quello di aggiungere un nuovo nodo, per es. in Kubernetes, ma quando si parla di stateful system è necessario considerare i tempi indispensabili affinchè i dati si sincronizzino e cosa accade quando la quantità di dati è enorme.
- gestione della domanda: la scalabilità si attiva in base al numero di richieste che potrebbero essere costanti e graduale ma anche repentine ed enorme sia per un picco sia per un attacco DoS così potendo eventualmente generare indisponibilità del servizio.
- cloud solution: buttarsi capo e piedi in un particolare cloud provider pensando che sia la soluzione si traduce, di fatto, in un lock-in che nello scenario strategico attuale non è mai una soluzione ideale.
Contattaci subito e senza impegno per costruire uno stateful system.
Una possibile soluzione all’autoscaling degli Stateful System
Partendo dal concetto base che la scalabilità vada costruita sia in maniera verticale(aumentare le risorse per es. maggiore potenza della CPU) sia orizzontale( aggiungere risorse per es. aggiungere un nuovo nodo) da pochi fino a migliaia di nodi in un cluster, è possibile costruire una soluzione agnostica, cioè indipendente dal tipo di dati da usare( JSON, serialized data, stream, blobs, ecc…) attraverso la creazione di:
- Writer: un nodo che ha il compito di scrivere i nuovi stati ed è responsabile della replica dei dati. Il Writer è il leader del consenso e costruisci il concetto di sharding, cioè mantiene segmenti che insieme fanno il “tutto”;
- Reader: un nodo che ha il compito leggere i dati e fornirli, crea connessioni multiple con il Writer leader ;
- Proxy: un nodo che fornisce servizi anche per compiti non legati a scrivere e leggere dati. Di fatto è un nodo che funziona da gateway e load balancer che invia le richieste al Writer ed al Reader aggregando le risposte e fornendole al cliente. Viene replicato in caso di esigenze ;
- Trigger non legato alle risorse ma alle risposte in modo garantire la risposta e non la risorsa(un concetto complesso in quanto una CPU che lavora al 99% potrebbe avere risposte in linea con la Customer Experience(CX) perchè magari fa un ottimo uso di cache e servizi avanzati).
- Algoritmo di consenso come Raft in modo che il leader sia sempre unico e poter avere più leader che costruiscono il consenso su chi debba scrivere i dati.
E’ un Design dell’architettura complesso che però ti permette di costruire un sistema stateful resiliente e non ha alcun lock-in con i provider quindi avendo la possibilità di essere completamente integrato nel tuo scenario e trasferito dove reputi opportuno anche On-Premise.
Contattaci subito e senza impegno per realizzare un Proof of Concept(PoC).
Glue Labs e le Architetture IT
Siamo partner di Google Cloud e Vonage, abbiamo progettato ed implementato architetture complesse ed integrate grazie a Cloud Engineer e Solution Architect in ambiente Offline, On-Premise e Cloud. Grazie alle competenze specialistiche maturate in tantissimi settori e con numerosi Clienti ti forniamo assistenza e supporto, eroghiamo formazione avanzata e realizziamo architetture che ti permettono di gestire i tuoi dati in maniera stateful con garanzia 12 mesi da qualsiasi bug. Contattaci subito e senza impegno per maggiori informazioni.
