Un’applicazione funziona bene con cento utenti. Poi arriva una campagna, una scadenza, un evento in diretta, e gli utenti diventano migliaia nello stesso momento: le pagine rallentano, le richieste vanno in errore, e il problema non è una singola funzione ma il modo in cui è costruito l’intero sistema.
La scalabilità è la capacità di un sistema di gestire più carico (più utenti, più dati, più richieste) senza perdere prestazioni né qualità del servizio, possibilmente con costi che crescono in proporzione. In questo articolo raccontiamo come la progettiamo nei nostri progetti: le tecniche che usiamo, in che ordine, e perché misurare viene prima di ottimizzare.
Scalare in verticale o in orizzontale
Ci sono due modi per dare più capacità a un sistema. Scalare in verticale significa usare una macchina più potente, con più CPU e più memoria: è semplice e spesso è il primo passo giusto, ma ha un limite fisico ed economico, e quella macchina resta un punto unico di guasto.
Scalare in orizzontale significa aggiungere altre copie (repliche) dello stesso servizio e distribuire il lavoro tra loro. Si può crescere molto di più e migliora anche l’affidabilità, ma l’applicazione deve essere pensata per girare in più copie contemporaneamente. È qui che contano le scelte di architettura.
Servizi senza stato, bilanciamento e cache
Il primo requisito per scalare in orizzontale sono i servizi senza stato (stateless): nessuna replica deve tenere in memoria dati che servono alle richieste successive, come la sessione dell’utente o i file caricati. Sessioni e file vanno in un archivio condiviso, così qualsiasi copia può rispondere a qualsiasi richiesta.
Davanti alle repliche c’è un bilanciatore di carico (load balancer), che distribuisce le richieste e smette di inviarle alle copie che non rispondono. Accanto c’è quasi sempre una cache, cioè una memoria veloce per i dati letti spesso e modificati di rado: con uno strumento come Redis, una risposta che richiederebbe una query complessa al database si serve in una frazione del tempo.
Il database, spesso il vero collo di bottiglia
Moltiplicare l’applicazione è relativamente facile; il database è più delicato, perché è il punto in cui tutte le copie si incontrano. Le tecniche principali sono queste:
- Indici: la prima verifica e spesso la più efficace; una query lenta su una tabella grande di solito manca di un indice adatto.
- Repliche di lettura: copie del database che rispondono solo alle letture, mentre le scritture restano sul database principale.
- Partizionamento: le tabelle più grandi si dividono per data, per cliente o per area, così ogni query lavora su una parte dei dati.
- Database gestiti: servizi come Amazon RDS, o gli equivalenti su Microsoft Azure e Google Cloud, si occupano di backup, aggiornamenti e repliche.
Code, CDN e lavoro in background
Non tutto deve succedere mentre l’utente aspetta. Le operazioni pesanti, come la conversione di un video, un report o l’invio di email, si mettono in una coda (per esempio Amazon SQS o Apache Kafka) e le eseguono processi dedicati, che si possono moltiplicare quando la coda si allunga. L’utente riceve subito una conferma e il sistema assorbe i picchi senza bloccarsi.
Per i contenuti statici e i media, una CDN (Content Delivery Network, una rete di server distribuiti in molti paesi) porta i file vicino a chi li richiede, togliendo carico ai server e riducendo i tempi di attesa.
Artika, la nostra piattaforma di streaming per il teatro, è costruita così su servizi gestiti di AWS. Video e libretti vanno su Amazon S3 direttamente dal browser, con link firmati di breve durata, senza passare dal server; AWS Elemental MediaConvert crea lo streaming HLS; sottotitoli e moderazione li elaborano Amazon Transcribe e Amazon Rekognition, e l’API ne raccoglie i risultati ogni minuto; Amazon CloudFront porta video e miniature agli spettatori.
Container, Kubernetes e cloud gestito
I container rendono pratica la scalabilità orizzontale: ogni servizio diventa un pacchetto standard, con il codice e tutto ciò che gli serve, che si avvia rapidamente ed è identico ovunque. Kubernetes, la piattaforma open source più diffusa per orchestrare i container, può aggiungere o togliere repliche in automatico in base a metriche come l’uso della CPU (autoscaling) e riavviare quelle che si bloccano.
Non sempre serve gestire Kubernetes in proprio. I servizi gestiti di AWS, Microsoft Azure e Google Cloud (container, database, code, CDN) spostano sul fornitore una parte del lavoro operativo. In 2VitaBCognitive per Atlantia, per esempio, i 6 microservizi girano in container Docker su Amazon ECS e i contenuti arrivano agli utenti da Amazon S3 attraverso CloudFront.
Misurare prima di ottimizzare, e controllare i costi
La scalabilità non si indovina: si misura. Prima di cambiare architettura facciamo test di carico che simulano il traffico atteso e quello di picco, e raccogliamo metriche su tempi di risposta, errori, uso delle risorse e lunghezza delle code. Spesso il collo di bottiglia è uno solo e sta dove nessuno se lo aspetta: una query, una chiamata a un servizio esterno, un file servito dal server invece che dalla CDN.
- Obiettivi chiari: per esempio il tempo entro cui deve rispondere la grande maggioranza delle richieste.
- Test di carico ripetibili, da rilanciare a ogni modifica importante.
- Monitoraggio in produzione, con allarmi che scattano prima che il problema arrivi agli utenti.
- Controllo dei costi: limiti all’autoscaling, risorse spente quando non servono, budget e avvisi sulla spesa cloud.
L’autoscaling senza limiti risolve i picchi, ma può trasformarli in una fattura inattesa. Per questo, per ogni componente, decidiamo insieme al cliente quanto deve poter crescere e quanto si è disposti a spendere.
Se la tua applicazione sta crescendo, o deve prepararsi a farlo, possiamo partire da una misura dello stato attuale e indicarti gli interventi con il miglior rapporto tra costo e beneficio. Contattaci per parlarne.
