Linha fina: Grupo Movile se destaca na terceira edição de 2018 da Qcon São Paulo, um dos maiores eventos de tecnologia do Brasil, apresentando a ferramenta Apache Spark.
O QCon São Paulo é um dos maiores eventos de tecnologia do Brasil e um dos poucos voltado para um público mais sênior. No qual encontram-se as melhores empresas do país, trazendo seus cases. Bem como, palestrantes internacionais de instituições de renome de extrema importância.
Representando o Grupo Movile, O Coordenador de Tecnologia da Wavy Eiti Kimura, apresentou a palestra “Analisador de dados Automatizado utilizando Machine Learning”. Mostrando como a Wavy utiliza análises de dados e Machine Learning para monitorar sistemas distribuídos, gerando impacto financeiro direto.
Os participantes tiveram a oportunidade de conhecer a ferramenta Apache Spark utilizada para empregar algoritmos de Machine Learning, gerando modelos capazes de fazer a análise dos dados automaticamente. Identificando problemas e notificando os times responsáveis.
Foi possível identificar como empregar com sucesso modelos de regressão linear com árvores de decisão. O que possibilita prever os valores de números de transações com sucesso e erros. E a partir disso, determinar se os valores das séries temporais funcionam de acordo com o esperado.
Vem com a gente e entenda o que foi abordado na palestra:
Um pouco sobre a Wavy:
A Wavy possui negócios e produtos com operadoras de telefonia móvel no Brasil e demais países da América Latina. Os clientes são tarifados de forma recorrente pelas assinaturas desses produtos. Em média, geramos em torno de 150 milhões de transações de tentativas de tarifação por dia. Todo esse ecossistema é composto de uma gama de sistemas distribuídos de alto desempenho que funcionam 24h por dia.
Porque a ferramenta Apache Spark?
Utilizamos a ferramenta Apache Spark para empregar algoritmos de Machine Learning, gerando modelos capazes de fazer a análise dos dados automaticamente, dessa forma, conseguindo identificar se temos algum problema em nossos serviços e notificando os times responsáveis. Nessa abordagem, empregamos com sucesso modelos de regressão linear com árvores de decisão, para conseguir prever os valores de números de transações com sucesso, erros e dessa forma, poder determinar se os valores de nossas séries temporais estavam funcionando de acordo com o esperado.
O desafio da Wavy
Na Wavy, existem diversos produtos e serviços, dentre eles: assinatura junto às operadoras de telefonia móvel, tais como, entrega de conteúdo rico no celular, acesso a aplicações móveis, jogos e etc.
As plataformas tratam as assinaturas, a criação e cancelamento dos produtos. E também, o controle do ciclo de renovação, que em termos práticos, significa a cobrança do cliente em sua operadora de telefonia celular.
Essas plataformas funcionam de forma distribuída, ou seja, em diversos computadores diferentes, inclusive em localidades distintas. Seus principais requisitos são: alto desempenho e disponibilidade. Há um grau de criticidade grande envolvido na manutenção operacional das plataformas, pois em caso de indisponibilidade de alguma parte, podemos ficar sem cobrar os usuários, afetando diretamente o faturamento da área como um todo.
Dado esse cenário, temos dois desafios:
- Saber se a plataforma está funcionando corretamente; e
- Identificar problemas com os produtos e operadora de forma automatizada.
Antes da solução que apresentamos aqui, as análises eram efetuadas manualmente sobre um conjunto de dados consolidados, provenientes do funcionamento da plataforma de tarifação,
veja a Tabela 1 abaixo:
Tabela 1. Dados de tentativas de tarifação consolidados para análise
Temos um identificador da operadora (carrier_weigth), a faixa de horários da análise, por exemplo das 0h até as 20h (date_time), algumas informações da operação, como: tempo de resposta da operadora (avg response time), requisições de cobranças com sucesso (succ. charges), número de tentativa de cobrança onde o usuário não possuía crédito suficiente (no credit), erros retornados pela plataforma ou pela operadora (general errors) e o número total de tentativas de cobranças (total attempts).
A análise era realizada comparando-se os dados do dia atual, com os dados dos dias anteriores na média, como mostrado na tabela acima, e não tínhamos um método formal para fazer essa análise. Caso o analista julgasse que os dados eram de alguma forma discrepantes, então iniciavam-se as investigações por problemas na plataforma.
Nossos objetivos com o projeto foram:
-
- Determinar se a plataforma distribuída estava funcionando adequadamente baseado somente em análise de dados
- Criar uma forma de analisar esses dados automaticamente de forma sistematizada
Em nossa abordagem, preparamos os dados da Tabela 1 para alimentar algoritmos de Machine Learning para experimentar sua capacidade de prever um determinado número contínuo, em nosso caso, queremos prever o número de sucessos de tarifação e o número esperado de tentativas de tarifação dado uma operadora, hora do dia e assim por diante.
Aprendizado Supervisionado é a categoria de problemas de Machine Learning, quando sabemos o que queremos prever, temos os chamados dados rotulados nas nossas amostras. Dentro desse tipo de aprendizado, quando queremos trabalhar para prever números contínuos, em geral, trabalhamos com regressões lineares. Baseado nisso, testamos algumas implementações de algoritmos regressores que o Apache Spark já disponibiliza. Fizemos os testes mudando alguns regularizadores. O resultado do desempenho dos algoritmos pode ser observado na Tabela 2 abaixo:
Tabela 2. Desempenho dos algoritmos regressores do Apache Spark
Na Tabela 2 temos as medidas de erro e acurácia dos algoritmos. O critério de avaliação para medir o erro foi a RMSE (Root Mean Square Error), já conhecido para medir desempenho dos algoritmos regressores. A acurácia reflete a capacidade do algoritmo de prever o valor para o número de sucessos, no nosso caso, consideramos uma variação de +/- 15% para considerar que o algoritmo acertou o valor esperado. Todo código da experimentação prática para chegar a esses resultados podem ser replicados através do spark-notebook disponível nesse repositório.
De acordo com os resultados apresentados na Tabela 2, o modelo de árvore de decisão com regressão linear (Decision Tree Model), foi o modelo com o menor erro e também com a maior capacidade de prever os valores, ou seja, acurácia.
Com 93% de acurácia, decidimos colocar o modelo em produção para fazer as análises automaticamente. O modelo serializado com Apache Spark dá bastante flexibilidade de trabalho, os modelos foram treinados em linguagem Scala, entretanto, para usá-lo , podemos escolher entre as linguagens suportadas pelo Apache Spark: Scala, Java, Python e para alguns casos até mesmo R.
Nós batizamos o projeto inicialmente de Watcher-AI. A implantação ocorreu em duas fases distintas. A primeira de treinamento do modelo. A segunda de implantação do modelo onde expomos como um pequeno micro serviço.
Com essa interface de previsões exposta, fizemos então que de hora em hora, os dados fossem coletados de nossas bases de produção e comparamos o valor corrente de tentativas de tarifação, número de sucessos, número de erros e tempos de resposta previstos pelo nosso modelo. Os detalhes da solução arquitetural podem ser observados na Figura 1.
Figura 1. Arquitetura da solução Watcher-AI
Os dados são coletados de nossas bases, treinamos os modelos no Apache Spark. Os modelos são expostos via uma API chamada de Nostradamus, o Watcher-AI por sua vez funciona a cada hora obtendo os dados atuais dos indicadores das plataformas e caso necessário envia mensagens de notificação usando diferentes tipos de canais de comunicação.
Caso o Watcher-AI detecte um valor muito discrepante entre o esperado e o medido, em geral maior que um limiar definido (exemplo: erro maior que 15%), o sistema envia uma série de notificações informando o problema e dando alguns dados adicionais para auxiliar nas investigações.
O sistema foi integrado com uma série de diferentes canais de comunicação, como ferramenta de chat interna da empresa, como o Slack, envio de notificações por push e até envio de mensagens via SMS. Dependendo do problema detectado diferentes times, são acionados e notificados via o canal mais adequado, por exemplo, problema com a operadora, notificamos o time de suporte, problema com a plataforma, número baixo de tentativas, notificamos o time de desenvolvimento e assim por diante.
E como são essas mensagens de notificação do Watcher-AI? As pessoas tem curiosidade de saber. Essas mensagens são programadas, não temos inteligência artificial envolvida.
Nas mensagens colocamos informações sobre o problema, valores medidos e esperados, erro calculado de forma a auxiliar na análise e diagnóstico do problema. Na Figura 2 mostramos o conteúdo de uma mensagem de exemplo, em cada canal de comunicação a mensagem vai se apresenta em formatos distintos, porém o conteúdo se mantém.
Figura 2. Exemplo de conteúdo de uma mensagem de notificação do sistema
Com os resultados práticos desse trabalho, conseguimos treinar um modelo capaz de prever nosso principais indicadores das plataformas. Esse modelo está sendo utilizado em produção no momento com alto impacto financeiro. Uma série de problemas foram descobertos, o sistema agora avisa quando algum número não está na faixa esperada e temos muito mais agilidade na detecção do problema, assim como na atuação para correção do problema. Em quase 3 anos de funcionamento, estimamos uma economia em custos por volta de 2 milhões de dólares.
Caso queira saber mais detalhes e acessar os slides que apresentei no QConSP 2018, basta clicar aqui.
Dica: tem uma talk também disponível onde apresento alguns pontos da solução:
Have Fun!
#GoMovile
#GoWavy
