Algo Trading Sistemlerinde Veri İletişimi: Teknolojiye Genel Bakış

Algoritmik trading'de kâr ve zarar arasındaki fark mikrosaniyelerle ölçülebilir. Veri iletim mimarisi, bir trading sisteminin verimliliğini belirleyen temel faktörlerden biridir. Bu makalede, tüm seviyelerdeki iletişim teknolojilerini ele alacağız: borsayla etkileşimden dahili servisler arası iletişime, depolama ve veri dağıtımına kadar.

Makale, gerçek bir algoritmik trading platformunun mimarisini yansıtacak şekilde "dışarıdan" (borsa protokolleri) "içeriye" (IPC, mesaj aracıları, depolama) doğru katmanlara göre düzenlenmiştir.

1. Borsa Etkileşimi: REST, WebSocket, FIX

1.1 REST API

REST, bir borsa API'siyle etkileşim kurmanın en kolay ve en yaygın yoludur. Her istek ayrı bir HTTP bağlantısıdır: TCP el sıkışması → TLS el sıkışması → istek gönder → yanıt al → bağlantıyı kapat.

REST'in Trading İçin Sorunları:

Her istek, bağlantı kurulum yükü taşır. HTTP keep-alive ile bile "istek-yanıt" modeli, isteklerden daha hızlı veri alamayacağınız anlamına gelir. Bu durum, borsa sunucularına %80'e kadar yük oluşturan (kripto borsa geliştiricilerine göre) sonsuz "yeni veri var mı?" sorgu döngüsü olan polling'e yol açar. Borsalar hız sınırları uygular (genellikle dakikada 10–1200 istek) ve bu durum REST'i yüksek frekanslı stratejiler için uygunsuz kılar.

REST'in uygun olduğu durumlar: geçmiş veri çekme (mumlar, OHLCV), hesap yönetimi (bakiye, pozisyonlar), gerçek zamanlı olmayan işlemler (DCA botları, saatlik yeniden dengeleme).

1.2 WebSocket

WebSocket, verinin iki yönlü aktığı tek bir kalıcı TCP bağlantısı kurar. Upgrade başlığıyla normal bir HTTP isteği olarak başlar, ardından iki yönlü bir çerçeveleme protokolüne geçer (yük metin JSON veya ikili olabilir).

Trading İçin Avantajları:

Temel avantaj, istek başına yük olmamasıdır. Bağlantı kurulduktan sonra veriler sunucu tarafından anında iletilir. WebSocket üzerinden piyasa verisi iletim gecikmesi genellikle borsa ağ geçidinden istemciye 50 ms'den azdır. Tek bir bağlantı üzerinden aynı anda 50'den fazla sembole abone olabilirsiniz.

Kritik bir nokta: WebSocket üzerinden emirler. Pek çok trader, bazı borsaların (Binance, HitBTC, Deribit, Bybit vb.) yalnızca veri almak için değil, WebSocket üzerinden emir göndermeye de izin verdiğini bilmez. Bu, REST'e kıyasla temelden daha hızlıdır çünkü:

• Her emir için TCP/TLS el sıkışması yoktur (bağlantı zaten "ısınmış" durumdadır)
• HTTP yükü yoktur (başlıklar, çerezler vb.)
• Asenkron model: bir emir gönderirsiniz ve iş parçacığını bloke etmeden aynı WebSocket üzerinden onay alırsınız.

Deribit'e göre, WebSocket ve FIX çoğu zaman aynı yürütme hızına sahiptir. REST, bağlantı düzeyinde ön işlem nedeniyle biraz daha yavaştır. WebSocket emirleri, FIX emirleri gibi eşleşme motoru kuyruğuna girer.

Bağlam Karıştırma Sorunu. Emirleri REST üzerinden gönderip yürütme bildirimlerini WebSocket üzerinden alırsanız bir yarış koşulu oluşur: WebSocket bildirimi, REST isteği tamamlanmadan önce gelebilir. Bu durum durum tutarsızlığına yol açar. Çözüm, emirleri aynı WebSocket üzerinden göndererek tamamen asenkron bir modele geçmektir.

1.3 FIX Protokolü (Financial Information eXchange)

FIX, 1992'den beri var olan (Fidelity Investments ve Salomon Brothers tarafından oluşturulan) elektronik trading için endüstri standardıdır. Trading için özel olarak tasarlanmış bir TCP üzerinde ikili protokoldür.

FIX Mimarisi:

• Oturum katmanı — bağlantı, kalp atışları, sıra numaralandırma, boşluk kurtarmayı yönetir. Teslimat ve mesaj sırasını garanti eder.
• Uygulama katmanı — iş mantığı: emir türleri, yürütme raporları, piyasa verisi istekleri.

FIX mesajları, SOH karakteriyle ayrılmış "etiket=değer" çiftlerinden oluşur. Örneğin, 150 $ fiyatla 100 adet AAPL hissesi için bir alım emri şöyle görünür:

8=FIX.4.2|35=D|49=BUYER|56=SELLER|11=ORD1001|38=100|40=2|54=1|55=AAPL|44=150.00

FIX neden WebSocket'ten daha hızlıdır: FIX, HTTP katmanları olmadan yerel bir TCP protokolüdür. AWS, kripto borsaları için tick-to-trade optimizasyon kılavuzunda protokol kaynaklı gecikmeyi en aza indirmek amacıyla REST ve WebSocket yerine açıkça FIX'i önerir. FIX mikrosaniye düzeyinde çalışırken, WebSocket tipik olarak milisaniye düzeyindedir.

FIX'in hakim olduğu yerler: Borsa eşleşme motoruna DMA (Doğrudan Piyasa Erişimi), kurumsal alanlarda algoritmik ve HFT trading, likidite toplama (onlarca bankaya FIX üzerinden bağlanan aracı kurumlar).

FIX Sınırlamaları: Entegrasyon karmaşıklığı, güncelliğini yitirmiş mesaj formatı (metin tabanlı etiket-değerler, ikili formatlardan daha az verimlidir), yüksek giriş engeli. Kripto endüstrisinde FIX yalnızca sınırlı sayıda borsa tarafından desteklenmektedir.

1.4 SBE (Simple Binary Encoding) — Evrimsel FIX

SBE, FIX Trading Community bünyesindeki Yüksek Performans Çalışma Grubu tarafından oluşturulmuş bir ikili serileştirme formatıdır. Misyonu, ultra düşük gecikmeli trading için metin FIX formatının yerini kompakt ikili gösterimle almaktır.

SBE'nin Temel Prensipleri:

• Sıfır kopyalı flyweight deseni — kodlayıcılar ve kod çözücüler bir arabellek üzerinde "şablon" olarak hareket eder. Değerler, ara kopyalar olmadan doğrudan yazılır (birkaç tane gerektiren Protobuf'un aksine).
• Kablo formatı = bellek formatı — kablo üzerindeki veriler bellekteki gibi görünür, dönüşüm yükünü en aza indirir.
• Sabit alanlar önce, değişken alanlar sonra — Protocol Buffers ile karşılaştırıldığında büyük ölçüde daha iyi performans sağlayan bir tasarım kısıtlaması.

SBE + Aeron, yüksek performanslı trading sistemleri için standart kombinasyondur. Aeron, Real Logic tarafından geliştirilen açık kaynaklı bir mesajlaşma sistemidir (eski LMAX Exchange CTO'su Martin Thompson ve eski 29West/Ultra Messaging CTO'su Todd Montgomery tarafından oluşturulmuştur). Tek haneli mikrosaniye gecikmeleriyle UDP ve paylaşılan bellek üzerinde çalışan finansal sistemler için özelleştirilmiş bir taşıma katmanıdır. SBE serileştirmeyi yönetirken Aeron, mikrosaniye gecikmelerle teslimattan sorumludur. Aeron hakkında daha fazla bilgi için bölüm 3.1'e bakın.

1.5 Borsa Protokollerinin Karşılaştırma Tablosu

2. Dahili Mikro Servis İletişimi

Veriler borsadan sisteminize girdikten sonra dahili işlem başlar: ayrıştırma → strateji → karar → emir gönderme. Her adımda servisler arası iletişim gerçekleşir.

2.1 gRPC Çift Yönlü Akış (TCP)

gRPC, serileştirme için Protocol Buffers kullanan HTTP/2 tabanlı bir Google çerçevesidir. Algoritmik trading açısından özellikle önemli olan çift yönlü akıştır — istemci ve sunucunun tek bir bağlantı üzerinden aynı anda mesaj akışı gönderdiği durum.

gRPC'nin trading sistemlerine neden uygun olduğu:

• Protobuf kompakttır (JSON'dan 3–10 kat daha küçük)
• HTTP/2 çoklama — tek TCP bağlantısı üzerinden birden fazla akış
• Derleme zamanında hataları yakalayan .proto şemalarıyla katı tipleme
• Python, Rust, Go, C++, Java vb. için kod üretimi
• Çift yönlü akış, tek bir kanal üzerinden "aşağı piyasa verisi, yukarı emirler" desenini mümkün kılar.

SmartDev'e göre, AI destekli HFT dağıtan finansal kurumların %70'i mikrosaniye yanıt süreleri için gRPC veya ham TCP kullanmaktadır.

Mimari örneği: Market Data Collector (Rust) → gRPC akışı → Strategy Engine (Python/Rust) → gRPC çağrısı → Order Router (Rust) → WebSocket/FIX → Borsa.

2.2 Unix Domain Socket Üzerinden gRPC (UDS)

Servisler aynı makinede çalışıyorsa (co-location için tipik), TCP gereksiz bir yüktür. Unix Domain Socket (UDS), tüm ağ yığınını atlar: TCP el sıkışması yok, yönlendirme yok, sağlama toplamı yok.

Kıyaslamalar önemli bir fark göstermektedir:

• UDS üzerinden gRPC: ~102 μs/istek (100K istek)
• TCP üzerinden gRPC: ~127 μs/istek (100K istek)
• UDS Kazancı: küçük mesajlarda ~%20, büyük mesajlarda (100KB+) %50'ye kadar.

F. Werner'e (MPI Heidelberg) göre, gRPC UDS ile UDS üzerinden ham bloke edici G/Ç karşılaştırıldığında, gRPC yaklaşık 10 kat ek yük ekler — ham UDS için ortalama ~13 μs'ye karşın ~130 μs. Bu, soyutlamanın bedeli (HTTP/2 çerçeveleme, protobuf serileştirme).

gRPC+UDS ne zaman kullanılır: Mutlak minimum gecikme üzerinde geliştirici kolaylığına (şema, kod üretimi) değer verildiğinde tek bir sunucudaki süreçler arası iletişim. UDS ayrıca Unix dosya izinleri aracılığıyla güvenlik avantajları sağlar.

Ne zaman KULLANILMAZ: <10 μs gecikme gerekiyorsa, gRPC olmadan paylaşılan bellek veya ham UDS daha iyidir. Referans olarak: ham UDS ortalaması ~13 μs, gRPC UDS ortalaması ~130 μs. Paylaşılan bellek (Aeron IPC) 1 μs'nin altında, LMAX Disruptor halka tamponu yaklaşık 50–100 ns'dir. Dolayısıyla gRPC+UDS, ham UDS'den ~10 kat ve paylaşılan bellekten 100–1000 kat daha yavaştır. Ancak gecikmede her bir adım aşağı, kod karmaşıklığında bir adım yukarıdır.

Kendiniz deneyin: Bu bölümdeki tüm IPC gecikme rakamları, açık kaynaklı yardımcı kıyaslama aracı suenot/trading-ipc-bench ile yeniden üretilebilir — kendi donanımınızda p50/p95/p99/p99.9 gecikme ve verim ölçen TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, Paylaşılan Bellek ve Named Pipe gidiş-dönüşlerinin Python uygulamaları.

gRPC olmadan ham UDS — gRPC yükü aşırıysa kaldırın ve yalnızca soketi tutun. Azalan performansa göre seçenekler:

• AF_UNIX soketleri + özel serileştirme (SBE, FlatBuffers, MessagePack) — ~13 μs ortalama, maksimum kontrol, maksimum karmaşıklık
• ZeroMQ IPC (ipc://) — ~50–100 μs, şablonsuz hazır desenler (PUB/SUB, REQ/REP), arka planda UDS kullanır
• nanomsg/NNG IPC — ZeroMQ'ya benzer, küçük mesajlarda (<64 KB) biraz daha iyi gecikme
• UDS üzerinden Cap'n Proto RPC — sıfır kopyalı serileştirme + RPC soyutlaması, gRPC'den daha hızlı, şemaya sahip

2.3 Paylaşılan Bellek IPC

Aynı ana bilgisayarda ultra düşük gecikme için paylaşılan bellek kullanın. İki süreç aynı RAM segmentini eşler ve veriler sistem çağrıları olmadan geçer (başlangıç kurulumu dışında).

LMAX Disruptor deseni (paylaşılan bellekte halka tamponu) tek bir iş parçacığında saniyede ~6 milyon olayı işler. Bu yaklaşım, LMAX Exchange ve birçok HFT sisteminin kalbidir.

Uygulamalar: Aeron IPC (Java/C++), Chronicle Queue (Java), özel mmap tabanlı çözümler (Rust/C++). IronSBE (Rust SBE uygulaması), SPSC kanal düzeyinde ~20 ns gecikmeyle paylaşılan bellek IPC'yi destekler.

3. Taşıma Sistemleri: Mesaj Aracıları ve Kütüphaneler

3.1 Aeron — Altın Standart

Aeron, Real Logic tarafından geliştirilen açık kaynaklı yüksek performanslı bir mesaj taşıma sistemidir. Yaratıcıları Martin Thompson (eski LMAX CTO) ve Todd Montgomery'dir (eski 29West CTO). 2014 yılında büyük bir ABD borsası için başladı ve şu anda 70'ten fazla katkıda bulunanı ve 5000'den fazla GitHub abonesi var.

Pratikte: Aeron ne bir aracı (Kafka gibi) ne de bir soket kütüphanesidir (ZeroMQ gibi). Öngörülebilir düşük gecikme için tasarlanmış bir taşıma katmanıdır. UDP (ağ) ve paylaşılan bellek (IPC) üzerinde çalışır; ham UDP'nin sahip olmadığı şeyler olan güvenilir teslimat, sıralama ve akış kontrolü sağlar. Aeron'u "UDP gecikmesiyle TCP" olarak düşünün.

Aeron Özellikleri:

• Gecikme: bulutta <100 μs, bare metal üzerinde <18 μs.
• Verim: mikrosaniye gecikmede >1M mesaj/s.
• Tepe noktasında 20M+ mesaj/s.
• Aracısız — tek hata noktası yok.
• Unicast, multicast ve IPC'yi destekler.
• Yerleşik akış kontrolü ve kayıp tespiti.

Aeron Cluster — tutarlı trading mantığı için minimum ek gecikmeyle hataya dayanıklı durum makinesi replikasyonu (Raft konsensüsü).

Aeron Archive — tam akış hızında mesaj kalıcılığı ve oynatma yeteneği.

Aeron Sequencer — ekosistemi için en yeni bileşen; büyük kuruluşlarda birden fazla projeyi koordine etmek için tasarlanmıştır. Aeron Transport ve Aeron Cluster üzerine inşa edilmiştir. Temel özellikler:

• Dağıtılmış günlük — hataya dayanıklılık için birden fazla makineye replike edilen uzun bir mesaj dizisi
• Birden fazla okuyucu — birden fazla uygulama farklı amaçlar için aynı günlüğü aynı anda okur
• Bağımsız ekipler — ekipler tek bir koordineli sistem içinde çalışırken bağımsız kalır
• Hedef kullanım alanları: piyasa verisi işleme, aracı platformlar, borsa motorları

Kafka ile karşılaştırma: Her ikisi de dağıtılmış günlük kullanır ancak Aeron mikrosaniye gecikme içindir, Kafka ise milisaniye dayanıklılık ve verim içindir. Aeron gerçek zamanlı mantık için varken Kafka, veri boru hatları ve analitik içindir.

3.2 Apache Kafka

Apache Kafka, ölçekte olay akışı için fiili standarttır. Trading hızlı yolu için değildir (milisaniye gecikmeleri) ancak şunlar için vazgeçilmezdir:

• Piyasa verisi toplama: 100'den fazla borsadan gelen akışları tek bir boru hattında toplama.
• Olay kaynağı: Her sistem eylemini bir olay konusu olarak kaydetme.
• CDC (Değişiklik Verisi Yakalama): Trading veritabanı değişikliklerini analitiğe aktarma.
• QuestDB Entegrasyonu: Gerçek zamanlı tick analitiği için Kafka → QuestDB.

Gecikme uçtan uca 2–15 ms'dir. HFT için kabul edilemez, ancak >1s ufku olan stratejiler için uygundur.

3.3 Redis Pub/Sub ve Streams

Redis, aynı zamanda hafif bir aracı olarak da çalışan bellek içi bir depodur.

Redis Pub/Sub — gönder-unut; milisaniyenin altında gecikme. Gerçek zamanlı bildirimler için idealdir: fiyat güncellemeleri, strateji sinyalleri, uyarılar.

Redis Streams — kalıcılık ve tüketici grupları ekler (mini-Kafka). Geçmiş okuma ve ACK'ları destekler.

Redis, küçük mesajlar için Kafka'dan daha hızlıdır (ms altı), ancak Kafka'nın ağır replikasyon ve dayanıklılığından yoksundur.

3.4 NATS

NATS, Go ile yazılmış ultra hafif bir sistemdir. Ms altı gecikme, yerleşik pub/sub, istek/yanıt. NATS JetStream kalıcılık ve tam bir kez teslimat ekler.

3.5 ZeroMQ ve nanomsg

Eşten eşe iletişim için soket soyutlamaları sağlayan aracısız kütüphaneler. ZeroMQ, 5M+ mesaj/s işler ve 2007'den beri savaşta test edilmiştir. nanomsg (ve NNG), küçük mesajlarda (<64KB) daha iyi gecikmeyle "halefi"dir.

4. İstemciler İçin Gerçek Zamanlı PUB/SUB: Centrifugo

Centrifugo, WebSocket, SSE veya gRPC aracılığıyla binlerce/milyonlarca istemciye yayın yapmak için optimize edilmiş Go ile yazılmış kendi kendine barındırılan bir PUB/SUB sunucusudur.

Algo Trading İçin Centrifugo Neden Kullanılır:

• Bir sunucuda 1M WebSocket bağlantısı ve dakikada 30M mesajı işler.
• 60Hz akışı destekler.
• Trafiği en aza indirmek için delta sıkıştırma (Fossil algoritması).
• Web kontrol panelleri veya mobil uygulamalara "son mil" için mükemmeldir.

5. Gerçek Zamanlı Erişim Veri Depoları

5.1 QuestDB — Trading İçin Zaman Serisi

QuestDB, Java (sıfır GC), C++ ve Rust ile yazılmış açık kaynaklı bir zaman serisi veritabanıdır.

• Sorgular: SIMD aracılığıyla ms altı vektörleştirilmiş yürütme.
• SAMPLE BY/ASOF JOIN: Trader dostu yerel SQL uzantıları.
• WAL: Ultra düşük gecikmeli ekleme.
• B3 (Brezilya borsası) tarafından kullanılmaktadır.

5.2 Veri Katmanı Olarak Redis

Genellikle ara bir katman:

• O(1) fiyat erişimi için Sıcak önbellek.
• Emir defterleri için Sıralı kümeler.
• Atomik işlemler için Lua betikleri.

5.3 Özel Çözümler: RayforceDB, AXL DB

Sıfır bağımlılık ve SIMD hızlandırmasıyla minimalist C tabanlı vektör veritabanları (ikili <1MB). HFT için deterministik gecikmeye odaklanır.

6. Serileştirme: Protobuf vs SBE vs JSON

7. Referans Mimariler

7.1 Kripto Arbitraj (Orta Frekans)

Borsalar → Toplayıcı (Rust) → Redis (Sıcak) → Strateji (Python) → gRPC → Yönlendirici (Rust) → Borsa.

7.2 HFT Piyasa Yapıcılığı (Co-location)

Borsa Feed'i → Kernel Bypass NIC → Aeron IPC → Strateji (C++) → SBE → Aeron → Borsa.

8. Pratik Tavsiyeler

• <10 μs (HFT): FPGA, paylaşılan bellek, SBE, Aeron IPC.
• 10–100 μs: Aeron (UDP), gRPC+UDS, ZeroMQ.
• 100 μs – 1 ms: gRPC (TCP), WebSocket, Protobuf.
• 1–10 ms (Orta Frekans): WebSocket, Kafka, Redis.
• >10 ms (Düşük Frekans / Swing): REST API yeterlidir. DCA, yeniden dengeleme, portföy yönetimi.

Darboğaz olmayan şeyi optimize etmeyin. Stratejiniz karar almak için 50 ms alıyorsa, Aeron'un 100 μs tasarrufu önemli olmaz. Hibrit mimariler normaldir: kurulum için REST, kalp için gRPC ve teslimat için WS kullanın.

Kıyaslama Deposu

Bu makalede alıntılanan gecikme rakamları, burada ele alınan tüm önemli IPC taşıma yöntemlerini kapsayan açık kaynaklı bir Python kıyaslama paketi olan suenot/trading-ipc-bench ile yeniden üretilebilir: TCP, UDS, Named Pipe, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub ve Paylaşılan Bellek.

git clone https://github.com/suenot/trading-ipc-bench
cd trading-ipc-bench
pip install -r requirements.txt
python run_all.py   # 8 taşıma yönteminin tamamını çalıştırır, sonuçları results/ dizinine kaydeder
python report.py    # özet tablo + ASCII gecikme grafiği yazdırır

Kendi donanımınızda çalıştırın — sonuçlar CPU'nuz, işletim sisteminiz, çekirdek sürümünüz ve ayarlamalarınıza bağlı olarak bu makaledeki rakamlardan farklı olacaktır. İşte bu, asıl amacıdır.

Sonuç

"Mükemmel" bir iletişim teknolojisi yoktur. Her seviyenin kendine özgü gereksinimleri vardır: dışsal (uyumluluk), dahili (gecikme), boru hattı (güvenilirlik) ve istemci (esneklik). Mimari, belirli iş için doğru aracı seçmekle ilgilidir.