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

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

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

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

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

Што се бодува

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

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

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

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

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

За задачата што е при рака, веќе користиме специјализиран систем за одлучување IBM WebSphere ILOG JRules BRMS, кој, врз основа на правилата поставени од аналитичарите, технолозите и програмерите, одлучува дали да одобри или одбие одреден банкарски производ на клиентот.

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

Задача

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

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

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

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

Нашето решение

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

За ова решение, беше неопходно да се најде соодветна рамка без сервер за да се имплементираат правилата на системот за одлучување што се развива. Бидејќи Tinkoff активно го користи Kubernetes за управување со инфраструктурата, разгледавме неколку готови решенија засновани на него; ќе ви кажам повеќе за тоа подоцна.

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

1. Аналитичарот пишува скрипта, правило или ML модел врз основа на податоците од магацинот. Како дел од хакатонот, решивме да го користиме Mongodb, но изборот на систем за складирање податоци овде не е важен.
2. По тестирањето на развиените правила за историски податоци, аналитичарот го поставува својот код на административниот панел.
3. За да се обезбеди верзија, целиот код ќе оди во складиштата на Git.
4. Преку административниот панел ќе може да се распореди кодот во облакот како посебен функционален безсервер модул.

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

Уште пред хакатонот се одлучивме за рамката без сервер што ќе ја користиме. Денес на пазарот има доста технологии кои го спроведуваат овој пристап. Најпопуларните решенија во рамките на архитектурата на Kubernetes се Fission, Open FaaS и Kubeless. Постојат дури и добра статија со нивниот опис и компаративна анализа.

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

За да работите со Fission, треба да разберете два основни концепти: функција и животна средина. Функцијата е дел од кодот напишан на еден од јазиците за кој постои околина Fission. Список на средини имплементирани во оваа рамка вклучува Python, JS, Go, JVM и многу други популарни јазици и технологии.

Fission исто така е способен да извршува функции поделени во неколку датотеки, претходно спакувани во архива. Работата на Fission во кластерот Kubernetes е обезбедена со специјализирани подлоги, кои се управувани од самата рамка. За да комуницирате со кластерските подлоги, на секоја функција мора да и се додели сопствена рута и на која можете да ги пренесете параметрите GET или телото на барањето во случај на барање POST.

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

Во нашето предложено решение, нема потреба да се објавуваат правила; кодот може лесно да се распореди со кликнување на копче. Исто така, управувањето со инфраструктурата во Kubernetes ви овозможува да не размислувате за оптоварување и скалирање; таквите проблеми се решаваат надвор од кутијата. И употребата на единствен складиште на податоци ја елиминира потребата да се споредуваат податоците во реално време со историските податоци, што ја поедноставува работата на аналитичарот.

Она што го добивме

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

Клучот за успех на секој хакатон е подготовка и добро напишан план. Затоа, првото нешто што направивме беше да одлучиме од кои модули ќе се состои нашата системска архитектура и кои технологии ќе ги користиме.

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

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

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

1. Клиентот пополнува формулар на веб-страницата и го испраќа своето барање до контролорот. Апликација за која треба да се донесе одлука доаѓа до влезот на системот и се евидентира во базата на податоци во неговата оригинална форма.
2. Следно, необработеното барање се испраќа на збогатување, доколку е потребно. Почетното барање можете да го дополните со податоци и од надворешни услуги и од складиштето. Добиеното збогатено барање исто така се чува во базата на податоци.
3. Се активира функцијата аналитичар, која зема збогатено барање како влез и произведува решение, кое исто така се запишува во складиштето.

Решивме да го користиме MongoDB како складиште во нашиот систем поради складирањето на податоци ориентирано кон документи во форма на документи JSON, бидејќи услугите за збогатување, вклучително и оригиналното барање, ги собираа сите податоци преку контролорите REST.

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

1. Предни административни панели за работата на аналитичарот, преку кои тој можеше да презема правила од системот за контрола на верзии на напишани скрипти, да избира опции за збогатување на влезните податоци и да ги уредува скриптите за правила онлајн.
2. Администратор на задниот дел, вклучувајќи REST API за предниот дел и интеграција со VCS.
3. Поставување инфраструктура во Google Cloud и развој на услуга за збогатување на изворните податоци.
4. Модул за интегрирање на административната апликација со рамката без сервер за последователно распоредување на правила.
5. Скрипти со правила за тестирање на перформансите на целиот систем и агрегација на аналитика на дојдовните апликации (донесени одлуки) за конечна демонстрација.

Да почнеме со цел.

Нашиот преден дел беше напишан во Angular 7 користејќи го банкарскиот UI Kit. Конечната верзија на административниот панел изгледаше вака:

Бидејќи имаше малку време, се обидовме да ја имплементираме само клучната функционалност. За да се распореди функција во кластерот Kubernetes, потребно беше да се избере настан (услуга за која треба да се распореди правило во облакот) и кодот на функцијата што ја спроведува логиката на одлучување. За секое распоредување на правило за избраната услуга, напишавме дневник на овој настан. Во административниот панел можете да ги видите дневниците на сите настани.

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

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

Заднината на платформата беше напишана во Java и имплементирана како апликација Spring Boot. Првично планиравме да користиме Postgres за складирање на администраторски податоци, но, како дел од хакатонот, решивме да се ограничиме на едноставен H2 за да заштедиме време. На задниот дел, интеграцијата со Bitbucket беше имплементирана за да се верзираат функциите за збогатување на барањата и скриптите за правила. За интеграција со далечински складишта на Git, користевме JGit библиотека, што е еден вид обвивка преку командите CLI, што ви овозможува да извршите какви било git инструкции користејќи пригоден софтверски интерфејс. Така, имавме две посебни складишта за функции и правила за збогатување, и сите скрипти беа поделени во директориуми. Преку корисничкиот интерфејс беше можно да се избере најновиот commit на скрипта на произволна гранка на складиштето. Кога се прават промени на кодот преку администраторскиот панел, заложбите на променетиот код беа креирани во оддалечените складишта.

За да ја реализираме нашата идеја, ни требаше соодветна инфраструктура. Решивме да го распоредиме нашиот Kubernetes кластер во облакот. Нашиот избор беше Google Cloud Platform. Рамката без сервер Fission беше инсталирана на кластерот Kubernetes, кој го распоредивме во Gcloud. Првично, услугата за збогатување на изворните податоци беше имплементирана како посебна Java апликација завиткана во Pod внатре во кластерот k8s. Но, по прелиминарната демонстрација на нашиот проект во средината на хакатонот, ни беше препорачано да ја направиме услугата Enrichment пофлексибилна за да обезбедиме можност да избереме како да ги збогатиме необработените податоци од дојдовните апликации. И немавме друг избор освен да ја направиме услугата за збогатување, исто така, без сервер.

За да работиме со Fission, го користевме Fission CLI, кој мора да се инсталира на врвот на Kubernetes CLI. Распоредувањето на функциите во кластерот k8s е прилично едноставно; само треба да доделите внатрешна рута и влез во функцијата за да дозволите дојдовен сообраќај доколку е потребен пристап надвор од кластерот. Распоредувањето на една функција обично трае не повеќе од 10 секунди.

Конечна презентација на проектот и сумирање

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

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

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

Имаше на располагање вкупно 3 фиктивни банкарски производи:

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

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

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

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

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

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

Извор: www.habr.com