Kader iz filma "Naše skrivnostno vesolje: Skrito življenje celice"

Naložbeni posel je eno najbolj zapletenih področij v bančnem svetu, saj ne gre le za posojila, posojila in depozite, temveč tudi za vrednostne papirje, valute, blago, izvedene finančne instrumente in vse vrste kompleksnosti v obliki strukturiranih produktov.

V zadnjem času opažamo dvig finančne pismenosti prebivalstva. Vse več ljudi se vključuje v trgovanje na trgih vrednostnih papirjev. Posamezni naložbeni računi so se pojavili ne tako dolgo nazaj. Omogočajo vam trgovanje na trgih vrednostnih papirjev in prejemanje davčnih olajšav ali izogibanje plačilu davkov. In vse stranke, ki pridejo k nam, želijo upravljati svoj portfelj in videti poročanje v realnem času. Poleg tega je ta portfelj najpogosteje sestavljen iz več izdelkov, kar pomeni, da so ljudje stranke različnih poslovnih področij.

Poleg tega naraščajo potrebe regulatorjev, tako ruskih kot tujih.

Da bi zadovoljili trenutne potrebe in postavili temelje za prihodnje nadgradnje, smo razvili investicijsko poslovno jedro, ki temelji na Tarantoolu.

Nekaj ​​statistike. Naložbena dejavnost Alfa-Bank zagotavlja posredniške storitve za posameznike in pravne osebe za zagotavljanje možnosti trgovanja na različnih trgih vrednostnih papirjev, storitve depozitarja za shranjevanje vrednostnih papirjev, storitve skrbniškega upravljanja za posameznike z zasebnim in velikim kapitalom, storitve za izdajo vrednostnih papirjev za druga podjetja. . Naložbeni posel Alfa-Bank vključuje več kot 3 tisoč kotacij na sekundo, ki se prenesejo z različnih trgovalnih platform. V delovnem dnevu se na trgih v imenu banke ali njenih strank sklene več kot 300 tisoč poslov. Na zunanjih in notranjih platformah se zgodi do 5 tisoč izvršitev naročil na sekundo. Hkrati pa si vsi naročniki, tako notranji kot zunanji, želijo ogledati svoje pozicije v realnem času.

prazgodovina

Nekje od začetka 2000-ih so se naša področja investicijskega poslovanja razvijala samostojno: borzno trgovanje, posredniške storitve, valutno trgovanje, izvenborzno trgovanje z vrednostnimi papirji in različnimi izvedenimi finančnimi instrumenti. Posledično smo se ujeli v past funkcionalnih vodnjakov. Kaj je to? Vsaka poslovna linija ima svoje sisteme, ki podvajajo funkcije drug drugega. Vsak sistem ima svoj podatkovni model, čeprav delujejo z istimi koncepti: transakcije, instrumenti, nasprotne stranke, kotacije itd. In ko se je vsak sistem razvijal neodvisno, je nastal raznolik živalski vrt tehnologij.

Poleg tega je kodna baza sistemov že precej zastarela, saj so nekateri produkti nastali sredi devetdesetih let. Na nekaterih področjih je to upočasnilo razvojni proces in pojavile so se težave z delovanjem.

Zahteve za novo rešitev

Podjetja so spoznala, da je tehnološka preobrazba ključna za nadaljnji razvoj. Dobili smo naloge:

1. Zberite vse poslovne podatke v enem, hitrem pomnilniku in v enem samem podatkovnem modelu.
2. Teh podatkov ne smemo izgubiti ali spremeniti.
3. Verzija podatkov je nujna, saj lahko regulator kadar koli zahteva statistiko za prejšnja leta.
4. Ne smemo samo prinesti neke nove, modne DBMS, ampak ustvariti platformo za reševanje poslovnih problemov.

Poleg tega naši arhitekti postavljajo svoje pogoje:

1. Nova rešitev mora biti podjetniška, torej mora biti že preizkušena v nekaterih velikih podjetjih.
2. Način delovanja rešitve bi moral biti kritičen. To pomeni, da moramo biti prisotni v več podatkovnih centrih hkrati in mirno preživeti izpad enega podatkovnega centra.
3. Sistem mora biti vodoravno razširljiv. Dejstvo je, da so vsi naši sedanji sistemi le vertikalno razširljivi in ​​že dosegamo zgornjo mejo zaradi nizke rasti moči strojne opreme. Zato je prišel trenutek, ko moramo imeti horizontalno razširljiv sistem za preživetje.
4. Med drugim so nam povedali, da mora biti rešitev poceni.

Šli smo po standardni poti: oblikovali smo zahteve in stopili v stik z nabavno službo. Od tam smo prejeli seznam podjetij, ki so na splošno pripravljena to narediti namesto nas. Vsem smo povedali o problemu, od šestih smo prejeli oceno rešitev.

V banki nikomur ne verjamemo na besedo, radi vse preizkusimo sami. Zato je bil obvezen pogoj našega razpisnega natečaja opravljene obremenitvene teste. Oblikovali smo naloge za obremenitveni test in tri od šestih podjetij so se že dogovorila, da bodo na lastne stroške implementirali prototipno rešitev, ki temelji na tehnologijah v pomnilniku, da bi jo testirali.

Ne bom vam povedal, kako smo vse testirali in koliko časa je trajalo, bom samo povzel: najboljšo zmogljivost pri obremenitvenih testih je pokazala prototipna rešitev, ki temelji na Tarantoolu iz razvojne ekipe Mail.ru Group. Podpisali smo pogodbo in začeli z razvojem. Iz skupine Mail.ru so bili štirje ljudje, iz banke Alfa-Bank pa trije razvijalci, trije sistemski analitiki, arhitekt rešitve, lastnik izdelka in mojster Scrum.

Nato vam bom povedal, kako je naš sistem rasel, kako se je razvijal, kaj smo počeli in zakaj točno to.

Razvoj

Prvo vprašanje, ki smo si ga zastavili, je bilo, kako pridobiti podatke iz naših trenutnih sistemov. Odločili smo se, da je HTTP zelo primeren za nas, saj vsi trenutni sistemi med seboj komunicirajo s pošiljanjem XML ali JSON prek HTTP.

Uporabljamo strežnik HTTP, ki je vgrajen v Tarantool, ker nam ni treba prekinjati sej SSL, njegova zmogljivost pa nam zadostuje.

Kot sem že rekel, vsi naši sistemi živijo v različnih podatkovnih modelih in na vhodu moramo objekt pripeljati do modela, ki ga sami opisujemo. Potreben je bil jezik, ki je omogočal pretvorbo podatkov. Izbrali smo imperativ Lua. Vso kodo za pretvorbo podatkov izvajamo v peskovniku – to je varno mesto, onkraj katerega izvajajoča se koda ne gre. Da bi to naredili, preprosto naložimo zahtevano kodo in ustvarimo okolje s funkcijami, ki ne morejo ničesar blokirati ali izpustiti.

Po pretvorbi je treba podatke preveriti glede skladnosti z modelom, ki ga ustvarjamo. Dolgo smo razpravljali o tem, kakšen naj bo model in v kakšnem jeziku naj ga opišemo. Izbrali smo Apache Avro, ker je jezik preprost in ima podporo Tarantoola. Nove različice modela in kode po meri lahko zaženete večkrat na dan, tudi pod obremenitvijo ali brez, kadarkoli v dnevu in se zelo hitro prilagodite spremembam.

Po preverjanju je treba podatke shraniti. To naredimo z uporabo vshard (imamo geo-razpršene replike shardov).

Poleg tega je specifika takšna, da je večini sistemov, ki nam pošiljajo podatke, vseeno, ali smo jih prejeli ali ne. Zato smo že od samega začetka uvedli čakalno vrsto popravil. Kaj je to? Če objekt iz nekega razloga ni podvržen podatkovni transformaciji ali verifikaciji, kljub temu potrdimo prejem, hkrati pa objekt shranimo v čakalno vrsto za popravilo. Je konsistenten in se nahaja v glavnem skladišču poslovnih podatkov. Zanj smo takoj napisali skrbniški vmesnik, različne metrike in opozorila. Posledično ne izgubimo podatkov. Tudi če se je kaj spremenilo v viru, če se je podatkovni model spremenil, bomo to takoj zaznali in se lahko prilagodili.

Zdaj se morate naučiti, kako pridobiti shranjene podatke. Skrbno smo analizirali naše sisteme in videli, da klasični sklad Jave in Oracla nujno vsebuje nekakšen ORM, ki pretvarja podatke iz relacijskih v objektne. Zakaj torej ne bi sistemom takoj dali objektov v obliki grafa? Zato smo z veseljem sprejeli GraphQL, ki je izpolnil vse naše potrebe. Omogoča vam prejemanje podatkov v obliki grafov in izvlečenje samo tistega, kar trenutno potrebujete. API lahko celo različicite z veliko prilagodljivostjo.

Skoraj takoj smo ugotovili, da podatki, ki smo jih pridobili, niso dovolj. Ustvarili smo funkcije, ki jih je mogoče povezati z objekti v modelu - v bistvu izračunana polja. To pomeni, da polju pripnemo določeno funkcijo, ki na primer izračuna povprečno ponudbeno ceno. In zunanji potrošnik, ki zahteva podatke, sploh ne ve, da je to izračunano polje.

Implementiran sistem avtentikacije.

Nato smo opazili, da se je v naši odločitvi izkristaliziralo več vlog. Vloga je neke vrste agregator funkcij. Običajno imajo vloge različne profile uporabe opreme:

• T-Connect: obravnava dohodne povezave, CPE omejen, nizka poraba pomnilnika, brez stanja.
• IB-Core: transformira podatke, ki jih prejme preko protokola Tarantool, torej operira s tabelami. Prav tako ne shranjuje stanja in je razširljiv.
• Shranjevanje: samo shranjuje podatke, ne uporablja nobene logike. Ta vloga implementira najpreprostejše vmesnike. Razširljivo zahvaljujoč vshard.

To pomeni, da smo z vlogami ločili različne dele gruče drug od drugega, ki jih je mogoče skalirati neodvisno drug od drugega.

Tako smo ustvarili asinhrono snemanje transakcijskega toka podatkov in čakalno vrsto za popravilo s skrbniškim vmesnikom. Snemanje je s poslovnega vidika asinhrono: če imamo zagotovljeno, da si bomo podatke zapisali, ne glede na to, kje, potem jih bomo potrdili. Če ni potrjen, je šlo nekaj narobe in je treba podatke poslati. To je asinhrono snemanje.

Testiranje

Že na samem začetku projekta smo se odločili, da bomo poskušali izvajati testno usmerjen razvoj. Teste enot pišemo v Lui z uporabo ogrodja tarantool/tap, teste integracije pa v Pythonu z uporabo ogrodja pytest. Hkrati v pisanje integracijskih testov vključujemo tako razvijalce kot analitike.

Kako uporabljamo testno usmerjen razvoj?

Če želimo kakšno novo funkcijo, poskusimo najprej napisati test zanjo. Ko odkrijemo napako, najprej napišemo test in jo šele nato popravimo. Sprva je tako težko delati, prihaja do nerazumevanja zaposlenih, tudi do sabotaže: »Dajmo zdaj hitro urediti, narediti nekaj novega, potem pa še s testi.« Samo tega "pozneje" skoraj nikoli ne pride.

Zato se morate najprej prisiliti k pisanju testov in prositi druge, da to naredijo. Verjemite, testno usmerjeni razvoj prinaša koristi tudi na kratek rok. Čutili boste, da je vaše življenje postalo lažje. Menimo, da je zdaj 99 % kode pokrito s testi. To se zdi veliko, vendar nimamo nobenih težav: testi se izvajajo ob vsaki objavi.

Najbolj pa nam je všeč obremenitveno testiranje, ki se nam zdi najpomembnejše in ga redno izvajamo.

Povedal vam bom kratko zgodbo o tem, kako smo izvedli prvo stopnjo obremenitvenega testiranja ene od prvih različic. Sistem smo namestili na prenosni računalnik razvijalca, vklopili obremenitev in dobili 4 tisoč transakcij na sekundo. Dober rezultat za prenosnik. Namestili smo ga na virtualno obremenitveno mizo štirih strežnikov, ki je šibkejša kot v proizvodnji. Razporejen na minimum. Zaženemo ga in v eni niti dobimo slabši rezultat kot na prenosniku. Vsebina šoka.

Bili smo zelo žalostni. Pogledamo obremenitev strežnika, vendar se izkaže, da so nedejavni.

Pokličemo razvijalce in nam, ljudem, ki prihajamo iz sveta Jave, razložijo, da je Tarantool enoniten. Učinkovito ga lahko uporablja samo eno procesorsko jedro pod obremenitvijo. Nato smo na vsak strežnik namestili največje možno število instanc Tarantoola, vklopili obremenitev in že prejeli 14,5 tisoč transakcij na sekundo.

Naj še enkrat razložim. Zaradi delitve na vloge, ki različno uporabljajo vire, so naše vloge, odgovorne za obdelavo povezav in transformacijo podatkov, obremenjevale samo procesor in to strogo sorazmerno z obremenitvijo.

V tem primeru je bil pomnilnik uporabljen samo za obdelavo dohodnih povezav in začasnih objektov.

Nasprotno, na strežnikih za shranjevanje se je obremenitev procesorja povečala, vendar veliko počasneje kot na strežnikih, ki obdelujejo povezave.

In poraba pomnilnika je rasla neposredno sorazmerno s količino naloženih podatkov.

Storitve

Za razvoj našega novega izdelka posebej kot aplikacijske platforme smo ustvarili komponento za uvajanje storitev in knjižnic na njej.

Storitve niso le majhni koščki kode, ki delujejo na nekaterih področjih. Lahko so precej velike in kompleksne strukture, ki so del gruče, preverjajo referenčne podatke, izvajajo poslovno logiko in vračajo odgovore. Izvozimo tudi shemo storitve v GraphQL, potrošnik pa prejme univerzalno dostopno točko do podatkov z introspekcijo po celotnem modelu. Je zelo udobno.

Ker storitve vsebujejo veliko več funkcij, smo se odločili, da morajo obstajati knjižnice, v katere bomo premaknili pogosto uporabljeno kodo. Dodali smo jih v varno okolje, pri čemer smo predhodno preverili, da nam kaj ne pokvari. Zdaj lahko funkcijam dodelimo dodatna okolja v obliki knjižnic.

Želeli smo imeti platformo ne samo za shranjevanje, ampak tudi za računalništvo. In ker smo že imeli kup replik in drobcev, smo uvedli nekakšno porazdeljeno računalništvo in ga poimenovali map reduction, ker se je izkazalo podobno originalnemu map reduciranju.

Stari sistemi

Vsi naši podedovani sistemi nas ne morejo poklicati prek HTTP in uporabljati GraphQL, čeprav podpirajo protokol. Zato smo ustvarili mehanizem, ki omogoča replikacijo podatkov v te sisteme.

Če se nam kaj spremeni, se v vlogi Storage sprožijo unikatni sprožilci in sporočilo s spremembami konča v čakalni vrsti za obdelavo. Pošlje se v zunanji sistem z uporabo ločene vloge replikatorja. Ta vloga ne shranjuje stanja.

Nove izboljšave

Kot se spomnite, smo s poslovnega vidika naredili asinhrono snemanje. Potem pa so ugotovili, da to ne bo dovolj, saj obstaja vrsta sistemov, ki morajo takoj prejeti odgovor o statusu delovanja. Zato smo razširili naš GraphQL in dodali mutacije. Organsko se prilegajo obstoječi paradigmi dela s podatki. Za nas je to ena sama točka za branje in pisanje za drug razred sistemov.

Ugotovili smo tudi, da nam same storitve ne bodo zadostovale, saj so kar težka poročila, ki jih je treba graditi enkrat na dan, teden, mesec. To lahko traja dolgo časa, poročila pa lahko celo blokirajo Tarantoolovo zanko dogodkov. Zato smo ustvarili ločeni vlogi: razporejevalnik in izvajalec. Tekači ne shranjujejo stanja. Izvajajo težke naloge, ki jih ne moremo izračunati sproti. Vloga razporejevalnika pa spremlja razpored zagona teh opravil, ki je opisan v konfiguraciji. Sama opravila so shranjena na istem mestu kot poslovni podatki. Ko pride pravi čas, urnik vzame nalogo, jo da nekemu tekaču, ki jo prešteje in shrani rezultat.

Ni treba, da se vse naloge izvajajo po urniku. Nekatera poročila je treba prebrati na zahtevo. Takoj ko prispe ta zahteva, se v peskovniku ustvari naloga in pošlje izvajalcu v izvedbo. Po določenem času uporabnik prejme asinhroni odgovor, da je vse izračunano in poročilo pripravljeno.

Na začetku smo se držali paradigme shranjevanja vseh podatkov, njihove različice in ne brisanja. A v življenju moraš od časa do časa vseeno kaj izbrisati, večinoma kakšno surovo ali vmesno informacijo. Na podlagi expirationd smo izdelali mehanizem za čiščenje shrambe zastarelih podatkov.

Zavedamo se tudi, da bo prej ali slej prišlo do situacije, ko v pomnilniku ne bo dovolj prostora za shranjevanje podatkov, vendar je podatke vseeno treba shraniti. Za te namene bomo v kratkem izdelali diskovno shrambo.

Zaključek

Začeli smo z nalogo nalaganja podatkov v en sam model in porabili tri mesece za njegov razvoj. Imeli smo šest podatkovnih sistemov. Celotna transformacijska koda v en sam model je približno 30 tisoč vrstic v Lua. In večina dela je še pred nami. Včasih manjka motivacije sosednjih ekip, veliko je okoliščin, ki otežujejo delo. Če se kdaj srečate s podobno nalogo, potem čas, ki se vam zdi normalen za njeno izvedbo, pomnožite s tri ali celo štiri.

Ne pozabite tudi, da obstoječih težav v poslovnih procesih ni mogoče rešiti z novim DBMS, tudi zelo produktivnim. Kaj mislim? Na začetku našega projekta smo med strankami ustvarili vtis, da bomo zdaj prinesli novo hitro bazo in bomo živeli! Procesi bodo potekali hitreje, vse bo v redu. Pravzaprav tehnologija ne rešuje težav, ki jih imajo poslovni procesi, saj so poslovni procesi ljudje. In delati morate z ljudmi, ne s tehnologijo.

Preskusno voden razvoj je lahko v zgodnjih fazah boleč in dolgotrajen. Toda njegov pozitiven učinek bo opazen tudi kratkoročno, ko vam za izvedbo regresijskega testiranja ni treba storiti ničesar.

Izredno pomembno je izvajati obremenitveno testiranje na vseh stopnjah razvoja. Prej ko boste opazili kakšno napako v arhitekturi, lažje jo boste odpravili, kar vam bo v prihodnosti prihranilo veliko časa.

Nič ni narobe z Luo. V njem se lahko nauči pisati kdorkoli: Java razvijalec, JavaScript razvijalec, Python razvijalec, front-end ali back-end. Tudi naši analitiki pišejo o tem.

Ko govorimo o tem, da nimamo SQL-a, to ljudi prestraši. »Kako dobite podatke brez SQL? Je to mogoče? Vsekakor. V sistemu razreda OLTP SQL ni potreben. Obstaja alternativa v obliki neke vrste jezika, ki vas takoj vrne v dokumentno usmerjen pogled. Na primer GraphQL. In obstaja alternativa v obliki porazdeljenega računalništva.

Če razumete, da boste morali povečati obseg, potem oblikujte svojo rešitev na Tarantoolu tako, da bo lahko delovala vzporedno na desetinah instanc Tarantoola. Če tega ne storite, bo kasneje težko in boleče, saj lahko Tarantool učinkovito uporablja le eno procesorsko jedro.

Vir: www.habr.com