Stillbild från filmen "Our Secret Universe: The Hidden Life of the Cell"

Investeringsverksamheten är ett av de mest komplexa områdena i bankvärlden, eftersom det inte bara finns lån, upplåning och inlåning, utan även värdepapper, valutor, råvaror, derivat och alla möjliga komplexiteter i form av strukturerade produkter.

På senare tid har vi sett en ökning av befolkningens ekonomiska kunskaper. Allt fler engagerar sig i handel på värdepappersmarknaderna. Individuella investeringskonton dök upp för inte så länge sedan. De låter dig handla på värdepappersmarknaderna och antingen få skatteavdrag eller slippa betala skatt. Och alla kunder som kommer till oss vill hantera sin portfölj och se rapportering i realtid. Dessutom är denna portfölj oftast multiprodukt, det vill säga människor är kunder i olika affärsområden.

Dessutom växer behoven hos tillsynsmyndigheter, både ryska och utländska.

För att möta nuvarande behov och lägga grunden för framtida uppgraderingar har vi utvecklat en investeringsverksamhetskärna baserad på Tarantool.

Lite statistik. Alfa-Banks investeringsverksamhet tillhandahåller mäklartjänster för privatpersoner och juridiska personer för att ge möjlighet att handla på olika värdepappersmarknader, depåtjänster för förvaring av värdepapper, förtroendeförvaltningstjänster för privatpersoner med privat och stort kapital, tjänster för emission av värdepapper för andra företag . Alfa-Banks investeringsverksamhet inkluderar mer än 3 tusen offerter per sekund, som laddas ner från olika handelsplattformar. Under arbetsdagen genomförs mer än 300 tusen transaktioner på marknaderna på uppdrag av banken eller dess kunder. Upp till 5 tusen orderutföranden per sekund sker på externa och interna plattformar. Samtidigt vill alla kunder, både interna och externa, se sina positioner i realtid.

förhistoria

Någonstans från början av 2000-talet utvecklades våra investeringsverksamhetsområden självständigt: börshandel, mäklartjänster, valutahandel, handel över disk i värdepapper och olika derivat. Som ett resultat har vi fallit i fällan med funktionella brunnar. Vad det är? Varje bransch har sina egna system som duplicerar varandras funktioner. Varje system har sin egen datamodell, även om de arbetar med samma koncept: transaktioner, instrument, motparter, offerter och så vidare. Och när varje system utvecklades oberoende, uppstod en mångsidig zoo av teknologier.

Dessutom är systemens kodbas redan ganska föråldrad, eftersom vissa produkter har sitt ursprung i mitten av 1990-talet. Och i vissa områden bromsade detta utvecklingsprocessen och det fanns prestandaproblem.

Krav på en ny lösning

Företag har insett att teknisk omvandling är avgörande för vidare utveckling. Vi fick uppgifter:

Samla all affärsdata i en enda snabb lagring och i en enda datamodell.
Vi får inte förlora eller ändra denna information.
Det är nödvändigt att versionera data, eftersom regulatorn när som helst kan be om statistik för tidigare år.
Vi måste inte bara ta med några nya, fashionabla DBMS, utan skapa en plattform för att lösa affärsproblem.

Dessutom sätter våra arkitekter sina egna villkor:

Den nya lösningen måste vara i företagsklass, det vill säga den måste redan testas i vissa stora företag.
Lösningens driftläge bör vara verksamhetskritisk. Det innebär att vi måste finnas i flera datacenter samtidigt och lugnt överleva avbrottet i ett datacenter.
Systemet måste vara horisontellt skalbart. Faktum är att alla våra nuvarande system bara är vertikalt skalbara, och vi når redan taket på grund av den låga tillväxten av hårdvarukraft. Därför har ögonblicket kommit då vi behöver ha ett horisontellt skalbart system för att överleva.
Vi fick bland annat veta att lösningen måste vara billig.

Vi följde standardvägen: vi formulerade kraven och kontaktade inköpsavdelningen. Därifrån fick vi en lista över företag som i allmänhet är redo att göra detta åt oss. Vi berättade för alla om problemet och fick en bedömning av lösningarna från sex av dem.

På banken tar vi ingens ord för det, vi gillar att testa allt själva. Därför var ett obligatoriskt villkor för vår anbudstävling att klara belastningstester. Vi formulerade belastningstestuppgifter och tre av sex företag har redan gått med på att implementera en prototyplösning baserad på in-memory-teknologier på egen bekostnad för att testa den.

Jag kommer inte att berätta hur vi testade allt och hur lång tid det tog, jag ska bara sammanfatta: den bästa prestandan i belastningstester visades av en prototyplösning baserad på Tarantool från Mail.ru Groups utvecklingsteam. Vi skrev på ett avtal och började utveckla. Det var fyra personer från Mail.ru Group, och från Alfa-Bank var det tre utvecklare, tre systemanalytiker, en lösningsarkitekt, en produktägare och en Scrum-mästare.

Härnäst ska jag berätta om hur vårt system växte, hur det utvecklades, vad vi gjorde och varför just detta.

utformning

Den första frågan vi ställde oss själva var hur vi får data från våra nuvarande system. Vi bestämde oss för att HTTP var ganska lämpligt för oss, eftersom alla nuvarande system kommunicerar med varandra genom att skicka XML eller JSON över HTTP.

Vi använder HTTP-servern inbyggd i Tarantool eftersom vi inte behöver avsluta SSL-sessioner, och dess prestanda räcker för oss.

Som jag redan sa lever alla våra system i olika datamodeller, och vid ingången behöver vi föra objektet till den modell som vi själva beskriver. Det behövdes ett språk som gjorde att data kunde omvandlas. Vi valde imperativ Lua. Vi kör all datakonverteringskod i en sandlåda - detta är en säker plats bortom vilken den löpande koden inte går. För att göra detta laddar vi helt enkelt den nödvändiga koden och skapar en miljö med funktioner som inte kan blockera eller släppa någonting.

Efter konvertering måste data kontrolleras för överensstämmelse med modellen vi skapar. Vi diskuterade länge vad modellen skulle vara och vilket språk vi skulle använda för att beskriva den. Vi valde Apache Avro eftersom språket är enkelt och det har stöd från Tarantool. Nya versioner av modellen och anpassad kod kan tas i drift flera gånger om dagen, även under belastning eller utan, när som helst på dygnet, och anpassas till förändringar mycket snabbt.

Efter verifiering måste uppgifterna sparas. Vi gör detta med vshard (vi har geografiskt spridda kopior av skärvor).

Dessutom är specificiteten sådan att de flesta system som skickar data till oss inte bryr sig om vi fick dem eller inte. Därför implementerade vi en reparationskö redan från början. Vad det är? Om ett objekt av någon anledning inte genomgår datatransformation eller verifiering, bekräftar vi ändå mottagandet, men sparar samtidigt objektet i reparationskön. Det är konsekvent och placerat i det huvudsakliga affärsdatalagret. Vi skrev omedelbart ett administratörsgränssnitt för det, olika mätvärden och varningar. Som ett resultat förlorar vi inte data. Även om något har förändrats i källan, om datamodellen har ändrats, kommer vi omedelbart att upptäcka det och kan anpassa oss.

Nu måste du lära dig hur du hämtar sparad data. Vi analyserade noggrant våra system och såg att den klassiska stacken av Java och Oracle nödvändigtvis innehåller någon form av ORM som omvandlar data från relationell till objekt. Så varför inte omedelbart ge objekt till system i form av en graf? Så vi anammade gladeligen GraphQL, som mötte alla våra behov. Det låter dig ta emot data i form av grafer och bara dra ut det du behöver just nu. Du kan till och med versionera API:et med ganska stor flexibilitet.

Nästan omedelbart insåg vi att den data vi extraherade inte var tillräcklig. Vi skapade funktioner som kan kopplas till objekt i modellen - i huvudsak beräknade fält. Det vill säga att vi kopplar en viss funktion till fältet, som till exempel beräknar det genomsnittliga offertpriset. Och den externa konsumenten som efterfrågar uppgifterna vet inte ens att detta är ett beräknat fält.

Implementerade ett autentiseringssystem.

Sedan märkte vi att flera roller utkristalliserades i vårt beslut. En roll är ett slags aggregator av funktioner. Vanligtvis har roller olika utrustningsanvändningsprofiler:

T-Connect: hanterar inkommande anslutningar, CPU-begränsad, låg minnesförbrukning, tillståndslös.
IB-Core: omvandlar data den tar emot via Tarantool-protokollet, det vill säga den arbetar med tabeller. Den lagrar inte heller status och är skalbar.
Lagring: lagrar endast data, använder ingen logik. Denna roll implementerar de enklaste gränssnitten. Skalbar tack vare vshard.

Det vill säga att vi med hjälp av roller frikopplade olika delar av klustret från varandra, som kan skalas oberoende av varandra.

Så vi har skapat en asynkron transaktionsdataflödesregistrering och en reparationskö med ett admingränssnitt. Inspelningen är asynkron ur affärssynpunkt: om vi garanterat kommer att skriva data till oss själva, oavsett var, så kommer vi att bekräfta det. Om det inte bekräftas har något gått fel och uppgifterna måste skickas. Detta är den asynkrona inspelningen.

testning

Redan från början av projektet bestämde vi att vi skulle försöka implementera testdriven utveckling. Vi skriver enhetstester i Lua med tarantool/tap-ramverket och integrationstester i Python med pytest-ramverket. Samtidigt involverar vi både utvecklare och analytiker i att skriva integrationstester.

Hur använder vi testdriven utveckling?

Om vi vill ha någon ny funktion försöker vi skriva ett test för det först. När vi upptäcker en bugg ser vi till att först skriva ett test och först sedan fixa det. Till en början är det svårt att arbeta så här, det finns missförstånd från de anställdas sida, till och med sabotage: "Låt oss snabbt fixa det nu, göra något nytt och sedan täcka det med tester." Bara detta "senare" kommer nästan aldrig.

Därför måste du tvinga dig själv att skriva prov först och be andra att göra det. Tro mig, testdriven utveckling ger fördelar även på kort sikt. Du kommer att känna att ditt liv har blivit lättare. Vi anser att 99 % av koden nu täcks av tester. Detta verkar vara mycket, men vi har inga problem: tester körs på varje commit.

Men det vi älskar mest är belastningstester, vi anser att det är det viktigaste och utför det regelbundet.

Jag ska berätta en liten historia om hur vi genomförde det första steget av lasttestning av en av de första versionerna. Vi installerade systemet på utvecklarens bärbara dator, slog på belastningen och fick 4 tusen transaktioner per sekund. Bra resultat för en bärbar dator. Vi installerade den på en virtuell lastbänk med fyra servrar, svagare än i produktionen. Utplacerad till ett minimum. Vi kör det, och vi får ett sämre resultat än på en bärbar dator i en tråd. Chockinnehåll.

Vi var väldigt ledsna. Vi tittar på serverbelastningen, men det visar sig att de är inaktiva.

Vi ringer utvecklarna, och de förklarar för oss, människor som kommer från Javas värld, att Tarantool är entrådig. Den kan endast användas effektivt av en processorkärna under belastning. Sedan distribuerade vi maximalt möjliga antal Tarantool-instanser på varje server, slog på belastningen och fick redan 14,5 tusen transaktioner per sekund.

Låt mig förklara igen. På grund av uppdelningen i roller som använder resurser på olika sätt, laddade våra roller ansvariga för bearbetning av anslutningar och datatransformation endast processorn, och strikt proportionell mot belastningen.

I det här fallet användes minnet endast för att bearbeta inkommande anslutningar och tillfälliga objekt.

Tvärtom, på lagringsservrar ökade processorbelastningen, men mycket långsammare än på servrar som bearbetar anslutningar.

Och minnesförbrukningen växte i direkt proportion till mängden laddad data.

Tjänster

För att utveckla vår nya produkt specifikt som en applikationsplattform skapade vi en komponent för att distribuera tjänster och bibliotek på den.

Tjänster är inte bara små kodbitar som verkar på vissa fält. De kan vara ganska stora och komplexa strukturer som ingår i ett kluster, kontrollerar referensdata, kör affärslogik och returnerar svar. Vi exporterar även tjänsteschemat till GraphQL, och konsumenten får en universell åtkomstpunkt till data, med introspektion över hela modellen. Det är väldigt bekvämt.

Eftersom tjänster innehåller många fler funktioner bestämde vi oss för att det ska finnas bibliotek där vi kommer att flytta ofta använd kod. Vi lade till dem i den säkra miljön, efter att tidigare ha kontrollerat att det inte går sönder något för oss. Och nu kan vi tilldela ytterligare miljöer till funktioner i form av bibliotek.

Vi ville ha en plattform inte bara för lagring utan också för datoranvändning. Och eftersom vi redan hade ett gäng repliker och skärvor, implementerade vi en sorts distribuerad beräkning och kallade det map reduce, eftersom det visade sig likna den ursprungliga map reduce.

Gamla system

Inte alla våra äldre system kan ringa oss över HTTP och använda GraphQL, även om de stöder protokollet. Därför skapade vi en mekanism som gör att data kan replikeras till dessa system.

Om något förändras för oss triggas unika triggers i Storage-rollen och meddelandet med ändringarna hamnar i bearbetningskön. Den skickas till ett externt system med en separat replikatorroll. Denna roll lagrar inte status.

Nya förbättringar

Som ni minns, ur affärssynpunkt, gjorde vi asynkron inspelning. Men sedan insåg de att det inte skulle räcka, eftersom det finns en klass av system som omedelbart behöver få ett svar om operationens status. Så vi utökade vår GraphQL och lade till mutationer. De passar organiskt in i det befintliga paradigmet att arbeta med data. För oss är detta en enda punkt för både läsning och skrivning för en annan klass av system.

Vi insåg också att enbart tjänster inte skulle räcka för oss, eftersom det är ganska tunga rapporter som behöver byggas en gång om dagen, en vecka, en månad. Detta kan ta lång tid, och rapporter kan till och med blockera Tarantools händelseslinga. Därför skapade vi separata roller: schemaläggare och löpare. Löpare lagrar inte staten. De kör tunga uppgifter som vi inte kan beräkna i farten. Och schemaläggarrollen övervakar startschemat för dessa uppgifter, vilket beskrivs i konfigurationen. Själva uppgifterna lagras på samma plats som affärsdata. När rätt tid kommer tar schemaläggaren uppgiften, ger den till någon löpare, som räknar den och sparar resultatet.

Alla uppgifter behöver inte köras enligt ett schema. Vissa rapporter måste läsas på begäran. Så snart detta krav kommer skapas en uppgift i sandlådan och skickas till löparen för utförande. Efter en tid får användaren ett asynkront svar att allt är beräknat och rapporten är klar.

Till en början höll vi oss till paradigmet att lagra all data, versionera den och inte radera den. Men i livet, då och då måste du fortfarande radera något, mestadels någon rå eller mellanliggande information. Baserat på utgångsdatum skapade vi en mekanism för att rensa lagringen från föråldrade data.

Vi förstår också att det förr eller senare kommer en situation då det inte kommer att finnas tillräckligt med utrymme för att lagra data i minnet, men ändå måste data lagras. För dessa ändamål kommer vi snart att göra disklagring.

Slutsats

Vi började med uppgiften att ladda data till en enda modell och ägnade tre månader åt att utveckla den. Vi hade sex dataförsörjningssystem. Hela omvandlingskoden till en enda modell är cirka 30 tusen rader i Lua. Och det mesta av arbetet ligger fortfarande framför oss. Ibland saknas motivation från grannlag, och det finns många omständigheter som försvårar arbetet. Om du någonsin står inför en liknande uppgift, multiplicera den tid som verkar normal för dig för dess genomförande med tre, eller till och med fyra.

Kom också ihåg att befintliga problem i affärsprocesser inte kan lösas med ett nytt DBMS, inte ens ett mycket produktivt. Vad jag menar? I början av vårt projekt skapade vi intrycket hos kunderna att nu kommer vi att ta med en ny snabb databas och vi kommer att leva! Processerna kommer att gå snabbare, allt blir bra. Faktum är att tekniken inte löser de problem som affärsprocesser har, eftersom affärsprocesser är människor. Och du måste arbeta med människor, inte teknik.

Testdriven utveckling kan vara smärtsam och tidskrävande i tidiga skeden. Men den positiva effekten av det kommer att märkas även på kort sikt, när du inte behöver göra något för att genomföra regressionstestning.

Det är oerhört viktigt att genomföra belastningstester i alla utvecklingsstadier. Ju tidigare du märker något fel i arkitekturen, desto lättare blir det att fixa det, vilket kommer att spara mycket tid i framtiden.

Det är inget fel på Lua. Vem som helst kan lära sig att skriva i den: Java-utvecklare, JavaScript-utvecklare, Python-utvecklare, front-end eller back-end. Till och med våra analytiker skriver om det.

När vi pratar om att vi inte har SQL skrämmer det folk. "Hur får man data utan SQL? Är det möjligt? Säkert. I ett OLTP-klasssystem behövs inte SQL. Det finns ett alternativ i form av något slags språk som omedelbart återför dig till en dokumentorienterad vy. Till exempel GraphQL. Och det finns ett alternativ i form av distribuerad beräkning.

Om du förstår att du kommer att behöva skala, designa sedan din lösning på Tarantool på ett sådant sätt att den kan köras parallellt på dussintals Tarantool-instanser. Om du inte gör detta kommer det att bli svårt och smärtsamt senare, eftersom Tarantool bara effektivt kan använda en processorkärna.

Källa: will.com

Hur vi byggde upp kärnan i Alfa-Banks investeringsverksamhet baserad på Tarantool