Fotografie din filmul „Universul nostru secret: viața ascunsă a celulei”

Afacerea de investiții este una dintre cele mai complexe domenii din lumea bancară, deoarece nu există doar împrumuturi, împrumuturi și depozite, ci și valori mobiliare, valute, mărfuri, derivate și tot felul de complexități sub formă de produse structurate.

Recent, am observat o creștere a alfabetizării financiare a populației. Din ce în ce mai mulți oameni se implică în tranzacționarea pe piețele valorilor mobiliare. Conturile individuale de investiții au apărut nu cu mult timp în urmă. Acestea vă permit să tranzacționați pe piețele de valori mobiliare și fie să primiți deduceri fiscale, fie să evitați plata impozitelor. Și toți clienții care vin la noi doresc să își gestioneze portofoliul și să vadă raportarea în timp real. Mai mult decât atât, cel mai adesea acest portofoliu este multi-produs, adică oamenii sunt clienți ai diverselor linii de afaceri.

În plus, nevoile autorităților de reglementare, atât rusești, cât și străine, sunt în creștere.

Pentru a răspunde nevoilor actuale și a pune bazele actualizărilor viitoare, am dezvoltat un nucleu de investiții bazat pe Tarantool.

Câteva statistici. Afacerea de investiții a Alfa-Bank oferă servicii de brokeraj pentru persoane fizice și juridice pentru a oferi oportunitatea de tranzacționare pe diverse piețe de valori mobiliare, servicii de depozitare pentru depozitarea valorilor mobiliare, servicii de gestionare a încrederii pentru persoane fizice cu capital privat și mare, servicii de emitere de valori mobiliare pentru alte companii. . Afacerile de investiții ale Alfa-Bank includ peste 3 mii de cotații pe secundă, care sunt descărcate de pe diverse platforme de tranzacționare. Pe parcursul zilei de lucru, pe piețe se încheie peste 300 de mii de tranzacții în numele băncii sau al clienților acesteia. Până la 5 mii de execuții de comenzi pe secundă au loc pe platforme externe și interne. În același timp, toți clienții, atât interni cât și externi, doresc să-și vadă pozițiile în timp real.

preistorie

Undeva de la începutul anilor 2000, domeniile noastre de afaceri de investiții s-au dezvoltat independent: tranzacționare la bursă, servicii de brokeraj, tranzacționare valutară, tranzacționare over-the-counter cu titluri de valoare și diverse derivate. Drept urmare, am căzut în capcana puțurilor funcționale. Ce este? Fiecare linie de afaceri are propriile sisteme care dublează reciproc funcțiile. Fiecare sistem are propriul model de date, deși funcționează cu aceleași concepte: tranzacții, instrumente, contrapărți, cotații etc. Și pe măsură ce fiecare sistem a evoluat independent, a apărut o grădină zoologică diversă de tehnologii.

În plus, baza de cod a sistemelor este deja destul de depășită, deoarece unele produse au apărut la mijlocul anilor 1990. Și în unele zone acest lucru a încetinit procesul de dezvoltare și au existat probleme de performanță.

Cerințe pentru o nouă soluție

Întreprinderile și-au dat seama că transformarea tehnologică este vitală pentru dezvoltarea ulterioară. Ni s-au dat sarcini:

1. Colectați toate datele de afaceri într-o singură stocare rapidă și într-un singur model de date.
2. Nu trebuie să pierdem sau să modificăm aceste informații.
3. Este necesară versiunea datelor, deoarece în orice moment autoritatea de reglementare poate solicita statistici pentru anii anteriori.
4. Nu trebuie doar să aducem niște SGBD noi, la modă, ci să creăm o platformă pentru rezolvarea problemelor de afaceri.

În plus, arhitecții noștri își stabilesc propriile condiții:

1. Noua soluție trebuie să fie de clasă enterprise, adică trebuie deja testată în unele companii mari.
2. Modul de operare al soluției ar trebui să fie esențial. Aceasta înseamnă că trebuie să fim prezenți în mai multe centre de date simultan și să supraviețuim cu calm întreruperii unui singur centru de date.
3. Sistemul trebuie să fie scalabil pe orizontală. Faptul este că toate sistemele noastre actuale sunt doar scalabile pe verticală și atingem deja plafonul din cauza creșterii reduse a puterii hardware. Prin urmare, a venit momentul în care trebuie să avem un sistem scalabil pe orizontală pentru a supraviețui.
4. Printre altele, ni s-a spus că soluția trebuie să fie ieftină.

Am urmat calea standard: am formulat cerințele și am contactat departamentul de achiziții. De acolo am primit o listă de companii care, în general, sunt gata să facă asta pentru noi. Am spus tuturor despre problemă și am primit o evaluare a soluțiilor de la șase dintre ei.

La bancă, nu credem pe cuvânt al nimănui; ne place să testăm totul singuri. Prin urmare, o condiție obligatorie a concursului nostru de licitație a fost să treacă testele de încărcare. Am formulat sarcini de testare a sarcinii, iar trei din șase companii au fost deja de acord să implementeze o soluție prototip bazată pe tehnologii în memorie pe cheltuiala lor pentru a o testa.

Nu vă spun cum am testat totul și cât timp a durat, voi rezuma doar: cea mai bună performanță în testele de încărcare a fost demonstrată de o soluție prototip bazată pe Tarantool de la echipa de dezvoltare Mail.ru Group. Am semnat un acord și am început dezvoltarea. Erau patru oameni de la Mail.ru Group, iar de la Alfa-Bank erau trei dezvoltatori, trei analiști de sistem, un arhitect de soluții, un proprietar de produs și un Scrum master.

În continuare, vă voi spune despre cum a crescut sistemul nostru, cum a evoluat, ce am făcut și de ce anume acest lucru.

desen

Prima întrebare pe care ne-am pus-o a fost cum să obținem date din sistemele noastre actuale. Am decis că HTTP este destul de potrivit pentru noi, deoarece toate sistemele actuale comunică între ele prin trimiterea XML sau JSON prin HTTP.

Folosim serverul HTTP încorporat în Tarantool, deoarece nu trebuie să încheiem sesiunile SSL, iar performanța acestuia este suficientă pentru noi.

După cum am spus deja, toate sistemele noastre trăiesc în modele de date diferite, iar la intrare trebuie să aducem obiectul la modelul pe care ni-l descriem noi înșine. Era nevoie de un limbaj care să permită transformarea datelor. Am ales imperativ Lua. Rulăm toate codurile de conversie a datelor într-un sandbox - acesta este un loc sigur dincolo de care codul de rulare nu trece. Pentru a face acest lucru, pur și simplu încărcăm codul necesar, creând un mediu cu funcții care nu pot bloca sau arunca nimic.

După conversie, datele trebuie verificate pentru conformitatea cu modelul pe care îl creăm. Am discutat mult timp care ar trebui să fie modelul și ce limbaj să folosim pentru a-l descrie. Am ales Apache Avro pentru că limbajul este simplu și are suport de la Tarantool. Noile versiuni ale modelului și codului personalizat pot fi puse în funcțiune de mai multe ori pe zi, chiar și sub sarcină sau fără, în orice moment al zilei și se pot adapta la schimbări foarte rapid.

După verificare, datele trebuie salvate. Facem acest lucru folosind vshard (avem replici geo-disperse ale cioburi).

Mai mult, specificul este de așa natură încât majoritatea sistemelor care ne trimit date nu le pasă dacă le-am primit sau nu. De aceea am implementat o coadă de reparații încă de la început. Ce este? Dacă dintr-un motiv oarecare un obiect nu este supus transformării sau verificării datelor, totuși confirmăm primirea, dar în același timp salvăm obiectul în coada de reparații. Este consecvent și situat în depozitul principal de date de afaceri. Am scris imediat o interfață de administrator pentru acesta, diverse valori și alerte. Drept urmare, nu pierdem date. Chiar dacă ceva s-a schimbat în sursă, dacă modelul de date s-a schimbat, îl vom detecta imediat și ne putem adapta.

Acum trebuie să învățați cum să recuperați datele salvate. Ne-am analizat cu atenție sistemele și am văzut că stiva clasică de Java și Oracle conține în mod necesar un fel de ORM care convertește datele din relaționale în obiecte. Deci, de ce să nu dăm imediat obiecte sistemelor sub forma unui grafic? Așa că am adoptat cu bucurie GraphQL, care ne satisfacea toate nevoile. Vă permite să primiți date sub formă de grafice și să scoateți doar ceea ce aveți nevoie acum. Puteți chiar versiunea API-ului cu destulă flexibilitate.

Aproape imediat ne-am dat seama că datele pe care le extragem nu erau suficiente. Am creat funcții care pot fi legate de obiecte din model - în esență, câmpuri calculate. Adică atașăm câmpului o anumită funcție, care, de exemplu, calculează prețul mediu de cotație. Iar consumatorul extern care solicită datele nici nu știe că acesta este un câmp calculat.

Implementat un sistem de autentificare.

Apoi am observat că mai multe roluri s-au cristalizat în decizia noastră. Un rol este un fel de agregator de funcții. De obicei, rolurile au profiluri diferite de utilizare a echipamentelor:

• T-Connect: gestionează conexiunile de intrare, CPU limitat, consum redus de memorie, apatrid.
• IB-Core: transformă datele pe care le primește prin protocolul Tarantool, adică operează cu tabele. De asemenea, nu stochează starea și este scalabil.
• Stocare: stochează doar date, nu folosește nicio logică. Acest rol implementează cele mai simple interfețe. Scalabil datorită vshard.

Adică, folosind roluri, am decuplat diferite părți ale clusterului unele de altele, care pot fi scalate independent unele de altele.

Deci, am creat o înregistrare asincronă a fluxului de date tranzacționale și o coadă de reparații cu o interfață de administrare. Înregistrarea este asincronă din punct de vedere al afacerii: dacă suntem garantați să scriem date pentru noi înșine, indiferent unde, atunci o vom confirma. Dacă nu este confirmat, atunci ceva a mers prost și datele trebuie trimise. Aceasta este înregistrarea asincronă.

Testarea

Încă de la începutul proiectului, am decis că vom încerca să implementăm o dezvoltare bazată pe teste. Scriem teste unitare în Lua folosind cadrul tarantool/tap și teste de integrare în Python folosind cadrul pytest. În același timp, implicăm atât dezvoltatorii, cât și analiștii în scrierea testelor de integrare.

Cum folosim dezvoltarea bazată pe teste?

Dacă vrem o funcție nouă, încercăm mai întâi să scriem un test pentru aceasta. Când descoperim o eroare, ne asigurăm că scriem mai întâi un test și abia apoi îl remediam. La început este greu să lucrezi așa, există neînțelegeri din partea angajaților, chiar și sabotaj: „Să rezolvăm rapid acum, să facem ceva nou și apoi să-l acoperim cu teste.” Numai că acest „mai târziu” nu vine aproape niciodată.

Prin urmare, trebuie să vă forțați să scrieți mai întâi teste și să le cereți altora să o facă. Credeți-mă, dezvoltarea bazată pe teste aduce beneficii chiar și pe termen scurt. Vei simți că viața ta a devenit mai ușoară. Considerăm că 99% din cod este acum acoperit de teste. Pare mult, dar nu avem probleme: testele rulează la fiecare commit.

Cu toate acestea, ceea ce ne place cel mai mult este testarea sarcinii; o considerăm cea mai importantă și o efectuăm în mod regulat.

Vă voi spune o mică poveste despre modul în care am efectuat prima etapă a testării de încărcare a uneia dintre primele versiuni. Am instalat sistemul pe laptopul dezvoltatorului, am pornit încărcarea și am obținut 4 mii de tranzacții pe secundă. Rezultat bun pentru un laptop. L-am instalat pe un banc de încărcare virtual de patru servere, mai slab decât în ​​producție. Desfăşurat la minimum. Îl rulăm și obținem un rezultat mai rău decât pe un laptop într-un singur fir. Conținut de șoc.

Eram foarte tristi. Ne uităm la încărcarea serverului, dar se dovedește că sunt inactiv.

Sunăm dezvoltatorii și ei ne explică nouă, oameni care vin din lumea Java, că Tarantool este cu un singur thread. Poate fi utilizat eficient doar de un nucleu de procesor sub încărcare. Apoi am implementat numărul maxim posibil de instanțe Tarantool pe fiecare server, am pornit încărcarea și am primit deja 14,5 mii de tranzacții pe secundă.

Lasă-mă să explic din nou. Datorită împărțirii în roluri care folosesc resursele diferit, rolurile noastre responsabile cu procesarea conexiunilor și transformarea datelor au încărcat doar procesorul și strict proporțional cu sarcina.

În acest caz, memoria a fost folosită numai pentru procesarea conexiunilor de intrare și a obiectelor temporare.

Dimpotrivă, pe serverele de stocare, sarcina procesorului a crescut, dar mult mai lent decât pe serverele care procesează conexiuni.

Iar consumul de memorie a crescut direct proporțional cu cantitatea de date încărcate.

Servicii

Pentru a dezvolta noul nostru produs în mod specific ca platformă de aplicații, am creat o componentă pentru implementarea serviciilor și bibliotecilor pe acesta.

Serviciile nu sunt doar mici bucăți de cod care operează în anumite domenii. Ele pot fi structuri destul de mari și complexe care fac parte dintr-un cluster, verifică datele de referință, rulează logica de afaceri și returnează răspunsuri. De asemenea, exportăm schema de serviciu în GraphQL, iar consumatorul primește un punct de acces universal la date, cu introspecție în întregul model. Este foarte confortabil.

Deoarece serviciile conțin mult mai multe funcții, am decis că ar trebui să existe biblioteci în care vom muta codul folosit frecvent. Le-am adăugat în mediul sigur, după ce am verificat în prealabil că nu ne sparge nimic. Și acum putem atribui medii suplimentare funcțiilor sub formă de biblioteci.

Ne-am dorit să avem o platformă nu doar pentru stocare, ci și pentru calcul. Și din moment ce aveam deja o grămadă de replici și fragmente, am implementat un fel de calcul distribuit și l-am numit reducere de hărți, pentru că s-a dovedit similar cu reducerea hărții inițiale.

Sisteme vechi

Nu toate sistemele noastre vechi ne pot apela prin HTTP și folosi GraphQL, deși acceptă protocolul. Prin urmare, am creat un mecanism care permite replicarea datelor în aceste sisteme.

Dacă ceva se schimbă pentru noi, declanșatoarele unice sunt declanșate în rolul Stocare și mesajul cu modificările ajunge în coada de procesare. Este trimis la un sistem extern folosind un rol de replicator separat. Acest rol nu stochează starea.

Noi îmbunătățiri

După cum vă amintiți, din punct de vedere al afacerii, am făcut înregistrare asincronă. Dar apoi și-au dat seama că nu ar fi suficient, deoarece există o clasă de sisteme care trebuie să primească imediat un răspuns despre starea operațiunii. Așa că ne-am extins GraphQL și am adăugat mutații. Ele se încadrează organic în paradigma existentă de lucru cu date. Pentru noi, acesta este un singur punct de citire și scriere pentru o altă clasă de sisteme.

De asemenea, ne-am dat seama că numai serviciile nu ar fi suficiente pentru noi, pentru că sunt rapoarte destul de grele care trebuie construite o dată pe zi, pe săptămână, pe lună. Acest lucru poate dura mult timp, iar rapoartele pot chiar bloca bucla de evenimente a Tarantool. Prin urmare, am creat roluri separate: planificator și alergător. Alergătorii nu stochează starea. Ei execută sarcini grele pe care nu le putem calcula din mers. Și rolul de planificator monitorizează programul de lansare al acestor sarcini, care este descris în configurare. Sarcinile în sine sunt stocate în același loc cu datele de afaceri. Când vine momentul potrivit, planificatorul preia sarcina, o dă unui alergător, care o numără și salvează rezultatul.

Nu toate sarcinile trebuie executate conform unui program. Unele rapoarte trebuie citite la cerere. De îndată ce sosește această cerință, o sarcină este creată în sandbox și trimisă alergătorului pentru execuție. După ceva timp, utilizatorul primește un răspuns asincron că totul a fost calculat și raportul este gata.

Inițial, am aderat la paradigma de stocare a tuturor datelor, versiunea lor și nu ștergerea lor. Dar în viață, din când în când mai trebuie să ștergi ceva, mai ales câteva informații brute sau intermediare. Pe baza expirării, am creat un mecanism pentru curățarea stocării de date învechite.

Mai înțelegem că mai devreme sau mai târziu va veni o situație când nu va fi suficient spațiu pentru stocarea datelor în memorie, dar totuși datele trebuie stocate. În aceste scopuri, vom face în curând stocare pe disc.

Concluzie

Am început cu sarcina de a încărca datele într-un singur model și am petrecut trei luni să-l dezvoltăm. Aveam șase sisteme de furnizare a datelor. Întregul cod de transformare într-un singur model este de aproximativ 30 de mii de linii în Lua. Și cea mai mare parte a muncii este încă înainte. Uneori există o lipsă de motivație din partea echipelor vecine și sunt multe circumstanțe care complică munca. Dacă vă confruntați vreodată cu o sarcină similară, atunci înmulțiți timpul care vi se pare normal pentru implementarea ei cu trei sau chiar patru.

De asemenea, amintiți-vă că problemele existente în procesele de afaceri nu pot fi rezolvate folosind un nou SGBD, chiar și unul foarte productiv. Ce vreau să spun? La începutul proiectului nostru, am creat impresia în rândul clienților că acum vom aduce o nouă bază de date rapidă și vom trăi! Procesele vor merge mai repede, totul va fi bine. De fapt, tehnologia nu rezolvă problemele pe care le au procesele de afaceri, deoarece procesele de afaceri sunt oameni. Și trebuie să lucrezi cu oameni, nu cu tehnologia.

Dezvoltarea bazată pe teste poate fi dureroasă și consumatoare de timp în stadiile incipiente. Dar efectul pozitiv al acestuia va fi vizibil chiar și pe termen scurt, când nu trebuie să faceți nimic pentru a efectua teste de regresie.

Este extrem de important să se efectueze teste de sarcină în toate etapele de dezvoltare. Cu cât observați mai devreme o defecțiune în arhitectură, cu atât va fi mai ușor să o remediați, ceea ce vă va economisi mult timp în viitor.

Nu e nimic în neregulă cu Lua. Oricine poate învăța să scrie în el: dezvoltator Java, dezvoltator JavaScript, dezvoltator Python, front-end sau back-end. Chiar și analiștii noștri scriu despre el.

Când vorbim despre faptul că nu avem SQL, îi îngrozește pe oameni. „Cum obțineți date fără SQL? Este posibil? Cu siguranță. Într-un sistem de clasă OLTP, SQL nu este necesar. Există o alternativă sub forma unui fel de limbaj care vă întoarce imediat la o vizualizare orientată spre document. De exemplu, GraphQL. Și există o alternativă sub formă de calcul distribuit.

Dacă înțelegeți că va trebui să scalați, atunci proiectați-vă soluția pe Tarantool în așa fel încât să poată rula în paralel pe zeci de instanțe Tarantool. Dacă nu faceți acest lucru, va fi dificil și dureros mai târziu, deoarece Tarantool poate folosi eficient doar un nucleu de procesor.

Sursa: www.habr.com