Kaader filmist “Meie salajane universum: raku varjatud elu”

Investeerimisäri on pangandusmaailmas üks keerulisemaid valdkondi, sest seal pole mitte ainult laenud, laenud ja hoiused, vaid ka väärtpaberid, valuutad, toorained, tuletisväärtpaberid ja kõikvõimalik keerukus struktureeritud toodete näol.

Viimasel ajal oleme näinud elanikkonna finantskirjaoskuse tõusu. Üha rohkem inimesi hakkab tegelema väärtpaberiturgudel kauplemisega. Individuaalsed investeerimiskontod ilmusid mitte nii kaua aega tagasi. Need võimaldavad teil kaubelda väärtpaberiturgudel ja saada maksusoodustusi või vältida maksude tasumist. Ja kõik meie juurde tulevad kliendid soovivad hallata oma portfelli ja näha aruandlust reaalajas. Pealegi on see portfell enamasti mitme tootega, st inimesed on erinevate ärivaldkondade kliendid.

Lisaks kasvavad nii Venemaa kui ka välismaiste regulaatorite vajadused.

Praeguste vajaduste rahuldamiseks ja tulevastele uuendustele aluse panemiseks oleme välja töötanud Tarantoolil põhineva investeerimistegevuse tuuma.

Natuke statistikat. Alfa-Pank investeerimisäri pakub maaklerteenuseid eraisikutele ja juriidilistele isikutele, et pakkuda võimalust kaubelda erinevatel väärtpaberiturgudel, depooteenuseid väärtpaberite hoidmiseks, usaldushaldusteenuseid era- ja suurkapitaliga eraisikutele, väärtpaberite emiteerimise teenuseid teistele ettevõtetele. . Alfa-Banki investeerimisäri hõlmab üle 3 tuhande noteeringu sekundis, mis laaditakse alla erinevatelt kauplemisplatvormidelt. Tööpäeva jooksul tehakse turgudel panga või tema klientide nimel üle 300 tuhande tehingu. Välis- ja siseplatvormidel toimub kuni 5 tuhat tellimuse täitmist sekundis. Samal ajal soovivad kõik kliendid, nii ettevõttesisesed kui ka välised, näha oma positsioone reaalajas.

eelajalugu

Kuskil 2000. aastate algusest arenesid meie investeerimisäri valdkonnad iseseisvalt: börsikauplemine, maaklerteenused, valuutakauplemine, väärtpaberite ja erinevate tuletisinstrumentidega kauplemine börsiväliselt. Selle tulemusena oleme sattunud funktsionaalsete kaevude lõksu. Mis see on? Igal ärivaldkonnal on oma süsteemid, mis dubleerivad üksteise funktsioone. Igal süsteemil on oma andmemudel, kuigi nad töötavad samade mõistetega: tehingud, instrumendid, vastaspooled, noteeringud jne. Ja kui iga süsteem arenes iseseisvalt, tekkis mitmekesine tehnoloogiate loomaaed.

Lisaks on süsteemide koodibaas juba üsna vananenud, sest osa tooteid on pärit 1990. aastate keskpaigast. Ja mõnes valdkonnas aeglustas see arendusprotsessi ja esines jõudlusprobleeme.

Nõuded uuele lahendusele

Ettevõtted on mõistnud, et tehnoloogiline ümberkujundamine on edasise arengu jaoks ülioluline. Meile anti ülesanded:

1. Koguge kõik äriandmed ühte kiiresse salvestusruumi ja ühte andmemudelisse.
2. Me ei tohi seda teavet kaotada ega muuta.
3. Andmeid on vaja versioonida, sest igal hetkel võib regulaator küsida eelmiste aastate statistikat.
4. Me ei pea lihtsalt tooma uusi, moekaid DBMS-e, vaid looma platvormi äriprobleemide lahendamiseks.

Lisaks seavad meie arhitektid oma tingimused:

1. Uus lahendus peab olema ettevõtlusklassi ehk mõnes suurettevõttes juba katsetatud.
2. Lahenduse töörežiim peaks olema missioonikriitiline. See tähendab, et peame olema korraga kohal mitmes andmekeskuses ja rahulikult üle elama ühe andmekeskuse katkemise.
3. Süsteem peab olema horisontaalselt skaleeritav. Fakt on see, et kõik meie praegused süsteemid on ainult vertikaalselt skaleeritavad ja riistvara võimsuse vähese kasvu tõttu oleme juba lakke löömas. Seetõttu on saabunud hetk, mil meil on ellujäämiseks vaja horisontaalselt skaleeritavat süsteemi.
4. Muuhulgas öeldi meile, et lahendus peab olema odav.

Läksime standardmarsruuti: sõnastasime nõuded ja võtsime ühendust ostuosakonnaga. Sealt saime nimekirja ettevõtetest, kes üldiselt on valmis seda meie eest tegema. Rääkisime probleemist kõigile ja saime lahendustele hinnangu kuuelt.

Pangas ei võta me kellegi sõna, meile meeldib kõike ise katsetada. Seetõttu oli meie hankekonkursi kohustuslik tingimus koormustestide läbimine. Sõnastasime koormustesti ülesanded ja kolm ettevõtet kuuest on juba nõustunud omal kulul kasutusele võtma mälusiseste tehnoloogiate prototüüplahenduse, et seda testida.

Ma ei räägi teile, kuidas me kõike testisime ja kui kaua see aega võttis, vaid võtan kokku: parimat jõudlust koormustestides näitas Mail.ru Groupi arendusmeeskonna Tarantoolil põhinev prototüüplahendus. Sõlmisime lepingu ja alustasime arendusega. Mail.ru Grupist oli kohal neli inimest, Alfa-Bankist kolm arendajat, kolm süsteemianalüütikut, lahenduse arhitekt, tooteomanik ja Scrumi meister.

Järgmisena räägin teile, kuidas meie süsteem kasvas, kuidas see arenes, mida me tegime ja miks just nii.

Areng

Esimene küsimus, mille me endale esitasime, oli, kuidas saada andmeid meie praegustest süsteemidest. Otsustasime, et HTTP on meile üsna sobiv, sest kõik praegused süsteemid suhtlevad omavahel, saates XML-i või JSON-i üle HTTP.

Tarantooli sisseehitatud HTTP-serverit kasutame, kuna meil pole vaja SSL-i seansse lõpetada ja selle jõudlus on meile piisav.

Nagu ma juba ütlesin, elavad kõik meie süsteemid erinevates andmemudelites ja sisendis peame viima objekti mudelisse, mida me ise kirjeldame. Vaja oli keelt, mis võimaldaks andmeid teisendada. Valisime kohustusliku Lua. Käitame kogu andmete teisenduskoodi liivakastis – see on turvaline koht, millest kaugemale jooksev kood ei lähe. Selleks laadime lihtsalt vajaliku koodi, luues keskkonna funktsioonidega, mis ei saa midagi blokeerida ega maha jätta.

Pärast teisendamist tuleb kontrollida andmete vastavust meie loodavale mudelile. Arutasime pikalt, milline peaks olema mudel ja mis keeles seda kirjeldada. Valisime Apache Avro, kuna keel on lihtne ja sellel on Tarantooli tugi. Mudeli ja kohandatud koodi uusi versioone saab kasutusele võtta mitu korda päevas, isegi koormuse all või ilma, igal kellaajal ja kohaneda muutustega väga kiiresti.

Pärast kontrollimist tuleb andmed salvestada. Teeme seda vshardi abil (meil on killude geograafiliselt hajutatud koopiad).

Pealegi on spetsiifilisus selline, et enamik süsteeme, mis meile andmeid saadavad, ei hooli sellest, kas me saime need kätte või mitte. Seetõttu rakendasime algusest peale remondijärjekorra. Mis see on? Kui objektil mingil põhjusel andmete ümberkujundamist või kontrollimist ei toimu, kinnitame siiski vastuvõtmise, kuid samal ajal salvestame objekti remondijärjekorda. See on järjepidev ja asub ettevõtte peamises andmelaos. Kirjutasime sellele kohe administraatoriliidese, erinevad mõõdikud ja hoiatused. Selle tulemusena me ei kaota andmeid. Isegi kui allikas on midagi muutunud, siis kui andmemudel on muutunud, tuvastame selle kohe ja saame kohaneda.

Nüüd peate õppima, kuidas salvestatud andmeid hankida. Analüüsisime hoolikalt oma süsteeme ja nägime, et klassikaline Java ja Oracle'i virn sisaldab tingimata mingisugust ORM-i, mis teisendab andmed relatsioonilistest objektideks. Miks siis mitte anda objektid süsteemidele kohe graafiku kujul? Seega võtsime õnnelikult kasutusele GraphQL-i, mis vastas kõigile meie vajadustele. See võimaldab teil saada andmeid graafikute kujul ja välja tõmmata ainult need, mida praegu vajate. Saate isegi API versiooni üsna paindlikult muuta.

Peaaegu kohe mõistsime, et meie kaevandatud andmetest ei piisa. Lõime funktsioonid, mida saab mudelis olevate objektidega siduda – sisuliselt arvutatud väljad. See tähendab, et me lisame väljale teatud funktsiooni, mis näiteks arvutab keskmise noteeringu hinna. Ja väline tarbija, kes andmeid küsib, ei tea isegi, et see on arvutuslik väli.

Rakendatud autentimissüsteem.

Siis märkasime, et meie otsuses kristalliseerusid mitmed rollid. Roll on omamoodi funktsioonide koondaja. Tavaliselt on rollidel erinevad seadmete kasutusprofiilid:

• T-Connect: käsitleb sissetulevaid ühendusi, CPU piiratud, väike mälutarbimine, olekuta.
• IB-Core: teisendab Tarantooli protokolli kaudu saadud andmeid, see tähendab, et see töötab tabelitega. Samuti ei salvesta see olekut ja on skaleeritav.
• Salvestus: salvestab ainult andmeid, ei kasuta mingit loogikat. See roll rakendab kõige lihtsamaid liideseid. Skaleeritav tänu vshardile.

See tähendab, et rollide abil eraldasime üksteisest klastri erinevad osad, mida saab üksteisest sõltumatult skaleerida.

Niisiis oleme loonud asünkroonse tehinguandmete voo salvestuse ja parandusjärjekorra koos administraatoriliidesega. Salvestus on ärilisest seisukohast asünkroonne: kui oleme garanteeritud, et kirjutame endale andmed, ükskõik kuhu, siis kinnitame selle. Kui seda ei kinnitata, siis läks midagi valesti ja andmed tuleb saata. See on asünkroonne salvestus.

Katsetamine

Otsustasime juba projekti algusest, et proovime rakendada testipõhist arendust. Luas kirjutame ühikuteste tarantool/tap raamistiku abil ja integratsiooniteste Pythonis pytest raamistiku abil. Samas kaasame integratsioonitestide kirjutamisse nii arendajaid kui analüütikuid.

Kuidas me testipõhist arendust kasutame?

Kui tahame mõnda uut funktsiooni, proovime kõigepealt selle jaoks testi kirjutada. Kui avastame vea, kirjutame esmalt kindlasti testi ja alles siis parandame selle. Alguses on nii raske töötada, töötajate poolne arusaamatus, isegi sabotaaž: "Teeme kohe kiiresti korda, teeme midagi uut ja katame siis testidega." Ainult seda "hiljem" ei tule peaaegu kunagi.

Seetõttu tuleb end sundida esmalt teste kirjutama ja paluma teistel seda teha. Uskuge mind, testipõhine arendus toob kasu isegi lühiajaliselt. Tunnete, et teie elu on muutunud lihtsamaks. Arvame, et 99% koodist on nüüd testidega kaetud. See tundub olevat palju, kuid meil pole probleeme: testid käivad iga sissekande korral.

Kõige rohkem armastame aga koormustestimist, mida peame kõige olulisemaks ja teeme seda regulaarselt.

Räägin teile väikese loo sellest, kuidas me ühe esimese versiooni koormustestimise esimese etapi läbi viisime. Installisime süsteemi arendaja sülearvutisse, lülitasime koormuse sisse ja saime 4 tuhat tehingut sekundis. Hea tulemus sülearvuti kohta. Paigaldasime selle neljast serverist koosnevale virtuaalsele koormuspingile, nõrgemale kui tootmises. Kasutatakse minimaalselt. Käitame seda ja saame ühe lõimega halvema tulemuse kui sülearvutil. Šokeeriv sisu.

Olime väga kurvad. Vaatame serveri koormust, kuid selgub, et need on jõude.

Helistame arendajatele ja nad selgitavad meile, inimestele, kes on pärit Java maailmast, et Tarantool on ühe lõimega. Seda saab tõhusalt kasutada ainult üks protsessori tuum koormuse all. Seejärel juurutasime igas serveris maksimaalse võimaliku arvu Tarantooli eksemplare, lülitasime koormuse sisse ja saime juba 14,5 tuhat tehingut sekundis.

Las ma seletan uuesti. Tulenevalt erinevalt ressursse kasutavateks rollideks jaotusest laadisid meie ühenduste töötlemise ja andmete teisendamise eest vastutavad rollid ainult protsessorit ja seda rangelt proportsionaalselt koormusega.

Sel juhul kasutati mälu ainult sissetulevate ühenduste ja ajutiste objektide töötlemiseks.

Vastupidi, salvestusserverites kasvas protsessori koormus, kuid palju aeglasemalt kui ühendusi töötlevates serverites.

Ja mälu tarbimine kasvas võrdeliselt laaditud andmete hulgaga.

Teenused

Oma uue toote arendamiseks spetsiaalselt rakendusplatvormina lõime sellel teenuste ja teekide juurutamiseks komponendi.

Teenused ei ole lihtsalt väikesed kooditükid, mis teatud väljadel toimivad. Need võivad olla üsna suured ja keerukad struktuurid, mis on osa klastrist, kontrollivad võrdlusandmeid, käitavad äriloogikat ja tagastavad vastuseid. Samuti ekspordime teenuseskeemi GraphQL-i ja tarbija saab andmetele universaalse juurdepääsupunkti koos kogu mudeli sisevaatlusega. See on väga mugav.

Kuna teenused sisaldavad palju rohkem funktsioone, otsustasime, et peaks olema teeke, kuhu liigutame sageli kasutatava koodi. Lisasime need turvalisse keskkonda, olles eelnevalt kontrollinud, et see meie jaoks midagi ei lõhu. Ja nüüd saame määrata funktsioonidele täiendavaid keskkondi teekide kujul.

Tahtsime platvormi mitte ainult salvestuseks, vaid ka andmetöötluseks. Ja kuna meil oli juba hunnik koopiaid ja killukesi, võtsime kasutusele mingi hajutatud andmetöötluse ja nimetasime selle kaardi vähendamiseks, kuna see osutus sarnaseks algse kaardi vähendamisega.

Vanad süsteemid

Mitte kõik meie pärandsüsteemid ei saa meile HTTP kaudu helistada ja GraphQL-i kasutada, kuigi nad toetavad seda protokolli. Seetõttu lõime mehhanismi, mis võimaldab andmeid nendesse süsteemidesse kopeerida.

Kui meie jaoks midagi muutub, käivitatakse salvestusrollis kordumatud päästikud ja muudatustega sõnum jõuab töötlemise järjekorda. See saadetakse välisesse süsteemi, kasutades eraldi replikaatori rolli. See roll olekut ei salvesta.

Uued täiustused

Nagu mäletate, tegime ärilisest seisukohast asünkroonset salvestamist. Kuid siis mõistsid nad, et sellest ei piisa, sest on olemas süsteemide klass, mis peavad operatsiooni oleku kohta kohe vastuse saama. Seega laiendasime oma GraphQL-i ja lisasime mutatsioonid. Need sobivad orgaaniliselt olemasoleva andmetega töötamise paradigmaga. Meie jaoks on see üheainsa punkt nii lugemiseks kui ka kirjutamiseks teise klassi süsteemi jaoks.

Saime ka aru, et teenustest üksi meie jaoks ei piisa, sest on üsna raskeid aruandeid, mida tuleb koostada kord päevas, nädalas, kuus. See võib võtta kaua aega ja aruanded võivad isegi Tarantooli sündmuste tsükli blokeerida. Seetõttu lõime eraldi rollid: planeerija ja jooksja. Jooksjad olekut ei salvesta. Nad täidavad raskeid ülesandeid, mida me ei suuda lennult arvutada. Ja planeerija roll jälgib nende ülesannete käivitamise ajakava, mida on kirjeldatud konfiguratsioonis. Ülesanded ise salvestatakse äriandmetega samasse kohta. Kui õige aeg kätte jõuab, võtab ajakava koostaja ülesande, annab mõnele jooksjale, kes loeb selle üle ja salvestab tulemuse.

Kõik ülesanded ei pea toimuma ajakava järgi. Mõningaid aruandeid tuleb nõudmisel lugeda. Niipea kui see nõue saabub, luuakse liivakastis ülesanne ja saadetakse jooksjale täitmiseks. Mõne aja pärast saab kasutaja asünkroonse vastuse, et kõik on arvutatud ja aruanne valmis.

Algselt järgisime kõigi andmete salvestamise, versioonide muutmise ja mitte kustutamise paradigmat. Aga elus tuleb ikka aeg-ajalt midagi ära kustutada, enamasti mingi toores või vahepealne info. Aegunud andmete põhjal lõime mehhanismi salvestusruumi puhastamiseks vananenud andmetest.

Samuti mõistame, et varem või hiljem saabub olukord, kus mälus andmete salvestamiseks ei jätku ruumi, kuid sellegipoolest tuleb andmed salvestada. Nendel eesmärkidel valmistame peagi kettasalvestust.

Järeldus

Alustasime ülesandega laadida andmed ühte mudelisse ja kulutasime kolm kuud selle väljatöötamisele. Meil oli kuus andmeedastussüsteemi. Kogu teisenduskood üheks mudeliks on Lua keeles umbes 30 tuhat rida. Ja suurem osa tööst on veel ees. Vahel napib motivatsiooni naabermeeskondadest ning on palju asjaolusid, mis teevad töö keeruliseks. Kui olete kunagi silmitsi sarnase ülesandega, korrutage selle täitmiseks teile normaalne tunduv aeg kolme või isegi neljaga.

Samuti pidage meeles, et olemasolevaid äriprotsesside probleeme ei saa lahendada uue DBMS-i abil, isegi kui see on väga produktiivne. Mida ma mõtlen? Jäime oma projekti alguses klientides mulje, et nüüd toome uue kiire andmebaasi ja elame! Protsessid lähevad kiiremini, kõik saab korda. Tegelikult ei lahenda tehnoloogia äriprotsesside probleeme, sest äriprotsessid on inimesed. Ja tööd tuleb teha inimestega, mitte tehnoloogiaga.

Testipõhine arendus võib varases staadiumis olla valulik ja aeganõudev. Kuid selle positiivne mõju on märgatav isegi lühiajaliselt, kui te ei pea regressioonitesti läbiviimiseks midagi ette võtma.

Koormustestide läbiviimine kõikides arendusetappides on äärmiselt oluline. Mida varem arhitektuuris mõnd viga märkad, seda lihtsam on seda parandada, mis säästab tulevikus palju aega.

Lual pole midagi viga. Sellesse kirjutamist saavad õppida kõik: Java arendaja, JavaScripti arendaja, Pythoni arendaja, esi- või tagaosa. Isegi meie analüütikud kirjutavad sellest.

Kui me räägime sellest, et meil pole SQL-i, siis see hirmutab inimesi. „Kuidas saada andmeid ilma SQL-ita? Kas see on võimalik? Kindlasti. OLTP-klassi süsteemis pole SQL-i vaja. Alternatiiv on mingi keele kujul, mis viib teid kohe tagasi dokumendile orienteeritud vaate juurde. Näiteks GraphQL. Ja on olemas alternatiiv hajutatud andmetöötluse näol.

Kui mõistate, et teil on vaja skaleerida, kujundage oma lahendus Tarantoolis nii, et see saaks paralleelselt töötada kümnetel Tarantooli eksemplaridel. Kui te seda ei tee, on hiljem raske ja valus, kuna Tarantool saab tõhusalt kasutada ainult ühte protsessori tuuma.

Allikas: www.habr.com