Evolucija arhitekture sistema trgovanja i kliringa Moskovske berze. Dio 1

Zdravo svima! Moje ime je Sergej Kostanbajev, na Berzi razvijam jezgro sistema trgovanja.

Kada holivudski filmovi prikazuju Njujoršku berzu, to uvek izgleda ovako: gomile ljudi, svi nešto viču, mašu papirima, pravi se potpuni haos. Ovo se nikada nije desilo ovde na Moskovskoj berzi, jer se trgovanje od samog početka odvija elektronskim putem i bazira se na dve glavne platforme - Spectra (forex tržište) i ASTS (devizno, berzansko i tržište novca). A danas želim da pričam o evoluciji arhitekture ASTS sistema trgovanja i kliringa, o raznim rešenjima i nalazima. Priča će biti duga, pa sam je morao podijeliti na dva dijela.

Mi smo jedna od rijetkih berzi u svijetu koja trguje imovinom svih klasa i pruža čitav niz usluga mjenjača. Na primjer, prošle godine smo bili na drugom mjestu u svijetu po obimu trgovanja obveznicama, na 25. mjestu među svim berzama, na 13. mjestu po kapitalizaciji među javnim berzama.

Za profesionalne učesnike u trgovanju kritični su parametri kao što su vreme odziva, stabilnost vremenske distribucije (jitter) i pouzdanost čitavog kompleksa. Trenutno obrađujemo desetine miliona transakcija dnevno. Obrada svake transakcije od strane kernela sistema traje desetine mikrosekundi. Naravno, mobilni operateri u novogodišnjoj noći ili sami pretraživači imaju veći obim posla od nas, ali po opterećenosti, uz gore navedene karakteristike, malo ko može da se poredi sa nama, čini mi se. Pri tome nam je važno da sistem ne usporava ni na sekundu, da radi apsolutno stabilno, a da su svi korisnici ravnopravni.

Malo istorije

Godine 1994. pokrenut je australijski ASTS sistem na Moskovskoj međubankarskoj berzi valuta (MICEX) i od tog trenutka se može računati ruska istorija elektronskog trgovanja. 1998. godine arhitektura berze je modernizovana kako bi se uvela internet trgovina. Od tada je brzina implementacije novih rješenja i arhitektonskih promjena u svim sistemima i podsistemima samo jačala.

Tih godina, sistem razmene je radio na vrhunskom hardveru - ultra-pouzdanim HP Superdome 9000 serverima (izgrađenim na PA-RISC), u kojoj je duplirano apsolutno sve: ulazno-izlazni podsistemi, mreža, RAM (u stvari, postojao je RAID niz RAM-a), procesori (zamenljivi na vruću). Bilo je moguće promijeniti bilo koju komponentu servera bez zaustavljanja mašine. Oslonili smo se na ove uređaje i smatrali ih praktički sigurnim od kvara. Operativni sistem je bio HP UX sistem sličan Unixu.

Ali otprilike od 2010. godine pojavio se fenomen koji se zove visokofrekventno trgovanje (HFT), ili visokofrekventno trgovanje – jednostavno rečeno, berzanski roboti. Za samo 2,5 godine opterećenje na našim serverima se povećalo 140 puta.

Bilo je nemoguće izdržati takvo opterećenje sa starom arhitekturom i opremom. Trebalo se nekako prilagoditi.

Начало

Zahtjevi prema sistemu razmjene mogu se podijeliti u dvije vrste:

• Transakcije. Ako želite da kupite dolare, akcije ili nešto drugo, šaljete transakciju u sistem trgovanja i dobijate odgovor o uspehu.
• Zahtjevi za informacijama. Ako želite saznati trenutnu cijenu, pogledajte knjigu narudžbi ili indekse, a zatim pošaljite zahtjeve za informacijama.

Šematski, jezgro sistema se može podijeliti na tri nivoa:

• Nivo klijenta, na kojem rade brokeri i klijenti. Svi oni komuniciraju sa pristupnim serverima.
• Gateway serveri su serveri za keširanje koji lokalno obrađuju sve zahtjeve za informacijama. Želite li znati po kojoj cijeni se trenutno trguje dionicama Sberbanke? Zahtjev ide na pristupni server.
• Ali ako želite kupiti dionice, onda zahtjev ide na centralni server (Trade Engine). Za svaku vrstu tržišta postoji po jedan takav server, oni igraju vitalnu ulogu, za njih smo kreirali ovaj sistem.

Srž sistema trgovanja je pametna baza podataka u memoriji u kojoj su sve transakcije transakcije razmene. Baza je napisana u C-u, jedine eksterne zavisnosti bile su libc biblioteka i uopšte nije bilo dinamičke alokacije memorije. Kako bi se smanjilo vrijeme obrade, sistem 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 dalji pristup disku, sav rad se obavlja samo u memoriji. Kada se sistem pokrene, svi referentni podaci su već sortirani, tako da pretraga radi veoma efikasno i traje malo vremena. Sve tabele su napravljene sa nametljivim listama i stablima za dinamičke strukture podataka tako da ne zahtevaju dodelu memorije za vreme izvođenja.

Hajdemo ukratko kroz istoriju razvoja našeg sistema trgovanja i kliringa.
Prva verzija arhitekture sistema trgovanja i kliringa izgrađena je na takozvanoj Unix interakciji: korišćena je zajednička memorija, semafori i redovi, a svaki proces se sastojao od jedne niti. Ovaj pristup je bio široko rasprostranjen ranih 1990-ih.

Prva verzija sistema je sadržala dva nivoa Gateway-a i centralni server sistema trgovanja. Tok rada je bio ovakav:

• Klijent šalje zahtjev koji stiže do Gatewaya. Provjerava valjanost formata (ali ne i samih podataka) i odbija netačne transakcije.
• Ako je zahtjev za informacijama poslan, on se izvršava lokalno; ako govorimo o transakciji, onda se ona preusmjerava na centralni server.
• Trgovački mehanizam zatim obrađuje transakciju, modificira lokalnu memoriju i šalje odgovor na transakciju i samu transakciju na replikaciju koristeći poseban mehanizam za replikaciju.
• Gateway prima odgovor od centralnog čvora i prosljeđuje ga klijentu.
• Nakon nekog vremena, Gateway prima transakciju putem mehanizma replikacije, a ovaj put je izvršava lokalno, mijenjajući svoje strukture podataka tako da sljedeći zahtjevi za informacijama prikazuju najnovije podatke.

U stvari, opisuje model replikacije u kojem je Gateway u potpunosti replicirao radnje izvršene u sistemu trgovanja. Odvojeni kanal replikacije osigurao je da se transakcije izvršavaju istim redoslijedom na više pristupnih čvorova.

Pošto je kod bio jednonitni, klasična šema sa procesnim viljuškama je korištena za opsluživanje mnogih klijenata. Međutim, bilo je jako skupo razdvojiti cijelu bazu podataka, pa su korišteni lagani servisni procesi koji su prikupljali pakete iz TCP sesija i prenijeli ih u jedan red (SystemV Message Queue). Gateway i Trade Engine su radili samo sa ovim redom, uzimajući transakcije odatle za izvršenje. Više nije bilo moguće poslati odgovor na njega, jer nije bilo jasno koji servisni proces treba da ga pročita. Zato smo pribjegli triku: svaki račvani proces kreirao je red odgovora za sebe, a kada je zahtjev došao u dolazni red, odmah mu je dodana oznaka za red odgovora.

Konstantno kopiranje velikih količina podataka iz reda u red je stvorilo probleme, posebno tipične za zahtjeve za informacijama. Stoga smo koristili još jedan trik: pored reda za odgovore, svaki proces je kreirao i zajedničku memoriju (SystemV Shared Memory). Sami paketi su stavljeni u njega, a u red čekanja je pohranjena samo oznaka koja je omogućavala pronalaženje originalnog paketa. Ovo je pomoglo da se podaci pohranjuju u keš memoriju procesora.

SystemV IPC uključuje pomoćne programe za gledanje stanja reda, memorije i objekata semafora. Ovo smo aktivno koristili da shvatimo šta se dešava u sistemu u određenom trenutku, gde se skupljaju paketi, šta je blokirano itd.

Prve modernizacije

Prije svega, riješili smo se jednoprocesnog Gatewaya. Njegov značajan nedostatak je bio to što je mogao da obrađuje ili jednu transakciju replikacije ili jedan zahtev za informacijama od klijenta. A kako se opterećenje povećava, Gatewayu će trebati više vremena da obradi zahtjeve i neće moći obraditi tok replikacije. Osim toga, ako je klijent poslao transakciju, potrebno je samo provjeriti njenu valjanost i proslijediti je dalje. Stoga smo zamijenili jedan Gateway proces sa više komponenti koje se mogu izvoditi paralelno: višenitne informacije i transakcijski procesi koji se izvode nezavisno jedan od drugog na području dijeljene memorije koristeći RW zaključavanje. 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 servera. Pored toga, PA-RISC arhitektura je praktično bila mrtva; dobavljač nije ponudio nikakva značajna ažuriranja. Kao rezultat toga, počeli smo da prelazimo sa HP UX/PA RISC na Linux/x86. Tranzicija je započela adaptacijom pristupnih servera.

Zašto smo morali ponovo da menjamo arhitekturu? Činjenica je da je visokofrekventno trgovanje značajno promijenilo profil opterećenja na jezgru sistema.

Recimo da imamo malu transakciju koja je izazvala značajnu promjenu cijene – neko je kupio pola milijarde dolara. Nakon nekoliko milisekundi, svi učesnici na tržištu to primjećuju i počinju sa korekcijom. Naravno, zahtjevi se poređaju u velikom redu, koji će sistemu trebati dosta vremena da ga očisti.

U ovom intervalu od 50 ms, prosječna brzina je oko 16 hiljada transakcija u sekundi. Ako smanjimo prozor na 20 ms, dobićemo prosječnu brzinu od 90 hiljada transakcija u sekundi, sa 200 hiljada transakcija na vrhuncu. Drugim riječima, opterećenje nije konstantno, sa iznenadnim rafalima. A red zahtjeva uvijek mora biti brzo obrađen.

Ali zašto uopšte postoji red? Dakle, u našem primjeru, mnogi korisnici su primijetili promjenu cijene i u skladu s tim poslali transakcije. Dolaze na Gateway, on ih serijalizuje, postavlja određeni red i šalje ih u mrežu. Ruteri miješaju pakete i prosljeđuju ih dalje. Čiji je paket prvi stigao, ta transakcija je “pobijedila”. Kao rezultat toga, klijenti mjenjačnice počeli su primjećivati ​​da ako je ista transakcija poslana s nekoliko Gateway-a, onda su šanse za njenu brzu obradu povećane. Ubrzo su roboti za razmjenu počeli bombardirati Gateway zahtjevima i podigla se lavina transakcija.

Novi krug evolucije

Nakon opsežnog testiranja i istraživanja, prešli smo na kernel operativnog sistema u realnom vremenu. Za ovo smo odabrali RedHat Enterprise MRG Linux, gdje MRG označava mrežu za razmjenu poruka u realnom vremenu. Prednost zakrpa u realnom vremenu je u tome što optimizuju sistem za najbrže moguće izvršenje: svi procesi su poređani u FIFO redu, jezgra se mogu izolovati, nema izbacivanja, sve transakcije se obrađuju u strogom redosledu.

Crvena - rad sa redom u običnom kernelu, zelena - rad u kernelu u realnom vremenu.

Ali postizanje niske latencije na redovnim serverima nije tako lako:

• SMI način rada, koji je u x86 arhitekturi osnova za rad sa važnim periferijama, u velikoj mjeri ometa. Obradu svih vrsta hardverskih događaja i upravljanje komponentama i uređajima firmver obavlja u takozvanom transparentnom SMI modu, u kojem operativni sistem uopšte ne vidi šta firmver radi. Po pravilu, svi glavni proizvođači nude posebna proširenja za servere firmvera koja omogućavaju smanjenje količine SMI obrade.
• Ne bi trebalo postojati dinamička kontrola frekvencije procesora, to dovodi do dodatnog zastoja.
• Kada se evidencija sistema datoteka isprazni, određeni procesi se javljaju u kernelu koji uzrokuju nepredvidiva kašnjenja.
• Morate obratiti pažnju na stvari kao što su CPU Affinity, Interrupt afinity, NUMA.

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

Prilikom prelaska sa PA-RISC servera na x86, praktički nismo morali mnogo da menjamo sistemski kod, samo smo ga prilagodili i rekonfigurisali. Istovremeno smo ispravili nekoliko grešaka. Na primjer, posljedice činjenice da je PA RISC bio Big endian sistem, a x86 Little endian sistem, brzo su se pojavile: na primjer, podaci su pogrešno pročitani. Zamršenija greška je bila koju PA RISC koristi dosljedno dosljedan (Sekvencijalno dosljedno) pristup memoriji, dok x86 može preurediti operacije čitanja, tako da je kod koji je bio apsolutno važeći na jednoj platformi postao pokvaren na drugoj.

Nakon prelaska na x86, performanse su se povećale skoro tri puta, prosječno vrijeme obrade transakcije smanjeno je na 60 μs.

Pogledajmo sada bliže koje su ključne promjene napravljene u arhitekturi sistema.

Hot rezervni ep

Prilikom prelaska na robne servere, bili smo svjesni da su manje pouzdani. Stoga smo pri kreiranju nove arhitekture a priori pretpostavili mogućnost kvara jednog ili više čvorova. Zbog toga je bio potreban sistem vruće pripravnosti koji bi se vrlo brzo mogao prebaciti na rezervne mašine.

Osim toga, postojali su i drugi zahtjevi:

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

Prilikom kreiranja sistema vruće pripravnosti, takve scenarije nismo smatrali dvostrukim kvarovima (na primjer, mreža na jednom serveru je prestala da radi, a glavni server se zamrznuo); nije uzeo u obzir mogućnost grešaka u softveru jer su identifikovane tokom testiranja; i nije uzeo u obzir neispravan rad hardvera.

Kao rezultat, došli smo do sljedeće šeme:

• Glavni server je direktno komunicirao sa serverima mrežnog prolaza.
• Sve transakcije primljene na glavnom serveru su trenutno replicirane na rezervni server preko posebnog kanala. Arbitar (guverner) je koordinirao prebacivanje ako bi se pojavili problemi.

  

• Glavni server je obradio svaku transakciju i čekao potvrdu od rezervnog servera. Kako bismo latenciju sveli na minimum, izbjegavali smo čekanje da se transakcija završi na backup serveru. Budući da je vrijeme potrebno da transakcija prođe kroz mrežu bilo je uporedivo s vremenom izvršenja, nije dodano dodatno kašnjenje.
• Mogli smo samo provjeriti status obrade glavnog i rezervnog servera za prethodnu transakciju, a status obrade trenutne transakcije je bio nepoznat. Budući da smo još uvijek koristili jednonitne procese, čekanje na odgovor od Backup-a bi usporilo cijeli tok obrade, pa smo napravili razuman kompromis: provjerili smo rezultat prethodne transakcije.

Shema je funkcionirala na sljedeći način.

Recimo da glavni server prestane da reaguje, ali mrežni prolazi nastavljaju da komuniciraju. Na backup serveru dolazi do isteka vremena, on kontaktira guvernera, koji mu dodeljuje ulogu glavnog servera, a svi mrežni prolazi prelaze na novi glavni server.

Ako se glavni server vrati na mrežu, on takođe pokreće interni timeout, jer nije bilo poziva serveru sa mrežnog prolaza određeno vreme. Zatim se obraća i guverneru, a on ga isključuje iz šeme. Kao rezultat toga, berza radi sa jednim serverom do kraja perioda trgovanja. Budući da je vjerovatnoća kvara servera prilično mala, ova šema se smatrala sasvim prihvatljivom, nije sadržavala složenu logiku i bila je laka za testiranje.

Nastaviti.

izvor: www.habr.com