Con il gateway nativo del cloud abbiamo risparmiato il 38% dei costi di elaborazione del traffico, ma per poco non abbiamo rovinato la catena di distribuzione di prodotti freschi in Europa durante il Black Friday.

La riunione di analisi del grande evento promozionale di Black Friday di settimana scorsa è appena terminata, e il nostro team di tre persone responsabile del back-end per la distribuzione di prodotti freschi in Europa è ancora preoccupato: il giorno della pre-vendita, il 17% delle richieste di consegna in condizioni di refrigerazione è stato rifiutato (con codice di errore 429), il numero di reclami da parte degli utenti è aumentato di tre volte, e per poco non abbiamo rovinato l’evento promozionale annuale che avevamo preparato per tre mesi.

Il problema è derivato dall’uso di un gateway API tradizionale per due anni: abbiamo impostato un limite di traffico unico per due interfacce chiave, ovvero l’analisi degli indirizzi e la prenotazione della catena di freddo. Il giorno del Black Friday, le richieste di analisi degli indirizzi hanno superato il limite, occupando completamente la capacità del gateway, impedendo alle richieste di prenotazione di essere elaborate. In precedenza pensavamo che il cambio di gateway fosse una procedura riservata solo a team più grandi; solo dopo aver incontrato questo problema ci siamo resi conto che i gateway cloud-native potrebbero rappresentare una scelta più conveniente anche per team più piccoli.

Cosa è esattamente un gateway nativo del cloud?

In poche parole: è l’ingresso del traffico che opera all’interno di un cluster K8s, e non è necessario noleggiare server separatamente per il suo deployment.Devi occuparti solo delle regole di routing e delle strategie di limitazione del traffico; per il resto, la flessibilità delle risorse e gli aggiornamenti operativi sono gestiti interamente dal provider di cloud.La versione che stiamo utilizzando ora può gestire fino a 20.000 richieste al secondo per singolo istante, quindi non è necessario pianificare in anticipo la capacità di sistema.

Dopo il cambio, abbiamo ottenuto tre ricavi effettivi.

Dopo il guasto avvenuto il giorno della pre-vendita, abbiamo impiegato 3 giorni per passare al gateway nativo del cloud. Il giorno della finale di Black Friday non si è verificato più alcun problema legato al limitazione del traffico ( throttling). Inoltre, ci sono stati altri tre vantaggi che hanno superato le nostre aspettative:

• Il costo è stato ridotto direttamente: prima di noleggiare due server 4 core 8G per eseguire il gateway tradizionale, più un servizio di manutenzione che ha trascorso 8 ore al mese per eseguire l'aggiornamento della versione, calcolato il costo mensile di 1200 euro, ora il gateway nativo del cloud paga per il volume delle chiamate, spende solo 740 euro al mese,Si è risparmiato direttamente il 38% dei costi di elaborazione del traffico.
• Finalmente ho capito come funziona la strategia di limitazione del traffico: il gateway precedente poteva impostare solo un valore di limite globale per tutte le interfacce, ma ora possiamo definire regole indipendenti per diversi scenari di utilizzo. Ad esempio, per l’interfaccia di risoluzione degli indirizzi è possibile impostare un limite massimo di 5000 richieste al secondo; anche se questa interfaccia viene sovraccaricata, non influirà sulle operazioni successive, come i pagamenti o le prenotazioni.
• Il tempo necessario per il processo di handshake HTTPS è stato ridotto della metà: in precedenza, il nostro certificato SSL era memorizzato sul server di gateway, il che causava ritardi nell’handshake di fino a 200 ms per gli utenti in diverse regioni europee. Ora che il provider di cloud ha memorizzato il certificato nei nodi di edge, la maggior parte delle richieste vede un tempo di handshake inferiore a 80 ms.

Non affrettarti a salire in macchina, abbiamo già superato quei due ostacoli.

Non si può dire che i gateway cloud-native siano solo vantaggi; durante il processo di passaggio a questi sistemi, abbiamo anche incontrato due problemi che hanno quasi costretto a rifare il lavoro:

Il primo problema riguarda il ritardo di avvio a freddo. Dopo il primo giorno di test di carico, abbiamo notato che, dopo 10 minuti senza richieste, il tempo di risposta della prima ondata di richieste aumentava improvvisamente a oltre 300 ms. Solo in seguito abbiamo scoperto che le istanze flessibili fornite dal provider di cloud vengono avviate su richiesta e che è necessario impostare un numero minimo di istanze riservate per le interfacce principali; altrimenti, l’arrivo improvviso di traffico in momenti di inattività può facilmente causare tempi di attesa eccessivi.

Il secondo aspetto riguarda i limiti degli plugin personalizzati. Prima avevamo scritto un plugin per la verifica della firma delle richieste che funzionava su un gateway tradizionale, ma solo quando abbiamo cambiato a un gateway cloud-native ci siamo resi conto che supportava solo plugin in formato WebAssembly. Abbiamo impiegato due giorni per modificare il codice per adattarlo. Se hai molte logiche personalizzate, è meglio controllare prima quali plugin sono supportati dal fornitore.

Dovremmo davvero cambiarlo? Basta guardare questi due criteri di valutazione.

La situazione in cui dovresti cambiare è:

• Il team è composto da meno di 5 sviluppatori backend e non dispone di personale dedicato alle operazioni di manutenzione; non vogliamo dedicare tempo alla gestione e all'aggiornamento dei server gateway.
• Fluttuazioni del traffico molto elevate: ad esempio, durante le promozioni, il traffico può essere da 3 a 10 volte superiore al normale. Non vogliamo noleggiare in anticipo un gran numero di server che rimarrebbero inutilizzati, sprecando soldi.

Le situazioni in cui non dovresti cambiare:

• I requisiti di conformità sono particolarmente rigorosi: tutto il traffico deve passare attraverso i server che tu controlli personalmente, e non è consentito utilizzare i nodi pubblici dei fornitori di servizi cloud.
• Il tuo gateway dispone di molte logiche personalizzate e speciali che non sono supportate dai gateway cloud-native disponibili sul mercato; inoltre, il costo di modificare tali logiche da soli è più elevato rispetto al costo di mantenere il gateway stesso.

Tre piccoli consigli per chi inizia per la prima volta

• Non è necessario effettuare il passaggio dell’intero traffico in una sola volta; innanzitutto, reindirizzate il 10% del traffico al gateway cloud-native per una settimana e monitorate la situazione. Se non riscontrate alcun problema, potrete procedere gradualmente con il passaggio del resto del traffico. Noi abbiamo iniziato proprio con il reindirizzamento dell’interfaccia di risoluzione degli indirizzi, e solo dopo aver verificato che tutto funzionava correttamente abbiamo migrato l’intero traffico.
• Le interfacce principali devono avere un numero minimo di istanze attive; non risparmiare su questo. Ora abbiamo riservato 2 istanze permanenti per ciascuna delle due interfacce principali, quella per la prenotazione e quella per i pagamenti nel sistema di catena del freddo, e da allora non si sono più verificati problemi di timeout durante il avvio del sistema.
• Non è necessario acquistare la versione più avanzata: per la maggior parte delle piccole e medie imprese, le funzionalità della versione base sono più che sufficienti. Quella che stiamo utilizzando attualmente permette di gestire fino a 20.000 richieste al secondo (QPS) senza dover pagare ulteriormente.

L'ultima domanda più frequente posta all'interno del team riguarda: "Ci sarà il rischio di essere legati a un fornitore di servizi cloud?"

La nostra conclusione è: per un team di sviluppo backend composto da meno di 10 persone,L'aumento di efficienza derivante dall'essere legati a un provider di cloud è di gran lunga superiore al costo di dover costruire tutti i componenti da zero.Quando arriverà il momento di cambiare fornitore di cloud, avrai sicuramente le risorse necessarie per effettuare la migrazione; per ora non preoccupartene troppo.