Edelleen elokuvasta "Salainen universumimme: solun piilotettu elämä"

Sijoitustoiminta on yksi pankkimaailman monimutkaisimmista alueista, koska siellä ei ole vain lainoja, lainoja ja talletuksia, vaan myös arvopapereita, valuuttoja, hyödykkeitä, johdannaisia ​​ja kaikenlaista monimutkaisuutta strukturoitujen tuotteiden muodossa.

Viime aikoina olemme nähneet väestön talouslukutaidon lisääntyneen. Yhä useammat ihmiset osallistuvat kaupankäyntiin arvopaperimarkkinoilla. Yksittäiset sijoitustilit ilmestyivät ei niin kauan sitten. Niiden avulla voit käydä kauppaa arvopaperimarkkinoilla ja joko saada verovähennyksiä tai välttää verojen maksamista. Ja kaikki meille tulevat asiakkaat haluavat hallita portfoliotaan ja nähdä raportoinnin reaaliajassa. Lisäksi useimmiten tämä portfolio on monituote, eli ihmiset ovat eri liiketoimintalinjojen asiakkaita.

Lisäksi sekä venäläisten että ulkomaisten sääntelyviranomaisten tarpeet kasvavat.

Vastataksemme nykyisiin tarpeisiin ja luodaksemme pohjan tuleville päivityksille olemme kehittäneet Tarantooliin perustuvan sijoitusliiketoiminnan ytimen.

Muutama tilasto. Alfa-Pankin sijoitusliiketoiminta tarjoaa välityspalveluita yksityishenkilöille ja oikeushenkilöille mahdollisuuden käydä kauppaa erilaisilla arvopaperimarkkinoilla, arvopapereiden säilytyspalveluita, luottamuspalveluita yksityisille ja suuripääomaisille henkilöille, arvopapereiden liikkeeseenlaskupalveluita muille yrityksille . Alfa-Pankin sijoitustoimintaan kuuluu yli 3 tuhatta lainausta sekunnissa, jotka ladataan eri kaupankäyntialustoista. Markkinoilla tehdään työpäivän aikana yli 300 tuhatta transaktiota pankin tai sen asiakkaiden puolesta. Ulkoisilla ja sisäisillä alustoilla tapahtuu jopa 5 tuhatta tilauksen toteutusta sekunnissa. Samaan aikaan kaikki asiakkaat, niin sisäiset kuin ulkoiset, haluavat nähdä asemansa reaaliajassa.

esihistoria

Jossain 2000-luvun alusta sijoitusliiketoiminta-alueemme kehittyivät itsenäisesti: pörssikauppa, välityspalvelut, valuuttakauppa, pörssin ulkopuolinen kaupankäynti arvopapereilla ja erilaisilla johdannaisilla. Tämän seurauksena olemme joutuneet toimivien kaivojen ansaan. Mikä se on? Jokaisella toimialalla on omat järjestelmänsä, jotka kopioivat toistensa toiminnot. Jokaisella järjestelmällä on oma tietomallinsa, vaikka ne toimivat samoilla käsitteillä: transaktiot, instrumentit, vastapuolet, noteeraukset ja niin edelleen. Ja kun jokainen järjestelmä kehittyi itsenäisesti, syntyi monipuolinen teknologiatarha.

Lisäksi järjestelmien koodikanta on jo varsin vanhentunut, koska osa tuotteista on peräisin 1990-luvun puolivälistä. Ja joillakin alueilla tämä hidasti kehitysprosessia ja suorituskykyongelmia.

Uuden ratkaisun vaatimukset

Yritykset ovat ymmärtäneet, että teknologinen muutos on elintärkeää jatkokehityksen kannalta. Saimme tehtävät:

1. Kerää kaikki yritystiedot yhteen, nopeaan tallennustilaan ja yhteen tietomalliin.
2. Emme saa kadottaa tai muuttaa näitä tietoja.
3. Tietojen versiointi on välttämätöntä, koska sääntelijä voi milloin tahansa pyytää tilastoja edellisiltä vuosilta.
4. Meidän ei tule vain tuoda uusia muodikkaita tietokantajärjestelmiä, vaan luoda alusta liiketoimintaongelmien ratkaisemiseen.

Lisäksi arkkitehdimme asettavat omat ehdot:

1. Uuden ratkaisun on oltava yritysluokkaa, eli sitä on jo testattava joissakin suurissa yrityksissä.
2. Ratkaisun toimintatavan tulee olla toiminnallinen. Tämä tarkoittaa, että meidän on oltava läsnä useissa palvelinkeskuksissa samanaikaisesti ja selvitettävä rauhallisesti yhden palvelinkeskuksen katkosta.
3. Järjestelmän tulee olla vaakasuunnassa skaalautuva. Tosiasia on, että kaikki nykyiset järjestelmämme ovat vain pystysuunnassa skaalautuvia, ja olemme jo menossa kattoon laitteistotehon alhaisen kasvun vuoksi. Siksi on tullut hetki, jolloin meillä on oltava horisontaalisesti skaalautuva järjestelmä selviytyäksemme.
4. Meille kerrottiin muun muassa, että ratkaisun on oltava halpa.

Noudatimme vakioreittiä: muotoilimme vaatimukset ja otimme yhteyttä hankintaosastoon. Sieltä saimme luettelon yrityksistä, jotka ovat yleensä valmiita tekemään tämän puolestamme. Kerroimme kaikille ongelmasta ja saimme kuudesta heistä arvion ratkaisuista.

Pankissa emme hyväksy kenenkään sanaa, vaan haluamme testata kaikkea itse. Siksi tarjouskilpailumme pakollinen ehto oli kuormitustestien läpäiseminen. Muotoilimme kuormitustestitehtävät, ja kolme kuudesta yrityksestä on jo suostunut ottamaan omalla kustannuksellaan käyttöön muistissa oleviin teknologioihin perustuvan prototyyppiratkaisun testatakseen sitä.

En kerro, kuinka testasimme kaikkea ja kuinka kauan se kesti, teen vain yhteenvedon: parhaan suorituskyvyn kuormitustesteissä osoitti Mail.ru Groupin kehitystiimin Tarantooliin perustuva prototyyppiratkaisu. Allekirjoitimme sopimuksen ja aloitimme kehittämisen. Mail.ru Groupista oli neljä henkilöä ja Alfa-Bankista kolme kehittäjää, kolme järjestelmäanalyytikkoa, ratkaisuarkkitehti, tuotteen omistaja ja Scrum-mestari.

Seuraavaksi kerron kuinka järjestelmämme kasvoi, miten se kehittyi, mitä teimme ja miksi juuri näin.

suunnittelu

Ensimmäinen kysymys, jonka esitimme itseltämme, oli kuinka saada tietoja nykyisistä järjestelmistämme. Päätimme, että HTTP oli meille varsin sopiva, koska kaikki nykyiset järjestelmät kommunikoivat keskenään lähettämällä XML- tai JSON-protokollaa HTTP:n kautta.

Käytämme Tarantooliin sisäänrakennettua HTTP-palvelinta, koska meidän ei tarvitse katkaista SSL-istuntoja ja sen suorituskyky riittää meille.

Kuten jo totesin, kaikki järjestelmämme elävät erilaisissa tietomalleissa, ja sisääntulossa meidän on saatava objekti siihen malliin, jota kuvaamme itse. Tarvittiin kieli, joka mahdollisti tietojen muuntamisen. Valitsimme pakollisen Luan. Suoritamme kaiken datan muunnoskoodin hiekkalaatikossa - tämä on turvallinen paikka, jonka yli käynnissä oleva koodi ei mene. Tätä varten yksinkertaisesti lataamme vaaditun koodin ja luomme ympäristön, jossa on toimintoja, jotka eivät voi estää tai pudottaa mitään.

Muuntamisen jälkeen on tarkistettava, että tiedot ovat luomamme mallin mukaisia. Keskustelimme pitkään, millainen mallin tulisi olla ja millä kielellä sitä kuvaillaan. Valitsimme Apache Avron, koska kieli on yksinkertainen ja sillä on Tarantoolin tuki. Mallin ja mukautetun koodin uudet versiot voidaan ottaa käyttöön useita kertoja päivässä, jopa kuormitettuna tai ilman, mihin aikaan päivästä tahansa, ja ne mukautuvat muutoksiin erittäin nopeasti.

Tarkistuksen jälkeen tiedot on tallennettava. Teemme tämän käyttämällä vshardia (meillä on maantieteellisesti hajautettuja replikoita sirpaleista).

Lisäksi erityispiirteet ovat sellaisia, että useimmat meille tietoja lähettävät järjestelmät eivät välitä siitä, saimmeko ne vai emme. Siksi otimme korjausjonon käyttöön alusta alkaen. Mikä se on? Jos objekti ei jostain syystä käy läpi tietojen muunnos- tai varmennusta, vahvistamme silti vastaanottamisen, mutta samalla tallennamme kohteen korjausjonoon. Se on johdonmukainen ja sijaitsee yrityksen päätietovarastossa. Kirjoitimme heti sille järjestelmänvalvojan käyttöliittymän, erilaisia ​​mittareita ja hälytyksiä. Tämän seurauksena emme menetä tietoja. Vaikka jokin on muuttunut lähteessä, jos tietomalli on muuttunut, havaitsemme sen välittömästi ja voimme mukautua.

Nyt sinun on opittava noutamaan tallennettuja tietoja. Analysoimme järjestelmämme huolellisesti ja huomasimme, että klassinen Java- ja Oracle-pino sisältää välttämättä jonkinlaisen ORM:n, joka muuntaa tiedot relaatiosta objektiksi. Joten miksi et heti antaisi objekteja järjestelmille graafin muodossa? Joten otimme onnellisesti käyttöön GraphQL:n, joka täytti kaikki tarpeemme. Sen avulla voit vastaanottaa tietoja kaavioiden muodossa ja vetää esiin vain sen, mitä tarvitset juuri nyt. Voit jopa versioida API:n melko joustavasti.

Melkein heti tajusimme, että keräämämme tiedot eivät riittäneet. Teimme funktioita, jotka voidaan linkittää mallissa oleviin objekteihin - lähinnä laskettuja kenttiä. Eli kenttään liitetään tietty funktio, joka esimerkiksi laskee keskimääräisen tarjoushinnan. Ja ulkopuolinen kuluttaja, joka pyytää tietoja, ei edes tiedä, että tämä on laskettu kenttä.

Otettu käyttöön todennusjärjestelmä.

Sitten huomasimme, että päätöksessämme kiteytyi useita rooleja. Rooli on eräänlainen toimintojen yhdistäjä. Tyypillisesti rooleilla on erilaiset laitteiden käyttöprofiilit:

• T-Connect: käsittelee saapuvat yhteydet, CPU rajoitettu, pieni muistin kulutus, tilaton.
• IB-Core: muuntaa Tarantool-protokollan kautta vastaanottamansa tiedot, eli se toimii taulukoiden kanssa. Se ei myöskään tallenna tilaa ja on skaalautuva.
• Tallennus: tallentaa vain tietoja, ei käytä logiikkaa. Tämä rooli toteuttaa yksinkertaisimmat käyttöliittymät. Skaalautuva vshardin ansiosta.

Toisin sanoen rooleja käyttämällä erotimme klusterin eri osia toisistaan, joita voidaan skaalata toisistaan ​​riippumatta.

Joten olemme luoneet asynkronisen tapahtumatietovirran tallennuksen ja korjausjonon järjestelmänvalvojan käyttöliittymällä. Tallennus on liiketoiminnallisesti asynkronista: jos taataan, että kirjoitamme tietoja itsellemme missä tahansa, niin vahvistamme sen. Jos sitä ei vahvisteta, jokin meni pieleen ja tiedot on lähetettävä. Tämä on asynkroninen tallennus.

Testaus

Jo projektin alusta päätimme, että yritämme toteuttaa testilähtöistä kehitystä. Kirjoitamme yksikkötestejä Luassa tarantool/tap-kehyksen avulla ja integraatiotestejä Pythonissa pytest-kehyksen avulla. Samalla otamme sekä kehittäjät että analyytikot mukaan integraatiotestien kirjoittamiseen.

Kuinka käytämme testilähtöistä kehitystä?

Jos haluamme uuden ominaisuuden, yritämme kirjoittaa sille ensin testin. Kun löydämme virheen, kirjoitamme ensin testin ja vasta sitten korjaamme sen. Aluksi näin työskentely on vaikeaa, työntekijöiden puolelta tulee väärinymmärrystä, jopa sabotointia: "Korjataan nyt nopeasti, tehdään jotain uutta ja peitetään sitten testeillä." Vain tämä "myöhemmin" ei tule koskaan.

Siksi sinun täytyy pakottaa itsesi kirjoittamaan kokeita ensin ja pyytää muita tekemään se. Uskokaa minua, testivetoinen kehitys tuo etuja myös lyhyellä aikavälillä. Tulet tuntemaan, että elämäsi on helpottunut. Mielestämme 99 % koodista on nyt testattu. Tämä vaikuttaa paljon, mutta meillä ei ole mitään ongelmia: testit suoritetaan jokaisella sitoumuksella.

Eniten rakastamme kuitenkin kuormitustestausta; pidämme sitä tärkeimpänä ja teemme sen säännöllisesti.

Kerron sinulle pienen tarinan siitä, kuinka suoritimme yhden ensimmäisistä versioista kuormitustestauksen ensimmäisen vaiheen. Asensimme järjestelmän kehittäjän kannettavaan tietokoneeseen, käynnistimme latauksen ja saimme 4 tuhatta tapahtumaa sekunnissa. Hyvä tulos kannettavalle tietokoneelle. Asensimme sen neljän palvelimen virtuaaliselle kuormituspenkille, heikommin kuin tuotannossa. Käytetty minimiin. Suoritamme sen ja saamme huonomman tuloksen kuin kannettavalla tietokoneella yhdessä säikeessä. Järkyttävää sisältöä.

Olimme hyvin surullisia. Tarkastelemme palvelimen kuormitusta, mutta käy ilmi, että ne ovat käyttämättömänä.

Soitamme kehittäjille, ja he selittävät meille, ihmisille, jotka tulevat Javan maailmasta, että Tarantool on yksisäikeinen. Vain yksi prosessoriydin voi käyttää sitä tehokkaasti kuormitettuna. Sitten otimme käyttöön suurimman mahdollisen määrän Tarantool-esiintymiä jokaiselle palvelimelle, otimme latauksen päälle ja saimme jo 14,5 tuhatta tapahtumaa sekunnissa.

Selitän vielä. Resursseja eri tavalla käyttäviin rooleihin jakautumisen vuoksi yhteyksien käsittelystä ja datan muuntamisesta vastaavat roolimme kuormittavat vain prosessoria ja tiukasti suhteessa kuormaan.

Tässä tapauksessa muistia käytettiin vain saapuvien yhteyksien ja väliaikaisten kohteiden käsittelyyn.

Päinvastoin, tallennuspalvelimilla prosessorien kuormitus kasvoi, mutta paljon hitaammin kuin yhteyksiä käsittelevillä palvelimilla.

Ja muistin kulutus kasvoi suoraan suhteessa ladatun tiedon määrään.

Palvelut

Kehittääksemme uutta tuotettamme nimenomaan sovellusalustaksi loimme siihen komponentin palveluiden ja kirjastojen käyttöönottamiseksi.

Palvelut eivät ole vain pieniä koodinpätkiä, jotka toimivat joillakin aloilla. Ne voivat olla melko suuria ja monimutkaisia ​​rakenteita, jotka ovat osa klusteria, tarkistavat viitetiedot, suorittavat liiketoimintalogiikkaa ja palauttavat vastauksia. Viemme myös palveluskeeman GraphQL:ään, jolloin kuluttaja saa yleisen pääsypisteen dataan, jossa on itsetutkiskelu koko mallin läpi. Se on erittäin mukava.

Koska palveluissa on paljon enemmän toimintoja, päätimme, että pitäisi olla kirjastoja, joihin siirretään usein käytettyä koodia. Lisäsimme ne turvalliseen ympäristöön, kun olimme aiemmin tarkastaneet, ettei se riko meille mitään. Ja nyt voimme määrittää funktioille lisäympäristöjä kirjastojen muodossa.

Halusimme alustan paitsi tallennusta, myös tietojenkäsittelyä varten. Ja koska meillä oli jo nippu replikoita ja sirpaleita, otimme käyttöön eräänlaisen hajautetun laskennan ja kutsuimme sitä kartan vähentämiseksi, koska se osoittautui samanlaiseksi kuin alkuperäinen kartan vähentäminen.

Vanhat järjestelmät

Kaikki vanhat järjestelmämme eivät voi soittaa meille HTTP:n kautta ja käyttää GraphQL:ää, vaikka ne tukevatkin protokollaa. Siksi loimme mekanismin, jonka avulla tietoja voidaan replikoida näihin järjestelmiin.

Jos jokin muuttuu meille, tallennusroolissa laukaistaan ​​ainutlaatuiset triggerit ja muutokset sisältävä viesti päätyy käsittelyjonoon. Se lähetetään ulkoiseen järjestelmään käyttämällä erillistä replikaattoriroolia. Tämä rooli ei tallenna tilaa.

Uusia parannuksia

Kuten muistatte, liiketoiminnasta katsottuna teimme asynkronisen äänityksen. Mutta sitten he ymmärsivät, että se ei riittäisi, koska on luokka järjestelmiä, joiden on välittömästi saatava vastaus toiminnan tilasta. Joten laajensimme GraphQL:ää ja lisäsimme mutaatioita. Ne sopivat orgaanisesti olemassa olevaan datan kanssa työskentelyn paradigmaan. Meille tämä on yksittäinen luku- ja kirjoituspiste toiselle järjestelmäluokalle.

Ymmärsimme myös, että palvelut eivät yksin riittäisi meille, koska siellä on melko raskaita raportteja, jotka on rakennettava kerran päivässä, viikossa, kuukaudessa. Tämä voi kestää kauan, ja raportit voivat jopa estää Tarantoolin tapahtumasilmukan. Siksi loimme erilliset roolit: ajoittaja ja juoksija. Juoksijat eivät tallenna tilaa. He suorittavat raskaita tehtäviä, joita emme voi laskea lennossa. Ja ajoittajarooli valvoo näiden tehtävien käynnistysaikataulua, joka on kuvattu kokoonpanossa. Itse tehtävät tallennetaan samaan paikkaan kuin yritystiedot. Kun oikea aika koittaa, aikatauluttaja ottaa tehtävän, antaa sen jollekin juoksijalle, joka laskee sen ja tallentaa tuloksen.

Kaikkia tehtäviä ei tarvitse suorittaa aikataulun mukaan. Jotkut raportit on luettava pyynnöstä. Heti kun tämä vaatimus saapuu, hiekkalaatikkoon luodaan tehtävä ja lähetetään juoksijalle suoritettavaksi. Jonkin ajan kuluttua käyttäjä saa asynkronisen vastauksen, että kaikki on laskettu ja raportti on valmis.

Aluksi noudatimme paradigmaa, jonka mukaan kaikki tiedot tallennetaan, versioitiin ja jätettiin poistamatta. Mutta elämässä pitää silloin tällöin silti poistaa jotain, lähinnä jotain raakaa tai välitietoa. Vanhenemisen perusteella loimme mekanismin tallennustilan puhdistamiseksi vanhentuneista tiedoista.

Ymmärrämme myös, että ennemmin tai myöhemmin tulee tilanne, jolloin muistissa ei ole tarpeeksi tilaa tietojen tallentamiseen, mutta siitä huolimatta tiedot on tallennettava. Näitä tarkoituksia varten teemme pian levytallennustilaa.

Johtopäätös

Aloitimme tiedon lataamisesta yhdeksi malliksi ja käytimme kolme kuukautta sen kehittämiseen. Meillä oli kuusi tiedonsyöttöjärjestelmää. Koko muunnoskoodi yhdeksi malliksi on noin 30 tuhatta riviä Luassa. Ja suurin osa työstä on vielä edessä. Joskus naapuritiimeistä puuttuu motivaatio ja monet olosuhteet vaikeuttavat työtä. Jos kohtaat joskus samanlaisen tehtävän, kerro sen suorittamiseen sinulle normaalilta näyttävä aika kolmella tai jopa neljällä.

Muista myös, että olemassa olevia liiketoimintaprosessien ongelmia ei voida ratkaista uudella, edes erittäin tuottavalla DBMS:llä. Mitä tarkoitan? Projektimme alussa loimme asiakkaiden keskuudessa sen vaikutelman, että nyt tuomme uuden nopean tietokannan ja elämme! Prosessit etenevät nopeammin, kaikki on hyvin. Itse asiassa teknologia ei ratkaise liiketoimintaprosessien ongelmia, koska liiketoimintaprosessit ovat ihmisiä. Ja sinun on työskenneltävä ihmisten, ei tekniikan kanssa.

Testilähtöinen kehitys voi olla tuskallista ja aikaa vievää alkuvaiheessa. Mutta sen positiivinen vaikutus on havaittavissa jopa lyhyellä aikavälillä, jolloin sinun ei tarvitse tehdä mitään regressiotestauksen suorittamiseksi.

On erittäin tärkeää suorittaa kuormitustestaus kaikissa kehitysvaiheissa. Mitä nopeammin huomaat jonkin virheen arkkitehtuurissa, sitä helpompi se on korjata, mikä säästää paljon aikaa tulevaisuudessa.

Luassa ei ole mitään vikaa. Kuka tahansa voi oppia kirjoittamaan siihen: Java-kehittäjä, JavaScript-kehittäjä, Python-kehittäjä, front-end tai back-end. Jopa analyytikkomme kirjoittavat siitä.

Kun puhumme siitä, että meillä ei ole SQL:ää, se kauhistuttaa ihmisiä. "Kuinka saat tietoja ilman SQL:ää? Onko tämä mahdollista? Varmasti. OLTP-luokkajärjestelmässä SQL:ää ei tarvita. Vaihtoehtona on jokin kieli, joka palauttaa sinut välittömästi asiakirjasuuntautuneeseen näkymään. Esimerkiksi GraphQL. Ja vaihtoehtona on hajautettu tietojenkäsittely.

Jos ymmärrät, että sinun on skaalattava, suunnittele ratkaisusi Tarantoolissa siten, että se voi toimia rinnakkain kymmenissä Tarantool-esiintymissä. Jos et tee tätä, se on myöhemmin vaikeaa ja tuskallista, koska Tarantool voi käyttää tehokkaasti vain yhtä prosessoriydintä.

Lähde: will.com