Kadr iz filma “Naš tajni svemir: Skriveni život ćelije”

Investicijski posao jedno je od najsloženijih područja u bankarskom svijetu, jer ne postoje samo krediti, posudbe i depoziti, već i vrijednosni papiri, valute, roba, derivati ​​i sve vrste složenosti u obliku strukturiranih proizvoda.

U posljednje vrijeme bilježimo porast financijske pismenosti stanovništva. Sve više i više ljudi uključuje se u trgovanje na tržištima vrijednosnih papira. Individualni investicijski računi pojavili su se ne tako davno. Omogućuju vam trgovanje na tržištima vrijednosnih papira i primanje poreznih olakšica ili izbjegavanje plaćanja poreza. I svi klijenti koji nam dolaze žele upravljati svojim portfeljem i vidjeti izvješća u stvarnom vremenu. Štoviše, najčešće je ovaj portfelj višeproizvodni, odnosno ljudi su klijenti različitih poslovnih linija.

Osim toga, rastu potrebe regulatora, kako ruskih tako i stranih.

Kako bismo zadovoljili trenutne potrebe i postavili temelje za buduće nadogradnje, razvili smo investicijsku poslovnu jezgru temeljenu na Tarantoolu.

Malo statistike. Investicijsko poslovanje Alfa-Bank pruža brokerske usluge za pojedince i pravne osobe za pružanje mogućnosti trgovanja na različitim tržištima vrijednosnih papira, usluge depozitara za pohranu vrijednosnih papira, usluge povjereničkog upravljanja za pojedince s privatnim i velikim kapitalom, usluge izdavanja vrijednosnih papira za druge tvrtke . Investicijski posao Alfa-Bank uključuje više od 3 tisuće citata u sekundi, koji se preuzimaju s različitih platformi za trgovanje. Tijekom radnog dana na tržištima se sklopi više od 300 tisuća transakcija u ime banke ili njenih klijenata. Na vanjskim i internim platformama događa se do 5 tisuća izvršenja naloga u sekundi. Istovremeno, svi klijenti, interni i eksterni, žele vidjeti svoje pozicije u realnom vremenu.

prapovijest

Negdje od početka 2000-ih samostalno su se razvijala naša područja investicijskog poslovanja: burzovno trgovanje, brokerske usluge, trgovanje valutama, izvanberzansko trgovanje vrijednosnim papirima i raznim izvedenicama. Kao rezultat toga, upali smo u zamku funkcionalnih bunara. Što je? Svaka linija poslovanja ima vlastite sustave koji dupliciraju funkcije drugih. Svaki sustav ima vlastiti model podataka, iako rade s istim konceptima: transakcije, instrumenti, druge ugovorne strane, kotacije itd. I kako se svaki sustav neovisno razvijao, pojavio se raznolik zoološki vrt tehnologija.

Osim toga, kodna baza sustava već je prilično zastarjela, jer su neki proizvodi nastali sredinom 1990-ih. U nekim je područjima to usporilo razvojni proces i bilo je problema s izvedbom.

Zahtjevi za novo rješenje

Poduzeća su shvatila da je tehnološka transformacija ključna za daljnji razvoj. Dobili smo zadatke:

1. Prikupite sve poslovne podatke u jednoj, brzoj pohrani iu jednom podatkovnom modelu.
2. Ove podatke ne smijemo izgubiti ili promijeniti.
3. Podatke je potrebno verzirati jer u svakom trenutku regulator može zatražiti statistiku za prethodne godine.
4. Ne smijemo samo donijeti neki novi, pomodni DBMS, nego stvoriti platformu za rješavanje poslovnih problema.

Osim toga, naši arhitekti postavljaju vlastite uvjete:

1. Novo rješenje mora biti enterprise-class, odnosno mora biti već testirano u nekim velikim tvrtkama.
2. Način rada rješenja trebao bi biti kritičan. To znači da moramo biti prisutni u više podatkovnih centara istovremeno i mirno preživjeti ispad jednog podatkovnog centra.
3. Sustav mora biti horizontalno skalabilan. Činjenica je da su svi naši trenutni sustavi samo vertikalno skalabilni, a već smo dosegli plafon zbog niskog rasta hardverske snage. Dakle, došao je trenutak kada moramo imati horizontalno skalabilan sustav da bismo preživjeli.
4. Između ostalog, rečeno nam je da rješenje mora biti jeftino.

Slijedili smo standardni put: formulirali smo zahtjeve i kontaktirali odjel nabave. Od tamo smo dobili popis tvrtki koje su, općenito, spremne to učiniti za nas. Svima smo ispričali problem, a od šestero smo dobili ocjenu rješenja.

U banci nikome ne vjerujemo na riječ, volimo sve sami testirati. Stoga je obavezni uvjet našeg natječaja bio prolazak testa opterećenja. Formulirali smo zadatke testiranja opterećenja, a tri od šest tvrtki već su pristale implementirati prototip rješenja temeljenog na in-memorijskim tehnologijama o vlastitom trošku kako bi ga testirali.

Neću vam reći kako smo sve testirali i koliko je dugo trajalo, samo ću sažeti: najbolju izvedbu u testovima opterećenja pokazao je prototip rješenja temeljen na Tarantoolu iz razvojnog tima Mail.ru Group. Potpisali smo ugovor i krenuli u razvoj. Bilo je četvero ljudi iz Mail.ru Group, a iz Alfa-Bank tri programera, tri sistemska analitičara, arhitekt rješenja, product owner i Scrum master.

Zatim ću vam reći kako je naš sustav rastao, kako se razvijao, što smo radili i zašto baš to.

dizajn

Prvo pitanje koje smo si postavili bilo je kako doći do podataka iz naših trenutnih sustava. Odlučili smo da je HTTP sasvim prikladan za nas, jer svi trenutni sustavi međusobno komuniciraju slanjem XML-a ili JSON-a preko HTTP-a.

Koristimo HTTP poslužitelj ugrađen u Tarantool jer ne moramo prekidati SSL sesije, a njegova izvedba nam je dovoljna.

Kao što sam već rekao, svi naši sustavi žive u različitim modelima podataka, a na ulazu trebamo objekt dovesti u model koji sami opisujemo. Bio je potreban jezik koji je omogućio transformaciju podataka. Izabrali smo imperativ Lua. Sav kôd za pretvorbu podataka izvodimo u sandboxu - ovo je sigurno mjesto izvan kojeg kôd koji se izvodi ne ide. Da bismo to učinili, jednostavno učitavamo traženi kod, stvarajući okruženje s funkcijama koje ne mogu ništa blokirati ili ispustiti.

Nakon konverzije, podatke je potrebno provjeriti u skladu s modelom koji stvaramo. Dugo smo raspravljali o tome kakav bi model trebao biti i kojim jezikom ga opisati. Odabrali smo Apache Avro jer je jezik jednostavan i ima podršku Tarantoola. Nove verzije modela i prilagođenog koda mogu se pustiti u rad nekoliko puta dnevno, čak i pod opterećenjem ili bez njega, u bilo koje doba dana, te se vrlo brzo prilagoditi promjenama.

Nakon provjere podatke je potrebno spremiti. To radimo pomoću vshard-a (imamo geo-raspršene replike shardova).

Štoviše, specifičnost je takva da većini sustava koji nam šalju podatke nije bitno jesmo li ih primili ili ne. Zato smo od samog početka implementirali red čekanja za popravke. Što je? Ako iz nekog razloga objekt ne prođe transformaciju podataka ili provjeru, svejedno potvrđujemo primitak, ali istovremeno spremamo objekt u red čekanja za popravak. Konzistentan je i nalazi se u glavnom skladištu poslovnih podataka. Odmah smo napisali administratorsko sučelje za njega, razne metrike i upozorenja. Kao rezultat toga, ne gubimo podatke. Čak i ako se nešto promijenilo u izvoru, ako se promijenio model podataka, mi ćemo to odmah otkriti i možemo se prilagoditi.

Sada morate naučiti kako dohvatiti spremljene podatke. Pažljivo smo analizirali naše sustave i uvidjeli da klasični hrp Jave i Oraclea nužno sadrži neku vrstu ORM-a koji pretvara podatke iz relacijskih u objektne. Pa zašto ne odmah dati objekte sustavima u obliku grafikona? Stoga smo sretno prihvatili GraphQL, koji je zadovoljio sve naše potrebe. Omogućuje vam primanje podataka u obliku grafikona i izvlačenje samo onoga što vam je trenutno potrebno. Možete čak i verzirati API s dosta fleksibilnosti.

Gotovo odmah smo shvatili da podaci koje izdvajamo nisu dovoljni. Napravili smo funkcije koje se mogu povezati s objektima u modelu - u biti izračunata polja. Odnosno, polju pridajemo određenu funkciju koja, na primjer, izračunava prosječnu kotiranu cijenu. A vanjski potrošač koji traži podatke niti ne zna da je to izračunato polje.

Implementiran sustav provjere autentičnosti.

Tada smo primijetili da se u našoj odluci iskristaliziralo nekoliko uloga. Uloga je vrsta skupljača funkcija. Obično uloge imaju različite profile korištenja opreme:

• T-Connect: upravlja dolaznim vezama, CPU ograničen, mala potrošnja memorije, bez stanja.
• IB-Core: transformira podatke koje prima preko Tarantool protokola, odnosno operira s tablicama. Također ne pohranjuje stanje i skalabilan je.
• Pohrana: samo pohranjuje podatke, ne koristi nikakvu logiku. Ova uloga implementira najjednostavnija sučelja. Skalabilan zahvaljujući vshard-u.

Odnosno, koristeći uloge, odvojili smo različite dijelove klastera jedan od drugog, koji se mogu skalirati neovisno jedan o drugom.

Dakle, stvorili smo asinkrono snimanje transakcijskog toka podataka i red čekanja za popravak s administratorskim sučeljem. Snimanje je asinkrono s poslovne točke gledišta: ako je zajamčeno da ćemo sami sebi zapisati podatke, bez obzira gdje, tada ćemo to potvrditi. Ako nije potvrđeno, onda je nešto pošlo po zlu i podatke treba poslati. Ovo je asinkrono snimanje.

Testiranje

Od samog početka projekta odlučili smo da ćemo pokušati implementirati test vođen razvoj. Pišemo jedinične testove u Lua koristeći okvir tarantool/tap, a testove integracije u Python koristeći okvir pytest. U isto vrijeme uključujemo i programere i analitičare u pisanje integracijskih testova.

Kako koristimo razvoj vođen testiranjem?

Ako želimo neku novu značajku, prvo pokušamo napisati test za nju. Kada otkrijemo grešku, prvo napišemo test, a tek onda je popravimo. U početku je teško ovako raditi, postoji nerazumijevanje od strane zaposlenika, čak i sabotaža: “Ajmo sad to brzo srediti, napraviti nešto novo, a onda to pokriti testovima.” Samo što ovo “kasnije” gotovo nikad ne dolazi.

Stoga se prvo morate natjerati da pišete testove i zamoliti druge da to rade. Vjerujte mi, testni razvoj donosi dobrobit čak i kratkoročno. Osjetit ćete da vam je život postao lakši. Smatramo da je 99% koda sada pokriveno testovima. Čini se da je to puno, ali nemamo nikakvih problema: testovi se pokreću pri svakom izdavanju.

Ipak, ono što najviše volimo je testiranje opterećenja, smatramo ga najvažnijim i redovito ga provodimo.

Ispričat ću vam malu priču o tome kako smo proveli prvu fazu testiranja opterećenja jedne od prvih verzija. Instalirali smo sustav na prijenosno računalo programera, uključili opterećenje i primili 4 tisuće transakcija u sekundi. Dobar rezultat za laptop. Instalirali smo ga na virtualnu platformu za opterećenje od četiri poslužitelja, slabiju nego u proizvodnji. Raspoređen na minimum. Pokrenemo ga, a u jednoj temi dobijemo rezultat lošiji nego na laptopu. Šok sadržaj.

Bili smo jako tužni. Gledamo opterećenje poslužitelja, ali ispada da su u stanju mirovanja.

Zovemo developere, a oni nama, ljudima koji dolaze iz svijeta Jave, objasne da je Tarantool single-thread. Može ga učinkovito koristiti samo jedna jezgra procesora pod opterećenjem. Zatim smo rasporedili najveći mogući broj instanci Tarantoola na svakom poslužitelju, uključili opterećenje i već primili 14,5 tisuća transakcija u sekundi.

Dopustite mi da opet objasnim. Zbog podjele na uloge koje različito koriste resurse, naše uloge odgovorne za obradu veza i transformaciju podataka opterećivale su samo procesor, i to strogo proporcionalno opterećenju.

U ovom slučaju memorija je korištena samo za obradu dolaznih veza i privremenih objekata.

Naprotiv, na poslužiteljima za pohranu podataka povećalo se opterećenje procesora, ali puno sporije nego na poslužiteljima koji obrađuju veze.

A potrošnja memorije rasla je izravno proporcionalno količini učitanih podataka.

Usluge

Kako bismo razvili naš novi proizvod posebno kao aplikacijsku platformu, stvorili smo komponentu za implementaciju usluga i biblioteka na njemu.

Usluge nisu samo mali komadići koda koji rade na nekim poljima. Mogu biti prilično velike i složene strukture koje su dio klastera, provjeravaju referentne podatke, pokreću poslovnu logiku i vraćaju odgovore. Također izvozimo shemu usluge u GraphQL, a potrošač dobiva univerzalnu pristupnu točku podacima, s introspekcijom kroz cijeli model. Vrlo je udoban.

Budući da usluge sadrže mnogo više funkcija, odlučili smo da trebaju postojati biblioteke u koje ćemo premjestiti često korišteni kod. Dodali smo ih u sigurno okruženje, prethodno provjerivši da nam ništa ne kvari. A sada funkcijama možemo dodijeliti dodatna okruženja u obliku knjižnica.

Htjeli smo imati platformu ne samo za pohranu, već i za računalstvo. A budući da smo već imali hrpu replika i fragmenata, implementirali smo neku vrstu distribuiranog računalstva i nazvali ga map reduciranje, jer je ispalo slično izvornom map reduciranju.

Stari sustavi

Ne mogu nas svi naši stari sustavi zvati putem HTTP-a i koristiti GraphQL, iako podržavaju protokol. Stoga smo stvorili mehanizam koji omogućuje repliciranje podataka u te sustave.

Ako se nešto promijeni za nas, jedinstveni okidači se pokreću u ulozi Storage i poruka s promjenama završava u redu čekanja za obradu. Šalje se vanjskom sustavu pomoću zasebne uloge replikatora. Ova uloga ne pohranjuje stanje.

Nova poboljšanja

Kao što se sjećate, s poslovne točke gledišta radili smo asinkrono snimanje. Ali onda su shvatili da to neće biti dovoljno, jer postoji klasa sustava koji moraju odmah dobiti odgovor o statusu operacije. Stoga smo proširili naš GraphQL i dodali mutacije. Organski se uklapaju u postojeću paradigmu rada s podacima. Za nas je ovo jedna točka za čitanje i pisanje za drugu klasu sustava.

Također smo shvatili da nam same usluge neće biti dovoljne, jer postoje dosta teški izvještaji koje treba graditi jednom dnevno, tjedno, mjesečno. To može potrajati dugo, a izvješća mogu čak blokirati Tarantool-ovu petlju događaja. Stoga smo kreirali zasebne uloge: planer i runner. Trkači ne pohranjuju stanje. Oni izvršavaju teške zadatke koje ne možemo izračunati u hodu. A uloga planera nadzire raspored pokretanja ovih zadataka, koji je opisan u konfiguraciji. Sami zadaci pohranjuju se na istom mjestu kao i poslovni podaci. Kada dođe pravo vrijeme, rokovnik preuzima zadatak, daje ga nekom trkaču, koji ga broji i sprema rezultat.

Ne moraju se svi zadaci izvoditi prema rasporedu. Neka izvješća treba čitati na zahtjev. Čim stigne ovaj zahtjev, zadatak se stvara u sandboxu i šalje pokretaču na izvršenje. Nakon nekog vremena korisnik dobiva asinkroni odgovor da je sve izračunato i da je izvještaj spreman.

U početku smo se pridržavali paradigme pohranjivanja svih podataka, njihove verzije i nebrisanja. Ali u životu s vremena na vrijeme ipak morate nešto izbrisati, uglavnom neke sirove ili srednje informacije. Na temelju expirationd napravili smo mehanizam za čišćenje pohrane od zastarjelih podataka.

Također razumijemo da će prije ili kasnije doći do situacije kada neće biti dovoljno prostora za pohranjivanje podataka u memoriju, ali svejedno podatke treba pohraniti. Za te potrebe uskoro ćemo napraviti i disk pohranu.

Zaključak

Počeli smo sa zadatkom učitavanja podataka u jedan model i proveli tri mjeseca razvijajući ga. Imali smo šest sustava za opskrbu podacima. Cijeli kod transformacije u jedan model je oko 30 tisuća redaka u Lua. A najveći dio posla tek predstoji. Ponekad nedostaje motivacije susjednih momčadi, a puno je okolnosti koje otežavaju rad. Ako se ikada suočite sa sličnim zadatkom, tada vrijeme koje vam se čini normalnim za njegovu provedbu pomnožite s tri, pa čak i četiri.

Također zapamtite da se postojeći problemi u poslovnim procesima ne mogu riješiti pomoću novog DBMS-a, čak ni vrlo produktivnog. Što mislim? Na početku našeg projekta stvorili smo dojam kod kupaca da ćemo sada donijeti novu brzu bazu podataka i živjet ćemo! Procesi će ići brže, sve će biti u redu. Zapravo, tehnologija ne rješava probleme koje imaju poslovni procesi, jer poslovni procesi su ljudi. I treba raditi s ljudima, a ne s tehnologijom.

Razvoj vođen testiranjem može biti bolan i dugotrajan u ranim fazama. Ali njegov pozitivan učinak bit će vidljiv čak i kratkoročno, kada ne morate ništa učiniti za provođenje regresijskog testiranja.

Iznimno je važno provesti testiranje opterećenja u svim fazama razvoja. Što prije uočite neki nedostatak u arhitekturi, lakše ćete ga popraviti, što će vam uštedjeti mnogo vremena u budućnosti.

Ništa nije u redu s Luom. Svatko može naučiti pisati u njemu: Java developer, JavaScript developer, Python developer, front-end ili back-end. Čak i naši analitičari pišu o tome.

Kad govorimo o tome da nemamo SQL, to ljude užasava. “Kako doći do podataka bez SQL-a? Je li to moguće? Sigurno. U sustavu klase OLTP, SQL nije potreban. Postoji alternativa u obliku neke vrste jezika koji vas odmah vraća u pogled orijentiran na dokument. Na primjer, GraphQL. A postoji alternativa u obliku distribuiranog računalstva.

Ako razumijete da ćete morati skalirati, tada dizajnirajte svoje rješenje na Tarantoolu na takav način da može raditi paralelno na desecima instanci Tarantoola. Ako to ne učinite, kasnije će biti teško i bolno, jer Tarantool može učinkovito koristiti samo jednu jezgru procesora.

Izvor: www.habr.com