“Gizli Kainatımız: Hüceyrənin Gizli Həyatı” filmindən kadr

İnvestisiya biznesi bank dünyasında ən mürəkkəb sahələrdən biridir, çünki burada təkcə kreditlər, borclar və depozitlər deyil, həm də qiymətli kağızlar, valyutalar, əmtəələr, törəmələr və strukturlaşdırılmış məhsullar şəklində hər cür mürəkkəblik mövcuddur.

Son zamanlar əhalinin maliyyə savadlılığının yüksəldiyini müşahidə edirik. Getdikcə daha çox insan qiymətli kağızlar bazarlarında ticarətlə məşğul olur. Fərdi investisiya hesabları çox keçməmiş ortaya çıxdı. Onlar sizə qiymətli kağızlar bazarlarında ticarət etməyə və ya vergi endirimləri almağa, ya da vergi ödəməkdən yayınmağa imkan verir. Bizə gələn bütün müştərilər öz portfellərini idarə etmək və real vaxt rejimində hesabat görmək istəyirlər. Üstəlik, əksər hallarda bu portfel çox məhsuldur, yəni insanlar müxtəlif biznes sahələrinin müştəriləridir.

Bundan əlavə, həm Rusiya, həm də xarici tənzimləyicilərin ehtiyacları artır.

Cari ehtiyacları ödəmək və gələcək təkmilləşdirmələrin əsasını qoymaq üçün biz Tarantool-a əsaslanan investisiya biznesi əsasını hazırlamışıq.

Bəzi statistika. Alfa-Bankın investisiya biznesi fiziki və hüquqi şəxslərə müxtəlif qiymətli kağızlar bazarlarında ticarət etmək imkanı vermək üçün broker xidmətləri, qiymətli kağızların saxlanması üzrə depozitar xidmətləri, fərdi və böyük kapitala malik fiziki şəxslər üçün etibarlı idarəetmə xidmətləri, digər şirkətlər üçün qiymətli kağızların buraxılması xidmətləri göstərir. . Alfa-Bankın investisiya biznesinə müxtəlif ticarət platformalarından endirilən saniyədə 3 mindən çox kotirovka daxildir. İş günü ərzində bazarlarda bankın və ya onun müştərilərinin adından 300 mindən çox əqd bağlanılır. Xarici və daxili platformalarda saniyədə 5 minə qədər sifariş icrası baş verir. Eyni zamanda, həm daxili, həm də xarici bütün müştərilər öz mövqelərini real vaxt rejimində görmək istəyirlər.

Prehistorya

2000-ci illərin əvvəllərindən hardasa, investisiya biznesimizin sahələri müstəqil şəkildə inkişaf etdi: birja ticarəti, broker xidmətləri, valyuta ticarəti, qiymətli kağızların və müxtəlif törəmə vasitələrin birjadankənar ticarəti. Nəticədə funksional quyuların tələsinə düşdük. Bu nədir? Hər bir iş sahəsinin bir-birinin funksiyalarını təkrarlayan öz sistemləri var. Hər bir sistemin öz məlumat modeli var, baxmayaraq ki, onlar eyni anlayışlarla işləyirlər: əməliyyatlar, alətlər, qarşı tərəflər, kotirovkalar və s. Və hər bir sistem müstəqil olaraq inkişaf etdikcə, müxtəlif texnologiyalar zooparkı yarandı.

Bundan əlavə, sistemlərin kod bazası artıq kifayət qədər köhnəlib, çünki bəzi məhsullar 1990-cı illərin ortalarında yaranıb. Və bəzi sahələrdə bu, inkişaf prosesini ləngitdi və performans problemləri var idi.

Yeni bir həll üçün tələblər

Müəssisələr başa düşdülər ki, texnoloji transformasiya gələcək inkişaf üçün həyati əhəmiyyət kəsb edir. Bizə tapşırıqlar verildi:

Bütün biznes məlumatlarını tək, sürətli yaddaşda və vahid məlumat modelində toplayın.
Biz bu məlumatı itirməməli və dəyişdirməməliyik.
Məlumatların versiyaya salınması lazımdır, çünki hər an tənzimləyici əvvəlki illərin statistikasını tələb edə bilər.
Biz sadəcə bəzi yeni, dəbli DBMS gətirməməliyik, həm də biznes problemlərinin həlli üçün platforma yaratmalıyıq.

Bundan əlavə, memarlarımız öz şərtlərini qoyurlar:

Yeni həll müəssisə səviyyəli olmalıdır, yəni artıq bəzi iri şirkətlərdə sınaqdan keçirilməlidir.
Həllin iş rejimi kritik vəzifə olmalıdır. Bu o deməkdir ki, biz eyni vaxtda bir neçə məlumat mərkəzində olmalı və bir məlumat mərkəzinin kəsilməsindən sakitcə sağ çıxmalıyıq.
Sistem üfüqi şəkildə ölçülə bilən olmalıdır. Fakt budur ki, bütün mövcud sistemlərimiz yalnız şaquli olaraq miqyaslana bilir və biz artıq aparat gücünün aşağı artımı səbəbindən tavanı vururuq. Buna görə də, sağ qalmaq üçün üfüqi olaraq genişlənə bilən bir sistemə ehtiyacımız olduğu an gəldi.
Başqa şeylərlə yanaşı, bizə dedilər ki, həll ucuz olmalıdır.

Biz standart marşrutla getdik: tələbləri tərtib etdik və satınalma şöbəsi ilə əlaqə saxladıq. Oradan, ümumiyyətlə, bizim üçün bunu etməyə hazır olan şirkətlərin siyahısını aldıq. Problemi hər kəsə söylədik və onlardan altısının həlli ilə bağlı qiymət aldıq.

Bankda biz heç kimin sözünü qəbul etmirik, hər şeyi özümüz sınamağı xoşlayırıq. Ona görə də tender müsabiqəmizin məcburi şərti yük sınaqlarından keçmək idi. Biz yük test tapşırıqlarını tərtib etdik və altı şirkətdən üçü artıq sınaqdan keçirmək üçün yaddaşdaxili texnologiyalara əsaslanan prototip həllini öz vəsaitləri hesabına həyata keçirməyə razılaşıb.

Hər şeyi necə sınaqdan keçirdiyimizi və bunun nə qədər çəkdiyini sizə deməyəcəyəm, sadəcə ümumiləşdirəcəyəm: yük testlərində ən yaxşı performans Mail.ru Group inkişaf qrupundan Tarantool-a əsaslanan prototip həlli ilə göstərildi. Biz müqavilə imzaladıq və inkişafa başladıq. Mail.ru Group-dan dörd nəfər, Alfa-Bankdan isə üç tərtibatçı, üç sistem analitiki, həll memarı, məhsul sahibi və Scrum ustası var idi.

Sonra sizə sistemimizin necə böyüdüyünü, necə inkişaf etdiyini, nə etdiyimizi və niyə məhz bunu izah edəcəyəm.

İnkişaf

Özümüzə verdiyimiz ilk sual, mövcud sistemlərimizdən məlumatları necə əldə etmək idi. HTTP-nin bizim üçün olduqca uyğun olduğuna qərar verdik, çünki bütün mövcud sistemlər HTTP üzərindən XML və ya JSON göndərməklə bir-biri ilə əlaqə qurur.

Tarantool-da quraşdırılmış HTTP serverindən istifadə edirik, çünki SSL seanslarını dayandırmağa ehtiyac yoxdur və onun performansı bizim üçün kifayətdir.

Artıq dediyim kimi, bütün sistemlərimiz müxtəlif məlumat modellərində yaşayır və girişdə obyekti özümüzü təsvir etdiyimiz modelə gətirməliyik. Verilənlərin çevrilməsinə imkan verən dil lazım idi. Biz imperativ Luanı seçdik. Biz bütün data çevrilmə kodunu sandboxda işlədirik - bu, işləyən kodun kənara çıxmadığı təhlükəsiz yerdir. Bunun üçün biz sadəcə olaraq tələb olunan kodu yükləyirik, heç nəyi bloklaya bilməyən və ya buraxa bilməyən funksiyaları olan bir mühit yaradırıq.

Konversiyadan sonra verilənlərin bizim yaratdığımız modelə uyğunluğu yoxlanılmalıdır. Modelin nə olması və onu təsvir etmək üçün hansı dildən istifadə edilməsi barədə uzun müddət müzakirə etdik. Apache Avro-nu seçdik, çünki dil sadədir və Tarantool tərəfindən dəstəklənir. Modelin və xüsusi kodun yeni versiyaları gündə bir neçə dəfə, hətta yük altında və ya olmadan, günün istənilən vaxtında istifadəyə verilə bilər və dəyişikliklərə çox tez uyğunlaşa bilər.

Doğrulamadan sonra məlumatlar saxlanmalıdır. Bunu vshard istifadə edərək edirik (bizdə qırıqların geo-dispers surətləri var).

Üstəlik, spesifiklik elədir ki, bizə məlumat göndərən əksər sistemlər onu qəbul edib-etməməyimizə əhəmiyyət vermir. Ona görə də biz əvvəldən təmir növbəsini həyata keçirdik. Bu nədir? Əgər nədənsə obyekt verilənlərin transformasiyasına və ya yoxlanmasına məruz qalmırsa, biz hələ də qəbzi təsdiqləyirik, lakin eyni zamanda obyekti təmir növbəsində saxlayırıq. O, ardıcıldır və əsas biznes məlumat anbarında yerləşir. Bunun üçün dərhal idarəçi interfeysi, müxtəlif ölçülər və xəbərdarlıqlar yazdıq. Nəticədə məlumatları itirmirik. Mənbədə bir şey dəyişsə belə, məlumat modeli dəyişibsə, biz onu dərhal aşkar edəcəyik və uyğunlaşa bilərik.

İndi saxlanmış məlumatları necə əldə edəcəyinizi öyrənməlisiniz. Sistemlərimizi diqqətlə təhlil etdik və gördük ki, Java və Oracle-ın klassik yığını məlumatı əlaqəlidən obyektə çevirən bir növ ORM ehtiva edir. Bəs niyə dərhal sistemlərə obyektləri qrafik şəklində verməyək? Beləliklə, biz məmnuniyyətlə bütün ehtiyaclarımızı qarşılayan GraphQL-i qəbul etdik. Bu, qrafiklər şəklində məlumatları qəbul etməyə və yalnız hazırda ehtiyac duyduğunuzu çıxarmağa imkan verir. Siz hətta API-ni olduqca çox çevikliklə versiya edə bilərsiniz.

Demək olar ki, dərhal anladıq ki, çıxardığımız məlumat kifayət deyil. Modeldəki obyektlərlə əlaqələndirilə bilən funksiyalar yaratdıq - mahiyyətcə hesablanmış sahələr. Yəni, sahəyə müəyyən bir funksiya əlavə edirik, məsələn, orta kotirovka qiymətini hesablayır. Məlumatları tələb edən xarici istehlakçı isə bunun hesablanmış sahə olduğunu belə bilmir.

Autentifikasiya sistemi tətbiq edilmişdir.

Sonra qərarımızda bir neçə rolun kristallaşdığını gördük. Rol funksiyaların bir növ aqreqatorudur. Tipik olaraq, rollar müxtəlif avadanlıq istifadə profillərinə malikdir:

T-Connect: daxil olan əlaqələri idarə edir, CPU məhdud, az yaddaş istehlakı, vətəndaşlığı olmayan.
IB-Core: Tarantool protokolu vasitəsilə aldığı məlumatları çevirir, yəni cədvəllərlə işləyir. O, həmçinin vəziyyəti saxlamır və miqyaslana bilir.
Saxlama: yalnız məlumatları saxlayır, heç bir məntiqdən istifadə etmir. Bu rol ən sadə interfeysləri həyata keçirir. Vshard sayəsində genişləndirilə bilər.

Yəni, rollardan istifadə edərək, bir-birindən asılı olmayaraq miqyaslana bilən klasterin müxtəlif hissələrini bir-birindən ayırdıq.

Beləliklə, biz asinxron əməliyyat məlumat axını qeydini və idarəetmə interfeysi ilə təmir növbəsini yaratdıq. Qeydiyyat biznes baxımından asinxrondur: əgər bizə haradan asılı olmayaraq məlumat yazmağımıza zəmanət verilirsə, biz bunu təsdiq edəcəyik. Təsdiqlənməyibsə, onda bir şey səhv olub və məlumat göndərilməlidir. Bu asinxron qeyddir.

Test

Layihənin əvvəlindən biz qərara gəldik ki, test əsaslı inkişafı həyata keçirməyə çalışaq. Biz tarantool/tap çərçivəsini istifadə edərək Lua-da vahid testlərini və pytest çərçivəsini istifadə edərək Python-da inteqrasiya testlərini yazırıq. Eyni zamanda, inteqrasiya testlərinin yazılmasına həm tərtibatçıları, həm də analitikləri cəlb edirik.

Test əsaslı inkişafdan necə istifadə edirik?

Əgər yeni bir xüsusiyyət istəsək, əvvəlcə onun üçün bir test yazmağa çalışırıq. Bir səhv aşkar etdikdə, əvvəlcə bir test yazmağa və yalnız sonra onu düzəltməyə əmin oluruq. Əvvəlcə belə işləmək çətindir, işçilər tərəfindən anlaşılmazlıq, hətta təxribat var: “Gəlin indi tez düzəldək, yeni bir şey edək, sonra testlərlə əhatə edək”. Yalnız bu "sonra" demək olar ki, heç vaxt gəlmir.

Ona görə də əvvəlcə özünüzü testlər yazmağa məcbur etməli və başqalarından bunu etmələrini xahiş etməlisiniz. İnanın ki, test əsaslı inkişaf hətta qısa müddətdə fayda gətirir. Həyatınızın asanlaşdığını hiss edəcəksiniz. Hiss edirik ki, kodun 99%-i artıq testlərlə əhatə olunub. Bu, çox şey kimi görünür, lakin bizim heç bir problemimiz yoxdur: testlər hər bir öhdəliyi yerinə yetirir.

Bununla belə, ən çox sevdiyimiz yük testidir; biz bunu ən vacib hesab edirik və müntəzəm olaraq həyata keçiririk.

İlk versiyalardan birinin yük sınağının ilk mərhələsini necə həyata keçirdiyimiz haqqında sizə bir az hekayə danışacağam. Sistemi tərtibatçının noutbukuna quraşdırdıq, yükü işə saldıq və saniyədə 4 min əməliyyat aldıq. Noutbuk üçün yaxşı nəticə. Biz onu istehsaldan daha zəif dörd serverdən ibarət virtual yükləmə skamyasına quraşdırdıq. Minimum şəkildə yerləşdirilib. Biz onu işə salırıq və bir ipdə noutbukdan daha pis nəticə əldə edirik. Şok məzmunu.

Çox kədərləndik. Server yükünə baxırıq, lakin onların boş olduğu ortaya çıxır.

Biz tərtibatçıları çağırırıq və onlar bizə, Java dünyasından gələn insanlara Tarantoolun tək yivli olduğunu izah edirlər. O, yük altında yalnız bir prosessor nüvəsi tərəfindən effektiv şəkildə istifadə edilə bilər. Sonra hər bir serverdə mümkün olan maksimum sayda Tarantool instansiyasını yerləşdirdik, yükü işə saldıq və artıq saniyədə 14,5 min əməliyyat aldıq.

Bir daha izah edim. Resurslardan fərqli istifadə edən rollara bölünmə ilə əlaqədar olaraq, əlaqələrin işlənməsi və məlumatların çevrilməsi üçün cavabdeh olan rollarımız yalnız prosessoru yükləyir və yükə ciddi şəkildə mütənasibdir.

Bu halda yaddaş yalnız daxil olan əlaqələri və müvəqqəti obyektləri emal etmək üçün istifadə olunurdu.

Əksinə, saxlama serverlərində prosessor yükü artdı, lakin əlaqələri emal edən serverlərə nisbətən daha yavaş oldu.

Və yaddaş istehlakı yüklənmiş məlumatların miqdarı ilə birbaşa mütənasib olaraq artdı.

Xidmətlər

Yeni məhsulumuzu xüsusi olaraq tətbiq platforması kimi inkişaf etdirmək üçün biz orada xidmətlər və kitabxanaların yerləşdirilməsi üçün komponent yaratdıq.

Xidmətlər yalnız bəzi sahələrdə fəaliyyət göstərən kiçik kod parçaları deyil. Onlar klasterin bir hissəsi olan, istinad məlumatlarını yoxlayan, biznes məntiqini idarə edən və cavabları qaytaran kifayət qədər böyük və mürəkkəb strukturlar ola bilər. Biz həmçinin xidmət sxemini GraphQL-ə ixrac edirik və istehlakçı bütün model üzrə introspeksiya ilə məlumatlara universal giriş nöqtəsi alır. Çox rahatdır.

Xidmətlər daha çox funksiyaları ehtiva etdiyi üçün biz qərara gəldik ki, tez-tez istifadə olunan kodu köçürəcəyimiz kitabxanalar olmalıdır. Biz onları təhlükəsiz mühitə əlavə etdik, əvvəllər bunun bizim üçün heç nəyi pozmadığını yoxladıq. İndi biz kitabxanalar şəklində funksiyalara əlavə mühitlər təyin edə bilərik.

Biz təkcə saxlama üçün deyil, həm də hesablamalar üçün platformaya sahib olmaq istəyirdik. Artıq bir dəstə replika və qırıntılarımız olduğundan, biz bir növ paylanmış hesablama tətbiq etdik və onu xəritənin azaldılması adlandırdıq, çünki bu, orijinal xəritənin azaldılmasına bənzəyir.

Köhnə sistemlər

Bütün köhnə sistemlərimiz protokolu dəstəkləsə də, bizə HTTP üzərindən zəng edə və GraphQL-dən istifadə edə bilməz. Buna görə də, məlumatların bu sistemlərə təkrarlanmasına imkan verən bir mexanizm yaratdıq.

Bizim üçün bir şey dəyişərsə, Yaddaş rolunda unikal tetikler işə salınır və dəyişikliklərin olduğu mesaj emal növbəsinə düşür. Ayrı bir replikator rolundan istifadə edərək xarici sistemə göndərilir. Bu rol vəziyyəti saxlamır.

Yeni təkmilləşdirmələr

Yadınızdadırsa, biznes nöqteyi-nəzərindən asinxron səsyazma apardıq. Ancaq sonra başa düşdülər ki, bu kifayət etməyəcək, çünki əməliyyatın vəziyyəti haqqında dərhal cavab almalı olan sistemlər sinfi var. Beləliklə, biz GraphQL-i genişləndirdik və mutasiyalar əlavə etdik. Onlar məlumatlarla işləmək üçün mövcud paradiqma ilə üzvi şəkildə uyğunlaşırlar. Bizim üçün bu, başqa sistemlər sinfi üçün həm oxumaq, həm də yazmaq üçün tək nöqtədir.

Həm də başa düşdük ki, təkcə xidmətlər bizim üçün kifayət etməyəcək, çünki gündə, həftədə, ayda bir dəfə qurulmalı olan kifayət qədər ağır hesabatlar var. Bu, uzun müddət çəkə bilər və hesabatlar hətta Tarantool-un hadisə dövrəsini bloklaya bilər. Buna görə də biz ayrı-ayrı rollar yaratdıq: planlaşdırıcı və qaçışçı. Qaçışçılar vəziyyəti saxlamırlar. Tez hesablaya bilməyəcəyimiz ağır tapşırıqları yerinə yetirirlər. Və planlaşdırıcı rolu konfiqurasiyada təsvir olunan bu tapşırıqların işə salınma cədvəlinə nəzarət edir. Tapşırıqların özləri biznes məlumatları ilə eyni yerdə saxlanılır. Düzgün vaxt gəldikdə, planlaşdırıcı tapşırığı götürür, onu sayan və nəticəni saxlayan bir qaçışçıya verir.

Bütün tapşırıqları cədvəl üzrə yerinə yetirmək lazım deyil. Bəzi hesabatlar tələb əsasında oxunmalıdır. Bu tələb gələn kimi sandboxda tapşırıq yaradılır və icra üçün qaçışçıya göndərilir. Bir müddət sonra istifadəçi hər şeyin hesablandığını və hesabatın hazır olduğunu bildirən asinxron cavab alır.

Əvvəlcə biz bütün məlumatların saxlanması, versiyaya salınması və silinməməsi paradiqmasına əməl etdik. Ancaq həyatda vaxtaşırı nəyisə silməlisən, əsasən də bəzi xam və ya aralıq məlumatları. İstifadə müddəti bitmiş məlumatlara əsaslanaraq, yaddaşın köhnəlmiş məlumatlardan təmizlənməsi mexanizmi yaratdıq.

Biz həmçinin anlayırıq ki, gec-tez elə bir vəziyyət yaranacaq ki, yaddaşda məlumat saxlamaq üçün kifayət qədər yer olmayacaq, lakin buna baxmayaraq, məlumat saxlanılmalıdır. Bu məqsədlər üçün biz tezliklə disk yaddaşı edəcəyik.

Nəticə

Biz məlumatların vahid modelə yüklənməsi vəzifəsi ilə başladıq və üç ay ərzində onu inkişaf etdirdik. Altı məlumat təchizatı sistemimiz var idi. Bütün transformasiya kodu Lua-da təxminən 30 min sətirdən ibarətdir. Və işlərin çoxu hələ qabaqdadır. Bəzən qonşu komandalardan motivasiya çatışmır, işi çətinləşdirən bir çox hallar olur. Əgər siz nə vaxtsa oxşar tapşırıqla qarşılaşırsınızsa, onun həyata keçirilməsi üçün sizə normal görünən vaxtı üç, hətta dörd dəfə çoxaltın.

Həm də unutmayın ki, biznes proseslərində mövcud problemlər yeni DBMS-dən, hətta çox məhsuldar olandan istifadə etməklə həll edilə bilməz. Nə demək istəyirəm? Layihəmizin başlanğıcında müştərilərdə belə bir təəssürat yaratdıq ki, indi biz yeni sürətli məlumat bazası gətirəcəyik və yaşayacağıq! Proseslər daha sürətlə gedəcək, hər şey yaxşı olacaq. Əslində, texnologiya biznes proseslərinin yaratdığı problemləri həll etmir, çünki biznes prosesləri insanlardır. Və texnologiya ilə deyil, insanlarla işləmək lazımdır.

Testə əsaslanan inkişaf erkən mərhələlərdə ağrılı və vaxt apara bilər. Ancaq bunun müsbət təsiri hətta qısa müddətdə, reqressiya testi aparmaq üçün heç bir şey etməyə ehtiyac olmadığı zaman nəzərə çarpacaqdır.

İnkişafın bütün mərhələlərində yük testinin aparılması son dərəcə vacibdir. Memarlıqda hansısa qüsuru nə qədər tez görsəniz, onu düzəltmək bir o qədər asan olacaq, bu da gələcəkdə sizə çox vaxt qənaət edəcək.

Lua ilə səhv bir şey yoxdur. Hər kəs orada yazmağı öyrənə bilər: Java tərtibatçısı, JavaScript tərtibatçısı, Python tərtibatçısı, front-end və ya back-end. Hətta bizim analitiklərimiz də bu barədə yazır.

SQL-in olmamasından danışanda insanları dəhşətə gətirir. “SQL olmadan məlumatları necə əldə edirsiniz? Bu mümkündürmü? Əlbəttə. OLTP sinif sistemində SQL tələb olunmur. Sizi dərhal sənəd yönümlü görünüşə qaytaran bir növ dil şəklində alternativ var. Məsələn, GraphQL. Və paylanmış hesablama şəklində alternativ var.

Əgər miqyaslandırmalı olduğunuzu başa düşsəniz, o zaman Tarantool-da həllinizi elə tərtib edin ki, o, onlarla Tarantool nümunəsində paralel işləyə bilsin. Bunu etməsəniz, daha sonra çətin və ağrılı olacaq, çünki Tarantool yalnız bir prosessor nüvəsindən səmərəli istifadə edə bilər.

Mənbə: www.habr.com

Tarantool əsasında Alfa-Bankın investisiya biznesinin əsasını necə qurduq