Өткен жылдан бастап біздің компания хакатондар ұйымдастыра бастады. Мұндай бірінші байқау өте сәтті өтті, біз бұл туралы жазғанбыз . Екінші хакатон 2019 жылдың ақпан айында өтті және одан кем болмады. Соңғысын өткізудің алдағы мақсаттары туралы ұйымдастырушы.
Қатысушыларға оны жүзеге асыру үшін технологиялық стек таңдауда толық еркіндікпен өте қызықты тапсырма берілді. Қолданбалардың жылдам ағынымен жұмыс істей алатын, ауыр жүктемелерге төтеп бере алатын және жүйенің өзі оңай масштабталатын тұтынушылардың скорингтік функцияларын ыңғайлы орналастыру үшін шешім қабылдау платформасын енгізу қажет болды.
Тапсырма тривиальды емес және оны көптеген жолдармен шешуге болады, оған қатысушылардың жобаларының қорытынды презентацияларын көрсету кезінде көз жеткіздік. Хакатонда 6 адамнан тұратын 5 команда болды, барлық қатысушылардың жақсы жобалары болды, бірақ біздің платформа ең бәсекеге қабілетті болып шықты. Бізде өте қызықты жоба бар, мен ол туралы осы мақалада айтқым келеді.
Біздің шешіміміз - Kubernetes ішіндегі серверсіз архитектураға негізделген платформа, ол өндіріске жаңа мүмкіндіктерді енгізуге кететін уақытты азайтады. Ол аналитиктерге кодты өздеріне ыңғайлы ортада жазуға және оны инженерлер мен әзірлеушілердің қатысуынсыз өндіріске енгізуге мүмкіндік береді.
Ұпай деген не
Tinkoff.ru, көптеген заманауи компаниялар сияқты, тұтынушылардың скорингіне ие. Скоринг – деректерді талдаудың статистикалық әдістеріне негізделген тұтынушыларды бағалау жүйесі.
Мысалы, клиент бізге несие беру немесе бізден жеке кәсіпкер шотын ашу туралы өтінішпен жүгінеді. Егер біз оған несие беруді жоспарласақ, онда оның төлем қабілеттілігін бағалау керек, ал егер шот жеке кәсіпкер болса, онда клиенттің алаяқтық операцияларды жасамайтынына сенімді болуымыз керек.
Мұндай шешімдерді қабылдаудың негізі қолданбаның өзінен алынған деректерді де, біздің сақтауымыздағы деректерді де талдайтын математикалық модельдер болып табылады. Ұқсас статистикалық әдістерді бағалаудан басқа, біздің клиенттер үшін жаңа өнімдерге жеке ұсыныстар жасау қызметінде де қолдануға болады.
Мұндай бағалау әдісі әр түрлі кіріс деректерін қабылдай алады. Ал белгілі бір сәтте біз енгізуге жаңа параметрді қоса аламыз, ол тарихи деректер бойынша талдау нәтижелеріне сүйене отырып, қызметті пайдаланудың конверсия жылдамдығын арттырады.
Бізде тұтынушылармен қарым-қатынастар туралы көптеген деректер бар және бұл ақпараттың көлемі үнемі өсіп келеді. Ұпай жұмыс істеуі үшін деректерді өңдеу сонымен бірге кімнің өтінімді мақұлдайтынын, кімнен бас тарту керектігін және олардың әлеуетті қызығушылығын бағалай отырып, кімге бірнеше өнімді ұсыну керектігін жылдам шешуге мүмкіндік беретін ережелерді (немесе математикалық үлгілерді) қажет етеді.
Тапсырманы орындау үшін біз қазірдің өзінде арнайы шешім қабылдау жүйесін қолданамыз , ол талдаушылар, технологтар және әзірлеушілер белгілеген ережелер негізінде клиентке белгілі бір банктік өнімді мақұлдау немесе бас тарту туралы шешім қабылдайды.
Нарықта көптеген дайын шешімдер бар, олар скорингтік модельдер де, шешім қабылдау жүйелері де бар. Біз компаниямызда осы жүйелердің бірін қолданамыз. Бірақ бизнес өсуде, әртараптандыруда, клиенттердің саны да, ұсынылатын өнімдердің саны да артып келеді және осымен бірге қолданыстағы шешім қабылдау процесін жақсарту туралы идеялар пайда болады. Қолданыстағы жүйемен жұмыс істейтін адамдарда оны қалай қарапайым, жақсырақ, ыңғайлы ету туралы көптеген идеялар бар, бірақ кейде сырттан келетін идеялар пайдалы. Жаңа хакатон дұрыс идеяларды жинау мақсатында ұйымдастырылды.
Тапсырма
Хакатон 23 ақпанда өтті. Қатысушыларға жауынгерлік тапсырма ұсынылды: бірқатар шарттарға сай шешім қабылдау жүйесін әзірлеу.
Бізге қолданыстағы жүйенің қалай жұмыс істейтіні және оның жұмыс істеуі кезінде қандай қиындықтар туындайтыны, сондай-ақ әзірленген платформа қандай бизнес мақсаттарды көздейтіні туралы айтылды. Жүйеде талдаушылардың жұмыс коды өндіріске мүмкіндігінше тез енуі үшін ережелерді әзірлеу үшін жылдам нарыққа шығу уақыты болуы керек. Ал өтініштердің кіріс ағыны үшін шешім қабылдау уақыты ең азға ұмтылуы керек. Сондай-ақ, әзірленіп жатқан жүйеде клиентке компанияның басқа өнімдерін, егер олар біз мақұлдаса және клиент тарапынан әлеуетті қызығушылық болса, сатып алу мүмкіндігін беру үшін кросс-сату мүмкіндіктері болуы керек.
Шығаруға дайын жобаны бір түнде жазу мүмкін емес екені анық, ол сөзсіз өндіріске енеді және бүкіл жүйені қамту өте қиын, сондықтан бізден оның кем дегенде бір бөлігін жүзеге асыруды сұрады. Прототип қанағаттандыруы тиіс бірқатар талаптар белгіленді. Барлық талаптарды толығымен қамтуға және әзірленіп жатқан платформаның жеке бөлімдерінде егжей-тегжейлі жұмыс істеуге тырысуға болады.
Технологияға келетін болсақ, барлық қатысушыларға таңдауға толық еркіндік берілді. Кез келген концепциялар мен технологияларды пайдалану мүмкін болды: деректер ағыны, машиналық оқыту, оқиға көзі, үлкен деректер және т.б.
Біздің шешім
Кішкене миға шабуылдан кейін біз FaaS шешімі тапсырманы орындау үшін өте қолайлы деп шештік.
Бұл шешім үшін әзірленіп жатқан шешім қабылдау жүйесінің ережелерін жүзеге асыру үшін қолайлы Серверсіз құрылымды табу қажет болды. Tinkoff Kubernetes-ті инфрақұрылымды басқару үшін белсенді түрде пайдаланатындықтан, біз оның негізінде бірнеше дайын шешімдерді қарастырдық; Мен бұл туралы кейінірек айтып беремін.
Ең тиімді шешімді табу үшін біз оны пайдаланушылардың көзімен әзірленетін өнімді қарадық. Жүйенің негізгі пайдаланушылары ережені әзірлеуге қатысатын талдаушылар болып табылады. Ережелер серверге орналастырылуы керек немесе біздің жағдайымыздағыдай, кейіннен шешім қабылдау үшін бұлтта орналастырылуы керек. Талдаушының көзқарасы бойынша жұмыс процесі келесідей көрінеді:
- Талдаушы қоймадағы деректерге негізделген сценарийді, ережені немесе ML үлгісін жазады. Хакатон аясында біз Mongodb пайдалануды шештік, бірақ бұл жерде деректерді сақтау жүйесін таңдау маңызды емес.
- Тарихи деректер бойынша әзірленген ережелерді сынақтан өткізгеннен кейін талдаушы өзінің кодын әкімші панеліне жүктейді.
- Нұсқалауды қамтамасыз ету үшін барлық код Git репозиторийлеріне өтеді.
- Әкімші панелі арқылы кодты бұлтта бөлек функционалды серверсіз модуль ретінде орналастыруға болады.
Клиенттердің бастапқы деректері бастапқы сұрауды қоймадағы деректермен байыту үшін әзірленген мамандандырылған байыту қызметі арқылы өтуі керек. Бірыңғай деректер құрылымын қолдау үшін бұл қызметті бір репозиториймен жұмыс істейтіндей етіп енгізу маңызды болды (талдаушы ережелерді әзірлеу кезінде деректерді алады).
Тіпті хакатонға дейін біз қолданатын серверсіз құрылымды шештік. Бүгінгі күні нарықта осы тәсілді жүзеге асыратын көптеген технологиялар бар. Kubernetes архитектурасындағы ең танымал шешімдер - Fission, Open FaaS және Kubeless. Тіпті бар .
Барлық артықшылықтар мен кемшіліктерді өлшеп, біз таңдадық . Бұл серверсіз құрылымды басқару өте оңай және тапсырманың талаптарына жауап береді.
Fission бағдарламасымен жұмыс істеу үшін екі негізгі ұғымды түсіну керек: функция және қоршаған орта. Функция - бұл Fission ортасы бар тілдердің бірінде жазылған код бөлігі. Python, JS, Go, JVM және басқа да көптеген танымал тілдер мен технологияларды қамтиды.
Fission сонымен қатар мұрағатқа алдын ала оралған бірнеше файлдарға бөлінген функцияларды орындауға қабілетті. Kubernetes кластеріндегі Fission жұмысы рамканың өзі басқаратын арнайы қосқыштармен қамтамасыз етіледі. Кластер қосқыштарымен әрекеттесу үшін әрбір функцияға POST сұрауы жағдайында GET параметрлерін немесе сұрау денесін өткізуге болатын өз маршруты тағайындалуы керек.
Нәтижесінде біз талдаушыларға инженерлер мен әзірлеушілердің қатысуынсыз әзірленген ереже сценарийлерін орналастыруға мүмкіндік беретін шешімді алуды жоспарладық. Сипатталған тәсіл әзірлеушілердің аналитик кодын басқа тілге қайта жазу қажеттілігін де болдырмайды. Мысалы, біз қолданатын қазіргі шешім қабылдау жүйесі үшін біз ережелерді жоғары мамандандырылған технологиялар мен тілдерде жазуымыз керек, олардың қолданылу аясы өте шектеулі, сонымен қатар қосымшалар серверіне қатты тәуелділік бар, өйткені барлық банк ережелерінің жобалары бір ортада орналастырылады. Нәтижесінде жаңа ережелерді енгізу үшін бүкіл жүйені босату қажет.
Біздің ұсынылған шешімімізде ережелерді шығарудың қажеті жоқ; кодты бір түймені басу арқылы оңай орналастыруға болады. Сондай-ақ, Kubernetes-тегі инфрақұрылымды басқару жүктеме мен масштабтау туралы ойламауға мүмкіндік береді, мұндай мәселелер қораптан тыс шешіледі. Бірыңғай деректер қоймасын пайдалану нақты уақыттағы деректерді тарихи деректермен салыстыру қажеттілігін жояды, бұл талдаушының жұмысын жеңілдетеді.
Бізде не бар
Біз хакатонға дайын шешіммен (қиялымызда) келгендіктен, бізге барлық ойларымызды код жолына айналдыру ғана қалды.
Кез келген хакатонда табысқа жетудің кілті - дайындық және жақсы жазылған жоспар. Сондықтан, біз ең алдымен жүйе архитектурасының қандай модульдерден тұратынын және қандай технологияларды қолданатынымызды шештік.
Біздің жобаның архитектурасы келесідей болды:
Бұл диаграмма екі кіру нүктесін көрсетеді, талдаушы (жүйенің негізгі пайдаланушысы) және клиент.
Жұмыс процесі осылай құрылымдалған. Аналитик өз үлгісі үшін ереже функциясын және деректерді байыту функциясын әзірлейді, оның кодын Git репозиторийінде сақтайды және әкімші қолданбасы арқылы моделін бұлтқа орналастырады. Орналастырылған функция қалай шақырылатынын және клиенттерден түсетін кіріс сұраулары бойынша шешім қабылдауды қарастырайық:
- Клиент веб-сайтта нысанды толтырып, бақылаушыға сұрауын жібереді. Шешім қабылдануы қажет өтініш жүйе енгізуіне түседі және бастапқы түрінде деректер базасына жазылады.
- Әрі қарай, қажет болған жағдайда шикізат сұранысы байытуға жіберіледі. Бастапқы сұрауды сыртқы қызметтерден де, жадтан да деректермен толықтыруға болады. Алынған байытылған сұрау да дерекқорда сақталады.
- Кіріс ретінде байытылған сұрауды қабылдайтын және сақтау орнына жазылатын шешімді шығаратын талдаушы функциясы іске қосылады.
JSON құжаттары түріндегі деректердің құжатқа бағытталған сақталуына байланысты MongoDB-ті жүйемізде сақтау орны ретінде пайдалануды ұйғардық, өйткені байыту қызметтері, оның ішінде бастапқы сұрау, REST контроллері арқылы барлық деректерді біріктірді.
Сонымен, платформаны жүзеге асыру үшін бізде XNUMX сағат болды. Біз рөлдерді сәтті бөлдік, әр топ мүшесінің жобамызда өз жауапкершілігі бар:
- Талдаушының жұмысына арналған басқару панельдері, ол арқылы жазбаша сценарийлердің нұсқаларын басқару жүйесінен ережелерді жүктеп алуға, кіріс деректерін байыту опцияларын таңдауға және ереже сценарийлерін желіде өңдеуге болады.
- Backend әкімшісі, соның ішінде фронтқа арналған REST API және VCS-пен интеграция.
- Google Cloud жүйесінде инфрақұрылымды орнату және бастапқы деректерді байыту қызметін дамыту.
- Ережелерді кейінгі қолдану үшін әкімші қолданбасын Серверсіз құрылыммен біріктіруге арналған модуль.
- Бүкіл жүйенің өнімділігін тестілеу ережелерінің сценарийлері және қорытынды демонстрация үшін кіріс өтінімдері (қабылданған шешімдер) бойынша аналитиканы біріктіру.
Кезекпен бастайық.
Біздің интерфейс банкинг UI жинағы арқылы Angular 7-де жазылған. Әкімші панелінің соңғы нұсқасы келесідей болды:
Уақыт аз болғандықтан, біз тек негізгі функционалдылықты енгізуге тырыстық. Функцияны Kubernetes кластерінде қолдану үшін оқиғаны (бұлтта ережені орналастыру қажет қызмет) және шешім қабылдау логикасын жүзеге асыратын функцияның кодын таңдау қажет болды. Таңдалған қызмет үшін ережені әрбір орналастыру үшін біз осы оқиғаның журналын жаздық. Әкімші панелінде сіз барлық оқиғалардың журналдарын көре аласыз.
Барлық функция коды қашықтағы Git репозиторийінде сақталды, оны да басқару тақтасында орнату керек болды. Кодтың нұсқасын жасау үшін барлық функциялар репозиторийдің әртүрлі тармақтарында сақталды. Әкімші тақтасы сонымен қатар жазбаша сценарийлерге түзетулер енгізу мүмкіндігін береді, осылайша функцияны өндіріске қолданбас бұрын, тек жазбаша кодты тексеріп қана қоймай, сонымен қатар қажетті өзгерістерді енгізуге болады.
Ережелер функцияларынан басқа, біз байыту функцияларын пайдаланып бастапқы деректерді біртіндеп байыту мүмкіндігін енгіздік, оның коды да деректер қоймасына кіруге, үшінші тарап қызметтеріне қоңырау шалуға және алдын ала есептеулерді орындауға болатын сценарийлер болды. . Шешімді көрсету үшін біз сұрауды қалдырған клиенттің зодиак белгісін есептедік және үшінші тараптың REST қызметін пайдалана отырып, оның ұялы байланыс операторын анықтадық.
Платформаның сервері Java тілінде жазылған және Spring Boot қолданбасы ретінде енгізілген. Біз бастапқыда әкімші деректерін сақтау үшін Postgres-ті пайдалануды жоспарладық, бірақ хакатонның бір бөлігі ретінде уақытты үнемдеу үшін қарапайым H2-мен шектелуді шештік. Сұрауды байыту функциялары мен ереже сценарийлерінің нұсқасы үшін серверде Bitbucket-пен интеграция жүзеге асырылды. Қашықтағы Git репозиторийлерімен біріктіру үшін біз қолдандық , бұл ыңғайлы бағдарламалық интерфейс арқылы кез келген git нұсқауларын орындауға мүмкіндік беретін CLI пәрмендері үстінен орауыш түрі. Сонымен, бізде байыту функциялары мен ережелері үшін екі бөлек репозиторий болды және барлық сценарийлер каталогтарға бөлінді. UI арқылы репозиторийдің ерікті тармағының сценарийінің соңғы тапсырмасын таңдауға болады. Әкімші панелі арқылы кодқа өзгерістер енгізу кезінде қашықтағы репозитарийлерде өзгертілген кодтың міндеттемелері жасалды.
Идеямызды жүзеге асыру үшін бізге қолайлы инфрақұрылым қажет болды. Біз Kubernetes кластерін бұлтта орналастыруды шештік. Біздің таңдауымыз Google Cloud Platform болды. Fission серверсіз құрылымы Kubernetes кластеріне орнатылды, біз оны Gcloud жүйесінде орналастырдық. Бастапқыда бастапқы деректерді байыту қызметі k8s кластерінің ішіндегі Pod ішіне оралған бөлек Java қолданбасы ретінде жүзеге асырылды. Бірақ хакатонның ортасында жобамыздың алдын ала көрсетілімінен кейін бізге кіріс қосымшаларының бастапқы деректерін байыту жолын таңдау мүмкіндігін беру үшін Enrichment қызметін икемді ету ұсынылды. Бізде байыту қызметін де серверсіз етуден басқа амал қалмады.
Fission-пен жұмыс істеу үшін біз Fission CLI қолдандық, ол Kubernetes CLI үстіне орнатылуы керек. K8s кластеріне функцияларды қолдану өте қарапайым; кластерден тыс кіру қажет болса, кіріс трафикке рұқсат беру үшін ішкі маршрутты тағайындау және функцияға кіру қажет. Бір функцияны қолдану әдетте 10 секундтан аспайды.
Жобаны қорытындылау және қорытындылау
Жүйенің қалай жұмыс істейтінін көрсету үшін біз қашықтағы серверге банк өнімдерінің біріне өтінім беруге болатын қарапайым пішінді орналастырдық. Өтініш беру үшін өзіңіздің аты-жөніңізді, туған күніңізді және телефон нөміріңізді енгізу керек болды.
Клиент пішіміндегі деректер контроллерге барды, ол бір уақытта барлық қол жетімді ережелерге сұраныс жібереді, бұрын көрсетілген шарттарға сәйкес деректерді байытып, оларды жалпы жадта сақтайды. Барлығы кіріс қолданбалар бойынша шешім қабылдайтын үш функцияны және деректерді байыту бойынша 4 қызметті қолдандық. Өтінішті жібергеннен кейін клиент біздің шешімімізді алды:
Бас тартудан немесе мақұлдаудан басқа, клиент басқа өнімдердің тізімін алды, олар бойынша біз параллель түрде жіберген сұраныстар. Осылайша біз платформамызда кросс-сату мүмкіндігін көрсеттік.
Барлығы 3 жалған банк өнімдері қолжетімді болды:
- Несие.
- Ойыншық
- Ипотека.
Көрсету барысында біз әр қызмет үшін дайындалған функциялар мен байыту сценарийлерін орналастырдық.
Әрбір ереже өзінің кіріс деректер жинағын талап етті. Сонымен, ипотеканы мақұлдау үшін біз клиенттің зодиак белгісін есептеп, оны ай күнтізбесінің логикасымен байланыстырдық. Ойыншықты мақұлдау үшін клиенттің кәмелеттік жасқа толғанын тексеріп, несие беру үшін ұялы байланыс операторын анықтау үшін сыртқы ашық қызметке сұраныс жібердік, ол бойынша шешім қабылданды.
Біз демонстрациямызды қызықты және интерактивті етуге тырыстық, келгендердің барлығы біздің формаға кіріп, оларға біздің ойдан шығарылған қызметтеріміздің бар-жоғын тексере алады. Тұсаукесердің ең соңында біз біздің қызметімізді қанша адам пайдаланғанын, мақұлдаулар мен бас тартулар санын көрсететін келіп түскен өтініштердің аналитикасын көрсеттік.
Интернеттегі аналитиканы жинау үшін біз ашық бастапқы BI құралын қосымша қолдандық және оны біздің сақтау құрылғысына бұрап қойды. Метабаза бізді қызықтыратын деректер бойынша аналитикасы бар экрандарды құруға мүмкіндік береді; сізге дерекқорға қосылымды тіркеу, кестелерді таңдау (біздің жағдайда, біз MongoDB пайдаланғандықтан, деректер жинақтары) және бізді қызықтыратын өрістерді көрсету керек. .
Нәтижесінде біз шешім қабылдау алаңының жақсы прототипін алдық және демонстрация кезінде әрбір тыңдаушы оның орындалуын жеке тексере алды. Қызықты шешім, дайын прототип және сәтті көрсетілім басқа командалардың күшті бәсекелестігіне қарамастан жеңіске жетуге мүмкіндік берді. Әр топтың жобасына қызықты мақала жазуға болатынына сенімдімін.
Ақпарат көзі: www.habr.com