A partir do ano passado, nossa empresa começou a organizar hackathons. A primeira dessas competições foi um grande sucesso, escrevemos sobre isso em . O segundo hackathon ocorreu em fevereiro de 2019 e não teve menos sucesso. Sobre os objetivos de realizar este último há não muito tempo organizador.
Os participantes receberam uma tarefa bastante interessante com total liberdade na escolha de uma pilha de tecnologia para sua implementação. Era necessário implementar uma plataforma de tomada de decisão para implantação conveniente de funções de pontuação de clientes que pudessem funcionar com um fluxo rápido de aplicativos, suportar cargas pesadas e que o próprio sistema fosse facilmente escalonável.
A tarefa não é trivial e pode ser resolvida de várias maneiras, como nos convencemos durante a demonstração das apresentações finais dos projetos dos participantes. Eram 6 equipes de 5 pessoas no hackathon, todos os participantes tiveram bons projetos, mas nossa plataforma acabou sendo a mais competitiva. Temos um projeto muito interessante, sobre o qual gostaria de falar neste artigo.
Nossa solução é uma plataforma baseada na arquitetura Serverless dentro do Kubernetes, o que reduz o tempo necessário para trazer novos recursos para produção. Ele permite que os analistas escrevam código em um ambiente conveniente para eles e o implantem na produção sem a participação de engenheiros e desenvolvedores.
O que é pontuação
Tinkoff.ru, como muitas empresas modernas, tem pontuação de clientes. Scoring é um sistema de avaliação de clientes baseado em métodos estatísticos de análise de dados.
Por exemplo, um cliente recorre a nós com um pedido de concessão de um empréstimo ou de abertura de uma conta de empresário individual conosco. Se planejamos conceder-lhe um empréstimo, precisamos avaliar sua solvência e, se a conta for de um empresário individual, precisamos ter certeza de que o cliente não realizará transações fraudulentas.
A base para tomar tais decisões são modelos matemáticos que analisam tanto os dados da própria aplicação quanto os dados do nosso armazenamento. Além da pontuação, métodos estatísticos semelhantes também podem ser utilizados no serviço de geração de recomendações individuais de novos produtos para nossos clientes.
O método dessa avaliação pode aceitar uma variedade de dados de entrada. E em algum momento podemos adicionar um novo parâmetro à entrada, que, com base nos resultados da análise dos dados históricos, aumentará a taxa de conversão de utilização do serviço.
Possuímos uma grande quantidade de dados sobre o relacionamento com os clientes e o volume dessas informações está em constante crescimento. Para que a pontuação funcione, o processamento de dados também requer regras (ou modelos matemáticos) que permitem decidir rapidamente quem aprovará um pedido, quem recusará e quem oferecerá mais alguns produtos, avaliando seu potencial interesse.
Para a tarefa em questão, já utilizamos um sistema especializado de tomada de decisão , que, com base nas regras estabelecidas por analistas, tecnólogos e desenvolvedores, decide se aprova ou recusa determinado produto bancário ao cliente.
Existem muitas soluções prontas no mercado, tanto modelos de pontuação quanto sistemas de tomada de decisão propriamente ditos. Usamos um desses sistemas em nossa empresa. Mas o negócio está a crescer, a diversificar-se, tanto o número de clientes como o número de produtos oferecidos estão a aumentar e, com isso, surgem ideias sobre como melhorar o processo de tomada de decisão existente. Certamente as pessoas que trabalham com o sistema existente têm muitas ideias sobre como torná-lo mais simples, melhor e mais conveniente, mas às vezes ideias externas são úteis. O New Hackathon foi organizado com o objetivo de coletar ideias sólidas.
Tarefa
O hackathon foi realizado em 23 de fevereiro. Foi oferecida aos participantes uma tarefa de combate: desenvolver um sistema de tomada de decisão que tivesse que atender a uma série de condições.
Fomos informados de como funciona o sistema existente e quais as dificuldades que surgem durante o seu funcionamento, bem como quais os objetivos de negócio que a plataforma desenvolvida deve perseguir. O sistema deve ter um tempo de lançamento rápido no mercado para o desenvolvimento de regras, para que o código funcional dos analistas entre em produção o mais rápido possível. E para o fluxo de entrada de inscrições, o tempo de tomada de decisão deve tender ao mínimo. Além disso, o sistema que está sendo desenvolvido deve ter capacidade de venda cruzada, a fim de dar ao cliente a oportunidade de adquirir outros produtos da empresa, caso sejam aprovados por nós e tenham potencial interesse do cliente.
É claro que é impossível escrever da noite para o dia um projeto pronto para lançamento que certamente entrará em produção, e é bastante difícil cobrir todo o sistema, por isso fomos solicitados a implementar pelo menos parte dele. Foram estabelecidos vários requisitos que o protótipo deve satisfazer. Foi possível tentar cobrir todos os requisitos na sua totalidade e trabalhar detalhadamente em secções individuais da plataforma que está a ser desenvolvida.
Quanto à tecnologia, todos os participantes tiveram total liberdade de escolha. Foi possível utilizar quaisquer conceitos e tecnologias: Data streaming, machine learning, event sourcing, big data e outros.
Nossa solução
Após um pequeno brainstorming, decidimos que uma solução FaaS seria ideal para completar a tarefa.
Para esta solução foi necessário encontrar um framework Serverless adequado para implementar as regras do sistema de tomada de decisão em desenvolvimento. Como a Tinkoff usa ativamente o Kubernetes para gerenciamento de infraestrutura, analisamos várias soluções prontas baseadas nele; contarei mais sobre isso mais tarde.
Para encontrar a solução mais eficaz, analisamos o produto que está sendo desenvolvido através dos olhos de seus usuários. Os principais usuários do nosso sistema são analistas envolvidos no desenvolvimento de regras. As regras devem ser implantadas no servidor, ou, como no nosso caso, implantadas na nuvem, para posterior tomada de decisão. Da perspectiva de um analista, o fluxo de trabalho é assim:
- O analista escreve um script, uma regra ou um modelo de ML com base nos dados do warehouse. Como parte do hackathon, decidimos usar o Mongodb, mas a escolha do sistema de armazenamento de dados não é importante aqui.
- Após testar as regras desenvolvidas nos dados históricos, o analista carrega seu código no painel de administração.
- Para garantir o versionamento, todo o código irá para os repositórios Git.
- Através do painel de administração será possível implantar o código na nuvem como um módulo funcional separado sem servidor.
Os dados iniciais dos clientes devem passar por um serviço especializado de Enriquecimento projetado para enriquecer a solicitação inicial com dados do warehouse. Era importante implementar este serviço de forma que funcionasse com um único repositório (do qual o analista retira os dados ao desenvolver regras) para manter uma estrutura de dados unificada.
Mesmo antes do hackathon, decidimos qual framework Serverless usaríamos. Hoje existem muitas tecnologias no mercado que implementam essa abordagem. As soluções mais populares dentro da arquitetura Kubernetes são Fission, Open FaaS e Kubeless. Existem até .
Depois de pesar todos os prós e contras, escolhemos . Esta estrutura Serverless é bastante fácil de gerenciar e atende aos requisitos da tarefa.
Para trabalhar com Fissão, você precisa entender dois conceitos básicos: função e ambiente. Uma função é um trecho de código escrito em uma das linguagens para a qual existe um ambiente Fission. inclui Python, JS, Go, JVM e muitas outras linguagens e tecnologias populares.
O Fission também é capaz de executar funções divididas em vários arquivos, pré-empacotados em um arquivo. O funcionamento do Fission num cluster Kubernetes é assegurado por pods especializados, que são geridos pelo próprio framework. Para interagir com pods de cluster, cada função deve receber sua própria rota e para a qual você pode passar parâmetros GET ou corpo da solicitação no caso de uma solicitação POST.
Como resultado, planejamos obter uma solução que permitiria aos analistas implantar scripts de regras desenvolvidos sem a participação de engenheiros e desenvolvedores. A abordagem descrita também elimina a necessidade dos desenvolvedores reescreverem o código do analista em outra linguagem. Por exemplo, para o atual sistema de tomada de decisão que utilizamos, temos que escrever regras em tecnologias e linguagens altamente especializadas, cujo âmbito é extremamente limitado, e existe também uma forte dependência do servidor de aplicação, uma vez que todos os projetos de regras bancárias são implantados em um único ambiente. Com isso, para implantar novas regras é necessário liberar todo o sistema.
Na nossa solução proposta, não há necessidade de liberar regras; o código pode ser facilmente implantado com o clique de um botão. Além disso, o gerenciamento de infraestrutura no Kubernetes permite que você não pense em carga e escalonamento; esses problemas são resolvidos imediatamente. E a utilização de um único data warehouse elimina a necessidade de comparar dados em tempo real com dados históricos, o que simplifica o trabalho do analista.
O que conseguimos
Como chegamos ao hackathon com uma solução pronta (em nossas fantasias), tudo o que tivemos que fazer foi converter todos os nossos pensamentos em linhas de código.
A chave para o sucesso em qualquer hackathon é a preparação e um plano bem escrito. Portanto, a primeira coisa que fizemos foi decidir em quais módulos consistiria a arquitetura do nosso sistema e quais tecnologias usaríamos.
A arquitetura do nosso projeto foi a seguinte:
Este diagrama mostra dois pontos de entrada, o analista (o principal usuário do nosso sistema) e o cliente.
O processo de trabalho está estruturado assim. O analista desenvolve uma função de regra e uma função de enriquecimento de dados para seu modelo, armazena seu código em um repositório Git e implanta seu modelo na nuvem por meio do aplicativo administrador. Vamos considerar como a função implantada será chamada e tomar decisões sobre as solicitações recebidas dos clientes:
- O cliente preenche um formulário no site e envia sua solicitação ao controlador. Uma aplicação sobre a qual é necessário tomar uma decisão chega à entrada do sistema e é registrada no banco de dados em sua forma original.
- A seguir, a solicitação bruta é enviada para enriquecimento, se necessário. Você pode complementar a solicitação inicial com dados de serviços externos e de armazenamento. A consulta enriquecida resultante também é armazenada no banco de dados.
- É lançada a função de analista, que recebe uma consulta enriquecida como entrada e produz uma solução, que também é gravada no armazenamento.
Decidimos utilizar o MongoDB como armazenamento em nosso sistema devido ao armazenamento de dados orientado a documentos na forma de documentos JSON, uma vez que os serviços de enriquecimento, incluindo a solicitação original, agregavam todos os dados por meio de controladores REST.
Então tivemos XNUMX horas para implementar a plataforma. Distribuímos as funções com bastante sucesso, cada membro da equipe tinha sua área de responsabilidade em nosso projeto:
- Painéis de administração front-end para o trabalho do analista, por meio dos quais ele poderia baixar regras do sistema de controle de versão de scripts escritos, selecionar opções para enriquecer os dados de entrada e editar scripts de regras online.
- Administração de backend, incluindo API REST para front e integração com VCS.
- Configuração de infraestrutura no Google Cloud e desenvolvimento de serviço para enriquecimento dos dados de origem.
- Um módulo para integração do aplicativo administrativo com a estrutura Serverless para posterior implantação de regras.
- Scripts de regras para teste de desempenho de todo o sistema e agregação de análises sobre aplicações recebidas (decisões tomadas) para demonstração final.
Vamos começar desde o início.
Nosso frontend foi escrito em Angular 7 usando o UI Kit bancário. A versão final do painel de administração ficou assim:
Como havia pouco tempo, tentamos implementar apenas as funcionalidades principais. Para implantar uma função no cluster Kubernetes, foi necessário selecionar um evento (serviço para o qual uma regra precisa ser implantada na nuvem) e o código da função que implementa a lógica de tomada de decisão. Para cada implantação de uma regra para o serviço selecionado, escrevemos um log desse evento. No painel de administração você pode ver os logs de todos os eventos.
Todo o código da função foi armazenado em um repositório Git remoto, que também teve que ser configurado no painel de administração. Para versionar o código, todas as funções foram armazenadas em diferentes ramos do repositório. O painel de administração também oferece a capacidade de fazer ajustes em scripts escritos, para que antes de implantar uma função na produção, você possa não apenas verificar o código escrito, mas também fazer as alterações necessárias.
Além das funções de regras, também implementamos a capacidade de enriquecer gradativamente os dados de origem por meio de funções de enriquecimento, cujo código também eram scripts nos quais era possível ir ao data warehouse, chamar serviços de terceiros e realizar cálculos preliminares . Para demonstrar nossa solução, calculamos o signo do zodíaco do cliente que deixou a solicitação e determinamos sua operadora móvel por meio de um serviço REST de terceiros.
O backend da plataforma foi escrito em Java e implementado como uma aplicação Spring Boot. Inicialmente planejamos usar o Postgres para armazenar dados administrativos, mas, como parte do hackathon, decidimos nos limitar a um simples H2 para economizar tempo. No backend, foi implementada integração com Bitbucket para versionar as funções de enriquecimento de consultas e scripts de regras. Para integração com repositórios Git remotos, usamos , que é uma espécie de wrapper sobre comandos CLI, permitindo executar qualquer instrução git usando uma interface de software conveniente. Portanto, tínhamos dois repositórios separados para funções e regras de enriquecimento, e todos os scripts foram divididos em diretórios. Através da UI foi possível selecionar o último commit de um script de uma ramificação arbitrária do repositório. Ao fazer alterações no código através do painel de administração, os commits do código alterado foram criados em repositórios remotos.
Para implementar a nossa ideia, precisávamos de infraestrutura adequada. Decidimos implantar nosso cluster Kubernetes na nuvem. Nossa escolha foi o Google Cloud Platform. A estrutura serverless Fission foi instalada em um cluster Kubernetes, que implantamos no Gcloud. Inicialmente, o serviço de enriquecimento de dados de origem foi implementado como um aplicativo Java separado, agrupado em um pod dentro do cluster k8s. Mas depois de uma demonstração preliminar do nosso projeto no meio do hackathon, fomos recomendados a tornar o serviço de enriquecimento mais flexível para fornecer a oportunidade de escolher como enriquecer os dados brutos dos aplicativos recebidos. E não tivemos escolha a não ser tornar o serviço de enriquecimento também Serverless.
Para trabalhar com Fission, usamos o Fission CLI, que deve ser instalado sobre o Kubernetes CLI. A implantação de funções em um cluster k8s é bastante simples; você só precisa atribuir uma rota interna e entrada à função para permitir o tráfego de entrada se for necessário acesso fora do cluster. A implantação de uma função normalmente não leva mais de 10 segundos.
Apresentação final do projeto e resumo
Para demonstrar como funciona o nosso sistema, colocamos um formulário simples num servidor remoto onde você pode enviar uma solicitação para um dos produtos do banco. Para solicitar, era necessário inserir suas iniciais, data de nascimento e número de telefone.
Os dados do formulário do cliente iam para o controlador, que enviava simultaneamente os pedidos de todas as regras disponíveis, tendo previamente enriquecido os dados de acordo com as condições especificadas, e guardados num armazenamento comum. No total, implantamos três funções que tomam decisões sobre aplicações recebidas e 4 serviços de enriquecimento de dados. Após enviar a inscrição, o cliente recebeu nossa decisão:
Além da recusa ou aprovação, o cliente também recebeu uma lista de outros produtos, cujos pedidos enviamos paralelamente. Foi assim que demonstramos a possibilidade de venda cruzada em nossa plataforma.
Havia um total de 3 produtos bancários fictícios disponíveis:
- Crédito.
- Brinquedo
- Hipoteca.
Durante a demonstração, implantamos funções preparadas e scripts de enriquecimento para cada serviço.
Cada regra exigia seu próprio conjunto de dados de entrada. Assim, para aprovar uma hipoteca, calculamos o signo do zodíaco do cliente e relacionamos isso com a lógica do calendário lunar. Para aprovar um brinquedo, verificamos se o cliente atingiu a maioridade e, para emitir um empréstimo, enviamos uma solicitação a um serviço aberto externo para determinar a operadora de celular, e foi tomada uma decisão sobre isso.
Procurámos tornar a nossa demonstração interessante e interactiva, todos os presentes puderam aceder ao nosso formulário e verificar a disponibilidade dos nossos serviços fictícios para eles. E ao final da apresentação demonstramos análises das inscrições recebidas, que mostraram quantas pessoas utilizaram nosso serviço, a quantidade de aprovações e recusas.
Para coletar análises on-line, implantamos adicionalmente uma ferramenta de BI de código aberto e parafusamos em nossa unidade de armazenamento. A Metabase permite construir telas com análises sobre os dados que nos interessam, bastando cadastrar uma conexão com o banco de dados, selecionar tabelas (no nosso caso, coletas de dados, já que utilizamos MongoDB) e especificar os campos de nosso interesse .
Como resultado, obtivemos um bom protótipo de plataforma de tomada de decisão e, durante a demonstração, cada ouvinte pôde verificar pessoalmente seu desempenho. Uma solução interessante, um protótipo finalizado e uma demonstração bem sucedida permitiram-nos vencer, apesar da forte concorrência de outras equipas. Tenho certeza que um artigo interessante também pode ser escrito sobre o projeto de cada equipe.
Fonte: habr.com