Moskova Borsası ticaret ve takas sisteminin mimarisinin evrimi. Bölüm 1

Herkese selam! Adım Sergey Kostanbaev, Borsada ticaret sisteminin çekirdeğini geliştiriyorum.

Hollywood filmleri New York Menkul Kıymetler Borsası'nı gösterdiğinde her zaman şöyle görünür: insan kalabalığı, herkes bir şeyler bağırıyor, kağıtlar sallıyor, tam bir kaos yaşanıyor. Bu, Moskova Borsası'nda hiçbir zaman gerçekleşmedi, çünkü ticaret en başından beri elektronik olarak yürütülüyor ve iki ana platforma dayanıyor: Spectra (forex piyasası) ve ASTS (döviz, hisse senedi ve para piyasası). Ve bugün ASTS ticaret ve takas sisteminin mimarisinin evrimi, çeşitli çözümler ve bulgular hakkında konuşmak istiyorum. Hikaye uzun olacağı için ikiye bölmek zorunda kaldım.

Dünyadaki her sınıftan varlığın alım satımını yapan ve çok çeşitli takas hizmetleri sunan birkaç borsadan biriyiz. Örneğin geçen yıl tahvil işlem hacminde dünyada ikinci, tüm borsalar arasında 25'inci, halka açık borsalar arasında kapitalizasyonda 13'üncü sırada yer aldık.

Profesyonel ticaret katılımcıları için yanıt süresi, zaman dağılımının istikrarı (jitter) ve tüm kompleksin güvenilirliği gibi parametreler kritik öneme sahiptir. Şu anda günde on milyonlarca işlem gerçekleştiriyoruz. Her bir işlemin sistem çekirdeği tarafından işlenmesi onlarca mikrosaniye sürer. Tabii ki, Yılbaşı Gecesi'ndeki mobil operatörlerin veya arama motorlarının iş yükü bizimkinden daha fazla, ancak iş yükü açısından, yukarıda belirtilen özelliklerle birleştiğinde, bana öyle geliyor ki, çok az kişi bizimle kıyaslanabilir. Aynı zamanda sistemin bir an bile yavaşlamaması, kesinlikle stabil çalışması ve tüm kullanıcıların eşit düzeyde olması bizim için önemli.

Biraz tarih

1994 yılında, Avustralya ASTS sistemi Moskova Bankalararası Döviz Borsası'nda (MICEX) başlatıldı ve o andan itibaren Rusya'nın elektronik ticaret tarihi sayılabilir. 1998 yılında borsa mimarisi, İnternet ticaretini başlatacak şekilde modernize edildi. O tarihten bu yana, yeni çözümlerin ve mimari değişikliklerin tüm sistem ve alt sistemlerde uygulanma hızı giderek artıyor.

O yıllarda değişim sistemi, son derece güvenilir HP Superdome 9000 sunucuları (temel olarak yerleşik) yüksek teknoloji donanımlar üzerinde çalışıyordu. PA-RISC), kesinlikle her şeyin kopyalandığı: giriş/çıkış alt sistemleri, ağ, RAM (aslında bir RAID RAM dizisi vardı), işlemciler (çalışırken değiştirilebilir). Makineyi durdurmadan herhangi bir sunucu bileşenini değiştirmek mümkündü. Bu cihazlara güvendik ve bunların neredeyse arıza korumalı olduğunu düşündük. İşletim sistemi Unix benzeri bir HP UX sistemiydi.

Ancak yaklaşık 2010'dan bu yana, yüksek frekanslı ticaret (HFT) veya yüksek frekanslı ticaret - basitçe söylemek gerekirse borsa robotları - adı verilen bir olgu ortaya çıktı. Sadece 2,5 yılda sunucularımızdaki yük 140 kat arttı.

Eski mimari ve ekipmanlarla bu kadar yüke dayanmak mümkün değildi. Bir şekilde uyum sağlamak gerekiyordu.

başlangıç

Değişim sistemine yapılan talepler iki türe ayrılabilir:

• İşlemler. Dolar, hisse senedi veya başka bir şey satın almak istiyorsanız işlem sistemine bir işlem gönderirsiniz ve başarılı olduğuna dair bir yanıt alırsınız.
• Bilgi talepleri. Güncel fiyatı öğrenmek istiyorsanız emir defterini veya endeksleri görüntüleyebilir, ardından bilgi talebi gönderebilirsiniz.

Şematik olarak sistemin çekirdeği üç seviyeye ayrılabilir:

• Aracıların ve müşterilerin çalıştığı müşteri düzeyi. Hepsi erişim sunucularıyla etkileşime girer.
• Ağ geçidi sunucuları, tüm bilgi isteklerini yerel olarak işleyen önbellek sunucularıdır. Sberbank hisselerinin şu anda hangi fiyattan işlem gördüğünü bilmek ister misiniz? İstek erişim sunucusuna gider.
• Ancak hisse satın almak istiyorsanız talep merkezi sunucuya (Trade Engine) gider. Her pazar türü için böyle bir sunucu vardır, hayati bir rol oynarlar, bu sistemi onlar için yarattık.

Ticaret sisteminin temeli, tüm işlemlerin takas işlemleri olduğu akıllı bir bellek içi veritabanıdır. Taban C dilinde yazılmıştı, tek harici bağımlılıklar libc kütüphanesiydi ve hiçbir dinamik bellek tahsisi yoktu. İşlem süresini azaltmak için sistem, statik bir dizi diziyle ve statik veri yeniden konumlandırmasıyla başlar: ilk olarak, geçerli güne ait tüm veriler belleğe yüklenir ve başka disk erişimi gerçekleştirilmez, tüm çalışmalar yalnızca bellekte gerçekleştirilir. Sistem başlatıldığında tüm referans verileri zaten sıralanmıştır, dolayısıyla arama çok verimli çalışır ve çalışma süresinde çok az zaman alır. Tüm tablolar, dinamik veri yapıları için müdahaleci listeler ve ağaçlarla yapılmıştır, böylece çalışma zamanında bellek tahsisi gerektirmezler.

Ticaret ve takas sistemimizin gelişim tarihine kısaca göz atalım.
Ticaret ve takas sistemi mimarisinin ilk versiyonu Unix etkileşimi üzerine inşa edildi: paylaşılan hafıza, semaforlar ve kuyruklar kullanıldı ve her süreç tek bir iş parçacığından oluşuyordu. Bu yaklaşım 1990'ların başında yaygınlaştı.

Sistemin ilk versiyonu iki düzeyde Ağ Geçidi ve ticaret sisteminin merkezi bir sunucusunu içeriyordu. İş akışı şu şekildeydi:

• İstemci, Ağ Geçidine ulaşan bir istek gönderir. Formatın geçerliliğini kontrol eder (ancak verinin kendisini değil) ve hatalı işlemleri reddeder.
• Bir bilgi talebi gönderildiyse yerel olarak gerçekleştirilir; eğer bir işlemden bahsediyorsak, o zaman merkezi sunucuya yönlendirilir.
• Ticaret motoru daha sonra işlemi işler, yerel belleği değiştirir ve ayrı bir çoğaltma motoru kullanarak çoğaltma için işleme ve işlemin kendisine bir yanıt gönderir.
• Ağ Geçidi, merkezi düğümden yanıtı alır ve istemciye iletir.
• Bir süre sonra Ağ Geçidi, işlemi kopyalama mekanizması aracılığıyla alır ve bu sefer yerel olarak yürütür, veri yapılarını değiştirerek sonraki bilgi isteklerinin en son verileri göstermesini sağlar.

Aslında Gateway'in ticaret sisteminde gerçekleştirilen eylemleri tamamen kopyaladığı bir çoğaltma modelini tanımlamaktadır. Ayrı bir çoğaltma kanalı, işlemlerin birden fazla erişim düğümünde aynı sırada yürütülmesini sağladı.

Kod tek iş parçacıklı olduğundan, birçok müşteriye hizmet vermek için işlem çatallarına sahip klasik bir şema kullanıldı. Ancak tüm veritabanını çatallamak çok pahalıydı, bu nedenle TCP oturumlarından paketleri toplayan ve bunları tek bir kuyruğa (SystemV Mesaj Kuyruğu) aktaran hafif hizmet süreçleri kullanıldı. Gateway ve Trade Engine yalnızca bu kuyrukla çalıştı ve işlemleri oradan yürütmek üzere aldı. Artık buna yanıt göndermek mümkün değildi çünkü hangi hizmet sürecinin bunu okuması gerektiği belli değildi. Bu yüzden bir numaraya başvurduk: çatallanmış her süreç kendisi için bir yanıt kuyruğu oluşturdu ve gelen kuyruğa bir istek geldiğinde, yanıt kuyruğu için bir etiket hemen ona eklendi.

Büyük miktarlarda verinin sürekli olarak kuyruktan kuyruğa kopyalanması, özellikle bilgi istekleri için tipik olan sorunlar yarattı. Bu nedenle başka bir numara kullandık: yanıt kuyruğuna ek olarak, her işlem aynı zamanda paylaşılan bellek (SystemV Shared Memory) oluşturdu. Paketlerin kendisi içine yerleştirildi ve kuyrukta yalnızca bir etiket saklandı, bu da kişinin orijinal paketi bulmasına izin verdi. Bu, verilerin işlemci önbelleğinde saklanmasına yardımcı oldu.

SystemV IPC, kuyruk, bellek ve semafor nesnelerinin durumunu görüntülemek için yardımcı programlar içerir. Belirli bir anda sistemde neler olduğunu, paketlerin nerede biriktiğini, nelerin engellendiğini vb. anlamak için bunu aktif olarak kullandık.

İlk yükseltmeler

Öncelikle tek işlemli Gateway’den kurtulduk. Önemli dezavantajı, bir çoğaltma işlemini veya bir istemciden gelen bir bilgi talebini işleyebilmesiydi. Yük arttıkça Gateway'in istekleri işlemesi daha uzun sürecek ve çoğaltma akışını işleyemeyecektir. Ek olarak, müşteri bir işlem gönderdiyse, yalnızca geçerliliğini kontrol etmeniz ve daha ileri iletmeniz gerekir. Bu nedenle, tek Ağ Geçidi sürecini paralel çalışabilen birden fazla bileşenle değiştirdik: RW kilitlemeyi kullanarak paylaşılan bir bellek alanında birbirinden bağımsız olarak çalışan çok iş parçacıklı bilgi ve işlem süreçleri. Aynı zamanda sevk ve çoğaltma süreçlerini de başlattık.

Yüksek Frekanslı Ticaretin Etkisi

Mimarinin yukarıdaki versiyonu 2010 yılına kadar mevcuttu. Bu arada HP Superdome sunucularının performansından artık memnun değildik. Ayrıca PA-RISC mimarisi neredeyse ölmüştü; satıcı herhangi bir önemli güncelleme sunmamıştı. Sonuç olarak HP UX/PA RISC'den Linux/x86'ya geçmeye başladık. Geçiş, erişim sunucularının uyarlanmasıyla başladı.

Neden mimariyi tekrar değiştirmek zorunda kaldık? Gerçek şu ki, yüksek frekanslı ticaret, sistem çekirdeğindeki yük profilini önemli ölçüde değiştirdi.

Diyelim ki önemli bir fiyat değişikliğine neden olan küçük bir işlemimiz var - birisi yarım milyar dolar satın aldı. Birkaç milisaniye sonra tüm piyasa katılımcıları bunu fark ediyor ve düzeltme yapmaya başlıyor. Doğal olarak istekler büyük bir kuyrukta sıralanır ve sistemin bunu temizlemesi uzun zaman alır.

Bu 50 ms aralığında ortalama hız saniyede 16 bin işlem civarındadır. Pencereyi 20 ms'ye indirirsek saniyede ortalama 90 bin işlem hızı elde ediyoruz, en üst noktada 200 bin işlem var. Yani yük sabit değil, ani patlamalar var. Ve istek sırasının her zaman hızlı bir şekilde işlenmesi gerekir.

Peki neden bir kuyruk var? Yani örneğimizde birçok kullanıcı fiyat değişimini fark etti ve buna göre işlem gönderdi. Gateway'e geliyorlar, onları serileştiriyor, belli bir sıra belirliyor ve ağa gönderiyor. Yönlendiriciler paketleri karıştırır ve iletir. Kimin paketi önce gelirse o işlem “kazandı”. Sonuç olarak, borsa müşterileri, aynı işlemin birden fazla Ağ Geçidinden gönderilmesi durumunda, hızlı işlem görme şansının arttığını fark etmeye başladı. Kısa süre sonra takas robotları Gateway'i taleplerle bombardımana tutmaya başladı ve bir çığ gibi işlem ortaya çıktı.

Yeni bir evrim turu

Kapsamlı test ve araştırmalardan sonra gerçek zamanlı işletim sistemi çekirdeğine geçtik. Bunun için MRG'nin gerçek zamanlı mesajlaşma ağı anlamına geldiği RedHat Enterprise MRG Linux'u seçtik. Gerçek zamanlı yamaların avantajı, sistemi mümkün olan en hızlı yürütme için optimize etmeleridir: tüm işlemler bir FIFO kuyruğunda sıralanır, çekirdekler izole edilebilir, çıkarma yapılmaz, tüm işlemler katı bir sırayla işlenir.

Kırmızı - normal bir çekirdekte kuyrukla çalışmak, yeşil - gerçek zamanlı bir çekirdekte çalışmak.

Ancak normal sunucularda düşük gecikme süresine ulaşmak o kadar kolay değil:

• X86 mimarisinde önemli çevre birimleriyle çalışmanın temelini oluşturan SMI modu büyük ölçüde müdahale ediyor. Her türlü donanım olayının işlenmesi ve bileşenlerin ve cihazların yönetimi, işletim sisteminin bellenimin ne yaptığını hiç görmediği şeffaf SMI modunda bellenim tarafından gerçekleştirilir. Kural olarak, tüm büyük satıcılar, donanım yazılımı sunucuları için SMI işleme miktarının azaltılmasına olanak tanıyan özel uzantılar sunar.
• İşlemci frekansının dinamik kontrolü olmamalıdır; bu, ek kesinti süresine yol açar.
• Dosya sistemi günlüğü temizlendiğinde, çekirdekte öngörülemeyen gecikmelere neden olan belirli işlemler meydana gelir.
• CPU Affinity, Interrupt benzeşimi, NUMA gibi şeylere dikkat etmeniz gerekiyor.

Gerçek zamanlı işleme için Linux donanımını ve çekirdeğini kurma konusunun ayrı bir makaleyi hak ettiğini söylemeliyim. İyi bir sonuca ulaşmadan önce denemeler ve araştırmalar yaparak çok zaman harcadık.

PA-RISC sunucularından x86'ya geçerken pratikte sistem kodunu çok fazla değiştirmemize gerek kalmadı, sadece uyarladık ve yeniden yapılandırdık. Aynı zamanda birçok hatayı düzelttik. Örneğin, PA RISC'nin bir Big endian sistemi ve x86'nın bir Little endian sistemi olmasının sonuçları hızla ortaya çıktı: örneğin, veriler yanlış okundu. Daha zor olan hata PA RISC'in kullandığıydı sürekli tutarlı (Sıralı olarak tutarlı) bellek erişimi, x86 ise okuma işlemlerini yeniden sıralayabildiğinden, bir platformda kesinlikle geçerli olan kod diğerinde bozuldu.

X86'ya geçtikten sonra performans neredeyse üç kat arttı, ortalama işlem süresi 60 μs'ye düştü.

Şimdi sistem mimarisinde hangi önemli değişikliklerin yapıldığına daha yakından bakalım.

Sıcak rezerv destanı

Ticari sunuculara geçerken bunların daha az güvenilir olduğunun farkındaydık. Bu nedenle, yeni bir mimari oluştururken, bir veya daha fazla düğümün arızalanma olasılığını önceden varsaydık. Bu nedenle çok hızlı bir şekilde yedek makinelere geçebilecek bir sıcak yedek sisteme ihtiyaç vardı.

Ayrıca başka gereksinimler de vardı:

• Hiçbir durumda işlenmiş işlemleri kaybetmemelisiniz.
• Sistemin altyapımıza kesinlikle şeffaf olması gerekiyor.
• İstemciler kesilen bağlantıları görmemelidir.
• Rezervasyonlar önemli bir gecikmeye neden olmamalıdır çünkü bu, değişim için kritik bir faktördür.

Sıcak yedek sistem oluştururken bu tür senaryoları çift arıza olarak değerlendirmedik (örneğin, bir sunucudaki ağ çalışmayı durdurdu ve ana sunucu dondu); test sırasında tespit edildiği için yazılımdaki hataların olasılığını dikkate almadı; ve donanımın yanlış çalışmasını dikkate almadı.

Sonuç olarak aşağıdaki şemaya geldik:

• Ana sunucu, Ağ Geçidi sunucularıyla doğrudan etkileşime girdi.
• Ana sunucuya alınan tüm işlemler ayrı bir kanal üzerinden anlık olarak yedek sunucuya kopyalanmıştır. Hakem (Vali), herhangi bir sorun ortaya çıkması durumunda değişimi koordine etti.

  

• Ana sunucu her işlemi işliyor ve yedek sunucunun onayını bekliyordu. Gecikmeyi minimumda tutmak için işlemin yedekleme sunucusunda tamamlanmasını beklemekten kaçındık. Bir işlemin ağda dolaşması için geçen süre, yürütme süresiyle karşılaştırılabilir olduğundan, ek bir gecikme eklenmedi.
• Önceki işleme ait yalnızca ana ve yedek sunucuların işlem durumunu kontrol edebildik ve mevcut işlemin işlem durumu bilinmiyordu. Hala tek iş parçacıklı işlemler kullandığımızdan, Yedekleme'den yanıt beklemek tüm işlem akışını yavaşlatabilirdi, bu nedenle makul bir uzlaşma yaptık: önceki işlemin sonucunu kontrol ettik.

Şema şu şekilde çalıştı.

Diyelim ki ana sunucu yanıt vermiyor ancak Ağ Geçitleri iletişim kurmaya devam ediyor. Yedekleme sunucusunda bir zaman aşımı meydana gelir, kendisine ana sunucu rolünü atayan Yönetici ile iletişime geçer ve tüm Ağ Geçitleri yeni ana sunucuya geçer.

Ana sunucu tekrar çevrimiçi olursa, belirli bir süre boyunca Ağ Geçidinden sunucuya herhangi bir çağrı yapılmadığı için bu aynı zamanda dahili bir zaman aşımını da tetikler. Daha sonra o da Valiye başvuruyor ve onu planın dışında tutuyor. Sonuç olarak borsa, işlem döneminin sonuna kadar tek sunucuyla çalışır. Sunucu arızası olasılığı oldukça düşük olduğundan, bu şema oldukça kabul edilebilir kabul edildi, karmaşık bir mantık içermiyordu ve test edilmesi kolaydı.

Devam edecek.

Kaynak: habr.com