Kepiye carane nggawe maya FaaS ing Kubernetes lan menang hackathon Tinkoff

Wiwit taun kepungkur, perusahaan kita wiwit ngatur hackathon. Kompetisi pisanan kasebut sukses banget, kita nulis babagan iki artikel. Hackathon kapindho ditindakake ing Februari 2019 lan ora kalah sukses. Babagan tujuan nyekel sing terakhir durung suwe wrote organizer.

Para peserta diwenehi tugas sing rada menarik kanthi kebebasan lengkap kanggo milih tumpukan teknologi kanggo implementasine. Sampeyan perlu kanggo ngleksanakake platform kanggo nggawe keputusan kanggo panyebaran trep saka fungsi nyetak pelanggan sing bisa karo aliran cepet saka aplikasi, tahan beban abot, lan sistem dhewe gampang keukur.

Tugas kasebut ora pati penting lan bisa ditanggulangi kanthi pirang-pirang cara, amarga kita yakin nalika demonstrasi presentasi pungkasan proyek para peserta. Ana 6 tim saka 5 wong ing hackathon, kabeh peserta duwe proyek apik, nanging platform kita dadi sing paling kompetitif. Kita duwe proyek sing menarik banget, sing arep dakkandhakake ing artikel iki.

Solusi kita yaiku platform adhedhasar arsitektur Tanpa Server ing Kubernetes, sing nyuda wektu sing dibutuhake kanggo ngasilake fitur anyar menyang produksi. Iki ngidini analis nulis kode ing lingkungan sing trep kanggo dheweke lan nyebarake menyang produksi tanpa partisipasi insinyur lan pangembang.

Apa sing menehi skor

Tinkoff.ru, kaya akeh perusahaan modern, duwe skor pelanggan. Skor minangka sistem penilaian pelanggan adhedhasar metode statistik analisis data.

Contone, klien nguripake kita kanthi panjaluk kanggo ngetokake utangan, utawa mbukak akun wirausaha individu karo kita. Yen kita rencana kanggo ngetokake silihan, kita kudu netepake solvency, lan yen akun iku pengusaha individu, kita kudu nggawe manawa klien ora nindakake transaksi fraudulent.

Basis kanggo nggawe keputusan kasebut yaiku model matematika sing nganalisa data saka aplikasi kasebut dhewe lan data saka panyimpenan kita. Saliyane menehi skor, cara statistik sing padha uga bisa digunakake ing layanan ngasilake rekomendasi individu kanggo produk anyar kanggo klien kita.

Cara pambiji kasebut bisa nampa macem-macem data input. Lan ing sawetara titik kita bisa nambah parameter anyar menyang input, sing, adhedhasar asil analisis data historis, bakal nambah tingkat konversi nggunakake layanan kasebut.

Kita duwe akeh data babagan hubungan pelanggan, lan volume informasi iki saya tambah akeh. Kanggo menehi skor bisa digunakake, pangolahan data uga mbutuhake aturan (utawa model matematika) sing ngidini sampeyan mutusake kanthi cepet sapa sing bakal nyetujoni aplikasi, sapa sing nolak, lan sapa sing bakal menehi sawetara produk liyane, ngetesake kapentingan potensial.

Kanggo tugas sing ditindakake, kita wis nggunakake sistem pengambilan keputusan khusus IBM WebSphere ILOG JRules BRMS, sing, adhedhasar aturan sing disetel dening analis, teknolog lan pangembang, mutusake manawa bakal nyetujoni utawa nolak produk perbankan tartamtu menyang klien.

Ana akeh solusi sing wis siap ing pasar, model skor lan sistem nggawe keputusan dhewe. Kita nggunakake salah siji saka sistem iki ing perusahaan kita. Nanging bisnis saya tambah akeh, macem-macem, jumlah klien lan jumlah produk sing ditawakake saya tambah akeh, lan bebarengan karo iki, ide muncul babagan carane nambah proses nggawe keputusan sing wis ana. Mesthine wong sing nggarap sistem sing wis ana akeh ide babagan carane nggawe luwih gampang, luwih apik, luwih trep, nanging kadhangkala ide saka njaba migunani. New Hackathon diorganisir kanthi tujuan kanggo ngumpulake ide sing apik.

tugas

Hackathon dianakaké tanggal 23 Februari. Para peserta ditawani tugas tempur: ngembangake sistem pengambilan keputusan sing kudu nyukupi sawetara syarat.

Kita dikandhani kepiye fungsi sistem sing ana lan kesulitan apa sing kedadeyan sajrone operasi kasebut, uga tujuan bisnis apa sing kudu ditindakake platform sing dikembangake. Sistem kasebut kudu duwe wektu cepet kanggo pasar kanggo ngembangake aturan supaya kode kerja analis bisa dadi produksi kanthi cepet. Lan kanggo aliran aplikasi sing mlebu, wektu nggawe keputusan kudu minimal. Uga, sistem sing dikembangake kudu nduweni kemampuan cross-sell supaya bisa menehi klien kesempatan kanggo tuku produk perusahaan liyane yen disetujoni dening kita lan duwe kapentingan potensial saka klien.

Cetha yen ora bisa nulis proyek siap-kanggo-rilis sewengi sing mesthi bakal dadi produksi, lan cukup angel kanggo nutupi kabeh sistem, mula kita dijaluk ngetrapake paling ora bagean kasebut. Sawetara syarat ditetepake sing kudu ditindakake prototipe. Sampeyan bisa nyoba loro-lorone kanggo nutupi kabeh syarat, lan bisa digunakake kanthi rinci babagan bagean individu ing platform sing dikembangake.

Ing babagan teknologi, kabeh peserta diwenehi kebebasan lengkap kanggo milih. Sampeyan bisa nggunakake konsep lan teknologi apa wae: Streaming data, pembelajaran mesin, sumber acara, data gedhe lan liya-liyane.

Solusi kita

Sawise brainstorming sethithik, kita mutusake manawa solusi FaaS bakal cocog kanggo ngrampungake tugas kasebut.

Kanggo solusi iki, perlu golek kerangka Serverless sing cocog kanggo ngetrapake aturan sistem nggawe keputusan sing dikembangake. Wiwit Tinkoff aktif nggunakake Kubernetes kanggo manajemen infrastruktur, kita ndeleng sawetara solusi sing wis siap adhedhasar iku; Aku bakal ngandhani sampeyan luwih lengkap babagan iki.

Kanggo nemokake solusi sing paling efektif, kita ndeleng produk sing dikembangake liwat mata pangguna. Pangguna utama sistem kita yaiku analis sing melu pangembangan aturan. Aturan kasebut kudu disebarake menyang server, utawa, kaya ing kasus kita, disebarake ing awan, kanggo nggawe keputusan sabanjure. Saka perspektif analis, alur kerja katon kaya iki:

1. Analis nulis skrip, aturan, utawa model ML adhedhasar data saka gudang. Minangka bagéan saka hackathon, kita mutusake nggunakake Mongodb, nanging pilihan sistem panyimpenan data ora penting ing kene.
2. Sawise nguji aturan sing dikembangake babagan data sejarah, analis ngunggah kode menyang panel admin.
3. Kanggo mesthekake versi, kabeh kode bakal pindhah menyang repositori Git.
4. Liwat panel admin bakal bisa nyebarake kode kasebut ing awan minangka modul Serverless fungsional sing kapisah.

Data awal saka klien kudu ngliwati layanan Pengayaan khusus sing dirancang kanggo nambah panjaluk awal kanthi data saka gudang. Penting kanggo ngleksanakake layanan iki kanthi cara sing bisa digunakake karo gudang siji (saka ngendi analis njupuk data nalika ngembangake aturan) kanggo njaga struktur data sing manunggal.

Malah sadurunge hackathon, kita mutusake babagan kerangka Serverless sing bakal digunakake. Dina iki ana cukup akeh teknologi ing pasar sing ngleksanakake pendekatan iki. Solusi sing paling populer ing arsitektur Kubernetes yaiku Fission, Open FaaS lan Kubeless. Malah ana artikel apik karo deskripsi lan analisis komparatif.

Sawise nimbang kabeh pro lan kontra, kita milih Pambuka. Framework Tanpa Server iki cukup gampang kanggo ngatur lan nyukupi syarat tugas kasebut.

Kanggo nggarap Fission, sampeyan kudu ngerti rong konsep dhasar: fungsi lan lingkungan. Fungsi minangka potongan kode sing ditulis ing salah sawijining basa sing ana lingkungan Fission. Dhaptar lingkungan sing ditindakake ing kerangka iki kalebu Python, JS, Go, JVM lan akeh basa lan teknologi populer liyane.

Fission uga bisa nindakake fungsi sing dipérang dadi sawetara file, sing wis dikemas dadi arsip. Operasi Fission ing kluster Kubernetes dijamin dening pod khusus, sing dikelola dening kerangka kasebut dhewe. Kanggo sesambungan karo polong kluster, saben fungsi kudu diwenehi rute dhewe, lan sampeyan bisa ngliwati paramèter GET utawa njaluk awak ing kasus panyuwunan POST.

Akibaté, kita ngrancang entuk solusi sing bakal ngidini analis nyebarake skrip aturan sing dikembangake tanpa partisipasi insinyur lan pangembang. Pendekatan sing diterangake uga ngilangi kabutuhan pangembang kanggo nulis ulang kode analis menyang basa liya. Contone, kanggo sistem nggawe keputusan saiki kita nggunakake, kita kudu nulis aturan ing teknologi Highly specialized lan basa, orane katrangan kang arang banget winates, lan ana uga katergantungan kuwat ing server aplikasi, amarga kabeh konsep aturan bank. disebarake ing lingkungan siji. Akibaté, kanggo masang aturan anyar perlu kanggo ngeculake kabeh sistem.

Ing solusi sing diusulake, ora perlu ngeculake aturan; kode bisa gampang disebarake kanthi ngeklik tombol. Kajaba iku, manajemen infrastruktur ing Kubernetes ngidini sampeyan ora mikir babagan beban lan skala; masalah kasebut dirampungake metu saka kothak. Lan panggunaan gudang data siji ngilangi kabutuhan kanggo mbandhingake data wektu nyata karo data historis, sing nyederhanakake karya analis.

Apa kita entuk

Wiwit kita teka ing hackathon kanthi solusi sing wis siap (ing fantasi), kabeh sing kudu ditindakake yaiku ngowahi kabeh pikirane dadi baris kode.

Kunci sukses ing hackathon apa wae yaiku persiapan lan rencana sing ditulis kanthi apik. Mula, sing sepisanan ditindakake yaiku mutusake modul apa arsitektur sistem kita lan teknologi apa sing bakal digunakake.

Arsitektur proyek kita kaya ing ngisor iki:

Diagram iki nuduhake rong titik entri, analis (pangguna utama sistem kita) lan klien.

Proses kerja disusun kaya iki. Analis ngembangake fungsi aturan lan fungsi pengayaan data kanggo modele, nyimpen kode ing gudang Git, lan nyebarake model menyang awan liwat aplikasi administrator. Ayo dipikirake carane fungsi sing disebarake bakal diarani lan nggawe keputusan babagan panjaluk sing mlebu saka klien:

1. Klien ngisi formulir ing situs web lan ngirim panjaluke menyang pengontrol. Aplikasi sing kudu nggawe keputusan teka ing input sistem lan dicathet ing basis data ing wangun asline.
2. Sabanjure, panyuwunan mentah dikirim kanggo pengayaan, yen perlu. Sampeyan bisa nambah panjalukan awal karo data saka layanan eksternal lan saka panyimpenan. Asil enriched query uga disimpen ing database.
3. Fungsi analis diluncurake, sing njupuk pitakon sing diperkaya minangka input lan ngasilake solusi, sing uga ditulis ing panyimpenan.

Kita mutusake nggunakake MongoDB minangka panyimpenan ing sistem kita amarga panyimpenan data berorientasi dokumen ing bentuk dokumen JSON, amarga layanan pengayaan, kalebu panyuwunan asli, nggabungake kabeh data liwat pengontrol REST.

Dadi, kita duwe XNUMX jam kanggo ngetrapake platform kasebut. Kita mbagekke peran kasebut kanthi sukses; saben anggota tim duwe tanggung jawab dhewe ing proyek kita:

1. Panel admin ngarep-mburi kanggo karya Analyst, liwat kang bisa download aturan saka sistem kontrol versi script ditulis, pilih opsi kanggo data input enriching lan suntingan aturan Tulisan online.
2. Admin backend, kalebu REST API kanggo ngarep lan integrasi karo VCS.
3. Nyetel infrastruktur ing Google Cloud lan ngembangake layanan kanggo nambah data sumber.
4. Modul kanggo nggabungake aplikasi admin karo kerangka Serverless kanggo panyebaran aturan sabanjure.
5. Skrip aturan kanggo nguji kinerja kabeh sistem lan agregasi analytics ing aplikasi sing mlebu (keputusan sing digawe) kanggo demonstrasi pungkasan.

Ayo miwiti.

Frontend kita ditulis ing Angular 7 nggunakake Kit UI perbankan. Versi pungkasan saka panel admin katon kaya iki:

Wiwit ana wektu sethitik, kita nyoba kanggo ngleksanakake mung fungsi tombol. Kanggo nyebarake fungsi ing kluster Kubernetes, perlu kanggo milih acara (layanan sing aturan kudu disebarake ing awan) lan kode fungsi sing ngetrapake logika nggawe keputusan. Kanggo saben panyebaran aturan kanggo layanan sing dipilih, kita nulis log acara iki. Ing panel admin sampeyan bisa ndeleng log kabeh acara.

Kabeh kode fungsi disimpen ing repositori Git remot, sing uga kudu disetel ing panel admin. Kanggo versi kode, kabeh fungsi disimpen ing macem-macem cabang gudang. Panel admin uga menehi kemampuan kanggo nggawe pangaturan kanggo skrip ditulis, supaya sadurunge deploying fungsi kanggo produksi, sampeyan ora mung bisa mriksa kode ditulis, nanging uga nggawe owah-owahan perlu.

Saliyane fungsi aturan, kita uga ngetrapake kemampuan kanggo nambah data sumber kanthi bertahap kanthi nggunakake fungsi Pengayaan, kode kasebut uga skrip sing bisa pindhah menyang gudang data, nelpon layanan pihak katelu lan nindakake petungan awal. . Kanggo nduduhake solusi, kita ngetung tandha zodiak klien sing ninggalake panjaluk kasebut lan nemtokake operator seluler nggunakake layanan REST pihak katelu.

Backend platform kasebut ditulis ing Jawa lan diimplementasikake minangka aplikasi Spring Boot. Kita wiwitane ngrancang nggunakake Postgres kanggo nyimpen data admin, nanging, minangka bagéan saka hackathon, kita mutusake kanggo mbatesi awake dhewe menyang H2 sing prasaja supaya bisa ngirit wektu. Ing backend, integrasi karo Bitbucket dileksanakake kanggo versi fungsi pengayaan query lan skrip aturan. Kanggo integrasi karo repositori Git remot, kita nggunakake Pustaka JGit, yaiku jinis pambungkus liwat perintah CLI, ngidini sampeyan nglakokake instruksi git nggunakake antarmuka piranti lunak sing trep. Dadi, kita duwe rong repositori sing kapisah kanggo fungsi lan aturan pengayaan, lan kabeh skrip dipérang dadi direktori. Liwat UI, sampeyan bisa milih komit paling anyar saka skrip saka cabang repositori sing sewenang-wenang. Nalika nggawe pangowahan kode liwat panel admin, kode sing diganti digawe ing repositori remot.

Kanggo ngetrapake ide kita, kita butuh infrastruktur sing cocog. Kita mutusake kanggo nyebarake kluster Kubernetes ing méga. Pilihan kita yaiku Google Cloud Platform. Framework tanpa server Fission diinstal ing kluster Kubernetes, sing kita sebarake ing Gcloud. Kaping pisanan, layanan pengayaan data sumber dileksanakake minangka aplikasi Java kapisah sing dibungkus ing Pod ing kluster k8s. Nanging sawise demonstrasi awal proyek kita ing tengah hackathon, kita disaranake supaya layanan Pengayaan luwih fleksibel kanggo menehi kesempatan kanggo milih carane nambah data mentah saka aplikasi sing mlebu. Lan kita ora duwe pilihan nanging nggawe layanan pengayaan uga Serverless.

Kanggo nggarap Fission, kita nggunakake Fission CLI, sing kudu diinstal ing ndhuwur Kubernetes CLI. Nyebarake fungsi menyang kluster k8s cukup prasaja; sampeyan mung kudu nemtokake rute internal lan mlebu menyang fungsi kasebut kanggo ngidini lalu lintas mlebu yen akses ing njaba kluster dibutuhake. Nggunakake siji fungsi biasane njupuk ora luwih saka 10 detik.

Presentasi pungkasan proyek lan ringkesan

Kanggo nduduhake cara kerja sistem, kita wis nyelehake formulir sing prasaja ing server remot ing ngendi sampeyan bisa ngirim aplikasi kanggo salah sawijining produk bank. Kanggo njaluk, sampeyan kudu ngetik inisial, tanggal lahir lan nomer telpon.

Data saka wangun klien tindak menyang controller, kang bebarengan ngirim panjalukan kanggo kabeh aturan kasedhiya, wis sadurunge enriched data miturut kondisi kasebut, lan disimpen ing panyimpenan umum. Secara total, kita nggunakake telung fungsi sing nggawe keputusan babagan aplikasi sing mlebu lan 4 layanan pengayaan data. Sawise ngirim aplikasi, klien nampa keputusan kita:

Saliyane penolakan utawa persetujuan, klien uga nampa dhaptar produk liyane, panjaluk sing dikirim bebarengan. Mangkene carane kita nuduhake kemungkinan adol silang ing platform kita.

Ana total 3 produk bank fiktif sing kasedhiya:

• Kredit.
• Toy
• hipotek.

Sajrone demonstrasi, kita masang fungsi sing disiapake lan skrip pengayaan kanggo saben layanan.

Saben aturan mbutuhake set data input dhewe. Dadi, kanggo nyetujoni hipotek, kita ngetung tandha zodiak klien lan nyambungake iki karo logika kalender lunar. Kanggo nyetujoni dolanan, kita mriksa manawa klien wis tekan umur mayoritas, lan kanggo ngetokake silihan, kita ngirim panjaluk menyang layanan mbukak eksternal kanggo nemtokake operator seluler, lan keputusan kasebut digawe.

Kita nyoba nggawe demonstrasi menarik lan interaktif, kabeh wong sing saiki bisa mbukak formulir lan mriksa kasedhiyan layanan fiksi kanggo dheweke. Lan ing pungkasan presentasi, kita nuduhake analytics aplikasi sing ditampa, sing nuduhake jumlah wong sing nggunakake layanan kita, jumlah persetujuan, lan penolakan.

Kanggo ngumpulake analytics online, kita uga nggunakake alat BI open source Metabase lan ngaco menyang unit panyimpenan kita. Metabase ngidini sampeyan nggawe layar kanthi analytics babagan data sing menarik kanggo kita; sampeyan mung kudu ndhaptar sambungan menyang database, pilih tabel (ing kasus kita, koleksi data, amarga kita nggunakake MongoDB), lan nemtokake lapangan sing kita minati. .

Akibaté, kita entuk prototipe platform nggawe keputusan sing apik, lan sajrone demonstrasi, saben pamireng bisa mriksa kinerja. Solusi sing menarik, prototipe sing wis rampung lan demonstrasi sing sukses ngidini kita menang, sanajan kompetisi sing kuat saka tim liyane. Aku yakin manawa artikel sing menarik uga bisa ditulis ing saben proyek tim.

Source: www.habr.com