Depuis l’année dernière, notre entreprise a commencé à organiser des hackathons. Le premier concours de ce type a été très réussi, nous en avons parlé dans . Le deuxième hackathon a eu lieu en février 2019 et n’a pas été moins réussi. Sur les objectifs de la tenue de ce dernier il n'y a pas si longtemps organisateur.
Les participants se sont vu confier une tâche plutôt intéressante avec une totale liberté dans le choix d'une pile technologique pour sa mise en œuvre. Il était nécessaire de mettre en œuvre une plate-forme de prise de décision pour un déploiement pratique des fonctions de notation client, capable de fonctionner avec un flux rapide d'applications, de supporter de lourdes charges, et le système lui-même était facilement évolutif.
La tâche n’est pas triviale et peut être résolue de plusieurs manières, comme nous en avons été convaincus lors de la démonstration des présentations finales des projets des participants. Il y avait 6 équipes de 5 personnes au hackathon, tous les participants avaient de bons projets, mais notre plateforme s'est avérée la plus compétitive. Nous avons un projet très intéressant, dont j'aimerais parler dans cet article.
Notre solution est une plateforme basée sur une architecture Serverless au sein de Kubernetes, ce qui réduit le temps nécessaire pour mettre de nouvelles fonctionnalités en production. Il permet aux analystes d'écrire du code dans un environnement qui leur convient et de le déployer en production sans la participation d'ingénieurs et de développeurs.
Qu'est-ce que la notation
Tinkoff.ru, comme de nombreuses entreprises modernes, dispose d'une notation client. Le Scoring est un système d’évaluation des clients basé sur des méthodes statistiques d’analyse des données.
Par exemple, un client s'adresse à nous pour lui demander un prêt ou ouvrir un compte d'entrepreneur individuel chez nous. Si nous envisageons de lui accorder un prêt, nous devons alors évaluer sa solvabilité, et si le compte est celui d'un entrepreneur individuel, nous devons alors nous assurer que le client n'effectuera pas de transactions frauduleuses.
De telles décisions reposent sur des modèles mathématiques qui analysent à la fois les données de l'application elle-même et les données de notre stockage. En plus de la notation, des méthodes statistiques similaires peuvent également être utilisées pour générer des recommandations individuelles de nouveaux produits pour nos clients.
La méthode d’une telle évaluation peut accepter une variété de données d’entrée. Et à un moment donné, nous pouvons ajouter un nouveau paramètre à l'entrée qui, sur la base des résultats de l'analyse des données historiques, augmentera le taux de conversion de l'utilisation du service.
Nous détenons une multitude de données sur les relations clients, et le volume de ces informations ne cesse de croître. Pour que la notation fonctionne, le traitement des données nécessite également des règles (ou des modèles mathématiques) qui vous permettent de décider rapidement à qui approuver une demande, à qui refuser et à qui proposer quelques produits supplémentaires, en évaluant leur intérêt potentiel.
Pour la tâche à accomplir, nous utilisons déjà un système de prise de décision spécialisé , qui, sur la base des règles fixées par les analystes, les technologues et les développeurs, décide d'approuver ou de refuser un produit bancaire particulier au client.
Il existe de nombreuses solutions toutes faites sur le marché, tant les modèles de notation que les systèmes de prise de décision eux-mêmes. Nous utilisons l'un de ces systèmes dans notre entreprise. Mais l'entreprise se développe, se diversifie, le nombre de clients et le nombre de produits proposés augmentent, et parallèlement, des idées émergent sur la manière d'améliorer le processus décisionnel existant. Les personnes travaillant avec le système existant ont sûrement de nombreuses idées pour le rendre plus simple, meilleur et plus pratique, mais parfois des idées extérieures sont utiles. Le New Hackathon a été organisé dans le but de collecter des idées solides.
Tâche
Le hackathon a eu lieu le 23 février. Les participants se sont vu proposer une tâche de combat : développer un système de prise de décision qui devait remplir un certain nombre de conditions.
On nous a expliqué comment fonctionne le système existant et quelles difficultés surviennent lors de son fonctionnement, ainsi que les objectifs commerciaux que la plate-forme développée doit poursuivre. Le système doit disposer d'un délai de mise sur le marché rapide pour développer des règles afin que le code de travail des analystes entre en production le plus rapidement possible. Et pour le flux de candidatures entrantes, le temps de prise de décision devrait tendre au minimum. De plus, le système en cours de développement doit avoir des capacités de vente croisée afin de donner au client la possibilité d'acheter d'autres produits de l'entreprise s'ils sont approuvés par nous et présentent un intérêt potentiel de la part du client.
Il est clair qu'il est impossible d'écrire du jour au lendemain un projet prêt à sortir qui entrera certainement en production, et il est assez difficile de couvrir l'ensemble du système, on nous a donc demandé d'en mettre en œuvre au moins une partie. Un certain nombre d'exigences ont été établies auxquelles le prototype doit satisfaire. Il a été possible d'essayer à la fois de couvrir toutes les exigences dans leur intégralité et de travailler en détail sur des sections individuelles de la plateforme en cours de développement.
Quant à la technologie, tous les participants ont eu une totale liberté de choix. Il était possible d'utiliser tous les concepts et technologies : streaming de données, machine learning, sourcing d'événements, big data et autres.
Notre solution
Après une petite réflexion, nous avons décidé qu'une solution FaaS serait idéale pour mener à bien cette tâche.
Pour cette solution, il fallait trouver un framework Serverless adapté pour mettre en œuvre les règles du système décisionnel en cours de développement. Étant donné que Tinkoff utilise activement Kubernetes pour la gestion de l'infrastructure, nous avons examiné plusieurs solutions toutes faites basées sur celui-ci ; je vous en parlerai plus en détail plus tard.
Pour trouver la solution la plus efficace, nous avons examiné le produit en cours de développement à travers les yeux de ses utilisateurs. Les principaux utilisateurs de notre système sont les analystes impliqués dans l'élaboration des règles. Les règles doivent être déployées sur le serveur, ou, comme dans notre cas, déployées dans le cloud, pour une prise de décision ultérieure. Du point de vue d'un analyste, le flux de travail ressemble à ceci :
- L'analyste écrit un script, une règle ou un modèle ML basé sur les données de l'entrepôt. Dans le cadre du hackathon, nous avons décidé d'utiliser Mongodb, mais le choix du système de stockage de données n'est pas important ici.
- Après avoir testé les règles développées sur les données historiques, l'analyste télécharge son code sur le panneau d'administration.
- Pour garantir le versionnage, tout le code ira dans les référentiels Git.
- Grâce au panneau d'administration, il sera possible de déployer le code dans le cloud en tant que module fonctionnel distinct sans serveur.
Les données initiales des clients doivent transiter par un service d'enrichissement spécialisé conçu pour enrichir la demande initiale avec les données de l'entrepôt. Il était important de mettre en œuvre ce service de manière à ce qu'il fonctionne avec un référentiel unique (à partir duquel l'analyste récupère les données lors de l'élaboration des règles) afin de maintenir une structure de données unifiée.
Même avant le hackathon, nous avons décidé du framework Serverless que nous utiliserions. Il existe aujourd’hui sur le marché de nombreuses technologies mettant en œuvre cette approche. Les solutions les plus populaires au sein de l'architecture Kubernetes sont Fission, Open FaaS et Kubeless. Il y a même .
Après avoir pesé le pour et le contre, nous avons choisi . Ce framework Serverless est assez simple à gérer et répond aux exigences de la tâche.
Pour travailler avec Fission, vous devez comprendre deux concepts de base : la fonction et l'environnement. Une fonction est un morceau de code écrit dans l'un des langages pour lesquels il existe un environnement Fission. inclut Python, JS, Go, JVM et de nombreux autres langages et technologies populaires.
Fission est également capable d'exécuter des fonctions divisées en plusieurs fichiers, pré-emballés dans une archive. Le fonctionnement de Fission dans un cluster Kubernetes est assuré par des pods spécialisés, qui sont gérés par le framework lui-même. Pour interagir avec les pods du cluster, chaque fonction doit se voir attribuer sa propre route, et à laquelle vous pouvez transmettre des paramètres GET ou le corps de la requête dans le cas d'une requête POST.
En conséquence, nous avions prévu d'obtenir une solution qui permettrait aux analystes de déployer des scripts de règles développés sans la participation des ingénieurs et des développeurs. L'approche décrite élimine également le besoin pour les développeurs de réécrire le code d'analyste dans un autre langage. Par exemple, pour le système décisionnel que nous utilisons actuellement, nous devons écrire des règles dans des technologies et des langages hautement spécialisés, dont la portée est extrêmement limitée, et il existe également une forte dépendance au serveur d'applications, puisque tous les projets de règles bancaires sont déployés dans un environnement unique. Par conséquent, pour déployer de nouvelles règles, il est nécessaire de libérer l’ensemble du système.
Dans la solution que nous proposons, il n'est pas nécessaire de publier des règles ; le code peut être facilement déployé en un seul clic. De plus, la gestion de l'infrastructure dans Kubernetes vous permet de ne pas penser à la charge et à la mise à l'échelle : ces problèmes sont résolus immédiatement. Et l’utilisation d’un entrepôt de données unique élimine le besoin de comparer les données en temps réel avec les données historiques, ce qui simplifie le travail de l’analyste.
Ce que nous avons
Puisque nous sommes arrivés au hackathon avec une solution toute faite (dans nos fantasmes), il nous suffisait de convertir toutes nos pensées en lignes de code.
La clé du succès de tout hackathon est la préparation et un plan bien rédigé. Par conséquent, la première chose que nous avons faite a été de décider de quels modules serait composée notre architecture système et quelles technologies nous utiliserions.
L'architecture de notre projet était la suivante :
Ce diagramme montre deux points d'entrée, l'analyste (l'utilisateur principal de notre système) et le client.
Le processus de travail est structuré ainsi. L'analyste développe une fonction de règles et une fonction d'enrichissement des données pour son modèle, stocke son code dans un référentiel Git et déploie son modèle dans le cloud via l'application administrateur. Examinons comment la fonction déployée sera appelée et prenons des décisions sur les demandes entrantes des clients :
- Le client remplit un formulaire sur le site Internet et adresse sa demande au responsable du traitement. Une demande sur laquelle une décision doit être prise arrive à l'entrée du système et est enregistrée dans la base de données sous sa forme originale.
- Ensuite, la requête brute est envoyée pour enrichissement, si nécessaire. Vous pouvez compléter la demande initiale avec des données provenant à la fois de services externes et du stockage. La requête enrichie résultante est également stockée dans la base de données.
- La fonction d'analyste est lancée, qui prend en entrée une requête enrichie et produit une solution, qui est également écrite dans le stockage.
Nous avons décidé d'utiliser MongoDB comme stockage dans notre système en raison du stockage des données orienté document sous forme de documents JSON, puisque les services d'enrichissement, y compris la demande d'origine, ont regroupé toutes les données via des contrôleurs REST.
Nous avons donc eu XNUMX heures pour mettre en œuvre la plateforme. Nous avons réparti les rôles avec assez de succès, chaque membre de l'équipe avait son propre domaine de responsabilité dans notre projet :
- Panneaux d'administration front-end pour le travail de l'analyste, grâce auxquels il pouvait télécharger des règles à partir du système de contrôle de version des scripts écrits, sélectionner des options pour enrichir les données d'entrée et éditer des scripts de règles en ligne.
- Administrateur backend, y compris API REST pour le front et intégration avec VCS.
- Mise en place d'une infrastructure dans Google Cloud et développement d'un service d'enrichissement des données sources.
- Un module d'intégration de l'application d'administration avec le framework Serverless pour un déploiement ultérieur de règles.
- Scripts de règles pour tester les performances de l'ensemble du système et agrégation d'analyses sur les applications entrantes (décisions prises) pour la démonstration finale.
Commençons par le début.
Notre interface a été écrite en Angular 7 à l'aide du kit d'interface utilisateur bancaire. La version finale du panneau d'administration ressemblait à ceci :
Comme nous disposions de peu de temps, nous avons essayé de mettre en œuvre uniquement les fonctionnalités clés. Pour déployer une fonction dans le cluster Kubernetes, il fallait sélectionner un événement (un service pour lequel une règle doit être déployée dans le cloud) et le code de la fonction qui implémente la logique décisionnelle. Pour chaque déploiement d'une règle pour le service sélectionné, nous avons rédigé un journal de cet événement. Dans le panneau d'administration, vous pouvez voir les journaux de tous les événements.
Tout le code de fonction était stocké dans un référentiel Git distant, qui devait également être défini dans le panneau d'administration. Pour versionner le code, toutes les fonctions ont été stockées dans différentes branches du référentiel. Le panneau d'administration offre également la possibilité d'apporter des ajustements aux scripts écrits, de sorte qu'avant de déployer une fonction en production, vous puissiez non seulement vérifier le code écrit, mais également apporter les modifications nécessaires.
En plus des fonctions de règles, nous avons également implémenté la possibilité d'enrichir progressivement les données sources à l'aide de fonctions d'enrichissement dont le code était également des scripts dans lesquels il était possible d'accéder à l'entrepôt de données, d'appeler des services tiers et d'effectuer des calculs préliminaires. . Pour démontrer notre solution, nous avons calculé le signe du zodiaque du client qui a laissé la demande et déterminé son opérateur mobile à l'aide d'un service REST tiers.
Le backend de la plateforme a été écrit en Java et implémenté en tant qu'application Spring Boot. Nous avions initialement prévu d'utiliser Postgres pour stocker les données d'administration, mais, dans le cadre du hackathon, nous avons décidé de nous limiter à un simple H2 afin de gagner du temps. Sur le backend, l'intégration avec Bitbucket a été mise en œuvre pour versionner les fonctions d'enrichissement des requêtes et les scripts de règles. Pour l'intégration avec les référentiels Git distants, nous avons utilisé , qui est une sorte de wrapper sur les commandes CLI, vous permettant d'exécuter n'importe quelle instruction git à l'aide d'une interface logicielle pratique. Nous avions donc deux référentiels distincts pour les fonctions et les règles d'enrichissement, et tous les scripts étaient divisés en répertoires. Grâce à l'interface utilisateur, il était possible de sélectionner le dernier commit d'un script d'une branche arbitraire du référentiel. Lors de la modification du code via le panneau d'administration, les validations du code modifié ont été créées dans des référentiels distants.
Pour mettre en œuvre notre idée, nous avions besoin d’une infrastructure adaptée. Nous avons décidé de déployer notre cluster Kubernetes dans le cloud. Notre choix s'est porté sur Google Cloud Platform. Le framework sans serveur Fission a été installé sur un cluster Kubernetes, que nous avons déployé dans Gcloud. Initialement, le service d'enrichissement des données sources était implémenté en tant qu'application Java distincte enveloppée dans un pod à l'intérieur du cluster k8s. Mais après une démonstration préliminaire de notre projet au milieu du hackathon, il nous a été recommandé de rendre le service d'enrichissement plus flexible pour offrir la possibilité de choisir comment enrichir les données brutes des applications entrantes. Et nous n'avions pas d'autre choix que de rendre le service d'enrichissement également sans serveur.
Pour travailler avec Fission, nous avons utilisé la CLI Fission, qui doit être installée au-dessus de la CLI Kubernetes. Le déploiement de fonctions dans un cluster k8s est assez simple : il vous suffit d'attribuer une route interne et une entrée à la fonction pour autoriser le trafic entrant si un accès en dehors du cluster est nécessaire. Le déploiement d’une fonction ne prend généralement pas plus de 10 secondes.
Présentation finale du projet et synthèse
Pour démontrer le fonctionnement de notre système, nous avons placé un formulaire simple sur un serveur distant où vous pouvez soumettre une demande pour l’un des produits de la banque. Pour demander, vous deviez saisir vos initiales, votre date de naissance et votre numéro de téléphone.
Les données du formulaire client ont été transmises au responsable du traitement, qui a simultanément envoyé des demandes pour toutes les règles disponibles, après avoir préalablement enrichi les données selon les conditions spécifiées, et les a enregistrées dans un stockage commun. Au total, nous avons déployé trois fonctions qui prennent des décisions sur les candidatures entrantes et 4 services d'enrichissement des données. Après avoir soumis la candidature, le client a reçu notre décision :
En plus du refus ou de l'approbation, le client a également reçu une liste d'autres produits, pour lesquels nous avons envoyé des demandes en parallèle. C'est ainsi que nous avons démontré la possibilité de vente croisée dans notre plateforme.
Il y avait au total 3 produits bancaires fictifs disponibles :
- Crédit.
- Jouet
- Hypothèque.
Au cours de la démonstration, nous avons déployé des fonctions préparées et des scripts d'enrichissement pour chaque service.
Chaque règle nécessitait son propre ensemble de données d'entrée. Ainsi, pour approuver un prêt hypothécaire, nous avons calculé le signe du zodiaque du client et l’avons relié à la logique du calendrier lunaire. Pour approuver un jouet, nous avons vérifié que le client avait atteint l'âge de la majorité, et pour émettre un prêt, nous avons envoyé une demande à un service ouvert externe pour déterminer l'opérateur cellulaire, et une décision a été prise à ce sujet.
Nous avons essayé de rendre notre démonstration intéressante et interactive, toutes les personnes présentes pouvaient accéder à notre formulaire et vérifier la disponibilité de nos services fictifs. Et à la toute fin de la présentation, nous avons présenté une analyse des candidatures reçues, qui a montré combien de personnes ont utilisé notre service, le nombre d'approbations et de refus.
Pour collecter des analyses en ligne, nous avons également déployé un outil BI open source et je l'ai vissé à notre unité de stockage. Metabase vous permet de créer des écrans avec des analyses sur les données qui nous intéressent ; il vous suffit d'enregistrer une connexion à la base de données, de sélectionner des tables (dans notre cas, des collections de données, puisque nous utilisons MongoDB) et de spécifier les champs qui nous intéressent. .
En conséquence, nous avons obtenu un bon prototype de plateforme de prise de décision, et lors de la démonstration, chaque auditeur a pu vérifier personnellement ses performances. Une solution intéressante, un prototype terminé et une démonstration réussie nous ont permis de gagner, malgré une forte concurrence des autres équipes. Je suis sûr qu’un article intéressant peut également être écrit sur le projet de chaque équipe.
Source: habr.com