.webp)
One Trading e AWS potenziano il trading su cripto-asset per offrire la più bassa latenza di mercato
Scritto da Stefan Blackwood, Atiek Arian, Boris Litvin, Hani Masri e Sercan Karaoglu.
La latenza è una delle fonti di vantaggio competitivo e un focus continuo per gli scambi e i Market Makers nei mercati di capitali. Migliorare la latenza impatta positivamente l'esecuzione delle strategie di trading, migliorando la liquidità e aumentando la redditività sia per i mercati che per i partecipanti. AWS possiede capacità tecnologiche avanzate che miglioreranno le prestazioni di rete di One Trading attraverso la collocazione nativa nel cloud.
In questo blog, abbiamo esplorato il tema della latenza di rete nel trading di cripto-asset e i vantaggi offerti agli scambi e ai Market Makers utilizzando gruppi di collocamento cluster (CPG) condivisi su Amazon Elastic Compute Cloud (Amazon EC2). One Trading lancerà presto un nuovo prodotto di scambio (F.A.S.T.) che offre collocazione nativa nel cloud AWS. Nel seguente articolo, condivideremo i test rappresentativi eseguiti in collaborazione con AWS.
AWS ha lavorato con One Trading, prima del lancio, per quantificare l'esperienza prevista del Market Maker dal punto di vista della latenza di rete attraverso una gamma di potenziali topologie di accesso allo scambio. Abbiamo costruito un client di trading ad alta frequenza (HFT) semplificato che ha implementato una strategia specifica e misurato i tempi di andata e ritorno per gli ordini simulati, incluso il ritardo del motore di abbinamento.
Secondo i risultati dei test AWS, F.A.S.T. di One Trading ha raggiunto una latenza di andata e ritorno inferiore a 74 microsecondi, e anche a volumi molto elevati, il viaggio di andata e ritorno (creazione e cancellazione) ha raggiunto i 112 microsecondi (400k ordini al secondo) su latenze p95 attraverso topologie di rete AWS di nuova generazione. La tecnologia rivoluzionaria di One Trading fornisce un trading end-to-end medio di soli 112 microsecondi, più veloce anche dei 126 microsecondi raggiunti dal Turquoise del London Stock Exchange (LSE) Group, una delle principali strutture di trading multilaterali (MTF) (LSE, 2022). Inoltre, il motore di rischio e abbinamento di One Trading, che opera sotto 1 microsecondo (μs), è 1000 volte più veloce del Global Matching Engine di CME, che opera tra 1-3 millisecondi (ms) (Lambert, 2023).
La latenza senza precedenti di 1μs del matching engine è rimasta costante anche durante uno stress test di 24 ore, durante il quale ha elaborato 34 miliardi di ordini senza alcun calo di prestazioni.
La nostra visione in One Trading è di portare gli standard più elevati del mondo della finanza tradizionale nel trading di asset digitali attraverso la tecnologia e la regolamentazione. Abbiamo trascorso gli ultimi due anni perseguendo una strategia normativa che ci consentirà di sviluppare prodotti in un settore sempre più competitivo e di costruire F.A.S.T., un luogo di trading digitale di cripto-asset di nuova generazione per il trading spot e, presto, prodotti derivati regolamentati.
Dr Stefan Blackwood, capo dell'ingegneria quantitativa di One Trading, ha detto sul lavoro con gli specialisti AWS durante le attività di pre-lancio, "Abbiamo deciso di lavorare a stretto contatto con AWS, cercando di raggiungere i tipi di latenze solitamente viste nei mercati di trading tradizionali leader, ma volevamo che queste fossero disponibili per tutti i tipi di clienti, sia che fossero al dettaglio o istituzionali. Abbiamo intrapreso un piano aggressivo per portare la nostra latenza di andata e ritorno sotto i 200 microsecondi.
Josh Barraclough, CEO di One Trading, ha detto: "Il nostro obiettivo era costruire un luogo di trading che potesse fornire la scoperta dei prezzi più veloce, l'esecuzione più rapida e poter mantenere ciò senza degrado delle prestazioni indipendentemente dai volumi lanciati sul luogo. La nostra ambizione è di scalare questo prodotto, utilizzando il cloud AWS, oltre gli asset digitali, e sotto la nostra nuova struttura di licenza saremo in grado di offrire titoli tradizionali per tutti i clienti."
Per scopi di test, sono state utilizzate diverse topologie di rete per simulare opzioni di connettività reali che One Trading può fornire per l'accesso allo scambio ai propri clienti. Ogni topologia fornisce un diverso profilo di latenza e può essere considerata come diversi "livelli di connettività". È stato creato un Account AWS Market Maker simulato all'interno del quale abbiamo distribuito il client HFT di test. L'enfasi principale è stata posta sull'ottimizzazione della latenza di rete per questi test, quindi solo una singola Zona di Disponibilità AWS (AZ) è stata considerata per la misurazione della latenza. La stessa AZ è utilizzata sia per l'account Exchange che per l'account Market Maker in tutti i test, per evitare ulteriore latenza di rete causata dal superamento dei confini dell'AZ. Architetture resilienti coinvolgerebbero l'uso di più AZ con istanze Amazon EC2 leader-seguaci e meccanismi di replica sincroni o asincroni, solitamente implementati a livello di applicazione. I nostri diagrammi seguenti raffigurano una configurazione resiliente in due AZ.
Per questa configurazione di test, è stata creata una connessione di peering Amazon Virtual Private Cloud (Amazon VPC) tra il VPC di One Trading e il VPC del Market Maker. È stato quindi creato un gruppo di collocazione cluster Amazon EC2 (CPG) nell'account AWS di One Trading che è stato condiviso con l'account AWS del Market Maker. Le istanze Amazon EC2 per il motore di trading, il gateway degli ordini e il motore di abbinamento sono state avviate da entrambi gli account AWS in questo CPG.
Le istanze Amazon EC2 avviate in un CPG beneficiano di una maggiore località nella rete fisica sottostante di AWS all'interno della Zona di Disponibilità. La connettività logica è ottenuta utilizzando la connessione di peering ed è privata con il traffico trasportato sulla rete AWS nella regione AWS.
Questa topologia consente di accedere allo scambio con la latenza più bassa.
Questa configurazione di test è simile alla precedente, senza l'uso dei CPG Amazon EC2. Incorpora la strategia di posizionamento delle istanze Amazon EC2 predefinita in cui le istanze vengono distribuite casualmente dal punto di vista della capacità fisica sottostante nella Zona di Disponibilità. Pertanto, ciò non include alcuna disposizione speciale per la località di rete tra le istanze Amazon EC2. La connettività logica, come prima, è privata e realizzata tramite Amazon VPC peering.
Questa topologia fornisce un accesso allo scambio con latenza bassa, ma non la più bassa.
Per questa configurazione di test, la connettività logica tra i VPC di One Trading e del Market Maker è fornita da AWS PrivateLink. PrivateLink è un servizio completamente gestito progettato per fornire connettività tra VPC su scale estremamente grandi (migliaia di VPC) e introduce ulteriori passaggi nel percorso di rete (endpoint e bilanciatori di carico).
Questa topologia di rete continua a fornire connettività privata sulla rete AWS all'interno della regione AWS. PrivateLink richiede la fornitura di un Elastic Load Balancer-NetworkLoad Balancer all'interno del VPC di One Trading attraverso il quale i gateway degli ordini vengono esposti come un servizio. Questi gateway ricevono traffico di flusso degli ordini dagli endpoint PrivateLink creati nel VPC del Market Maker.
Questa topologia fornisce livelli medi di latenza per l'accesso allo scambio.
In questa configurazione di test, la connettività è fornita tramite una rete di distribuzione di contenuti Amazon CloudFront. La distribuzione CloudFront origina da un Elastic Load Balancer rivolto al pubblico, che indirizza il traffico ai gateway degli ordini nel VPC di One Trading. Questa topologia di rete coinvolge connettività pubblica e consente l'accesso allo scambio sia dall'interno che dall'esterno della regione AWS.
I Market Makers con presenze all'interno della regione AWS raggiungeranno la connettività ottimale poiché è instradata sulla rete di confine e regionale AWS e non esce su Internet pubblico, nonostante il traffico utilizzi uno spazio IP pubblico. I Market Makers esterni ad AWS possono accedere allo scambio utilizzando la propria connettività Internet e saranno indirizzati al punto di presenza CloudFront più vicino (PoP).
Se è richiesto che i motori di trading nel VPC del Market Maker siano distribuiti in sottoreti private, questa architettura può essere integrata con l'aggiunta di managed gateway NAT in quei VPC. Si noti che ciò aggiungerebbe latenza aggiuntiva.
Tra tutte le configurazioni di test, questa topologia fornisce la latenza più alta per l'accesso allo scambio.
Abbiamo creato un client HFT che è stato distribuito su istanze Amazon EC2 all'interno del VPC del Market Maker. Questo client ha implementato un algoritmo di trading a bassa latenza semplificato che ha indirizzato il flusso degli ordini attraverso le varie topologie di test di rete allo scambio di One Trading eseguendo i seguenti passaggi:
La seguente (Figura 5) è un semplice diagramma di sequenza che illustra i passaggi del flusso di messaggi precedenti.
Una volta completato questo ciclo di ordini, l'intera sequenza del flusso di ordini viene ripetuta. Sono stati creati più account sullo scambio, e questo processo è stato eseguito in parallelo. La logica di business testa quindi sia l'esecuzione sequenziale che parallela sia sul lato del motore di trading che su quello dello scambio. L'esecuzione parallela ha anche permesso di generare diversi flussi di ordini attraverso diverse velocità di attraversamento: basse e alte.
Le configurazioni a bassa velocità hanno generato 10.000 messaggi al secondo, e quelle ad alta velocità 400.000 messaggi al secondo, con una dimensione media del carico utile del messaggio di 120 byte.
I test sono stati condotti su istanze Amazon EC2 c6id.metal con Amazon Linux 2023. Per il client HFT sono state implementate le seguenti tecniche e ottimizzazioni del livello applicativo:
1. Affinità del processore del thread attraverso il pinning del core della CPU: Per ridurre la latenza causata dalla copia dei dati e delle istruzioni del thread nella cache della CPU, ogni thread viene appuntato su un core distinto. Il sistema operativo garantisce che un determinato thread venga eseguito solo su un core specifico.
2. Buffer compositi: Il client HFT implementa Netty come framework di rete dell'applicazione sottostante. I buffer compositi di Netty riducono l'allocazione di oggetti non necessari e le operazioni di copia quando si uniscono più frame di dati.
3. IO_uring: IO_uring è un'interfaccia di I/O asincrono per il kernel Linux. Implementa buffer ad anello di memoria condivisa che forniscono una coda tra l'applicazione e lo spazio kernel, riducendo la latenza grazie all'eliminazione di chiamate di sistema aggiuntive per le operazioni di I/O dell'applicazione.
4. Segregazione dei thread: I thread responsabili dell'I/O di rete sono tenuti distinti da quelli che calcolano le latenze di andata e ritorno e generano i dati dell'istogramma. Questo modello di responsabilità unica evita che la latenza generata dalla logica aziendale influisca sulla trasmissione dei messaggi d'ordine.
5. Ridurre la pressione della garbage collection (GC): Vengono utilizzate varie tecniche, tra cui il riscaldamento dei processi della macchina virtuale Java (JVM) per evitare interpretazioni ripetute e la compilazione di codice nativo da utilizzare nella cache, il riavvio regolare dei processi e parametri specifici della JVM per ridurre la pressione della GC.
Abbiamo reso disponibile il client HFT in questo repository GitHub, dove è possibile visualizzare il codice e leggere di più su come queste ottimizzazioni sono implementate.
Per mantenere una base di partenza semplice, molte ulteriori ottimizzazioni dello stack tipicamente implementate per tipi specifici di carichi di lavoro HFT non sono state applicate per questi test. I tipi di carichi di lavoro non applicati erano il trattamento degli IRQ, i controlli dello stato P e C della CPU, i buffer di rete, il bypass del kernel, lo scaling lato ricezione, lo steering dei pacchetti di trasmissione, le politiche del pianificatore Linux e l'ottimizzazione dell'adattatore di rete elastico AWS.
I test sono stati eseguiti simultaneamente su tutte le topologie di rete di prova per un periodo continuo di 24 ore. Ai fini della chiarezza e della massima utilità, i tempi di andata e ritorno non includono la latenza aggiunta dalla logica commerciale del client HFT e sono quindi una chiara rappresentazione del costo delle prestazioni della rete per ciascuna topologia. La tabella seguente (Figura 6) mostra i risultati aggregati.
I risultati ottenuti dimostrano che l'utilizzo del peering Amazon VPC e dei gruppi di collocazione cluster Amazon EC2 condivisi per alti tassi di messaggi al P99, è del 98% più veloce rispetto all'accesso utilizzando Internet con Amazon CloudFront e del 41% più veloce rispetto all'accesso tramite Amazon VPC peering senza l'uso di CPG condivisi.
In questo blog, abbiamo discusso come abbiamo lavorato con AWS durante le attività di pre-lancio per il nostro nuovo prodotto di scambio F.A.S.T. Abbiamo dimostrato che il nostro client HFT e lo scambio One Trading, distribuiti su istanze Amazon EC2 c6id.metal, sono in grado di scalare per elaborare un gran numero di ordini al secondo con una minima contesa applicativa. La latenza è stata introdotta come risultato delle varie topologie di rete di test implementate.
Abbiamo mostrato come l'implementazione di un'architettura che coinvolge il peering Amazon VPC e i gruppi di collocazione cluster Amazon EC2 condivisi fornisce il modello di connettività con la latenza più bassa.
Sebbene tutte le topologie testate siano funzionalmente valide e possano essere fornite da One Trading a diverse categorie di partecipanti al mercato, il peering Amazon VPC e i CPG condivisi offrono un livello di accesso materialmente vantaggioso per i loro più grandi clienti di market making.
Se siete interessati a saperne di più sul nuovo prodotto di scambio F.A.S.T. di One Trading, vi preghiamo di contattareOne Trading. Se desiderate eseguire test di prestazioni simili utilizzando o modificando il codice creato per questo client HFT, contattate un rappresentante AWS.
Dott. Stefan Blackwood
Un sviluppatore di algoritmi di successo e dottore di ricerca in matematica noto per superare costantemente le applicazioni leader attraverso soluzioni personalizzate. Come appassionato di tecnologia imprenditoriale, si entusiasma per l'innovazione, la risoluzione dei problemi e il percorrere strade inesplorate nel mondo in continua evoluzione della tecnologia.
Atiek Arian
Atiek è Senior Manager in Solutions Architecture all'interno del Global Financial Services presso AWS. Ha oltre 20 anni di esperienza nella progettazione e gestione di soluzioni di rete, calcolo e archiviazione nel settore dei servizi finanziari.
Boris Litvin
Boris è Principal Solution Architect presso AWS. Il suo lavoro è l'innovazione nel settore dei servizi finanziari. Boris è entrato in AWS dall'industria, più recentemente da Goldman Sachs, dove ha ricoperto una varietà di ruoli quantitativi in Equity, FX, Tassi di interesse ed è stato CEO e fondatore di una startup FinTech di trading quantitativo.
Hani Masri
Hani Masri è Senior Solutions Architect all'interno del Global Financial Services presso AWS. Supporta i clienti dei servizi finanziari nel loro percorso di migrazione verso il cloud e trasformazione digitale. Hani è appassionato di analisi dei dati e lavora nel settore da oltre 10 anni.
Sercan Karaoglu
Sercan Karaoglu è Senior Solutions Architect, specializzato nei mercati dei capitali. È un ex ingegnere dei dati e appassionato di ricerca sugli investimenti quantitativi.
I servizi di crypto-asset sono forniti da One Trading Markets S.r.l.
One Trading Markets S.r.l. è un fornitore di servizi di crypto-asset (Virtual Asset Service Provider - VASP) italiano registrato presso l'Organismo Agenti e Mediatori (OAM).
.webp)
.svg)
.png)
