Il nostro bot Slack ha gestito 200 messaggi al giorno per tre mesi senza problemi. Poi un blogger tecnologico ne ha parlato in una newsletter e siamo passati da 200 a 12.000 messaggi in 48 ore.
Tutto ha smesso di funzionare. Non in modo spettacolare — il server non è esploso né altro. Ha semplicemente… rallentato. E ha continuato a rallentare. Poi ha iniziato a perdere messaggi. E infine è diventato completamente silenzioso mentre 12.000 persone si chiedevano perché il bot IA di cui avevano appena sentito parlare non rispondesse.
Ecco cosa è successo, cosa abbiamo fatto e come siamo passati da “progetto secondario divertente” a “cosa su cui le persone fanno davvero affidamento” in una settimana.
Le prime 6 ore: negazione e panico
La newsletter è arrivata nelle caselle di posta alle 9:00 di martedì. Alle 10:00, la nostra coda di messaggi aveva un ritardo di 400 messaggi. A mezzogiorno, la coda raggiungeva i 2.000 e il tempo di risposta era di 45 secondi (normalmente meno di 3 secondi).
La mia prima reazione: “Hmm, sono molti messaggi.” La mia seconda reazione, 20 minuti dopo: “Oh no.”
Il collo di bottiglia non era la CPU o la memoria — era l’API del modello IA. Ogni messaggio richiedeva una chiamata API e stavamo rapidamente raggiungendo i limiti di velocità. Il nostro piano API gratuito consentiva 60 richieste al minuto. Ne servivano più di 200 al minuto.
Soluzione veloce: aggiornamento del piano API. Abbiamo portato il nostro limite a 500 richieste al minuto in 30 minuti passando a un piano a pagamento. La coda iniziava a svuotarsi. Crisi parzialmente evitata.
Ma poi è arrivata la seconda ondata.
Ore 6-24: tutto il resto si rompe
Aumentare il throughput API ha rivelato tutti gli altri colli di bottiglia che non avevamo notato a basso volume.
Connessioni al database sature. Ogni messaggio attivava una ricerca nel database per il contesto utente. A 200 messaggi/giorno, nessun problema. A 12.000, il nostro pool di connessioni si era esaurito. Gli utenti ricevevano errori “servizio non disponibile”.
Correzione: aumento delle dimensioni del pool di connessioni, aggiunta dell’ottimizzazione delle connessioni con PgBouncer e configurazione di repliche di lettura per le ricerche di contesto.
Fuga di memoria nel gestore dei messaggi. Una variabile che memorizzava il contesto della conversazione cresceva senza essere ripulita. A basso volume, cresceva lentamente ed era purgata da riavvii occasionali. A alto volume, consumava tutta la memoria disponibile in circa 4 ore.
Correzione: aggiunta di una pulizia appropriata dopo l’elaborazione di ogni messaggio. Questo bug esisteva sin dal primo giorno — non aveva mai importanza fino ad ora.
Elaborazione mono-thread. I messaggi venivano elaborati sequenzialmente. Uno alla volta. A 200 messaggi/giorno, andava bene. A 12.000, significava che ogni messaggio aspettava dietro ogni altro messaggio.
Correzione: implementazione di un’elaborazione concorrente con una coda di lavori appropriata. I messaggi vengono distribuiti tra più lavoratori. Questo ha ridotto il tempo di risposta medio da 45 secondi a meno di 5.
Il momento “Oh, abbiamo bisogno di una vera infrastruttura”
Dopo 24 ore, ho capito che la nostra architettura “funziona su un VPS a 10 $/mese” non sarebbe riuscita a gestire una crescita sostenuta. Avevamo bisogno di:
Un vero bilanciatore di carico. Non perché avessimo bisogno di più server, ma perché avevamo bisogno di controlli di stato, riavvii automatici e la capacità di distribuire aggiornamenti senza tempi di inattività.
Una coda di messaggi. Coda di lavori supportata da Redis che decouples la ricezione dei messaggi dall’elaborazione dei messaggi. Se il modello IA è lento, i messaggi attendono nella coda invece di morire nei tempi di attesa. Se un lavoratore fallisce, il messaggio è ritentato invece di essere perso.
Monitoraggio che allerta realmente. Avevamo dei log. Non avevamo alcun avviso. La differenza è significativa quando le cose falliscono alle 2 del mattino e nessuno monitora i log.
Scalabilità orizzontale. La capacità di aggiungere più lavoratori quando il carico aumenta. La nostra architettura ridimensiona automaticamente: se la profondità della coda supera una soglia, nuovi lavoratori vengono messi in funzione automaticamente.
Ciò che abbiamo realizzato in una settimana
Giorno 1-2: aggiornamento d’emergenza del limite di velocità, correzione del pool di connessioni, correzione della fuga di memoria.
Giorno 3-4: implementazione della coda dei messaggi, elaborazione concorrente.
Giorno 5-6: bilanciatore di carico, monitoraggio con avvisi, scalabilità orizzontale.
Giorno 7: finalmente ho dormito.
Il costo totale dell’infrastruttura è passato da 10 $/mese a circa 120 $/mese. Ma siamo passati da 200 messaggi/giorno a gestire comodamente 50.000. E l’architettura può ancora adattarsi semplicemente aggiungendo lavoratori.
La lista di controllo della scalabilità che avrei voluto avere
Se il tuo bot IA sta crescendo e vuoi essere pronto prima che arrivi il picco:
Configura il monitoraggio con avvisi ora. Tempi di risposta, tassi di errore, profondità della coda, utilizzo della memoria. Soglie di avviso a 2x i valori normali. Vuoi essere a conoscenza dei problemi prima che gli utenti te lo segnalino.
Implementa una coda di messaggi. Anche a basso volume. Questo disaccoppia la ricezione dall’elaborazione, consente ritentativi e rende la scalabilità orizzontale triviale in seguito.
Analizza il tuo utilizzo delle risorse per messaggio. Quante richieste di database per messaggio? Quanta memoria? Quanti chiamate API? Moltiplica questi numeri per il tuo obiettivo di crescita e vedi dove sono i colli di bottiglia.
Testa a 10 volte il tuo carico attuale. Usa uno strumento di test di carico per simulare un volume di messaggi moltiplicato per 10 per un’ora. Guarda cosa si rompe. Risolvilo prima che crolli in produzione.
Avere un piano di scalabilità documentato. “Se il traffico raddoppia, fai queste tre cose.” Avere il piano scritto significa che puoi eseguirlo alle 2 del mattino quando sei a metà addormentato invece di cercare di pensare a soluzioni sotto pressione.
Ciò che ho imparato sull’IA su larga scala
Il modello IA di solito non è il collo di bottiglia — tutto ciò che lo circonda lo è. Richieste di database, gestione del contesto, formattazione dell’output, instradamento dei messaggi — tutta l’infrastruttura “noiosa” che ometti quando costruisci un prototipo. Su larga scala, gli elementi noiosi sono più importanti degli elementi IA.
Inoltre: i limiti di velocità sono la restrizione di scalabilità più sottovalutata nelle applicazioni IA. La tua architettura brillante non ha importanza se l’API del modello consente solo 60 richieste al minuto. Controlla i tuoi limiti prima di lanciare e avrai un piano per quando li superi.
Il picco virale è stato stressante ma alla fine positivo. Ci ha costretti a costruire l’infrastruttura che avremmo dovuto mettere in atto fin dall’inizio. E ora siamo pronti per il prossimo picco — quando arriverà.
🕒 Published: