Sinds vorig jaar is ons bedrijf begonnen met het organiseren van hackathons. De eerste dergelijke wedstrijd was zeer succesvol, we schreven erover in . De tweede hackathon vond plaats in februari 2019 en was niet minder succesvol. Over de doelstellingen van het vasthouden van de laatste nog niet zo lang geleden organisator.
De deelnemers kregen een nogal interessante taak met volledige vrijheid bij het kiezen van een technologiestapel voor de implementatie ervan. Het was noodzakelijk om een besluitvormingsplatform te implementeren voor een gemakkelijke implementatie van klantscorefuncties dat kon werken met een snelle stroom van applicaties, bestand was tegen zware belastingen, en het systeem zelf gemakkelijk schaalbaar was.
De taak is niet triviaal en kan op veel manieren worden opgelost, zoals we overtuigd waren tijdens de demonstratie van de eindpresentaties van de projecten van de deelnemers. Er waren 6 teams van 5 personen bij de hackathon, alle deelnemers hadden goede projecten, maar ons platform bleek het meest competitief. We hebben een heel interessant project, waarover ik in dit artikel graag wil praten.
Onze oplossing is een platform gebaseerd op serverloze architectuur binnen Kubernetes, waardoor de tijd die nodig is om nieuwe functies in productie te brengen, wordt verkort. Het stelt analisten in staat code te schrijven in een voor hen geschikte omgeving en deze in productie te nemen zonder de deelname van ingenieurs en ontwikkelaars.
Wat is scoren
Tinkoff.ru heeft, net als veel moderne bedrijven, klantenscores. Scoring is een klantbeoordelingssysteem gebaseerd op statistische methoden voor data-analyse.
Een klant wendt zich bijvoorbeeld tot ons met het verzoek hem een lening te verstrekken, of een individuele ondernemersrekening bij ons te openen. Als we van plan zijn hem een lening te verstrekken, moeten we zijn solvabiliteit beoordelen, en als de rekening een individuele ondernemer is, moeten we er zeker van zijn dat de klant geen frauduleuze transacties zal uitvoeren.
De basis voor het nemen van dergelijke beslissingen zijn wiskundige modellen die zowel de data uit de applicatie zelf als de data uit onze opslag analyseren. Naast scoring kunnen vergelijkbare statistische methoden ook worden gebruikt om individuele aanbevelingen voor nieuwe producten voor onze klanten te genereren.
De methode van een dergelijke beoordeling kan een verscheidenheid aan invoergegevens accepteren. En op een gegeven moment kunnen we een nieuwe parameter aan de invoer toevoegen, die, op basis van de resultaten van analyse van historische gegevens, de conversieratio van het gebruik van de service zal verhogen.
We beschikken over een schat aan gegevens over klantrelaties, en de omvang van deze informatie groeit voortdurend. Om het scoren te laten werken, vereist de gegevensverwerking ook regels (of wiskundige modellen) waarmee u snel kunt beslissen wie een aanvraag goedkeurt, wie u weigert en wie nog een paar producten aanbiedt, waarbij u hun potentiële interesse beoordeelt.
Voor de taak die voor ons ligt, gebruiken we al een gespecialiseerd besluitvormingssysteem , dat op basis van de regels van analisten, technologen en ontwikkelaars beslist of een bepaald bankproduct aan de klant wordt goedgekeurd of geweigerd.
Er zijn veel kant-en-klare oplossingen op de markt, zowel scoremodellen als beslissingssystemen zelf. Wij gebruiken een van deze systemen in ons bedrijf. Maar het bedrijf groeit en diversifieert, zowel het aantal klanten als het aantal aangeboden producten neemt toe, en tegelijkertijd ontstaan er ideeën over hoe het bestaande besluitvormingsproces kan worden verbeterd. Mensen die met het bestaande systeem werken, hebben ongetwijfeld veel ideeën over hoe ze het eenvoudiger, beter en handiger kunnen maken, maar soms zijn ideeën van buitenaf nuttig. De Nieuwe Hackathon werd georganiseerd met als doel goede ideeën te verzamelen.
Taak
Op 23 februari vond de hackathon plaats. De deelnemers kregen een gevechtstaak aangeboden: het ontwikkelen van een besluitvormingssysteem dat aan een aantal voorwaarden moest voldoen.
Er werd ons verteld hoe het bestaande systeem functioneert en welke moeilijkheden zich voordoen tijdens de werking ervan, en welke zakelijke doelen het ontwikkelde platform zou moeten nastreven. Het systeem moet een snelle time-to-market hebben voor het ontwikkelen van regels, zodat de werkende code van analisten zo snel mogelijk in productie komt. En voor de binnenkomende stroom aanvragen moet de besluitvormingstijd tot een minimum worden beperkt. Ook moet het systeem dat wordt ontwikkeld over cross-sell-mogelijkheden beschikken om de klant de mogelijkheid te geven andere bedrijfsproducten te kopen als deze door ons zijn goedgekeurd en mogelijk interesse hebben van de klant.
Het is duidelijk dat het onmogelijk is om van de ene op de andere dag een kant-en-klaar project te schrijven dat zeker in productie zal gaan, en het is nogal moeilijk om het hele systeem te dekken, dus werd ons gevraagd om tenminste een deel ervan te implementeren. Er zijn een aantal eisen gesteld waar het prototype aan moet voldoen. Het was mogelijk om zowel te proberen alle vereisten in hun geheel te dekken, als om in detail te werken aan afzonderlijke delen van het platform dat werd ontwikkeld.
Wat de technologie betreft, kregen alle deelnemers volledige keuzevrijheid. Het was mogelijk om alle concepten en technologieën te gebruiken: datastreaming, machine learning, eventsourcing, big data en meer.
Onze oplossing
Na een beetje brainstormen besloten we dat een FaaS-oplossing ideaal zou zijn om de taak te voltooien.
Voor deze oplossing was het noodzakelijk om een geschikt serverloos raamwerk te vinden om de regels van het besluitvormingssysteem dat werd ontwikkeld te implementeren. Omdat Tinkoff Kubernetes actief gebruikt voor infrastructuurbeheer, hebben we op basis daarvan een aantal kant-en-klare oplossingen bekeken; daar vertel ik later meer over.
Om de meest effectieve oplossing te vinden, keken we naar het product dat werd ontwikkeld door de ogen van de gebruikers. De belangrijkste gebruikers van ons systeem zijn analisten die betrokken zijn bij de ontwikkeling van regels. De regels moeten op de server worden geïmplementeerd, of, zoals in ons geval, in de cloud, voor daaropvolgende besluitvorming. Vanuit het perspectief van een analist ziet de workflow er als volgt uit:
- De analist schrijft een script, regel of ML-model op basis van gegevens uit het magazijn. Als onderdeel van de hackathon hebben we besloten om Mongodb te gebruiken, maar de keuze van het dataopslagsysteem is hier niet belangrijk.
- Nadat de ontwikkelde regels op historische gegevens zijn getest, uploadt de analist zijn code naar het beheerderspaneel.
- Om versiebeheer te garanderen, gaat alle code naar Git-repository's.
- Via het admin panel is het mogelijk om de code in de cloud te implementeren als een aparte functionele Serverless module.
De initiële gegevens van klanten moeten via een gespecialiseerde verrijkingsservice gaan die is ontworpen om de initiële aanvraag te verrijken met gegevens uit het magazijn. Het was belangrijk om deze dienst zo te implementeren dat deze zou werken met één enkele repository (waaruit de analist gegevens haalt bij het ontwikkelen van regels) om een uniforme datastructuur te behouden.
Zelfs vóór de hackathon hadden we besloten welk Serverless-framework we zouden gebruiken. Tegenwoordig zijn er behoorlijk wat technologieën op de markt die deze aanpak implementeren. De meest populaire oplossingen binnen de Kubernetes-architectuur zijn Fission, Open FaaS en Kubeless. Er zijn zelfs .
Na alle voor- en nadelen afgewogen te hebben, hebben we gekozen . Dit serverloze raamwerk is vrij eenvoudig te beheren en voldoet aan de vereisten van de taak.
Om met Fission te kunnen werken, moet u twee basisconcepten begrijpen: functie en omgeving. Een functie is een stukje code geschreven in een van de talen waarvoor er een Fission-omgeving bestaat. omvat Python, JS, Go, JVM en vele andere populaire talen en technologieën.
Fission kan ook functies uitvoeren die zijn onderverdeeld in verschillende bestanden, voorverpakt in een archief. De werking van Fission in een Kubernetes-cluster wordt verzekerd door gespecialiseerde pods, die worden beheerd door het raamwerk zelf. Om met clusterpods te kunnen communiceren, moet aan elke functie een eigen route worden toegewezen, en waaraan u GET-parameters kunt doorgeven of de hoofdtekst kunt aanvragen in het geval van een POST-aanvraag.
Als gevolg hiervan waren we van plan een oplossing te verkrijgen waarmee analisten ontwikkelde regelscripts konden implementeren zonder de deelname van ingenieurs en ontwikkelaars. De beschreven aanpak elimineert ook de noodzaak voor ontwikkelaars om analistencode in een andere taal te herschrijven. Voor het huidige besluitvormingssysteem dat we gebruiken, moeten we bijvoorbeeld regels schrijven in zeer gespecialiseerde technologieën en talen, waarvan de reikwijdte uiterst beperkt is, en er is ook een sterke afhankelijkheid van de applicatieserver, aangezien alle ontwerpbankregels worden in één omgeving ingezet. Als gevolg hiervan is het voor het implementeren van nieuwe regels noodzakelijk om het hele systeem vrij te geven.
In onze voorgestelde oplossing is het niet nodig om regels vrij te geven; de code kan eenvoudig met één klik op de knop worden geïmplementeerd. Bovendien zorgt infrastructuurbeheer in Kubernetes ervoor dat u niet hoeft na te denken over belasting en schaalvergroting; dergelijke problemen worden out-of-the-box opgelost. En het gebruik van één enkel datawarehouse elimineert de noodzaak om realtime gegevens te vergelijken met historische gegevens, wat het werk van de analist vereenvoudigt.
Wat we hebben
Omdat we (in onze fantasieën) met een kant-en-klare oplossing naar de hackathon kwamen, hoefden we alleen al onze gedachten om te zetten in regels code.
De sleutel tot succes bij elke hackathon is voorbereiding en een goed geschreven plan. Daarom besloten we eerst uit welke modules onze systeemarchitectuur zou bestaan en welke technologieën we zouden gebruiken.
De architectuur van ons project was als volgt:
Dit diagram toont twee toegangspunten: de analist (de hoofdgebruiker van ons systeem) en de klant.
Het werkproces is als volgt opgebouwd. De analist ontwikkelt een regelfunctie en een gegevensverrijkingsfunctie voor zijn model, slaat zijn code op in een Git-repository en implementeert zijn model via de beheerdersapplicatie in de cloud. Laten we eens kijken hoe de geïmplementeerde functie wordt aangeroepen en beslissingen nemen over inkomende verzoeken van clients:
- De klant vult een formulier in op de website en stuurt zijn verzoek naar de verwerkingsverantwoordelijke. Een aanvraag waarover een besluit moet worden genomen, komt bij de systeeminvoer en wordt in de oorspronkelijke vorm vastgelegd in de database.
- Vervolgens wordt het onbewerkte verzoek indien nodig ter verrijking verzonden. U kunt de initiële aanvraag aanvullen met gegevens van zowel externe diensten als uit de opslag. De resulterende verrijkte zoekopdracht wordt ook opgeslagen in de database.
- De analistenfunctie wordt gestart, die een verrijkte query als invoer neemt en een oplossing oplevert, die ook naar de opslag wordt geschreven.
We hebben besloten om MongoDB als opslag in ons systeem te gebruiken vanwege de documentgeoriënteerde opslag van gegevens in de vorm van JSON-documenten, aangezien de verrijkingsdiensten, inclusief het oorspronkelijke verzoek, alle gegevens verzamelden via REST-controllers.
We hadden dus XNUMX uur de tijd om het platform te implementeren. We hebben de rollen redelijk succesvol verdeeld; elk teamlid had zijn eigen verantwoordelijkheidsgebied in ons project:
- Front-end adminpanelen voor het werk van de analist, waarmee hij regels kon downloaden uit het versiebeheersysteem van geschreven scripts, opties kon selecteren voor het verrijken van invoergegevens en regelscripts online kon bewerken.
- Backend admin, inclusief REST API voor de front en integratie met VCS.
- Opzetten van infrastructuur in Google Cloud en ontwikkelen van een dienst voor het verrijken van brondata.
- Een module voor het integreren van de beheerdersapplicatie met het Serverless-framework voor de daaropvolgende implementatie van regels.
- Scripts met regels voor het testen van de prestaties van het hele systeem en aggregatie van analyses van binnenkomende applicaties (genomen beslissingen) voor de uiteindelijke demonstratie.
Laten we beginnen op volgorde.
Onze frontend is geschreven in Angular 7 met behulp van de banking UI Kit. De definitieve versie van het beheerderspaneel zag er als volgt uit:
Omdat er weinig tijd was, probeerden we alleen de belangrijkste functionaliteit te implementeren. Om een functie in het Kubernetes-cluster te implementeren, was het nodig om een gebeurtenis (een dienst waarvoor een regel in de cloud moet worden geïmplementeerd) en de code van de functie die de besluitvormingslogica implementeert te selecteren. Voor elke implementatie van een regel voor de geselecteerde service hebben we een logboek van deze gebeurtenis geschreven. In het beheerderspaneel kunt u logboeken van alle gebeurtenissen zien.
Alle functiecode werd opgeslagen in een externe Git-repository, die ook in het beheerderspaneel moest worden ingesteld. Om de code te versieleren, werden alle functies opgeslagen in verschillende takken van de repository. Het beheerderspaneel biedt ook de mogelijkheid om aanpassingen aan geschreven scripts aan te brengen, zodat u, voordat u een functie naar productie implementeert, niet alleen de geschreven code kunt controleren, maar ook de nodige wijzigingen kunt aanbrengen.
Naast de regelfuncties hebben we ook de mogelijkheid geïmplementeerd om de brongegevens geleidelijk te verrijken met behulp van verrijkingsfuncties, waarvan de code ook scripts was waarin het mogelijk was om naar het datawarehouse te gaan, diensten van derden te bellen en voorlopige berekeningen uit te voeren . Om onze oplossing te demonstreren, berekenden we het sterrenbeeld van de klant die het verzoek had achtergelaten en bepaalden we zijn mobiele operator met behulp van een REST-service van derden.
De backend van het platform is geschreven in Java en geïmplementeerd als Spring Boot-applicatie. We waren aanvankelijk van plan om Postgres te gebruiken om beheerdersgegevens op te slaan, maar als onderdeel van de hackathon hebben we besloten ons te beperken tot een eenvoudige H2 om tijd te besparen. Op de backend werd integratie met Bitbucket geïmplementeerd om de functies voor het verrijken van zoekopdrachten en regelscripts te versieleren. Voor integratie met externe Git-repository's hebben we gebruikt , wat een soort wrapper is over CLI-opdrachten, waardoor je alle git-instructies kunt uitvoeren met behulp van een handige software-interface. We hadden dus twee afzonderlijke opslagplaatsen voor verrijkingsfuncties en -regels, en alle scripts waren onderverdeeld in mappen. Via de gebruikersinterface was het mogelijk om de laatste commit van een script van een willekeurige tak van de repository te selecteren. Wanneer u via het beheerderspaneel wijzigingen in de code aanbrengt, worden er commits van de gewijzigde code gemaakt in externe opslagplaatsen.
Om ons idee te verwezenlijken hadden we een geschikte infrastructuur nodig. We besloten ons Kubernetes-cluster in de cloud te implementeren. Onze keuze viel op Google Cloud Platform. Het Fission serverless framework werd geïnstalleerd op een Kubernetes-cluster, dat we in Gcloud hebben geïmplementeerd. Aanvankelijk werd de brongegevensverrijkingsservice geïmplementeerd als een afzonderlijke Java-applicatie verpakt in een pod in het k8s-cluster. Maar na een voorlopige demonstratie van ons project midden in de hackathon, werd ons aanbevolen om de Enrichment-service flexibeler te maken, zodat we konden kiezen hoe we de onbewerkte gegevens van binnenkomende applicaties wilden verrijken. En we hadden geen andere keuze dan de verrijkingsservice ook serverloos te maken.
Om met Fission te werken, hebben we de Fission CLI gebruikt, die bovenop de Kubernetes CLI moet worden geïnstalleerd. Het implementeren van functies in een k8s-cluster is vrij eenvoudig; u hoeft alleen maar een interne route en toegang toe te wijzen aan de functie om inkomend verkeer toe te staan als toegang buiten het cluster nodig is. Het implementeren van één functie duurt doorgaans niet langer dan 10 seconden.
Eindpresentatie van het project en samenvatting
Om te laten zien hoe ons systeem werkt, hebben wij een eenvoudig formulier op een externe server geplaatst waar u een aanvraag kunt indienen voor een van de producten van de bank. Om dit aan te vragen, moest u uw initialen, geboortedatum en telefoonnummer invoeren.
Gegevens van het klantformulier gingen naar de controller, die tegelijkertijd verzoeken voor alle beschikbare regels stuurde, nadat hij de gegevens eerder had verrijkt volgens de gespecificeerde voorwaarden, en deze in een gemeenschappelijke opslag opsloeg. In totaal hebben we drie functies ingezet die beslissingen nemen over inkomende applicaties en vier dataverrijkingsdiensten. Na het indienen van de aanvraag heeft de opdrachtgever ons besluit ontvangen:
Naast weigering of goedkeuring ontving de klant ook een lijst met andere producten, verzoeken waarvoor we parallel stuurden. Zo hebben wij de mogelijkheid tot cross-sale in ons platform gedemonstreerd.
In totaal waren er 3 fictieve bankproducten beschikbaar:
- Credit.
- Speelbal
- Hypotheek.
Tijdens de demonstratie hebben we voor elke service voorbereide functies en verrijkingsscripts geïmplementeerd.
Elke regel vereiste zijn eigen set invoergegevens. Om een hypotheek goed te keuren, berekenden we dus het sterrenbeeld van de klant en verbonden dit met de logica van de maankalender. Om speelgoed goed te keuren, controleerden we of de klant meerderjarig was, en om een lening te verstrekken, stuurden we een verzoek naar een externe open dienst om de mobiele operator te bepalen, en er werd een beslissing over genomen.
We hebben geprobeerd onze demonstratie interessant en interactief te maken. Alle aanwezigen konden naar ons formulier gaan en de beschikbaarheid van onze fictieve diensten voor hen controleren. En helemaal aan het einde van de presentatie demonstreerden we analyses van ontvangen sollicitaties, waaruit bleek hoeveel mensen onze service gebruikten, het aantal goedkeuringen en weigeringen.
Om online analyses te verzamelen, hebben we bovendien een open source BI-tool geïmplementeerd en vastgeschroefd aan onze opslagruimte. Met Metabase kunt u schermen bouwen met analyses van de gegevens die ons interesseren; u hoeft alleen maar een verbinding met de database te registreren, tabellen te selecteren (in ons geval gegevensverzamelingen, aangezien we MongoDB gebruikten) en de velden te specificeren die voor ons interessant zijn .
Het resultaat was dat we een goed prototype van een besluitvormingsplatform kregen, en tijdens de demonstratie kon elke luisteraar persoonlijk de prestaties ervan controleren. Dankzij een interessante oplossing, een voltooid prototype en een succesvolle demonstratie konden we winnen, ondanks de sterke concurrentie van andere teams. Ik ben er zeker van dat er ook over het project van elk team een interessant artikel kan worden geschreven.
Bron: www.habr.com