Still uit de film “Ons geheime universum: het verborgen leven van de cel”
De beleggingssector is een van de meest complexe gebieden in de bankwereld, omdat er niet alleen leningen en deposito's zijn, maar ook effecten, valuta, grondstoffen, derivaten en allerlei complexiteiten in de vorm van gestructureerde producten.
De laatste tijd zien we een toename in de financiële geletterdheid van de bevolking. Steeds meer mensen raken betrokken bij de handel op de effectenmarkten. Individuele beleggingsrekeningen zijn nog niet zo lang geleden verschenen. Ze stellen u in staat om op de effectenmarkten te handelen en belastingaftrek te ontvangen of belasting te vermijden. En alle klanten die bij ons komen, willen hun portefeuille beheren en de rapportage in realtime zien. Bovendien bestaat deze portefeuille meestal uit meerdere producten, dat wil zeggen dat mensen klanten zijn van verschillende bedrijfsonderdelen.
Bovendien groeien de behoeften van toezichthouders, zowel Russische als buitenlandse.
Om aan de huidige behoeften te voldoen en de basis te leggen voor toekomstige upgrades, hebben we een investeringsbedrijfskern ontwikkeld op basis van Tarantool.
Enkele statistieken. De beleggingsactiviteiten van Alfa-Bank bieden makelaarsdiensten aan particulieren en rechtspersonen om de mogelijkheid te bieden om op verschillende effectenmarkten te handelen, bewaardiensten voor de opslag van effecten, trustbeheerdiensten voor particulieren met particulier en groot kapitaal, diensten voor de uitgifte van effecten voor andere bedrijven . De beleggingsactiviteiten van Alfa-Bank omvatten meer dan drieduizend koersen per seconde, die worden gedownload van verschillende handelsplatforms. Gedurende een werkdag worden namens de bank of haar klanten ruim 3 transacties op de markten afgesloten. Tot 300 orderuitvoeringen per seconde vinden plaats op externe en interne platforms. Tegelijkertijd willen alle klanten, zowel intern als extern, hun posities in realtime zien.
prehistorie
Ergens vanaf het begin van de jaren 2000 ontwikkelden onze beleggingsactiviteiten zich onafhankelijk: wisselhandel, makelaarsdiensten, valutahandel, over-the-counter handel in effecten en diverse derivaten. Als gevolg hiervan zijn we in de valkuil van functionele putten gelopen. Wat het is? Elke branche heeft zijn eigen systemen die elkaars functies dupliceren. Elk systeem heeft zijn eigen datamodel, hoewel ze met dezelfde concepten werken: transacties, instrumenten, tegenpartijen, koersen, enzovoort. En terwijl elk systeem zich onafhankelijk ontwikkelde, ontstond er een gevarieerde dierentuin van technologieën.
Bovendien is de codebasis van de systemen al behoorlijk verouderd, omdat sommige producten halverwege de jaren negentig zijn ontstaan. En op sommige gebieden vertraagde dit het ontwikkelingsproces en waren er prestatieproblemen.
Vereisten voor een nieuwe oplossing
Bedrijven hebben zich gerealiseerd dat technologische transformatie essentieel is voor verdere ontwikkeling. We kregen taken:
- Verzamel alle bedrijfsgegevens in één snelle opslag en in één datamodel.
- We mogen deze informatie niet verliezen of wijzigen.
- Het is noodzakelijk om de gegevens te versieleren, omdat de toezichthouder op elk moment om statistieken van voorgaande jaren kan vragen.
- We moeten niet alleen een nieuw, modieus DBMS introduceren, maar een platform creëren voor het oplossen van zakelijke problemen.
Daarnaast stellen onze architecten hun eigen voorwaarden:
- De nieuwe oplossing moet van ondernemingsklasse zijn, dat wil zeggen dat ze al bij een aantal grote bedrijven moet worden getest.
- De bedrijfsmodus van de oplossing moet bedrijfskritisch zijn. Dit betekent dat we in meerdere datacenters tegelijk aanwezig moeten zijn en de uitval van één datacenter rustig moeten overleven.
- Het systeem moet horizontaal schaalbaar zijn. Feit is dat al onze huidige systemen alleen verticaal schaalbaar zijn, en dat we al tegen het plafond aanlopen vanwege de lage groei van het hardwarevermogen. Daarom is het moment aangebroken waarop we een horizontaal schaalbaar systeem nodig hebben om te overleven.
- We kregen onder meer te horen dat de oplossing goedkoop moest zijn.
We volgden de standaardroute: we formuleerden de eisen en namen contact op met de inkoopafdeling. Van daaruit ontvingen we een lijst met bedrijven die over het algemeen bereid zijn dit voor ons te doen. We vertelden iedereen over het probleem en kregen van zes van hen een beoordeling van de oplossingen.
Bij de bank geloven we niemand op zijn woord, we testen graag alles zelf. Daarom was het slagen voor de belastingstests een verplichte voorwaarde voor onze aanbesteding. We hebben belastingtesttaken geformuleerd en drie van de zes bedrijven hebben er al mee ingestemd om op eigen kosten een prototypeoplossing op basis van in-memory-technologieën te implementeren om deze te testen.
Ik zal je niet vertellen hoe we alles hebben getest en hoe lang het duurde, ik vat het alleen samen: de beste prestaties bij belastingtests werden aangetoond door een prototype-oplossing gebaseerd op Tarantool van het ontwikkelingsteam van Mail.ru Group. We tekenden een overeenkomst en begonnen met de ontwikkeling. Er waren vier mensen van Mail.ru Group en van Alfa-Bank waren er drie ontwikkelaars, drie systeemanalisten, een oplossingsarchitect, een producteigenaar en een Scrummaster.
Vervolgens zal ik je vertellen hoe ons systeem groeide, hoe het zich ontwikkelde, wat we deden en waarom dit precies is.
ontwerp
De eerste vraag die we onszelf stelden was hoe we data uit onze huidige systemen konden halen. We besloten dat HTTP heel geschikt voor ons was, omdat alle huidige systemen met elkaar communiceren door XML of JSON over HTTP te verzenden.
We gebruiken de HTTP-server die in Tarantool is ingebouwd omdat we SSL-sessies niet hoeven te beëindigen en de prestaties ervan voor ons voldoende zijn.
Zoals ik al zei, leven al onze systemen in verschillende datamodellen, en bij de invoer moeten we het object naar het model brengen dat we zelf beschrijven. Er was een taal nodig waarmee gegevens konden worden getransformeerd. We kozen voor imperatief Lua. We voeren alle dataconversiecode uit in een sandbox - dit is een veilige plek waar de actieve code niet verder komt. Om dit te doen, laden we eenvoudigweg de vereiste code, waardoor een omgeving ontstaat met functies die niets kunnen blokkeren of laten vallen.
Na de conversie moeten de gegevens worden gecontroleerd op overeenstemming met het model dat we maken. We hebben lang besproken wat het model zou moeten zijn en welke taal we moesten gebruiken om het te beschrijven. Wij hebben voor Apache Avro gekozen omdat de taal eenvoudig is en ondersteuning krijgt van Tarantool. Nieuwe versies van het model en de aangepaste code kunnen meerdere keren per dag, zelfs onder belasting of zonder, op elk moment van de dag in gebruik worden genomen en zich zeer snel aanpassen aan veranderingen.
Na verificatie moeten de gegevens worden opgeslagen. We doen dit met behulp van vshard (we hebben geografisch verspreide replica's van scherven).
Bovendien is de specificiteit zodanig dat het voor de meeste systemen die ons gegevens sturen niet uitmaakt of we deze wel of niet hebben ontvangen. Daarom hebben we vanaf het begin een reparatiewachtrij geïmplementeerd. Wat het is? Als een object om wat voor reden dan ook geen gegevenstransformatie of verificatie ondergaat, bevestigen we nog steeds de ontvangst, maar slaan we het object tegelijkertijd op in de reparatiewachtrij. Het is consistent en bevindt zich in het belangrijkste zakelijke datawarehouse. We hebben er meteen een beheerdersinterface voor geschreven, verschillende statistieken en waarschuwingen. Hierdoor verliezen we geen gegevens. Zelfs als er iets is veranderd in de bron, als het datamodel is veranderd, zullen we dit onmiddellijk detecteren en kunnen we ons aanpassen.
Nu moet u leren hoe u opgeslagen gegevens kunt ophalen. We hebben onze systemen zorgvuldig geanalyseerd en gezien dat de klassieke stapel van Java en Oracle noodzakelijkerwijs een soort ORM bevat die gegevens omzet van relationeel naar object. Dus waarom zouden we niet meteen objecten aan systemen geven in de vorm van een grafiek? Daarom hebben we met veel plezier GraphQL geadopteerd, dat aan al onze behoeften voldeed. Hiermee kunt u gegevens in de vorm van grafieken ontvangen en er alleen uit halen wat u op dit moment nodig heeft. U kunt zelfs een versie van de API maken met behoorlijk wat flexibiliteit.
Vrijwel onmiddellijk beseften we dat de gegevens die we verzamelden niet voldoende waren. We hebben functies gemaakt die kunnen worden gekoppeld aan objecten in het model - in wezen berekende velden. Dat wil zeggen dat we een bepaalde functie aan het veld koppelen, die bijvoorbeeld de gemiddelde offerteprijs berekent. En de externe consument die de gegevens opvraagt, weet niet eens dat dit een berekend veld is.
Een authenticatiesysteem geïmplementeerd.
Toen merkten we dat verschillende rollen zich uitkristalliseerden in onze beslissing. Een rol is een soort aggregator van functies. Doorgaans hebben rollen verschillende apparatuurgebruiksprofielen:
- T-Connect: verwerkt inkomende verbindingen, CPU beperkt, laag geheugenverbruik, staatloos.
- IB-Core: transformeert de gegevens die het ontvangt via het Tarantool-protocol, dat wil zeggen dat het met tabellen werkt. Het slaat ook geen status op en is schaalbaar.
- Opslag: slaat alleen gegevens op, gebruikt geen logica. Deze rol implementeert de eenvoudigste interfaces. Schaalbaar dankzij vshard.
Dat wil zeggen dat we met behulp van rollen verschillende delen van het cluster van elkaar hebben losgekoppeld, die onafhankelijk van elkaar kunnen worden geschaald.
Daarom hebben we een asynchrone registratie van de transactiegegevensstroom en een reparatiewachtrij met een beheerdersinterface gemaakt. De opname is vanuit zakelijk oogpunt asynchroon: als we gegarandeerd gegevens naar onszelf kunnen schrijven, waar dan ook, dan zullen we dit bevestigen. Als de bevestiging niet wordt bevestigd, is er iets misgegaan en moeten de gegevens worden verzonden. Dit is de asynchrone opname.
Testen
Vanaf het allereerste begin van het project hebben we besloten dat we zouden proberen testgestuurde ontwikkeling te implementeren. We schrijven unit-tests in Lua met behulp van het tarantool/tap-framework, en integratietests in Python met behulp van het pytest-framework. Tegelijkertijd betrekken we zowel ontwikkelaars als analisten bij het schrijven van integratietesten.
Hoe gebruiken we testgestuurde ontwikkeling?
Als we een nieuwe functie willen, proberen we er eerst een test voor te schrijven. Wanneer we een bug ontdekken, zorgen we ervoor dat we eerst een test schrijven en deze pas daarna repareren. In het begin is het moeilijk om op deze manier te werken, er is onbegrip bij de medewerkers, zelfs sabotage: "Laten we het nu snel oplossen, iets nieuws doen en het dan bedekken met tests." Alleen komt dit ‘later’ vrijwel nooit.
Daarom moet je jezelf dwingen om eerst tests te schrijven en anderen te vragen dit te doen. Geloof me, testgestuurde ontwikkeling levert zelfs op de korte termijn voordelen op. U zult merken dat uw leven gemakkelijker is geworden. We zijn van mening dat 99% van de code nu door tests wordt gedekt. Dit lijkt veel, maar we hebben geen problemen: er worden tests uitgevoerd op elke commit.
Wat wij echter het leukste vinden is het testen van de belasting; wij vinden dit het belangrijkste en voeren dit regelmatig uit.
Ik zal je een klein verhaal vertellen over hoe we de eerste fase van de belastingtest van een van de eerste versies hebben uitgevoerd. We installeerden het systeem op de laptop van de ontwikkelaar, zetten de belasting aan en kregen 4 transacties per seconde. Goed resultaat voor een laptop. We installeerden het op een virtuele laadbank van vier servers, zwakker dan in productie. Tot een minimum beperkt. We voeren het uit en we krijgen een slechter resultaat dan op een laptop in één thread. Schok inhoud.
We waren erg verdrietig. We kijken naar de serverbelasting, maar het blijkt dat ze inactief zijn.
We bellen de ontwikkelaars, en zij leggen ons uit, mensen die uit de wereld van Java komen, dat Tarantool single-threaded is. Het kan alleen effectief worden gebruikt door één processorkern onder belasting. Vervolgens hebben we het maximaal mogelijke aantal Tarantool-instanties op elke server geïmplementeerd, de belasting ingeschakeld en al 14,5 duizend transacties per seconde ontvangen.
Laat me het nog eens uitleggen. Vanwege de opdeling in rollen die bronnen op verschillende manieren gebruiken, belastten onze rollen die verantwoordelijk zijn voor het verwerken van verbindingen en gegevenstransformatie alleen de processor, en strikt evenredig aan de belasting.
In dit geval werd het geheugen alleen gebruikt voor het verwerken van inkomende verbindingen en tijdelijke objecten.
Integendeel, op opslagservers nam de processorbelasting toe, maar veel langzamer dan op servers die verbindingen verwerken.
En het geheugenverbruik groeide in directe verhouding tot de hoeveelheid geladen gegevens.
Services
Om ons nieuwe product specifiek als applicatieplatform te ontwikkelen, hebben we een component gemaakt waarmee we services en bibliotheken kunnen inzetten.
Services zijn niet slechts kleine stukjes code die op bepaalde velden werken. Het kunnen vrij grote en complexe structuren zijn die deel uitmaken van een cluster, referentiegegevens controleren, bedrijfslogica uitvoeren en antwoorden retourneren. We exporteren het serviceschema ook naar GraphQL en de consument krijgt een universeel toegangspunt tot de gegevens, met introspectie over het hele model. Het is zeer comfortabel.
Omdat services veel meer functies bevatten, hebben we besloten dat er bibliotheken moeten zijn waarin we veelgebruikte code zullen verplaatsen. We hebben ze toegevoegd aan de veilige omgeving, nadat we eerder hadden gecontroleerd of het voor ons niets kapot maakt. En nu kunnen we extra omgevingen toewijzen aan functies in de vorm van bibliotheken.
We wilden niet alleen een platform hebben voor opslag, maar ook voor computers. En omdat we al een aantal replica's en shards hadden, hebben we een soort gedistribueerd computergebruik geïmplementeerd en dit map reduce genoemd, omdat het vergelijkbaar bleek te zijn met de originele map reduce.
Oude systemen
Niet al onze oudere systemen kunnen ons via HTTP bellen en GraphQL gebruiken, hoewel ze het protocol ondersteunen. Daarom hebben we een mechanisme gecreëerd waarmee gegevens naar deze systemen kunnen worden gerepliceerd.
Als er voor ons iets verandert, worden er unieke triggers geactiveerd in de rol Opslag en komt het bericht met de wijzigingen in de verwerkingswachtrij terecht. Het wordt naar een extern systeem verzonden met behulp van een afzonderlijke replicatorrol. Deze rol slaat de status niet op.
Nieuwe verbeteringen
Zoals u zich herinnert, hebben we vanuit zakelijk oogpunt asynchrone opnames gemaakt. Maar toen beseften ze dat dit niet genoeg zou zijn, omdat er een klasse systemen is die onmiddellijk een antwoord moeten ontvangen over de status van de operatie. Daarom hebben we onze GraphQL uitgebreid en mutaties toegevoegd. Ze passen organisch in het bestaande paradigma van het werken met data. Voor ons is dit een enkel punt van zowel lezen als schrijven voor een andere klasse systemen.
We realiseerden ons ook dat services alleen voor ons niet genoeg zouden zijn, omdat er behoorlijk zware rapporten zijn die één keer per dag, per week, per maand moeten worden gebouwd. Dit kan lang duren en rapporten kunnen zelfs de gebeurtenislus van Tarantool blokkeren. Daarom hebben we aparte rollen gecreëerd: planner en runner. Lopers slaan de staat niet op. Ze voeren zware taken uit die we niet zomaar kunnen berekenen. En de rol van planner bewaakt het startschema van deze taken, dat wordt beschreven in de configuratie. De taken zelf worden op dezelfde plek opgeslagen als bedrijfsgegevens. Als het juiste moment is aangebroken, neemt de planner de taak over, geeft deze aan een loper, die deze telt en het resultaat opslaat.
Niet alle taken hoeven volgens een schema te worden uitgevoerd. Sommige rapporten moeten op aanvraag worden gelezen. Zodra deze vereiste binnenkomt, wordt er een taak in de sandbox aangemaakt en ter uitvoering naar de hardloper gestuurd. Na enige tijd krijgt de gebruiker een asynchroon antwoord dat alles is berekend en dat het rapport gereed is.
Aanvankelijk hielden we ons aan het paradigma van het opslaan van alle gegevens, het beheren van versies ervan en het niet verwijderen ervan. Maar in het leven moet je af en toe nog steeds iets verwijderen, meestal wat ruwe of tussentijdse informatie. Op basis van de vervaldatum hebben we een mechanisme gecreëerd om de opslag van verouderde gegevens op te schonen.
We begrijpen ook dat er vroeg of laat een situatie zal ontstaan waarin er niet genoeg ruimte is om gegevens in het geheugen op te slaan, maar de gegevens toch moeten worden opgeslagen. Voor deze doeleinden zullen we binnenkort schijfopslag maken.
Conclusie
We zijn begonnen met de taak om gegevens in één model te laden en hebben drie maanden besteed aan de ontwikkeling ervan. We hadden zes datatoevoersystemen. De volledige transformatiecode naar één enkel model bestaat uit ongeveer 30 regels in Lua. En het meeste werk ligt nog voor de boeg. Soms is er een gebrek aan motivatie bij naburige teams en zijn er veel omstandigheden die het werk bemoeilijken. Als u ooit met een soortgelijke taak wordt geconfronteerd, vermenigvuldig dan de tijd die u normaal lijkt voor de implementatie ervan met drie of zelfs vier.
Bedenk ook dat bestaande problemen in bedrijfsprocessen niet kunnen worden opgelost met een nieuw DBMS, zelfs niet als het een zeer productief DBMS is. Wat ik bedoel? Bij de start van ons project hebben we bij klanten de indruk gewekt dat we nu een nieuwe snelle database zullen brengen en dat we zullen leven! De processen zullen sneller gaan, alles komt goed. In feite lost technologie de problemen van bedrijfsprocessen niet op, omdat bedrijfsprocessen mensen zijn. En je moet met mensen werken, niet met technologie.
Testgestuurde ontwikkeling kan in de beginfase pijnlijk en tijdrovend zijn. Maar het positieve effect ervan zal zelfs op de korte termijn merkbaar zijn, wanneer u niets hoeft te doen om regressietesten uit te voeren.
Het is uiterst belangrijk om belastingtests uit te voeren in alle ontwikkelingsfasen. Hoe eerder u een fout in de architectuur opmerkt, hoe gemakkelijker het zal zijn om deze te repareren, wat u in de toekomst veel tijd zal besparen.
Er is niets mis met Lua. Iedereen kan erin leren schrijven: Java-ontwikkelaar, JavaScript-ontwikkelaar, Python-ontwikkelaar, front-end of back-end. Zelfs onze analisten schrijven erover.
Als we het hebben over het feit dat we geen SQL hebben, maakt dat mensen bang. “Hoe krijg je data zonder SQL? Is dat mogelijk? Zeker. In een OLTP-klassesysteem is SQL niet nodig. Er is een alternatief in de vorm van een soort taal die je meteen terugbrengt naar een documentgeoriënteerde weergave. Bijvoorbeeld GraphQL. En er is een alternatief in de vorm van gedistribueerd computergebruik.
Als u begrijpt dat u moet schalen, ontwerp dan uw oplossing op Tarantool zo dat deze parallel kan draaien op tientallen Tarantool-instanties. Als u dit niet doet, zal het later moeilijk en pijnlijk zijn, aangezien Tarantool slechts één processorkern effectief kan gebruiken.
Bron: www.habr.com