Záběr z filmu „Náš tajný vesmír: Skrytý život buňky“

Investiční byznys je jednou z nejsložitějších oblastí v bankovním světě, protože existují nejen půjčky, půjčky a vklady, ale také cenné papíry, měny, komodity, deriváty a nejrůznější složitosti v podobě strukturovaných produktů.

V poslední době zaznamenáváme nárůst finanční gramotnosti obyvatel. Do obchodování na trzích cenných papírů se zapojuje stále více lidí. Individuální investiční účty se objevily nedávno. Umožňují vám obchodovat na trzích cenných papírů a buď přijímat daňové odpočty, nebo se vyhýbat placení daní. A všichni klienti, kteří k nám přicházejí, chtějí spravovat své portfolio a vidět reporting v reálném čase. Navíc je toto portfolio nejčastěji multiproduktové, to znamená, že lidé jsou klienty různých oborů podnikání.

Navíc rostou potřeby regulátorů, ruských i zahraničních.

Abychom vyhověli současným potřebám a položili základy pro budoucí upgrady, vyvinuli jsme investiční obchodní jádro založené na Tarantool.

Nějaká statistika. Investiční činnost Alfa-Bank poskytuje zprostředkovatelské služby pro fyzické a právnické osoby za účelem poskytování možnosti obchodovat na různých trzích cenných papírů, služby depozitáře pro uložení cenných papírů, služby správy svěřenských fondů pro fyzické osoby se soukromým a velkým kapitálem, služby pro vydávání cenných papírů pro jiné společnosti . Investiční činnost Alfa-Bank zahrnuje více než 3 tisíce kotací za sekundu, které jsou stahovány z různých obchodních platforem. Během pracovního dne je na trzích uzavřeno více než 300 tisíc transakcí jménem banky nebo jejích klientů. Na externích a interních platformách dochází až k 5 tisícům realizace objednávek za sekundu. Všichni klienti, interní i externí, přitom chtějí vidět své pozice v reálném čase.

pravěk

Někde od počátku 2000. století se naše oblasti investičního podnikání vyvíjely samostatně: obchodování na burze, makléřské služby, obchodování s měnami, mimoburzovní obchodování s cennými papíry a různými deriváty. V důsledku toho jsme se dostali do pasti funkčních studní. co to je? Každá oblast podnikání má své vlastní systémy, které navzájem duplikují funkce. Každý systém má svůj vlastní datový model, i když fungují se stejnými pojmy: transakce, nástroje, protistrany, kotace a tak dále. A jak se každý systém vyvíjel nezávisle, vznikla různorodá zoologická zahrada s technologiemi.

Kódová základna systémů je navíc již značně zastaralá, protože některé produkty vznikly v polovině 1990. let. A v některých oblastech to zpomalilo proces vývoje a došlo k problémům s výkonem.

Požadavky na nové řešení

Podniky si uvědomily, že technologická transformace je životně důležitá pro další rozvoj. Dostali jsme úkoly:

1. Sbírejte všechna obchodní data v jediném rychlém úložišti a v jediném datovém modelu.
2. Tyto informace nesmíme ztratit ani změnit.
3. Údaje je nutné verzovat, protože regulátor si může kdykoli vyžádat statistiky za předchozí roky.
4. Musíme nejen přinést nějaké nové, módní DBMS, ale vytvořit platformu pro řešení obchodních problémů.

Naši architekti si navíc stanoví své vlastní podmínky:

1. Nové řešení musí být podnikové třídy, to znamená, že už musí být otestováno v některých velkých společnostech.
2. Provozní režim řešení by měl být kritický. To znamená, že musíme být přítomni ve více datových centrech současně a v klidu přežít výpadek jednoho datového centra.
3. Systém musí být horizontálně škálovatelný. Faktem je, že všechny naše současné systémy jsou pouze vertikálně škálovatelné a už teď narážíme na strop kvůli nízkému růstu výkonu hardwaru. Proto nastal okamžik, kdy potřebujeme mít horizontálně škálovatelný systém, abychom přežili.
4. Mimo jiné nám bylo řečeno, že řešení musí být levné.

Šli jsme standardní cestou: zformulovali jsme požadavky a kontaktovali oddělení nákupu. Odtud jsme obdrželi seznam společností, které jsou obecně připraveny to pro nás udělat. Všem jsme o problému řekli a od šesti z nich jsme obdrželi posouzení řešení.

V bance nikoho nebereme za slovo, rádi si vše sami testujeme. Povinnou podmínkou naší výběrové soutěže proto bylo absolvování zatěžovacích zkoušek. Formulovali jsme úlohy zátěžového testu a tři ze šesti společností již souhlasily s implementací prototypového řešení založeného na in-memory technologiích na vlastní náklady za účelem jeho testování.

Neřeknu vám, jak jsme vše testovali a jak dlouho to trvalo, jen to shrnu: nejlepší výkon v zátěžových testech ukázal prototyp řešení založeného na Tarantool od vývojového týmu Mail.ru Group. Podepsali jsme smlouvu a zahájili vývoj. Byli to čtyři lidé z Mail.ru Group az Alfa-Bank to byli tři vývojáři, tři systémoví analytici, architekt řešení, vlastník produktu a Scrum master.

Dále vám řeknu o tom, jak náš systém rostl, jak se vyvíjel, co jsme dělali a proč přesně to.

Vývoj

První otázka, kterou jsme si položili, byla, jak získat data z našich současných systémů. Rozhodli jsme se, že HTTP je pro nás docela vhodné, protože všechny současné systémy spolu komunikují odesíláním XML nebo JSON přes HTTP.

Používáme HTTP server zabudovaný v Tarantool, protože nepotřebujeme ukončovat SSL relace a jeho výkon nám stačí.

Jak jsem již řekl, všechny naše systémy žijí v různých datových modelech a na vstupu musíme objekt přivést do modelu, který si sami popisujeme. Byl potřeba jazyk, který by umožňoval transformaci dat. Zvolili jsme imperativ Lua. Veškerý kód pro konverzi dat spouštíme v sandboxu – to je bezpečné místo, za které běžící kód nejde. Za tímto účelem jednoduše načteme požadovaný kód a vytvoříme prostředí s funkcemi, které nemohou nic blokovat ani zahazovat.

Po převodu je třeba zkontrolovat, zda data odpovídají námi vytvářenému modelu. Dlouho jsme diskutovali o tom, jaký by měl být model a jakým jazykem jej popsat. Vybrali jsme Apache Avro, protože jazyk je jednoduchý a má podporu od Tarantool. Nové verze modelu a vlastního kódu lze zprovoznit několikrát denně, i pod zátěží nebo bez, kdykoli během dne a velmi rychle se přizpůsobit změnám.

Po ověření je nutné data uložit. Děláme to pomocí vshard (máme geodispergované repliky střepů).

Specifičnost je navíc taková, že většině systémů, které nám data posílají, je jedno, zda jsme je dostali nebo ne. Proto jsme hned od začátku implementovali frontu na opravy. co to je? Pokud z nějakého důvodu objekt neprojde transformací nebo ověřením dat, stále potvrdíme přijetí, ale zároveň objekt uložíme do fronty na opravy. Je konzistentní a nachází se v hlavním obchodním datovém skladu. Okamžitě jsme k tomu napsali administrátorské rozhraní, různé metriky a upozornění. Díky tomu o data nepřicházíme. I když se ve zdroji něco změnilo, pokud se změnil datový model, okamžitě to zjistíme a můžeme se přizpůsobit.

Nyní se musíte naučit, jak načíst uložená data. Pečlivě jsme analyzovali naše systémy a zjistili jsme, že klasický zásobník Java a Oracle nutně obsahuje nějaký druh ORM, který převádí data z relačních na objektová. Proč tedy rovnou nedat objekty systémům ve formě grafu? Takže jsme s radostí přijali GraphQL, který splnil všechny naše potřeby. Umožňuje přijímat data ve formě grafů a vytahovat z nich jen to, co právě potřebujete. Můžete dokonce verzovat API s poměrně velkou flexibilitou.

Téměř okamžitě jsme si uvědomili, že data, která jsme extrahovali, nestačí. Vytvořili jsme funkce, které lze propojit s objekty v modelu – v podstatě počítaná pole. To znamená, že k poli připojíme určitou funkci, která například vypočítá průměrnou cenu nabídky. A externí spotřebitel, který data požaduje, ani neví, že se jedná o počítané pole.

Implementován autentizační systém.

Pak jsme si všimli, že v našem rozhodování vykrystalizovalo několik rolí. Role je jakýmsi agregátorem funkcí. Role mají obvykle různé profily využití zařízení:

• T-Connect: zvládá příchozí připojení, CPU omezený, nízká spotřeba paměti, bezstavový.
• IB-Core: transformuje data, která přijímá přes protokol Tarantool, to znamená, že pracuje s tabulkami. Také neukládá stav a je škálovatelný.
• Úložiště: pouze ukládá data, nepoužívá žádnou logiku. Tato role implementuje nejjednodušší rozhraní. Škálovatelné díky vshard.

To znamená, že pomocí rolí jsme od sebe oddělili různé části clusteru, které lze škálovat nezávisle na sobě.

Vytvořili jsme tedy záznam asynchronního transakčního toku dat a frontu oprav s administrátorským rozhraním. Záznam je z obchodního hlediska asynchronní: pokud máme zaručeno, že si data budeme zapisovat, ať už kamkoli, tak to potvrdíme. Pokud to není potvrzeno, pak se něco pokazilo a data je potřeba odeslat. Toto je asynchronní záznam.

Testování

Od samého začátku projektu jsme se rozhodli, že se pokusíme implementovat testovací vývoj. Unit testy píšeme v Lua pomocí rámce tarantool/tap a integrační testy v Pythonu pomocí rámce pytest. Zároveň do psaní integračních testů zapojujeme jak vývojáře, tak analytiky.

Jak používáme vývoj řízený testováním?

Pokud chceme nějakou novou funkci, zkusíme pro ni nejprve napsat test. Když objevíme chybu, ujistíme se, že nejprve napíšeme test a teprve potom opravíme. Zpočátku je těžké takto pracovat, dochází k nepochopení ze strany zaměstnanců, dokonce k sabotáži: „Hned to rychle opravíme, udělejme něco nového a pak to zakryjme testy.“ Jen to „později“ téměř nikdy nepřichází.

Proto se musíte nejprve přinutit napsat testy a požádat o to ostatní. Věřte mi, testem řízený vývoj přináší výhody i v krátkodobém horizontu. Budete mít pocit, že se váš život stal jednodušším. Máme pocit, že 99 % kódu je nyní pokryto testy. Zdá se to být hodně, ale nemáme žádné problémy: testy běží při každém potvrzení.

Nejvíc nás však baví zátěžové testování, které považujeme za nejdůležitější a provádíme je pravidelně.

Povím vám malý příběh o tom, jak jsme provedli první fázi zátěžového testování jedné z prvních verzí. Nainstalovali jsme systém na notebook vývojáře, zapnuli zatížení a získali 4 tisíce transakcí za sekundu. Dobrý výsledek pro notebook. Nainstalovali jsme jej na virtuální zátěžovou lavici se čtyřmi servery, slabší než ve výrobě. Nasazeno na minimum. Spustíme to a v jednom vlákně dostaneme výsledek horší než na notebooku. Šokující obsah.

Byli jsme velmi smutní. Podíváme se na zatížení serveru, ale ukázalo se, že jsou nečinné.

Voláme vývojářům a oni nám, lidem ze světa Javy, vysvětlují, že Tarantool je jednovláknový. Při zátěži jej může efektivně využívat pouze jedno jádro procesoru. Poté jsme nasadili maximální možný počet instancí Tarantool na každý server, zapnuli zátěž a již přijali 14,5 tisíce transakcí za sekundu.

Dovolte mi to znovu vysvětlit. Vzhledem k rozdělení do rolí, které využívají zdroje odlišně, naše role odpovědné za zpracování připojení a transformaci dat zatěžovaly pouze procesor a to přísně úměrně zátěži.

V tomto případě byla paměť použita pouze pro zpracování příchozích spojení a dočasných objektů.

Naopak na úložných serverech se zátěž procesoru zvýšila, ale mnohem pomaleji než na serverech, které zpracovávají připojení.

A spotřeba paměti rostla přímo úměrně s množstvím načtených dat.

Služby

Abychom mohli náš nový produkt vyvinout specificky jako aplikační platformu, vytvořili jsme komponentu pro nasazení služeb a knihoven na něm.

Služby nejsou jen malé kousky kódu, které fungují v některých oblastech. Mohou to být poměrně velké a složité struktury, které jsou součástí klastru, kontrolují referenční data, spouštějí obchodní logiku a vracejí odpovědi. Také exportujeme schéma služby do GraphQL a spotřebitel obdrží univerzální přístupový bod k datům s introspekcí napříč celým modelem. Je to velmi pohodlné.

Protože služby obsahují mnohem více funkcí, rozhodli jsme se, že by měly existovat knihovny, ve kterých budeme přesouvat často používaný kód. Přidali jsme je do bezpečného prostředí s tím, že jsme si předtím zkontrolovali, že nám to nic nerozbije. A nyní můžeme funkcím přiřadit další prostředí v podobě knihoven.

Chtěli jsme mít platformu nejen pro úložiště, ale také pro výpočetní techniku. A protože už jsme měli hromadu replik a střepů, implementovali jsme jakýsi distribuovaný výpočet a nazvali jsme to map reduction, protože to dopadlo podobně jako původní map reduction.

Staré systémy

Ne všechny naše starší systémy nám mohou volat přes HTTP a používat GraphQL, ačkoli protokol podporují. Proto jsme vytvořili mechanismus, který umožňuje replikaci dat do těchto systémů.

Pokud se pro nás něco změní, spustí se jedinečné triggery v roli Storage a zpráva se změnami skončí ve frontě zpracování. Odesílá se do externího systému pomocí samostatné role replikátoru. Tato role neukládá stav.

Nová vylepšení

Jak si vzpomínáte, z obchodního hlediska jsme dělali asynchronní nahrávání. Pak si ale uvědomili, že to nebude stačit, protože existuje třída systémů, které potřebují okamžitě dostat odpověď o stavu operace. Rozšířili jsme tedy náš GraphQL a přidali mutace. Organicky zapadají do stávajícího paradigmatu práce s daty. Pro nás je to jediný bod čtení i zápisu pro jinou třídu systémů.

Uvědomili jsme si také, že samotné služby by nám nestačily, protože jsou poměrně těžké reporty, které je potřeba budovat jednou za den, týden, měsíc. To může trvat dlouho a zprávy mohou dokonce blokovat smyčku událostí Tarantool. Proto jsme vytvořili samostatné role: plánovač a běžec. Běžci neukládají stav. Provádějí těžké úkoly, které nemůžeme vypočítat za běhu. A role plánovače sleduje plán spouštění těchto úloh, který je popsán v konfiguraci. Samotné úkoly jsou uloženy na stejném místě jako obchodní data. Když přijde správný čas, plánovač úkol převezme, dá ho nějakému běžci, který to spočítá a uloží výsledek.

Ne všechny úlohy musí být spouštěny podle plánu. Některé zprávy je třeba číst na požádání. Jakmile tento požadavek dorazí, v sandboxu se vytvoří úkol a odešle se běžci k provedení. Po nějaké době uživatel obdrží asynchronní odpověď, že vše bylo spočítáno a sestava je připravena.

Zpočátku jsme se drželi paradigmatu ukládání všech dat, jejich verzování a nemazání. Ale v životě čas od času stejně musíte něco smazat, většinou nějaké surové nebo mezilehlé informace. Na základě expirace jsme vytvořili mechanismus pro čištění úložiště od neaktuálních dat.

Chápeme také, že dříve nebo později přijde situace, kdy nebude dostatek místa pro uložení dat v paměti, ale přesto je nutné data uložit. Pro tyto účely brzy vytvoříme diskové úložiště.

Závěr

Začali jsme úkolem načíst data do jednoho modelu a jeho vývojem jsme strávili tři měsíce. Měli jsme šest systémů dodávky dat. Celý transformační kód do jediného modelu má asi 30 tisíc řádků v Lua. A většina práce je ještě před námi. Někdy chybí motivace sousedních týmů a je mnoho okolností, které práci komplikují. Pokud budete někdy čelit podobnému úkolu, vynásobte čas, který se vám zdá normální pro jeho provedení, třemi, nebo dokonce čtyřmi.

Pamatujte také, že stávající problémy v obchodních procesech nelze vyřešit pomocí nového DBMS, a to ani velmi produktivního. To, co mám na mysli? Na začátku našeho projektu jsme mezi zákazníky vzbudili dojem, že nyní přineseme novou rychlou databázi a budeme žít! Procesy půjdou rychleji, vše bude v pořádku. Technologie ve skutečnosti neřeší problémy, které mají obchodní procesy, protože obchodní procesy jsou lidé. A musíte pracovat s lidmi, ne s technologiemi.

Testem řízený vývoj může být v raných fázích bolestivý a časově náročný. Pozitivní efekt bude ale patrný i krátkodobě, kdy pro provádění regresního testování nemusíte nic dělat.

Je nesmírně důležité provádět zátěžové testování ve všech fázích vývoje. Čím dříve si všimnete nějaké chyby v architektuře, tím snazší bude její oprava, což vám v budoucnu ušetří spoustu času.

S Luou není nic špatného. Každý se v něm může naučit psát: Java developer, JavaScript developer, Python developer, front-end nebo back-end. Píšou o tom i naši analytici.

Když mluvíme o tom, že nemáme SQL, lidi to děsí. „Jak získáte data bez SQL? Je to možné? Rozhodně. V systému třídy OLTP není SQL potřeba. Existuje alternativa v podobě jakéhosi jazyka, který vás okamžitě vrátí do pohledu orientovaného na dokumenty. Například GraphQL. A existuje alternativa v podobě distribuovaného počítání.

Pokud chápete, že budete muset škálovat, navrhněte své řešení na Tarantool takovým způsobem, aby mohlo běžet paralelně na desítkách instancí Tarantool. Pokud to neuděláte, bude to později obtížné a bolestivé, protože Tarantool dokáže efektivně využívat pouze jedno jádro procesoru.

Zdroj: www.habr.com