Како смо направили цлоуд ФааС унутар Кубернетеса и победили на Тинкофф хакатону

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

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

Задатак је нетривијалан и може се решити на више начина, у шта смо се уверили током демонстрације завршних презентација пројеката учесника. На хакатону је било 6 тимова од по 5 људи, сви учесници су имали добре пројекте, али се наша платформа показала као најконкурентнија. Имамо веома интересантан пројекат, о коме бих желео да говорим у овом чланку.

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

Шта је бодовање

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

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

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

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

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

За овај задатак већ користимо специјализовани систем доношења одлука ИБМ ВебСпхере ИЛОГ ЈРулес БРМС, која на основу правила која постављају аналитичари, технолози и програмери одлучује да ли ће клијенту одобрити или одбити одређени банкарски производ.

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

Задатак

Хакатон је одржан 23. фебруара. Учесницима је понуђен борбени задатак: да развију систем одлучивања који мора да испуни низ услова.

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

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

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

Наше решење

После малог размишљања, одлучили смо да би ФааС решење било идеално за завршетак задатка.

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

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

1. Аналитичар пише скрипту, правило или МЛ модел на основу података из складишта. У оквиру хакатона одлучили смо да користимо Монгодб, али избор система за складиштење података овде није битан.
2. Након тестирања развијених правила на историјским подацима, аналитичар поставља свој код на админ панел.
3. Да би се обезбедило управљање верзијама, сав код ће ићи у Гит спремишта.
4. Преко административног панела биће могуће применити код у облаку као посебан функционални модул без сервера.

Почетни подаци од клијената морају проћи кроз специјализовану услугу обогаћивања која је осмишљена да обогати почетни захтев подацима из складишта. Било је важно имплементирати овај сервис на такав начин да ради са једним спремиштем (из којег аналитичар узима податке када развија правила) како би се одржала јединствена структура података.

Чак и пре хакатона, одлучили смо се за Серверлесс фрамеворк који ћемо користити. Данас на тржишту постоји доста технологија које имплементирају овај приступ. Најпопуларнија решења у оквиру Кубернетес архитектуре су Фиссион, Опен ФааС и Кубелесс. Постоје чак добар чланак са њиховим описом и упоредном анализом.

Након што смо одмерили све предности и недостатке, изабрали смо Фисија. Овај оквир без сервера је прилично једноставан за управљање и испуњава захтеве задатка.

Да бисте радили са Фисионом, морате разумети два основна концепта: функцију и окружење. Функција је део кода написан на једном од језика за који постоји Фиссион окружење. Списак окружења имплементираних у оквиру овог оквира укључује Питхон, ЈС, Го, ЈВМ и многе друге популарне језике и технологије.

Фиссион је такође способан да обавља функције подељене у неколико фајлова, претходно упакованих у архиву. Рад Фисије у Кубернетес кластеру је обезбеђен специјализованим подовима, којима управља сам оквир. За интеракцију са модулима кластера, свакој функцији мора бити додељена сопствена рута, којој можете проследити ГЕТ параметре или тело захтева у случају ПОСТ захтева.

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

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

Шта имамо

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

Кључ успеха на сваком хакатону је припрема и добро написан план. Стога је прво што смо урадили било да одлучимо од којих модула ће се састојати архитектура нашег система и које технологије ћемо користити.

Архитектура нашег пројекта је била следећа:

Овај дијаграм приказује две улазне тачке, аналитичара (главног корисника нашег система) и клијента.

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

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

Одлучили смо да користимо МонгоДБ као складиште у нашем систему због документно оријентисаног складиштења података у облику ЈСОН докумената, пошто су услуге обогаћивања, укључујући и оригинални захтев, агрегирале све податке преко РЕСТ контролера.

Дакле, имали смо XNUMX сата да имплементирамо платформу. Улоге смо прилично успешно распоредили; сваки члан тима је имао своју област одговорности у нашем пројекту:

1. Фронт-енд админ панели за рад аналитичара, преко којих је могао да преузима правила из система контроле верзија писаних скрипти, бира опције за обогаћивање улазних података и уређује скрипте правила онлајн.
2. Позадински администратор, укључујући РЕСТ АПИ за предњи део и интеграцију са ВЦС-ом.
3. Постављање инфраструктуре у Гоогле Цлоуд-у и развој услуге за обогаћивање изворних података.
4. Модул за интеграцију администрацијске апликације са оквиром без сервера за накнадну примену правила.
5. Скрипте правила за тестирање перформанси целог система и агрегацију аналитике на долазним апликацијама (донетим одлукама) за завршну демонстрацију.

Кренимо редом.

Наш фронтенд је написан у Ангулар 7 користећи банкарски УИ Кит. Коначна верзија административног панела је изгледала овако:

Пошто је било мало времена, покушали смо да имплементирамо само кључну функционалност. Да бисте применили функцију у Кубернетес кластеру, било је потребно изабрати догађај (услуга за коју је потребно применити правило у облаку) и код функције која имплементира логику доношења одлука. За сваку примену правила за изабрану услугу, написали смо дневник овог догађаја. У админ панелу можете видети евиденцију свих догађаја.

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

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

Позадина платформе је написана на Јави и имплементирана као Спринг Боот апликација. Првобитно смо планирали да користимо Постгрес за чување администраторских података, али смо, као део хакатона, одлучили да се ограничимо на једноставан Х2 како бисмо уштедели време. На позадини, интеграција са Битбуцкет-ом је имплементирана за верзију функција обогаћивања упита и скрипти правила. За интеграцију са удаљеним Гит репозиторијумима, користили смо ЈГит библиотека, што је нека врста омотача преко ЦЛИ команди, омогућавајући вам да извршите било које гит инструкције користећи погодан софтверски интерфејс. Тако смо имали два одвојена спремишта за функције и правила обогаћивања, а све скрипте су подељене у директоријуме. Преко корисничког интерфејса било је могуће изабрати најновије урезивање скрипте произвољне гране спремишта. Приликом измена кода преко административног панела, урезивања промењеног кода су креирана у удаљеним репозиторијумима.

За реализацију наше идеје била нам је потребна одговарајућа инфраструктура. Одлучили смо да поставимо наш Кубернетес кластер у облаку. Наш избор је била Гоогле Цлоуд Платформ. Оквир без сервера Фиссион је инсталиран на Кубернетес кластеру, који смо применили у Гцлоуду. У почетку, услуга обогаћивања изворних података била је имплементирана као засебна Јава апликација умотана у Под унутар к8с кластера. Али након прелиминарне демонстрације нашег пројекта усред хакатона, препоручено нам је да учинимо услугу Енрицхмент флексибилнијом како бисмо пружили могућност избора како да обогатимо сирове податке долазних апликација. И нисмо имали избора осим да услугу обогаћивања учинимо и без сервера.

За рад са Фиссионом, користили смо Фиссион ЦЛИ, који се мора инсталирати на Кубернетес ЦЛИ. Примена функција у к8с кластер је прилично једноставна; само треба да доделите интерну руту и ​​улаз функцији да бисте дозволили долазни саобраћај ако је потребан приступ ван кластера. Примена једне функције обично не траје више од 10 секунди.

Завршна презентација пројекта и сумирање

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

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

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

Била су доступна укупно 3 фиктивна банкарска производа:

• Кредит.
• Играчка
• Хипотека.

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

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

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

Да бисмо прикупљали аналитику на мрежи, додатно смо применили БИ алат отвореног кода Метабасе и причврстио га на нашу складишну јединицу. Метабасе вам омогућава да направите екране са аналитиком на подацима који нас занимају; потребно је само да региструјете везу са базом података, изаберете табеле (у нашем случају збирке података, пошто смо користили МонгоДБ) и наведете поља која нас занимају. .

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

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