Sejak tahun lalu, hackathons mulai diorganisir di perusahaan kami. Kompetisi pertama seperti itu sangat sukses, kami menulisnya di
artikel . Hackathon kedua diadakan pada Februari 2019 dan tidak kalah berhasil. Panitia baru-baru ini
menulis tentang tujuan yang terakhir.
Para peserta diberi tugas yang agak menarik dengan kebebasan penuh dalam memilih tumpukan teknologi untuk implementasinya. Itu perlu untuk mengimplementasikan platform keputusan untuk penyebaran fungsi penilaian pelanggan yang nyaman yang dapat bekerja pada aliran aplikasi yang cepat, tahan terhadap beban berat, dan sistem itu sendiri mudah diskalakan.
Tugas ini tidak sepele dan dapat diselesaikan dengan banyak cara, seperti yang kita lihat dalam demonstrasi presentasi akhir dari proyek peserta. Ada 6 tim yang terdiri dari 5 orang di hackathon, semua peserta memiliki proyek yang bagus, tetapi platform kami ternyata yang paling kompetitif. Kami mendapat proyek yang sangat menarik, yang ingin saya bicarakan di artikel ini.
Solusi kami adalah platform berbasis arsitektur Serverless di dalam Kubernetes, yang mengurangi waktu yang dibutuhkan untuk menghadirkan fitur-fitur baru ke dalam produksi. Hal ini memungkinkan analis untuk menulis kode di lingkungan yang nyaman bagi mereka dan menyebarkannya di prod tanpa partisipasi insinyur dan pengembang.
Apa yang dimaksud dengan skor?
Tinkoff.ru, seperti banyak perusahaan modern, memiliki penilaian pelanggan. Penilaian adalah sistem penilaian pelanggan berdasarkan metode statistik analisis data.
Sebagai contoh, seorang klien meminta kami untuk memberinya pinjaman, atau membuka akun IP bersama kami. Jika kami berencana untuk memberinya pinjaman, maka Anda perlu mengevaluasi solvabilitasnya, dan jika akun tersebut adalah ekuitas pribadi, maka Anda perlu memastikan bahwa klien tidak akan melakukan transaksi penipuan.
Keputusan ini didasarkan pada model matematika yang menganalisis data aplikasi itu sendiri dan data penyimpanan kami. Selain penilaian, metode statistik yang serupa juga dapat digunakan dalam pekerjaan layanan untuk menghasilkan rekomendasi individu pada produk baru untuk pelanggan kami.
Metode penilaian semacam itu dapat menerima berbagai input data. Dan pada titik tertentu, kita dapat menambahkan parameter baru ke input, yang, menurut analisis data historis, akan meningkatkan konversi penggunaan layanan.
Kami menyimpan banyak data tentang hubungan pelanggan, dan volume informasi ini terus bertambah. Agar skor berfungsi, pemrosesan data juga memerlukan aturan (atau model matematika) yang memungkinkan Anda untuk dengan cepat memutuskan siapa yang menyetujui aplikasi, siapa yang menolak, dan siapa lagi yang menawarkan beberapa produk untuk menilai minat potensial.
Untuk tugas ini, kami telah menggunakan
sistem pengambilan keputusan
BRMS IBM WebSphere ILOG khusus
IBM , yang, berdasarkan aturan yang ditetapkan oleh analis, teknologi, dan pengembang, memutuskan apakah akan menyetujui produk perbankan tertentu untuk klien atau menolak.
Ada banyak solusi siap pakai di pasar, baik model penilaian dan sistem pengambilan keputusan sendiri. Kami menggunakan salah satu dari sistem ini di perusahaan kami. Tetapi bisnis ini tumbuh, beragam, baik jumlah pelanggan dan jumlah produk yang ditawarkan meningkat, dan seiring dengan ini, muncul ide bagaimana meningkatkan proses pengambilan keputusan yang ada. Tentunya orang yang bekerja dengan sistem yang ada memiliki banyak ide tentang cara membuatnya lebih sederhana, lebih baik, lebih nyaman, tetapi kadang-kadang ide dari luar berguna. Untuk mengumpulkan ide-ide yang bagus, New Hackathon diorganisir.
Tugas
Hackathon diadakan pada 23 Februari. Para peserta ditawari misi tempur: untuk mengembangkan sistem pengambilan keputusan, yang memenuhi sejumlah persyaratan.
Kami diberitahu bagaimana fungsi sistem yang ada dan kesulitan apa yang muncul selama operasinya, serta tujuan bisnis apa yang harus dicapai oleh platform yang sedang dikembangkan. Sistem harus memiliki waktu yang cepat ke pasar aturan yang sedang dikembangkan sehingga kode kerja analis masuk ke dalam produksi secepat mungkin. Dan untuk arus masuk aplikasi, waktu pengambilan keputusan harus cenderung minimum. Selain itu, sistem yang dikembangkan harus dapat melakukan cross-selling untuk memberikan klien kesempatan untuk membeli produk perusahaan lain jika disetujui oleh kami dan potensi minat dari pihak klien.
Jelas bahwa dalam satu malam tidak mungkin untuk menulis proyek siap-lepas yang pasti akan masuk ke produksi, dan seluruh sistem cukup sulit untuk dicakup, jadi kami diminta untuk mengimplementasikan setidaknya sebagian darinya. Sejumlah persyaratan ditetapkan bahwa prototipe harus dipenuhi. Seseorang dapat mencoba untuk mencakup semua persyaratan secara keseluruhan, dan untuk bekerja secara rinci setiap bagian dari platform yang dikembangkan.
Adapun teknologi, maka semua peserta diberi kebebasan penuh untuk memilih. Dimungkinkan untuk menggunakan konsep dan teknologi apa pun: Streaming data, pembelajaran mesin, sumber acara, data besar, dan lainnya.
Keputusan kami
Setelah sesi brainstorming kecil, kami memutuskan bahwa solusi FaaS akan ideal untuk tugas tersebut.
Untuk solusi ini, perlu untuk menemukan kerangka kerja Serverless yang sesuai untuk mengimplementasikan aturan-aturan dari sistem pengambilan keputusan yang dikembangkan. Karena Kubernetes secara aktif digunakan dalam manajemen infrastruktur di Tinkoff, kami memeriksa beberapa solusi yang sudah jadi berdasarkan itu, saya akan berbicara lebih banyak tentang itu nanti.
Untuk menemukan solusi yang paling efektif, kami melihat produk yang dikembangkan melalui mata penggunanya. Pengguna utama sistem kami adalah analis yang terlibat dalam pengembangan aturan. Aturan harus disebarkan ke server, atau, seperti dalam kasus kami, disebarkan ke cloud untuk pengambilan keputusan selanjutnya. Dari perspektif analis, alur kerjanya adalah sebagai berikut:
- Analis menulis skrip, aturan, atau model ML berdasarkan data dari repositori. Sebagai bagian dari hackathon, kami memutuskan untuk menggunakan Mongodb, tetapi pilihan sistem penyimpanan tidak penting di sini.
- Setelah menguji aturan yang dikembangkan pada data historis, analis menuangkan kodenya ke panel admin.
- Untuk memastikan versi, semua kode akan pergi ke repositori Git.
- Melalui panel admin, dimungkinkan untuk menyebarkan kode di cloud sebagai modul Serverless fungsional yang terpisah.
Sumber data dari pelanggan harus melalui layanan Pengayaan khusus, yang dirancang untuk memperkaya permintaan awal dengan data dari repositori. Penting untuk mengimplementasikan layanan ini sedemikian rupa sehingga dapat bekerja dengan repositori tunggal (dari mana analis mengambil data saat mengembangkan aturan) untuk mempertahankan struktur data yang terpadu.
Bahkan sebelum hackathon, kami memutuskan kerangka Serverless yang akan kami gunakan. Ada beberapa teknologi di pasar yang menerapkan pendekatan ini. Solusi arsitektur Kubernetes yang paling populer adalah Fission, Open FaaS, dan Kubeless. Bahkan ada
artikel bagus dengan deskripsi dan analisis komparatifnya .
Setelah mempertimbangkan semua pro dan kontra, kami memilih untuk
Fission . Kerangka kerja Serverless ini cukup mudah untuk dikelola dan memenuhi persyaratan tugas.
Untuk bekerja dengan Fission, Anda perlu memahami dua konsep dasar: fungsi dan lingkungan. Fungsi (fungsi) adalah bagian dari kode yang ditulis dalam salah satu bahasa yang ada lingkungan-Fisi (lingkungan).
Daftar lingkungan yang diimplementasikan dalam kerangka kerja ini termasuk Python, JS, Go, JVM dan banyak bahasa dan teknologi populer lainnya.
Fission juga dapat melakukan fungsi, dibagi menjadi beberapa file, yang telah dikemas sebelumnya dalam arsip. Operasi fisi di kluster Kubernetes disediakan oleh pod khusus, yang dikelola oleh framework itu sendiri. Untuk berinteraksi dengan pod kluster, setiap fungsi harus diberi rute, dan Anda dapat melewati parameter GET atau badan permintaan jika ada permintaan POST.
Sebagai hasilnya, kami berencana untuk mendapatkan solusi yang memungkinkan analis untuk menyebarkan skrip aturan yang dikembangkan tanpa partisipasi insinyur dan pengembang. Pendekatan yang dijelaskan juga menghilangkan kebutuhan pengembang untuk menulis ulang kode analis dalam bahasa lain. Misalnya, untuk sistem pengambilan keputusan saat ini yang kami gunakan, kami harus menulis aturan dalam teknologi dan bahasa profil-sempit, ruang lingkup yang sangat terbatas, dan ada juga ketergantungan yang kuat pada server aplikasi, karena semua rancangan aturan bank dikerahkan dalam satu lingkungan. Akibatnya, untuk penerapan aturan baru, perlu untuk merilis seluruh sistem.
Dalam solusi yang kami usulkan, tidak perlu melepaskan aturan, kode mudah digunakan di klik tombol. Juga, manajemen infrastruktur di Kubernetes memungkinkan Anda untuk tidak memikirkan beban dan penskalaan, masalah seperti itu dipecahkan. Dan penggunaan gudang data tunggal menghilangkan kebutuhan untuk membandingkan data real-time dengan data historis, yang menyederhanakan pekerjaan analis.
Apa yang kita dapat
Karena kami tiba di hackathon dengan solusi yang sudah jadi (dalam fantasi kami), kita hanya perlu mengubah semua pikiran kita menjadi baris kode.
Kunci kesuksesan di hackathon apa pun adalah persiapan dan rencana yang dibuat dengan baik. Karena itu, pertama-tama, kami memutuskan modul mana yang akan terdiri dari arsitektur sistem kami dan teknologi mana yang akan kami gunakan.
Arsitektur proyek kami adalah sebagai berikut:
Diagram ini menunjukkan dua titik masuk, seorang analis (pengguna utama sistem kami) dan seorang klien.
Proses kerjanya terstruktur seperti ini. Analis mengembangkan fungsi aturan dan fungsi pengayaan data untuk modelnya, menyimpan kode-nya di repositori Git, dan menyebarkan modelnya di cloud melalui aplikasi administrator. Pertimbangkan bagaimana fungsi yang diperluas akan dipanggil dan membuat keputusan tentang permintaan yang masuk dari klien:
- Klien yang mengisi formulir di situs mengirimkan permintaannya ke controller. Aplikasi tiba di input sistem, yang menurutnya keputusan harus dibuat, dan dicatat dalam database dalam bentuk aslinya.
- Selanjutnya, permintaan mentah dikirim untuk pengayaan, jika perlu. Anda dapat melengkapi permintaan awal dengan data baik dari layanan eksternal maupun dari repositori. Permintaan kaya yang diterima juga disimpan dalam database.
- Fungsi analis diluncurkan, yang menerima permintaan yang diperkaya pada input dan memberikan keputusan, yang juga dicatat dalam repositori.
Sebagai penyimpanan dalam sistem kami, kami memutuskan untuk menggunakan MongoDB mengingat penyimpanan data yang terdokumentasi dalam bentuk dokumen JSON, karena layanan pengayaan, termasuk permintaan awal, mengumpulkan semua data melalui pengontrol REST.
Jadi, kami punya satu hari untuk mengimplementasikan platform. Kami cukup berhasil mendistribusikan peran, setiap anggota tim memiliki bidang tanggung jawabnya sendiri dalam proyek kami:
- Panel admin frontend untuk pekerjaan analis yang melaluinya dia dapat mengunduh aturan dari sistem kontrol pembuatan skrip tertulis, memilih opsi untuk memperkaya data input dan mengedit skrip aturan online.
- Panel admin backend yang menyertakan REST API untuk bagian depan dan integrasi VCS.
- Menyiapkan infrastruktur di Google Cloud dan mengembangkan layanan pengayaan data sumber.
- Modul untuk mengintegrasikan aplikasi admin dengan kerangka kerja Serverless untuk penerapan aturan selanjutnya.
- Skrip aturan untuk menguji kesehatan seluruh sistem dan agregasi analitik untuk aplikasi yang masuk (keputusan yang dibuat) untuk demonstrasi terakhir.
Mari kita mulai.
Frontend kami ditulis dalam Angular 7 menggunakan Kit UI perbankan. Versi terakhir dari panel admin adalah sebagai berikut:
Karena tidak ada banyak waktu, kami mencoba menerapkan hanya fungsi utama. Untuk menyebarkan fungsi di kluster Kubernetes, Anda harus memilih acara (layanan yang Anda perlukan untuk menyebarkan aturan di cloud) dan kode kode fungsi yang mengimplementasikan logika keputusan. Untuk setiap penerapan aturan untuk layanan yang dipilih, kami menulis log acara ini. Di panel admin, Anda bisa melihat log semua peristiwa.
Semua kode fungsi disimpan dalam repositori Git jarak jauh, yang juga harus diatur di panel admin. Untuk versi kode, semua fungsi disimpan di cabang yang berbeda dari repositori. Panel admin juga menyediakan kemampuan untuk membuat penyesuaian pada skrip tertulis sehingga sebelum menggunakan fungsi untuk produksi, Anda tidak hanya dapat memeriksa kode tertulis, tetapi juga membuat perubahan yang diperlukan.
Selain fungsi aturan, kami juga menyadari kemungkinan pengayaan tahap demi tahap dari data sumber menggunakan fungsi Pengayaan, kode yang juga terdiri dari skrip di mana Anda bisa pergi ke gudang data, memanggil layanan pihak ketiga dan melakukan perhitungan pendahuluan. Untuk menunjukkan solusi kami, kami menghitung tanda zodiak klien yang meninggalkan aplikasi dan menentukan operator selulernya menggunakan layanan REST pihak ketiga.
Platform backend ditulis dalam Java dan diimplementasikan sebagai aplikasi Spring Boot. Untuk menyimpan data admin, kami awalnya berencana untuk menggunakan Postgres, tetapi, sebagai bagian dari hackathon, kami memutuskan untuk membatasi diri kami pada H2 sederhana, untuk menghemat waktu. Di bagian belakang, integrasi dengan Bitbucket diimplementasikan ke versi fungsi pengayaan kueri dan skrip aturan. Untuk berintegrasi dengan repositori Git jarak jauh,
perpustakaan JGit digunakan , yang merupakan semacam pembungkus atas perintah CLI yang memungkinkan Anda untuk menjalankan instruksi git menggunakan antarmuka program yang nyaman. Jadi kami memiliki dua repositori terpisah, untuk fungsi dan aturan pengayaan, dan semua skrip diatur dalam direktori. Melalui UI, dimungkinkan untuk memilih skrip komit terakhir dari cabang repositori sewenang-wenang. Saat membuat perubahan pada kode melalui panel admin, komit dari kode yang dimodifikasi dibuat di repositori jarak jauh.
Untuk mengimplementasikan ide kami, kami membutuhkan infrastruktur yang sesuai. Kami memutuskan untuk menggunakan kluster Kubernet kami di cloud. Pilihan kami adalah Google Cloud Platform. Kerangka kerja serverless Fless diinstal pada cluster Kubernetes, yang kami gunakan untuk Gcloud. Awalnya, layanan pengayaan data sumber diimplementasikan oleh aplikasi Java terpisah yang dibungkus dengan Pod di dalam kluster k8s. Tetapi setelah demonstrasi awal proyek kami di tengah hackathon, kami direkomendasikan untuk membuat layanan Pengayaan lebih fleksibel untuk memberikan kesempatan untuk memilih bagaimana memperkaya data mentah dari aplikasi yang masuk. Dan kami tidak punya pilihan selain membuat layanan pengayaan juga Serverless.
Untuk bekerja dengan Fission, kami menggunakan Fission CLI, yang harus diinstal di atas Kubernetes CLI. Menyebarkan fungsi dalam cluster k8s cukup sederhana, Anda hanya perlu menetapkan rute internal dan masuknya fungsi untuk memungkinkan lalu lintas masuk jika diperlukan akses di luar cluster. Menyebarkan satu fungsi biasanya tidak lebih dari 10 detik.
Pertunjukan terakhir dari proyek dan disimpulkan
Untuk menunjukkan operasi sistem kami, kami menempatkan pada server jarak jauh formulir sederhana yang dapat Anda gunakan untuk salah satu produk bank. Untuk permintaan, Anda harus memasukkan inisial, tanggal lahir dan nomor telepon Anda.
Data dari formulir klien pergi ke controller, yang secara bersamaan mengirim aplikasi untuk semua aturan yang tersedia, pra-pengayaan data sesuai dengan kondisi yang diberikan, dan menyimpannya di penyimpanan umum. Secara total, kami telah menggunakan tiga fungsi pengambilan keputusan untuk aplikasi yang masuk dan 4 layanan pengayaan data. Setelah mengirim aplikasi, klien menerima solusi kami:
Selain penolakan atau persetujuan, klien juga menerima daftar produk lain yang kami kirim permintaan secara paralel. Jadi kami menunjukkan kemungkinan penjualan silang di platform kami.
Secara total, 3 produk bank yang ditemukan tersedia:
Selama setiap demonstrasi, kami menggunakan fungsi yang disiapkan dan skrip pengayaan untuk setiap layanan.
Setiap aturan membutuhkan set input data sendiri. Jadi, untuk menyetujui hipotek, kami menghitung tanda zodiak pelanggan dan mengaitkannya dengan logika kalender lunar. Untuk menyetujui mainan itu, kami memeriksa bahwa klien sudah cukup umur, dan untuk mengeluarkan pinjaman, kami mengirim permintaan ke layanan terbuka eksternal untuk menentukan operator seluler, dan kami membuat keputusan untuk itu.
Kami mencoba menjadikan demonstrasi kami menarik dan interaktif, semua orang yang hadir dapat masuk ke formulir kami dan memeriksa ketersediaan layanan imajiner kami kepadanya. Dan di akhir presentasi, kami mendemonstrasikan analisis aplikasi yang diterima, di mana ditunjukkan berapa banyak orang yang menggunakan layanan kami, jumlah persetujuan, penolakan.
Untuk mengumpulkan analitik online, kami juga menggunakan alat BI open-source
Metabase dan mengacaukannya ke repositori kami. Metabase memungkinkan Anda untuk membangun layar dengan analitik berdasarkan data yang kami minati, Anda hanya perlu mendaftarkan koneksi ke database, pilih tabel (dalam kasus kami, pengumpulan data, karena kami menggunakan MongoDB), dan tentukan bidang yang menarik bagi kami.
Sebagai hasilnya, kami mendapatkan prototipe yang baik dari platform pengambilan keputusan, dan pada demonstrasi tersebut setiap pendengar dapat secara pribadi menguji kinerjanya. Solusi yang menarik, prototipe yang sudah jadi, dan demonstrasi yang berhasil memungkinkan kami untuk menang, meskipun ada persaingan yang kuat dalam menghadapi tim lain. Saya yakin bahwa pada proyek masing-masing tim, Anda juga dapat menulis artikel yang menarik.