Maskvos biržos prekybos ir kliringo sistemos architektūros raida. 1 dalis

Sveiki visi! Mano vardas Sergejus Kostanbajevas, biržoje kuriu prekybos sistemos branduolį.

Kai Holivudo filmuose rodoma Niujorko birža, visada atrodo taip: žmonių minios, visi kažką šaukia, mojuoja popieriais, vyksta visiškas chaosas. Čia Maskvos biržoje to niekada nebuvo, nes prekyba nuo pat pradžių buvo vykdoma elektroniniu būdu ir yra paremta dviem pagrindinėmis platformomis – Spectra (forex rinka) ir ASTS (užsienio birža, akcijų ir pinigų rinka). O šiandien noriu pakalbėti apie ASTS prekybos ir kliringo sistemos architektūros raidą, apie įvairius sprendimus ir atradimus. Istorija bus ilga, todėl teko ją suskaidyti į dvi dalis.

Esame viena iš nedaugelio biržų pasaulyje, kuri prekiauja visų klasių turtu ir teikia visą keitimo paslaugų spektrą. Pavyzdžiui, pernai užėmėme antrą vietą pasaulyje pagal prekybos obligacijomis apimtis, 25 vietą tarp visų biržų, 13 vietą pagal kapitalizaciją tarp viešųjų biržų.

Profesionaliems prekybos dalyviams tokie parametrai kaip atsako laikas, laiko pasiskirstymo stabilumas (drebėjimas) ir viso komplekso patikimumas yra labai svarbūs. Šiuo metu per dieną apdorojame dešimtis milijonų operacijų. Kiekvienos operacijos apdorojimas sistemos branduolyje trunka dešimtis mikrosekundžių. Žinoma, mobiliojo ryšio operatoriai Naujųjų metų išvakarėse ar pačios paieškos sistemos turi didesnį darbo krūvį nei pas mus, bet pagal darbo krūvį, kartu su aukščiau paminėtomis savybėmis, man atrodo, mažai kas gali lygintis su mumis. Tuo pačiu mums svarbu, kad sistema nė sekundei nesulėtėtų, veiktų absoliučiai stabiliai, o visi vartotojai būtų vienodoje padėtyje.

Šiek tiek istorijos

1994 m. Maskvos tarpbankinėje valiutų biržoje (MICEX) buvo paleista Australijos ASTS sistema, nuo kurios galima skaičiuoti Rusijos elektroninės prekybos istoriją. 1998 m. biržos architektūra buvo modernizuota, įvedant internetinę prekybą. Nuo tada naujų sprendimų diegimo ir architektūrinių pokyčių visose sistemose ir posistemiuose greitis tik įgauna pagreitį.

Tais metais mainų sistema veikė su aukščiausios klasės aparatine įranga – itin patikimais HP Superdome 9000 serveriais (pastatytais PA-RISC), kuriame dubliavosi absoliučiai viskas: įvesties/išvesties posistemiai, tinklas, operatyvioji atmintis (tiesą sakant, buvo RAID masyvas RAM), procesoriai (pakeičiami karštuoju režimu). Nestabdant mašinos buvo galima pakeisti bet kurį serverio komponentą. Pasitikėjome šiais įrenginiais ir laikėme juos beveik saugiais. Operacinė sistema buvo į Unix panaši HP UX sistema.

Tačiau maždaug nuo 2010 metų atsirado reiškinys, vadinamas aukšto dažnio prekyba (HFT), arba aukšto dažnio prekyba – paprasčiau tariant, biržos robotai. Vos per 2,5 metų mūsų serverių apkrova išaugo 140 kartų.

Su sena architektūra ir įranga tokio krūvio atlaikyti buvo neįmanoma. Reikėjo kažkaip prisitaikyti.

Pradėti

Užklausas mainų sistemai galima suskirstyti į du tipus:

• Sandoriai. Jei norite nusipirkti dolerių, akcijų ar dar ką nors, siunčiate sandorį į prekybos sistemą ir gaunate atsakymą apie sėkmę.
• Informacijos prašymai. Jei norite sužinoti esamą kainą, peržiūrėti užsakymų knygą ar indeksus, tada siųsti informacijos užklausas.

Schematiškai sistemos šerdį galima suskirstyti į tris lygius:

• Kliento lygis, kuriame dirba brokeriai ir klientai. Visi jie sąveikauja su prieigos serveriais.
• Šliuzo serveriai yra talpyklos serveriai, kurie lokaliai apdoroja visas informacijos užklausas. Ar norite sužinoti, kokia kaina šiuo metu prekiaujama „Sberbank“ akcijomis? Prašymas siunčiamas į prieigos serverį.
• Bet jei norite nusipirkti akcijų, tada užklausa siunčiama į centrinį serverį (Trade Engine). Kiekvienam rinkos tipui yra vienas toks serveris, jie atlieka gyvybiškai svarbų vaidmenį, būtent jiems sukūrėme šią sistemą.

Prekybos sistemos esmė yra sumani duomenų bazė atmintyje, kurioje visi sandoriai yra mainų sandoriai. Pagrindas buvo parašyta C, vienintelės išorinės priklausomybės buvo libc biblioteka ir iš viso nebuvo dinaminio atminties paskirstymo. Kad sutrumpėtų apdorojimo laikas, sistema pradedama nuo statinio masyvų rinkinio ir statinio duomenų perkėlimo: pirmiausia į atmintį įkeliami visi einamosios dienos duomenys ir nebeatliekama prieiga prie disko, visi darbai atliekami tik atmintyje. Kai sistema paleidžiama, visi atskaitos duomenys jau yra surūšiuoti, todėl paieška veikia labai efektyviai ir trunka mažai laiko. Visos lentelės yra sudarytos su įkyriais sąrašais ir medžiais dinaminėms duomenų struktūroms, kad vykdymo metu joms nereikėtų skirti atminties.

Trumpai apžvelgsime mūsų prekybos ir kliringo sistemos raidos istoriją.
Pirmoji prekybos ir kliringo sistemos architektūros versija buvo sukurta remiantis vadinamąja Unix sąveika: buvo naudojama bendra atmintis, semaforai ir eilės, o kiekvienas procesas susideda iš vienos gijos. Šis požiūris buvo plačiai paplitęs 1990-ųjų pradžioje.

Pirmojoje sistemos versijoje buvo du lygiai Gateway ir centrinis prekybos sistemos serveris. Darbo eiga buvo tokia:

• Klientas siunčia užklausą, kuri pasiekia šliuzą. Ji tikrina formato (bet ne pačių duomenų) galiojimą ir atmeta neteisingas operacijas.
• Jeigu buvo išsiųstas informacijos prašymas, jis vykdomas lokaliai; jei mes kalbame apie sandorį, tada jis nukreipiamas į centrinį serverį.
• Tada prekybos variklis apdoroja operaciją, modifikuoja vietinę atmintį ir siunčia atsakymą į operaciją bei pačią operaciją replikuoti naudodamas atskirą replikacijos variklį.
• Vartai gauna atsakymą iš centrinio mazgo ir perduoda jį klientui.
• Po kurio laiko „Gateway“ gauna operaciją per replikacijos mechanizmą ir šį kartą ją vykdo lokaliai, pakeisdamas duomenų struktūras taip, kad kitose informacijos užklausose būtų rodomi naujausi duomenys.

Tiesą sakant, jis aprašo replikacijos modelį, kuriame „Gateway“ visiškai atkartojo prekybos sistemoje atliekamus veiksmus. Atskiras replikacijos kanalas užtikrino, kad operacijos būtų vykdomos ta pačia tvarka keliuose prieigos mazguose.

Kadangi kodas buvo vienos gijos, daugeliui klientų aptarnauti buvo naudojama klasikinė schema su proceso šakėmis. Tačiau visos duomenų bazės šakės buvo labai brangios, todėl buvo naudojami lengvi paslaugų procesai, kurie rinko paketus iš TCP seansų ir perkeldavo juos į vieną eilę (SystemV Message Queue). „Gateway“ ir „Trade Engine“ veikė tik su šia eile, iš ten paimdami operacijas vykdyti. Atsakymo į jį išsiųsti nebepavyko, nes nebuvo aišku, kuris serviso procesas turėtų jį perskaityti. Taigi griebėmės gudrybės: kiekvienas šakotasis procesas susikurdavo sau atsakymo eilę, o kai užklausa pateko į gaunamą eilę, prie jos iškart buvo pridėta atsakymo eilės žyma.

Nuolat kopijuojant didelius duomenų kiekius iš eilės į eilę kilo problemų, ypač būdingų informacijos užklausoms. Todėl panaudojome kitą gudrybę: be atsakymo eilės, kiekvienas procesas taip pat sukūrė bendrinamą atmintį (SystemV Shared Memory). Į jį buvo dedamos pačios pakuotės, o eilėje buvo saugoma tik etiketė, leidžianti rasti originalią pakuotę. Tai padėjo išsaugoti duomenis procesoriaus talpykloje.

„SystemV IPC“ apima programas, skirtas peržiūrėti eilės būseną, atmintį ir semaforinius objektus. Tai aktyviai naudojome norėdami suprasti, kas konkrečiu momentu vyksta sistemoje, kur kaupiasi paketai, kas užblokuota ir pan.

Pirmieji modernizavimai

Visų pirma, atsikratėme vieno proceso vartų. Reikšmingas trūkumas buvo tai, kad jis galėjo apdoroti vieną replikacijos operaciją arba vieną kliento informacijos užklausą. Didėjant apkrovai, „Gateway“ užklausų apdorojimas užtruks ilgiau ir negalės apdoroti replikacijos srauto. Be to, jei klientas atsiuntė operaciją, tereikia patikrinti jos galiojimą ir persiųsti toliau. Todėl vieną šliuzo procesą pakeitėme keliais komponentais, kurie gali veikti lygiagrečiai: kelių gijų informacija ir operacijų procesai, veikiantys nepriklausomai vienas nuo kito bendros atminties srityje, naudojant RW užrakinimą. Ir tuo pat metu pristatėme siuntimo ir replikacijos procesus.

Aukšto dažnio prekybos poveikis

Aukščiau pateikta architektūros versija egzistavo iki 2010 m. Tuo tarpu HP Superdome serverių veikimas mūsų nebetenkino. Be to, PA-RISC architektūra buvo beveik mirusi; pardavėjas nepasiūlė jokių reikšmingų atnaujinimų. Dėl to pradėjome pereiti nuo HP UX/PA RISC prie Linux/x86. Perėjimas prasidėjo nuo prieigos serverių pritaikymo.

Kodėl vėl turėjome keisti architektūrą? Faktas yra tas, kad aukšto dažnio prekyba žymiai pakeitė sistemos branduolio apkrovos profilį.

Tarkime, turime nedidelį sandorį, dėl kurio smarkiai pasikeitė kaina – kažkas nupirko pusę milijardo dolerių. Po poros milisekundžių visi rinkos dalyviai tai pastebi ir pradeda taisyti. Natūralu, kad užklausos rikiuojasi didžiulėje eilėje, kurią sistemai išvalyti užtruks daug laiko.

Šiuo 50 ms intervalu vidutinis greitis yra apie 16 tūkstančių operacijų per sekundę. Jei sumažinsime langą iki 20 ms, gautume vidutinį 90 tūkstančių operacijų per sekundę greitį, o piko metu – 200 tūkst. Kitaip tariant, apkrova nėra pastovi, su staigiais sprogimais. O užklausų eilė visada turi būti tvarkoma greitai.

Bet kodėl išvis susidaro eilė? Taigi, mūsų pavyzdyje daugelis vartotojų pastebėjo kainos pasikeitimą ir atitinkamai išsiuntė operacijas. Jie ateina į „Gateway“, jis juos serializuoja, nustato tam tikrą tvarką ir siunčia į tinklą. Maršrutizatoriai maišo paketus ir persiunčia juos toliau. Kieno paketas atkeliavo pirmas, tas sandoris „laimėjo“. Dėl to mainų klientai pradėjo pastebėti, kad jei ta pati operacija buvo išsiųsta iš kelių šliuzų, padidėjo tikimybė, kad ji bus greitai apdorota. Netrukus mainų robotai pradėjo bombarduoti Gateway prašymais ir kilo sandorių lavina.

Naujas evoliucijos ratas

Po išsamių bandymų ir tyrimų perėjome prie operacinės sistemos branduolio realiuoju laiku. Tam pasirinkome „RedHat Enterprise MRG Linux“, kur MRG reiškia pranešimų siuntimo realaus laiko tinklelį. Realaus laiko pataisų privalumas yra tas, kad jie optimizuoja sistemą, kad jos vykdymas būtų kuo greitesnis: visi procesai išdėliojami FIFO eilėje, branduoliai gali būti izoliuojami, jokių išstūmimų, visos operacijos apdorojamos griežta seka.

Raudona – darbas su eile įprastame branduolyje, žalia – darbas realaus laiko branduolyje.

Tačiau pasiekti mažą delsą įprastuose serveriuose nėra taip paprasta:

• SMI režimas, kuris x86 architektūroje yra darbo su svarbiais periferiniais įrenginiais pagrindas, labai trukdo. Visų rūšių aparatinės įrangos įvykių apdorojimą ir komponentų bei įrenginių valdymą programinė įranga atlieka vadinamuoju skaidriu SMI režimu, kai operacinė sistema visiškai nemato, ką programinė įranga daro. Paprastai visi pagrindiniai pardavėjai siūlo specialius programinės įrangos serverių plėtinius, kurie leidžia sumažinti SMI apdorojimo kiekį.
• Neturėtų būti jokios dinaminės procesoriaus dažnio kontrolės, tai sukelia papildomų prastovų.
• Kai failų sistemos žurnalas išplaunamas, branduolyje vyksta tam tikri procesai, dėl kurių atsiranda nenuspėjamų vėlavimų.
• Turite atkreipti dėmesį į tokius dalykus kaip CPU Affinity, Interrupt affinity, NUMA.

Turiu pasakyti, kad „Linux“ aparatinės įrangos ir branduolio nustatymo realiuoju laiku apdorojimui tema nusipelno atskiro straipsnio. Mes praleidome daug laiko eksperimentuodami ir tyrinėdami, kol pasiekėme gerą rezultatą.

Pereinant nuo PA-RISC serverių prie x86, sistemos kodo praktiškai daug keisti nereikėjo, tiesiog pritaikėme ir perkonfigūravome. Tuo pačiu metu ištaisėme keletą klaidų. Pavyzdžiui, greitai išryškėjo to, kad PA RISC buvo Big endian sistema, o x86 – Little endian sistema, pasekmės: pavyzdžiui, duomenys buvo nuskaityti neteisingai. Sudėtingesnė klaida buvo ta, kurią naudoja PA RISC nuosekliai nuosekliai (Iš eilės nuoseklus) prieiga prie atminties, o x86 gali pertvarkyti skaitymo operacijas, todėl kodas, kuris buvo visiškai galiojantis vienoje platformoje, sugedo kitoje.

Perėjus prie x86, našumas padidėjo beveik tris kartus, vidutinis operacijos apdorojimo laikas sumažėjo iki 60 μs.

Dabar atidžiau pažiūrėkime, kokie pagrindiniai sistemos architektūros pakeitimai buvo padaryti.

Karštas rezervinis epas

Pereinant prie prekių serverių, žinojome, kad jie buvo mažiau patikimi. Todėl kurdami naują architektūrą a priori manėme, kad gali sugesti vienas ar daugiau mazgų. Todėl reikėjo karšto budėjimo sistemos, kuri galėtų labai greitai pereiti prie atsarginių mašinų.

Be to, buvo keliami kiti reikalavimai:

• Jokiomis aplinkybėmis nepraraskite apdorotų operacijų.
• Sistema turi būti visiškai skaidri mūsų infrastruktūrai.
• Klientai neturėtų matyti nutrūkusių ryšių.
• Rezervacijos neturėtų sukelti didelių vėlavimų, nes tai yra esminis mainų veiksnys.

Kurdami karšto budėjimo sistemą, tokių scenarijų nelaikėme dvigubais gedimais (pavyzdžiui, tinklas viename serveryje nustojo veikti, o pagrindinis serveris užšalo); neatsižvelgė į programinės įrangos klaidų galimybę, nes jos nustatomos testavimo metu; ir neatsižvelgė į netinkamą techninės įrangos veikimą.

Dėl to priėjome prie tokios schemos:

• Pagrindinis serveris tiesiogiai bendravo su „Gateway“ serveriais.
• Visos operacijos, gautos pagrindiniame serveryje, buvo akimirksniu perkeltos į atsarginį serverį per atskirą kanalą. Arbitras (gubernatorius) koordinavo perjungimą, jei iškiltų kokių nors problemų.

  

• Pagrindinis serveris apdorojo kiekvieną operaciją ir laukė patvirtinimo iš atsarginio serverio. Kad delsa būtų kuo mažesnė, vengėme laukti, kol operacija bus baigta atsarginiame serveryje. Kadangi laikas, kurio prireikė operacijai keliauti tinkle, buvo panašus į vykdymo laiką, papildoma delsa nebuvo pridėta.
• Galėjome patikrinti tik ankstesnės operacijos pagrindinio ir atsarginio serverio apdorojimo būseną, o dabartinės operacijos apdorojimo būsena buvo nežinoma. Kadangi vis dar naudojome vienos gijos procesus, laukdami atsakymo iš atsarginės kopijos, būtų sulėtėjęs visas apdorojimo srautas, todėl padarėme pagrįstą kompromisą: patikrinome ankstesnės operacijos rezultatą.

Schema veikė taip.

Tarkime, kad pagrindinis serveris nustoja reaguoti, bet vartai ir toliau bendrauja. Atsarginiame serveryje įvyksta laikas, jis susisiekia su valdytoju, kuris jam priskiria pagrindinio serverio vaidmenį, ir visi šliuzai persijungia į naują pagrindinį serverį.

Jei pagrindinis serveris vėl prisijungia, jis taip pat suaktyvina vidinį skirtąjį laiką, nes tam tikrą laiką nebuvo skambučių į serverį iš šliuzo. Tada jis taip pat kreipiasi į gubernatorių ir pašalina jį iš schemos. Dėl to birža dirba su vienu serveriu iki prekybos laikotarpio pabaigos. Kadangi serverio gedimo tikimybė yra gana maža, ši schema buvo laikoma gana priimtina, joje nebuvo sudėtingos logikos ir buvo lengva patikrinti.

Bus tęsiama.

Šaltinis: www.habr.com