Өткөн жылдан баштап биздин компания хакатондорду уюштура баштады. Мындай биринчи сынак абдан ийгиликтүү болду, биз бул тууралуу жазганбыз . Экинчи хакатон 2019-жылдын февраль айында болуп өткөн жана андан кем эмес ийгиликтүү болгон. Жакында эле акыркысын өткөрүү максаттары жөнүндө уюштуруучу.
Катышуучуларга аны ишке ашыруу үчүн технологиялык стек тандоодо толук эркиндик менен бир топ кызыктуу тапшырма берилди. Тиркемелердин тез агымы менен иштей ала турган, оор жүктөргө туруштук бере турган жана системанын өзү оңой масштабдалуучу кардарлардын скорингдик функцияларын ыңгайлуу жайылтуу үчүн чечим кабыл алуу платформасын ишке ашыруу керек болчу.
Милдет анчалык деле маанилүү эмес жана аны ар кандай жолдор менен чечсе болот, буга катышуучулардын долбоорлорунун жыйынтыктоочу презентацияларын көрсөтүү учурунда ынандык. Хакатондо 6 адамдан турган 5 команда болду, бардык катышуучулардын жакшы долбоорлору бар болчу, бирок биздин платформа эң атаандаш болуп чыкты. Бизде абдан кызыктуу долбоор бар, мен бул макалада ал жөнүндө айткым келет.
Биздин чечим - бул Kubernetes ичиндеги Serverless архитектурасына негизделген платформа, ал өндүрүшкө жаңы функцияларды алып келүүгө кеткен убакытты азайтат. Бул аналитиктерге кодду өздөрү үчүн ыңгайлуу чөйрөдө жазууга жана аны инженерлердин жана иштеп чыгуучулардын катышуусуз өндүрүшкө жайылтууга мүмкүндүк берет.
Не деген упай
Tinkoff.ru, көптөгөн заманбап компаниялар сыяктуу эле, кардарлардын рейтингине ээ. Скоринг – маалыматтарды талдоонун статистикалык ыкмаларына негизделген кардарларды баалоо системасы.
Мисалы, кардар бизге насыя берүү, же бизден жеке ишкердин эсебин ачуу өтүнүчү менен кайрылат. Эгерде биз ага кредит берүүнү пландаштырсак, анда анын төлөө жөндөмдүүлүгүн баалашыбыз керек, ал эми эсеп жеке ишкер болсо, анда кардар алдамчылык операцияларды жүргүзбөйт деп ишенишибиз керек.
Мындай чечимдерди кабыл алуу үчүн негиз болуп, колдонмонун өзүнөн алынган маалыматтарды жана биздин сактагычтагы маалыматтарды талдоочу математикалык моделдер саналат. Упай коюудан тышкары, ушул сыяктуу статистикалык ыкмалар биздин кардарлар үчүн жаңы өнүмдөр боюнча жеке сунуштарды түзүү кызматында да колдонулушу мүмкүн.
Мындай баалоо ыкмасы ар кандай киргизүү маалыматтарды кабыл алат. Ал эми кайсы бир учурда биз киргизүүгө жаңы параметрди кошо алабыз, ал тарыхый маалыматтар боюнча анализдин жыйынтыгында кызматты колдонуунун конверсия ылдамдыгын жогорулатат.
Бизде кардарлардын мамилелери жөнүндө көптөгөн маалыматтар бар жана бул маалыматтын көлөмү тынымсыз өсүп жатат. Упайлардын иштеши үчүн маалыматтарды иштеп чыгуу эрежелерди (же математикалык моделдерди) талап кылат, алар кимге арызды жактырууну, ким баш тартууну жана кимге дагы бир нече өнүм сунуш кылууну, алардын потенциалдуу кызыгуусун баалоону тез чечүүгө мүмкүндүк берет.
Алдыда турган тапшырма үчүн биз чечим кабыл алуунун адистештирилген системасын колдонобуз , ал талдоочулар, технологдор жана иштеп чыгуучулар тарабынан белгиленген эрежелердин негизинде кардарга белгилүү бир банк продуктусун жактыруу же баш тартууну чечет.
Рынокто көптөгөн даяр чечимдер бар, алар баалоо моделдери жана чечимдерди кабыл алуу системалары. Биз компаниябызда бул системалардын бирин колдонобуз. Бирок бизнес өсүүдө, диверсификациялоодо, кардарлардын саны да, сунушталган продукциялардын саны да көбөйүүдө жана муну менен катар учурдагы чечимдерди кабыл алуу процессин жакшыртуу боюнча идеялар пайда болууда. Албетте, иштеп жаткан система менен иштеген адамдар аны кантип жөнөкөй, жакшыраак, ыңгайлуу кылуу боюнча көптөгөн идеяларга ээ, бирок кээде сырттан келген идеялар пайдалуу. New Hackathon туура идеяларды чогултуу максатында уюштурулган.
Тапшырма
Хакатон 23-февралда өткөн. Катышуучуларга согуштук тапшырма сунушталды: бир катар шарттарга жооп бериши керек болгон чечимдерди кабыл алуу системасын иштеп чыгуу.
Бизге иштеп жаткан система кандай иштээри жана анын иштөө учурунда кандай кыйынчылыктар пайда болоору, ошондой эле иштелип чыккан платформа кандай бизнес максаттарды көздөшү керектиги айтылды. Аналитиктердин жумушчу коду өндүрүшкө мүмкүн болушунча тезирээк кириши үчүн система эрежелерди иштеп чыгуу үчүн тез базарга чыгууга ээ болушу керек. Ал эми арыздардын кирүүчү агымы үчүн чечим кабыл алуу убактысы минималдуу болушу керек. Ошондой эле, иштелип жаткан система кардарга компаниянын башка өнүмдөрүн сатып алуу мүмкүнчүлүгүн берүү үчүн кайчылаш сатуу мүмкүнчүлүктөрүнө ээ болушу керек, эгерде алар биз жактырган болсо жана кардар тарабынан потенциалдуу кызыкчылык болсо.
Бул, албетте, өндүрүшкө кире турган чыгарууга даяр долбоорду бир түндө жазуу мүмкүн эмес экени түшүнүктүү жана бүт системаны камтуу абдан кыйын, ошондуктан бизден анын жок дегенде бир бөлүгүн ишке ашырууну суранышты. Прототиби жооп бериши керек болгон бир катар талаптар белгиленген. Бардык талаптарды толугу менен камтууга жана иштелип жаткан платформанын айрым бөлүмдөрүндө деталдуу иштөөгө аракет кылуу мүмкүн болду.
Технологияга келсек, бардык катышуучуларга тандоо эркиндиги толук берилген. Каалаган концепцияларды жана технологияларды колдонууга мүмкүн болду: Берилиштер агымы, машинаны үйрөнүү, окуя булактары, чоң маалыматтар жана башкалар.
Биздин чечим
Бир аз акыл чабуулунан кийин, биз FaaS чечими тапшырманы аткаруу үчүн идеалдуу болот деп чечтик.
Бул чечим үчүн, иштелип жаткан чечимдерди кабыл алуу тутумунун эрежелерин ишке ашыруу үчүн ылайыктуу Serverless негизин табуу керек болчу. Tinkoff инфраструктураны башкаруу үчүн Kubernetesти жигердүү колдонгондуктан, биз анын негизинде бир нече даяр чечимдерди карап чыктык; Мен бул тууралуу кийинчерээк айтып берем.
Эң натыйжалуу чечимди табуу үчүн, биз анын колдонуучуларынын көзү менен иштелип жаткан продуктуну карадык. Биздин системанын негизги колдонуучулары эрежени иштеп чыгууга катышкан аналитиктер. Эрежелер серверге жайгаштырылышы керек, же биздин жагдайдагыдай, кийинки чечимди кабыл алуу үчүн булутта жайгаштырылышы керек. Аналитиктин көз карашы боюнча, иш процесси төмөнкүдөй көрүнөт:
- Аналитик кампадагы маалыматтардын негизинде сценарий, эреже же ML моделин жазат. Хакатондун алкагында биз Mongodb колдонууну чечтик, бирок бул жерде маалыматтарды сактоо тутумун тандоо маанилүү эмес.
- Тарыхый маалыматтар боюнча иштелип чыккан эрежелерди сынап көргөндөн кийин, аналитик өзүнүн кодун администратор панелине жүктөйт.
- Версиялоону камсыздоо үчүн бардык код Git репозиторийлерине өтөт.
- Администратор панели аркылуу кодду булуттагы өзүнчө функционалдуу Serverless модулу катары жайылтууга болот.
Кардарлардын баштапкы маалыматтары кампадагы маалыматтар менен баштапкы суроо-талапты байытуу үчүн арналган адистештирилген Байытуу кызматы аркылуу өтүшү керек. Бул кызматты бирдиктүү репозиторий менен иштей тургандай кылып (аналитик эрежелерди иштеп чыгууда маалыматтарды алат) бирдиктүү маалымат түзүмүн сактоо үчүн ишке ашыруу маанилүү болгон.
Хакатонго чейин да биз колдоно турган Serverless алкагын чечтик. Бүгүнкү күндө рынокто бул ыкманы ишке ашыруу үчүн технологиялар абдан көп. Kubernetes архитектурасынын эң популярдуу чечимдери - Fission, Open FaaS жана Kubeless. Ал тургай бар .
Бардык жакшы жана жаман жактарын таразалап көрүп, тандап алдык . Бул Serverless алкак башкаруу үчүн абдан жеңил жана тапшырманын талаптарына жооп берет.
Fission менен иштөө үчүн сиз эки негизги түшүнүктү түшүнүшүңүз керек: функция жана айлана-чөйрө. Функция - бул Fission чөйрөсү бар тилдердин биринде жазылган коддун бөлүгү. Python, JS, Go, JVM жана башка көптөгөн популярдуу тилдерди жана технологияларды камтыйт.
Fission ошондой эле архивге алдын ала пакеттелген бир нече файлдарга бөлүнгөн функцияларды аткарууга жөндөмдүү. Kubernetes кластериндеги Fission иштеши алкактын өзү тарабынан башкарылуучу адистештирилген поддондор менен камсыз кылынат. Кластер поддондору менен иштешүү үчүн, ар бир функцияга өзүнүн маршруту дайындалышы керек жана POST сурамында сиз GET параметрлерин же суроонун органын өткөрө аласыз.
Натыйжада, биз аналитиктерге инженерлердин жана иштеп чыгуучулардын катышуусуз иштелип чыккан эрежелердин скрипттерин жайылтууга мүмкүндүк берген чечимди алууну пландаштырдык. Сүрөттөлгөн ыкма иштеп чыгуучулардын аналитик кодун башка тилге кайра жазуу зарылдыгын да жок кылат. Мисалы, биз колдонуп жаткан чечимдерди кабыл алуу системасы үчүн биз эрежелерди жогорку адистештирилген технологияларда жана тилдерде жазышыбыз керек, алардын чөйрөсү өтө чектелүү, ошондой эле тиркеме серверине күчтүү көз карандылык бар, анткени бардык банк эрежелеринин долбоорлору бир чөйрөдө жайгаштырылат. Натыйжада, жаңы эрежелерди жайылтуу үчүн бүт системаны чыгаруу керек.
Биздин сунуштаган чечимибизде эрежелерди чыгаруунун кажети жок; кодду бир баскычты чыкылдатуу менен оңой жайгаштырууга болот. Ошондой эле, Kubernetes инфраструктурасын башкаруу сизге жүктөө жана масштабдоо жөнүндө ойлонбоого мүмкүндүк берет, мындай көйгөйлөр кутудан чечилет. Ал эми бирдиктүү маалымат кампасын колдонуу аналитиктин ишин жөнөкөйлөткөн реалдуу убакыттагы маалыматтарды тарыхый маалыматтар менен салыштыруунун зарылдыгын жокко чыгарат.
Бизде эмне бар
Биз хакатонго даяр чечим менен келгендиктен (фантазияларыбызда), бардык ойлорубузду код саптарына айландыруу гана болду.
Ар кандай хакатондо ийгиликтин ачкычы - бул даярдык жана жакшы жазылган план. Ошондуктан, биз биринчи кылган нерсе, биздин системанын архитектурасы кандай модулдардан тураарын жана кандай технологияларды колдонорубузду чечтик.
Биздин долбоордун архитектурасы төмөнкүдөй болгон:
Бул диаграммада эки кирүү пункту, аналитик (системабыздын негизги колдонуучусу) жана кардар көрсөтүлгөн.
Иш процесси мына ушундай структураланган. Аналитик өзүнүн модели үчүн эреже функциясын жана маалыматтарды байытуу функциясын иштеп чыгат, анын кодун Git репозиторийинде сактайт жана администратор тиркемеси аркылуу өзүнүн моделин булутка жайгаштырат. Келгиле, орнотулган функция кантип чакырыларын карап көрөлү жана кардарлардан түшкөн суроо-талаптар боюнча чечим кабыл алалы:
- Кардар веб-сайтта форманы толтуруп, контроллерге өзүнүн суроо-талабын жөнөтөт. Чечим кабыл алынышы керек болгон өтүнмө системанын киргизүүсүнө келип, баштапкы түрүндө маалымат базасына жазылат.
- Андан кийин, зарыл болсо, чийки суроо-талап байытуу үчүн жөнөтүлөт. Сиз баштапкы суроо-талапты тышкы кызматтардан да, сактагычтан дагы маалыматтар менен толуктай аласыз. Натыйжада байытылган суроо да маалымат базасында сакталат.
- Аналитик функциясы ишке киргизилет, ал байытылган суроону киргизүү катары кабыл алат жана чечимди чыгарат, ал да сактагычка жазылат.
JSON документтери түрүндөгү маалыматтарды документке багытталган сакталгандыктан, MongoDBти тутумубузда сактагыч катары колдонууну чечтик, анткени байытуу кызматтары, анын ичинде баштапкы суроо-талап, REST контроллерлору аркылуу бардык маалыматтарды топтогон.
Ошентип, платформаны ишке ашыруу үчүн бизде XNUMX саат бар болчу. Биз ролдорду ийгиликтүү бөлүштүрдүк; биздин долбоордо команданын ар бир мүчөсүнүн өзүнүн жоопкерчилиги бар:
- Талдоочунун иши үчүн алдыңкы администратор панелдери, алар аркылуу ал жазуу жүзүндөгү скрипттердин версиясын башкаруу тутумунан эрежелерди жүктөй алат, киргизилген маалыматтарды байытуу үчүн варианттарды тандап, эреженин скрипттерин онлайн түзөтө алат.
- Backend администратору, анын ичинде фронт үчүн REST API жана VCS менен интеграция.
- Google Булутунда инфраструктураны орнотуу жана булак маалыматтарын байытуу кызматын иштеп чыгуу.
- Эрежелерди кийинки жайылтуу үчүн администратордук тиркемени Serverless алкактары менен интеграциялоо модулу.
- Бүткүл системанын иштешин текшерүү эрежелеринин скрипттери жана акыркы демонстрация үчүн келип түшкөн өтүнмөлөр (кабыл алынган чечимдер) боюнча аналитиканы бириктирүү.
анын башынан баштайлы.
Биздин frontend банктык UI Kit аркылуу 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 тиркемеси катары ишке ашырылган. Бирок хакатондун ортосунда биздин долбоордун алдын ала демонстрациясынан кийин, бизге келген тиркемелердин чийки маалыматтарын кантип байытууну тандоо мүмкүнчүлүгүн берүү үчүн байытуу кызматын ийкемдүү кылуу сунушталды. Жана бизде байытуу кызматын серверсиз кылуудан башка аргабыз жок болчу.
Fission менен иштөө үчүн биз Fission CLI колдондук, аны Kubernetes CLI үстүнө орнотуу керек. Функцияларды k8s кластерине жайгаштыруу абдан жөнөкөй; сиз жөн гана ички маршрутту дайындыңыз жана кластерден тышкары кирүү керек болсо, кирген трафикке уруксат берүү үчүн функцияга кирүү керек. Бир функцияны жайылтуу адатта 10 секунддан ашпайт.
Долбоордун жыйынтыктоочу презентациясы жана жыйынтыгын чыгаруу
Биздин системанын кантип иштээрин көрсөтүү үчүн биз алыскы серверге жөнөкөй форманы жайгаштырдык, анда сиз банктын продуктыларынын бирине арыз бере аласыз. Сурам үчүн инициалдарыңызды, туулган күнүңүздү жана телефон номериңизди киргизишиңиз керек болчу.
Кардар формасынан маалыматтар контроллерге келип түшкөн, ал бир эле учурда бардык жеткиликтүү эрежелерге суроо-талаптарды жөнөтүп, мурда көрсөтүлгөн шарттарга ылайык маалыматтарды байытып, аларды жалпы сактагычта сактаган. Бардыгы болуп, биз кирүүчү тиркемелер боюнча чечим кабыл алган үч функцияны жана маалыматтарды байытуу боюнча 4 кызматты орноттук. Арызды тапшыргандан кийин кардар биздин чечимди кабыл алды:
Баш тартуудан же жактыруудан тышкары, кардар биз параллелдүү түрдө жөнөткөн суроо-талаптарды дагы башка өнүмдөрдүн тизмесин алды. Мына ушундайча биз платформабызда кайчылаш сатуу мүмкүнчүлүгүн көрсөттүк.
Бардыгы болуп 3 жасалма банк продуктулары бар болчу:
- Кредит.
- куурчак
- Ипотека.
Демонстрация учурунда биз ар бир кызмат үчүн даярдалган функцияларды жана байытуу сценарийлерин жайгаштырдык.
Ар бир эреже өзүнүн киргизүү маалыматтарынын топтомун талап кылган. Ошентип, ипотеканы бекитүү үчүн биз кардардын зодиак белгисин эсептеп, аны ай календарынын логикасы менен байланыштырдык. Оюнчукту бекитүү үчүн кардардын бойго жеткенин текшерип, насыя берүү үчүн уюлдук операторду аныктоо боюнча тышкы ачык кызматка суроо-талап жөнөттүк жана ал боюнча чечим кабыл алынды.
Биз демонстрациябызды кызыктуу жана интерактивдүү өткөрүүгө аракет кылдык, катышуучулардын баары биздин формага кирип, биздин ойдон чыгарылган кызматтарыбыздын аларга жеткиликтүүлүгүн текшере алышат. Ал эми бет ачардын аягында биз келип түшкөн арыздардын аналитикасын көрсөттүк, ал биздин кызматты канча адам колдонгонун, жактыруулардын жана баш тартуулардын санын көрсөттү.
Аналитиканы онлайн чогултуу үчүн биз кошумча булактуу BI куралын колдондук жана аны биздин сактоочу бөлүмгө бурап койду. Метабаза бизди кызыктырган маалыматтар боюнча аналитика менен экрандарды курууга мүмкүндүк берет; сиз жөн гана маалымат базасына туташууну каттап, таблицаларды тандап алышыңыз керек (биздин учурда, биз MongoDB колдонгондуктан, маалымат жыйнактары) жана бизди кызыктырган талааларды көрсөтүшүңүз керек. .
Натыйжада биз чечим кабыл алуу платформасынын жакшы прототибин алдык жана демонстрация учурунда ар бир угуучу анын аткарылышын жеке өзү текшере алды. Кызыктуу чечим, даяр прототип жана ийгиликтүү демонстрация башка командалардын күчтүү атаандаштыгына карабай жеңишке жетишүүгө мүмкүндүк берди. Ар бир команданын долбоору боюнча кызыктуу макала да жазылса болот деп ишенем.
Source: www.habr.com