Как направихме облачен FaaS в Kubernetes и спечелихме хакатона Tinkoff

От миналата година нашата компания започна да организира хакатони. Първото подобно състезание беше много успешно, писахме за него в Статия. Вторият хакатон се проведе през февруари 2019 г. и беше не по-малко успешен. За целите на провеждането на последното не толкова отдавна написах организатор.

Участниците получиха доста интересна задача с пълна свобода при избора на технологичен стек за нейното изпълнение. Беше необходимо да се внедри платформа за вземане на решения за удобно разгръщане на функции за оценяване на клиенти, които да могат да работят с бърз поток от приложения, да издържат на големи натоварвания, а самата система може лесно да се мащабира.

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

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

Какво е точкуване

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. Модул за интегриране на административното приложение със Serverless framework за последващо внедряване на правила.
5. Скриптове от правила за тестване на производителността на цялата система и агрегиране на анализи за входящи заявления (взети решения) за окончателна демонстрация.

Да започнем в ред.

Нашият интерфейс беше написан на Angular 7 с помощта на банковия UI Kit. Финалната версия на админ панела изглеждаше така:

Тъй като времето беше малко, се опитахме да внедрим само ключовата функционалност. За да разположите функция в клъстера на Kubernetes, беше необходимо да изберете събитие (услуга, за която трябва да се внедри правило в облака) и кода на функцията, която прилага логиката за вземане на решение. За всяко внедряване на правило за избраната услуга записахме дневник на това събитие. В административния панел можете да видите логове на всички събития.

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

В допълнение към функциите на правилата, ние също внедрихме възможността за постепенно обогатяване на изходните данни с помощта на функции за обогатяване, чийто код също беше скриптове, в които беше възможно да отидете в хранилището на данни, да се обадите на услуги на трети страни и да извършите предварителни изчисления . За да демонстрираме нашето решение, изчислихме зодията на клиента, който е оставил заявката, и определихме неговия мобилен оператор, използвайки REST услуга на трета страна.

Бекендът на платформата е написан на Java и е реализиран като Spring Boot приложение. Първоначално планирахме да използваме Postgres за съхраняване на администраторски данни, но като част от хакатона решихме да се ограничим до обикновен H2, за да спестим време. В бекенда е внедрена интеграция с Bitbucket за версия на функциите за обогатяване на заявки и скриптове за правила. За интеграция с отдалечени Git хранилища използвахме JGit библиотека, което е един вид обвивка на CLI команди, което ви позволява да изпълнявате всякакви git инструкции с помощта на удобен софтуерен интерфейс. Така че имахме две отделни хранилища за функции и правила за обогатяване и всички скриптове бяха разделени на директории. Чрез потребителския интерфейс беше възможно да се избере последният комит на скрипт на произволен клон на хранилището. Когато правите промени в кода през административния панел, ангажиментите на променения код се създават в отдалечени хранилища.

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

За да работим с Fission, използвахме Fission CLI, който трябва да бъде инсталиран върху Kubernetes CLI. Разполагането на функции в k8s клъстер е доста просто; просто трябва да зададете вътрешен маршрут и вход към функцията, за да разрешите входящия трафик, ако е необходим достъп извън клъстера. Внедряването на една функция обикновено отнема не повече от 10 секунди.

Окончателно представяне на проекта и обобщение

За да демонстрираме как работи нашата система, поставихме лесен формуляр на отдалечен сървър, където можете да подадете заявка за някой от продуктите на банката. За да поискате, трябваше да въведете вашите инициали, дата на раждане и телефонен номер.

Данните от клиентската форма отидоха до администратора, който едновременно изпрати заявки за всички налични правила, като предварително обогати данните според зададените условия и ги запази в общо хранилище. Общо разгърнахме три функции, които вземат решения за входящи приложения и 4 услуги за обогатяване на данни. След подаване на заявката, клиентът получи нашето решение:

Освен отказ или одобрение, клиентът получаваше и списък с други продукти, заявки за които изпращахме паралелно. Така демонстрирахме възможността за кръстосана продажба в нашата платформа.

Имаше налични общо 3 фиктивни банкови продукта:

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

По време на демонстрацията внедрихме подготвени функции и обогатяващи скриптове за всяка услуга.

Всяко правило изискваше собствен набор от входни данни. И така, за да одобрим ипотека, изчислихме зодията на клиента и го свързахме с логиката на лунния календар. За да одобрим играчка, проверихме дали клиентът е навършил пълнолетие и за издаване на заем изпратихме заявка до външна отворена услуга за определяне на клетъчния оператор и беше взето решение по него.

Постарахме се да направим нашата демонстрация интересна и интерактивна, всеки присъстващ можеше да отиде на нашата форма и да провери достъпността на нашите измислени услуги за тях. И в самия край на презентацията демонстрирахме анализи на получените заявления, които показаха колко хора са използвали нашата услуга, броя на одобренията и отказите.

За да събираме анализи онлайн, ние допълнително внедрихме BI инструмент с отворен код Метабаза и го завинтихме към нашата единица за съхранение. Метабазата ви позволява да създавате екрани с анализ на данните, които ни интересуват; просто трябва да регистрирате връзка към базата данни, да изберете таблици (в нашия случай колекции от данни, тъй като използвахме MongoDB) и да посочите полетата, които ни интересуват .

В резултат на това получихме добър прототип на платформа за вземане на решения и по време на демонстрацията всеки слушател може лично да провери нейната ефективност. Интересно решение, завършен прототип и успешна демонстрация ни позволиха да спечелим, въпреки силната конкуренция от други отбори. Сигурен съм, че за всеки проект на екип може да се напише интересна статия.

Източник: www.habr.com