«Біздің құпия ғалам: Жасушаның жасырын өмірі» фильмінен кадр

Инвестициялық бизнес банк әлеміндегі ең күрделі салалардың бірі болып табылады, өйткені мұнда тек несиелер, қарыздар және депозиттер ғана емес, сонымен қатар бағалы қағаздар, валюталар, тауарлар, туынды құралдар және құрылымдық өнімдер түріндегі күрделіліктердің барлық түрлері бар.

Соңғы уақытта халықтың қаржылық сауаттылығының артқанын байқаймыз. Бағалы қағаздар нарығындағы саудаға көбірек адамдар тартылуда. Жеке инвестициялық шоттар жақында пайда болды. Олар сізге бағалы қағаздар нарығында сауда жасауға және салық шегерімдерін алуға немесе салық төлеуден жалтаруға мүмкіндік береді. Ал бізге келген барлық клиенттер өз портфолиосын басқарып, нақты уақытта есеп беруді көргісі келеді. Сонымен қатар, бұл портфолио көбінесе көп өнім болып табылады, яғни адамдар әртүрлі бизнес бағыттарының клиенттері болып табылады.

Сонымен қатар, ресейлік және шетелдік реттеушілердің қажеттіліктері артып келеді.

Ағымдағы қажеттіліктерді қанағаттандыру және болашақ жаңартулардың негізін қалау үшін біз Tarantool негізіндегі инвестициялық бизнес негізін жасадық.

Кейбір статистика. Альфа-Банктің инвестициялық бизнесі жеке және заңды тұлғаларға әртүрлі бағалы қағаздар нарығында сауда жасау мүмкіндігін қамтамасыз ету үшін брокерлік қызметтерді, бағалы қағаздарды сақтау бойынша депозитарлық қызметтерді, жеке және ірі капиталы бар жеке тұлғаларға сенімгерлік басқару қызметтерін, басқа компаниялар үшін бағалы қағаздарды шығару бойынша қызметтерді ұсынады. . Альфа-Банктің инвестициялық бизнесі әртүрлі сауда платформаларынан жүктелетін секундына 3 мыңнан астам баға белгілеуді қамтиды. Жұмыс күні ішінде банктің немесе оның клиенттерінің атынан базарларда 300 мыңнан астам мәміле жасалады. Сыртқы және ішкі платформаларда секундына 5 мыңға дейін тапсырыс орындалады. Сонымен қатар, барлық ішкі және сыртқы клиенттер нақты уақытта өз позицияларын көргісі келеді.

тарихын

2000-шы жылдардың басынан бастап біздің инвестициялық бизнестің салалары өз бетінше дамыды: биржалық сауда, брокерлік қызметтер, валюталық сауда, бағалы қағаздармен және әртүрлі туынды құралдармен биржадан тыс сауда. Нәтижесінде біз функционалдық ұңғымалардың тұзағына түсіп қалдық. Бұл не? Әрбір бизнес саласында бір-бірінің функцияларын қайталайтын өз жүйелері бар. Әрбір жүйенің өзіндік деректер үлгісі бар, бірақ олар бірдей ұғымдармен жұмыс істейді: транзакциялар, құралдар, контрагенттер, баға белгілеулер және т.б. Әр жүйе өз бетінше дамып келе жатқандықтан, әртүрлі зоопарк пайда болды.

Сонымен қатар, жүйелердің кодтық базасы қазірдің өзінде әбден ескірген, өйткені кейбір өнімдер 1990 жылдардың ортасында пайда болды. Ал кейбір аймақтарда бұл даму үдерісін бәсеңдетіп, өнімділік проблемалары туындады.

Жаңа шешімге қойылатын талаптар

Кәсіпорындар әрі қарай даму үшін технологиялық трансформацияның маңызды екенін түсінді. Бізге тапсырмалар берілді:

1. Барлық бизнес деректерін бір, жылдам жадта және бір деректер үлгісінде жинаңыз.
2. Біз бұл ақпаратты жоғалтпауымыз немесе өзгертуіміз керек.
3. Деректердің нұсқасын жасау қажет, өйткені кез келген уақытта реттеуші өткен жылдардағы статистиканы сұрауы мүмкін.
4. Біз жаңа, сәнді ДҚБЖ әкеліп қана қоймай, бизнес мәселелерін шешу үшін платформа құруымыз керек.

Сонымен қатар, біздің сәулетшілер өз шарттарын белгілейді:

1. Жаңа шешім кәсіпорын деңгейінде болуы керек, яғни кейбір ірі компанияларда сыналған болуы керек.
2. Шешімнің жұмыс режимі маңызды міндет болуы керек. Бұл дегеніміз, біз бір уақытта бірнеше деректер орталықтарында болуымыз керек және бір дата орталығының тоқтап қалуынан сабырмен аман өтуіміз керек.
3. Жүйе көлденең масштабталатын болуы керек. Біздің барлық қазіргі жүйелеріміз тек тігінен масштабталады және біз аппараттық қуаттың төмен өсуіне байланысты төбеге жетіп жатырмыз. Сондықтан, бізге аман қалу үшін көлденең масштабталатын жүйе қажет болатын сәт келді.
4. Басқа нәрселермен қатар, бізге шешім арзан болуы керек екенін айтты.

Біз стандартты бағытты ұстандық: талаптарды тұжырымдап, сатып алу бөліміне хабарластық. Ол жерден біз жалпы алғанда біз үшін мұны жасауға дайын компаниялардың тізімін алдық. Біз барлығына мәселені айтып, алтауының шешіміне баға алдық.

Банкте біз ешкімнің сөзін қабылдамаймыз, біз бәрін өзіміз сынағанды ​​ұнатамыз. Сондықтан, біздің тендерлік конкурстың міндетті шарты жүктеме сынақтарынан өту болды. Біз жүктемелік сынақ тапсырмаларын тұжырымдадық, алты компанияның үшеуі оны сынау үшін жадтағы технологияларға негізделген прототиптік шешімді өз қаражатына енгізуге келісті.

Мен барлығын қалай сынағанымызды және оған қанша уақыт кеткенін айтпаймын, мен жай ғана қорытындылаймын: жүктеме сынақтарындағы ең жақсы өнімділікті Mail.ru Group әзірлеу тобының Tarantool негізіндегі прототиптік шешімі көрсетті. Біз келісімге қол қойып, әзірлеуді бастадық. Mail.ru Group-тан төрт адам болды, ал Альфа-Банктен үш әзірлеуші, үш жүйелік талдаушы, шешім сәулетшісі, өнім иесі және Scrum шебері болды.

Әрі қарай мен сізге жүйеміздің қалай өскені, оның қалай дамығаны, біз не істегеніміз және неліктен бұл туралы айтып беремін.

Даму

Біз өзімізге қойған бірінші сұрақ қазіргі жүйелерімізден деректерді қалай алуға болады. Біз HTTP бізге өте қолайлы деп шештік, өйткені барлық ағымдағы жүйелер HTTP арқылы XML немесе JSON жіберу арқылы бір-бірімен байланысады.

Біз Tarantool ішіне орнатылған HTTP серверін пайдаланамыз, себебі SSL сеанстарын тоқтатудың қажеті жоқ және оның өнімділігі біз үшін жеткілікті.

Жоғарыда айтқанымдай, біздің барлық жүйелеріміз әртүрлі деректер үлгілерінде өмір сүреді және енгізу кезінде біз объектіні өзімізді сипаттайтын модельге келтіруіміз керек. Деректерді түрлендіруге мүмкіндік беретін тіл қажет болды. Біз императивті Луаны таңдадық. Біз барлық деректерді түрлендіру кодын құм жәшігінде іске қосамыз - бұл қауіпсіз орын, одан тыс орындалатын код жүрмейді. Мұны істеу үшін біз жай ғана қажетті кодты жүктеп, ештеңені блоктай алмайтын немесе тастамайтын функциялары бар ортаны жасаймыз.

Түрлендіруден кейін деректердің біз жасап жатқан үлгіге сәйкестігін тексеру керек. Модельдің қандай болуы керектігін және оны сипаттау үшін қандай тілде қолдану керектігін ұзақ талқыладық. Біз Apache Avro-ны таңдадық, себебі тіл қарапайым және оған Tarantool қолдауы бар. Модельдің және пайдаланушы кодының жаңа нұсқалары күніне бірнеше рет, тіпті жүктеме кезінде немесе онсыз, тәуліктің кез келген уақытында іске қосылуы мүмкін және өзгерістерге өте тез бейімделеді.

Тексеруден кейін деректерді сақтау керек. Біз мұны vshard арқылы жасаймыз (бізде фрагменттердің гео-дисперсті көшірмелері бар).

Оның үстіне, ерекшелік соншалық, бізге деректерді жіберетін көптеген жүйелер оны алған-алмағанымызға мән бермейді. Сондықтан жөндеу кезегін басынан бастап іске асырдық. Бұл не? Егер қандай да бір себептермен нысан деректерді түрлендіруден немесе тексеруден өтпесе, біз әлі де алуды растаймыз, бірақ сонымен бірге нысанды жөндеу кезегіне сақтаймыз. Ол тұрақты және негізгі бизнес деректер қоймасында орналасқан. Біз оған бірден әкімші интерфейсін, әртүрлі көрсеткіштер мен ескертулерді жаздық. Нәтижесінде біз деректерді жоғалтпаймыз. Тіпті дереккөзінде бірдеңе өзгерсе де, деректер үлгісі өзгерсе, біз оны дереу анықтаймыз және бейімделе аламыз.

Енді сіз сақталған деректерді алу жолын үйренуіңіз керек. Біз жүйелерімізді мұқият талдадық және классикалық Java және Oracle стекінде міндетті түрде деректерді қатыстылықтан объектіге түрлендіретін ORM түрі бар екенін көрдік. Ендеше неге бірден жүйелерге объектілерді график түрінде бермеске? Сондықтан біз барлық қажеттіліктерімізді қанағаттандыратын GraphQL-ті қуана қабылдадық. Ол графиктер түрінде деректерді алуға және дәл қазір қажет нәрсені ғана шығаруға мүмкіндік береді. Сіз тіпті API нұсқасын өте икемділікпен жасай аласыз.

Бірден дерлік біз шығарып жатқан деректер жеткіліксіз екенін түсіндік. Біз модельдегі нысандармен байланыстыруға болатын функцияларды жасадық - негізінен есептелген өрістер. Яғни, біз белгілі бір функцияны өріске тіркейміз, ол, мысалы, орташа баға белгілеу бағасын есептейді. Ал деректерді сұраған сыртқы тұтынушы бұл есептелген өріс екенін де білмейді.

Аутентификация жүйесі енгізілді.

Содан кейін біз шешімімізде бірнеше рөлдердің кристалданғанын байқадық. Рөл - функцияларды жинақтауыштың бір түрі. Әдетте рөлдердің әртүрлі жабдықты пайдалану профильдері болады:

• T-Connect: кіріс қосылымдарын өңдейді, CPU шектеулі, жадты аз тұтыну, азаматтығы жоқ.
• IB-Core: Tarantool протоколы арқылы алынған деректерді түрлендіреді, яғни кестелермен жұмыс істейді. Ол сондай-ақ күйді сақтамайды және масштабталады.
• Сақтау: тек деректерді сақтайды, ешқандай логиканы пайдаланбайды. Бұл рөл ең қарапайым интерфейстерді жүзеге асырады. Vshard арқасында масштабталады.

Яғни, рөлдерді пайдалана отырып, біз бір-бірінен тәуелсіз масштабтауға болатын кластердің әртүрлі бөліктерін бір-бірінен ажыраттық.

Сонымен, біз транзакциялық деректер ағынының асинхронды жазбасын және әкімші интерфейсі бар жөндеу кезегін жасадық. Жазба іскерлік тұрғыдан асинхронды: егер бізге қай жерде болса да, өзімізге деректерді жазуға кепілдік берілсе, біз оны растаймыз. Егер ол расталмаса, бірдеңе дұрыс болмады және деректерді жіберу керек. Бұл асинхронды жазба.

Тестілеу

Жобаның басынан бастап біз тестілеуге негізделген әзірлеуді енгізуге тырысамыз деп шештік. Біз tarantool/tap құрылымын пайдаланып Lua тілінде бірлік сынақтарын және pytest құрылымын пайдаланып Python-да интеграция сынақтарын жазамыз. Сонымен бірге біз интеграциялық сынақтарды жазуға әзірлеушілерді де, талдаушыларды да тартамыз.

Тестке негізделген дамуды қалай пайдаланамыз?

Жаңа мүмкіндікті алғымыз келсе, алдымен оған сынақ жазуға тырысамыз. Қатені тапқанда, алдымен сынақ жазып, содан кейін ғана түзетеміз. Алғашында бұлай жұмыс істеу қиын, қызметкерлер тарапынан түсінбеушілік, тіпті саботаж бар: «Қазір тез түзетейік, жаңа нәрсе жасайық, содан кейін оны сынақтармен жабамыз». Тек бұл «кейінірек» ешқашан келмейді.

Сондықтан алдымен тест жазуға өзіңізді мәжбүрлеп, басқалардан сұрау керек. Маған сеніңіз, сынаққа негізделген даму тіпті қысқа мерзімде де пайда әкеледі. Өміріңіздің жеңілдегенін сезінесіз. Біз кодтың 99% қазір сынақтармен қамтылғанын сеземіз. Бұл көп сияқты көрінеді, бірақ бізде ешқандай проблема жоқ: сынақтар әрбір тапсырмада орындалады.

Дегенмен, біз ең жақсы көретін нәрсе - жүктеме сынағы; біз оны ең маңызды деп санаймыз және оны үнемі жүргіземіз.

Мен сізге бірінші нұсқалардың бірінің жүктеме сынауының бірінші кезеңін қалай өткізгеніміз туралы шағын әңгіме айтып беремін. Біз жүйені әзірлеушінің ноутбугіне орнаттық, жүктемені қостық және секундына 4 мың транзакция алдық. Ноутбук үшін жақсы нәтиже. Біз оны төрт серверден тұратын виртуалды жүктеме орнына орнаттық, бұл өндіріске қарағанда әлсіз. Минимумға дейін орналастырылған. Біз оны іске қосамыз және бір ағындағы ноутбукке қарағанда нашар нәтиже аламыз. Шок мазмұны.

Біз қатты қайғырдық. Біз сервер жүктемесін қарастырамыз, бірақ олар жұмыссыз болып шықты.

Біз әзірлеушілерді шақырамыз және олар бізге Java әлемінен келген адамдарға Tarantool бір ағынды екенін түсіндіреді. Оны тек бір процессор өзегі жүктеме кезінде тиімді пайдалана алады. Содан кейін біз әр серверде Tarantool даналарының максималды санын орналастырдық, жүктемені қостық және секундына 14,5 мың транзакция алдық.

Тағы да түсіндірейін. Ресурстарды басқаша пайдаланатын рөлдерге бөлінуіне байланысты қосылымдарды өңдеуге және деректерді түрлендіруге жауапты рөлдеріміз тек процессорды жүктейді және жүктемеге қатаң пропорционалды.

Бұл жағдайда жад тек кіріс қосылымдары мен уақытша объектілерді өңдеу үшін пайдаланылды.

Керісінше, сақтау серверлерінде процессор жүктемесі өсті, бірақ қосылымдарды өңдейтін серверлерге қарағанда әлдеқайда баяу.

Ал жадты тұтыну жүктелген деректер көлеміне тікелей пропорционалды өсті.

Қызметтер

Жаңа өнімімізді қолданбалы платформа ретінде әзірлеу үшін біз оған қызметтер мен кітапханаларды орналастыруға арналған құрамдас жасадық.

Қызметтер кейбір өрістерде жұмыс істейтін кодтың кішкене бөліктері ғана емес. Олар кластердің бөлігі болып табылатын, анықтамалық деректерді тексеретін, бизнес логикасын іске қосатын және жауаптарды қайтаратын өте үлкен және күрделі құрылымдар болуы мүмкін. Біз сондай-ақ қызмет схемасын GraphQL-ге экспорттаймыз және тұтынушы барлық модель бойынша интроспекция арқылы деректерге әмбебап кіру нүктесін алады. Бұл өте ыңғайлы.

Қызметтерде көптеген басқа функциялар болғандықтан, біз жиі қолданылатын кодты жылжытатын кітапханалар болуы керек деп шештік. Біз оларды қауіпсіз ортаға қостық, ол біз үшін ештеңені бұзбайтынын алдын ала тексердік. Ал енді біз кітапханалар түріндегі функцияларға қосымша орталарды тағайындай аламыз.

Біз тек сақтау үшін ғана емес, сонымен қатар есептеулер үшін де платформаға ие болғымыз келді. Бізде репликалар мен сынықтар көп болғандықтан, біз таратылған есептеудің бір түрін енгіздік және оны картаны азайту деп атадық, себебі ол бастапқы картаны азайтуға ұқсас болды.

Ескі жүйелер

Біздің бұрынғы жүйелеріміздің барлығы протоколды қолдағанымен HTTP арқылы бізге қоңырау шалып, GraphQL пайдалана алмайды. Сондықтан біз деректерді осы жүйелерге көшіруге мүмкіндік беретін механизмді жасадық.

Егер біз үшін бірдеңе өзгерсе, бірегей триггерлер Сақтау рөлінде іске қосылады және өзгерістері бар хабар өңдеу кезегіне аяқталады. Ол бөлек репликатор рөлі арқылы сыртқы жүйеге жіберіледі. Бұл рөл күйді сақтамайды.

Жаңа жақсартулар

Естеріңізде болса, бизнес тұрғысынан біз асинхронды жазба жүргіздік. Бірақ содан кейін олар бұл жеткіліксіз болатынын түсінді, өйткені операцияның күйі туралы дереу жауап алу керек жүйелер класы бар. Осылайша, біз GraphQL-ті кеңейтіп, мутацияларды қостық. Олар деректермен жұмыс істеудің қолданыстағы парадигмасына органикалық түрде сәйкес келеді. Біз үшін бұл басқа жүйелер класы үшін оқу мен жазудың бір нүктесі.

Сондай-ақ біз тек қызмет көрсетудің бізге жеткіліксіз екенін түсіндік, өйткені күніне, аптасына, айына бір рет салынуы керек өте ауыр есептер бар. Бұл ұзақ уақыт алуы мүмкін және есептер тіпті Tarantool оқиғалар циклін блоктай алады. Сондықтан біз бөлек рөлдерді жасадық: жоспарлаушы және жүгіруші. Жүгірушілер күйді сақтамайды. Олар біз есептей алмайтын ауыр тапсырмаларды орындайды. Ал жоспарлаушы рөлі конфигурацияда сипатталған осы тапсырмаларды іске қосу кестесін бақылайды. Тапсырмалардың өзі бизнес деректерімен бір жерде сақталады. Тиісті уақыт келгенде, жоспарлаушы тапсырманы алып, оны бірнеше жүгірушіге береді, ол оны санап, нәтижені сақтайды.

Барлық тапсырмаларды кесте бойынша орындау қажет емес. Кейбір есептерді сұраныс бойынша оқу керек. Бұл талап келген бойда тапсырма құм жәшігінде жасалады және орындау үшін жүгірушіге жіберіледі. Біраз уақыттан кейін пайдаланушы барлығы есептелген және есеп дайын деген асинхронды жауап алады.

Бастапқыда біз барлық деректерді сақтау, оны версиялау және оны жоймау парадигмасын ұстандық. Бірақ өмірде мезгіл-мезгіл сіз әлі де бір нәрсені, негізінен кейбір өңделмеген немесе аралық ақпаратты жоюға тура келеді. Жарамдылық мерзімі өткеніне байланысты біз жадты ескірген деректерден тазарту механизмін жасадық.

Біз сондай-ақ ерте ме, кеш пе, жадта деректерді сақтау үшін орын жеткіліксіз болатын жағдай туындайтынын түсінеміз, бірақ соған қарамастан деректерді сақтау керек. Осы мақсаттар үшін біз жақын арада дискіні сақтауды жасаймыз.

қорытынды

Біз деректерді бір модельге жүктеу тапсырмасынан бастап, оны әзірлеуге үш ай жұмсадық. Бізде деректермен қамтамасыз етудің алты жүйесі болды. Бір үлгіге айналдырудың бүкіл коды Луада шамамен 30 мың жолды құрайды. Ал жұмыстың басым бөлігі әлі алда. Кейде көршілес ұжымдардан мотивация жетіспейді, жұмысты қиындататын жағдайлар көп. Егер сізде осындай тапсырма кездессе, оны орындау үшін сізге қалыпты болып көрінетін уақытты үшке, тіпті төртке көбейтіңіз.

Сондай-ақ бизнес-процестердегі бар мәселелерді жаңа ДҚБЖ, тіпті өте өнімді болса да шешу мүмкін емес екенін есте сақтаңыз. Мен не айтқым келеді? Жобамыздың басында біз тұтынушылар арасында енді біз жаңа жылдам деректер базасын әкелеміз және біз өмір сүреміз деген әсер қалдырдық! Процестер тезірек жүреді, бәрі жақсы болады. Іс жүзінде технология бизнес-процестердің проблемаларын шешпейді, өйткені бизнес-процестер адамдар. Және технологиямен емес, адамдармен жұмыс істеу керек.

Сынақ негізіндегі даму ерте кезеңдерде ауыр және көп уақытты қажет етуі мүмкін. Бірақ оның оң әсері тіпті қысқа мерзімде, регрессиялық тестілеуді жүргізу үшін ештеңе істеудің қажеті жоқ кезде де байқалады.

Дамудың барлық кезеңдерінде жүктеме сынамасын жүргізу өте маңызды. Архитектурадағы қандай да бір ақаулықты тезірек байқасаңыз, оны түзету оңайырақ болады, бұл болашақта көп уақытты үнемдейді.

Луаға ешнәрсе жоқ. Онда кез келген адам жазуды үйрене алады: Java әзірлеушісі, JavaScript әзірлеушісі, Python әзірлеушісі, фронт-end немесе back-end. Бұл туралы біздің сарапшылар да жазады.

Бізде SQL жоқ екендігі туралы айтатын болсақ, ол адамдарды қорқытады. «SQL-сіз деректерді қалай алуға болады? Бұл мүмкін бе? Әрине. OLTP класс жүйесінде SQL қажет емес. Сізді құжатқа бағытталған көрініске дереу қайтаратын тілдің қандай да бір түрі түрінде балама бар. Мысалы, GraphQL. Ал таратылған есептеулер түрінде балама бар.

Егер сізге масштабтау қажет екенін түсінсеңіз, онда Tarantool жүйесінде шешіміңізді ондаған Tarantool даналарында параллель жұмыс істейтіндей етіп жасаңыз. Егер мұны жасамасаңыз, бұл кейінірек қиын және ауыр болады, өйткені Tarantool тек бір процессор өзегін тиімді пайдалана алады.

Ақпарат көзі: www.habr.com