Снимак из филма „Наш тајни универзум: Скривени живот ћелије“

Инвестициони бизнис је једна од најсложенијих области у банкарском свету, јер не постоје само зајмови, позајмице и депозити, већ и хартије од вредности, валуте, роба, деривати и све врсте сложености у виду структурираних производа.

У последње време бележимо пораст финансијске писмености становништва. Све више људи се укључује у трговање на тржишту хартија од вредности. Индивидуални инвестициони рачуни појавили су се не тако давно. Они вам омогућавају да тргујете на тржиштима хартија од вредности и или примате пореске олакшице или избегавате плаћање пореза. А сви клијенти који дођу код нас желе да управљају својим портфолиом и виде извештавање у реалном времену. Штавише, најчешће је овај портфолио вишепродуктан, односно људи су клијенти различитих пословних линија.

Осим тога, расту потребе регулатора, како руских тако и страних.

Да бисмо задовољили тренутне потребе и поставили темеље за будуће надоградње, развили смо пословно језгро улагања засновано на Тарантоол-у.

Неке статистике. Инвестиционо пословање Алфа-Банк пружа брокерске услуге за физичка и правна лица за пружање могућности трговања на различитим тржиштима хартија од вредности, услуге депозитара за складиштење хартија од вредности, услуге управљања поверењем за физичка лица са приватним и великим капиталом, услуге издавања хартија од вредности за друга предузећа . Инвестициони бизнис Алфа-Банк обухвата више од 3 хиљаде цитата у секунди, који се преузимају са различитих платформи за трговање. Током радног дана на пијацама се закључи више од 300 хиљада трансакција у име банке или њених клијената. До 5 хиљада извршења налога у секунди се дешава на спољним и интерним платформама. Истовремено, сви клијенти, како интерни тако и екстерни, желе да виде своје позиције у реалном времену.

praistorija

Негде од почетка 2000-их, наше области инвестиционог пословања су се самостално развијале: берзанска трговина, брокерске услуге, трговина валутама, ванберзанско трговање хартијама од вредности и разним дериватима. Као резултат тога, упали смо у замку функционалних бунара. Шта је то? Свака линија пословања има своје системе који међусобно дуплирају функције. Сваки систем има свој модел података, иако раде са истим концептима: трансакције, инструменти, друге стране, котације итд. И како се сваки систем развијао независно, појавио се разнолик зоолошки врт технологија.

Поред тога, кодна база система је већ прилично застарела, јер су неки производи настали средином 1990-их. А у неким областима то је успорило развојни процес и било је проблема са перформансама.

Захтеви за ново решење

Предузећа су схватила да је технолошка трансформација од виталног значаја за даљи развој. Добили смо задатке:

1. Прикупите све пословне податке у једном, брзом складишту и у једном моделу података.
2. Не смемо изгубити или променити ове информације.
3. Неопходно је верзионисати податке, јер регулатор у сваком тренутку може затражити статистику за претходне године.
4. Не морамо само да донесемо неке нове, модерне ДБМС, већ да створимо платформу за решавање пословних проблема.

Поред тога, наше архитекте постављају сопствене услове:

1. Ново решење мора бити Ентерприсе класе, односно већ мора бити тестирано у неким великим компанијама.
2. Режим рада решења треба да буде критичан. То значи да морамо бити присутни у више дата центара истовремено и мирно преживети испад једног дата центра.
3. Систем мора бити хоризонтално скалабилан. Чињеница је да су сви наши тренутни системи само вертикално скалабилни, а ми већ достижемо плафон због ниског раста хардверске снаге. Стога је дошао тренутак када је потребно да имамо хоризонтално скалабилан систем да бисмо преживели.
4. Између осталог, речено нам је да решење мора бити јефтино.

Пратили смо стандардни пут: формулисали смо захтеве и контактирали одељење набавке. Одатле смо добили списак компанија које су, генерално, спремне да то ураде за нас. Свима смо рекли о проблему, а од њих шесторо добили оцену решења.

У банци не верујемо никоме на реч, волимо све да тестирамо сами. Стога је обавезан услов нашег тендерског конкурса био да прође тестове оптерећења. Формулисали смо задатке за тестирање оптерећења, а три од шест компанија су се већ сложиле да имплементирају прототип решења заснованог на ин-мемори технологијама о свом трошку како би га тестирали.

Нећу вам рећи како смо све тестирали и колико је времена требало, само ћу резимирати: најбоље перформансе у тестовима оптерећења показао је прототип решења заснованог на Тарантоол-у развојног тима Маил.ру Гроуп. Потписали смо споразум и почели развој. Било је четворо људи из Маил.ру групе, а из Алфа-Банк-а су била три програмера, три системска аналитичара, архитекта решења, власник производа и Сцрум мастер.

Следеће ћу вам рећи како је наш систем растао, како је еволуирао, шта смо радили и зашто баш то.

Развој

Прво питање које смо себи поставили било је како да добијемо податке из наших тренутних система. Одлучили смо да нам ХТТП одговара, јер сви тренутни системи међусобно комуницирају слањем КСМЛ-а или ЈСОН-а преко ХТТП-а.

Користимо ХТТП сервер уграђен у Тарантоол јер не морамо да прекидамо ССЛ сесије, а његове перформансе су нам довољне.

Као што сам већ рекао, сви наши системи живе у различитим моделима података, а на улазу треба да доведемо објекат до модела који сами описујемо. Био је потребан језик који омогућава трансформацију података. Изабрали смо императив Луа. Покрећемо сав код за конверзију података у сандбок-у - ово је безбедно место даље од кога покренути код не иде. Да бисмо то урадили, једноставно учитавамо потребан код, стварајући окружење са функцијама које не могу ништа да блокирају или испусте.

Након конверзије, подаци се морају проверити да ли су усклађени са моделом који креирамо. Дуго смо расправљали о томе шта модел треба да буде и којим језиком да га опишемо. Изабрали смо Апацхе Авро јер је језик једноставан и има подршку од Тарантоол-а. Нове верзије модела и прилагођеног кода могу се пуштати у рад неколико пута дневно, чак и под оптерећењем или без, у било које доба дана, и врло брзо се прилагођавати променама.

Након верификације, подаци морају бити сачувани. Ово радимо помоћу всхард-а (имамо гео-диспергиране реплике фрагмената).

Штавише, специфичност је таква да већини система који нам шаљу податке није важно да ли смо их примили или не. Зато смо од самог почетка спровели ред поправке. Шта је то? Ако из неког разлога објекат не пролази кроз трансформацију или верификацију података, ми и даље потврђујемо пријем, али истовремено чувамо објекат у реду за поправку. Доследан је и налази се у главном складишту пословних података. Одмах смо написали администраторски интерфејс за њега, разне метрике и упозорења. Као резултат тога, не губимо податке. Чак и ако се нешто променило у извору, ако се променио модел података, ми ћемо то одмах открити и можемо да се прилагодимо.

Сада морате научити како да преузмете сачуване податке. Пажљиво смо анализирали наше системе и видели да класични стек Јаве и Орацле-а нужно садржи неку врсту ОРМ-а који конвертује податке из релационих у објектне. Па зашто не бисте одмах дали објекте системима у облику графикона? Тако смо срећно усвојили ГрапхКЛ, који је задовољио све наше потребе. Омогућава вам да примате податке у облику графикона и извлачите само оно што вам је тренутно потребно. Можете чак и верзију АПИ-ја са доста флексибилности.

Скоро одмах смо схватили да подаци које смо извлачили нису довољни. Направили смо функције које се могу повезати са објектима у моделу - у суштини, израчунатим пољима. То јест, пољу прилажемо одређену функцију која, на пример, израчунава просечну цену понуде. А спољни потрошач који тражи податке ни не зна да је ово израчунато поље.

Имплементиран систем аутентификације.

Тада смо приметили да се у нашој одлуци искристалисало неколико улога. Улога је нека врста агрегатора функција. Обично улоге имају различите профиле употребе опреме:

• Т-Цоннецт: управља долазним конекцијама, ЦПУ ограничен, мала потрошња меморије, без држављанства.
• ИБ-Цоре: трансформише податке које прима преко Тарантоол протокола, односно ради са табелама. Такође не чува стање и скалабилан је.
• Складиштење: чува само податке, не користи никакву логику. Ова улога имплементира најједноставније интерфејсе. Скалабилност захваљујући всхард-у.

То јест, користећи улоге, одвојили смо различите делове кластера један од другог, који се могу скалирати независно један од другог.

Дакле, креирали смо асинхрони запис тока трансакцијских података и ред за поправку са интерфејсом администратора. Снимање је асинхроно са пословне тачке гледишта: ако је гарантовано да себи запишемо податке, без обзира где, онда ћемо то потврдити. Ако није потврђено, нешто је пошло наопако и потребно је послати податке. Ово је асинхрони снимак.

Тестирање

Од самог почетка пројекта одлучили смо да покушамо да имплементирамо тест вођен развој. Јединичне тестове пишемо у Луа користећи тарантоол/тап фрамеворк, а интеграцијске тестове у Питхон-у користећи питест фрамеворк. Истовремено, укључујемо и програмере и аналитичаре у писање интеграционих тестова.

Како користимо тест вођен развој?

Ако желимо неку нову функцију, прво покушавамо да напишемо тест за њу. Када откријемо грешку, обавезно прво напишемо тест, па тек онда поправимо. У почетку је тешко овако радити, долази до неразумевања код запослених, чак и саботаже: „Хајде сада брзо да поправимо, урадимо нешто ново, па то покријемо тестовима. Само ово „касније“ скоро никад не долази.

Стога, морате се присилити да прво напишете тестове и замолите друге да то ураде. Верујте ми, развој заснован на тестовима доноси предности чак и краткорочно. Осетићете да вам је живот постао лакши. Сматрамо да је 99% кода сада покривено тестовима. Ово изгледа као много, али немамо никаквих проблема: тестови се покрећу при сваком урезивању.

Међутим, оно што највише волимо је тестирање оптерећења; сматрамо га најважнијим и спроводимо га редовно.

Испричаћу вам малу причу о томе како смо извршили прву фазу тестирања оптерећења једне од првих верзија. Инсталирали смо систем на лаптоп програмера, укључили оптерећење и примили 4 хиљаде трансакција у секунди. Добар резултат за лаптоп. Инсталирали смо га на виртуелној клупи за учитавање од четири сервера, слабије него у производњи. Распоређен на минимум. Покрећемо га, и добијамо резултат лошији него на лаптопу у једној нити. Шок садржај.

Били смо веома тужни. Гледамо оптерећење сервера, али се испоставило да су неактивни.

Позовемо програмере, а они нама, људима који долазе из света Јаве, објашњавају да је Тарантоол једнонитни. Може га ефикасно користити само једно језгро процесора под оптерећењем. Затим смо распоредили максимални могући број Тарантоол инстанци на сваком серверу, укључили оптерећење и већ примили 14,5 хиљада трансакција у секунди.

Да објасним поново. Због поделе на улоге које различито користе ресурсе, наше улоге одговорне за обраду веза и трансформацију података оптерећују само процесор, и то строго пропорционално оптерећењу.

У овом случају, меморија је коришћена само за обраду долазних веза и привремених објеката.

Напротив, на серверима за складиштење, оптерећење процесора се повећало, али много спорије него на серверима који обрађују везе.

А потрошња меморије је расла директно пропорционално количини учитаних података.

Услуге

Да бисмо развили наш нови производ посебно као платформу за апликације, креирали смо компоненту за примену услуга и библиотека на њој.

Услуге нису само мали делови кода који раде на неким пољима. То могу бити прилично велике и сложене структуре које су део кластера, проверавају референтне податке, покрећу пословну логику и враћају одговоре. Такође извозимо шему услуге у ГрапхКЛ, а потрошач добија универзалну приступну тачку подацима, са интроспекцијом кроз цео модел. Веома је удобно.

Пошто сервиси садрже много више функција, одлучили смо да постоје библиотеке у које ћемо премештати често коришћени код. Додали смо их у безбедно окружење, претходно проверивши да нам ништа не квари. И сада можемо доделити додатна окружења функцијама у облику библиотека.

Желели смо да имамо платформу не само за складиштење, већ и за рачунарство. А пошто смо већ имали гомилу реплика и фрагмената, имплементирали смо неку врсту дистрибуираног рачунарства и назвали га мап редукција, јер је испало слично оригиналном смањењу мапе.

Стари системи

Не могу сви наши стари системи да нас позову преко ХТТП-а и користе ГрапхКЛ, иако подржавају протокол. Стога смо креирали механизам који омогућава да се подаци реплицирају у ове системе.

Ако се нешто промени за нас, у улози Складиште се покрећу јединствени окидачи и порука са променама завршава у реду за обраду. Шаље се спољном систему помоћу посебне улоге репликатора. Ова улога не чува стање.

Нова побољшања

Као што се сећате, са пословне тачке гледишта, радили смо асинхроно снимање. Али онда су схватили да то неће бити довољно, јер постоји класа система који треба одмах да добију одговор о статусу операције. Тако смо проширили наш ГрапхКЛ и додали мутације. Органски се уклапају у постојећу парадигму рада са подацима. За нас је ово јединствена тачка читања и писања за другу класу система.

Такође смо схватили да нам сами сервиси неће бити довољни, јер постоје прилично тешки извештаји које треба правити једном дневно, недељно, месечно. Ово може потрајати дуго, а извештаји чак могу блокирати Тарантоол-ову петљу догађаја. Стога смо креирали одвојене улоге: планер и тркач. Тркачи не чувају стање. Они обављају тешке задатке које не можемо израчунати у ходу. А улога планера надгледа распоред покретања ових задатака, који је описан у конфигурацији. Сами задаци се чувају на истом месту као и пословни подаци. Када дође право време, планер преузима задатак, даје га неком тркачу, који га пребројава и чува резултат.

Не морају се сви задаци извршавати по распореду. Неки извештаји се морају читати на захтев. Чим овај захтев стигне, креира се задатак у сандбок-у и шаље се тркачу на извршење. Након неког времена корисник добија асинхрони одговор да је све израчунато и извештај је спреман.

У почетку смо се држали парадигме чувања свих података, верзионисања и небрисања. Али у животу, с времена на време ипак морате нешто да избришете, углавном неке сирове или посредне информације. На основу истека, направили смо механизам за чишћење складишта од застарелих података.

Такође разумемо да ће пре или касније доћи ситуација када неће бити довољно простора за складиштење података у меморији, али подаци се ипак морају ускладиштити. За ове сврхе, ускоро ћемо направити складиште на диску.

Закључак

Почели смо са задатком да учитамо податке у један модел и провели три месеца да га развијамо. Имали смо шест система за снабдевање подацима. Цео код трансформације у један модел је око 30 хиљада линија у Луа. А највећи део посла тек предстоји. Понекад постоји недостатак мотивације суседних екипа, а постоје и многе околности које компликују посао. Ако се икада суочите са сличним задатком, онда помножите време које вам се чини нормалним за његову реализацију са три, па чак и четири.

Такође запамтите да се постојећи проблеми у пословним процесима не могу решити коришћењем новог ДБМС-а, чак ни веома продуктивног. Оно што мислим? На почетку нашег пројекта створили смо утисак међу купцима да ћемо сада донети нову брзу базу података и живећемо! Процеси ће ићи брже, све ће бити у реду. У ствари, технологија не решава проблеме које имају пословни процеси, јер пословни процеси су људи. И треба да радите са људима, а не са технологијом.

Развој вођен тестом може бити болан и дуготрајан у раним фазама. Али позитиван ефекат ће бити приметан чак и краткорочно, када не морате ништа да радите да бисте спровели регресијско тестирање.

Изузетно је важно спровести тестирање оптерећења у свим фазама развоја. Што пре приметите неки недостатак у архитектури, лакше ћете га поправити, што ће вам уштедети много времена у будућности.

Ништа није у реду са Луом. Свако може да научи да пише у њему: Јава програмер, ЈаваСцрипт програмер, Питхон програмер, фронт-енд или бацк-енд. Чак и наши аналитичари пишу о томе.

Када говоримо о томе да немамо СКЛ, то ужасава људе. „Како добијате податке без СКЛ-а? Да ли је то могуће? Сигурно. У систему ОЛТП класа, СКЛ није потребан. Постоји алтернатива у облику неке врсте језика који вас одмах враћа у приказ оријентисан на документ. На пример, ГрапхКЛ. А постоји и алтернатива у облику дистрибуираног рачунарства.

Ако разумете да ћете морати да скалирате, дизајнирајте своје решење на Тарантоол-у на такав начин да може да ради паралелно на десетинама Тарантоол инстанци. Ако то не урадите, касније ће бити тешко и болно, пошто Тарантоол може ефикасно да користи само једно језгро процесора.

Извор: ввв.хабр.цом