Abbiamo risolto gli errori durante la promozione del 429 utilizzando il gateway Kubernetes, e inoltre abbiamo risparmiato il 30% sui costi dei server.

Il mese scorso, durante il Black Friday, il nostro team è quasi andato in tilt:Il 13% delle richieste di risoluzione degli indirizzi utente viene rifiutato direttamente con il codice di errore 429.Dopo aver controllato in background per mezza giornata, abbiamo scoperto che le regole di limitazione del traffico assegnate individualmente a ciascun microservizio erano troppo rigide. Di conseguenza, il traffico del modulo di ricerca logistica è aumentato di tre volte, e le risorse disponibili non sono state in grado di essere utilizzate per altri scopi.

Prima pensavamo sempre che il gateway di Kubernetes fosse un componente complesso utilizzato solo dalle grandi aziende, fino a quando non abbiamo incontrato alcuni problemi e siamo stati costretti ad implementarlo. Tutto questo è avvenuto in meno di una settimana, e i risultati sono stati molto migliori di quanto ci aspettassimo.

Cosa è esattamente il gateway di Kubernetes?

In parole povere, è l’ingresso unico per il traffico di tutto il vostro cluster Kubernetes: tutte le richieste esterne arrivano prima qui, per poi essere inoltrate ai servizi backend corrispondenti. La versione open source che utilizziamo è in grado di gestire fino a 12.000 richieste al secondo con un singolo istante, quindi per le piccole squadre non c’è alcun bisogno di preoccuparsi di problemi di prestazioni.

Tre vantaggi concreti che abbiamo ottenuto

Il primo aspetto più evidente è che non è più necessario configurare regole di limitazione del traffico per ogni servizio separatamente. In passato, durante le promozioni, dovevamo modificare i valori di limitazione del traffico per sette o otto microservizi; se ne mancava uno, si verificavano problemi. Ora, invece, la limitazione del traffico avviene direttamente a livello di gateway, e le risorse di server disponibili vengono automaticamente assegnate ai moduli con un maggior carico di traffico. Durante la grande promozione di Natale, il numero di errori di tipo 429 è diminuito drasticamente, fino a zero.

Il secondo aspetto importante è la riduzione dei costi. In precedenza, per gestire i picchi di traffico, avevamo aggiunto 2 server di riserva per ciascuno dei 3 servizi principali, ma la maggior parte del tempo il tasso di utilizzo delle risorse era solo del 20%. Ora che il gateway è in grado di effettuare il bilanciamento del carico automaticamente, abbiamo ridotto il numero di server di 6 unità, e i calcoli indicano che i costi cloud mensili sono diminuiti del 30%.

Il terzo vantaggio è che non è necessario che il backend modifichi ripetutamente logiche comuni come il controllo delle cross-domain e l’autenticazione. In passato, ogni volta che veniva lanciato un nuovo servizio, il backend doveva scrivere il codice per il controllo JWT; ora basta impostare una regola a livello di gateway e il problema è risolto. Grazie a questo, noi tre sviluppatori del backend possiamo dedicare almeno mezza giornata in più ogni settimana allo sviluppo del codice per le funzionalità specifiche del servizio.

Non ascoltate solo i vantaggi: abbiamo commesso questi due errori in modo piuttosto grave.

Il primo problema è che l’impostazione predefinita del timeout è davvero problematica. Già il primo giorno di lancio abbiamo riscontrato che il 5% delle richieste di risoluzione degli indirizzi veniva bloccato a causa del timeout. Dopo molte ricerche abbiamo scoperto che il timeout predefinito del gateway era di 30 secondi, mentre il nostro servizio di risoluzione degli indirizzi richiedeva in realtà fino a 40 secondi per completare il suo lavoro. Dopo aver modificato le impostazioni del timeout, il problema è stato immediatamente risolto. Prima di lanciare il servizio, è fondamentale verificare uno per uno i valori dei timeout in base alle esigenze delle proprie interfacce di business.

Il secondo errore da evitare è quello di attivare tutte le funzionalità all’inizio. Inizialmente volevamo abilitare contemporaneamente log, throttling, WAF e il lancio in modalità grigia, ma abbiamo commesso un errore nella configurazione che ha causato il blocco dell’intero cluster per 20 minuti. Successivamente abbiamo attivato solo routing e throttling, e dopo tre giorni di funzionamento stabile, abbiamo aggiunto gradualmente le altre funzionalità senza più incorrere in problemi.

Dovremmo usarlo o no? I criteri che abbiamo per prendere questa decisione sono molto semplici.

Casi in cui è adatto:

• Il numero dei tuoi microservizi ha superato le 5 unità, e ogni volta che devi modificare le configurazioni comuni, devi apportare modifiche in diversi punti del sistema.
• Si verificano spesso picchi di traffico, e non è possibile allocare le risorse in modo flessibile tra i diversi servizi.
• Il team di sviluppo backend è composto da meno di 5 persone e non vogliamo sprecare tempo a scrivere ripetutamente logiche comuni.

Situazioni in cui non vale la pena perdere tempo:

• Hai solo due microservizi, il traffico è stabile tutto l’anno, e l’utilizzo di NGINX per la reindirizzione non presenta alcun problema.
• Nessuno nel team conosce le basi di Kubernetes; non cercare di adottare nuove tecnologie a tutti i costi solo per stare al passo con le tendenze.

Due consigli concreti per piccoli team che stanno iniziando per la prima volta

Non c’è bisogno di preoccuparsi troppo per la scelta del software: per le piccole squadre è sufficiente utilizzare API-SIX o Kong, entrambi open source. Sono disponibili documentazioni complete e, in caso di problemi, basta cercare online per trovare soluzioni. Non è necessario acquistare la versione commerciale; le funzionalità della versione gratuita sono più che sufficienti.

Prima di lanciare il servizio, distribuire il 10% del traffico per 24 ore, concentrandosi principalmente su eventuali problemi di timeout o intercettazioni errate delle richieste. Solo se tutto va bene, passare il traffico intero. Non trasferire tutto il traffico all’improvviso.

Infine, una domanda che tutti fanno spesso: nessuno dei nostri tre sviluppatori di backend aveva precedentemente studiato i gateway in modo approfondito, ma abbiamo costruito il sistema in due giorni seguendo la documentazione ufficiale. Non è affatto così complicato come potreste pensare.