Evolucija arhitekture sustava trgovanja i kliringa Moskovske burze. 1. dio

Bok svima! Moje ime je Sergey Kostanbaev, na Burzi razvijam jezgru trgovinskog sustava.

Kada se u holivudskim filmovima prikazuje Njujorška burza, uvijek izgleda ovako: gomile ljudi, svi nešto viču, mašu papirima, događa se potpuni kaos. Kod nas na Moskovskoj burzi to se nikada nije dogodilo jer se trgovanje od samog početka odvija elektroničkim putem i temelji se na dvije glavne platforme – Spectra (forex tržište) i ASTS (devizno, dioničko i novčano tržište). A danas želim govoriti o evoluciji arhitekture ASTS sustava trgovanja i kliringa, o raznim rješenjima i nalazima. Priča će biti duga pa sam je morao podijeliti na dva dijela.

Mi smo jedna od rijetkih burzi u svijetu koja trguje imovinom svih klasa i pruža cijeli niz usluga mjenjačnice. Primjerice, prošle smo godine bili drugi u svijetu po obimu trgovanja obveznicama, 25. mjesto među svim burzama, 13. mjesto po kapitalizaciji među javnim burzama.

Za profesionalne sudionike trgovanja kritični su parametri kao što su vrijeme odziva, stabilnost distribucije vremena (jitter) i pouzdanost cijelog kompleksa. Trenutno obrađujemo desetke milijuna transakcija dnevno. Obrada svake transakcije od strane jezgre sustava traje desetke mikrosekundi. Naravno, mobilni operateri u novogodišnjoj noći ili same tražilice imaju veće opterećenje od naših, ali po opterećenosti, uz gore navedene karakteristike, malo tko se može mjeriti s nama, čini mi se. Pritom nam je bitno da sustav ne usporava ni sekunde, da radi apsolutno stabilno, a da su svi korisnici ravnopravni.

Malo povijesti

Godine 1994. australski ASTS sustav pokrenut je na Moskovskoj međubankarskoj burzi (MICEX) i od tog trenutka može se računati ruska povijest elektroničkog trgovanja. Godine 1998. arhitektura burze je modernizirana kako bi se uvelo internetsko trgovanje. Od tada se brzina implementacije novih rješenja i arhitektonskih promjena u svim sustavima i podsustavima samo ubrzava.

Tih je godina sustav razmjene radio na hi-end hardveru - ultra-pouzdanim HP Superdome 9000 poslužiteljima (izgrađenim na PA-RISC), u kojem je bilo duplicirano apsolutno sve: ulazno/izlazni podsustavi, mreža, RAM (zapravo, postojao je RAID niz RAM-a), procesori (hot-swappable). Bilo je moguće promijeniti bilo koju komponentu poslužitelja bez zaustavljanja stroja. Oslonili smo se na te uređaje i smatrali ih gotovo sigurnima od kvarova. Operativni sustav bio je HP UX sustav sličan Unixu.

No, otprilike od 2010. godine pojavio se fenomen nazvan visokofrekventno trgovanje (HFT), odnosno visokofrekventno trgovanje – jednostavno rečeno, burzovni roboti. U samo 2,5 godine opterećenje naših poslužitelja povećalo se 140 puta.

Sa starom arhitekturom i opremom nije bilo moguće izdržati takvo opterećenje. Trebalo se nekako prilagoditi.

početak

Zahtjevi prema sustavu razmjene mogu se podijeliti u dvije vrste:

• Transakcije. Ako želite kupiti dolare, dionice ili nešto drugo, šaljete transakciju u trgovinski sustav i dobivate odgovor o uspješnosti.
• Zahtjevi za informacijama. Ako želite saznati trenutnu cijenu, pogledajte knjigu narudžbi ili indekse, zatim pošaljite upite za informacije.

Shematski se jezgra sustava može podijeliti na tri razine:

• Razina klijenta, na kojoj rade brokeri i klijenti. Svi oni komuniciraju s pristupnim poslužiteljima.
• Gateway poslužitelji su poslužitelji za predmemoriju koji lokalno obrađuju sve zahtjeve za informacijama. Želite li znati po kojoj se cijeni trenutno trguje dionicama Sberbanke? Zahtjev ide pristupnom poslužitelju.
• Ali ako želite kupiti dionice, tada zahtjev ide na središnji poslužitelj (Trade Engine). Postoji jedan takav poslužitelj za svaku vrstu tržišta, oni igraju vitalnu ulogu, za njih smo kreirali ovaj sustav.

Jezgra trgovinskog sustava je pametna baza podataka u memoriji u kojoj su sve transakcije transakcije razmjene. Baza je napisana u C-u, jedine vanjske ovisnosti bile su biblioteka libc i uopće nije bilo dinamičke dodjele memorije. Kako bi se smanjilo vrijeme obrade, sustav počinje sa statičkim skupom nizova i sa statičkim premještanjem podataka: prvo se svi podaci za tekući dan učitavaju u memoriju i ne vrši se daljnji pristup disku, sav rad se obavlja samo u memoriji. Kada se sustav pokrene, svi referentni podaci već su sortirani, tako da pretraživanje radi vrlo učinkovito i traje malo vremena u vremenu izvođenja. Sve tablice izrađene su s nametljivim popisima i stablima za dinamičke strukture podataka tako da ne zahtijevaju dodjelu memorije tijekom izvođenja.

Osvrnimo se ukratko na povijest razvoja našeg trgovinskog i klirinškog sustava.
Prva verzija arhitekture sustava trgovanja i kliringa izgrađena je na tzv. Unix interakciji: korištena je zajednička memorija, semafori i redovi čekanja, a svaki se proces sastojao od jedne dretve. Ovaj pristup bio je raširen početkom 1990-ih.

Prva verzija sustava sadržavala je dvije razine Gatewaya i središnji poslužitelj trgovinskog sustava. Tok rada je bio ovakav:

• Klijent šalje zahtjev koji dolazi do pristupnika. Provjerava valjanost formata (ali ne i same podatke) i odbija netočne transakcije.
• Ako je zahtjev za informacijama poslan, on se izvršava lokalno; ako govorimo o transakciji, onda se ona preusmjerava na središnji poslužitelj.
• Trgovački mehanizam zatim obrađuje transakciju, modificira lokalnu memoriju i šalje odgovor na transakciju i samu transakciju za replikaciju pomoću zasebnog replikacijskog mehanizma.
• Gateway prima odgovor od središnjeg čvora i prosljeđuje ga klijentu.
• Nakon nekog vremena Gateway prima transakciju putem mehanizma replikacije i ovaj put je izvršava lokalno, mijenjajući svoje strukture podataka tako da sljedeći zahtjevi za informacijama prikazuju najnovije podatke.

Zapravo, opisuje replikacijski model u kojem je Gateway u potpunosti replicirao radnje koje se izvode u sustavu trgovanja. Odvojeni replikacijski kanal osigurava da se transakcije izvršavaju istim redoslijedom preko višestrukih pristupnih čvorova.

Budući da je kod bio jednonitni, klasična shema s procesnim račvama korištena je za posluživanje mnogih klijenata. Međutim, bilo je vrlo skupo forkirati cijelu bazu podataka, pa su korišteni lagani servisni procesi koji su skupljali pakete iz TCP sesija i prenosili ih u jedan red (SystemV Message Queue). Gateway i Trade Engine radili su samo s ovim redom čekanja, preuzimajući transakcije odatle za izvršenje. Više nije bilo moguće poslati odgovor na njega, jer nije bilo jasno koji ga servisni proces treba pročitati. Stoga smo pribjegli triku: svaki račvani proces je za sebe stvorio red čekanja odgovora, a kada je zahtjev došao u dolazni red čekanja, odmah mu je dodana oznaka za red čekanja odgovora.

Konstantno kopiranje velikih količina podataka iz reda u red stvaralo je probleme, osobito tipične za informacijske zahtjeve. Stoga smo upotrijebili još jedan trik: osim reda čekanja odgovora, svaki proces je također kreirao zajedničku memoriju (SystemV Shared Memory). Sami su paketi bili smješteni u njega, a samo je oznaka bila pohranjena u redu čekanja, omogućujući pronalazak originalnog paketa. To je pomoglo u pohranjivanju podataka u predmemoriju procesora.

SystemV IPC uključuje pomoćne programe za gledanje stanja reda čekanja, memorije i objekata semafora. Ovo smo aktivno koristili kako bismo razumjeli što se događa u sustavu u određenom trenutku, gdje su se paketi nakupili, što je blokirano itd.

Prve modernizacije

Prije svega, riješili smo se jednoprocesnog Gatewaya. Njegov značajan nedostatak bio je taj što je mogao obraditi ili jednu replikacijsku transakciju ili jedan informacijski zahtjev od klijenta. A kako se opterećenje povećava, pristupniku će trebati više vremena za obradu zahtjeva i neće moći obraditi tok replikacije. Osim toga, ako je klijent poslao transakciju, tada samo trebate provjeriti njezinu valjanost i proslijediti je dalje. Stoga smo zamijenili jedan Gateway proces s višestrukim komponentama koje se mogu izvoditi paralelno: višenitni procesi informacija i transakcija koji se izvode neovisno jedan o drugom na području zajedničke memorije pomoću RW zaključavanja. Istovremeno smo uveli procese otpreme i replikacije.

Utjecaj visokofrekventnog trgovanja

Gornja verzija arhitekture postojala je do 2010. godine. U međuvremenu, više nismo bili zadovoljni performansama HP Superdome poslužitelja. Osim toga, PA-RISC arhitektura bila je praktički mrtva; dobavljač nije ponudio nikakva značajna ažuriranja. Kao rezultat toga, počeli smo prelaziti s HP UX/PA RISC na Linux/x86. Prijelaz je započeo prilagodbom pristupnih poslužitelja.

Zašto smo morali ponovno mijenjati arhitekturu? Činjenica je da je visokofrekventno trgovanje značajno promijenilo profil opterećenja jezgre sustava.

Recimo da imamo malu transakciju koja je uzrokovala značajnu promjenu cijene – netko je kupio pola milijarde dolara. Nakon nekoliko milisekundi, svi sudionici na tržištu to primjećuju i počinju vršiti korekciju. Naravno, zahtjevi se redaju u velikom redu čekanja, čije će čišćenje sustavu trebati dugo vremena.

Na ovom intervalu od 50 ms prosječna brzina je oko 16 tisuća transakcija u sekundi. Ako smanjimo prozor na 20 ms, dobivamo prosječnu brzinu od 90 tisuća transakcija u sekundi, s 200 tisuća transakcija na vrhuncu. Drugim riječima, opterećenje nije konstantno, s iznenadnim naletima. A red zahtjeva uvijek se mora brzo obraditi.

Ali zašto uopće postoji red? Dakle, u našem primjeru, mnogi su korisnici primijetili promjenu cijene i poslali transakcije u skladu s tim. Oni dolaze u Gateway, on ih serijalizira, postavlja određeni redoslijed i šalje ih na mrežu. Usmjerivači miješaju pakete i prosljeđuju ih dalje. Čiji paket prvi stigne, ta je transakcija "pobijedila". Kao rezultat toga, klijenti razmjene počeli su primjećivati ​​da ako je ista transakcija poslana s nekoliko pristupnika, tada su se povećale šanse za njezinu brzu obradu. Ubrzo su roboti mjenjačnice počeli bombardirati Gateway zahtjevima i nastala je lavina transakcija.

Novi krug evolucije

Nakon opsežnog testiranja i istraživanja, prebacili smo se na jezgru operativnog sustava u stvarnom vremenu. Za ovo smo odabrali RedHat Enterprise MRG Linux, gdje MRG označava mrežu poruka u stvarnom vremenu. Prednost zakrpa u stvarnom vremenu je u tome što optimiziraju sustav za najbrže moguće izvršenje: svi su procesi poredani u FIFO red čekanja, jezgre se mogu izolirati, nema izbacivanja, sve se transakcije obrađuju u strogom slijedu.

Crveno - rad s redom čekanja u običnom kernelu, zeleno - rad u kernelu u stvarnom vremenu.

Ali postizanje niske latencije na običnim poslužiteljima nije tako jednostavno:

• Jako smeta SMI mod koji je u x86 arhitekturi temelj za rad s važnim periferijama. Obradu svih vrsta hardverskih događaja i upravljanje komponentama i uređajima vrši firmware u takozvanom transparentnom SMI modu, u kojem operativni sustav uopće ne vidi što firmware radi. U pravilu, svi glavni dobavljači nude posebne ekstenzije za firmware poslužitelje koji omogućuju smanjenje količine SMI obrade.
• Ne bi trebalo biti dinamičke kontrole frekvencije procesora, to dovodi do dodatnog zastoja.
• Kada se zapisnik datotečnog sustava ispere, u kernelu se događaju određeni procesi koji uzrokuju nepredvidiva kašnjenja.
• Morate obratiti pozornost na stvari kao što su CPU afinitet, afinitet prekida, NUMA.

Moram reći da tema postavljanja Linux hardvera i kernela za obradu u stvarnom vremenu zaslužuje poseban članak. Proveli smo puno vremena eksperimentirajući i istražujući prije nego što smo postigli dobar rezultat.

Prilikom prelaska s PA-RISC poslužitelja na x86 praktički nismo morali puno mijenjati kod sustava, samo smo ga prilagodili i rekonfigurirali. Istovremeno smo ispravili nekoliko grešaka. Na primjer, brzo su isplivale posljedice činjenice da je PA RISC Big endian sustav, a x86 Little endian sustav: na primjer, podaci su netočno čitani. Zamršeniji bug bio je taj što koristi PA RISC dosljedno dosljedan (Sekvencijalno dosljedan) pristup memoriji, dok x86 može promijeniti redoslijed operacija čitanja, tako da kod koji je bio apsolutno valjan na jednoj platformi postaje pokvaren na drugoj.

Nakon prelaska na x86, performanse su se povećale gotovo tri puta, prosječno vrijeme obrade transakcija smanjilo se na 60 μs.

Pogledajmo sada pobliže koje su ključne promjene napravljene u arhitekturi sustava.

Vrući rezervni ep

Prilikom prelaska na robne poslužitelje bili smo svjesni da su manje pouzdani. Stoga smo pri izradi nove arhitekture a priori pretpostavili mogućnost kvara jednog ili više čvorova. Stoga je bio potreban hot standby sustav koji bi se mogao vrlo brzo prebaciti na rezervne strojeve.

Osim toga, postojali su i drugi zahtjevi:

• Ni pod kojim okolnostima ne smijete izgubiti obrađene transakcije.
• Sustav mora biti apsolutno transparentan za našu infrastrukturu.
• Klijenti ne bi trebali vidjeti prekinute veze.
• Rezervacije ne bi trebale uzrokovati značajna kašnjenja jer je to kritičan faktor za razmjenu.

Prilikom stvaranja sustava vruće pripravnosti takve scenarije nismo smatrali dvostrukim kvarovima (na primjer, mreža na jednom poslužitelju prestala je raditi, a glavni poslužitelj se zamrznuo); nije razmotrio mogućnost grešaka u softveru jer su one identificirane tijekom testiranja; i nije uzeo u obzir neispravan rad hardvera.

Kao rezultat toga, došli smo do sljedeće sheme:

• Glavni poslužitelj izravno je komunicirao s pristupnim poslužiteljima.
• Sve transakcije primljene na glavnom poslužitelju trenutno su replicirane na rezervni poslužitelj putem zasebnog kanala. Sudac (guverner) je koordinirao zamjenu ako se pojave problemi.

  

• Glavni poslužitelj obrađivao je svaku transakciju i čekao potvrdu rezervnog poslužitelja. Kako bismo latenciju sveli na minimum, izbjegli smo čekanje da se transakcija završi na rezervnom poslužitelju. Budući da je vrijeme potrebno da transakcija putuje mrežom bilo usporedivo s vremenom izvršenja, nije dodana dodatna latencija.
• Mogli smo samo provjeriti status obrade glavnog i rezervnih poslužitelja za prethodnu transakciju, a status obrade trenutne transakcije bio je nepoznat. Budući da smo i dalje koristili procese s jednom niti, čekanje odgovora od sigurnosne kopije usporilo bi cijeli tijek obrade, pa smo napravili razuman kompromis: provjerili smo rezultat prethodne transakcije.

Shema je radila na sljedeći način.

Recimo da glavni poslužitelj prestane odgovarati, ali pristupnici nastavljaju komunicirati. Na rezervnom poslužitelju dolazi do vremenskog ograničenja, on kontaktira upravitelja koji mu dodjeljuje ulogu glavnog poslužitelja, a svi se pristupnici prebacuju na novi glavni poslužitelj.

Ako se glavni poslužitelj vrati na mrežu, također pokreće interno vremensko ograničenje jer određeno vrijeme nije bilo poziva prema poslužitelju s pristupnika. Tada se također obraća guverneru, koji ga isključuje iz plana. Kao rezultat toga, burza radi s jednim poslužiteljem do kraja razdoblja trgovanja. Budući da je vjerojatnost kvara poslužitelja prilično niska, ova se shema smatra sasvim prihvatljivom; nije sadržavala složenu logiku i lako ju je testirati.

Nastaviti.

Izvor: www.habr.com