Bagaimana kami membuat awan FaaS di dalam Kubernetes dan memenangi hackathon Tinkoff

Bermula tahun lepas, syarikat kami mula menganjurkan hackathon. Pertandingan pertama sebegini sangat berjaya, kami menulis mengenainya dalam artikel. Hackathon kedua berlangsung pada Februari 2019 dan tidak kurang berjayanya. Mengenai matlamat mengadakan yang terakhir tidak lama dahulu saya menulis penganjur.

Para peserta diberi tugasan yang agak menarik dengan kebebasan sepenuhnya dalam memilih susunan teknologi untuk pelaksanaannya. Adalah perlu untuk melaksanakan platform membuat keputusan untuk penggunaan mudah fungsi pemarkahan pelanggan yang boleh berfungsi dengan aliran aplikasi yang pantas, menahan beban yang berat, dan sistem itu sendiri mudah berskala.

Tugas itu bukan remeh dan boleh diselesaikan dalam pelbagai cara, seperti yang kami yakini semasa demonstrasi pembentangan akhir projek peserta. Terdapat 6 pasukan yang terdiri daripada 5 orang di hackathon, semua peserta mempunyai projek yang bagus, tetapi platform kami ternyata yang paling kompetitif. Kami mempunyai projek yang sangat menarik, yang saya ingin bincangkan dalam artikel ini.

Penyelesaian kami ialah platform berdasarkan seni bina Tanpa Pelayan di dalam Kubernetes, yang mengurangkan masa yang diperlukan untuk membawa ciri baharu kepada pengeluaran. Ia membolehkan penganalisis menulis kod dalam persekitaran yang sesuai untuk mereka dan menggunakannya ke dalam pengeluaran tanpa penyertaan jurutera dan pembangun.

Apakah pemarkahan

Tinkoff.ru, seperti banyak syarikat moden, mempunyai pemarkahan pelanggan. Pemarkahan ialah sistem penilaian pelanggan berdasarkan kaedah statistik analisis data.

Sebagai contoh, pelanggan berpaling kepada kami dengan permintaan untuk mengeluarkan pinjaman kepadanya, atau membuka akaun usahawan individu dengan kami. Jika kami bercadang untuk mengeluarkan pinjaman kepadanya, maka kami perlu menilai kesolvenannya, dan jika akaun itu adalah usahawan individu, maka kami perlu memastikan bahawa pelanggan tidak akan melakukan transaksi penipuan.

Asas untuk membuat keputusan sedemikian adalah model matematik yang menganalisis kedua-dua data daripada aplikasi itu sendiri dan data daripada storan kami. Selain pemarkahan, kaedah statistik yang serupa juga boleh digunakan dalam perkhidmatan menjana cadangan individu untuk produk baharu untuk pelanggan kami.

Kaedah penilaian sedemikian boleh menerima pelbagai data input. Dan pada satu ketika kita boleh menambah parameter baharu pada input, yang, berdasarkan hasil analisis pada data sejarah, akan meningkatkan kadar penukaran menggunakan perkhidmatan tersebut.

Kami mempunyai banyak data tentang hubungan pelanggan, dan jumlah maklumat ini sentiasa berkembang. Untuk pemarkahan berfungsi, pemprosesan data juga memerlukan peraturan (atau model matematik) yang membolehkan anda memutuskan dengan cepat siapa yang akan meluluskan permohonan, siapa yang akan ditolak, dan siapa yang akan menawarkan beberapa lagi produk, menilai potensi minat mereka.

Untuk tugas di tangan, kami sudah menggunakan sistem membuat keputusan khusus IBM WebSphere ILOG JRules BRMS, yang, berdasarkan peraturan yang ditetapkan oleh penganalisis, ahli teknologi dan pembangun, memutuskan sama ada untuk meluluskan atau menolak produk perbankan tertentu kepada pelanggan.

Terdapat banyak penyelesaian siap sedia di pasaran, kedua-dua model pemarkahan dan sistem membuat keputusan sendiri. Kami menggunakan salah satu sistem ini dalam syarikat kami. Tetapi perniagaan semakin berkembang, mempelbagaikan, kedua-dua bilangan pelanggan dan bilangan produk yang ditawarkan semakin meningkat, dan bersama-sama dengan ini, idea-idea muncul tentang cara untuk menambah baik proses membuat keputusan sedia ada. Pasti orang yang bekerja dengan sistem sedia ada mempunyai banyak idea tentang cara menjadikannya lebih mudah, lebih baik, lebih mudah, tetapi kadangkala idea dari luar berguna. Hackathon Baru telah dianjurkan dengan tujuan untuk mengumpul idea yang bernas.

Tugasan

Hackathon itu diadakan pada 23 Februari. Para peserta ditawarkan tugas tempur: untuk membangunkan sistem membuat keputusan yang perlu memenuhi beberapa syarat.

Kami diberitahu bagaimana sistem sedia ada berfungsi dan apa kesukaran yang timbul semasa operasinya, serta matlamat perniagaan yang perlu dicapai oleh platform yang dibangunkan. Sistem mesti mempunyai masa ke pasaran yang pantas untuk membangunkan peraturan supaya kod kerja penganalisis masuk ke dalam pengeluaran secepat mungkin. Dan untuk aliran masuk permohonan, masa membuat keputusan harus cenderung kepada minimum. Selain itu, sistem yang dibangunkan mesti mempunyai keupayaan jualan silang untuk memberi peluang kepada pelanggan untuk membeli produk syarikat lain jika ia diluluskan oleh kami dan mempunyai potensi minat daripada pelanggan.

Adalah jelas bahawa adalah mustahil untuk menulis projek sedia untuk dikeluarkan semalaman yang pastinya akan dikeluarkan, dan agak sukar untuk merangkumi keseluruhan sistem, jadi kami diminta untuk melaksanakan sekurang-kurangnya sebahagian daripadanya. Beberapa keperluan telah ditetapkan yang mesti dipenuhi oleh prototaip. Ia adalah mungkin untuk mencuba kedua-duanya untuk menampung semua keperluan secara keseluruhannya, dan untuk bekerja secara terperinci pada bahagian individu platform yang sedang dibangunkan.

Bagi teknologi, semua peserta diberi kebebasan sepenuhnya untuk memilih. Anda boleh menggunakan sebarang konsep dan teknologi: Penstriman data, pembelajaran mesin, penyumberan acara, data besar dan lain-lain.

Penyelesaian kami

Selepas sumbang saran sedikit, kami memutuskan bahawa penyelesaian FaaS sesuai untuk menyelesaikan tugas.

Untuk penyelesaian ini, adalah perlu untuk mencari rangka kerja Tanpa Pelayan yang sesuai untuk melaksanakan peraturan sistem membuat keputusan yang sedang dibangunkan. Memandangkan Tinkoff secara aktif menggunakan Kubernetes untuk pengurusan infrastruktur, kami melihat beberapa penyelesaian sedia dibuat berdasarkannya; Saya akan memberitahu anda lebih lanjut mengenainya kemudian.

Untuk mencari penyelesaian yang paling berkesan, kami melihat produk yang dibangunkan melalui mata penggunanya. Pengguna utama sistem kami ialah penganalisis yang terlibat dalam pembangunan peraturan. Peraturan mesti digunakan ke pelayan, atau, seperti dalam kes kami, digunakan dalam awan, untuk membuat keputusan seterusnya. Dari perspektif penganalisis, aliran kerja kelihatan seperti ini:

1. Penganalisis menulis skrip, peraturan atau model ML berdasarkan data daripada gudang. Sebagai sebahagian daripada hackathon, kami memutuskan untuk menggunakan Mongodb, tetapi pilihan sistem storan data tidak penting di sini.
2. Selepas menguji peraturan yang dibangunkan pada data sejarah, penganalisis memuat naik kodnya ke panel pentadbir.
3. Untuk memastikan versi, semua kod akan pergi ke repositori Git.
4. Melalui panel pentadbir adalah mungkin untuk menggunakan kod dalam awan sebagai modul Tanpa Pelayan berfungsi berasingan.

Data awal daripada pelanggan mesti melalui perkhidmatan Pengayaan khusus yang direka untuk memperkaya permintaan awal dengan data daripada gudang. Adalah penting untuk melaksanakan perkhidmatan ini dengan cara yang ia akan berfungsi dengan satu repositori (dari mana penganalisis mengambil data semasa membangunkan peraturan) untuk mengekalkan struktur data bersatu.

Malah sebelum hackathon, kami memutuskan rangka kerja Tanpa Pelayan yang akan kami gunakan. Hari ini terdapat banyak teknologi di pasaran yang melaksanakan pendekatan ini. Penyelesaian yang paling popular dalam seni bina Kubernetes ialah Fission, Open FaaS dan Kubeless. Malah ada artikel yang baik dengan penerangan dan analisis perbandingan mereka.

Selepas menimbang semua kebaikan dan keburukan, kami memilih Pembelahan. Rangka kerja Tanpa Pelayan ini agak mudah diurus dan memenuhi keperluan tugas.

Untuk bekerja dengan Fission, anda perlu memahami dua konsep asas: fungsi dan persekitaran. Fungsi ialah sekeping kod yang ditulis dalam salah satu bahasa yang terdapat persekitaran Fission. Senarai persekitaran yang dilaksanakan dalam rangka kerja ini termasuk Python, JS, Go, JVM dan banyak lagi bahasa dan teknologi popular.

Pembelahan juga mampu melaksanakan fungsi yang dibahagikan kepada beberapa fail, dipra-bungkus ke dalam arkib. Operasi Fission dalam kelompok Kubernetes dipastikan oleh pod khusus, yang diuruskan oleh rangka kerja itu sendiri. Untuk berinteraksi dengan pod kluster, setiap fungsi mesti diberikan laluannya sendiri dan yang mana anda boleh lulus parameter GET atau badan permintaan dalam kes permintaan POST.

Akibatnya, kami merancang untuk mendapatkan penyelesaian yang membolehkan penganalisis menggunakan skrip peraturan yang dibangunkan tanpa penyertaan jurutera dan pembangun. Pendekatan yang diterangkan juga menghapuskan keperluan untuk pembangun menulis semula kod penganalisis ke dalam bahasa lain. Sebagai contoh, untuk sistem membuat keputusan semasa yang kami gunakan, kami perlu menulis peraturan dalam teknologi dan bahasa yang sangat khusus, skopnya sangat terhad, dan terdapat juga pergantungan yang kuat pada pelayan aplikasi, kerana semua draf peraturan bank digunakan dalam satu persekitaran. Akibatnya, untuk menggunakan peraturan baru adalah perlu untuk melepaskan keseluruhan sistem.

Dalam penyelesaian yang dicadangkan kami, tidak perlu mengeluarkan peraturan; kod boleh digunakan dengan mudah dengan mengklik butang. Selain itu, pengurusan infrastruktur dalam Kubernetes membolehkan anda tidak memikirkan tentang beban dan penskalaan; masalah sedemikian diselesaikan di luar kotak. Dan penggunaan gudang data tunggal menghapuskan keperluan untuk membandingkan data masa nyata dengan data sejarah, yang memudahkan kerja penganalisis.

Apa yang kita dapat

Memandangkan kami datang ke hackathon dengan penyelesaian siap pakai (dalam fantasi kami), apa yang kami perlu lakukan ialah menukar semua pemikiran kami ke dalam baris kod.

Kunci kejayaan di mana-mana hackathon adalah persediaan dan rancangan yang ditulis dengan baik. Oleh itu, perkara pertama yang kami lakukan ialah memutuskan modul yang akan terdiri daripada seni bina sistem kami dan teknologi yang akan kami gunakan.

Seni bina projek kami adalah seperti berikut:

Rajah ini menunjukkan dua titik masuk, penganalisis (pengguna utama sistem kami) dan pelanggan.

Proses kerja tersusun seperti ini. Penganalisis membangunkan fungsi peraturan dan fungsi pengayaan data untuk modelnya, menyimpan kodnya dalam repositori Git dan menggunakan modelnya ke awan melalui aplikasi pentadbir. Mari kita pertimbangkan cara fungsi yang digunakan akan dipanggil dan membuat keputusan mengenai permintaan masuk daripada pelanggan:

1. Pelanggan mengisi borang di laman web dan menghantar permintaannya kepada pengawal. Aplikasi di mana keputusan perlu dibuat datang ke input sistem dan direkodkan dalam pangkalan data dalam bentuk asalnya.
2. Seterusnya, permintaan mentah dihantar untuk pengayaan, jika perlu. Anda boleh menambah permintaan awal dengan data dari perkhidmatan luaran dan dari storan. Pertanyaan diperkaya yang terhasil juga disimpan dalam pangkalan data.
3. Fungsi penganalisis dilancarkan, yang mengambil pertanyaan yang diperkaya sebagai input dan menghasilkan penyelesaian, yang juga ditulis ke storan.

Kami memutuskan untuk menggunakan MongoDB sebagai storan dalam sistem kami kerana penyimpanan data berorientasikan dokumen dalam bentuk dokumen JSON, memandangkan perkhidmatan pengayaan, termasuk permintaan asal, mengagregatkan semua data melalui pengawal REST.

Jadi, kami mempunyai XNUMX jam untuk melaksanakan platform tersebut. Kami mengagihkan peranan dengan agak berjaya; setiap ahli pasukan mempunyai bidang tanggungjawab sendiri dalam projek kami:

1. Panel pentadbir bahagian hadapan untuk kerja penganalisis, yang melaluinya dia boleh memuat turun peraturan daripada sistem kawalan versi skrip bertulis, memilih pilihan untuk memperkaya data input dan mengedit skrip peraturan dalam talian.
2. Pentadbir bahagian belakang, termasuk REST API untuk bahagian hadapan dan penyepaduan dengan VCS.
3. Menyediakan infrastruktur dalam Google Cloud dan membangunkan perkhidmatan untuk memperkaya data sumber.
4. Modul untuk menyepadukan aplikasi pentadbir dengan rangka kerja Tanpa Pelayan untuk penggunaan peraturan seterusnya.
5. Skrip peraturan untuk menguji prestasi keseluruhan sistem dan pengagregatan analitik pada aplikasi masuk (keputusan dibuat) untuk demonstrasi akhir.

Mari mulakan dengan teratur.

Bahagian hadapan kami ditulis dalam Angular 7 menggunakan Kit UI perbankan. Versi akhir panel pentadbir kelihatan seperti ini:

Memandangkan terdapat sedikit masa, kami cuba melaksanakan hanya fungsi utama. Untuk menggunakan fungsi dalam gugusan Kubernetes, adalah perlu untuk memilih acara (perkhidmatan yang peraturannya perlu digunakan dalam awan) dan kod fungsi yang melaksanakan logik membuat keputusan. Untuk setiap penggunaan peraturan untuk perkhidmatan yang dipilih, kami menulis log acara ini. Dalam panel pentadbir anda boleh melihat log semua acara.

Semua kod fungsi disimpan dalam repositori Git jauh, yang juga perlu ditetapkan dalam panel pentadbir. Untuk versi kod, semua fungsi disimpan dalam cawangan repositori yang berbeza. Panel pentadbir juga menyediakan keupayaan untuk membuat pelarasan pada skrip bertulis, supaya sebelum menggunakan fungsi untuk pengeluaran, anda bukan sahaja boleh menyemak kod bertulis, tetapi juga membuat perubahan yang diperlukan.

Sebagai tambahan kepada fungsi peraturan, kami juga melaksanakan keupayaan untuk memperkayakan data sumber secara beransur-ansur menggunakan fungsi Pengayaan, kod yang juga merupakan skrip yang membolehkan anda pergi ke gudang data, memanggil perkhidmatan pihak ketiga dan melakukan pengiraan awal. . Untuk menunjukkan penyelesaian kami, kami mengira tanda zodiak pelanggan yang meninggalkan permintaan dan menentukan pengendali mudah alihnya menggunakan perkhidmatan REST pihak ketiga.

Bahagian belakang platform ditulis dalam Java dan dilaksanakan sebagai aplikasi Spring Boot. Kami pada mulanya merancang untuk menggunakan Postgres untuk menyimpan data pentadbir, tetapi, sebagai sebahagian daripada hackathon, kami memutuskan untuk mengehadkan diri kami kepada H2 yang mudah untuk menjimatkan masa. Pada bahagian belakang, integrasi dengan Bitbucket telah dilaksanakan untuk versi fungsi pengayaan pertanyaan dan skrip peraturan. Untuk penyepaduan dengan repositori Git jauh, kami menggunakan perpustakaan JGit, yang merupakan sejenis pembalut atas arahan CLI, membolehkan anda melaksanakan sebarang arahan git menggunakan antara muka perisian yang mudah. Jadi kami mempunyai dua repositori berasingan untuk fungsi dan peraturan pengayaan, dan semua skrip dibahagikan kepada direktori. Melalui UI adalah mungkin untuk memilih komit terbaharu skrip cawangan arbitrari repositori. Apabila membuat perubahan pada kod melalui panel pentadbir, komit kod yang diubah telah dibuat dalam repositori jauh.

Untuk melaksanakan idea kami, kami memerlukan infrastruktur yang sesuai. Kami memutuskan untuk menggunakan kluster Kubernetes kami dalam awan. Pilihan kami ialah Google Cloud Platform. Rangka kerja tanpa pelayan Fission telah dipasang pada gugusan Kubernetes, yang kami gunakan dalam Gcloud. Pada mulanya, perkhidmatan pengayaan data sumber dilaksanakan sebagai aplikasi Java berasingan yang dibalut dalam Pod di dalam kluster k8s. Tetapi selepas demonstrasi awal projek kami di tengah-tengah hackathon, kami disyorkan untuk menjadikan perkhidmatan Pengayaan lebih fleksibel untuk memberi peluang untuk memilih cara memperkaya data mentah aplikasi masuk. Dan kami tidak mempunyai pilihan selain menjadikan perkhidmatan pengayaan itu juga Tanpa Pelayan.

Untuk bekerja dengan Fission, kami menggunakan Fission CLI, yang mesti dipasang di atas Kubernetes CLI. Menggunakan fungsi ke dalam kluster k8s agak mudah; anda hanya perlu menetapkan laluan dalaman dan kemasukan ke fungsi untuk membenarkan trafik masuk jika akses di luar kluster diperlukan. Menggunakan satu fungsi biasanya mengambil masa tidak lebih daripada 10 saat.

Pembentangan akhir projek dan rumusan

Untuk menunjukkan cara sistem kami berfungsi, kami telah meletakkan borang ringkas pada pelayan jauh di mana anda boleh menyerahkan permohonan untuk salah satu produk bank. Untuk meminta, anda perlu memasukkan inisial, tarikh lahir dan nombor telefon anda.

Data dari borang pelanggan pergi ke pengawal, yang pada masa yang sama menghantar permintaan untuk semua peraturan yang ada, setelah memperkaya data sebelum ini mengikut syarat yang ditentukan, dan menyimpannya dalam storan biasa. Secara keseluruhan, kami menggunakan tiga fungsi yang membuat keputusan mengenai aplikasi masuk dan 4 perkhidmatan pengayaan data. Selepas mengemukakan permohonan, pelanggan menerima keputusan kami:

Selain penolakan atau kelulusan, pelanggan juga menerima senarai produk lain, permintaan yang kami hantar secara selari. Ini adalah cara kami menunjukkan kemungkinan jualan silang dalam platform kami.

Terdapat sejumlah 3 produk bank rekaan yang tersedia:

• Kredit.
• Mainan
• gadai janji.

Semasa demonstrasi, kami menggunakan fungsi yang disediakan dan skrip pengayaan untuk setiap perkhidmatan.

Setiap peraturan memerlukan set data inputnya sendiri. Jadi, untuk meluluskan gadai janji, kami mengira tanda zodiak pelanggan dan menghubungkannya dengan logik kalendar lunar. Untuk meluluskan mainan, kami menyemak bahawa pelanggan telah mencapai umur dewasa, dan untuk mengeluarkan pinjaman, kami menghantar permintaan kepada perkhidmatan terbuka luaran untuk menentukan pengendali selular, dan keputusan telah dibuat mengenainya.

Kami cuba menjadikan demonstrasi kami menarik dan interaktif, semua orang yang hadir boleh pergi ke borang kami dan menyemak ketersediaan perkhidmatan fiksyen kami kepada mereka. Dan pada penghujung pembentangan, kami menunjukkan analisis aplikasi yang diterima, yang menunjukkan bilangan orang yang menggunakan perkhidmatan kami, bilangan kelulusan dan penolakan.

Untuk mengumpul analitis dalam talian, kami juga menggunakan alat BI sumber terbuka Metabase dan mengacaukannya ke unit storan kami. Metabase membolehkan anda membina skrin dengan analitik pada data yang menarik minat kami; anda hanya perlu mendaftarkan sambungan ke pangkalan data, pilih jadual (dalam kes kami, pengumpulan data, kerana kami menggunakan MongoDB), dan nyatakan medan yang menarik kepada kami .

Hasilnya, kami mendapat prototaip platform membuat keputusan yang baik, dan semasa demonstrasi, setiap pendengar boleh menyemak sendiri prestasinya. Penyelesaian yang menarik, prototaip siap dan demonstrasi yang berjaya membolehkan kami menang, walaupun saingan kuat daripada pasukan lain. Saya pasti bahawa artikel yang menarik juga boleh ditulis pada projek setiap pasukan.

Sumber: www.habr.com