Come abbiamo migliorato le prestazioni di Moove del 59%

La distanza era la nostra dipendenza più lenta

La maggior parte di chi apre la Moove app usa reti mobili in Nigeria e in Indonesia, a migliaia di chilometri dai server che rispondono alle sue richieste. Questo mese abbiamo cambiato il modo in cui quelle richieste ci raggiungono e il nostro tempo al primo byte (TTFB), cioè il tempo che passa tra l'invio di una richiesta da parte di un telefono e l'arrivo della prima parte della risposta, è sceso del 59%, da 0,74 secondi a 0,31 secondi. Per riuscirci non abbiamo spostato nemmeno un server.

Questo articolo spiega perché la distanza ci è costata più del previsto, cosa abbiamo cambiato, la parte che si è rivelata più difficile del cambiamento stesso e cosa diremmo a un altro team che sta per fare la stessa cosa.

Perché un lungo viaggio diventa tre

Gli ingegneri chiamano latenza il ritardo tra l'invio di qualcosa e il suo arrivo, e tempo di andata e ritorno (RTT) il tempo necessario perché un messaggio raggiunga un server e la risposta torni indietro. Da Lagos ai nostri server l'RTT è compreso tra 200 e 300 millisecondi. Da solo, è un ritardo tollerabile. Il problema è che una richiesta raramente viaggia da sola.

Prima che un telefono possa chiedere qualcosa tramite una connessione sicura, deve completare due handshake, i brevi scambi che stabiliscono una connessione. L'handshake TCP apre la connessione, poi l'handshake TLS concorda le chiavi di cifratura che la mantengono privata. Ciascuno costa un viaggio di andata e ritorno completo. Solo dopo parte la richiesta vera e propria, che è il terzo viaggio. A 250 millisecondi a viaggio, l'utente aspetta circa tre quarti di secondo prima che i nostri server abbiano svolto qualsiasi lavoro.

Sulle reti mobili questo costo si paga molto più spesso di quanto si vorrebbe. I telefoni passano da una cella all'altra, le radio vanno in sospensione per risparmiare batteria e le app vengono mandate in background. Ognuno di questi eventi può far cadere la connessione, e la richiesta successiva deve ripartire da una connessione a freddo, cioè senza alcun handshake già eseguito, e pagare di nuovo l'intero costo di apertura. Una connessione a caldo, già aperta e protetta, passa direttamente alla richiesta.

Non potevamo avvicinare Lagos ai nostri server. Potevamo però avvicinare a Lagos la fase di apertura.

Spostare l'handshake, non i server

Una rete di distribuzione dei contenuti (CDN) di solito viene descritta come una cache: un insieme di sedi nel mondo che conservano copie dei file per servirli da vicino. Noi ne abbiamo usata una per un altro motivo. Per la nostra API, l'interfaccia con cui l'app comunica per tutto ciò che fa, la cache è disattivata del tutto. Ogni richiesta continua ad arrivare al nostro origin, il nome che la CDN dà ai server che ha alle spalle.

Cambia il punto in cui parte la connessione. Ora un telefono apre la connessione con la sede periferica (edge) più vicina, detta anche punto di presenza (PoP): una delle sedi della CDN nel mondo, spesso a decine di millisecondi di distanza invece che a centinaia. L'edge esegue la terminazione TLS, cioè la connessione sicura con il telefono finisce lì. Poi riutilizza un insieme di connessioni a caldo verso il nostro origin, mantenute aperte con il keep-alive, un'impostazione che lascia aperta una connessione tra una richiesta e l'altra invece di chiuderla. I due costosi viaggi di apertura avvengono sul tratto breve e solo la richiesta vera e propria attraversa l'oceano, su una connessione già a caldo.

Tre viaggi lunghi diventano un viaggio lungo e due brevi. Tutta l'idea è qui.

Il resto l'abbiamo tenuto volutamente semplice:

• I client non si sono accorti di nulla. L'app e il sito web hanno mantenuto gli stessi indirizzi, quindi non è servito alcun rilascio dell'app e nessuno ha dovuto aggiornare niente.
• Il comportamento in caso di errore è rimasto lo stesso. I timeout corrispondono a quelli di prima, quindi ciò che falliva prima fallisce ancora allo stesso modo. Non volevamo nuovi tipi di errore.
• L'edge chiude per primo le connessioni inattive. Ogni connessione ha un timeout di inattività, il tempo per cui può restare inutilizzata prima di essere chiusa. Se i nostri server chiudessero una connessione silenziosa mentre l'edge la ritiene ancora aperta, la richiesta successiva fallirebbe. Impostare un timeout più breve sull'edge fa sì che sia sempre lui a rinunciare per primo e ad aprire una connessione nuova.
• Protocolli più recenti per i telefoni. I telefoni possono connettersi tramite HTTP/3, l'ultima versione del protocollo web per le richieste. Funziona su QUIC, che unisce i due handshake in un unico viaggio di andata e ritorno e gestisce meglio la perdita di pacchetti, frequente sulle reti mobili.
• Nessuna regione esclusa. I livelli più economici di una rete edge spesso saltano sedi proprio nelle parti del mondo in cui vivono i nostri utenti, quindi abbiamo scelto la copertura completa.

Cosa abbiamo misurato

Abbiamo misurato da Sydney, che dai nostri server dista all'incirca quanto Lagos, confrontando il vecchio percorso con il nuovo. Per ciascuno abbiamo aperto cinque connessioni a freddo nuove, il caso che conta di più sulle reti mobili, e abbiamo preso la mediana, indicata anche come p50: il risultato centrale, che metà delle richieste batte e metà no. Lo stesso progetto ha anche attivato la compressione per gli script del nostro sito web, che prima venivano inviati a dimensione piena. La compressione riduce un file prima dell'invio e il browser lo espande di nuovo all'arrivo; abbiamo usato Brotli, un formato di compressione pensato per il web.

Il tempo al primo byte è l'origine del 59%. Una connessione che prima richiedeva mezzo secondo per aprirsi ora è pronta in meno di un decimo di secondo, e una prima visita al nostro sito web ora scarica due terzi in meno, su connessioni in cui molte persone pagano ogni megabyte.

Questi numeri vengono da una sola città e non sono un benchmark globale. Il ragionamento però vale anche per Lagos e Giacarta, ed è lì che si trovano i nostri utenti.

La parte difficile era sapere chi sta chiamando

Mettere qualcosa davanti ai propri server è facile. Far continuare a funzionare le protezioni che stanno dietro è stato il punto in cui è andata la maggior parte dell'impegno.

Come la maggior parte delle piattaforme di pagamento, Moove usa il rate limiting, un limite al numero di richieste che un singolo chiamante può fare in un dato intervallo di tempo, e questi limiti sono legati all'indirizzo IP del chiamante, il numero che identifica un dispositivo su internet. Dietro una rete edge, ogni richiesta arriva dall'indirizzo di una sede edge invece che da quello dell'utente. Se nient'altro fosse cambiato, tutti a Lagos avrebbero condiviso un solo budget, e un pomeriggio intenso avrebbe iniziato a respingere persone che non avevano fatto nulla di sbagliato.

La soluzione si basa su due idee.

Fidarsi esattamente dei livelli che si hanno. Una CDN è un tipo di reverse proxy, un server che si pone davanti al tuo e inoltra le richieste. Ogni proxy aggiunge l'indirizzo da cui ha ricevuto una richiesta a un'intestazione standard chiamata X-Forwarded-For, quindi il vero chiamante si trova a un numero fisso di passaggi, o hop, all'indietro in quell'elenco. Sbagliare quel numero è un bug in entrambe le direzioni. Se si contano troppo pochi livelli, ogni utente sembra la propria sede edge. Se se ne contano troppi, ci si fida di una voce scritta dal chiamante stesso. Per questo abbiamo reso quel numero una proprietà dell'infrastruttura e non del codice. Cambia nello stesso momento in cui cambia la rete, e il nostro servizio rifiuta di avviarsi se il valore non ha senso, invece di tirare a indovinare.

Far garantire l'edge per il chiamante e credere solo all'edge. Ora l'edge scrive l'indirizzo del vero chiamante su ogni richiesta e sovrascrive qualsiasi cosa il chiamante abbia inviato al suo posto. Le nostre protezioni credono a quel valore solo quando possono verificare che la richiesta sia davvero passata dal nostro edge. Ogni limite che prima era legato all'indirizzo di rete ora è legato al vero chiamante per il traffico che passa dall'edge. Queste regole le abbiamo aggiunte accanto alle vecchie invece di modificarle, così ogni passo del rilascio era una pura aggiunta che chiunque poteva rivedere in una sola lettura.

Un bug individuato prima del rilascio

I Moove Profiles possono vivere sul dominio di un esercente. Le richieste per quei domini venivano inoltrate attraverso il nostro sito web con allegato il dominio dell'esercente, così il sito sapeva quale profilo mostrare.

Il nuovo edge davanti al sito web elimina questo tipo di informazioni dalle richieste in ingresso, ed è giusto così, perché un visitatore non dovrebbe mai poterle impostare. Voleva però dire che, una volta spostato il sito dietro l'edge, ogni dominio di esercente avrebbe mostrato in silenzio la home page di Moove invece del profilo dell'esercente.

Ce ne siamo accorti in fase di revisione, abbiamo spostato per prima cosa il percorso dei domini degli esercenti su una rotta separata e abbiamo fatto in modo che la nostra infrastruttura si rifiuti di applicare la modifica al sito web ovunque quello spostamento non sia avvenuto. Un errore che prima viveva solo nella testa di chi faceva la revisione ora è qualcosa che la build blocca.

La lezione generale: quando aggiungi un livello che ripulisce gli input, cerca tutto ciò che dipendeva dagli input che stai per ripulire.

Come l'abbiamo rilasciato

Per l'infrastruttura dei pagamenti non vale il "rilascia e vedi", quindi abbiamo modificato prima lo staging e poi la produzione, e alcune scelte hanno reso il passaggio senza sorprese. Abbiamo abbassato il TTL (time to live, tempo di vita) sui nostri record DNS, la rubrica di internet che trasforma un nome come moove.xyz in un indirizzo di server. Il TTL indica per quanto tempo il resto di internet può tenere in cache quella risposta, e noi l'abbiamo ridotto da un'ora a cinque minuti, un'ora intera prima che si spostasse qualsiasi cosa, così la vecchia risposta era scaduta ovunque e un rollback avrebbe avuto effetto in pochi minuti. Abbiamo mantenuto i record degli indirizzi in una forma che poteva essere cambiata sul posto, perché rimuoverli e ricrearli avrebbe lasciato un vuoto, e un vuoto è un'interruzione. Ogni passo rischioso è stato una piccola modifica a sé, con i passaggi per annullarla scritti in ordine.

Cosa diremmo a un altro team

Se i tuoi utenti sono lontani dai tuoi server, una rete edge vale la pena anche quando non mette nulla in cache. Prima del passaggio:

• Elenca tutto ciò che legge l'indirizzo del chiamante, inclusi rate limit, allowlist, segnali antifrode, log di audit e regole di sicurezza. Ognuno di questi vede l'indirizzo dell'edge, a meno che tu non lo cambi.
• Rendi il numero di livelli di cui ti fidi parte della tua infrastruttura e rifiuta l'avvio quando è sbagliato.
• Lascia che sia l'edge a registrare il vero chiamante e fidati di quella registrazione solo sul traffico che puoi verificare provenire dal tuo edge.
• Assicurati che i tuoi server accettino traffico solo attraverso l'edge e osserva prima di far rispettare la regola.
• Se metti in cache le pagine, costruisci la chiave di cache, l'insieme dei dettagli di una richiesta che una cache usa per decidere se due richieste possono condividere una sola risposta salvata, a partire da tutto ciò da cui la risposta dipende davvero. I server elencano questi dettagli in un'intestazione Vary, quindi leggila invece di affidarti alla memoria.
• Misura prima e dopo, e guarda separatamente il tempo di handshake e il tempo al primo byte, così puoi distinguere l'apertura della connessione dal tempo che i tuoi server dedicano al lavoro.

Uno sguardo al futuro

La maggior parte delle nostre pagine è personalizzata, quindi per ora la cache edge del sito web resta per lo più inutilizzata. Il miglioramento della connessione vale per ogni pagina in ogni caso, e le singole pagine ora possono scegliere di usare la cache quando è sicuro condividerle. Mettere in cache le risposte dell'API richiederebbe un progetto e una revisione a parte, ed è la prossima cosa che vogliamo esaminare.

Il denaro dovrebbe muoversi alla velocità della rete, non alla velocità della luce attraverso un oceano.

Se sviluppi su Moove, leggi la nostra introduzione alle API e agli SDK per pagamenti Web3 e il Moove Developer Program.

Scritto dal team di ingegneria di moove.xyz.

Chi è moove.xyz

moove.xyz è una piattaforma fintech Web3 globale, creata per il movimento permissionless e senza sforzo del valore. Diamo a aziende e consumatori di ogni parte del mondo la possibilità di inviare, ricevere, fare staking e swap di qualsiasi criptovaluta su qualsiasi blockchain, tutto in un'unica piattaforma.

Siamo una delle prime aziende fintech Web3 al mondo a innovare e costruire un'infrastruttura completa per i pagamenti crypto e la finanza decentralizzata, con una copertura integrata e completa di accesso a wallet multi-chain, handle personalizzati per il wallet, swap di token cross-chain, transazioni cross-chain integrate e una rete finanziaria sociale decentralizzata. I nostri prodotti principali sono Moove Profile, Moove Send, Moove Receive, Moove Stake, Moove Swap, Moove Rewards, Moove Discover e altri.

La nostra missione è semplice: creare e distribuire tecnologia finanziaria permissionless e senza sforzo per il prossimo miliardo di utenti Web3. Crediamo fermamente che il futuro del movimento di denaro e valore sarà a costo zero, senza confini, permissionless, senza sforzo e pensato per tutti, e stiamo costruendo la piattaforma fintech Web3 definitiva per renderlo reale.

Il tuo denaro. La tua mossa.