Hau Trukearen funtzionamendua bermatzen duen karga handiko sistema indartsu bat sortzeko gure bide arantzatsuari buruzko istorio luze baten jarraipena da. Lehenengo zatia hemen dago:
Akats misteriotsua
Proba ugari egin ondoren, merkataritza eta garbiketa sistema eguneratua martxan jarri zen, eta akats bat aurkitu genuen, istorio detektibe-mistiko bat idatzi genezakeenari buruz.
Zerbitzari nagusian abiarazi eta gutxira, transakzioetako bat errore batekin prozesatu zen. Hala ere, dena ondo zegoen babeskopia zerbitzarian. Zerbitzari nagusian berretzailea kalkulatzeko eragiketa matematiko sinple batek emaitza negatiboa eman zuela benetako argumentutik! Ikertzen jarraitu genuen, eta SSE2 erregistroan bit bateko aldea aurkitu genuen, hau da, biribiltzearen arduraduna koma mugikorreko zenbakiekin lan egitean.
Proba-erabilgarritasun sinple bat idatzi dugu biribilketa-bit multzoarekin berretzailea kalkulatzeko. Erabili genuen RedHat Linux-en bertsioan funtzio matematikoarekin lan egitean akats bat zegoela txertatu zenean. Honen berri eman genion RedHat-i, pixka bat igaro ondoren haiengandik adabaki bat jaso eta zabaldu genuen. Akatsa jada ez zen gertatu, baina ez zegoen argi nondik datorren bit hau? Funtzioa arduratzen zen fesetround C lengoaiatik.Gure kodea arretaz aztertu dugu ustezko akatsaren bila: egon daitezkeen egoera guztiak egiaztatu ditugu; biribilketa erabiltzen zuten funtzio guztiak aztertu zituen; saio huts bat erreproduzitzen saiatu da; aukera ezberdinekin konpilatzaile desberdinak erabili zituen; Analisi estatikoa eta dinamikoa erabili dira.
Ezin izan da aurkitu errorearen kausa.
Ondoren, hardwarea egiaztatzen hasi ziren: prozesadoreen karga probak egin zituzten; RAM egiaztatu; Are gehiago, probak egin genituen gelaxka batean bit anitzeko errore baten agertokirako. Ezertarako.
Azkenean, energia altuko fisikaren munduko teoria batean finkatu ginen: energia handiko partikula batzuk gure datu-zentrora hegan egin zuen, kaxa horma zulatu, prozesadorea jo eta abiarazlearen itxitura pixka bat itsatsita eragin zuen. Teoria absurdo honi "neutrinoa" deitzen zitzaion. Partikulen fisikatik urrun bazaude: neutrinoek ia ez dute kanpoko munduarekin elkarreragin, eta, zalantzarik gabe, ezin dute prozesadorearen funtzionamenduan eragin.
Ezinezkoa izan zenez hutsegitearen kausa aurkitu, zerbitzari "iraingarria" funtzionamendutik kendu zen badaezpada.
Denbora pixka bat igaro ondoren, babeskopia beroaren sistema hobetzen hasi ginen: "erreserba beroak" (beroa) deiturikoak sartu genituen - erreplika asinkronoak. Datu-zentro ezberdinetan egon zitezkeen transakzio-korronte bat jaso zuten, baina beroketak ez zuen aktiboki elkarreragin beste zerbitzariekin.
Zergatik egin zen hau? Babeskopia zerbitzariak huts egiten badu, zerbitzari nagusiari lotuta beroa babeskopia berri bihurtzen da. Hau da, hutsegite baten ondoren, sistema ez da zerbitzari nagusi batekin geratzen merkataritza saioa amaitu arte.
Eta sistemaren bertsio berria probatu eta martxan jarri zenean, biribilketa-bit errorea berriro gertatu zen. Gainera, zerbitzari epelen kopurua handituz gero, errorea maizago agertzen hasi zen. Aldi berean, saltzaileak ez zuen ezer erakusteko, froga zehatzik ez zegoelako.
Egoeraren hurrengo azterketan, arazoa OSarekin erlazionatuta egon zitekeen teoria bat sortu zen. Funtzio bat amaigabeko begizta batean deitzen duen programa sinple bat idatzi dugu fesetround, uneko egoera gogoratzen du eta loaren bidez egiaztatzen du, eta hori lehian dauden hari askotan egiten da. Lo egiteko parametroak eta hari-kopurua hautatuta, bitaren hutsegitea etengabe erreproduzitzen hasi ginen utilitatea exekutatzen 5 minutu inguru igaro ondoren. Hala ere, Red Hat-en laguntza ezin izan da erreproduzitu. Gure beste zerbitzarien probak frogatu du prozesadore jakin batzuk dituztenek bakarrik direla errorea jasan dezaketela. Aldi berean, kernel berri batera aldatzeak arazoa konpondu zuen. Azkenean, OS ordeztu besterik ez dugu egin, eta akatsaren benetako kausa ez zegoen argi.
Eta bat-batean iaz artikulu bat argitaratu zen HabrΓ©-n β" Bertan azaltzen den egoera gurearen oso antzekoa zen, baina egileak ikerketa aurrerago eraman zuen eta akatsa mikrokodean zegoela dioen teoria aurkeztu zuen. Eta Linux nukleoak eguneratzen direnean, fabrikatzaileek mikrokodea ere eguneratzen dute.
Sistemaren garapena gehiago
Akatsa kendu genuen arren, istorio honek sistemaren arkitektura berraztertzera behartu gaitu. Azken finean, ez geunden babestuta horrelako akatsen errepikapenetik.
Oinarri hauek izan ziren erreserba sistemaren hurrengo hobekuntzak egiteko oinarria:
- Ezin zara inorekin fidatu. Baliteke zerbitzariek behar bezala ez funtzionatzea.
- Gehiengo erreserba.
- Adostasuna bermatzea. Gehiengo erreserbaren gehigarri logiko gisa.
- Huts bikoitzak posible dira.
- Bizitasun. Egonkortasun beroko eskema berriak ez luke aurrekoa baino okerragoa izan behar. Negoziazioa etenik gabe jarraitu beharko litzateke azken zerbitzarira arte.
- Latentziaren igoera apur bat. Edozein geldialdi denborak galera ekonomiko handiak dakartza.
- Sareko interakzio minimoa latentzia ahalik eta txikiena izateko.
- Zerbitzari nagusi berri bat segundotan hautatzea.
Merkatuan zeuden irtenbideetako bat ere ez zitzaigun egokitzen, eta Raft protokoloa hastapenetan zegoen, beraz, gure irtenbidea sortu genuen.
Saregintza
Erreserba sistemaz gain, sareko interakzioa modernizatzen hasi ginen. I/O azpisistemak prozesu asko zituen, eta horrek eragin okerrena izan zuen jitter eta latentzian. TCP konexioak kudeatzen dituzten ehunka prozesurekin, haien artean etengabe aldatzera behartuta egon ginen, eta mikrosegundoko eskalan nahiko denbora eskatzen duen eragiketa da. Baina okerrena da prozesu batek prozesatzeko pakete bat jasotzen zuenean, SystemV ilara batera bidaltzen zuela eta, ondoren, beste SystemV ilara bateko gertaera baten zain geratzen zela. Hala ere, nodo kopuru handia dagoenean, prozesu batean TCP pakete berri bat iristeak eta beste batean ilaran datuak jasotzeak bi gertakari lehian adierazten ditu OSrako. Kasu honetan, bi zereginetarako prozesadore fisikorik ez badago, bat prozesatu egingo da, eta bigarrena itxaron-ilara batean jarriko da. Ezinezkoa da ondorioak aurreikustea.
Horrelako egoeretan, prozesuen lehentasunen kontrol dinamikoa erabil daiteke, baina horretarako baliabideak behar dituzten sistema-deiak erabili beharko dira. Ondorioz, hari batera aldatu ginen epoll klasikoa erabiliz, honek abiadura asko handitu zuen eta transakzioen prozesatzeko denbora murriztu zuen. Sare-komunikazio-prozesu bereiziak eta SystemV bidezko komunikazioa ere kendu genituen, sistema-deien kopurua nabarmen murriztu genuen eta eragiketen lehentasunak kontrolatzen hasi ginen. I/O azpisisteman bakarrik, 8-17 mikrosegundo inguru aurreztea posible zen, eszenatokiaren arabera. Hari bakarreko eskema hau aldatu gabe erabili da orduz geroztik; marjina duen epoll hari bat nahikoa da konexio guztiei zerbitzua emateko.
Transakzio prozesatzea
Gure sistemaren karga gero eta handiagoak ia osagai guztiak berritu behar zituen. Baina, zoritxarrez, azken urteotan prozesadorearen erloju-abiaduren hazkuntzaren geldialdiak jada ez du posible prozesuak aurrez aurre eskalatzea. Hori dela eta, Engine prozesua hiru mailatan banatzea erabaki dugu, eta haietako okupatuena arriskuak egiaztatzeko sistema izanik, kontuetan funtsen eskuragarritasuna ebaluatzen du eta beraiek eragiketak sortzen dituzte. Baina dirua moneta desberdinetan egon daiteke, eta eskaeren prozesamendua zein oinarritan banatu behar zen jakin behar zen.
Irtenbide logikoa monetaz banatzea da: zerbitzari batek dolartan negoziatzen du, beste batek libratan eta heren batek eurotan. Baina, eskema horrekin, bi transakzio bidaltzen badira moneta desberdinak erosteko, orduan zorroaren desinkronizazioaren arazoa sortuko da. Baina sinkronizazioa zaila eta garestia da. Hori dela eta, zuzena izango litzateke zorroen bidez bereizita zatitzea eta instrumentuen arabera bereizita. Bide batez, Mendebaldeko truke gehienek ez dute arriskuak guk bezain zorrotz egiaztatzeko zeregina, beraz, gehienetan lineaz kanpo egiten da. Lineako egiaztapena ezarri behar genuen.
Azal dezagun adibide batekin. Dendari batek 30 $ erosi nahi ditu, eta eskaera transakzioen baliozkotzera doa: dendari honek merkataritza modu honetara onartzen duen eta beharrezko eskubideak dituen egiaztatzen dugu. Dena ondo badago, eskaera arriskuak egiaztatzeko sistemara doa, hau da. transakzio bat egiteko funtsen nahikoa egiaztatzeko. Beharrezko zenbatekoa blokeatuta dagoela dioen ohar bat dago. Ondoren, eskaera merkataritza sistemara bidaltzen da, eta horrek transakzioa onartzen edo gaitzetsi egiten du. Demagun transakzioa onartzen dela; orduan arriskua egiaztatzeko sistemak dirua desblokeatua dela adierazten du eta errubloak dolar bihurtzen dira.
Oro har, arriskuak egiaztatzeko sistemak algoritmo konplexuak ditu eta baliabide asko erabiltzen dituzten kalkulu ugari egiten ditu, eta ez du "kontuaren saldoa" besterik gabe egiaztatzen, lehen begiratuan badirudi bezala.
Engine prozesua mailatan banatzen hasi ginenean, arazo bat topatu genuen: une hartan eskuragarri zegoen kodeak aktiboki erabiltzen zuen datu-sorta bera baliozkotze- eta egiaztapen-fasetan, eta horrek kode-oinarri osoa berridaztea eskatzen zuen. Ondorioz, prozesadore modernoetatik instrukzioak prozesatzeko teknika bat maileguan hartu dugu: horietako bakoitza etapa txikietan banatzen da eta hainbat ekintza paraleloki egiten dira ziklo batean.
Kodearen egokitzapen txiki baten ondoren, transakzio paraleloen prozesamendurako kanalizazio bat sortu genuen, zeinetan transakzioa kanalizazioko 4 fasetan banatu zen: sareko elkarrekintza, baliozkotzea, exekuzioa eta emaitzaren argitalpena.
Ikus dezagun adibide bat. Bi prozesatzeko sistema ditugu, seriea eta paraleloa. Lehenengo transakzioa iristen da eta bi sistemetan baliozkotzeko bidaltzen da. Bigarren transakzioa berehala iristen da: sistema paralelo batean berehala eramaten da lanera, eta sistema sekuentzial batean ilaran jartzen da lehen transakzioa uneko prozesatze-fasea igaro arte. Hau da, kanalizazioaren prozesamenduaren abantaila nagusia transakzio-ilara azkarrago prozesatzen dugula da.
Horrela sortu genuen ASTS+ sistema.
Egia da, dena ez da hain leuna zintekin ere. Demagun aldameneko transakzio batean datu-matrizei eragiten dien transakzio bat dugula; hau truke baterako egoera arrunta da. Horrelako transakzio bat ezin da kanalizazio batean exekutatu, besteengan eragina izan dezakeelako. Egoera horri datu-arriskua deitzen zaio, eta transakzio horiek banan-banan prozesatzen dira: ilaran dauden transakzio "azkarrak" amaitzen direnean, kanalizazioa gelditzen da, sistemak transakzio "motela" prozesatzen du eta, ondoren, kanalizazioa berriro hasten da. Zorionez, transakzio horien proportzioa fluxu orokorrean oso txikia da, beraz, kanalizazioa hain gutxitan gelditzen da, non errendimendu orokorrean eragiten ez duen.
Ondoren, hiru exekuzio hari sinkronizatzeko arazoa konpontzen hasi ginen. Emaitza tamaina finkoko zelulak dituen eraztun-buffer batean oinarritutako sistema bat izan zen. Sistema honetan, dena prozesatzeko abiaduraren menpe dago; datuak ez dira kopiatzen.
- Sarrerako sare-pakete guztiak esleipen-fasean sartzen dira.
- Array batean jartzen ditugu eta #1 faserako erabilgarri gisa markatzen ditugu.
- Bigarren transakzioa iritsi da, berriro ere eskuragarri dago 1. etaparako.
- Lehen prozesatzeko hariak eskuragarri dauden transakzioak ikusten ditu, prozesatzen ditu eta bigarren prozesatzeko hariaren hurrengo fasera eramaten ditu.
- Ondoren, lehenengo transakzioa prozesatzen du eta dagokion gelaxka markatzen du
deletedβ Orain erabilgarri dago erabilera berrietarako.
Modu honetan prozesatzen da ilara osoa.
Etapa bakoitzaren prozesamenduak unitateak edo hamarnaka mikrosegundoak behar ditu. Eta OS sinkronizazio-eskema estandarrak erabiltzen baditugu, denbora gehiago galduko dugu sinkronizazioan bertan. Horregatik hasi ginen spinlock erabiltzen. Hala ere, oso txarra da denbora errealeko sistema batean, eta RedHat-ek ez du gomendatzen zorrozki hori egitea, beraz, 100 ms-ko spin-blokeoa aplikatzen dugu eta, ondoren, semaforo modura aldatzen dugu blokeo-blokeoaren aukera kentzeko.
Ondorioz, segundoko 8 milioi transakzio inguruko errendimendua lortu genuen. Eta literalki bi hilabete geroago LMAX Disruptor-i buruz funtzionaltasun bera duen zirkuitu baten deskribapena ikusi dugu.
Orain hainbat exekuzio-hari egon litezke etapa batean. Transakzio guztiak banan-banan prozesatu ziren, jaso ziren ordenan. Ondorioz, errendimendu gorena segundoko 18 mila transakziotik 50 mila izatera pasa zen.
Truke-arriskuak kudeatzeko sistema
Ez dago perfekzioaren mugarik, eta handik gutxira berriz ere modernizazioari ekin genion: ASTS+-ren esparruan, arriskuak kudeatzeko eta likidatzeko eragiketen sistemak osagai autonomoetara eramaten hasi ginen. Arkitektura moderno malgu bat eta arrisku-eredu hierarkiko berri bat garatu genituen, eta klasea ahal zen guztietan erabiltzen saiatu ginen fixed_point ordez double.
Baina berehala sortu zen arazo bat: nola sinkronizatu urte askotan lanean egon den negozio-logika guztia eta nola transferitu sistema berrira? Ondorioz, sistema berriaren prototipoaren lehen bertsioa alde batera utzi behar izan zen. Bigarren bertsioa, gaur egun ekoizpenean lanean ari dena, kode berean oinarritzen da, eta merkataritza eta arrisku zatietan lan egiten du. Garapenean zehar, zailena bi bertsioren artean git bateratzea izan zen. Gure lankide Evgeniy Mazurenok astero egiten zuen ebakuntza hau eta aldi bakoitzean madarikatu egiten zuen denbora luzez.
Sistema berri bat hautatzerakoan, berehala konpondu behar izan dugu elkarrekintzaren arazoa. Datu-busa aukeratzerakoan, jitter egonkorra eta gutxieneko latentzia bermatu behar zen. InfiniBand RDMA sarea zen horretarako egokiena: batez besteko prozesatzeko denbora 4 G Ethernet sareetan baino 10 aldiz txikiagoa da. Baina benetan liluratu gintuena pertzentileen aldea izan zen: 99 eta 99,9.
Jakina, InfiniBand-ek baditu bere erronkak. Lehenik eta behin, API ezberdin bat - ibverbs socketen ordez. Bigarrenik, ez dago ia kode irekiko mezularitza-irtenbide oso erabilgarririk. Gure prototipoa egiten saiatu ginen, baina oso zaila izan zen eta, beraz, irtenbide komertziala aukeratu genuen: Confinity Low Latency Messaging (lehen IBM MQ LLM).
Orduan sortu zen arrisku-sistema behar bezala banatzeko zeregina. Risk Engine-a kentzen baduzu eta tarteko nodorik sortzen ez baduzu, bi iturritako transakzioak nahas daitezke.
Latentzia Ultra Baxua deritzon soluzioek berrantolatzeko modua dute: bi iturritako transakzioak behar den ordenan antola daitezke jasotzean; hau eskaerari buruzko informazioa trukatzeko kanal bereizi bat erabiliz gauzatzen da. Baina oraindik ez dugu modu hau erabiltzen: prozesu osoa zailtzen du, eta hainbat irtenbidetan ez da batere onartzen. Gainera, transakzio bakoitzari dagozkion denbora-zigiluak esleitu beharko litzaizkioke, eta gure eskeman mekanismo hori oso zaila da behar bezala ezartzea. Horregatik, eskema klasikoa erabili dugu mezu-artekari batekin, hau da, Risk Engine-ren artean mezuak banatzen dituen bidaltzaile batekin.
Bigarren arazoa bezeroen sarbidearekin erlazionatuta zegoen: Arrisku atebide batzuk badaude, bezeroak horietako bakoitzarekin konektatu behar du, eta horretarako bezero geruzan aldaketak beharko dira. Fase honetan honetatik aldendu nahi genuen, beraz, egungo Risk Gateway diseinuak datu-korronte osoa prozesatzen du. Horrek asko mugatzen du gehienezko errendimendua, baina asko errazten du sistemaren integrazioa.
bikoizketa
Gure sistemak ez luke huts puntu bakar bat izan behar, hau da, osagai guztiak bikoiztu behar dira, mezuen bitartekaria barne. CLLM sistema erabiliz konpondu dugu arazo hau: RCMS kluster bat dauka eta bertan bi bidaltzaileek maisu-esklabo moduan lan egin dezakete, eta batek huts egiten duenean, sistema automatikoki bestera aldatzen da.
Babeskopiako datu-zentro batekin lan egitea
InfiniBand sare lokal gisa funtzionatzeko optimizatuta dago, hau da, rack muntatzeko ekipoak konektatzeko, eta InfiniBand sare bat ezin da geografikoki banatutako bi datu-zentroren artean ezarri. Hori dela eta, zubi/bidaltzaile bat ezarri dugu, mezuen biltegiratzearekin konektatzen dena Ethernet sare arrunten bidez eta transakzio guztiak bigarren IB sare batera transmititzen dituena. Datu-zentro batetik migratu behar dugunean, zein datu-zentrorekin lan egin nahi dugun aukera dezakegu orain.
Emaitzak
Aurreko guztia ez zen aldi berean egin; hainbat iterazio behar izan ziren arkitektura berri bat garatzeko. Prototipoa hilabete batean sortu genuen, baina bi urte baino gehiago behar izan ziren funtzionatzeko. Transakzioen prozesatzeko denbora handitzearen eta sistemaren fidagarritasuna handitzearen arteko konpromisorik onena lortzen saiatu gara.
Sistema asko eguneratu zenez, bi iturri independentetatik datuak berreskuratzea ezarri genuen. Arrazoiren batengatik mezuen biltegia ez bada behar bezala funtzionatzen, bigarren iturri batetik hartu dezakezu transakzioen erregistroa - Risk Engine-tik. Printzipio hori sistema osoan betetzen da.
Besteak beste, bezeroaren APIa gorde ahal izan dugu, ez artekariek ez beste inork arkitektura berrirako birlanketa esanguratsurik eskatuko ez zedin. Interfaze batzuk aldatu behar izan genituen, baina ez zegoen eredu eragilean aldaketa nabarmenik egin beharrik.
Gure plataformaren egungo bertsioari Rebus deitu diogu, arkitekturako bi berrikuntza nabarmenen laburdura gisa, Risk Engine eta BUS.
Hasieran, garbiketa zatia bakarrik esleitu nahi genuen, baina emaitza sistema banatu handia izan zen. Bezeroek Merkataritza Gateway, Clearing Gateway edo biekin elkarreragin dezakete orain.
Azkenean lortu duguna:
Latentzia maila murriztu da. Transakzio bolumen txiki batekin, sistemak aurreko bertsioaren berdin funtzionatzen du, baina aldi berean karga askoz handiagoa jasan dezake.
Errendimendu gorena segundoko 50 mila transakziotik 180 mila transakziora igo da. Beste igoera bat oztopatzen du eskaerak parekatzeko jario bakarrak.
Gehiago hobetzeko bi modu daude: parekatzea paralelotzea eta Gateway-rekin lan egiteko modua aldatzea. Orain Gateway guztiek erreplikazio-eskema baten arabera funtzionatzen dute, eta horrek, karga horren pean, normal funtzionatzeari uzten dio.
Azkenik, aholku batzuk eman ditzaket enpresa-sistemak amaitzen ari direnei:
- Presta zaitez uneoro txarrenerako. Arazoak beti sortzen dira ustekabean.
- Normalean ezinezkoa da arkitektura azkar berregitea. Batez ere, hainbat adierazletan fidagarritasun handiena lortu behar baduzu. Zenbat eta nodo gehiago, orduan eta baliabide gehiago behar dira laguntzarako.
- Soluzio pertsonalizatu eta jabedun guztiek baliabide osagarriak beharko dituzte ikerketarako, laguntzarako eta mantentze-lanetarako.
- Ez atzeratu sistemaren fidagarritasunari eta berreskurapenari buruzko arazoak konpontzea hutsegiteen ondoren; kontuan izan itzazu hasierako diseinu-fasean.
Iturria: www.habr.com