Ešte z filmu „Náš tajný vesmír: Skrytý život bunky“

Investičný biznis je jednou z najzložitejších oblastí bankového sveta, pretože tu nie sú len úvery, pôžičky a vklady, ale aj cenné papiere, meny, komodity, deriváty a všelijaké zložitosti v podobe štruktúrovaných produktov.

V poslednom období zaznamenávame nárast finančnej gramotnosti obyvateľstva. Čoraz viac ľudí sa zapája do obchodovania na trhoch s cennými papiermi. Individuálne investičné účty sa objavili nie tak dávno. Umožňujú vám obchodovať na trhoch s cennými papiermi a buď prijímať daňové odpočty, alebo sa vyhýbať plateniu daní. A všetci klienti, ktorí k nám prídu, chcú spravovať svoje portfólio a vidieť reporting v reálnom čase. Toto portfólio je navyše najčastejšie multiproduktové, to znamená, že ľudia sú klientmi rôznych obchodných línií.

Okrem toho rastú potreby regulačných orgánov, ruských aj zahraničných.

Aby sme vyhoveli súčasným potrebám a položili základy pre budúce upgrady, vyvinuli sme investičné obchodné jadro založené na Tarantool.

Nejaké štatistiky. Investičná činnosť Alfa-Bank poskytuje sprostredkovateľské služby pre fyzické a právnické osoby s cieľom poskytnúť možnosť obchodovať na rôznych trhoch s cennými papiermi, služby depozitára na uskladnenie cenných papierov, služby správy trustu pre fyzické osoby so súkromným a veľkým kapitálom, služby spojené s vydávaním cenných papierov pre iné spoločnosti . Investičný biznis Alfa-Bank zahŕňa viac ako 3 300 kotácií za sekundu, ktoré sú stiahnuté z rôznych obchodných platforiem. Počas pracovného dňa sa na trhoch v mene banky alebo jej klientov uzavrie viac ako 5 tisíc transakcií. Na externých a interných platformách dochádza k realizácii až XNUMX tisíc objednávok za sekundu. Zároveň všetci klienti, interní aj externí, chcú vidieť svoje pozície v reálnom čase.

pravek

Niekde od začiatku 2000. storočia sa naše oblasti investičného podnikania vyvíjali samostatne: obchodovanie na burze, maklérske služby, obchodovanie s menami, mimoburzové obchodovanie s cennými papiermi a rôznymi derivátmi. V dôsledku toho sme sa dostali do pasce funkčných studní. Čo to je? Každá oblasť podnikania má svoje vlastné systémy, ktoré navzájom duplikujú funkcie. Každý systém má svoj vlastný dátový model, aj keď fungujú s rovnakými pojmami: transakcie, nástroje, protistrany, kotácie atď. A keďže sa každý systém vyvíjal nezávisle, vznikla rôznorodá zoologická záhrada s technológiami.

Navyše kódová základňa systémov je už dosť zastaraná, pretože niektoré produkty vznikli v polovici 1990. rokov. A v niektorých oblastiach to spomalilo proces vývoja a vyskytli sa problémy s výkonom.

Požiadavky na nové riešenie

Podniky si uvedomili, že technologická transformácia je životne dôležitá pre ďalší rozvoj. Dostali sme úlohy:

1. Zhromažďujte všetky obchodné údaje v jedinom rýchlom úložisku a v jedinom dátovom modeli.
2. Tieto informácie nesmieme stratiť ani zmeniť.
3. Údaje je potrebné verzovať, pretože regulátor si môže kedykoľvek vyžiadať štatistiky za predchádzajúce roky.
4. Musíme nielen priniesť nejaké nové, módne DBMS, ale vytvoriť platformu na riešenie obchodných problémov.

Naši architekti si navyše stanovujú svoje vlastné podmienky:

1. Nové riešenie musí byť podnikovej triedy, to znamená, že už musí byť otestované v niektorých veľkých spoločnostiach.
2. Prevádzkový režim riešenia by mal byť kritický. To znamená, že musíme byť prítomní vo viacerých dátových centrách súčasne a pokojne prežiť výpadok jedného dátového centra.
3. Systém musí byť horizontálne škálovateľný. Faktom je, že všetky naše súčasné systémy sú len vertikálne škálovateľné a už teraz narážame na strop kvôli nízkemu nárastu výkonu hardvéru. Preto nastal moment, keď potrebujeme mať horizontálne škálovateľný systém, aby sme prežili.
4. Okrem iného nám bolo povedané, že riešenie musí byť lacné.

Išli sme štandardnou cestou: sformulovali sme požiadavky a kontaktovali oddelenie nákupu. Odtiaľ sme dostali zoznam spoločností, ktoré sú vo všeobecnosti pripravené urobiť to pre nás. Všetkým sme povedali o probléme a dostali sme posúdenie riešení od šiestich z nich.

V banke nikoho neberieme za slovo, radi si všetko sami testujeme. Povinnou podmienkou našej verejnej súťaže preto bolo absolvovanie zaťažkávacích skúšok. Sformulovali sme úlohy záťažového testu a tri zo šiestich spoločností už súhlasili s implementáciou prototypu riešenia založeného na in-memory technológiách na vlastné náklady, aby ho mohli otestovať.

Nepoviem vám, ako sme všetko testovali a ako dlho to trvalo, len zhrniem: najlepší výkon v záťažových testoch ukázal prototyp riešenia založeného na Tarantool od vývojového tímu Mail.ru Group. Podpísali sme zmluvu a začali s vývojom. Boli to štyria ľudia z Mail.ru Group az Alfa-Bank boli traja vývojári, traja systémoví analytici, architekt riešení, produktový vlastník a Scrum master.

Ďalej vám poviem o tom, ako náš systém rástol, ako sa vyvíjal, čo sme robili a prečo práve toto.

dizajn

Prvá otázka, ktorú sme si položili, bola, ako získať dáta z našich súčasných systémov. Rozhodli sme sa, že HTTP je pre nás celkom vhodné, pretože všetky súčasné systémy medzi sebou komunikujú posielaním XML alebo JSON cez HTTP.

Používame HTTP server zabudovaný v Tarantool, pretože nepotrebujeme ukončovať relácie SSL a jeho výkon nám stačí.

Ako som už povedal, všetky naše systémy žijú v rôznych dátových modeloch a na vstupe musíme objekt preniesť do modelu, ktorý si sami popíšeme. Bol potrebný jazyk, ktorý by umožňoval transformáciu údajov. Zvolili sme imperatív Lua. Všetky kódy konverzie údajov spúšťame v karanténe – toto je bezpečné miesto, za ktoré sa spustený kód nedostane. Aby sme to dosiahli, jednoducho načítame reťazec požadovaného kódu a vytvoríme prostredie s funkciami, ktoré nemôžu nič zablokovať ani zrušiť.

Po konverzii je potrebné skontrolovať, či sú údaje v súlade s modelom, ktorý vytvárame. Dlho sme diskutovali o tom, aký by mal byť model a akým jazykom ho popísať. Vybrali sme Apache Avro, pretože jazyk je jednoduchý a má podporu od Tarantool. Nové verzie modelu a vlastného kódu je možné uviesť do prevádzky niekoľkokrát denne aj pod záťažou alebo bez nej, kedykoľvek počas dňa a veľmi rýchlo sa prispôsobiť zmenám.

Po overení je potrebné údaje uložiť. Robíme to pomocou vshard (máme geodispergované repliky črepov).

Špecifickosť je navyše taká, že väčšine systémov, ktoré nám posielajú údaje, nezáleží na tom, či sme ich dostali alebo nie. Preto sme od začiatku implementovali front na opravy. Čo to je? Ak z nejakého dôvodu objekt neprejde transformáciou alebo overením údajov, stále potvrdíme prijatie, ale zároveň uložíme objekt do frontu na opravu. Je konzistentný a nachádza sa v hlavnom obchodnom dátovom sklade. Hneď sme k tomu napísali administrátorské rozhranie, rôzne metriky a upozornenia. Vďaka tomu nestrácame dáta. Aj keď sa niečo zmenilo v zdroji, ak sa zmenil dátový model, okamžite to zistíme a vieme sa prispôsobiť.

Teraz sa musíte naučiť, ako získať uložené údaje. Starostlivo sme analyzovali naše systémy a zistili sme, že klasický zásobník Java a Oracle nevyhnutne obsahuje nejaký druh ORM, ktorý prevádza dáta z relačných na objektové. Prečo teda nedať okamžite objekty systémom vo forme grafu? Takže sme s radosťou prijali GraphQL, ktorý splnil všetky naše potreby. Umožňuje vám prijímať údaje vo forme grafov a vytiahnuť len to, čo práve potrebujete. Môžete dokonca verzovať API s pomerne veľkou flexibilitou.

Takmer okamžite sme si uvedomili, že údaje, ktoré sme extrahovali, nestačia. Vytvorili sme funkcie, ktoré je možné prepojiť s objektmi v modeli - v podstate vypočítané polia. To znamená, že k poľu pripojíme určitú funkciu, ktorá napríklad vypočíta priemernú cenovú ponuku. A externý spotrebiteľ, ktorý požaduje údaje, ani nevie, že ide o vypočítané pole.

Implementovaný autentifikačný systém.

Potom sme si všimli, že v našom rozhodovaní sa vykryštalizovalo viacero rolí. Rola je akýmsi agregátorom funkcií. Roly majú zvyčajne rôzne profily používania zariadení:

• T-Connect: obsluhuje prichádzajúce pripojenia, CPU obmedzený, nízka spotreba pamäte, bezstavový.
• IB-Core: transformuje dáta, ktoré prijíma cez protokol Tarantool, to znamená, že pracuje s tabuľkami. Tiež neukladá stav a je škálovateľný.
• Úložisko: iba ukladá dáta, nepoužíva žiadnu logiku. Táto rola implementuje najjednoduchšie rozhrania. Škálovateľné vďaka vshard.

To znamená, že pomocou rolí sme od seba oddelili rôzne časti klastra, ktoré je možné škálovať nezávisle od seba.

Vytvorili sme teda asynchrónne zaznamenávanie transakčných dátových tokov a frontu opráv s administrátorským rozhraním. Nahrávanie je z obchodného hľadiska asynchrónne: ak máme zaručené, že si dáta zapíšeme sami, nech je to kdekoľvek, tak to potvrdíme. Ak sa nepotvrdí, niečo sa pokazilo a údaje je potrebné odoslať. Toto je asynchrónny záznam.

Testovanie

Od samého začiatku projektu sme sa rozhodli, že sa pokúsime implementovať testom riadený vývoj. Unit testy píšeme v Lua pomocou rámca tarantool/tap a integračné testy v Pythone pomocou rámca pytest. Zároveň do písania integračných testov zapájame vývojárov aj analytikov.

Ako používame testom riadený vývoj?

Ak chceme nejakú novú funkciu, skúsime na ňu najprv napísať test. Keď objavíme chybu, najprv napíšeme test a až potom ho opravíme. Spočiatku je ťažké takto pracovať, dochádza k nepochopeniu zo strany zamestnancov, dokonca k sabotáži: „Rýchlo to hneď napravme, urobme niečo nové a potom to zahrňme testami.“ Len toto „neskôr“ takmer nikdy neprichádza.

Preto sa musíte najprv prinútiť písať testy a požiadať o to ostatných. Verte mi, testom riadený vývoj prináša výhody aj z krátkodobého hľadiska. Budete mať pocit, že váš život sa stal ľahším. Máme pocit, že 99 % kódu je teraz pokrytých testami. Zdá sa to veľa, ale nemáme žiadne problémy: testy prebiehajú pri každom odovzdaní.

Najviac sa nám však páči záťažové testovanie, ktoré považujeme za najdôležitejšie a vykonávame ho pravidelne.

Poviem vám malý príbeh o tom, ako sme vykonali prvú fázu záťažového testovania jednej z prvých verzií. Nainštalovali sme systém na notebook vývojára, zapli sme zaťaženie a dostali sme 4 XNUMX transakcií za sekundu. Dobrý výsledok pre notebook. Nainštalovali sme ho na virtuálnu záťažovú lavicu štyroch serverov, slabšiu ako vo výrobe. Nasadené na minimum. Spustíme to a v jednom vlákne dostaneme horší výsledok ako na notebooku. Šokujúci obsah.

Boli sme veľmi smutní. Pozeráme sa na zaťaženie servera, ale ukázalo sa, že sú nečinné.

Voláme vývojárom a tí nám, ľuďom, ktorí pochádzajú zo sveta Javy, vysvetľujú, že Tarantool je jednovláknový. Pri záťaži ho môže efektívne využívať iba jedno jadro procesora. Potom sme nasadili maximálny možný počet inštancií Tarantool na každý server, zapli záťaž a už sme prijali 14,5 tisíc transakcií za sekundu.

Ešte raz to vysvetlím. Vďaka rozdeleniu na roly, ktoré využívajú zdroje odlišne, naše roly zodpovedné za spracovanie pripojení a transformáciu dát zaťažili iba procesor a to striktne úmerne zaťaženiu.

V tomto prípade bola pamäť použitá len na spracovanie prichádzajúcich pripojení a dočasných objektov.

Naopak, na úložných serveroch sa zaťaženie procesora zvýšilo, ale oveľa pomalšie ako na serveroch, ktoré spracovávajú pripojenia.

A spotreba pamäte rástla priamo úmerne s množstvom načítaných dát.

Služby

Aby sme náš nový produkt vyvinuli špecificky ako aplikačnú platformu, vytvorili sme komponent na nasadenie služieb a knižníc na ňom.

Služby nie sú len malé kúsky kódu, ktoré fungujú v niektorých oblastiach. Môžu to byť pomerne veľké a zložité štruktúry, ktoré sú súčasťou klastra, kontrolujú referenčné údaje, spúšťajú obchodnú logiku a vracajú odpovede. Tiež exportujeme schému služby do GraphQL a spotrebiteľ dostane univerzálny prístupový bod k údajom s introspekciou naprieč celým modelom. Je to veľmi pohodlné.

Keďže služby obsahujú oveľa viac funkcií, rozhodli sme sa, že by mali existovať knižnice, v ktorých budeme presúvať často používaný kód. Pridali sme ich do bezpečného prostredia, pričom sme si predtým skontrolovali, či nám nič nerozbíja. A teraz môžeme funkciám priradiť ďalšie prostredia v podobe knižníc.

Chceli sme mať platformu nielen na ukladanie, ale aj na výpočtovú techniku. A keďže sme už mali kopu replík a črepov, implementovali sme akési distribuované výpočty a nazvali sme to zmenšením mapy, pretože to dopadlo podobne ako pôvodné zmenšenie mapy.

Staré systémy

Nie všetky naše staršie systémy nám môžu volať cez HTTP a používať GraphQL, hoci protokol podporujú. Preto sme vytvorili mechanizmus, ktorý umožňuje replikáciu údajov do týchto systémov.

Ak sa pre nás niečo zmení, v role Storage sa spustia jedinečné spúšťače a správa so zmenami skončí vo fronte spracovania. Odošle sa do externého systému pomocou samostatnej roly replikátora. Táto rola neukladá stav.

Nové vylepšenia

Ako si pamätáte, z obchodného hľadiska sme robili asynchrónne nahrávanie. Potom si však uvedomili, že to nebude stačiť, pretože existuje trieda systémov, ktoré potrebujú okamžite dostať odpoveď o stave prevádzky. Rozšírili sme teda náš GraphQL a pridali sme mutácie. Organicky zapadajú do existujúcej paradigmy práce s dátami. Pre nás je to jediný bod čítania aj zápisu pre inú triedu systémov.

Uvedomili sme si tiež, že samotné služby by nám nestačili, pretože sú dosť ťažké reporty, ktoré treba budovať raz za deň, týždeň, mesiac. Môže to trvať dlho a správy môžu dokonca blokovať slučku udalostí Tarantool. Preto sme vytvorili samostatné roly: plánovač a bežec. Bežce neukladajú stav. Vykonávajú ťažké úlohy, ktoré nedokážeme vypočítať za behu. A rola plánovača monitoruje plán spúšťania týchto úloh, ktorý je popísaný v konfigurácii. Samotné úlohy sú uložené na rovnakom mieste ako obchodné dáta. Keď príde správny čas, plánovač prevezme úlohu, dá ju nejakému bežcovi, ktorý to spočíta a uloží výsledok.

Nie všetky úlohy musia byť spustené podľa plánu. Niektoré správy je potrebné prečítať na požiadanie. Hneď ako táto požiadavka príde, v karanténe sa vytvorí úloha a odošle sa bežcovi na vykonanie. Po určitom čase používateľ dostane asynchrónnu odpoveď, že všetko bolo vypočítané a správa je pripravená.

Spočiatku sme sa držali paradigmy ukladať všetky dáta, verzovať ich a nemazať ich. Ale v živote musíte z času na čas stále niečo vymazať, väčšinou nejaké surové alebo stredné informácie. Na základe expirácie sme vytvorili mechanizmus na čistenie úložiska od neaktuálnych dát.

Chápeme tiež, že skôr či neskôr príde situácia, kedy nebude dostatok miesta na uloženie dát v pamäti, no napriek tomu treba dáta uložiť. Pre tieto účely čoskoro vytvoríme diskové úložisko.

Záver

Začali sme s úlohou načítať dáta do jedného modelu a jeho vývojom sme strávili tri mesiace. Mali sme šesť systémov na dodávku údajov. Celý transformačný kód do jedného modelu má približne 30 tisíc riadkov v Lua. A väčšina práce je ešte pred nami. Niekedy chýba motivácia zo strany susedných tímov a je veľa okolností, ktoré komplikujú prácu. Ak budete niekedy čeliť podobnej úlohe, vynásobte čas, ktorý sa vám zdá normálny na jej realizáciu, tromi alebo dokonca štyrmi.

Pamätajte tiež, že existujúce problémy v obchodných procesoch nemožno vyriešiť pomocou nového DBMS, dokonca ani veľmi produktívneho. To, čo mám na mysli? Na začiatku nášho projektu sme medzi zákazníkmi vytvorili dojem, že teraz prinesieme novú rýchlu databázu a budeme žiť! Procesy pôjdu rýchlejšie, všetko bude v poriadku. V skutočnosti technológia nerieši problémy, ktoré majú obchodné procesy, pretože obchodné procesy sú ľudia. A musíte pracovať s ľuďmi, nie s technológiou.

Vývoj riadený testami môže byť v počiatočných štádiách bolestivý a časovo náročný. Pozitívny efekt sa však prejaví aj krátkodobo, keď na vykonanie regresného testovania nemusíte nič robiť.

Je mimoriadne dôležité vykonávať záťažové testovanie vo všetkých fázach vývoja. Čím skôr si všimnete nejaký nedostatok v architektúre, tým ľahšie ho opravíte, čo vám v budúcnosti ušetrí veľa času.

Lua nemá chybu. Môže sa v ňom naučiť písať každý: vývojár Java, vývojár JavaScript, vývojár Pythonu, front-end alebo back-end. Dokonca o tom píšu aj naši analytici.

Keď hovoríme o tom, že nemáme SQL, ľudí to desí. „Ako získate údaje bez SQL? Je to možné? určite. V systéme triedy OLTP nie je SQL potrebný. Existuje alternatíva v podobe nejakého jazyka, ktorý vás okamžite vráti do zobrazenia orientovaného na dokumenty. Napríklad GraphQL. A existuje alternatíva v podobe distribuovaných výpočtov.

Ak chápete, že budete musieť škálovať, navrhnite svoje riešenie na Tarantool takým spôsobom, aby mohlo bežať paralelne na desiatkach inštancií Tarantool. Ak to neurobíte, bude to neskôr ťažké a bolestivé, keďže Tarantool dokáže efektívne využívať iba jedno jadro procesora.

Zdroj: hab.com