Från och med förra året började vårt företag organisera hackathons. Den första sådana tävlingen var mycket framgångsrik, vi skrev om den i . Det andra hackathonet ägde rum i februari 2019 och var inte mindre framgångsrikt. Om målen med att hålla den sistnämnda för inte så länge sedan arrangör.
Deltagarna fick en ganska intressant uppgift med fullständig frihet att välja en teknikstack för dess implementering. Det var nödvändigt att implementera en beslutsfattande plattform för bekväm implementering av kundpoängfunktioner som kunde fungera med ett snabbt flöde av applikationer, stå emot tunga belastningar och själva systemet var lätt skalbart.
Uppgiften är icke-trivial och kan lösas på många sätt, vilket vi blev övertygade om under demonstrationen av de slutliga presentationerna av deltagarnas projekt. Det var 6 lag om 5 personer på hackathonet, alla deltagare hade bra projekt, men vår plattform visade sig vara den mest konkurrenskraftiga. Vi har ett mycket intressant projekt, som jag skulle vilja prata om i den här artikeln.
Vår lösning är en plattform baserad på serverlös arkitektur inuti Kubernetes, vilket minskar tiden det tar att ta med nya funktioner till produktion. Det tillåter analytiker att skriva kod i en miljö som är bekväm för dem och distribuera den i produktion utan deltagande av ingenjörer och utvecklare.
Vad är poäng
Tinkoff.ru, som många moderna företag, har kundpoäng. Scoring är ett kundbedömningssystem baserat på statistiska metoder för dataanalys.
Till exempel vänder sig en kund till oss med en begäran om att ge honom ett lån eller öppna ett individuellt företagarkonto hos oss. Om vi planerar att ge honom ett lån, måste vi bedöma hans solvens, och om kontot är en enskild entreprenör, måste vi vara säkra på att kunden inte kommer att genomföra bedrägliga transaktioner.
Grunden för att fatta sådana beslut är matematiska modeller som analyserar både data från själva applikationen och data från vår lagring. Förutom poängsättning kan liknande statistiska metoder också användas för att generera individuella rekommendationer för nya produkter till våra kunder.
Metoden för en sådan bedömning kan acceptera en mängd olika indata. Och vid något tillfälle kan vi lägga till en ny parameter till ingången, som, baserat på resultaten av analys på historiska data, kommer att öka omvandlingsfrekvensen för att använda tjänsten.
Vi har en mängd data om kundrelationer, och volymen av denna information växer ständigt. För att poängsättning ska fungera kräver databearbetning också regler (eller matematiska modeller) som gör att du snabbt kan bestämma vem som ska godkänna en ansökan, vem som ska avslå och vem som ska erbjuda ytterligare ett par produkter, för att bedöma deras potentiella intresse.
För den aktuella uppgiften använder vi redan ett specialiserat beslutssystem , som, baserat på de regler som satts av analytiker, teknologer och utvecklare, beslutar om att godkänna eller vägra en viss bankprodukt till kunden.
Det finns många färdiga lösningar på marknaden, både poängmodeller och själva beslutssystemen. Vi använder ett av dessa system i vårt företag. Men verksamheten växer, diversifieras, både antalet kunder och antalet produkter som erbjuds ökar, och tillsammans med detta dyker det upp idéer om hur man kan förbättra den befintliga beslutsprocessen. Människor som arbetar med det befintliga systemet har säkert många idéer om hur man kan göra det enklare, bättre, bekvämare, men ibland är idéer utifrån användbara. New Hackathon arrangerades med syftet att samla in sunda idéer.
Uppgift
Hackathon hölls den 23 februari. Deltagarna erbjöds en stridsuppgift: att utveckla ett beslutssystem som måste uppfylla ett antal villkor.
Vi fick veta hur det befintliga systemet fungerar och vilka svårigheter som uppstår under driften, samt vilka affärsmål den utvecklade plattformen ska eftersträva. Systemet måste ha en snabb time-to-market för att utveckla regler så att analytikers arbetskod kommer i produktion så snabbt som möjligt. Och för det inkommande ansökningsflödet bör beslutstiden tendera till ett minimum. Dessutom måste systemet som utvecklas ha korsförsäljningsmöjligheter för att ge kunden möjlighet att köpa andra företagsprodukter om de är godkända av oss och har potentiellt intresse från kunden.
Det är klart att det är omöjligt att skriva ett släppfärdigt projekt över en natt som säkert kommer att gå i produktion, och det är ganska svårt att täcka hela systemet, så vi blev ombedda att implementera åtminstone en del av det. Ett antal krav fastställdes som prototypen ska uppfylla. Det var möjligt att försöka både täcka alla krav i sin helhet och att arbeta i detalj på enskilda delar av plattformen som utvecklades.
När det gäller teknik fick alla deltagare fullständig valfrihet. Det var möjligt att använda alla koncept och tekniker: dataströmning, maskininlärning, event sourcing, big data och annat.
Vår lösning
Efter lite brainstorming bestämde vi oss för att en FaaS-lösning skulle vara idealisk för att slutföra uppgiften.
För denna lösning var det nödvändigt att hitta ett lämpligt serverlöst ramverk för att implementera reglerna för det beslutssystem som utvecklades. Eftersom Tinkoff aktivt använder Kubernetes för infrastrukturhantering tittade vi på flera färdiga lösningar baserade på det, jag kommer att berätta mer om det senare.
För att hitta den mest effektiva lösningen tittade vi på produkten som utvecklades genom användarnas ögon. De huvudsakliga användarna av vårt system är analytiker som är involverade i regelutveckling. Reglerna måste distribueras till servern, eller, som i vårt fall, distribueras i molnet, för efterföljande beslutsfattande. Ur en analytikers perspektiv ser arbetsflödet ut så här:
- Analytikern skriver ett skript, en regel eller en ML-modell baserat på data från lagret. Som en del av hackathonet bestämde vi oss för att använda Mongodb, men valet av datalagringssystem är inte viktigt här.
- Efter att ha testat de utvecklade reglerna för historisk data laddar analytikern upp sin kod till adminpanelen.
- För att säkerställa versionshantering kommer all kod att gå till Git repositories.
- Genom adminpanelen kommer det att vara möjligt att distribuera koden i molnet som en separat funktionell Serverlös modul.
Initial data från kunder måste passera genom en specialiserad berikningstjänst utformad för att berika den initiala begäran med data från lagret. Det var viktigt att implementera den här tjänsten på ett sådant sätt att den skulle fungera med ett enda arkiv (från vilket analytikern hämtar data när han utvecklar regler) för att upprätthålla en enhetlig datastruktur.
Redan innan hackathonet bestämde vi oss för det serverlösa ramverket som vi skulle använda. Idag finns det ganska många tekniker på marknaden som implementerar detta tillvägagångssätt. De mest populära lösningarna inom Kubernetes-arkitekturen är Fission, Open FaaS och Kubeless. Det finns till och med .
Efter att ha vägt alla för- och nackdelar valde vi . Detta serverlösa ramverk är ganska lätt att hantera och uppfyller kraven för uppgiften.
För att arbeta med Fission behöver du förstå två grundläggande begrepp: funktion och miljö. En funktion är en bit kod skriven på ett av de språk som det finns en Fission-miljö för. inkluderar Python, JS, Go, JVM och många andra populära språk och teknologier.
Fission kan också utföra funktioner uppdelade i flera filer, förpackade i ett arkiv. Driften av Fission i ett Kubernetes-kluster säkerställs av specialiserade pods, som hanteras av själva ramverket. För att interagera med klusterpods måste varje funktion tilldelas sin egen rutt, och till vilken du kan skicka GET-parametrar eller begärandekroppen i fallet med en POST-begäran.
Som ett resultat planerade vi att skaffa en lösning som skulle göra det möjligt för analytiker att distribuera utvecklade regelskript utan medverkan av ingenjörer och utvecklare. Det beskrivna tillvägagångssättet eliminerar också behovet för utvecklare att skriva om analytikerkoden till ett annat språk. Till exempel, för det nuvarande beslutssystem vi använder, måste vi skriva regler i högt specialiserade tekniker och språk, vars omfattning är extremt begränsad, och det finns också ett starkt beroende av applikationsservern, eftersom alla utkast till bankregler distribueras i en enda miljö. Som ett resultat är det nödvändigt att släppa hela systemet för att distribuera nya regler.
I vår föreslagna lösning finns det inget behov av att släppa regler, koden kan enkelt distribueras med ett klick på en knapp. Dessutom tillåter infrastrukturhantering i Kubernetes dig att inte tänka på belastning och skalning; sådana problem löses direkt. Och användningen av ett enda datalager eliminerar behovet av att jämföra realtidsdata med historiska data, vilket förenklar analytikerns arbete.
Vad vi fick
Eftersom vi kom till hackathonet med en färdig lösning (i våra fantasier) behövde vi bara omvandla alla våra tankar till kodrader.
Nyckeln till framgång på alla hackathon är förberedelser och en välskriven plan. Därför var det första vi gjorde att bestämma vilka moduler vår systemarkitektur skulle bestå av och vilka teknologier vi skulle använda.
Arkitekturen för vårt projekt var följande:
Detta diagram visar två ingångspunkter, analytikern (huvudanvändaren av vårt system) och klienten.
Arbetsprocessen är uppbyggd så här. Analytikern utvecklar en regelfunktion och en databerikande funktion för sin modell, lagrar sin kod i ett Git-förråd och distribuerar sin modell till molnet via administratörsapplikationen. Låt oss överväga hur den distribuerade funktionen kommer att anropas och fatta beslut om inkommande förfrågningar från kunder:
- Kunden fyller i ett formulär på hemsidan och skickar sin förfrågan till den registeransvarige. En ansökan som behöver fattas beslut om kommer till systeminmatningen och registreras i databasen i sin ursprungliga form.
- Därefter skickas den råa begäran för anrikning, om det behövs. Du kan komplettera den initiala förfrågan med data både från externa tjänster och från lagringen. Den resulterande berikade frågan lagras också i databasen.
- Analytikerfunktionen lanseras, som tar en berikad fråga som input och tar fram en lösning som också skrivs till lagringen.
Vi bestämde oss för att använda MongoDB som en lagring i vårt system på grund av den dokumentorienterade lagringen av data i form av JSON-dokument, eftersom anrikningstjänsterna, inklusive den ursprungliga begäran, aggregerade all data genom REST-kontrollanter.
Så vi hade XNUMX timmar på oss att implementera plattformen. Vi fördelade rollerna ganska framgångsrikt; varje teammedlem hade sitt eget ansvarsområde i vårt projekt:
- Front-end adminpaneler för analytikerns arbete, genom vilka han kunde ladda ner regler från versionskontrollsystemet för skrivna skript, välja alternativ för att berika indata och redigera regelskript online.
- Backend-admin, inklusive REST API för fronten och integration med VCS.
- Konfigurera infrastruktur i Google Cloud och utveckla en tjänst för att berika källdata.
- En modul för att integrera administratörsapplikationen med det serverlösa ramverket för efterföljande distribution av regler.
- Skript med regler för att testa hela systemets prestanda och aggregering av analyser på inkommande applikationer (beslut fattade) för den slutliga demonstrationen.
Låt oss börja i ordning.
Vår frontend skrevs i Angular 7 med hjälp av bank-UI Kit. Den slutliga versionen av adminpanelen såg ut så här:
Eftersom det var kort tid försökte vi implementera endast nyckelfunktionaliteten. För att distribuera en funktion i Kubernetes-klustret var det nödvändigt att välja en händelse (en tjänst för vilken en regel måste distribueras i molnet) och koden för funktionen som implementerar beslutslogiken. För varje distribution av en regel för den valda tjänsten skrev vi en logg över denna händelse. I adminpanelen kunde du se loggar över alla händelser.
All funktionskod lagrades i ett avlägset Git-förråd, som också måste ställas in i adminpanelen. För att versionera koden lagrades alla funktioner i olika grenar av förvaret. Administratörspanelen ger också möjligheten att göra justeringar av skrivna skript, så att du inte bara kan kontrollera den skrivna koden innan du distribuerar en funktion till produktionen, utan även göra nödvändiga ändringar.
Utöver regelfunktionerna implementerade vi även möjligheten att gradvis berika källdata med hjälp av berikningsfunktioner, vars kod också var skript där det var möjligt att gå till datalagret, ringa tredjepartstjänster och utföra preliminära beräkningar . För att demonstrera vår lösning beräknade vi stjärntecknet för klienten som lämnade begäran och bestämde sin mobiloperatör med hjälp av en tredje parts REST-tjänst.
Baksidan av plattformen skrevs i Java och implementerades som en Spring Boot-applikation. Vi planerade från början att använda Postgres för att lagra admindata, men som en del av hackathonet bestämde vi oss för att begränsa oss till en enkel H2 för att spara tid. På baksidan implementerades integration med Bitbucket för att versionera frågeanrikningsfunktionerna och regelskripten. För integration med fjärrstyrda Git-förråd använde vi , som är ett slags omslag över CLI-kommandon, som låter dig utföra alla git-instruktioner med ett bekvämt mjukvarugränssnitt. Så vi hade två separata arkiv för berikningsfunktioner och regler, och alla skript var uppdelade i kataloger. Genom användargränssnittet var det möjligt att välja den senaste commit för ett skript av en godtycklig gren av förvaret. När du gjorde ändringar i koden via adminpanelen skapades commits för den ändrade koden i fjärrlager.
För att genomföra vår idé behövde vi lämplig infrastruktur. Vi bestämde oss för att distribuera vårt Kubernetes-kluster i molnet. Vårt val var Google Cloud Platform. Det serverlösa Fission-ramverket installerades på ett Kubernetes-kluster, som vi distribuerade i Gcloud. Ursprungligen implementerades källdataanrikningstjänsten som en separat Java-applikation insvept i en Pod inuti k8s-klustret. Men efter en preliminär demonstration av vårt projekt mitt under hackathonet rekommenderades vi att göra Enrichment-tjänsten mer flexibel för att ge möjlighet att välja hur man berikar rådata från inkommande applikationer. Och vi hade inget annat val än att göra berikningstjänsten även Serverlös.
För att arbeta med Fission använde vi Fission CLI, som måste installeras ovanpå Kubernetes CLI. Att distribuera funktioner i ett k8s-kluster är ganska enkelt; du behöver bara tilldela en intern rutt och ingång till funktionen för att tillåta inkommande trafik om åtkomst utanför klustret behövs. Att implementera en funktion tar vanligtvis inte mer än 10 sekunder.
Slutlig presentation av projektet och sammanfattning
För att visa hur vårt system fungerar har vi lagt ett enkelt formulär på en fjärrserver där du kan skicka in en ansökan om en av bankens produkter. För att begära var du tvungen att ange dina initialer, födelsedatum och telefonnummer.
Data från klientformuläret gick till den registeransvarige, som samtidigt skickade förfrågningar om alla tillgängliga regler, efter att tidigare ha berikat uppgifterna enligt de angivna villkoren och sparat dem i en gemensam lagring. Totalt har vi implementerat tre funktioner som fattar beslut om inkommande applikationer och 4 databerikningstjänster. Efter att ha skickat in ansökan fick kunden vårt beslut:
Utöver avslag eller godkännande fick kunden även en lista över andra produkter, förfrågningar som vi skickade parallellt. Så demonstrerade vi möjligheten till korsförsäljning i vår plattform.
Det fanns totalt 3 fiktiva bankprodukter tillgängliga:
- Kreditera.
- leksak
- Inteckning.
Under demonstrationen distribuerade vi förberedda funktioner och berikningsskript för varje tjänst.
Varje regel krävde sin egen uppsättning indata. Så för att godkänna en inteckning beräknade vi kundens stjärntecken och kopplade detta till månkalenderns logik. För att godkänna en leksak kontrollerade vi att kunden hade uppnått myndig ålder och för att utfärda ett lån skickade vi en begäran till en extern öppen tjänst för att fastställa mobiloperatören och beslut fattades om det.
Vi försökte göra vår demonstration intressant och interaktiv, alla närvarande kunde gå till vårt formulär och kontrollera tillgängligheten av våra fiktiva tjänster för dem. Och alldeles i slutet av presentationen visade vi analyser av mottagna ansökningar, som visade hur många som använde vår tjänst, antalet godkännanden och avslag.
För att samla in analyser online har vi dessutom implementerat ett BI-verktyg med öppen källkod och skruvade fast den i vår förvaringsenhet. Metabase låter dig bygga skärmar med analyser på data som intresserar oss; du behöver bara registrera en anslutning till databasen, välja tabeller (i vårt fall datainsamlingar, eftersom vi använde MongoDB) och ange vilka områden som är intressanta för oss .
Som ett resultat fick vi en bra prototyp av en beslutsplattform, och under demonstrationen kunde varje lyssnare personligen kontrollera dess prestanda. En intressant lösning, en färdig prototyp och en lyckad demonstration gjorde att vi kunde vinna, trots stark konkurrens från andra team. Jag är säker på att en intressant artikel också kan skrivas om varje teams projekt.
Källa: will.com