La storia è semplice, e l'ho sentita più volte di quanto vorrei: un'istanza EC2 singola, diversi (molti) container in esecuzione, Traefik come reverse proxy davanti a tutto, più siti web ciascuno con la propria struttura e il proprio database. Un setup consolidato, che girava da anni (almeno 4) senza problemi particolari.

Un giorno qualcosa va storto. Il servizio diventa irraggiungibile, i siti non rispondono, i container si bloccano a catena. La soluzione più veloce? Raddoppiare CPU e RAM dell'istanza.

Come risposta a un'emergenza ha senso. È la cosa giusta da fare quando il telefono squilla e il cliente ha i siti giù: rimetti in piedi il servizio, poi ti fermi, respiri e vai a fondo. Il problema è quello che succede dopo.

Settimane dopo, l'istanza raddoppiata era ancora lì. Nessuno aveva indagato la reale causa del picco. Nessuno aveva verificato se le risorse aggiuntive servissero davvero. L'unica cosa certa era che la fattura mensile era raddoppiata.

Cosa ho trovato

Prima ancora di guardare il problema tecnico, il quadro generale era già abbastanza chiaro.

L'istanza era on-demand. Attiva da almeno quattro anni. Nessun Savings Plan, nessuna Reserved Instance, nessun tipo di impegno. Costo pieno, ogni ora, ogni giorno, per anni. Solo questo dettaglio rappresentava uno spreco significativo: un Savings Plan su un'istanza che gira 24/7 da quattro anni avrebbe potuto ridurre il costo compute di un buon 30-40%, senza cambiare nulla dell'architettura.

Poi c'era il monitoring: non esisteva. Nessun allarme CloudWatch configurato, nessuna metrica sotto osservazione, nessun dashboard. Il team si accorgeva dei problemi quando i siti andavano giù. Non prima, non durante: dopo. Quando qualcuno chiamava o quando qualcuno provava ad aprire un sito e non caricava.

Senza visibilità, ogni problema diventa un'emergenza. E ogni emergenza si risolve con la stessa mossa: buttarci più risorse sopra.

Ma il punto vero era un altro: cosa aveva causato il picco che aveva messo in ginocchio il servizio?

Non era la CPU. Non era la RAM.

Erano gli IOPS.

Il disco sbagliato

Il server era strutturato bene, per certi versi. Ogni container aveva il suo mountpoint dedicato per i dati, i container database montavano i propri volumi separati sul filesystem. L'architettura applicativa non era il problema, anzi: chi aveva impostato il sistema ci aveva pensato.

Il problema era il tipo di disco su cui girava tutto: un volume EBS di tipo gp2.

I volumi gp2 funzionano con un sistema a crediti. Hai un livello base di IOPS proporzionale alla dimensione del disco (3 IOPS per GB) e un burst fino a 3.000 IOPS che puoi usare quando serve, ma che si esaurisce. Finiti i crediti, torni al livello base. Se il disco è piccolo, quel livello base può essere molto basso.

Con quella quantità di container attivi, ciascuno con le proprie operazioni di lettura e scrittura, più i database che per natura fanno un uso intensivo del disco, il volume gp2 era sotto pressione costante. I crediti di burst si esaurivano e le performance crollavano. Quando il disco non riesce a tenere il passo, tutto quello che ci gira sopra rallenta: i database si bloccano, i container vanno in timeout, i siti smettono di rispondere.

Raddoppiare CPU e RAM non serviva a niente: il collo di bottiglia non era lì. Era come mettere un motore più potente in una macchina con le ruote sgonfie.

La soluzione

Migrazione da gp2 a gp3. Niente di estremo, niente io1 o io2 (che sarebbero stati sovradimensionati e molto più costosi per questo caso d'uso). I volumi gp3 sono la generazione successiva: offrono 3.000 IOPS di base garantiti, senza il meccanismo a crediti, e permettono di configurare IOPS e throughput in modo indipendente dalla dimensione del disco.

Il bello è che il costo base di un gp3 è addirittura inferiore a quello di un gp2 a parità di dimensione. Stai pagando meno per avere performance migliori e più prevedibili.

Con il nuovo volume in posizione, il server ha smesso di soffocare. Le operazioni su disco non erano più il collo di bottiglia, i database rispondevano nei tempi normali, i container giravano senza timeout.

A quel punto è stato possibile fare la cosa che contava davvero: riportare l'istanza alla dimensione originale. CPU e RAM dimezzate, perché il problema non era mai stato lì.

Risultato: circa il 50% in meno sul costo compute. Non perché abbiamo ottimizzato qualcosa di complicato, ma perché abbiamo individuato la reale causa del problema.

Il pattern

Questo caso ha molto in comune con un altro intervento sui costi cloud di cui ho già scritto. Lì il problema era lo storage S3 con versioning non governato: si pagava per dati che l'applicazione considerava cancellati. Qui è un disco di tipo sbagliato su un server che gira da anni senza che nessuno ci abbia più guardato dentro.

Contesti diversi, stesso schema: un costo che cresce, nessuno che sa spiegare perché, e una reazione istintiva (spendere di più) che non risolve niente.

Il denominatore comune è lo stesso: il cloud non è caro. È non governato.

Quando manca visibilità su quello che succede, le decisioni diventano reattive. Si raddoppia, si scala, si spende di più. Non perché serva, ma perché non si sa cosa fare di diverso.

Ho raccomandato al cliente di attivare un Savings Plan per l'istanza, perché quattro anni di on-demand sono soldi buttati. E di mettere in piedi un minimo di monitoring. Non serve un sistema complesso: bastano le metriche base di CloudWatch con un paio di allarmi sulle soglie giuste per CPU, memoria e, soprattutto, IOPS. Quel minimo che ti permette di vedere un problema prima che diventi un'emergenza.

Prima di spendere di più, vale la pena capire cosa si sta pagando. E perché.

Se hai una fattura cloud che non sai spiegare, o un server che "funziona" solo perché qualcuno un giorno ha raddoppiato tutto... parliamone. Ti dico se il problema è davvero dove pensi tu.