Moskuko Burtsaren merkataritza eta konpentsazio sistemaren arkitekturaren bilakaera. 1. zatia

Kaixo guztioi! Nire izena Sergey Kostanbaev da, Exchange-n merkataritza-sistemaren muina garatzen ari naiz.

Hollywoodeko filmek New Yorkeko Burtsa erakusten dutenean, beti itxura hau ematen du: jende andana, denak zerbait oihukatzen ari da, paperak astintzen, kaosa osoa gertatzen ari da. Hau ez da inoiz gertatu hemen Moskuko Burtsan, merkataritza hasiera-hasieratik modu elektronikoan egin delako eta bi plataforma nagusitan oinarritzen delako: Spectra (forex merkatua) eta ASTS (dibisa, balore eta diru merkatua). Eta gaur ASTS merkataritza eta konpentsazio sistemaren arkitekturaren bilakaerari buruz hitz egin nahi dut, hainbat irtenbide eta aurkikuntzari buruz. Istorioa luzea izango da, beraz, bi zatitan banatu behar izan nuen.

Klase guztietako aktiboak negoziatzen dituen eta truke-zerbitzu sorta osoa eskaintzen duen munduko truke gutxietako bat gara. Esaterako, iaz munduko bigarren postuan kokatu ginen bonuen salerosketa bolumenari dagokionez, 25. postua burtsa guztien artean, 13. postua burtsa publikoen artean kapitalizazioan.

Merkataritza parte-hartzaile profesionalentzat, erantzun denbora, denbora banaketaren egonkortasuna (jitter) eta konplexu osoaren fidagarritasuna bezalako parametroak funtsezkoak dira. Gaur egun, egunero hamar milioi transakzio prozesatzen ditugu. Sistema kernelaren transakzio bakoitzaren prozesatzeak hamarnaka mikrosegundo behar ditu. Noski, mugikor-operadoreek edo bilatzaileek beraiek gurea baino lan karga handiagoa dute, baina lan kargari dagokionez, aipatutako ezaugarriekin batera, gutxi dira gurekin konparatu, iruditzen zait. Aldi berean, garrantzitsua da guretzat sistema segundo batean moteltzea, erabat egonkorra dabilela eta erabiltzaile guztiak berdin-berdin egotea.

Historia pixka bat

1994an, Australiako ASTS sistema martxan jarri zen Moskuko Banku Arteko Moneta Trukean (MICEX), eta une horretatik aurrera Errusiako merkataritza elektronikoaren historia zenbatu daiteke. 1998an, truke-arkitektura modernizatu zen Interneteko merkataritza sartzeko. Harrezkero, sistema eta azpisistema guztietan soluzio berrien eta aldaketa arkitektonikoak ezartzeko abiadurak indarra hartu besterik ez du egin.

Urte haietan, truke sistemak goi-end hardwarean funtzionatzen zuen: HP Superdome 9000 zerbitzari oso fidagarriak PA-RISC), zeinetan erabat bikoiztuta zegoen: sarrera/irteera azpisistemak, sarea, RAM (izan ere, RAM RAID array bat zegoen), prozesadoreak (beroan trukatzekoak). Edozein zerbitzari osagai aldatzea posible zen makina gelditu gabe. Gailu horietan oinarritu ginen eta ia hutsegite-segurutzat jotzen genituen. Sistema eragilea Unix antzeko HP UX sistema bat zen.

Baina 2010. urteaz geroztik, maiztasun altuko merkataritza (HFT) edo maiztasun handiko merkataritza izeneko fenomeno bat sortu da, hots, burtsako robotak. 2,5 urtetan, gure zerbitzarietako karga 140 aldiz handitu da.

Ezinezkoa zen arkitektura eta ekipamendu zaharrekin horrelako kargari eustea. Nolabait moldatu beharra zegoen.

Начало

Truke sistemarako eskaerak bi motatan bana daitezke:

• Transakzioak. Dolarrak, akzioak edo beste zerbait erosi nahi badituzu, transakzio bat bidaltzen duzu merkataritza sistemara eta arrakastari buruzko erantzuna jasoko duzu.
• Informazio eskaerak. Uneko prezioa ezagutu nahi baduzu, ikusi eskaera-liburua edo indizeak, eta bidali informazio eskaerak.

Eskematikoki, sistemaren muina hiru mailatan bana daiteke:

• Bezeroen maila, zeinetan lan egiten duten artekariek eta bezeroek. Guztiak sarbide-zerbitzariekin elkarreragiten dute.
• Gateway zerbitzariak informazio eskaera guztiak lokalean prozesatzen dituzten cachean gordetzeko zerbitzariak dira. Sberbanken akzioen prezioa zein preziotan saltzen diren jakin nahi duzu? Eskaera sarbide zerbitzarira doa.
• Baina akzioak erosi nahi badituzu, eskaera zerbitzari zentralera doa (Trade Engine). Merkatu mota bakoitzerako halako zerbitzari bat dago, ezinbesteko zeregina dute, beraientzat sortu dugu sistema hau.

Negoziazio sistemaren muina memoriako datu-base adimentsu bat da, non transakzio guztiak truke-transakzioak diren. Oinarria C-n idatzi zen, kanpoko menpekotasun bakarrak libc liburutegia ziren eta ez zegoen memoria dinamikoko esleipenik. Prozesatzeko denbora murrizteko, sistema matrize-multzo estatiko batekin eta datu-deslokalizazio estatikoarekin hasten da: lehenik eta behin, egungo eguneko datu guztiak memorian kargatzen dira, eta ez da diskorako sarbide gehiagorik egiten, lan guztiak memorian bakarrik egiten dira. Sistema abiarazten denean, erreferentziako datu guztiak ordenatuta daude dagoeneko, beraz, bilaketak oso modu eraginkorrean funtzionatzen du eta denbora gutxi behar du exekuzioan. Taula guztiak datu-egitura dinamikoetarako zerrenda eta zuhaitz intrusiboekin egiten dira, exekuzio garaian memoria esleipenik behar ez izateko.

Goazen laburki gure merkataritza eta konpentsazio sistemaren garapenaren historia.
Negoziazio eta garbiketa sistemaren arkitekturaren lehen bertsioa Unix interakzioa deiturikoan eraiki zen: memoria partekatua, semaforoak eta ilarak erabiltzen ziren, eta prozesu bakoitza hari bakar batez osatuta zegoen. Ikuspegi hori 1990eko hamarkadaren hasieran zabaldu zen.

Sistemaren lehen bertsioak Gateway-ren bi maila eta merkataritza-sistemaren zerbitzari zentrala zituen. Lanaren fluxua honelakoa izan zen:

• Bezeroak eskaera bat bidaltzen du, Gatewayra iristen dena. Formatuaren baliozkotasuna egiaztatzen du (baina ez datuak berak) eta transakzio okerrak baztertzen ditu.
• Informazio eskaera bat bidali bada, lokalean exekutatzen da; transakzio bati buruz ari bagara, zerbitzari zentralera birbideratzen da.
• Merkataritza-motorrak transakzioa prozesatzen du, memoria lokala aldatzen du eta erantzun bat bidaltzen dio transakzioari eta transakzioari berari erreplikatzeko, bereizitako erreplikazio-motor bat erabiliz.
• Gateway-k erantzuna nodo zentraletik jasotzen du eta bezeroari bidaltzen dio.
• Denbora pixka bat igaro ondoren, Gateway-k transakzioa jasotzen du erreplikazio-mekanismoaren bidez, eta oraingoan lokalean exekutatzen du, bere datu-egiturak aldatuz, hurrengo informazio-eskaerek azken datuak bistaratzeko.

Izan ere, erreplikazio-eredu bat deskribatzen du, non Gateway-k merkataritza-sisteman egindako ekintzak guztiz errepikatu zituen. Erreplikazio-kanal bereizi batek transakzioak hainbat sarbide-nodotan ordena berean exekutatzen zirela bermatzen zuen.

Kodea hari bakarrekoa zenez, prozesu-sardexkak dituen eskema klasiko bat erabili zen bezero asko zerbitzatzeko. Hala ere, datu-base osoa bifurkatzea oso garestia zen, beraz, zerbitzu-prozesu arinak erabili ziren TCP saioetako paketeak bildu eta ilara batera transferitzen zituztenak (SystemV Message Queue). Gateway-k eta Trade Engine-ek ilara honekin bakarrik funtzionatzen zuten, handik transakzioak exekutatzeko hartuz. Jada ezin zen hari erantzunik bidali, ez zegoelako argi zein zerbitzu-prozesu irakurri behar zuen. Beraz, trikimailu batera jo genuen: bifurkatutako prozesu bakoitzak erantzun-ilara bat sortzen zuen beretzat, eta eskaera bat sarrerako ilaran sartzen zenean, erantzun-ilararen etiketa bat gehitzen zitzaion berehala.

Ilaraz ilara datu kopuru handiak etengabe kopiatzeak arazoak sortu zituen, batez ere informazio-eskaeretarako ohikoak. Horregatik, beste trikimailu bat erabili dugu: erantzun-ilaraz gain, prozesu bakoitzak memoria partekatua ere sortzen du (SystemV Shared Memory). Paketeak berak jartzen ziren bertan, eta ilaran etiketa bat bakarrik gordetzen zen, jatorrizko paketea aurkitzeko aukera emanez. Horrek prozesadorearen cachean datuak gordetzen lagundu zuen.

SystemV IPC-k ilararen, memoriaren eta semaforo-objektuen egoera ikusteko utilitateak ditu. Momentu jakin batean sisteman zer gertatzen ari zen, paketeak non pilatzen ziren, zer blokeatzen zen, etab.

Lehen modernizazioak

Lehenik eta behin, prozesu bakarreko Gateway-a kendu genuen. Bere eragozpen esanguratsua zen erreplika transakzio bat edo bezero baten informazio eskaera bat kudeatu zezakeela. Eta karga handitzen den heinean, Gateway-k denbora gehiago beharko du eskaerak prozesatzeko eta ezin izango du erreplikazio-fluxua prozesatu. Horrez gain, bezeroak transakzio bat bidali badu, haren baliozkotasuna egiaztatu eta gehiago bidali besterik ez duzu egin behar. Hori dela eta, Gateway prozesu bakarra paraleloan exekutatu daitezkeen hainbat osagairekin ordezkatu dugu: hari anitzeko informazioa eta transakzio-prozesuak elkarrengandik independentean exekutatzen diren memoria-eremu partekatu batean RW blokeoa erabiliz. Eta, aldi berean, bidalketa eta erreplikazio prozesuak sartu genituen.

Maiztasun handiko merkataritzaren eragina

Goiko arkitekturaren bertsioa 2010era arte egon zen. Bien bitartean, jada ez ginen pozik HP Superdome zerbitzarien errendimenduarekin. Gainera, PA-RISC arkitektura ia hilda zegoen; saltzaileak ez zuen eguneratze garrantzitsurik eskaini. Ondorioz, HP UX/PA RISC-tik Linux/x86ra pasatzen hasi ginen. Trantsizioa sarbide-zerbitzarien egokitzapenarekin hasi zen.

Zergatik aldatu behar izan dugu berriro arkitektura? Izan ere, maiztasun handiko merkataritzak nabarmen aldatu du sistemaren nukleoko karga-profila.

Demagun prezio aldaketa nabarmena eragin duen transakzio txiki bat dugula: norbaitek milioi erdi dolar erosi zituen. Pare bat milisegundoren buruan, merkatuko parte-hartzaile guztiak hori nabaritu eta zuzenketa bat egiten hasten dira. Jakina, eskaerak ilara handi batean sartzen dira, eta sistemak denbora luzea beharko du garbitzeko.

50 ms-ko tarte horretan, batez besteko abiadura segundoko 16 mila transakzio ingurukoa da. Leihoa 20 ms-ra murrizten badugu, 90 mila transakzio segundoko batez besteko abiadura lortzen dugu, 200 mila transakzio gailurrean. Beste era batera esanda, karga ez da konstantea, bat-bateko eztandarekin. Eta eskaera-ilara beti azkar prozesatu behar da.

Baina zergatik dago ilara bat? Beraz, gure adibidean, erabiltzaile askok prezio aldaketa nabaritu zuten eta horren arabera bidali zituzten transakzioak. Gatewayra etortzen dira, serializatzen ditu, ordena jakin bat ezartzen du eta sarera bidaltzen ditu. Bideratzaileek paketeak nahasten dituzte eta bidaltzen dituzte. Noren paketea iritsi zen lehen, transakzio horrek "irabazi". Ondorioz, truke-bezeroak konturatzen hasi ziren transakzio bera hainbat atebideetatik bidaltzen bazen, orduan prozesatzeko aukerak handitu egiten zirela. Laster, truke-robotak Gateway eskaerarekin bonbardatzen hasi ziren, eta transakzio-jausi bat sortu zen.

Eboluzio txanda berri bat

Proba eta ikerketa ugari egin ondoren, denbora errealeko sistema eragilearen nukleora aldatu ginen. Horretarako RedHat Enterprise MRG Linux aukeratu dugu, non MRG mezularitza denbora errealeko sareta adierazten duen. Denbora errealeko adabakien abantaila sistema ahalik eta azkarren exekutatzeko optimizatzen dutela da: prozesu guztiak FIFO ilara batean lerrokatuta daude, nukleoak isolatu daitezke, kanporatzerik ez, transakzio guztiak sekuentzia zorrotzean prozesatzen dira.

Gorria - kernel arrunt batean ilara batekin lan egitea, berdea - denbora errealeko kernel batean lan egitea.

Baina ohiko zerbitzarietan latentzia baxua lortzea ez da hain erraza:

• SMI moduak, x86 arkitekturan periferiko garrantzitsuekin lan egiteko oinarria dena, asko oztopatzen du. Era guztietako hardware-gertaerak prozesatzea eta osagai eta gailuen kudeaketa firmwareak SMI gardena deritzon moduan egiten du, zeinetan sistema eragileak ez du ikusten firmwareak zer egiten duen. Oro har, hornitzaile nagusi guztiek firmware zerbitzarietarako luzapen bereziak eskaintzen dituzte, SMI prozesatzeko kopurua murrizteko aukera ematen dutenak.
• Ez luke prozesadorearen maiztasunaren kontrol dinamikorik egon behar, honek geldialdi gehigarria dakar.
• Fitxategi-sistemaren erregistroa garbitzen denean, prozesu jakin batzuk gertatzen dira nukleoan, ezusteko atzerapenak eragiten dituztenak.
• CPU Affinity, Interrupt afinity, NUMA bezalako gauzei arreta jarri behar diezu.

Esan behar dut Linux hardwarea eta nukleoa denbora errealean prozesatzeko konfigurazioaren gaiak aparteko artikulu bat merezi duela. Emaitza ona lortu aurretik denbora asko eman genuen esperimentatzen eta ikertzen.

PA-RISC zerbitzarietatik x86ra pasatzean, ia ez genuen sistemaren kodea asko aldatu behar izan, egokitu eta birkonfiguratu genuen. Aldi berean, hainbat akats konpondu ditugu. Esaterako, azkar azaleratu ziren PA RISC Big endian sistema eta x86 Little endian sistema izatearen ondorioak: adibidez, datuak gaizki irakurri ziren. Akats korapilatsuena PA RISC-k erabiltzen duena izan zen koherentziaz koherentea (Sekuentzialki koherentea) memoria sarbidea, x86-k irakurketa eragiketak berrantola ditzake, beraz, plataforma batean guztiz baliozkoa zen kodea beste batean hautsi zen.

X86ra aldatu ondoren, errendimendua ia hiru aldiz handitu zen, batez besteko transakzioen prozesatzeko denbora 60 μs-ra jaitsi zen.

Ikus dezagun orain sistemaren arkitekturan zer aldaketa funtsezko egin diren.

Erreserba epopeia beroa

Salgaien zerbitzarietara aldatzean, fidagarriak ez zirela jabetu ginen. Hori dela eta, arkitektura berri bat sortzean, a priori nodo baten edo gehiagoren hutsegitearen aukera bere gain hartu genuen. Hori dela eta, babeskopia-makinetara oso azkar alda zitekeen sistema beroa behar zen.

Horrez gain, beste baldintza batzuk zeuden:

• Inolaz ere ez dituzu prozesatutako transakzioak galdu behar.
• Sistemak erabat gardena izan behar du gure azpiegituretarako.
• Bezeroek ez lukete eroritako konexioak ikusi behar.
• Erreserbak ez luke atzerapen handirik sartu behar trukerako faktore kritikoa delako.

Erreserba beroko sistema bat sortzean, ez genituen horrelako eszenatokiak huts bikoitztzat hartu (adibidez, zerbitzari bateko sarea funtzionatzeari utzi eta zerbitzari nagusia izoztu zen); ez du kontuan hartu softwarean akatsak izateko aukera, proban identifikatzen direlako; eta ez zuen kontuan hartu hardwarearen funtzionamendu okerra.

Ondorioz, eskema honetara iritsi ginen:

• Zerbitzari nagusiak zuzenean elkarreragin zuen Gateway zerbitzariekin.
• Zerbitzari nagusian jasotako transakzio guztiak berehala erreplikatu ziren babeskopia zerbitzarian kanal bereizi baten bidez. Arbitroak (Gobernadoreak) aldaketaren bat koordinatu zuen, arazorik sortuz gero.

  

• Zerbitzari nagusiak transakzio bakoitza prozesatu zuen eta babeskopia zerbitzariaren baieztapenaren zain egon zen. Latentzia minimoa izan dadin, transakzioa bete arte itxarotea saihestu dugu babeskopia zerbitzarian. Transakzio batek sarean zehar bidaiatzeko behar zuen denbora exekuzio denboraren parekoa zenez, ez zen latentzia gehigarririk gehitu.
• Aurreko transakziorako zerbitzari nagusien eta babeskopien prozesatze-egoera soilik egiaztatu ahal izan dugu, eta uneko transakzioaren prozesatze-egoera ezezaguna zen. Oraindik hari bakarreko prozesuak erabiltzen ari ginenez, Backup-en erantzunaren zain egoteak prozesatzeko fluxu osoa moteldu egingo zuen, beraz, arrazoizko konpromisoa hartu genuen: aurreko transakzioaren emaitza egiaztatu genuen.

Eskemak honela funtzionatu zuen.

Demagun zerbitzari nagusiak erantzuteari uzten diola, baina atebideek komunikatzen jarraitzen dute. Babeskopia zerbitzarian denbora-muga bat gertatzen da, Gobernadorearekin harremanetan jartzen da, honek zerbitzari nagusiaren rola esleitzen dion eta Gateway guztiak zerbitzari nagusi berrira aldatzen dira.

Zerbitzari nagusia sarera itzultzen bada, barneko denbora-muga ere abiarazten du, zerbitzariari ez zaiolako deirik egon Gatewaytik denbora jakin batean. Gero, Gobernadorearengana ere jotzen du, eta eskematik kanpo uzten du. Ondorioz, trukeak zerbitzari batekin funtzionatzen du merkataritza-aldiaren amaiera arte. Zerbitzariaren hutsegite probabilitatea nahiko baxua denez, eskema hau nahiko onargarria izan zen; ez zuen logika konplexurik eta probatzeko erraza zen.

Jarraitu behar da.

Iturria: www.habr.com