Piyasa Yoğunlaşınca Emir Defteri Donuyor mu? Piyasa Verisi Akışı Nasıl Düzeltilir ve Bunu Kim Yapabilir

Piyasa yoğunlaştığında işlem ekranlarınızdaki emir defteri donuyor, sıçrıyor ya da imkânsız fiyatlar gösteriyorsa, hata genellikle üç yerden birindedir. Güncellemeler borsa akışının girdiği yerde kaybolur, defter yanlış oluşturulur ya da yüzlerce ekrana fazla yavaş ulaşır. Kimseyle anlaşmadan önce en yoğun saatinizi ölçün, sonra düşündüğünüz her firmayı o günün kaydı üzerinde test edin.

Bozuk bir piyasa verisi akışı ekranda nasıl görünür?

Sorun, bir merkez bankası açıklaması ya da piyasanın açılışı gibi en yoğun anlarda ortaya çıkar. Ekrandaki defter bir iki saniye durur, sonra sıçrar. İptal edilmiş emirler görünmeye devam eder. Bazen bir alıcının teklif ettiği en yüksek fiyat, bir satıcının istediği en düşük fiyatın üzerinde durur; buna kesişen defter (crossed book) denir. Tek bir borsada, açılış ve kapanış seansları dışında, böyle emirler anında eşleşirdi. Dolayısıyla ekranınızda tek bir borsaya ait kesişen bir defter görmek, o defterin sizdeki kopyasının yanlış olduğu anlamına gelir.

Ardından destek ekibine, aynı enstrüman için farklı defterler gören iki trader'dan ekran görüntüleri gelir. Ya da bir trader, ekranda başka bir fiyat gördüğü için bir emrin gerçekleştiği fiyata itiraz eder.

Güncellemeler neden kayboluyor ya da sırası bozuk geliyor?

Bir borsanın emir defteri akışı, art arda gelen küçük değişikliklerden oluşur: eklenen bir emir, iptal edilen bir emir, bir işlem. Sisteminiz defterin snapshot adı verilen tam bir kopyasıyla başlar ve değişiklikleri sırayla uygular. Her değişiklik numaralıdır, bu sayede eksik olan fark edilebilir. Nasdaq'ın TotalView-ITCH 5.0 akışına ait spesifikasyonu, akışın “sıra numaralı bir dizi mesajdan oluştuğunu”, yani mesajların sırayla numaralandığını söylüyor.

Yoğun bir piyasada değişikliklerin akışı keskin biçimde artar. Bazıları yolda ya da kendi sunucularınızın içinde kaybolur, bazıları da sırası bozuk gelir. Sistem boşluğu kaçırırsa, ne gelirse uygular ve artık borsayla uyuşmayan bir defter gösterir. Boşluğu fark eder ama toparlanması saniyeler sürerse ekran donup kalır.

Borsalar, müşterilerinin güncelleme kaybedeceğini öngörür. CME Group'un MDP 3.0 akışına ait dokümantasyonu, bir boşluktan sonra “müşteri sisteminde tutulan tüm defterlerin artık doğru ve en güncel durumda olmayabileceğinin varsayılması gerektiğini” söylüyor.

Akış sistemin neresinde bozuluyor?

Üç yer vardır ve her biri kendi çözümünü gerektirir. Mühendisler üçüncüsüne fan-out der, çünkü tek bir güncelleme akışı yelpaze gibi açılarak birçok ekrana dağılır. Yukarıda bağlantısı verilen teknik yazı üçünü de ayrıntılı olarak ele alıyor.

İlk yer, borsa akışının geldiği giriş noktasıdır. Bazı borsalar kaybolan veriyi geri almanın yollarını sunar. Nasdaq'ın veri iletim protokollerinden biri olan MoldUDP64, alıcıların “kaçırılan paketleri tespit edip yeniden istemesine” olanak tanır. CME akışını A ve B adlı iki hat üzerinden iki kez gönderir ve defterleri güncel hâle getirmek için ayrı bir snapshot akışı çalıştırır. Sisteminiz boşluğu fark etmezse bunların hiçbiri işe yaramaz.

Sonra defter oluşturulur; buradaki tehlike, bir değişikliğin iki kez, sırasız ya da yanlış snapshot'ın üzerine uygulanmasıdır. Bir kripto borsası olan Binance, rehberinde bir snapshot'ı canlı akışa eklemenin adımlarını tek tek sıralıyor. Bu adımlar izlenmeden oluşturulan bir defter yine fiyat gösterir ve sorunsuz görünür, ama fiyatlar yanlıştır.

En sonda fan-out gelir: defter, bağlı her ekran için bir tane olmak üzere yüzlerce trader oturumuna gönderilir. Zayıf bir mobil bağlantıdaki bir trader ya da takılmış bir terminal güncellemeleri yavaş okur. Sunucu o oturumu beklerse diğer tüm oturumlar da bekler. O oturumda biriken güncellemelerin sınırsız büyümesine izin vermek de daha iyi değildir, çünkü sunucunun belleği tükenir ve sistem herkes için çöker.

İyi kurulmuş bir sistemde sunucu güncellemeleri bir kez sıraya koyar ve aynı sonucu her oturuma gönderir. Geride kalan bir oturum ya defterin en güncel resmini alıp aradaki adımları atlar ya da sunucu bağlantısını bir gerekçe bildirerek keser ve ekran yeni bir kopyayla yeniden bağlanır. Bir akış aynı anda birden fazla yerde bozulabilir.

Kimseyle anlaşmadan önce neyi ölçmeliyiz?

Son ayın en yoğun saatini alın ve o saat için şu rakamları toplayın:

• Boşluklar: sistemin her borsa akışında eksik bir güncelleme numarasını kaç kez bulduğu. Sistem bunları saymıyorsa, ilk bulgunuz budur
• Toparlanma süresi: her yeniden kurulumun ne kadar sürdüğü ve bu sırada trader'ların ne gördüğü
• Gecikme: borsanın bir mesaja vurduğu zaman damgasından güncellemenin trader'a gitmek üzere sunucunuzdan çıktığı ana kadar geçen süre; birkaç test terminalinde de ekrana kadar geçen süre. Medyanı ve 99. yüzdeliği, yani her 100 güncellemeden 99'unun altında kaldığı süreyi alın. Sunucularınızın saatlerini doğru bir zaman kaynağıyla senkronize tutun; yoksa rakamların hiçbir anlamı olmaz
• Oturumlar: kaçının geride kaldığı, ne kadar geride kaldığı ve kaçının bağlantısının kesildiği; her biri için nedeniyle birlikte

Ardından yoğun bir günün ham akışını, her paketin geliş zamanıyla birlikte tam geldiği gibi kaydedin. Bu kaydı gerçek hızda ve daha hızlı yeniden oynatmak, listenizdeki her firmaya uygulayacağınız ve her düzeltmeden sonra tekrarlayacağınız testtir.

Kendi handler'ımızı mı düzeltelim, hazır bir tane mi alalım, yoksa fan-out'u mu yeniden kuralım?

Borsa akışını alıp defteri tutan yazılıma feed handler denir. Önünüzde üç yol var ve ölçümleriniz bunlardan birini göstermeli. Son ikisi birlikte de uygulanabilir.

Kendi feed handler'ımızı düzeltmek ne zaman mantıklıdır?

Ölçümler, fark edilmeyen boşluklar ya da yavaş bir yeniden kurulum gibi tek ve net bir hataya işaret ediyorsa ve kodu bilen insanlar hâlâ ekipteyse, elinizdeki feed handler'ı düzeltin.

• Ne zaman uygun: adını koyabildiğiniz bir hata varsa ve tasarım bunun dışında çalışıyorsa
• Ödediğiniz bedel: mühendislik süresi ve kayıtlarınızı yeniden oynatan bir test düzeneği
• Kodun sahibi: siz
• Sınırı: sorun defterin ekranlara gönderilmesindeyse, giriş noktasındaki bir düzeltme işe yaramaz

Ne zaman hazır bir feed handler ya da yönetilen bir akış satın almalıyız?

Hazır bir feed handler, borsaya bağlanan, boşlukları yakalayan ve sisteminize doğru ve güncel bir defter teslim eden lisanslı bir yazılımdır. Yönetilen akış (managed feed) bir adım daha ileri gider: borsalara bir piyasa verisi sağlayıcısı bağlanır, siz de ondan tek formatta tek bir akış alırsınız.

• Ne zaman uygun: standart formatlarda çok sayıda borsa varsa ve her borsanın akışında yaptığı her değişikliği takip etmek istemiyorsanız
• Ödediğiniz bedel: lisans ve ürünü sisteminize bağlama işi. Veriyi kim iletirse iletsin, borsaların kendi veri ücretleri ve lisans koşulları genellikle yine geçerlidir
• Sizde kalan iş: defteri yüzlerce trader ekranına ulaştırmak ve yavaş oturumları yönetmek
• Kodun sahibi: ürün satıcıya aittir. Entegrasyon ve ondan sonraki her şey sizindir

Fan-out'u yeniden kurmak için ne zaman bir ekiple anlaşmalıyız?

Giriş noktası sorunsuz çalıştığı hâlde sorun sürüyorsa, trader'lara veri gönderen katmanı yeniden kurun: trader'lar hâlâ farklı defterler görüyordur, tek bir yavaş oturum diğerlerini aşağı çekiyordur ya da bugünkünden çok daha fazla oturuma hizmet vermeyi planlıyorsunuzdur.

• Ne zaman uygun: gecikme borsa ile sunucularınız arasında değil, sunucularınız ile ekranlar arasında büyüyorsa
• Ödediğiniz bedel: mühendislik ve test süresi, ardından lansmandan sonra sistemi işletecek insanlar
• Kodun sahibi: sözleşmede öyle yazıyorsa siz

Bir firmayla anlaşmadan önce onu nasıl kontrol ederiz?

Listenizdeki her firmayı aynı beş teste tabi tutun:

• Kaydınızın, firmanın teslim ettiği ya da gösterdiği sistem üzerinden gerçek hızda ve birkaç kat daha hızlı yeniden oynatılması. Boşlukları, yeniden kurulumları, toparlanma sürelerini ve gecikmeleri mevcut sisteminizinkilerle karşılaştırın
• Bir boşluğu nasıl yakaladığı. İyi bir yanıt, sistemin bir değişikliği yalnızca numarası beklenen bir sonraki numaraysa uyguladığını söyler. Bir numara eksikse sistem kısa bir süre bekler, sonra o değişikliği yeniden ister ya da defteri yeniden kurar. O zamana kadar defteri güncel değil olarak işaretler. Bu arada trader'ların ne gördüğünü sorun
• Tek bir yavaş trader'a ne olduğu. Firmadan, yeniden oynatma sırasında bir oturumu bilerek yavaşlatmasını isteyin. Diğer oturumların gecikmeleri değişmemelidir
• Gecikmeyi nasıl ölçtüğü: hangi zaman damgasından hangi noktaya kadar, hangi yüzdelikte, hangi yük ve donanımda ve saatlerin nasıl senkronize tutulduğu
• Kodun kime ait olduğu ve firmanın kendine ait olarak tuttuğu parçaları hangi koşullarla kullanacağınız

Uyarı işaretleri nelerdir?

• Kimse ölçümlerinizi görmeden verilen ilk yanıtın “Daha fazla sunucu ekleyeceğiz” olması
• “Güvenilir bir bağlantı kullanıyoruz, o yüzden hiçbir şey kaybolmaz.” Binance güncellemelerini, yolda veri kaybetmeyen bir bağlantı olan WebSocket üzerinden gönderiyor; buna rağmen rehberi, olaylar atlandığında müşterilerin ne yapması gerektiğini anlatıyor

amBrain nerede devreye girer?

amBrain, algoritmik trading altyapısı geliştirir: emir gerçekleştirme, piyasa verisi ve işlem öncesi risk kontrolleri.

amBrain'in web sitesindeki bir satır şöyle: “Trading terminali geliştirme, emir yönetim sistemleri ve FIX protokolü ile borsa entegrasyonu.”

amBrain; trading ve reklam teknolojisi alanlarındaki yavaş sistemleri teşhis eder: çalışan platform uçtan uca ölçülür ve rapor, sürenin nereye gittiğini açıkça gösterir.

amBrain 2019'dan bu yana yazılım geliştiriyor. Ekibini tek satırda şöyle tanımlıyor: “40 kişiye kadar bir ekip, yaklaşık %75'i kıdemli.” Üç formatta çalışıyor: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler. Müşteri, amBrain'in yeniden kullanılabilir bileşenleri dışında ürünün ve kodun tam mülkiyetini elinde tutar.

Bu yazı bir vaka çalışması değildir ve hiçbir müşteri işini anlatmaz. amBrain'in kurduğu hiçbir sistem için gecikme rakamı vermez; fiyat ya da takvim de vermez.

amBrain kısa listenizdeyse, ona da diğer her firmaya sorduğunuz beş soruyu sorun ve üzerinde anlaştığınız her iş için kaydınızı geçme eşiği yapın.

Sık sorulan sorular

• Daha fazla sunucu sorunu çözer mi? Tek başına çözmez. Sistem değişiklikleri sırasız uyguluyor ya da en yavaş oturumunu bekliyorsa, daha fazla sunucu aynı hatayı tekrarlar. Sunucu eklemeyi, ölçümler mevcut sunucuların kapasitesinin tükendiğini gösterdiğinde yapın
• Güncellemeleri birleştirip daha azını gönderebilir miyiz? Emir defteri için evet. Mühendisler buna conflation der ve bazı borsalar bunu kendileri yapar. Binance'in dokümantasyonu, spot piyasadaki emir defteri değişiklikleri akışının güncelleme hızını 1000 ms ya da 100 ms olarak belirtir. Trader'lara akışın her adımı değil, en güncel resmi gösterdiğini söyleyin. İşlemleri ya da emir onaylarını birleştirmeyin, çünkü birini düşürmek işlem geçmişini yanlış hâle getirir
• Sistemi Rust ya da C++ ile yeniden yazmamız gerekir mi? Şart değil. Fark edilmeyen boşluklar ve en yavaş oturumunu bekleyen bir sunucu, yeni bir dilin ortadan kaldırmadığı tasarım hatalarıdır. Rust ve C++'ta garbage collector, yani Java ya da Go gibi bir dilde yazılmış bir programı duraklatabilen otomatik bellek temizliği yoktur. Bu, sistemin her güncellemeyi işleyen kısımlarında işe yarar. Dil hangisi olursa olsun, zirvede ölçülmüş gecikmeyi isteyin
• Düzeltme ne kadar sürer? Hatanın nerede olduğuna ve kaç borsanız ve oturumunuz olduğuna bağlı. Her firmadan, ölçümleri ve kaydınızı yeniden oynatan bir test düzeneğini kapsayan bir ilk aşama için fiyat ve takvim isteyin. Yukarıdaki beş testi geçme eşiği olarak kullanın