Állókép a „Titkos univerzumunk: A sejt rejtett élete” című filmből

A befektetési üzletág a bankvilág egyik legbonyolultabb területe, hiszen nem csak hitelek, kölcsönök és betétek vannak, hanem értékpapírok, devizák, áruk, származtatott ügyletek és mindenféle komplexitás strukturált termékek formájában.

Az utóbbi időben a lakosság pénzügyi ismereteinek növekedését tapasztaltuk. Egyre többen kapcsolódnak be az értékpapírpiaci kereskedésbe. Az egyéni befektetési számlák nem is olyan régen jelentek meg. Lehetővé teszik az értékpapírpiacokon való kereskedést, és adólevonást kaphat, vagy elkerülheti az adófizetést. És minden hozzánk érkező ügyfél szeretné kezelni portfólióját és valós időben látni a jelentéseket. Sőt, ez a portfólió leggyakrabban több termékből áll, vagyis az emberek különböző üzletágak ügyfelei.

Emellett az orosz és a külföldi szabályozók igényei is nőnek.

A jelenlegi igények kielégítése és a jövőbeli fejlesztések megalapozása érdekében a Tarantool-on alapuló befektetési üzleti magot fejlesztettünk ki.

Néhány statisztika. Az Alfa-Bank befektetési üzletága magánszemélyek és jogi személyek részére brókeri szolgáltatásokat nyújt különböző értékpapírpiacokon történő kereskedés lehetőségéhez, értékpapírok tárolására szolgáló letéti szolgáltatásokat, magán- és nagytőkével rendelkező magánszemélyek számára vagyonkezelési szolgáltatásokat, más társaságok számára értékpapír-kibocsátási szolgáltatásokat. . Az Alfa-Bank befektetési üzletága másodpercenként több mint 3 ezer jegyzést foglal magában, amelyeket különböző kereskedési platformokról töltenek le. A munkanap során több mint 300 ezer tranzakciót kötnek a piacokon a bank vagy ügyfelei nevében. Külső és belső platformokon másodpercenként akár 5 ezer megrendelés végrehajtása is előfordul. Ugyanakkor minden belső és külső ügyfél valós időben szeretné látni pozícióit.

őstörténet

Valahol a 2000-es évek elejétől önállóan fejlődtek befektetési üzletágaink: tőzsdei kereskedés, brókerszolgáltatás, devizakereskedelem, tőzsdén kívüli értékpapír- és különböző származékos kereskedés. Ennek eredményeként a funkcionális kutak csapdájába estünk. Ami? Minden üzletágnak megvannak a saját rendszerei, amelyek megkettőzik egymás funkcióit. Minden rendszernek megvan a saját adatmodellje, bár ugyanazokkal a fogalmakkal működnek: tranzakciók, instrumentumok, partnerek, jegyzések stb. És ahogy az egyes rendszerek egymástól függetlenül fejlődtek, a technológiák változatos állatkertje alakult ki.

Ráadásul a rendszerek kódbázisa már eléggé elavult, mert egyes termékek az 1990-es évek közepétől származnak. És bizonyos területeken ez lelassította a fejlesztési folyamatot, és teljesítményproblémák adódtak.

Új megoldás követelményei

A vállalkozások felismerték, hogy a technológiai átalakulás elengedhetetlen a további fejlődéshez. Feladatokat kaptunk:

1. Gyűjtse össze az összes üzleti adatot egyetlen, gyors tárolóban és egyetlen adatmodellben.
2. Ezeket az információkat nem szabad elveszítenünk vagy megváltoztatnunk.
3. Az adatok verziószámítása szükséges, mert a szabályozó bármikor kérhet statisztikai adatokat a korábbi évekre vonatkozóan.
4. Nem csak egy új, divatos DBMS-t kell hoznunk, hanem platformot kell teremtenünk az üzleti problémák megoldására.

Ezen kívül építészeink saját feltételeiket szabják meg:

1. Az új megoldásnak vállalati szintűnek kell lennie, vagyis néhány nagyvállalatnál már tesztelni kell.
2. A megoldás működési módjának küldetéskritikusnak kell lennie. Ez azt jelenti, hogy egyszerre több adatközpontban kell jelen lennünk, és nyugodtan túl kell élnünk egy adatközpont kiesését.
3. A rendszernek vízszintesen méretezhetőnek kell lennie. Az tény, hogy minden jelenlegi rendszerünk csak vertikálisan skálázható, és a hardveres teljesítmény alacsony növekedése miatt máris a plafont ütjük. Ezért eljött a pillanat, amikor vízszintesen skálázható rendszerre van szükségünk a túléléshez.
4. Többek között azt mondták nekünk, hogy a megoldásnak olcsónak kell lennie.

A szokásos utat követtük: megfogalmaztuk a követelményeket és felvettük a kapcsolatot a beszerzési részleggel. Innen kaptunk egy listát azokról a cégekről, amelyek általában készek ezt megtenni helyettünk. Mindenkinek elmondtuk a problémát, hattól kaptunk értékelést a megoldásokról.

A bankban nem fogadunk szót senkinek, szeretünk mindent magunk tesztelni. Ezért pályázatunk kötelező feltétele volt a terhelési tesztek teljesítése. Terhelésvizsgálati feladatokat fogalmaztunk meg, és hat cégből három már vállalta, hogy saját költségén implementál egy memóriatechnológiákra épülő prototípus-megoldást annak tesztelésére.

Nem árulom el, hogyan teszteltünk mindent és mennyi ideig tartott, csak összefoglalom: a terhelési teszteken a legjobb teljesítményt a Mail.ru Group fejlesztőcsapatának Tarantool-on alapuló prototípus-megoldása mutatta. Megállapodást írtunk alá és megkezdtük a fejlesztést. A Mail.ru Csoporttól négyen, az Alfa-Banktól pedig három fejlesztő, három rendszerelemző, egy megoldástervező, egy terméktulajdonos és egy Scrum mester volt jelen.

A következőkben elmondom, hogyan fejlődött a rendszerünk, hogyan fejlődött, mit tettünk és miért pont ez.

tervezés

Az első kérdés, amit feltettünk magunknak, az volt, hogyan szerezzünk adatokat a jelenlegi rendszereinkből. Úgy döntöttünk, hogy a HTTP nagyon megfelelő számunkra, mivel az összes jelenlegi rendszer HTTP-n keresztül XML vagy JSON elküldésével kommunikál egymással.

Azért használjuk a Tarantoolba épített HTTP szervert, mert nem kell SSL munkameneteket megszakítanunk, és a teljesítménye is elegendő számunkra.

Ahogy már mondtam, minden rendszerünk különböző adatmodellekben él, és a bemeneten az objektumot ahhoz a modellhez kell hoznunk, amelyet mi magunk írunk le. Szükség volt egy nyelvre, amely lehetővé tette az adatok átalakítását. A kötelező Lua-t választottuk. Minden adatkonverziós kódot homokozóban futtatunk – ez egy biztonságos hely, amelyen túl a futó kód nem megy tovább. Ehhez egyszerűen betöltjük a szükséges kódot, és olyan funkciókkal rendelkező környezetet hozunk létre, amelyek nem tudnak semmit sem blokkolni, sem eldobni.

Az átalakítás után ellenőrizni kell, hogy az adatok megfelelnek-e az általunk készített modellnek. Sokáig vitatkoztunk, hogy mi legyen a modell és milyen nyelven írjuk le. Az Apache Avro-t választottuk, mert a nyelv egyszerű, és támogatja a Tarantool-tól. A modell és egyedi kód új verziói naponta többször, akár terhelés alatt vagy anélkül, a nap bármely szakában üzembe helyezhetők, és nagyon gyorsan alkalmazkodnak a változásokhoz.

Az ellenőrzést követően az adatokat el kell menteni. Ezt a vshard segítségével tesszük (a szilánkok földrajzilag szétszórt replikái vannak).

Ráadásul a specifikum olyan, hogy a legtöbb nekünk adatokat küldő rendszernek nem mindegy, hogy megkaptuk-e vagy sem. Ezért már a kezdetektől bevezettünk egy javítási sort. Ami? Ha egy objektum valamilyen oknál fogva nem megy át adatátalakításon vagy ellenőrzésen, akkor is megerősítjük az átvételt, de egyben mentjük az objektumot a javítási sorba. Konzisztens, és a fő üzleti adattárházban található. Rögtön írtunk hozzá egy rendszergazdai felületet, különféle mérőszámokat, riasztásokat. Ennek eredményeként nem veszítünk el adatokat. Még akkor is, ha valami változott a forrásban, ha az adatmodell megváltozott, azonnal észleljük és alkalmazkodhatunk.

Most meg kell tanulnia, hogyan kérheti le a mentett adatokat. Gondosan elemeztük rendszereinket, és láttuk, hogy a Java és az Oracle klasszikus halma szükségszerűen tartalmaz valamilyen ORM-et, amely az adatokat relációsból objektummá konvertálja. Akkor miért nem adunk objektumokat azonnal a rendszereknek gráf formájában? Így boldogan elfogadtuk a GraphQL-t, amely minden igényünket kielégítette. Lehetővé teszi adatok fogadását grafikonok formájában, és csak azt húzza ki, amire éppen szüksége van. Még az API-t is nagyon rugalmasan verziózhatja.

Szinte azonnal rájöttünk, hogy az általunk kinyert adatok nem elegendőek. Olyan függvényeket hoztunk létre, amelyek a modellben szereplő objektumokhoz kapcsolhatók - lényegében számított mezők. Azaz egy bizonyos függvényt csatolunk a mezőhöz, ami például kiszámolja az átlagos árajánlatot. Az adatokat kérő külső fogyasztó pedig nem is tudja, hogy ez egy számított mező.

Bevezetett egy hitelesítési rendszert.

Aztán észrevettük, hogy döntésünkben több szerep is kikristályosodott. A szerep a funkciók egyfajta aggregátora. A szerepkörök általában eltérő eszközhasználati profillal rendelkeznek:

• T-Connect: kezeli a bejövő kapcsolatokat, CPU korlátozott, alacsony memóriafogyasztás, állapotmentes.
• IB-Core: átalakítja a Tarantool protokollon keresztül kapott adatokat, azaz táblákkal operál. Ezenkívül nem tárolja az állapotot, és méretezhető.
• Tárolás: csak adatokat tárol, logikát nem használ. Ez a szerepkör a legegyszerűbb felületeket valósítja meg. A vshardnak köszönhetően méretezhető.

Vagyis szerepek segítségével a klaszter különböző részeit leválasztottuk egymástól, amelyek egymástól függetlenül skálázhatók.

Létrehoztunk tehát egy aszinkron tranzakciós adatfolyam rögzítést és egy adminisztrátori felülettel rendelkező javítási sort. A rögzítés üzleti szempontból aszinkron: ha garantáltan adatokat írunk magunknak, mindegy, hogy hol, akkor visszaigazoljuk. Ha nem erősítik meg, akkor valami hiba történt, és el kell küldeni az adatokat. Ez az aszinkron felvétel.

tesztelés

Már a projekt elején elhatároztuk, hogy megpróbáljuk megvalósítani a tesztvezérelt fejlesztést. Lua nyelven egységteszteket írunk a tarantool/tap keretrendszerrel, és integrációs teszteket Pythonban a pytest keretrendszer használatával. Ugyanakkor fejlesztőket és elemzőket is bevonunk az integrációs tesztek írásába.

Hogyan használjuk a tesztvezérelt fejlesztést?

Ha valami új funkciót akarunk, először megpróbálunk hozzá tesztet írni. Ha hibát észlelünk, először írjunk tesztet, és csak azután javítsuk ki. Eleinte nehéz így dolgozni, a dolgozók részéről félreértés, sőt szabotázs is történik: „Most gyorsan javítsuk ki, csináljunk valami újat, aztán fedjük le tesztekkel.” Csak ez a „később” szinte soha nem jön el.

Ezért kényszerítened kell magad, hogy először teszteket írj, és másokat kérj meg erre. Higgye el, a tesztvezérelt fejlesztés már rövid távon is hoz előnyöket. Érezni fogod, hogy könnyebb lett az életed. Úgy érezzük, hogy a kód 99%-át most már tesztelik. Ez soknak tűnik, de nincs semmi problémánk: minden véglegesítéskor lefutnak a tesztek.

Leginkább azonban a terheléses tesztelést szeretjük, ezt tartjuk a legfontosabbnak és rendszeresen végezzük.

Elmesélek egy kis történetet arról, hogyan végeztük el az egyik első verzió terhelési tesztelésének első szakaszát. Telepítettük a rendszert a fejlesztő laptopjára, bekapcsoltuk a terhelést és másodpercenként 4 ezer tranzakciót kaptunk. Laptophoz jó eredmény. Négy szerverből álló virtuális terhelési padra telepítettük, gyengébb, mint a termelésben. Minimálisra telepítve. Futtatjuk, és egy szálon belül rosszabb eredményt kapunk, mint egy laptopon. Sokkoló tartalom.

Nagyon szomorúak voltunk. Megnézzük a szerverterhelést, de kiderül, hogy tétlenek.

Felhívjuk a fejlesztőket, és elmagyarázzák nekünk, a Java világából érkezőknek, hogy a Tarantool egyszálú. Terhelés alatt csak egy processzormag tudja hatékonyan használni. Ezután minden szerveren a lehető legtöbb Tarantool példányt telepítettük, bekapcsoltuk a terhelést és már 14,5 ezer tranzakció érkezett másodpercenként.

Hadd magyarázzam el még egyszer. Az erőforrásokat eltérően használó szerepkörökre való felosztás miatt a kapcsolatok feldolgozásáért és az adatátalakításért felelős szerepköreink csak a processzort terhelték, szigorúan a terheléssel arányosan.

Ebben az esetben a memóriát csak a bejövő kapcsolatok és ideiglenes objektumok feldolgozására használták.

Éppen ellenkezőleg, a tárolószervereken a processzor terhelése nőtt, de sokkal lassabban, mint a kapcsolatokat feldolgozó szervereken.

A memóriafelhasználás pedig egyenes arányban nőtt a betöltött adatok mennyiségével.

Szolgáltatások

Ahhoz, hogy új termékünket kifejezetten alkalmazásplatformként fejleszthessük, létrehoztunk egy komponenst a szolgáltatások és könyvtárak telepítéséhez.

A szolgáltatások nem csupán kis kódrészletek, amelyek bizonyos mezőkön működnek. Ezek meglehetősen nagy és összetett struktúrák lehetnek, amelyek egy fürt részét képezik, ellenőrzik a referenciaadatokat, futtatják az üzleti logikát és válaszokat adnak vissza. A szolgáltatássémát a GraphQL-be ​​is exportáljuk, és a fogyasztó univerzális hozzáférési pontot kap az adatokhoz, a teljes modellen belüli betekintéssel. Nagyon kényelmes.

Mivel a szolgáltatások sokkal több funkciót tartalmaznak, úgy döntöttünk, hogy kellenek olyan könyvtárak, amelyekbe áthelyezzük a gyakran használt kódokat. Hozzáadtuk őket a biztonságos környezethez, miután előzőleg ellenőriztük, hogy nem ront el semmit számunkra. Mostantól pedig további környezeteket rendelhetünk a függvényekhez könyvtárak formájában.

Nemcsak a tároláshoz, hanem a számítástechnikához is szerettünk volna egy platformot létrehozni. És mivel már volt egy rakás replikánk és szilánkunk, egyfajta elosztott számítást valósítottunk meg, és ezt map Redukciónak neveztük el, mert hasonló lett az eredeti map redukcióhoz.

Régi rendszerek

Nem minden régebbi rendszerünk képes HTTP-n keresztül hívni minket, és használni a GraphQL-t, bár támogatja a protokollt. Ezért létrehoztunk egy olyan mechanizmust, amely lehetővé teszi az adatok replikálását ezekbe a rendszerekbe.

Ha valami megváltozik a számunkra, egyedi triggerek aktiválódnak a Storage szerepkörben, és a változásokat tartalmazó üzenet a feldolgozási sorba kerül. Külső rendszernek küldik el egy külön replikátori szerepkör használatával. Ez a szerepkör nem tárolja az állapotot.

Új fejlesztések

Mint emlékszel, üzleti szempontból aszinkron felvételt készítettünk. De aztán rájöttek, hogy ez nem lesz elég, mert van egy osztály a rendszereknek, amelyeknek azonnal választ kell kapniuk a művelet állapotáról. Ezért kiterjesztettük a GraphQL-t, és mutációkat adtunk hozzá. Szervesen illeszkednek az adatokkal való munka meglévő paradigmájába. Számunkra ez az olvasás és az írás egyetlen pontja egy másik rendszerosztály számára.

Arra is rájöttünk, hogy a szolgáltatások önmagukban nem elegendőek számunkra, mert elég súlyos riportok vannak, amelyeket naponta, hetente, havonta egyszer kell elkészíteni. Ez sokáig tarthat, és a jelentések akár a Tarantool eseményhurkát is blokkolhatják. Ezért külön szerepköröket hoztunk létre: ütemezőt és futtatót. A futók nem tárolják az állapotot. Nehéz feladatokat hajtanak végre, amelyeket nem tudunk menet közben kiszámítani. Az ütemező szerepkör pedig figyeli ezeknek a feladatoknak az indítási ütemezését, amely a konfigurációban van leírva. Maguk a feladatok ugyanazon a helyen vannak tárolva, mint az üzleti adatok. Amikor eljön a megfelelő idő, az ütemező felveszi a feladatot, odaadja valamelyik futónak, aki megszámolja és elmenti az eredményt.

Nem kell minden feladatot ütemezetten végrehajtani. Egyes jelentéseket igény szerint el kell olvasni. Amint ez a követelmény megérkezik, egy feladat jön létre a homokozóban, és elküldi a futónak végrehajtásra. Egy idő után a felhasználó aszinkron választ kap, hogy mindent kiszámoltak, és a jelentés kész.

Kezdetben ragaszkodtunk ahhoz a paradigmához, hogy minden adatot tárolunk, verziózunk, és ne töröljük. De az életben időnként mégis törölni kell valamit, többnyire nyers vagy köztes információkat. A lejárat alapján létrehoztunk egy mechanizmust a tárhely megtisztítására az elavult adatoktól.

Azt is megértjük, hogy előbb-utóbb eljön az a helyzet, amikor nem lesz elég hely az adatok tárolására a memóriában, de ennek ellenére az adatokat tárolni kell. Ebből a célból hamarosan lemezes tárolást készítünk.

Következtetés

Azzal a feladattal kezdtük, hogy adatokat töltsünk be egyetlen modellbe, és három hónapot töltöttünk a fejlesztésével. Hat adatszolgáltató rendszerünk volt. A teljes átalakítási kód egyetlen modellbe körülbelül 30 ezer sor Lua-ban. És a munka nagy része még hátra van. Néha hiányzik a motiváció a szomszédos csapatokból, és sok körülmény nehezíti a munkát. Ha valaha is hasonló feladattal szembesül, szorozza meg hárommal, vagy akár néggyel a számodra normálisnak tűnő időt a végrehajtásához.

Ne feledje azt is, hogy az üzleti folyamatokban meglévő problémákat nem lehet új DBMS-sel megoldani, még egy nagyon produktív is. Mire gondolok? Projektünk indulásakor azt a benyomást keltettük az ügyfelekben, hogy most hozunk egy új gyors adatbázist és élni fogunk! Gyorsabban mennek a folyamatok, minden rendben lesz. Valójában a technológia nem oldja meg az üzleti folyamatokkal kapcsolatos problémákat, mivel az üzleti folyamatok emberek. És emberekkel kell dolgozni, nem technológiával.

A tesztvezérelt fejlesztés fájdalmas és időigényes lehet a korai szakaszban. De ennek pozitív hatása még rövid távon is érezhető lesz, amikor már nem kell semmit tennie a regressziós teszt elvégzéséhez.

Rendkívül fontos a terhelési teszt elvégzése a fejlesztés minden szakaszában. Minél hamarabb észlel valamilyen hibát az architektúrában, annál könnyebb lesz kijavítani, amivel sok időt takaríthat meg a jövőben.

Nincs semmi baj Luával. Bárki megtanulhat benne írni: Java fejlesztő, JavaScript fejlesztő, Python fejlesztő, front-end vagy back-end. Még elemzőink is írnak róla.

Ha arról beszélünk, hogy nincs SQL-ünk, az megrémíti az embereket. „Hogyan szerezhet be adatokat SQL nélkül? Ez lehetséges? Biztosan. Egy OLTP osztályú rendszerben nincs szükség SQL-re. Van egy alternatíva valamilyen nyelv formájában, amely azonnal visszatér a dokumentum-orientált nézethez. Például GraphQL. És van egy alternatíva az elosztott számítástechnika formájában.

Ha megérti, hogy méretezni kell, akkor tervezze meg megoldását a Tarantool-on úgy, hogy az párhuzamosan futhasson több tucat Tarantool-példányon. Ha ezt nem teszi meg, később nehéz és fájdalmas lesz, hiszen a Tarantool csak egy processzormagot tud hatékonyan használni.

Forrás: will.com