Кадр з фільма «Над Secret Universe: The Hidden Life of the Cell»
Інвестыцыйны бізнэс - гэта адно з найскладанейшых напрамкаў у банкаўскім свеце, таму што тут ёсць не толькі крэдыты, пазыкі і дэпазіты, але і каштоўныя паперы, валюта, тавары, дэрыватывы і ўсякія складанасці ў выглядзе структурных прадуктаў.
У апошні час мы назіраем рост фінансавай пісьменнасці насельніцтва. Усё больш людзей залучаецца ў гандаль на рынках каштоўных папер. Індывідуальныя інвестыцыйныя рахункі з'явіліся не так даўно. Яны дазваляюць вам гандляваць на рынках каштоўных папер і пры гэтым ці атрымліваць падатковыя вылікі, ці не плаціць падаткі. І ўсе кліенты, якія да нас прыходзяць, жадаюць кіраваць сваім партфелем і бачыць справаздачнасць у рэальным часе. Прычым часцей за ўсё гэты партфель мультыпрадуктавы, гэта значыць людзі з'яўляюцца кліентамі розных напрамкаў бізнесу.
Акрамя таго, растуць і запатрабаванні рэгулятараў, як расійскіх, так і замежных.
Каб адпавядаць бягучым патрэбам і закласці падмурак для будучых мадэрнізацый, мы распрацавалі ядро інвест-бізнэсу на аснове Tarantool.
Крыху статыстыкі. Інвестыцыйны бізнес "Альфа-Банка" аказвае брокерскія паслугі для фізічных і юрыдычных асоб па прадастаўленні магчымасці гандляваць на розных рынках каштоўных папер, дэпазітарныя паслугі па захоўванні каштоўных папер, паслугі па давернаму кіраванню для асоб з прыватным і буйным капіталам, паслугі па выпуску каштоўных папер для іншых кампаній. Інвестыцыйны бізнес "Альфа-Банка" - гэта больш за 3 тыс. каціровак у секунду, якія загружаюцца з розных гандлёвых пляцовак. На працягу працоўнага дня на рынках заключаецца больш за 300 тыс. здзелак ад асобы банка або яго кліентаў. На знешніх і ўнутраных пляцоўках адбываецца да 5 тыс. выкананняў ордэраў за секунду. Пры гэтым усе кліенты, як унутраныя, так і знешнія, хочуць бачыць свае пазіцыі ў рэжыме рэальнага часу.
перадгісторыя
Недзе з пачатку 2000-х гадоў нашы напрамкі інвестыцыйнага бізнесу развіваліся незалежна: біржавы гандаль, брокерскія паслугі, гандаль валютай, пазабіржавы гандаль каштоўнымі паперамі і рознымі дэрыватывамі. У выніку мы патрапілі ў пастку функцыянальных студняў. Што гэта такое? У кожнага напрамку бізнесу ёсць свае сістэмы, якія дублююць функцыі адна адной. У кожнай сістэмы свая мадэль дадзеных, хоць яны аперуюць аднымі і тымі ж паняццямі: здзелкамі, інструментамі, контрагентамі, каціроўкамі і іншым. І паколькі кожная сістэма развівалася незалежна, узнік разнастайны заапарк тэхналогій.
Акрамя таго, кодавая база сістэм ужо парадкам састарэла, бо некаторыя прадукты зарадзіліся яшчэ ў сярэдзіне 1990-х. І на некаторых напрамках гэта запавольвала працэс распрацоўкі, былі праблемы з прадукцыйнасцю.
Патрабаванні да новага рашэння
Бізнес зразумеў, што для далейшага развіцця жыццёва неабходна тэхналагічная трансфармацыя. Нам паставілі задачы:
- Сабраць усе дадзеныя бізнэсу ў адзіным хуткім сховішчы і ў адзінай мадэлі дадзеных.
- Гэтую інфармацыю мы не павінны губляць ці мяняць.
- Трэба версіяваць дадзеныя, таму што ў любы момант рэгулятар можа папытаць статыстыку за мінулыя гады.
- Мы павінны не проста прынесці нейкую новую, модную СКБД, а зрабіць платформу для вырашэння бізнес-задач.
Апроч гэтага нашы архітэктары паставілі свае ўмовы:
- Новае рашэнне павінна быць карпаратыўнага класа, гэта значыць яно павінна быць ужо апрабавана ў нейкіх буйных кампаніях.
- Рэжым працы рашэння павінен быць mission critical. Гэта значыць, што мы павінны прысутнічаць адначасова ў некалькіх дата-цэнтрах і спакойна перажываць адключэнне аднаго дата-цэнтра.
- Сістэма павінна быць гарызантальна якая маштабуецца. Справа ў тым, што ўсе нашы бягучыя сістэмы толькі вертыкальна якія маштабуюцца, і мы ўжо ўпіраемся ў столь з-за нізкага росту магутнасці жалеза. Таму надышоў момант, калі нам для выжывання трэба мець гарызантальна якая маштабуецца сістэму.
- Апроч усяго іншага нам сказалі, што рашэнне павінна быць танным.
Мы пайшлі стандартным шляхам: сфармулявалі патрабаванні і звярнуліся ў аддзел закупак. Адтуль атрымалі спіс кампаній, якія, у цэлым, гатовы для нас гэта рабіць. Распавялі ўсім аб задачы, і ад шасці з іх атрымалі адзнаку рашэнняў.
Мы ў слоіку на слова нікому не верым, каханы ўсё тэставаць самастойна. Таму абавязковай умовай нашага тэндэрнага конкурсу было праходжанне нагрузачных тэстаў. Сфармулявалі тэставыя заданні па нагрузцы, і ўжо тры кампаніі з шасці пагадзіліся за свой кошт рэалізаваць прататып рашэння на базе in-memory-тэхналогій, каб пратэставаць яго.
Я не буду распавядаць, як мы ўсё тэставалі і колькі часу гэта заняло, падвяду толькі вынік: лепшую прадукцыйнасць у нагрузачных тэстах паказаў прататып рашэння на базе Tarantool ад каманды распрацоўшчыкаў Mail.ru Group. Мы падпісалі дамову і пачалі распрацоўку. Чатыры чалавекі было з боку Mail.ru Group, а ад "Альфа-Банка" тры распрацоўшчыка, тры сістэмных аналітыка, solution-архітэктар, уладальнік прадукту і Scrum-майстар.
Далей раскажу аб тым, як расла наша сістэма, як яна эвалюцыянавала, што мы рабілі і чаму менавіта так.
Распрацоўка
У першую чаргу мы задаліся пытаннем, як атрымліваць даныя з нашых бягучых сістэм. Вырашылі, што HTTP нам суцэль падыходзіць, таму што ўсе бягучыя сістэмы маюць зносіны паміж сабой, перасылаючы XML ці JSON па HTTP.
Мы выкарыстоўваем убудаваны ў Tarantool HTTP-сервер, таму што ў нас няма неабходнасці тэрмінаваць SSL-сесіі, і яго прадукцыйнасці нам хапае за вочы.
Як я ўжо казаў, у нас усе сістэмы жывуць у розных мадэлях дадзеных, і на ўваходзе нам трэба прывесці аб'ект да той мадэлі, якую мы ў сябе апішам. Неабходна была мова, якая дазваляе трансфармаваць дадзеныя. Мы выбралі імператыўны Lua. Увесь код для пераўтварэння дадзеных мы запускаем у пясочніцы - гэта бяспечнае месца, за межы якога запушчаны код не выходзіць. Для гэтага проста які робіцца loadstring патрэбнага кода, ствараючы асяроддзе з функцыямі, якія не могуць нічога заблакаваць або нешта выпусціць.
Пасля пераўтварэння дадзеныя трэба праверыць на адпаведнасць той мадэлі, якую мы ствараем. Доўга абмяркоўвалі, што павінна ўяўляць сабой мадэль, якую мову выкарыстоўваць для яе апісання. Спыніліся на Apache Avro, таму што мова простая і ў яго ёсць падтрымка з боку Tarantool. Новыя версіі мадэлі і карыстацкага кода можна адпраўляць у эксплуатацыю некалькі разоў у дзень хоць пад нагрузкай, хоць без, у любы час сутак, і вельмі хутка адаптавацца да змен.
Пасля праверкі дадзеныя трэба захаваць. Які робіцца мы гэта з дапамогай vshard (у нас георазнесенные рэплікі шардов).
Пры гэтым спецыфіка такая, што большасці сістэм, якія адпраўляюць нам дадзеныя, усё роўна, атрымалі мы іх ці не. Таму з самага пачатку мы рэалізавалі рамонтную чаргу. Што гэта такое? Калі па нейкіх прычынах аб'ект не прайшоў трансфармацыю даных або праверку, то мы ўсё роўна пацвярджаем атрыманне, але пры гэтым захоўваем аб'ект у рамонтную чаргу. Яна ўзгоднена, размяшчаецца ў асноўным сховішча з бізнес-дадзенымі. Мы адразу напісалі для яе інтэрфейс адміністратара, розныя метрыкі і абвесткі. У выніку мы не губляем дадзеныя. Нават калі ў крыніцы нешта памянялася, калі змянілася мадэль дадзеных, мы адразу гэта выявім і можам адаптавацца.
Цяпер трэба навучыцца здабываць захаваныя дадзеныя. Мы ўважліва прааналізавалі нашы сістэмы і ўбачылі, што на класічным стэку з Java і Oracle абавязкова прысутнічае якая-небудзь ORM, якая пераўтворыць дадзеныя з рэляцыйнага выгляду ў аб'ектны. Дык чаму б адразу не аддаваць аб'екты сістэмам у выглядзе графа? Таму мы з радасцю ўзялі GraphQL, які задавальняў усе нашыя патрэбы. Ён дазваляе атрымліваць дадзеныя ў выглядзе графаў, выцягваць толькі тое, што трэба менавіта зараз. Можна нават версіяваць API з дастаткова вялікай гнуткасцю.
Амаль адразу мы зразумелі, што вымаемых дадзеных нам мала. Зрабілі функцыі, якія можна прывязаць да аб'ектаў у мадэлі - па сутнасці, якія вылічаюцца палі. Гэта значыць, мы прывязваем да поля нейкую функцыю, якая, напрыклад, лічыць сярэдні кошт каціроўкі. А вонкавы спажывец, які запытвае дадзеныя, нават не ведае, што гэтае поле вылічанае.
Рэалізавалі сістэму аўтэнтыфікацыі.
Потым заўважылі, што ў нашым рашэнні выкрышталізоўваецца некалькі роляў. Роля - гэта нейкі агрэгатар функцый. Як правіла, у роляў розны профіль выкарыстання абсталявання:
- T-Connect: апрацоўвае ўваходныя злучэнні, абмежавана па працэсары, спажывае мала памяці, не захоўвае стан.
- IB-Core: трансфармуе дадзеныя, якія атрымлівае па пратаколе Tarantool, гэта значыць яна аперуе таблічкамі. Таксама не захоўвае стан і паддаецца маштабаванні.
- Storage: толькі захоўвае дадзеныя, ніякай логікі не выкарыстоўвае. У гэтай ролі рэалізаваны найпростыя інтэрфейсы. Маштабуецца дзякуючы vshard.
Гэта значыць з дапамогай роляў мы адвязалі сябар ад сябра розныя часткі кластара, якія можна маштабаваць незалежна сябар ад сябра.
Такім чынам, мы стварылі асінхронны запіс транзакцыйнага патоку дадзеных і рамонтную чаргу з інтэрфейсам адміністратара. Запіс асінхронны з пункту гледжання бізнесу: калі мы гарантавана запісалі да сябе дадзеныя, усё роўна куды, то мы гэта пацвердзім. Калі не пацвердзілі, значыць нешта пайшло не так, даныя трэба пераслаць. У гэтым і заключаецца асінхроннасць запісу.
Тэставанне
З самага пачатку праекту вырашылі, што будзем спрабаваць насаджаць test driven development. Модульныя тэсты мы пішам на Lua з дапамогай фрэймворка tarantool/tap, інтэграцыйныя - на Python з дапамогай фрэймворка pytest. Пры гэтым у напісанне інтэграцыйных тэстаў у нас уцягнуты і распрацоўшчыкі, і аналітыкі.
Як у нас прымяняецца test driven development?
Калі мы жадаем нейкую новую фічу, то імкнемся спачатку напісаць для яе тэст. Выявіўшы баг, абавязкова спачатку пішам на тэст, і толькі потым выпраўляем. Спачатку так працаваць цяжка, узнікае неразуменне з боку супрацоўнікаў, нават сабатаж: "Давайце зараз хутка паправім, зробім нешта новае, а потым пакрыем тэстамі". Толькі гэтае «потым» не надыходзіць амаль ніколі.
Таму трэба прымушаць сябе найперш пісаць тэсты, прасіць навакольных гэта рабіць. Паверце, test driven development прыносіць выгаду нават у кароткатэрміновай перспектыве. Вы адчуеце, што вам стала лягчэй жыць. Па нашых адчуваннях, зараз тэстамі пакрыта 99% кода. Здаецца, што гэта шмат, але ў нас не ўзнікае ніякіх праблем: тэсты запускаюцца па кожным коміце.
Аднак больш за ўсё мы кахаем нагрузачнае тэставанне лічым яго найважнейшым і рэгулярна праводжаны.
Раскажу невялікую гісторыю аб тым, як мы праводзілі першы этап нагрузачнага тэсціравання адной з першых версій. Паставілі сістэму на ноўтбук распрацоўшчыка, уключылі нагрузку і атрымалі 4 тыс. транзакцый за секунду. Добры вынік для наўтбука. Паставілі на віртуальны нагрузачны стэнд з чатырох сервераў, слабейшыя, чым у production. Разгарнулі па мінімуме. Запускаем, і атрымліваем вынік горш, чым на наўтбуку ў адзін струмень. Шок-кантэнт.
Мы вельмі зажурыліся. Глядзім загрузку сервераў, а яны, аказваецца, прастойваюць.
Тэлефануем распрацоўнікам, а яны тлумачаць нам, людзям, якія прыйшлі са свету Java, што Tarantool аднаструменны. Яго можа эфектыўна выкарыстоўваць толькі адно ядро працэсара пад нагрузкай. Тады мы разгарнулі на кожным серверы максімальна магчымую колькасць інстансаў Tarantool, уключылі нагрузку і атрымалі ўжо 14,5 тыс. транзакцый у секунду.
Яшчэ раз растлумачу. З-за дзялення на ролі, якія па-рознаму выкарыстоўваюць рэсурсы, нашы ролі, якія адказвалі за апрацоўку злучэнняў і трансфармацыю дадзеных загружалі толькі працэсар, прычым строга прапарцыйна нагрузцы.
Пры гэтым памяць выкарыстоўвалася толькі пад апрацоўку ўваходзячых злучэнняў і часавых аб'ектаў.
А на серверах захоўвання наадварот, загрузка працэсара расла, але нашмат павольней, чым на серверах, якія займаюцца апрацоўкай злучэнняў.
І спажыванне памяці расло прама прапарцыйна загружанаму аб'ёму дадзеных.
Сэрвісы
Каб развіваць наш новы прадукт менавіта як платформу дадаткаў, мы зрабілі кампанент для разгортвання на ёй сэрвісаў і бібліятэк.
Сэрвісы - гэта не проста маленькія кавалачкі кода, якія аперуюць нейкімі палямі. Яны могуць быць дастаткова вялікімі і складанымі канструкцыямі, якія ўваходзяць у склад кластара, правяраюць даведачныя дадзеныя, круцяць бізнес-логіку і аддаюць адказы. Схему сэрвісу мы таксама экспартуем у GraphQL, а спажывец атрымлівае ўніверсальную кропку доступу да дадзеных, з інтраспекцыяй па ўсёй мадэлі. Гэта вельмі зручна.
Бо сэрвісы ўтрымоўваюць значна больш функцый, мы вырашылі, што тамака павінны быць бібліятэкі, у якія мы будзем выносіць часта выкарыстоўваны код. Іх мы дадалі ў бяспечнае асяроддзе, папярэдне праверыўшы, што гэта нам нічога не ламае. І зараз можам задаваць функцый дадатковыя асяроддзі ў выглядзе бібліятэк.
Мы хацелі, каб у нас была платформа не толькі для захоўвання, але і для вылічэнняў. І паколькі ў нас ужо была куча рэплік і шардаў, мы рэалізавалі падабенства размеркаваных вылічэнняў і назвалі гэта map reduce, таму што атрымалася падобна на арыгінальны map reduce.
Старыя сістэмы
Не ўсе з нашых старых сістэм могуць выклікаць нас па HTTP і выкарыстоўваць GraphQL, хаця і падтрымліваюць гэты пратакол. Таму мы зрабілі механізм, які дазваляе рэпліцыраваць дадзеныя ў гэтыя сістэмы.
Калі ў нас нешта змяняецца, у ролі Storage спрацоўваюць своеасаблівыя трыгеры і паведамленне са зменамі пападае ў чаргу апрацоўкі. Яно з дапамогай асобнай ролі рэплікатара адпраўляецца ў знешнюю сістэму. Гэтая роля не захоўвае стан.
Новыя дапрацоўкі
Як вы памятаеце, з пункту гледжання бізнэсу мы зрабілі асінхронны запіс. Але тут зразумелі, што яе будзе нядосыць, таму што ёсць клас сістэм, якім патрабуецца адразу атрымліваць адказ аб статуце аперацыі. Таму мы пашырылі наш GraphQL і дадалі мутацыі. Яны арганічна ўпісаліся ў існуючую парадыгму працы з дадзенымі. У нас гэта адзіная кропка як чытання, так і запісы для іншага класа сістэм.
Таксама мы зразумелі, што адных толькі сэрвісаў нам будзе нядосыць, таму што бываюць даволі цяжкія справаздачы, якія трэба будаваць раз у суткі, у тыдзень, у месяц. Гэта можа займаць доўгі час, прычым справаздачы могуць нават блакаваць event loop Tarantool'а. Таму мы зрабілі асобныя ролі: scheduler і runner. Runner'ы не захоўваюць стан. На іх запускаюцца цяжкія задачы, якія мы не можам лічыць на лета. А роля scheduler сочыць за раскладам запуску гэтых задач, якое апісана ў канфігурацыі. Самі задачы захоўваюцца там жа, дзе і бізнес-звесткі. Калі надыходзіць прыдатны час, scheduler бярэ задачу, аддае нейкаму runner'у, той яе лічыць і захоўвае вынік.
Не ўсе задачы трэба запускаць па раскладзе. Нейкія справаздачы трэба лічыць на патрабаванне. Як толькі гэтае патрабаванне прыходзіць, у пясочніцы фармуецца задача і адпраўляецца на выкананне ў runner. Праз некаторы час карыстачу асінхронна прыходзіць адказ, што ўсё палічылася, справаздача готаў.
Першапачаткова мы прытрымліваліся парадыгмы захавання ўсіх дадзеных, версіяніруючы і не выдаляючы іх. Але ў жыцці перыядычна ўсё ж такі даводзіцца нешта выдаляць, у асноўным нейкую сырую ці прамежкавую інфармацыю. На аснове expirationd мы зрабілі механізм ачысткі сховішчы ад састарэлых дадзеных.
Таксама мы разумеем, што рана ці позна наступіць сітуацыя, калі месца для захоўвання дадзеных у памяці пачне не хапаць, але тым не менш дадзеныя трэба захоўваць. Для гэтых мэт мы хутка зробім дыскавае сховішча.
Заключэнне
Мы пачалі з задачы па загрузцы дадзеных у адзіную мадэль, патрацілі на яе распрацоўку тры месяцы. У нас было шэсць сістэм-пастаўшчыкоў даных. Увесь код трансфармацыі ў адзіную мадэль складае каля 30 тыс. радкоў на Lua. А большая частка працы яшчэ наперадзе. Часам не хапае матывацыі суседніх каманд, якія шмат ускладняюць працу абставін. Калі перад вамі калі-небудзь паўстане падобная задача, той час, які вам здасца нармальным для яе рэалізацыі, памножце на тры, ці нават на чатыры.
Таксама памятайце, што існуючыя праблемы ў бізнес-працэсах немагчыма вырашыць з дапамогай новай СКБД, няхай нават вельмі прадукцыйнай. Што я маю на ўвазе? На старце нашага праекта мы стварылі ў заказчыкаў уражанне, што зараз мы прынясем новую хуткую БД, і зажывем! Працэсы пойдуць хутчэй, усё будзе добра. На самай справе, тэхналогіі не вырашаюць тых праблем, якія ёсць у бізнес-працэсах, таму што бізнес-працэсы - гэта людзі. І трэба працаваць з людзьмі, а не з тэхналогіямі.
Распрацоўка праз тэсціраванне на пачатковых этапах можа дастаўляць боль і адымаць вельмі шмат часу. Але станоўчы эфект ад яе будзе замецены нават у кароткатэрміновай перспектыве, калі для правядзення рэгрэсійнага тэсціравання вам не спатрэбіцца нічога рабіць.
Вельмі важна праводзіць нагрузачнае тэсціраванне на ўсіх этапах распрацоўкі. Чым раней вы заўважыце нейкую недапрацоўку ў архітэктуры, тым лягчэй будзе яе выправіць, гэта зэканоміць вам кучу часу ў далейшым.
У мове Lua няма нічога страшнага. На ім можа навучыцца пісаць хто заўгодна: Java-распрацоўшчык, JavaScript-распрацоўшчык, распрацоўшчык на Python, франтэндэр або бэкендэр. У нас нават аналітыкі на ім пішуць.
Калі мы расказваем пра тое, што ў нас няма SQL, гэта прыводзіць людзей у жах. «Як вы дастаеце дадзеныя без SQL? Няўжо так можна?» Канечне. У сістэме класа OLTP SQL не патрэбен. Ёсць альтэрнатыва ў выглядзе якой-небудзь мовы, якая вяртае вам адразу дакументаарыентаваны від. Напрыклад, GraphQL. І ёсць альтэрнатыва ў выглядзе размеркаваных вылічэнняў.
Калі вы разумееце, што вам трэба будзе маштабавацца, то праектуйце сваё рашэнне на Tarantool, адразу такім чынам, каб яно магло працаваць раўналежна на дзясятках асобнікаў Tarantool. Калі вы гэтага не зробіце, тое потым будзе складана і балюча, паколькі Tarantool можа эфектыўна выкарыстоўваць толькі адно ядро працэсара.
Крыніца: habr.com