Şirketimiz geçtiğimiz yıldan itibaren hackathonlar düzenlemeye başladı. Bu tür ilk yarışma çok başarılıydı, bunun hakkında yazdık . İkinci hackathon Şubat 2019'da gerçekleşti ve daha az başarılı olmadı. İkincisini çok uzun zaman önce tutmanın hedefleri hakkında organizatör.
Katılımcılara, uygulanması için bir teknoloji yığını seçme konusunda tam bir özgürlüğe sahip oldukça ilginç bir görev verildi. Hızlı uygulama akışıyla çalışabilecek, ağır yüklere dayanabilecek müşteri puanlama fonksiyonlarının uygun şekilde konuşlandırılması için bir karar verme platformunun uygulanması gerekiyordu ve sistemin kendisi de kolayca ölçeklenebilirdi.
Katılımcıların projelerinin son sunumlarının gösterimi sırasında da ikna olduğumuz gibi, görev önemsiz değildir ve birçok yolla çözülebilir. Hackathon'da 6'er kişilik 5 takım vardı, tüm katılımcıların iyi projeleri vardı ama bizim platformumuz en rekabetçi olanı oldu. Bu yazıda bahsetmek istediğim çok ilginç bir projemiz var.
Çözümümüz, Kubernetes içindeki Sunucusuz mimariyi temel alan ve yeni özelliklerin üretime getirilmesi için gereken süreyi azaltan bir platformdur. Analistlerin kendileri için uygun bir ortamda kod yazmalarına ve mühendislerin ve geliştiricilerin katılımı olmadan bunu üretime yerleştirmelerine olanak tanır.
Puanlama nedir
Tinkoff.ru, birçok modern şirket gibi müşteri puanlamasına da sahiptir. Puanlama, istatistiksel veri analizi yöntemlerine dayanan bir müşteri değerlendirme sistemidir.
Örneğin, bir müşteri kendisine kredi verme veya bizde bireysel bir girişimci hesabı açma talebiyle bize başvuruyor. Ona kredi vermeyi planlıyorsak, ödeme gücünü değerlendirmemiz gerekir ve eğer hesap bireysel bir girişimci ise müşterinin hileli işlemler yapmayacağından emin olmamız gerekir.
Bu tür kararları vermenin temeli, hem uygulamanın kendisinden gelen verileri hem de depolama alanımızdaki verileri analiz eden matematiksel modellerdir. Puanlamanın yanı sıra benzer istatistiksel yöntemler, müşterilerimize yeni ürünler için bireysel öneriler oluşturma hizmetinde de kullanılabilir.
Böyle bir değerlendirmenin yöntemi çeşitli girdi verilerini kabul edebilir. Ve bir noktada girdiye, geçmiş verilere ilişkin analiz sonuçlarına göre hizmeti kullanmanın dönüşüm oranını artıracak yeni bir parametre ekleyebiliriz.
Müşteri ilişkileriyle ilgili zengin bir veriye sahibiz ve bu bilgilerin hacmi sürekli artıyor. Puanlamanın işe yaraması için, veri işleme aynı zamanda bir başvuruyu kimin onaylayacağına, kimin reddedeceğine ve kime birkaç ürün daha sunacağına, potansiyel ilgi alanlarını değerlendirerek hızlı bir şekilde karar vermenize olanak tanıyan kuralları (veya matematiksel modelleri) gerektirir.
Eldeki görev için halihazırda özel bir karar verme sistemi kullanıyoruz analistler, teknoloji uzmanları ve geliştiriciler tarafından belirlenen kurallara dayanarak müşteriye belirli bir bankacılık ürününün onaylanıp onaylanmayacağına karar verir.
Piyasada hem puanlama modelleri hem de karar verme sistemlerinin kendisi olmak üzere pek çok hazır çözüm bulunmaktadır. Biz de firmamızda bu sistemlerden birini kullanıyoruz. Ancak iş büyüyor, çeşitleniyor, hem müşteri sayısı hem de sunulan ürün sayısı artıyor ve bununla birlikte mevcut karar alma sürecinin nasıl iyileştirilebileceğine dair fikirler ortaya çıkıyor. Elbette mevcut sistemle çalışan kişilerin onu nasıl daha basit, daha iyi, daha kullanışlı hale getireceğine dair birçok fikri vardır, ancak bazen dışarıdan gelen fikirler de faydalıdır. Yeni Hackathon, sağlam fikirlerin toplanması amacıyla düzenlendi.
Görev
Hackathon 23 Şubat'ta düzenlendi. Katılımcılara bir savaş görevi teklif edildi: bir dizi koşulu karşılaması gereken bir karar verme sistemi geliştirmek.
Mevcut sistemin nasıl çalıştığı, işletimi sırasında ne gibi zorlukların ortaya çıktığı ve geliştirilen platformun hangi iş hedeflerini takip etmesi gerektiği bize söylendi. Analistlerin çalışma kodlarının mümkün olan en kısa sürede üretime geçebilmesi için sistemin, kuralları geliştirmek için hızlı bir pazara sürüm süresine sahip olması gerekir. Gelen başvuru akışı için de karar verme süresinin minimuma inmesi gerekiyor. Ayrıca, geliştirilmekte olan sistemin, tarafımızdan onaylanması ve müşterinin potansiyel ilgisini çekmesi durumunda müşteriye diğer şirket ürünlerini satın alma fırsatı vermek için çapraz satış yeteneklerine sahip olması gerekir.
Yayına hazır bir projeyi bir gecede yazmanın kesin olarak üretime geçmesinin imkansız olduğu ve sistemin tamamını kapsamanın oldukça zor olduğu açıktı, bu yüzden en azından bir kısmını hayata geçirmemiz istendi. Prototipin karşılaması gereken bir takım gereksinimler belirlendi. Hem tüm gereksinimleri bir bütün olarak karşılamaya çalışmak, hem de geliştirilmekte olan platformun ayrı bölümleri üzerinde ayrıntılı olarak çalışmak mümkün oldu.
Teknolojiye gelince, tüm katılımcılara tam bir seçim özgürlüğü verildi. Herhangi bir kavram ve teknolojiyi kullanmak mümkündü: Veri akışı, makine öğrenimi, olay kaynağı bulma, büyük veri ve diğerleri.
Bizim çözümümüz
Biraz beyin fırtınası yaptıktan sonra görevi tamamlamak için FaaS çözümünün ideal olacağına karar verdik.
Bu çözüm için geliştirilmekte olan karar verme sisteminin kurallarını uygulamaya uygun Sunucusuz bir çerçeve bulmak gerekiyordu. Tinkoff, altyapı yönetimi için Kubernetes'i aktif olarak kullandığından, buna dayalı birkaç hazır çözüme baktık; size daha sonra detaylı olarak anlatacağım.
En etkili çözümü bulmak için geliştirilmekte olan ürüne kullanıcı gözüyle baktık. Sistemimizin ana kullanıcıları kural geliştirmede görev alan analistlerdir. Daha sonraki karar verme süreçleri için kuralların sunucuya veya bizim durumumuzda olduğu gibi buluta dağıtılması gerekir. Bir analistin bakış açısından iş akışı şöyle görünür:
- Analist, depodaki verilere dayalı olarak bir komut dosyası, kural veya makine öğrenimi modeli yazar. Hackathon kapsamında Mongodb kullanmaya karar verdik ancak burada veri depolama sistemi seçimi önemli değil.
- Analist, geliştirilen kuralları geçmiş veriler üzerinde test ettikten sonra kodunu yönetici paneline yükler.
- Sürüm oluşturmayı sağlamak için tüm kodlar Git depolarına gidecektir.
- Yönetici paneli aracılığıyla kodu bulutta ayrı bir işlevsel Sunucusuz modül olarak dağıtmak mümkün olacaktır.
Müşterilerden gelen ilk veriler, ilk isteği depodan gelen verilerle zenginleştirmek için tasarlanmış özel bir Zenginleştirme hizmetinden geçmelidir. Bu hizmetin, birleşik bir veri yapısını korumak için tek bir depoyla (analistin kuralları geliştirirken verileri aldığı) çalışacak şekilde uygulanması önemliydi.
Hackathon'dan önce bile kullanacağımız Sunucusuz çerçeveye karar verdik. Bugün piyasada bu yaklaşımı uygulayan oldukça fazla teknoloji var. Kubernetes mimarisindeki en popüler çözümler Fission, Open FaaS ve Kubeless'tir. Hatta var .
Tüm artıları ve eksileri tarttıktan sonra seçtik . Bu Sunucusuz çerçevenin yönetimi oldukça kolaydır ve görevin gereksinimlerini karşılar.
Fision ile çalışmak için iki temel kavramı anlamanız gerekir: işlev ve ortam. Fonksiyon, Fisyon ortamının bulunduğu dillerden birinde yazılmış bir kod parçasıdır. Python, JS, Go, JVM ve diğer birçok popüler dil ve teknolojiyi içerir.
Fision aynı zamanda birden fazla dosyaya bölünmüş ve bir arşiv halinde önceden paketlenmiş işlevleri de gerçekleştirebilir. Fision'ın Kubernetes kümesindeki çalışması, çerçevenin kendisi tarafından yönetilen özel bölmeler tarafından sağlanır. Küme bölmeleriyle etkileşim kurmak için her işleve kendi rotası atanmalı ve POST isteği durumunda GET parametrelerini veya istek gövdesini iletebilirsiniz.
Sonuç olarak, analistlerin geliştirilen kural komut dosyalarını mühendislerin ve geliştiricilerin katılımı olmadan dağıtmasına olanak tanıyacak bir çözüm elde etmeyi planladık. Açıklanan yaklaşım aynı zamanda geliştiricilerin analist kodunu başka bir dile yeniden yazma ihtiyacını da ortadan kaldırır. Örneğin, kullandığımız mevcut karar verme sistemi için, kapsamı son derece sınırlı olan dar profilli teknolojiler ve dillerde kurallar yazmak zorunda kalıyoruz ve ayrıca tüm taslak bankalardan dolayı uygulama sunucusuna güçlü bir bağımlılık var. kurallar tek bir ortamda dağıtılır. Sonuç olarak, yeni kuralların uygulamaya konulması için tüm sistemin serbest bırakılması gerekmektedir.
Önerilen çözümümüzde kuralların serbest bırakılmasına gerek yoktur; kod, bir düğmeye tıklanarak kolayca dağıtılabilir. Ayrıca Kubernetes'teki altyapı yönetimi, yükleme ve ölçeklendirmeyi düşünmemenizi sağlar; bu tür sorunlar anında çözülür. Tek bir veri ambarının kullanılması, gerçek zamanlı verileri geçmiş verilerle karşılaştırma ihtiyacını ortadan kaldırır ve bu da analistin işini kolaylaştırır.
Ne elde ettik
Hackathona hazır bir çözümle (fantezilerimizde) geldiğimiz için tek yapmamız gereken tüm düşüncelerimizi kod satırlarına dönüştürmekti.
Herhangi bir hackathonda başarının anahtarı hazırlık ve iyi yazılmış bir plandır. Bu nedenle ilk yaptığımız sistem mimarimizin hangi modüllerden oluşacağına ve hangi teknolojileri kullanacağımıza karar vermek oldu.
Projemizin mimarisi şu şekildeydi:
Bu şemada analist (sistemimizin ana kullanıcısı) ve müşteri olmak üzere iki giriş noktası gösterilmektedir.
İş süreci bu şekilde yapılandırılmıştır. Analist, modeli için bir kural işlevi ve bir veri zenginleştirme işlevi geliştirir, kodunu bir Git deposunda saklar ve modelini yönetici uygulaması aracılığıyla buluta dağıtır. Dağıtılan işlevin nasıl çağrılacağını düşünelim ve istemcilerden gelen isteklere göre karar verelim:
- Müşteri web sitesinde bir form doldurur ve talebini kontrolöre gönderir. Karar verilmesi gereken bir başvuru sistem girişine gelir ve orijinal haliyle veri tabanına kaydedilir.
- Daha sonra gerekirse zenginleştirme için ham istek gönderilir. İlk isteği hem harici hizmetlerden hem de depolama alanından gelen verilerle tamamlayabilirsiniz. Ortaya çıkan zenginleştirilmiş sorgu da veritabanında saklanır.
- Zenginleştirilmiş bir sorguyu girdi olarak alan ve yine depolamaya yazılan bir çözüm üreten analist işlevi başlatılır.
Orijinal istek de dahil olmak üzere zenginleştirme hizmetleri tüm verileri REST denetleyicileri aracılığıyla topladığından, verilerin JSON belgeleri biçiminde belge odaklı depolanması nedeniyle MongoDB'yi sistemimizde depolama olarak kullanmaya karar verdik.
Yani platformu hayata geçirmek için 24 saatimiz vardı. Rolleri oldukça başarılı bir şekilde dağıttık; projemizde her ekip üyesinin kendi sorumluluk alanı vardı:
- Analistin çalışması için, yazılı komut dosyalarının sürüm kontrol sisteminden kuralları indirebildiği, giriş verilerini zenginleştirme seçeneklerini seçebildiği ve kural komut dosyalarını çevrimiçi olarak düzenleyebildiği ön uç yönetici panelleri.
- Ön uç için REST API ve VCS ile entegrasyon dahil olmak üzere arka uç yöneticisi.
- Google Cloud'da altyapı kurulumu ve kaynak verilerin zenginleştirilmesine yönelik hizmet geliştirilmesi.
- Kuralların daha sonra dağıtılması için yönetici uygulamasını Sunucusuz çerçeveyle entegre etmeye yönelik bir modül.
- Tüm sistemin performansını test etmek için kural komut dosyaları ve son gösterim için gelen uygulamalardaki (alınan kararlar) analitiklerin toplanması.
En sırayla başlayalım.
Ön ucumuz bankacılık UI Kiti kullanılarak Angular 7'de yazılmıştır. Yönetici panelinin son versiyonu şuna benziyordu:
Çok az zamanımız olduğundan yalnızca temel işlevleri uygulamaya çalıştık. Kubernetes kümesinde bir işlevi dağıtmak için bir etkinliğin (bulutta bir kuralın dağıtılması gereken bir hizmet) ve karar verme mantığını uygulayan işlevin kodunun seçilmesi gerekiyordu. Seçilen hizmete yönelik her bir kural dağıtımı için bu olayın bir günlüğünü yazdık. Yönetici panelinde tüm olayların günlüklerini görebilirsiniz.
Tüm işlev kodları, yönetici panelinde de ayarlanması gereken uzak bir Git deposunda saklanıyordu. Kodu versiyonlandırmak için tüm işlevler havuzun farklı dallarında saklandı. Yönetici paneli ayrıca yazılı komut dosyalarında ayarlamalar yapma olanağı da sağlar; böylece bir işlevi üretime dağıtmadan önce yalnızca yazılı kodu kontrol etmekle kalmaz, aynı zamanda gerekli değişiklikleri de yapabilirsiniz.
Kural işlevlerine ek olarak, kodu aynı zamanda veri ambarına gitmenin, üçüncü taraf hizmetlerini çağırmanın ve ön hesaplamalar yapmanın mümkün olduğu komut dosyaları olan Zenginleştirme işlevlerini kullanarak kaynak verileri kademeli olarak zenginleştirme yeteneğini de uyguladık. . Çözümümüzü göstermek için, isteği bırakan müşterinin burcunu hesapladık ve üçüncü taraf bir REST hizmeti kullanarak mobil operatörünü belirledik.
Platformun arka ucu Java ile yazılmış ve Spring Boot uygulaması olarak uygulanmıştır. Başlangıçta Postgres'i yönetici verilerini depolamak için kullanmayı planladık, ancak hackathon kapsamında zamandan tasarruf etmek için kendimizi basit bir H2 ile sınırlamaya karar verdik. Arka uçta, sorgu zenginleştirme işlevlerinin ve kural komut dosyalarının sürümü için Bitbucket ile entegrasyon uygulandı. Uzak Git depolarıyla entegrasyon için şunu kullandık: CLI komutları üzerinde bir tür sarmalayıcı olan ve uygun bir yazılım arayüzü kullanarak herhangi bir git talimatını yürütmenize olanak tanıyan . Yani zenginleştirme işlevleri ve kuralları için iki ayrı havuzumuz vardı ve tüm komut dosyaları dizinlere bölünmüştü. Kullanıcı arayüzü aracılığıyla, havuzun isteğe bağlı bir dalının bir komut dosyasının en son taahhüdünü seçmek mümkündü. Yönetici paneli aracılığıyla kodda değişiklik yaparken, uzak depolarda değiştirilen kodun taahhütleri oluşturuldu.
Fikrimizi hayata geçirmek için uygun altyapıya ihtiyacımız vardı. Kubernetes kümemizi bulutta konuşlandırmaya karar verdik. Bizim tercihimiz Google Cloud Platform oldu. Fission sunucusuz çerçevesi, Gcloud'da konuşlandırdığımız bir Kubernetes kümesine kuruldu. Başlangıçta kaynak veri zenginleştirme hizmeti, k8s kümesinin içindeki bir Pod'a sarılmış ayrı bir Java uygulaması olarak uygulandı. Ancak hackathonun ortasında projemizin ön gösteriminin ardından, bize gelen uygulamaların ham verilerinin nasıl zenginleştirileceğini seçme fırsatı sağlamak için Zenginleştirme hizmetini daha esnek hale getirmemiz önerildi. Zenginleştirme hizmetini de Sunucusuz yapmaktan başka seçeneğimiz yoktu.
Fission ile çalışmak için Kubernetes CLI'nin üzerine kurulması gereken Fission CLI'yi kullandık. İşlevleri bir k8s kümesine dağıtmak oldukça basittir; küme dışından erişim gerekiyorsa, gelen trafiğe izin vermek için yalnızca işleve dahili bir rota ve giriş atamanız gerekir. Bir işlevi dağıtmak genellikle 10 saniyeden fazla sürmez.
Projenin son sunumu ve özeti
Sistemimizin nasıl çalıştığını göstermek amacıyla uzak bir sunucuya, bankanın ürünlerinden biri için başvuruda bulunabileceğiniz basit bir form yerleştirdik. Talep etmek için adınızın baş harflerini, doğum tarihinizi ve telefon numaranızı girmeniz gerekiyordu.
İstemci formundaki veriler, daha önce verileri belirtilen koşullara göre zenginleştiren ve bunları ortak bir depolama birimine kaydeden, mevcut tüm kurallar için eşzamanlı olarak istek gönderen denetleyiciye gitti. Toplamda, gelen uygulamalara karar veren üç fonksiyonu ve 4 veri zenginleştirme hizmetini devreye aldık. Başvuruyu gönderdikten sonra müşteri kararımızı aldı:
Müşteri, ret veya onayın yanı sıra paralel olarak talep gönderdiğimiz diğer ürünlerin bir listesini de aldı. Platformumuzda çapraz satış olasılığını bu şekilde gösterdik.
Toplamda 3 hayali banka ürünü mevcuttu:
- Kredi.
- Oyuncak
- İpotek.
Gösterim sırasında her servis için hazırlanmış fonksiyonları ve zenginleştirme scriptlerini devreye aldık.
Her kural kendi giriş verileri kümesini gerektiriyordu. Bu nedenle, bir ipoteği onaylamak için müşterinin burcunu hesapladık ve bunu ay takviminin mantığıyla ilişkilendirdik. Bir oyuncağı onaylamak için müşterinin reşit olma yaşına ulaştığını kontrol ettik ve kredi vermek için cep telefonu operatörünü belirlemek üzere harici bir açık servise talep gönderdik ve buna karar verdik.
Gösterimizi ilgi çekici ve etkileşimli hale getirmeye çalıştık; orada bulunan herkes formumuza gidebilir ve kurgusal hizmetlerimizin kendilerine uygun olup olmadığını kontrol edebilir. Sunumun en sonunda, hizmetimizi kaç kişinin kullandığını, onay ve ret sayısını gösteren, alınan başvuruların analitiğini gösterdik.
Analitikleri çevrimiçi toplamak için ek olarak açık kaynaklı bir BI aracını devreye aldık ve onu depolama ünitemize vidaladık. Metatabanı, bizi ilgilendiren veriler üzerinde analitik içeren ekranlar oluşturmanıza olanak tanır; yalnızca veritabanına bir bağlantı kaydetmeniz, tabloları seçmeniz (bizim durumumuzda, MongoDB'yi kullandığımız için veri koleksiyonları) ve ilgimizi çeken alanları belirtmeniz yeterlidir. .
Sonuç olarak, bir karar verme platformunun iyi bir prototipini elde ettik ve gösteri sırasında her dinleyici, performansını kişisel olarak kontrol edebildi. İlginç bir çözüm, bitmiş bir prototip ve başarılı bir gösteri, diğer takımların güçlü rekabetine rağmen kazanmamızı sağladı. Eminim ki her ekibin projesi üzerine ilginç bir yazı da yazılabilir.
Kaynak: habr.com