Dai 13% di errori nelle richieste durante il Black Friday ai zero downtime: grazie all’implementazione containerizzata abbiamo risparmiato il 60% sui costi dei server.

Lo scorso Black Friday il nostro servizio di risoluzione degli indirizzi è andato completamente in tilt: il 13% delle richieste ha ricevuto il codice di errore 429, e il nostro servizio clienti ha ricevuto più di 300 lamentele da parte dei commercianti. Tre server backend hanno lavorato ininterrottamente per 24 ore per superare il picco di traffico. A quel tempo il nostro servizio funzionava su due server cloud con configurazioni fisse, e l’espansione o la riduzione della capacità richiedeva modifiche manuali alle configurazioni; solo quando venivano avviati nuovi server il picco di traffico era già passato.

Prima di tutto, dobbiamo capire cosa sia esattamente il containerization deployment.

In parole povere, si tratta di raggruppare tutto il codice, le librerie di dipendenza e i file di configurazione in un “contenitore” standardizzato, il cui peso varia da pochi MB a diversi centinaia di MB, in modo che l’ambiente di esecuzione sia 100% uniforme, indipendentemente dal server su cui viene eseguito il programma. L’immagine del servizio di risoluzione degli indirizzi che abbiamo inizialmente creato aveva una dimensione di...187MBIl processo di download e avvio richiede non più di 10 secondi.

I 3 principali benefici che abbiamo ottenuto concretamente

• L'auto-scaling ha davvero salvato la situazione: durante il Black Friday di quest'anno il traffico è aumentato di tre volte, il sistema ha automaticamente avviato 27 istanze di container e, una volta superato il picco, le ha ridotte a 3, tutto senza alcun intervento umano; il tasso di errori è sceso direttamente al di sotto dello 0,1%.
• Il bug legato alle discrepanze ambientali è completamente scomparso: i problemi “misteriosi” che funzionavano bene in locale ma fallivano non appena il sistema veniva messo online rappresentavano il 40% del totale dei bug che avevamo. Dopo il passaggio ai container, non si è più verificato nemmeno un singolo caso di questo tipo.
• I costi del server sono stati ridotti della metà: in passato, per far fronte ai picchi di traffico, noleggiavamo 8 server di alta configurazione per tutto l’anno, con un utilizzo medio del 15%. Ora paghiamo in base all’uso effettivo, risparmiando il 60% delle spese per i server su un anno intero.

Non guardiamo solo i vantaggi: abbiamo davvero commesso molti errori in questi casi.

Quando abbiamo iniziato a utilizzare il container, per comodità abbiamo conservato tutti i log e i file temporanei all’interno di esso. Purtroppo, a causa della distruzione automatica di un’istanza, i log relativi alle richieste degli ultimi 3 giorni sono andati persi, e il recupero dei dati ha richiesto ben due giorni interi. Un’altra volta, l’immagine del container conteneva troppe dipendenze inutili, il che ha aumentato il tempo di avvio da 10 secondi a 2 minuti; inoltre, quando è arrivato un improvviso aumento del traffico, non siamo riusciti a espandere le risorse in tempo, rischiando di avere un altro guasto.

Il problema più facile da trascurare sono quelli legati ai diritti di accesso: all’inizio abbiamo concesso ai container i diritti di root, il che è stato sfruttato da programmi di mining, che hanno occupato il 30% delle risorse CPU. Solo dopo una settimana siamo riusciti a scoprirlo attraverso i sistemi di monitoraggio.

Prima di tutto, pensa bene se davvero dovresti usarlo o meno.

Se siete un piccolo team di persone che sviluppa strumenti interni con flussi di traffico molto stabili, e avete solo 1-2 servizi in totale, non c’è davvero bisogno di complicarsi la vita: noleggiare un server è la soluzione più semplice e conveniente.

Ma se il traffico del tuo servizio è molto variabile, hai bisogno di aggiornamenti frequenti, ci sono problemi con l’interazione tra i diversi ambienti di sviluppo all’interno del team, o stai già spendendo troppo denaro per risorse di server inutilizzate, allora il deployment in container vale assolutamente la pena di essere provato, anche se richiede un po’ di tempo (un’intera settimana).

3 consigli concreti per chi si avvicina per la prima volta

• Non iniziare subito con i cluster K8S: prova prima a utilizzare Docker Compose per implementare una distribuzione su singolo host. Impara bene il funzionamento dei processi di packaging, esecuzione e montaggio dei log. È esattamente quello che abbiamo fatto nei primi 3 mesi, e ci è stato più che sufficiente.
• La prima volta che si crea un’immagine, si segue il “principio di minimizzazione”, installando soltanto le dipendenze necessarie per il funzionamento del sistema. Utilizzando un’immagine di base Alpine, è possibile ridurre il volume dell’immagine di oltre la metà.
• Tutti i dati e i log generati devono essere memorizzati su volumi di archiviazione esterni al container, e in nessun caso all’interno del container stesso. Questo punto è specificato all’inizio delle linee guida operative del vostro team.

Domande e risposte su problemi comuni

Domanda: Nessuno nel nostro team conosce i contenitori, il costo di apprendimento potrebbe essere molto alto?
Risposta: Per un uso base, basteranno 2 giorni per leggere i documenti di introduzione ufficiali per far funzionare il primo servizio; per le configurazioni più complesse dei cluster, potrai impararle quando ne avrai bisogno, senza problemi.

Domanda: Sarà molto complicato migrare i servizi esistenti nei container?
Le nostre 3 servizi di back-end sono state completamente migrate in una settimana; la maggior parte del tempo è stata impiegata per analizzare le dipendenze, mentre il tempo effettivamente trascorso nella scrittura dei file Dockerfile è stato inferiore a 1 giorno.