Stillbilde fra filmen "Our Secret Universe: The Hidden Life of the Cell"

Investeringsvirksomheten er et av de mest komplekse områdene i bankverdenen, fordi det ikke bare er lån, innlån og innskudd, men også verdipapirer, valuta, råvarer, derivater og alle slags kompleksiteter i form av strukturerte produkter.

Den siste tiden har vi sett en økning i befolkningens økonomiske kompetanse. Stadig flere engasjerer seg i handel i verdipapirmarkedene. Individuelle investeringskontoer dukket opp for ikke så lenge siden. De lar deg handle på verdipapirmarkedene og enten motta skattefradrag eller unngå å betale skatt. Og alle kunder som kommer til oss ønsker å administrere sin portefølje og se rapportering i sanntid. Dessuten er denne porteføljen oftest multiprodukt, det vil si at folk er kunder i forskjellige forretningsområder.

I tillegg vokser behovene til regulatorer, både russiske og utenlandske.

For å møte dagens behov og legge grunnlaget for fremtidige oppgraderinger, har vi utviklet en investeringsvirksomhetskjerne basert på Tarantool.

Litt statistikk. Alfa-Banks investeringsvirksomhet yter meglertjenester for enkeltpersoner og juridiske personer for å gi mulighet til å handle på ulike verdipapirmarkeder, depottjenester for oppbevaring av verdipapirer, trustforvaltningstjenester for enkeltpersoner med privat og stor kapital, tjenester for utstedelse av verdipapirer for andre selskaper . Alfa-Banks investeringsvirksomhet inkluderer mer enn 3 tusen sitater per sekund, som lastes ned fra ulike handelsplattformer. I løpet av arbeidsdagen gjennomføres mer enn 300 tusen transaksjoner på markedene på vegne av banken eller dens kunder. Opptil 5 tusen ordreutførelser per sekund skjer på eksterne og interne plattformer. Samtidig ønsker alle kunder, både interne og eksterne, å se sine posisjoner i sanntid.

forhistorie

Et sted fra begynnelsen av 2000-tallet utviklet våre investeringsområder seg uavhengig: børshandel, meglertjenester, valutahandel, over-the-counter handel med verdipapirer og ulike derivater. Som et resultat har vi gått i fellen med funksjonelle brønner. Hva det er? Hver bransje har sine egne systemer som dupliserer hverandres funksjoner. Hvert system har sin egen datamodell, selv om de opererer med de samme konseptene: transaksjoner, instrumenter, motparter, sitater og så videre. Og etter hvert som hvert system utviklet seg uavhengig, dukket det opp en mangfoldig dyrehage av teknologier.

I tillegg er kodebasen til systemene allerede ganske utdatert, fordi noen produkter oppsto på midten av 1990-tallet. Og på noen områder bremset dette utviklingsprosessen, og det var ytelsesproblemer.

Krav til ny løsning

Bedrifter har innsett at teknologisk transformasjon er avgjørende for videre utvikling. Vi fikk oppgaver:

1. Samle alle forretningsdata i én enkelt, rask lagring og i én enkelt datamodell.
2. Vi må ikke miste eller endre denne informasjonen.
3. Det er nødvendig å versjonere dataene, fordi regulatoren når som helst kan be om statistikk for tidligere år.
4. Vi må ikke bare ta med noen nye, fasjonable DBMS, men skape en plattform for å løse forretningsproblemer.

I tillegg setter våre arkitekter sine egne betingelser:

1. Den nye løsningen må være i bedriftsklasse, det vil si at den allerede må testes i noen store selskaper.
2. Løsningens driftsmodus bør være forretningskritisk. Det betyr at vi må være tilstede i flere datasentre samtidig og rolig overleve utfall av ett datasenter.
3. Systemet må være horisontalt skalerbart. Faktum er at alle våre nåværende systemer kun er vertikalt skalerbare, og vi når allerede taket på grunn av den lave veksten av maskinvarekraft. Derfor har øyeblikket kommet da vi må ha et horisontalt skalerbart system for å overleve.
4. Vi fikk blant annet beskjed om at løsningen måtte være billig.

Vi fulgte standardruten: vi formulerte kravene og kontaktet innkjøpsavdelingen. Derfra mottok vi en liste over selskaper som generelt sett er klare til å gjøre dette for oss. Vi fortalte alle om problemet, og fikk en vurdering av løsningene fra seks av dem.

I banken tar vi ingens ord for det, vi liker å teste alt selv. Derfor var en obligatorisk betingelse i vår anbudskonkurranse å bestå belastningstester. Vi formulerte lasttestoppgaver, og tre av seks selskaper har allerede sagt ja til å implementere en prototypeløsning basert på in-memory-teknologier for egen regning for å teste den.

Jeg vil ikke fortelle deg hvordan vi testet alt og hvor lang tid det tok, jeg vil bare oppsummere: den beste ytelsen i belastningstester ble vist av en prototypeløsning basert på Tarantool fra Mail.ru Groups utviklingsteam. Vi signerte en avtale og startet utviklingen. Det var fire personer fra Mail.ru Group, og fra Alfa-Bank var det tre utviklere, tre systemanalytikere, en løsningsarkitekt, en produkteier og en Scrum-master.

Deretter skal jeg fortelle deg om hvordan systemet vårt vokste, hvordan det utviklet seg, hva vi gjorde og hvorfor akkurat dette.

utforming

Det første spørsmålet vi stilte oss selv var hvordan vi henter data fra våre nåværende systemer. Vi bestemte oss for at HTTP var ganske passende for oss, fordi alle nåværende systemer kommuniserer med hverandre ved å sende XML eller JSON over HTTP.

Vi bruker HTTP-serveren innebygd i Tarantool fordi vi ikke trenger å avslutte SSL-økter, og ytelsen er nok for oss.

Som jeg allerede sa, lever alle systemene våre i forskjellige datamodeller, og ved inngangen må vi bringe objektet til modellen vi selv beskriver. Et språk var nødvendig som gjorde at data kunne transformeres. Vi valgte imperativ Lua. Vi kjører all datakonverteringskode i en sandkasse - dette er et trygt sted som kjørekoden ikke går utover. For å gjøre dette, laster vi ganske enkelt den nødvendige koden, og lager et miljø med funksjoner som ikke kan blokkere eller slippe noe.

Etter konvertering må dataene kontrolleres for samsvar med modellen vi lager. Vi diskuterte lenge hva modellen skulle være og hvilket språk vi skulle bruke for å beskrive den. Vi valgte Apache Avro fordi språket er enkelt og det har støtte fra Tarantool. Nye versjoner av modellen og tilpasset kode kan settes i drift flere ganger om dagen, selv under belastning eller uten, når som helst på dagen, og tilpasses endringer svært raskt.

Etter verifisering må dataene lagres. Vi gjør dette ved å bruke vshard (vi har geo-spredte kopier av shards).

Dessuten er spesifisiteten slik at de fleste systemer som sender oss data ikke bryr seg om vi mottok dem eller ikke. Derfor implementerte vi en reparasjonskø helt fra starten. Hva det er? Dersom et objekt av en eller annen grunn ikke gjennomgår datatransformasjon eller verifisering, bekrefter vi likevel mottak, men lagrer samtidig objektet i reparasjonskøen. Det er konsistent og plassert i det viktigste forretningsdatavarehuset. Vi skrev umiddelbart et administratorgrensesnitt for det, ulike beregninger og varsler. Som et resultat mister vi ikke data. Selv om noe har endret seg i kilden, hvis datamodellen har endret seg, vil vi umiddelbart oppdage det og kan tilpasse oss.

Nå må du lære hvordan du henter lagrede data. Vi analyserte systemene våre nøye og så at den klassiske stabelen med Java og Oracle nødvendigvis inneholder en slags ORM som konverterer data fra relasjonell til objekt. Så hvorfor ikke umiddelbart gi objekter til systemer i form av en graf? Så vi tok gjerne i bruk GraphQL, som dekket alle våre behov. Den lar deg motta data i form av grafer og trekke ut bare det du trenger akkurat nå. Du kan til og med versjonere API med ganske mye fleksibilitet.

Nesten umiddelbart skjønte vi at dataene vi hentet ut ikke var nok. Vi laget funksjoner som kan knyttes til objekter i modellen - i hovedsak beregnede felt. Det vil si at vi knytter en bestemt funksjon til feltet, som for eksempel beregner gjennomsnittlig tilbudspris. Og den eksterne forbrukeren som ber om dataene vet ikke engang at dette er et beregnet felt.

Implementerte et autentiseringssystem.

Så la vi merke til at flere roller utkrystalliserte seg i avgjørelsen vår. En rolle er en slags aggregator av funksjoner. Roller har vanligvis forskjellige utstyrsbruksprofiler:

• T-Connect: håndterer innkommende tilkoblinger, CPU begrenset, lavt minneforbruk, statsløs.
• IB-Core: transformerer dataene den mottar via Tarantool-protokollen, det vil si at den opererer med tabeller. Den lagrer heller ikke tilstand og er skalerbar.
• Lagring: lagrer kun data, bruker ingen logikk. Denne rollen implementerer de enkleste grensesnittene. Skalerbar takket være vshard.

Det vil si at vi ved hjelp av roller koblet forskjellige deler av klyngen fra hverandre, som kan skaleres uavhengig av hverandre.

Så vi har opprettet en asynkron transaksjonsdataflytregistrering og en reparasjonskø med et admin-grensesnitt. Opptaket er asynkront fra et forretningsmessig synspunkt: hvis vi garantert vil skrive data til oss selv, uansett hvor, så vil vi bekrefte det. Hvis det ikke er bekreftet, gikk noe galt og dataene må sendes. Dette er det asynkrone opptaket.

Testing

Helt fra starten av prosjektet bestemte vi oss for at vi skulle prøve å implementere testdrevet utvikling. Vi skriver enhetstester i Lua ved å bruke tarantool/tap-rammeverket, og integrasjonstester i Python ved å bruke pytest-rammeverket. Samtidig involverer vi både utviklere og analytikere i å skrive integrasjonstester.

Hvordan bruker vi testdrevet utvikling?

Hvis vi vil ha en ny funksjon, prøver vi å skrive en test for den først. Når vi oppdager en feil, sørger vi for å skrive en test først, og først deretter fikse den. Til å begynne med er det vanskelig å jobbe slik, det er misforståelser hos ansatte, til og med sabotasje: "La oss raskt fikse det nå, gjøre noe nytt, og så dekke det med tester." Bare dette "senere" kommer nesten aldri.

Derfor må du tvinge deg selv til å skrive tester først og be andre om å gjøre det. Tro meg, testdrevet utvikling gir fordeler selv på kort sikt. Du vil føle at livet ditt har blitt enklere. Vi føler at 99 % av koden nå er dekket av tester. Dette virker som mye, men vi har ingen problemer: tester kjøres på hver commit.

Men det vi elsker mest er belastningstesting; vi anser det som det viktigste og utfører det regelmessig.

Jeg skal fortelle deg en liten historie om hvordan vi utførte den første fasen av lasttesting av en av de første versjonene. Vi installerte systemet på utviklerens bærbare datamaskin, satte på belastningen og fikk 4 tusen transaksjoner per sekund. Godt resultat for en bærbar PC. Vi installerte den på en virtuell lastebenk med fire servere, svakere enn i produksjon. Utplassert til et minimum. Vi kjører det, og vi får et dårligere resultat enn på en bærbar datamaskin i én tråd. Sjokkinnhold.

Vi var veldig triste. Vi ser på serverbelastningen, men det viser seg at de er inaktive.

Vi ringer utviklerne, og de forklarer oss, folk som kommer fra Java-verdenen, at Tarantool er entrådet. Den kan bare brukes effektivt av én prosessorkjerne under belastning. Deretter distribuerte vi maksimalt mulig antall Tarantool-forekomster på hver server, satte på belastningen og mottok allerede 14,5 tusen transaksjoner per sekund.

La meg forklare igjen. På grunn av inndelingen i roller som bruker ressurser forskjellig, lastet våre roller som er ansvarlige for behandling av tilkoblinger og datatransformasjon kun prosessoren, og strengt proporsjonal med belastningen.

I dette tilfellet ble minnet kun brukt til å behandle innkommende tilkoblinger og midlertidige objekter.

Tvert imot, på lagringsservere økte prosessorbelastningen, men mye tregere enn på servere som behandler tilkoblinger.

Og minneforbruket vokste i direkte forhold til mengden data som ble lastet inn.

tjenester

For å utvikle vårt nye produkt spesifikt som en applikasjonsplattform, har vi laget en komponent for å distribuere tjenester og biblioteker på den.

Tjenester er ikke bare små kodebiter som opererer på enkelte felt. De kan være ganske store og komplekse strukturer som er en del av en klynge, sjekker referansedata, kjører forretningslogikk og returnerer svar. Vi eksporterer også tjenesteskjemaet til GraphQL, og forbrukeren får et universelt tilgangspunkt til dataene, med introspeksjon på tvers av hele modellen. Det er veldig behagelig.

Siden tjenester inneholder mange flere funksjoner, bestemte vi oss for at det skulle være biblioteker der vi flytter ofte brukt kode. Vi la dem til det trygge miljøet, etter å ha sjekket at det ikke ødelegger noe for oss. Og nå kan vi tilordne tilleggsmiljøer til funksjoner i form av biblioteker.

Vi ønsket å ha en plattform ikke bare for lagring, men også for databehandling. Og siden vi allerede hadde en haug med replikaer og skår, implementerte vi en slags distribuert databehandling og kalte det kartredusering, fordi det viste seg å ligne den originale kartreduksjonen.

Gamle systemer

Ikke alle våre eldre systemer kan ringe oss over HTTP og bruke GraphQL, selv om de støtter protokollen. Derfor har vi laget en mekanisme som gjør at data kan replikeres inn i disse systemene.

Hvis noe endres for oss, utløses unike triggere i Storage-rollen og meldingen med endringene havner i behandlingskøen. Den sendes til et eksternt system ved hjelp av en egen replikatorrolle. Denne rollen lagrer ikke tilstand.

Nye forbedringer

Som du husker, fra et forretningsmessig synspunkt, gjorde vi asynkrone opptak. Men så skjønte de at det ikke ville være nok, fordi det er en klasse med systemer som umiddelbart trenger å motta et svar om status for operasjonen. Så vi utvidet GraphQL og la til mutasjoner. De passer organisk inn i det eksisterende paradigmet med å jobbe med data. For oss er dette et enkelt punkt for både lesing og skriving for en annen klasse av systemer.

Vi innså også at tjenester alene ikke ville være nok for oss, fordi det er ganske tunge rapporter som må bygges en gang om dagen, en uke, en måned. Dette kan ta lang tid, og rapporter kan til og med blokkere Tarantools hendelsesløkke. Derfor opprettet vi separate roller: planlegger og løper. Løpere lagrer ikke tilstand. De kjører tunge oppgaver som vi ikke kan beregne på sparket. Og planleggerrollen overvåker lanseringsplanen for disse oppgavene, som er beskrevet i konfigurasjonen. Selve oppgavene lagres på samme sted som forretningsdata. Når rett tid kommer, tar planleggeren oppgaven, gir den til en løper, som teller den og lagrer resultatet.

Ikke alle oppgaver må kjøres etter en tidsplan. Noen rapporter må leses på forespørsel. Så snart dette kravet kommer, opprettes en oppgave i sandkassen og sendes til løperen for utførelse. Etter en tid får brukeren et asynkront svar om at alt er beregnet og rapporten er klar.

Til å begynne med fulgte vi paradigmet om å lagre alle data, versjonere dem og ikke slette dem. Men i livet må du fra tid til annen fortsatt slette noe, for det meste noe rå eller mellomliggende informasjon. Basert på utløpt, har vi laget en mekanisme for å rense lagringen fra utdaterte data.

Vi forstår også at det før eller siden vil komme en situasjon hvor det ikke vil være nok plass til å lagre data i minnet, men likevel må dataene lagres. For disse formålene vil vi snart lage disklagring.

Konklusjon

Vi startet med oppgaven med å laste data inn i en enkelt modell og brukte tre måneder på å utvikle den. Vi hadde seks dataforsyningssystemer. Hele transformasjonskoden til en enkelt modell er omtrent 30 tusen linjer i Lua. Og det meste av arbeidet ligger fortsatt foran. Noen ganger er det mangel på motivasjon fra nabolag, og det er mange forhold som vanskeliggjør arbeidet. Hvis du noen gang står overfor en lignende oppgave, multipliser tiden som virker normal for deg for implementeringen med tre, eller til og med fire.

Husk også at eksisterende problemer i forretningsprosesser ikke kan løses ved hjelp av et nytt DBMS, selv et veldig produktivt. Hva jeg mener? I starten av prosjektet vårt skapte vi et inntrykk blant kundene at nå skal vi bringe en ny rask database, og vi lever! Prosessene vil gå raskere, alt blir bra. Faktisk løser ikke teknologien problemene som forretningsprosesser har, fordi forretningsprosesser er mennesker. Og du må jobbe med mennesker, ikke teknologi.

Testdrevet utvikling kan være smertefullt og tidkrevende i de tidlige stadiene. Men den positive effekten av det vil være merkbar selv på kort sikt, når du ikke trenger å gjøre noe for å gjennomføre regresjonstesting.

Det er ekstremt viktig å gjennomføre lasttesting på alle stadier av utviklingen. Jo før du oppdager en feil i arkitekturen, jo lettere blir det å fikse det, noe som vil spare deg for mye tid i fremtiden.

Det er ingenting galt med Lua. Alle kan lære å skrive i den: Java-utvikler, JavaScript-utvikler, Python-utvikler, front-end eller back-end. Til og med våre analytikere skriver om det.

Når vi snakker om at vi ikke har SQL, skremmer det folk. "Hvordan får du data uten SQL? Er dette mulig? Sikkert. I et OLTP-klassesystem er SQL ikke nødvendig. Det finnes et alternativ i form av et slags språk som umiddelbart returnerer deg til et dokumentorientert syn. For eksempel GraphQL. Og det finnes et alternativ i form av distribuert databehandling.

Hvis du forstår at du må skalere, utform løsningen din på Tarantool på en slik måte at den kan kjøres parallelt på dusinvis av Tarantool-forekomster. Hvis du ikke gjør dette, vil det være vanskelig og smertefullt senere, siden Tarantool effektivt bare kan bruke én prosessorkjerne.

Kilde: www.habr.com