.webp)
One Trading und AWS verbessern den Kryptohandel und bieten die niedrigste Marktlatenz
Geschrieben von Dr. Stefan Blackwood, Atiek Arian, Boris Litvin, Hani Masri, und Sercan Karaoglu
Latenz ist eine der Quellen für Wettbewerbsvorteile und ein kontinuierlicher Fokus für Börsen und Market Maker auf den Kapitalmärkten. Die Verbesserung der Latenz wirkt sich positiv auf die Ausführung von Handelsstrategien aus, steigert die Liquidität und erhöht die Rentabilität für Handelsplätze und Teilnehmer. AWS verfügt über fortschrittliche technologische Fähigkeiten, die die Netzwerkleistung von One Trading durch Cloud-native Colocation verbessern werden.
In diesem Blog haben wir das Thema Netzwerklatenz im Krypto-Assets-Handel und die Vorteile, die Börsen und Market Makern durch die Nutzung von gemeinsam genutzten Amazon Elastic Compute Cloud (Amazon EC2) Clusterplatzierungsgruppen (CPGs) geboten werden, untersucht. One Trading wird bald ein neues Börsenprodukt (F.A.S.T.) einführen, das native Colocation in der AWS Cloud bietet. Im folgenden Artikel werden wir repräsentative Tests vorstellen, die in Partnerschaft mit AWS durchgeführt wurden.
AWS arbeitete mit One Trading vor dem Start zusammen, um die erwartete Erfahrung des Market Makers aus der Perspektive der Netzwerklatenz über eine Reihe potenzieller Börsenzugangstopologien zu quantifizieren. Wir entwickelten einen vereinfachten High-Frequency-Trading (HFT) Client, der eine spezifische Strategie implementierte und die Round-Trip-Zeiten für simulierte Orders maß, einschließlich der Latenz des Matching-Engines.
Laut den AWS-Testergebnissen erreichte One Tradings F.A.S.T. unter 74 Mikrosekunden für einen Roundtrip, und selbst bei sehr hohen Volumina erreichte der Roundtrip (Erstellen und Stornieren) 112 Mikrosekunden (400.000 Orders pro Sekunde) bei p95-Latenzen durch Netzwerktopologien der nächsten Generation von AWS. One Tradings bahnbrechende Technologie bietet einen durchschnittlichen End-to-End-Handel von nur 112 Mikrosekunden, schneller sogar als die 126 Mikrosekunden, die auf dem Turquoise der London Stock Exchange (LSE) Group, einer führenden Multilateral Trading Facility (MTF), erreicht wurden (LSE, 2022). Darüber hinaus ist One Tradings Risiko- und Matching-Engine, die unter 1 Mikrosekunde (μs) operiert, 1000-mal schneller als CMEs Global Matching Engine, die 1-3 Millisekunden (ms) betreibt (Lambert, 2023).
Die beispiellose Latenz von 1μs der Matching-Engine blieb auch während eines 24-Stunden-Stresstests konstant, bei dem 34 Milliarden Aufträge ohne Leistungsabfall verarbeitet wurden.
One Trading ist entschlossen, das Beste aus der traditionellen Finanzwelt und den Krypto-Asset-Märkten zusammenzubringen. Wir haben den weltweit schnellsten und zuverlässigsten Handelsplatz entwickelt, der in der Lage ist, Arbitrage-Gelegenheiten auf anderen Handelsplätze zu eröffnen. Wir verfolgen dabei auch eine einzigartige regulatorische Strategie und werden einen vollwertigen Handelsplatz unter höchsten Standards anbieten, anstatt – wie Mitbewerber – bloß auf Basis einer Broker-Lizenz zu arbeiten.
Dr. Stefan Blackwood, Leiter des Quant Engineering bei One Trading, sagte über die Arbeit mit AWS-Spezialisten während der Vorstartaktivitäten: „Wir haben uns entschieden, eng mit AWS zusammenzuarbeiten, um die Arten von Latenzen zu erreichen, die normalerweise auf den marktführenden traditionellen Handelsplätzen zu sehen sind, aber wir wollten, dass diese für alle Kundentypen verfügbar sind, egal ob sie Einzelhandels- oder institutionelle Kunden sind. Wir haben einen aggressiven Plan verfolgt, um unsere Round-Trip-Latenz auf unter 200 Mikrosekunden zu bringen.
Josh Barraclough, CEO von One Trading, sagte: „Unser Ziel war es, einen Handelsplatz zu bauen, der die schnellste Preisfindung und schnellste Ausführung bieten kann und dies unabhängig vom Handelsvolumen ohne Leistungseinbußen aufrechterhält. Unser Ehrgeiz ist es, dieses Produkt mit der AWS Cloud über digitale Vermögenswerte hinaus zu skalieren, und unter unserer neuen Lizenzstruktur werden wir in der Lage sein, traditionelle Wertpapiere für alle Kunden anzubieten.“
Zu Testzwecken wurden verschiedene Netzwerktopologien verwendet, um realweltliche Konnektivitätsoptionen zu simulieren, die One Trading für den Zugang zur Börse für ihre Kunden bieten kann. Jede Topologie bietet ein unterschiedliches Latenzprofil und kann als unterschiedliche „Konnektivitätsebenen“ betrachtet werden. Ein simuliertes Market Maker AWS-Konto wurde erstellt, in dem wir den Test-HFT-Client implementiert haben. Der primäre Schwerpunkt lag auf der Optimierung der Netzwerklatenz für diese Tests, daher wurde nur eine einzelne AWS Availability Zone (AZ) bei der Messung der Latenz berücksichtigt. Dieselbe AZ wird in allen Tests sowohl für Exchange- als auch für Market Maker-Konten verwendet, um zusätzliche Netzwerklatenz, die durch das Überschreiten von AZ-Grenzen entsteht, zu vermeiden. Resiliente Architekturen würden den Einsatz mehrerer AZs mit Leader-Follower Amazon EC2-Instanzen und synchronen oder asynchronen Replikationsmechanismen beinhalten, die normalerweise auf Anwendungsebene implementiert werden. Unsere folgenden Diagramme stellen eine resiliente Konfiguration in zwei AZs dar.
Für diese Testkonfiguration wurde eine Peering-Verbindung zwischen dem Amazon Virtual Private Cloud (Amazon VPC) Peering-Verbindung von One Trading und dem Market Maker VPC erstellt. Anschließend wurde eine Amazon EC2 CPG im AWS-Konto von One Trading erstellt, die mit dem Market Maker AWS-Konto geteilt wurde. Handelsmotor-, Ordergateway- und Matching-Engine-Amazon EC2-Instanzen wurden von beiden AWS-Konten in diese CPG gestartet.
Amazon EC2-Instanzen, die in eine CPG gestartet werden, profitieren von einer größeren Lokalität im zugrunde liegenden physischen AWS-Netzwerk innerhalb der Verfügbarkeitszone. Logische Konnektivität wird durch die Peering-Verbindung erreicht und ist privat, wobei der Datenverkehr über das AWS-Netzwerk in der AWS-Region übertragen wird.
Diese Topologie bietet den Zugang zur Börse mit der geringsten Latenz.
Diese Testkonfiguration ist ähnlich der vorherigen, jedoch ohne die Verwendung von Amazon EC2 CPGs. Sie beinhaltet die Standard-Platzierungsstrategie von Amazon EC2-Instanzen, bei der Instanzen zufällig aus der Perspektive der zugrunde liegenden physischen Kapazität in der Verfügbarkeitszone bereitgestellt werden. Daher umfasst dies keine spezielle Vorgabe für die Netzwerklokalität zwischen Amazon EC2-Instanzen. Die logische Konnektivität ist, wie zuvor, privat und wird durch Amazon VPC Peering erreicht.
Diese Topologie bietet Zugang zur Börse mit niedriger, aber nicht der niedrigsten Latenz.
Für diese Testkonfiguration wird die logische Konnektivität zwischen den VPCs von One Trading und Market Maker durch AWS PrivateLink bereitgestellt. PrivateLink ist ein vollständig verwalteter Dienst, der darauf ausgelegt ist, Konnektivität zwischen VPCs in extrem großen Maßstäben (Tausende von VPCs) zu bieten und führt zusätzliche Sprünge im Netzwerkpfad ein (Endpunkte und Lastausgleich).
Diese Netzwerktopologie bietet weiterhin private Konnektivität über das AWS-Netzwerk innerhalb der AWS-Region. PrivateLink erfordert die Bereitstellung eines Elastic Load Balancer-NetworkLoad Balancer innerhalb des One Trading VPC, über den die Order-Gateways als Dienst freigelegt werden. Diese Gateways empfangen den Order-Flow-Verkehr von PrivateLink-Endpunkten, die im Market Maker VPC erstellt wurden.
Diese Topologie bietet mittlere Latenzniveaus für den Zugang zur Börse.
In dieser Testkonfiguration wird die Konnektivität durch ein Amazon CloudFront Content Distribution Network bereitgestellt. Die CloudFront-Distribution stammt von einem öffentlich zugänglichen Elastic Load Balancer, der den Verkehr zu den Order-Gateways im One Trading VPC leitet. Diese Netzwerktopologie beinhaltet öffentliche Konnektivität und ermöglicht den Zugang zur Börse sowohl von innerhalb als auch von außerhalb der AWS-Region.
Market Maker mit Standorten innerhalb der AWS-Region erreichen eine optimale Konnektivität, da der Verkehr über das AWS-Region- und Grenznetzwerk geleitet wird und nicht ins öffentliche Internet austritt – trotz der Verwendung eines öffentlichen IP-Bereichs. Market Maker, die außerhalb von AWS sind, können auf den Handel zugreifen, indem sie ihre eigene Internetverbindung nutzen und zum nächstgelegenen CloudFront Point of Presence (PoP) geleitet werden.
Falls Handelsmotoren im Market Maker VPC in privaten Subnetzen bereitgestellt werden müssen, kann diese Architektur durch Hinzufügen von verwalteten NAT-Gateways in diesen VPCs ergänzt werden. Beachten Sie, dass dies zusätzliche Latenz hinzufügt.
Von allen Testkonfigurationen bietet diese Topologie den höchsten Latenzzugang zur Börse.
Wir haben einen HFT-Client erstellt, der auf Amazon EC2-Instanzen im Market Maker VPC bereitgestellt wurde. Dieser Client implementierte einen vereinfachten Low-Latency-Handelsalgorithmus, der den Order-Flow über die verschiedenen Netzwerk-Testtopologien zum One Trading-Austausch leitete, indem er die folgenden Schritte ausführte:
Die folgende (Figur 5) ist ein einfaches Sequenzdiagramm, das die vorangegangenen Nachrichtenflussschritte veranschaulicht.
Sobald dieser Orderzyklus abgeschlossen ist, wird die gesamte Orderflusssequenz wiederholt. Mehrere Konten wurden auf der Börse erstellt, und dieser Prozess wurde parallel ausgeführt. Die Geschäftslogik testet daher sowohl die sequenzielle als auch die parallele Ausführung sowohl auf der Seite des Handelsmotors als auch der Börse. Die parallele Ausführung ermöglichte auch das Generieren unterschiedlicher Orderfluss-Durchsätze – niedrige und hohe Raten.
Niedrigraten-Konfigurationen generierten 10.000 Nachrichten pro Sekunde und Hochraten-Konfigurationen 400.000 Nachrichten pro Sekunde bei einer durchschnittlichen Nachrichtengröße von 120 Byte.
Die Tests wurden auf Amazon EC2 c6id.metal-Instanzen unter Amazon Linux 2023 durchgeführt. Die folgenden Optimierungen und Techniken der Anwendungsschicht wurden für den HFT-Client implementiert:
1. Thread-Prozessor-Affinität durch CPU-Kern-Pinning: Um die durch das Kopieren von Thread-Daten und -Befehlen in den CPU-Cache verursachte Latenz zu verringern, wird jeder Thread an einen bestimmten Kern gebunden. Das Betriebssystem stellt sicher, dass ein bestimmter Thread nur auf einem bestimmten Kern ausgeführt wird.
2. Zusammengesetzte Puffer: Der HFT-Client implementiert Netty als das zugrunde liegende Anwendungsnetzwerk. Zusammengesetzte Puffer in Netty reduzieren unnötige Objektzuweisungen und Kopiervorgänge beim Zusammenführen mehrerer Datenrahmen.
3. IO_uring: IO_uring ist eine asynchrone E/A-Schnittstelle für den Linux-Kernel. Sie implementiert gemeinsam genutzte Speicherringpuffer, die eine Warteschlange zwischen der Anwendung und dem Kernelbereich bilden und die Latenzzeit durch die Beseitigung zusätzlicher Systemaufrufe für E/A-Operationen der Anwendung verringern.
4. Thread-Trennung: Die für die Netzwerk-E/A zuständigen Threads sind von den Threads getrennt, die die Round-Trip-Latenzen berechnen und Histogrammdaten erzeugen. Durch dieses Modell der Einzelverantwortung wird verhindert, dass die durch die Geschäftslogik verursachte Latenz die Übertragung der Auftragsnachrichten beeinträchtigt.
5. Verringerung des Drucks durch die Garbage Collection (GC): Es kommen verschiedene Techniken zum Einsatz, darunter das Aufwärmen von Prozessen der virtuellen Java-Maschine (JVM), um eine wiederholte Interpretation zu verhindern und nativen Code für die Verwendung aus dem Cache zu kompilieren, regelmäßige Neustarts von Prozessen und spezifische JVM-Parameter zur Verringerung des GC-Drucks.
Wir haben den HFT-Client in diesem GitHub-Repository zur Verfügung gestellt, wo Sie den Code einsehen und mehr darüber erfahren können, wie diese Optimierungen implementiert werden.
Um eine einfache Ausgangsbasis beizubehalten, wurden viele zusätzliche Stack-Optimierungen, die typischerweise für spezifische HFT-Workload-Typen implementiert werden, bei diesem Test nicht angewendet. Nicht angewendete Workload-Typen waren IRQ-Handling, CPU P-State- und C-State-Steuerungen, Netzwerkpuffer, Kernel-Bypass, Receive-Side-Scaling, Transmit-Packet-Steering, Linux-Scheduler-Policies und das Tuning von AWS Elastic Network Adaptern.
Die Tests wurden über einen kontinuierlichen Zeitraum von 24 Stunden gleichzeitig für alle Testnetztopologien durchgeführt. Aus Gründen der Übersichtlichkeit und des größtmöglichen Nutzens enthalten die Roundtrip-Zeiten keine Latenzzeiten, die durch die Geschäftslogik der HFT-Clients hinzugefügt werden, und sind daher eine klare Darstellung der Kosten für die Netzwerkleistung für jede Topologie. In der folgenden Tabelle (Abbildung 6) sind die aggregierten Ergebnisse dargestellt.
Die erhaltenen Ergebnisse zeigen, dass die Verwendung von Amazon VPC Peering und gemeinsam genutzten Amazon EC2 Clusterplatzierungsgruppen für hohe Nachrichtenraten bei P99 98% schneller ist als der Zugang über das Internet mit Amazon CloudFront und 41% schneller als der Zugang über Amazon VPC Peering ohne die Verwendung von gemeinsam genutzten CPGs.
In diesem Blog haben wir besprochen, wie wir mit AWS während der Vorstartaktivitäten für unser neues F.A.S.T. Exchange-Produkt zusammengearbeitet haben. Wir haben demonstriert, dass unser HFT-Client und der One Trading-Austausch, der auf Amazon EC2 c6id.metal-Instanzen bereitgestellt wurde, in der Lage sind, eine große Anzahl von Orders pro Sekunde mit minimaler Anwendungsstreitigkeit zu verarbeiten. Latenz wurde als Ergebnis der verschiedenen eingesetzten Testnetzwerktopologien eingeführt.
Wir haben gezeigt, wie die Implementierung einer Architektur, die Amazon VPC Peering und gemeinsam genutzte Amazon EC2 Clusterplatzierungsgruppen umfasst, das Muster mit der niedrigsten Latenzverbindung bietet.
Während alle getesteten Topologien funktional gültig sind und von One Trading verschiedenen Kategorien von Marktteilnehmern zur Verfügung gestellt werden können, bietet Amazon VPC Peering und gemeinsam genutzte CPGs eine materiell vorteilhafte Zugangsebene für ihre größten Market-Making-Kunden.
Wenn Sie mehr über das neue F.A.S.T. Exchange-Produkt von One Trading erfahren möchten, kontaktieren Sie bitte One Trading. Wenn Sie ähnliche Leistungstests durchführen möchten, indem Sie den für diesen HFT-Client erstellten Code verwenden oder modifizieren, kontaktieren Sie bitte einen AWS-Vertreter.
Dr. Stefan Schwarzholz
Ein erfahrener Algorithmusentwickler und Mathematik-Doktor, der für das kontinuierliche Übertreffen führender Anwendungen durch maßgeschneiderte Lösungen bekannt ist. Als unternehmerisch denkender Technologieenthusiast blüht er bei Innovationen, Problemlösungen und beim Beschreiten neuer Wege in der sich ständig weiterentwickelnden Welt der Technologie auf.
Atiek Arian
Atiek ist Senior Manager für Solutions Architecture im Bereich Global Financial Services bei AWS. Er verfügt über mehr als 20 Jahre Erfahrung in der Architektur und Verwaltung von Netzwerk-, Compute- und Speicherlösungen in der Finanzdienstleistungsbranche.
Boris Litwin
Boris ist Principal Solution Architect bei AWS. Seine Aufgabe ist die Innovation im Bereich der Finanzdienstleistungen. Boris kam zu AWS aus der Industrie, zuletzt von Goldman Sachs, wo er eine Vielzahl von quantitativen Rollen in den Bereichen Aktien, FX, Zinssätze innehatte und CEO und Gründer eines quantitativen Trading FinTech-Startups war.
Hani Masri
Hani Masri ist Senior Solutions Architect im Bereich Global Financial Services bei AWS. Er unterstützt Kunden aus dem Finanzdienstleistungsbereich auf ihrem Weg zur Cloud-Migration und digitalen Transformation. Hani ist leidenschaftlich an Datenanalytik interessiert und arbeitet seit über 10 Jahren in der Branche.
Sercan Karaoglu
Sercan Karaoglu ist Senior Solutions Architect, spezialisiert auf Kapitalmärkte. Er ist ein ehemaliger Daten-Ingenieur und leidenschaftlich an quantitativer Investmentforschung interessiert.
Krypto-Asset-Services werden von One Trading Markets S.r.l. angeboten.
One Trading Markets S.r.l. ist ein italienischer Virtual Asset Services Provider (VASP), der bei Organismo Agenti e Mediatori (OAM) registriert ist. Die Services auf dieser Website richten sich an Kunden in Italien und sind nicht außerhalb Italiens reguliert.
.webp)
.png)
.svg)
.png)
