Universidade Federal do Rio Grande do Norte Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada Bacharelado em Engenharia de Software
Arquitetura Baseada em Microsserviços para
Classificação de Dados
José Lucas Santos Ribeiro
Natal-RN Novembro de 2018
Ribeiro, José Lucas Santos.
Arquitetura baseada em microsserviços para classificação de dados / José Lucas Santos Ribeiro. - 2018.
54f.: il.
Monografia (Bacharelado em Engenharia de Software)
-Universidade Federal do Rio Grande do Norte, Centro de Ciências Exatas e da Terra, Departamento de Informática e Matemática Aplicada, Curso de Engenharia de Software. Natal, 2018. Orientador: Nélio Alessandro Azevedo Cacho.
1. Engenharia de software - Monografia. 2. Sistemas
distribuídos - Monografia. 3. Microsserviços - Monografia. 4. Arquitetura - Monografia. 5. Docker - Monografia. 6. Machine learning - Monografia. 7. Transfer learning - Monografia. I. Cacho, Nélio Alessandro Azevedo. II. Título.
RN/UF/CCET CDU 004.41
Universidade Federal do Rio Grande do Norte - UFRN Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
José Lucas Santos Ribeiro
Arquitetura Baseada em Microsserviços para
Classificação de Dados
Proposta de Monografia de Graduação apre-sentada ao Departamento de Informática e Matemática Aplicada (DIMAp) da Universi-dade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de bacharel em Engenharia de Software.
Orientador
Prof. Dr. Nélio Alessandro Azevedo Cacho
Universidade Federal do Rio Grande do Norte – UFRN Departamento de Informática e Matemática Aplicada - DIMAp
Natal-RN Novembro de 2018
Monografia de graduação sob o título Arquitetura Baseada em Microsserviços para Clas-sificação de Dados apresentada por José Lucas Santos Ribeiro e aceita pelo Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especificada:
Prof. Dr. Nélio Alessandro Azevedo Cacho
Orientador
Departamento de Informática e Matemática Aplicada Universidade Federal do Rio Grande do Norte
Prof. Dr. Frederico Araújo da Silva Lopes
Co-Orientador
Instituto Metrópole Digital
Universidade Federal do Rio Grande do Norte
Prof. Dr. Daniel Sabino Amorim de Araújo
Examinador
Instituto Metrópole Digital
Universidade Federal do Rio Grande do Norte
Dedico este trabalho aos meus pais, Eleonora Nascimento e Alcione Ribeiro, que são a minha base e o motivo de eu ser quem eu sou hoje.
Agradecimentos
Agradeço à Eleonora Nascimento, Alcione Ribeiro, Ana Luiza Ribeiro e Ana Paula Fernandes, minha família, pelo amor, suporte e apoio que me prestaram na minha jornada. Agradeço ao professor Nélio Cacho, que desde 2014 é meu orientador e, se não fosse por ele, não teria aprendido muitas coisas importantes para minha carreira e nem me tornado o profissional que sou atualmente.
Agradeço à todos os professores do meu curso, que me concederam muito conheci-mento, e agradeço especialmente aos professores Frederico Lopes e Everton Cavalcante, que fizeram parte da minha orientação no Projeto Smart Metropolis e me auxiliaram sempre que precisei.
Agradeço aos meus grandes amigos Adelson Dias, Mickael Figueredo e Lucio Soares pelo companheirismo, pelos vários momentos de felicidade que me proporcionaram e por toda a ajuda que me forneceram.
Agradeço à Universidade Federal do Rio Grande do Norte, pela educação de qualidade, pelas inúmeras oportunidades que me foram oferecidas e por todo o ambiente que me foi disponibilizado para auxiliar os meus estudos.
Cada sonho que você deixa pra trás, é um pedaço do seu futuro que deixa de existir. Steve Jobs
Arquitetura Baseada em Microsserviços para
Classificação de Dados
Autor: José Lucas Santos Ribeiro Orientador: Prof. Dr. Nélio Alessandro Azevedo Cacho
Resumo
Soluções inteligentes para classificação de dados que fazem uso de Machine Learning estão em um momento de ascensão. A área de análise de dados está atraindo cada vez mais desenvolvedores e pesquisadores, porém as soluções desenvolvidas precisam estar em um ambiente escalável e modularizado para serem fornecidas para uma grande quantidade de usuários. A partir dessa motivação, este trabalho propõe uma arquitetura genérica para classificação de dados, nomeada Machine Learning in Microservices Architecture (MLMA), que pode ser reproduzida em um ambiente de produção. Além disso é apre-sentado a utilização da arquitetura em um projeto que faz classificação multi-label de imagens para recomendar pontos turísticos ao usuário e um mapeamento da arquitetura em um projeto de análise de texto é introduzido.
Palavras-chave: Sistemas Distribuídos, Serviços, Microsserviços, Arquitetura, Docker, Ma-chine Learning, Deep Learning, Transfer Learning.
Microservice Based Architecture for Data Classification
Author: José Lucas Santos Ribeiro Advisor: Prof. Dr. Nélio Alessandro Azevedo Cacho
Abstract
Smart solutions for data classification data that make use of Deep Learning are in a mo-ment of ascension. The area of data analysis is attracting more and more developers and researchers, but the solutions developed need to be in a scalable and modularized environ-ment to be delivered to a large number of users. From this motivation, this work presents a generic architecture for data classification, named Machine Learning in Microservices Architecture (MLMA), that can be reproduced in a production environment. In addition, the use of the architecture is presented in a project that makes multi-label classification of images to recommend tourist attractions and a architecture mapping in a text analysis project is introduced.
Keywords: Distributed Systems, Services, Microservices, Architecture, Docker, Machine Learning, Deep Learning, Transfer Learning.
Lista de figuras
1 Relatório do Google Trends sobre Machine Learning e Deep Learning . p. 14 2 Sistema de Recomendação como uma Aplicação Monolítica . . . p. 18 3 Arquitetura Inicial . . . p. 19 4 Hello World com Flask . . . p. 20 5 Abstração do uso de uma CNN para classificar uma imagem . . . p. 21 6 Diagrama representando o carregamento de modelos durante uma
requi-sição . . . p. 22 7 Relatório do Google Trends sobre Microservices . . . p. 23 8 Abordagem monolítica e abordagem com microsserviços . . . p. 23 9 Virtualização vs Docker Container . . . p. 27 10 Arquitetura Genérica para classificação de dados. Os dados são enviados
pela API pelo componente Consumer, que ao final da análise receberá
a informação sobre a classificação. . . p. 32 11 Sistema de Recomendação mapeado na arquitetura genérica proposta.
Requisição iniciando pelo Consumer, que envia as fotos, logo após o Flow Controller Service requisita a análise das fotos, e com o resultado da análise gera informação para retornar para o Consumer a partir do
Fuzzy Service e Recommendation Service . . . p. 36 12 Exemplo do json recebido pelo Data Collector Service . . . p. 37 13 Processo de criação de threads para cada modelo utilizado na análise no
Data Analysis Service. . . p. 38 14 Utilizando NGINX como balanceador de carga e consumindo os processos
criados do Predict Service para carregar qualquer modelo durante uma
15 Tela de login . . . p. 43 16 Tela de seleção de fotos . . . p. 43 17 Tela de resultado do perfil do usuário . . . p. 44 18 Tela de recomendações . . . p. 44 19 Fluxo passo a passo do Sistema de Validação. . . p. 45 20 Sistema de Análise de Sentimentos mapeado na MLMA. . . p. 46 21 Monitoramento do ambiente dos containers Docker. (Fonte: (ANDERSON,
Lista de tabelas
1 Média de tempo de resposta das requisições com 7 fotos . . . p. 20 2 Memória consumida com N processos do Features Service. . . p. 39 3 Média dos tempos de carregamento dos modelos. . . p. 40 4 Memória consumida com N processos do Predict Service. . . p. 40 5 Tempos de cada etapa para cada abordagem. . . p. 42
Lista de abreviaturas e siglas
ML – Machine Learning
IaaS – Infrastructure as a Service PaaS – Platform as a Service SaaS – Software as a Service
REST – Representational State Transfer API – Application Programming Interface POI – Points of Interest
CNN – Convolutional Neural Networks
MLMA – Machine Learning in Microservices Architecture DNN – Deep Neural Network
Sumário
1 Introdução p. 14
1.1 Organização do trabalho . . . p. 17
2 Servindo a Classificação de Fotos p. 18 2.1 Transfer Learning . . . p. 20 2.2 Arquiteturas Baseadas em Microsserviços . . . p. 22 2.3 Problemática . . . p. 24
3 Docker p. 26
3.1 Images . . . p. 27 3.2 Docker Compose . . . p. 28 3.3 Volume . . . p. 29
4 MLMA: Arquitetura e Instanciação p. 30 4.1 Machine Learning in Microservices Architecture . . . p. 30 4.1.1 Flow Controller Service e Post Processing Service . . . p. 31 4.1.2 Data Collector Service . . . p. 33 4.1.3 Data Analysis Service . . . p. 33 4.1.4 Preprocessing Service . . . p. 33 4.1.5 Features Service . . . p. 34 4.1.6 Predict Service . . . p. 34 4.2 Sistema de Recomendação mapeado na Arquitetura Genérica . . . p. 35 4.2.1 Flow Controller Service . . . p. 37
4.2.2 Data Collector Service . . . p. 37 4.2.3 Data Analysis Service . . . p. 38 4.2.4 Features Service . . . p. 39 4.2.5 Predict Service . . . p. 39 4.2.6 Fuzzy Service e Recommendation Service . . . p. 41 4.2.7 Tempos de processamento . . . p. 42 4.2.8 Sistema de Validação . . . p. 42 4.3 Classificação de textos mapeado na Arquitetura Genérica . . . p. 45
5 Trabalhos Relacionados p. 47
6 Considerações finais p. 49
6.1 Trabalhos futuros . . . p. 49
14
1
Introdução
Nos últimos anos, há uma onda de interesses em Machine Learning (ML) , como podemos verificar no relatório do Google Trends sobre o assunto na Figura 1, onde os números representam o interesse de pesquisa relativo ao ponto mais alto no gráfico, ou seja, um valor de 100 representa o pico de popularidade de um termo. Acompanhando essa tendência, as técnicas de Deep Learning, que são uma especificação das anteriormente citadas, tomam boa parte da atenção dos entusiastas. Assim, diversas soluções que fazem uso desta tecnologia estão surgindo constantemente, porém em alguns casos a necessidade de recurso computacional para realizar classificação de dados utilizando redes neurais pode ser alta, tornando inviável executar todo o processamento dos dados no lado do cliente.
Figura 1: Relatório do Google Trends sobre Machine Learning e Deep Learning
Com a necessidade de recursos computacionais remotos surge a ideia de Computação em Nuvem, ou Cloud Computing (ARMBRUST et al., 2010). Através desse paradigma, é possível que uma aplicação execute em um servidor remoto, ou seja, este servidor provê recursos e dados que podem ser acessados através de outros dispositivos quando necessário. Existem três tipos principais de serviços em nuvem: IaaS - Infrastructure as a Service, PaaS - Platform as a Service e SaaS - Software as a Service. Esses serviços são definidos por (MELL; GRANCE et al., 2011) como a capacidade do consumidor de :
15
• IaaS: utilizar processamento, armazenamento, redes e outros recursos computacio-nais que tornem possível a implantação de algum Software, podendo ser aplicações, sistemas operacionais ou outros.
• PaaS: implantar sua aplicação em uma infraestrutura de nuvem que suporte as tecnologias utilizadas sem precisar se preocupar com o controle da infraestrutura e configurações.
• SaaS: utilizar aplicações que estão funcionando em uma infraestrutura de nuvem. Por exemplo temos o Facebook, Youtube e Google.
Com esses conceitos introduzidos, este trabalho objetiva fornecer uma alternativa de modelagem para que aplicações que fazem classificação de dados sejam fornecidas à usuários como SaaS, ou melhor, Machine Learning as a Service, isto é, algoritmos de Machine Learning encapsulados por Representational State Transfer (REST), como proposto por (PAHL; LOIPFINGER, 2018). Assim, será possível fazer um processamento
remoto dos dados disponibilizados pelo usuário da aplicação. Nesse sentido, este trabalho foi motivado pela necessidade da criação de uma Application Programming Interface (API) para um sistema de recomendação de pontos turísticos (FIGUEREDO et al., 2018) que faz uso de dados de redes sociais.
Grande parte das informações e dados disponibilizados por meio de redes sociais possui aplicabilidade no cenário de planejamento de uma viagem para um destino desconhecido (BORRàS; MORENO; VALLS, 2014). De acordo com (LITVIN; GOLDSMITH; PAN, 2008), essa informação também é uma fonte substancial de informações estratégicas que podem ser usadas para desenvolver uma grande quantidade de estratégia de negócios, incluindo a capacidade de melhorar a descoberta de novas experiências por parte dos usuários.
A ideia do sistema de recomendação, citado anteriormente, é que a extração das fotos dos perfis seja feita por meio das APIs disponibilizadas pelas redes sociais mais utilizadas atualmente (Facebook e Instagram). O sistema recomenda, baseado em fotos oriundas de redes sociais dos usuários, Points of Interest (POI) que mais se adéquam aos locais e ambientes mais frequentados anteriormente pelos usuários. Os POI podem ser vistos como locais que o usuário possa ter interesse em visitar. Um componente de interface web, desenvolvido neste trabalho e apresentado mais à frente, busca as permissões dos usuários para iniciar o processo de análise do perfil. O objetivo central da análise das fotos é modelar o perfil dentro de classes turísticas.
16
razão de viagem. Entretanto, na literatura de turismo não existe um consenso no contexto de classificação e definição de tipos de turismo. Uma série de topologias são propostas (LOHMANN, 2017; WICKENS, 2002) variando na capacidade de generalização das classes em seus locais de aplicação. Dessa forma, o sistema de recomendação utiliza a topologia proposta por (IGNARRA, 1999) para sobrepor a variações culturais de diferentes contextos, provendo classes genéricas para os tipos de turismo e classificando um turista usando a seguinte topologia: Landscape, Historical/Cultural, Shopping, Urban e Adventure.
As fotos são classificadas dentre 25 classes de ambientes por meio de 25 classificadores de ambientes binários. A abordagem permite uma maior escalabilidade ao sistema de recomendação, além de prover uma classificação multilabel das imagens (FIGUEREDO et al., 2018). Um algoritmo de Deep Learning foi utilizado para criar classificadores robustos capazes de generalizar os dados utilizados no treinamento, provendo acurácia superior à 85% na classificação. O Resultado da classificação das fotos do perfil é enviada para um módulo de classificação fuzzy que irá reduzir e mapear as preferências do turista dentro das classes Landscape, Historical/Cultural, Shopping, Urban and Adventure. A recomendação então é simplificada devido a redução de dimensionalidade das informações inicialmente representadas como fotos.
Por fim, uma abordagem baseada em conhecimento (JANNACH; ZANKER; JESSENITS-CHNIG, 2009) é utilizada para gerar as recomendações de POI s para cada perfil. Na
abor-dagem, a recomendação das atrações sugeridas é baseada no conhecimento sobre usuá-rios, itens e relacionamento entre eles. As atrações turísticas que alimentam a base dados da plataforma são classificadas no mesmo domínio que o perfil do turista, ou seja, nas mesmas classes descritas por (IGNARRA, 1999). Essa abordagem utilizada pelo sistema
de recomendação da plataforma permite evitar o problema conhecido como Cold-Start (BARJASTEH et al., 2015), muito comum em sistemas de recomendação mais clássicos que utilizam filtragem colaborativa.
Para realizar a análise das fotos do usuário, é feito o uso de Transfer Learning, que será um tópico abordado mais a frente no trabalho. Assim, há uma necessidade de recursos computacionais para processamento e armazenamento de informações, ao mesmo tempo que é necessário a existência de uma API pronta para, a partir de fotos de preferências turísticas, recomendar POI ao usuário em tempo aceitável. Dessa forma, este trabalho propõe uma arquitetura genérica utilizável em um ambiente de produção para um projeto que faça uso de Machine Learning para classificação de dados em geral, após apresentar a arquitetura teremos exemplos de utilização desta arquitetura.
17
1.1
Organização do trabalho
O presente trabalho é organizado em forma de capítulos. Eles estão ordenados e apre-sentados da seguinte forma:
• Capítulo 2: Mostra a arquitetura inicial em serviços para o sistema de recomendação e os tempos obtidos nem uma requisição de classificação com 7 fotos. Alguns concei-tos necessários são introduzidos para o entendimento deste trabalho e a problemática é apresentada.
• Capítulo 3: A tecnologia de Docker é explicada, diferenciando containers e máqui-nas virtuais. Os principais comandos e facilidades disponibilizados pelo Docker são discutidos.
• Capítulo 4: A arquitetura proposta neste trabalho é introduzida neste capítulo. Todos os componentes da arquitetura são explicados, a utilização da arquitetura em um projeto que faz classificação multi-label de imagens é apresentada e um mapeamento da arquitetura em um projeto de análise de texto é introduzido. • Capítulo 5: Alguns artigos que trabalham com a tecnologia Docker e a ideia de
serviços para Machine Learning são apresentados e discutidos.
• Capítulo 6: Apresenta as contribuições deste trabalho, assim como as limitações enfrentadas e os trabalhos futuros para a arquitetura proposta.
18
2
Servindo a Classificação de Fotos
Como discutido, este trabalho foi motivado pela necessidade de criação de uma API para o sistema de recomendação. Assim, o sistema poderia ser realmente utilizado por aplicações a fim de recomendar pontos turísticos aos seus usuários. A ideia da API é que ao receber as fotos do usuário, fará a análise dessas fotos e retornará a lista de pontos de interesse.
Inicialmente, o sistema de recomendação foi desenvolvido por (FIGUEREDO et al., 2018) como uma aplicação monolítica, ou seja, os componentes do sistema estão combinados em apenas uma aplicação, onde os dados de entrada são as fotos e a saída são as recomenda-ções baseadas nessas fotos. Esse sistema apresentava sérios problemas de escalabilidade, pois sua manutenção não era simples e adicionar novos componentes seria muito custoso. Na Figura 2 é representada a aplicação monolítica do sistema de recomendação.
19
Como mostrado anteriormente, o sistema de recomendação é dividido em três etapas, estas são scene classifier, fuzzy classifier e recommendation. Para uma versão inicial de uma API dessa aplicação, cada etapa foi dividida em um serviço independente em uma arquitetura inicial, ou seja, temos um endpoint separado para cada uma das etapas e foi criado um novo serviço chamado Flow para fazer a integração dos resultados desses outros três, como é mostrado na Figura 3. Assim, caso seja necessário utilizar um algoritmo de recomendação diferente para alguma aplicação, basta subir um novo serviço com um novo endpoint que será consumido por essa nova aplicação utilizando o resultado dos outros dois serviços (profile e fuzzy).
Figura 3: Arquitetura Inicial
Esses serviços foram implementados utilizando o framework Flask, desenvolvido em python, e a sua comunicação ocorre via json. Flask foi a tecnologia selecionada para implementação por ser uma framework web simples e minimalista, com poucas linhas de código é possível criar um serviço, como é mostrado na Figura 4, que retorna Hello World em uma requisição. Apesar de não ter sido encontrado artigos científicos que articulem como propriamente criar serviços que fazem uso de CNN para classificação de imagens, existem alguns exemplos, em blogs da internet, de outros desenvolvedores utilizando Flask para a criação de soluções semelhantes (MURRAY, 2017), (ROSEBROCK, 2018).
No primeiro teste utilizando esses serviços, o fluxo funcionou como esperado, porém o tempo de resposta da requisição foi muito alto, como mostrado na Tabela 1. Apesar da utilização de serviços para o processamento das imagens, os tempos apresentados na Tabela 1 é quase o mesmo da abordagem monolítica, pois a única diferença é que as etapas
20
Figura 4: Hello World com Flask
estão modularizadas. Os resultados do experimento apresentado são a média de tempo de 5 execuções. A plataforma utilizada neste trabalho foi o sistema operacional Windows 10, em um notebook Dell 7567 A-20P, que possui o processador I7 7700HQ, 8GB de memória ram (2400Ghz), 1TB de disco rígido (HD) e a placa de vídeo GeForce GTX 1050TI.
Tabela 1: Média de tempo de resposta das requisições com 7 fotos
Etapa Tempo
Scene Classifier 30,394 s Profile Fuzzification 0,258 s Recommendation 0,067 s
O tempo total de resposta da requisição mostrou-se inviável para um ambiente de real utilização desta solução, considerando ainda que isto foi executado em um servidor de testes que possui apenas um processo para responder requisições de cada serviço im-plementado. Assim, foi estudado que tipo de técnica é utilizada na análise das fotos e o que pode ser melhorado, a seguir temos uma explicação do processo de análise de fotos.
2.1
Transfer Learning
Classificação de imagens utilizando Deep Learning cresceu muito nos últimos anos devido a melhoria dos resultados e da facilidade de adaptar um problema que antes clas-sificava um tipo de imagem a outro. Esse assunto não é o foco deste trabalho, porém seu estudo é necessário para justificar as decisões arquiteturais que foram tomadas durante o desenvolvimento dos serviços.
As redes neurais convolucionais, ou Convolutional Neural Networks (CNN) auxiliam na simulação da visão humana para classificação de imagens (ONDIEKI, 2015). Porém, treinar uma CNN com um propósito específico é muito custoso, precisa-se de milhares
21
de fotos rotuladas com o que elas representam (Gato, Cachorro, Rua, Árvore...) e muitos recursos computacionais. Dessa forma, a técnica de Transfer Learning (PAN; YANG et al., 2010) parece ser promissora, já que utiliza menos dados e apresenta bons resultados. Nessa técnica, utiliza-se o que um modelo aprende com algum problema e aplica-se o mesmo modelo para um novo problema.
As camadas iniciais de um modelo de Deep Learning podem identificar formas, as ca-madas seguintes identificam padrões mais complexos e a última camada realiza prediction, ou seja, atribui um número ao que queremos classificar. A arquitetura de uma CNN pode ser ilustrada como na Figura 5, e geralmente sua performance é avaliada com uma taxa de confiabilidade da classificação que foi feita, através de métricas diversas como acurácia, precisão e erro.
Figura 5: Abstração do uso de uma CNN para classificar uma imagem
No Transfer Learning, a maioria das camadas de um modelo já estão treinadas e podem ser úteis em novas aplicações, precisando apenas substituir a última camada da CNN para classificarmos um diferente tipo de imagem. Para treinar essa última camada é necessário um conjunto de fotos, cada uma com seu respectivo rótulo, ou label. Para o caso do sistema de recomendação, é utilizado o modelo já treinado InceptionV3 (SZEGEDY et al., 2016), o qual mostrou-se muito eficiente ao classificar imagens em outros projetos, por exemplo o estudo de classificação de tipos diferentes de flores (XIA; XU; NAN, 2017).
Na última camada da rede neural pensada para a recomendação turística detalhada por (FIGUEREDO et al., 2018) são carregados alguns dos modelos que identificam 25 tipos diferentes de classes, tais como praia, museu e restaurante. Como a camada que faz a predição precisa apenas do resultado que foi gerado ao passar a imagem no modelo Incep-tionV3, esta não precisa estar necessariamente no mesmo trecho de código ou no mesmo serviço, podendo ser modularizada. Assim, podemos ter um serviço que recebe uma requisição para fazer "predict "de uma classe específica e carrega a última camada da CNN
22
em tempo de execução. Na Figura 6 temos uma representação desse processo.
Figura 6: Diagrama representando o carregamento de modelos durante uma requisição
2.2
Arquiteturas Baseadas em Microsserviços
Uma tendência recente na prática de desenvolver sistemas distribuídos é utilizar arqui-teturas baseadas em microsserviços (KRYLOVSKIY; JAHN; PATTI, 2015). Esse tipo de arqui-tetura é uma abordagem para dividir um sistema em um conjunto de pequenos serviços, altamente desacoplados, cada um executando em seu próprio processo e comunicando-se com mecanismos leves (ALSHUQAYRAN; ALI; EVANS, 2016). Cada serviço possui um pro-pósito específico e bem definido, concentrando-se em fazer uma pequena tarefa (NEWMAN, 2015). Na Figura 7 é apresentado o relatório do Google Trends sobre microservices, po-demos ver a crescente pesquisa pelo assunto iniciando entre 2014 e 2015. A escala deste gráfico é a mesma explicada anteriormente no relatório sobre Machine Learning.
23
Figura 7: Relatório do Google Trends sobre Microservices
Diferente de uma abordagem monolítica, microsserviços são independentes e possuem uma função específica, ou seja, são bem definidos e de fácil manutenibilidade. Alguns blocos de uma abordagem monolítica podem ser modularizados e tratados de forma inde-pendente, ganhos na velocidade de execução podem ocorrer ao paralelizar a execução dos microsserviços utilizando técnicas como Threading para fazer requisições simultâneas. Na Figura 8 são representadas as abordagens em microsserviços e monolítica.
Figura 8: Abordagem monolítica e abordagem com microsserviços
Utilizar microsserviços é uma prática recente e provou ser aplicável a aplicações distri-buídas altamente escaláveis e que necessitam de alterações constantes. Alguns exemplos de sucesso na utilização de microsserviços são a Netflix (TILKOV, 2015), a Amazon (GRAY, 2006) e a SoundCloud (CALçADO, 2015).
24
Pelo fato de microsserviços serem independentes e desacoplados, utilizá-los traz uma série de vantagens. (i) Arquitetura em microsserviços dá a liberdade ao desenvolvedor de desenvolver e implantar serviços de forma independente; (ii) O código de diferentes serviços podem ser implementados em diferentes linguagens; (iii) Fácil integração e deploy da aplicação ao utilizar tecnologias como Docker; (iv) Fácil entendimento de um serviço, logo um desenvolvedor que for trabalhar com um serviço específico será produtivo mais rapidamente; (v) Falhas isoladas.
Apesar de todos os benefícios, ao utilizar uma arquitetura baseada em microsservi-ços não significa que teremos um sistema mais rápido do que teríamos ao seguir uma abordagem monolítica, assim como podemos ver no estudo de (VILLAMIZAR et al., 2015), onde o tempo de resposta de ambas abordagens é muito semelhante. É possível diminuir o tempo de execução ao trabalhar com paralelização dos serviços, mas isto vai depender da aplicação e do que pode ser paralelizado.
2.3
Problemática
A proposta inicial de arquitetura em serviços para o sistema de recomendação (Figura 3), apesar de funcional, consumia muitos recursos computacionais e o tempo de resposta estava muito alto. Como visto na Tabela 1, o maior gargalo da requisição está no serviço Scene Classifier, que é onde realmente ocorre o processamento da imagem. Ao estudar esse serviço, temos algumas considerações:
• Durante a requisição a rede neural InceptionV3 é carregada em memória. Esse carre-gamento mostrou-se como a parte mais lenta de todo o processo e o maior gargalo ao realizar as análises. Assim, é algo que deve ser pré carregado em memória ao iniciar o serviço, como explicado por (ROSEBROCK, 2018), pois em um ambiente de real utilização que recebesse N requisições ao mesmo tempo, teríamos N modelos sendo carregados em memória, o que facilmente poderia implicar em um esgotamento da memória do sistema;
• Vários arquivos são carregados sequencialmente na memória ao fazer a análise de uma foto. Dependendo da quantidade de requisições recebidas simultaneamente, esta etapa pode ser muito custosa, pois o consumo de memória seria alto. Esses arquivos são carregados para realizar a etapa de prediction, na última camada da CNN;
25
• Para cada arquivo carregado, temos uma nova variável. Isto não é caracterizado como um gargalo, mas como uma prática ruim de programação, pois em um ambiente que fossem carregados 100 modelos, por exemplo, teríamos 100 variáveis diferentes, cada uma representando um modelo. Essas variáveis poderiam ser criadas dinamicamente em um array, tornando o código mais limpo.
Assim, é necessário realizar mudanças do que está sendo carregado na memória du-rante a requisição para que o que possa ser pré carregado ao iniciar o serviço Scene Classifier esteja inicializado e pronto para uso. Além disso, como esse serviço está muito denso, pois muitas tarefas estão atribuídas a ele e essas tarefas não precisam necessaria-mente estarem juntas. Uma solução é que seja modularizado em microsserviços, separando bem as suas etapas, assim podemos dividir a análise das fotos em etapas mais genéricas para que seja possível utilizar o mesmo projeto para outras finalidades, como analisar outros tipos de fotos com diferentes classes. A seguir temos uma apresentação da tecnolo-gia Docker, que facilitará no processo de modularização do sistema e na implantação dos microsserviços.
26
3
Docker
Em um projeto como o proposto neste trabalho, que faz uso de muitos recursos com-putacionais, a escolha das tecnologias utilizadas é uma etapa muito importante. Nesta seção são apresentados alguns conceitos da tecnologia Docker, que foi utilizada durante o desenvolvimento do projeto e se aplica perfeitamente às necessidades da arquitetura que será proposta no próximo capítulo.
Docker é uma tecnologia de conteinerização que permite a criação e o uso de containers Linux. Com o Docker, é possível lidar com os containers como se fossem máquinas virtuais modulares e extremamente leves. Além disso, os containers oferecem maior flexibilidade. Com eles, é possível criar, implantar e migrá-los de um ambiente para outro com pouco custo. Várias empresas de grande porte utilizam Docker em produção, tais como PayPal, Visa e ADP (DOCKER, 2013).
A tecnologia de containers está trazendo um impacto profundo em sistemas distri-buídos e computação em nuvem (JARAMILLO; NGUYEN; SMART, 2016). O crescimento na
popularidade de containers coincide com o surgimento de cada vez mais de aplicações feitas em cima de arquiteturas baseadas em microsserviços. Docker possui os principais recursos e ferramentas no qual podem ajudar a enfrentar os desafios ao utilizar uma arquitetura de microsserviços, tais como automação do deploy, independência dos serviços, portabilidade da aplicação, utilização de recursos e segurança por serem ambientes isolados.
Diferente de máquina virtuais, containers consomem poucos recursos, pois não preci-sam instalar um sistema operacional próprio e são enxergados pelo sistema operacional como processos, assim fazem chamadas por recursos computacionais diretamente para o sistema operacional de onde está o container, como é mostrado na Figura 9.
27
Figura 9: Virtualização vs Docker Container
3.1
Images
Cada serviço da plataforma criada fica hospedado em um container. Como os serviços operam de forma diferente, estes precisam de diversas bibliotecas instaladas para funcio-nar. Logo, a partir da imagem base do Ubuntu, foram criados containers separados para preparar os ambientes para cada um dos serviços. Inicializamos o container Ubuntu em seu terminal a partir do comando:
docker run -it ubuntu
Com todas as dependências instaladas para o serviço que o container hospedará, podemos criar uma nova imagem do estado atual do container que estávamos trabalhando, a partir do comando docker commit, desta forma:
docker commit ID/NAME NEW-IMAGE
Assim, podemos facilmente iniciar, parar ou modificar uma imagem já existente. Com estas imagens no Docker Hub, é possível migrar qualquer projeto para um novo servidor com apenas alguns comandos. Como este projeto lida com muitos containers e iniciar cada
28
um deles manualmente cada vez que for fazer deploy da aplicação é algo muito custoso, faremos uso do Docker Compose, explicado na próxima seção.
3.2
Docker Compose
Docker Compose é uma ferramenta fornecida pelo Docker para construir e rodar apli-cações que possuem vários containers. Em um arquivo chamado docker-compose.yml defi-nimos a nossa aplicação, configurando qual imagem cada container vai rodar, portas que serão abertas nos containers, possíveis dependências de um container para outro na hora de iniciar e outras configurações dependendo da necessidade da aplicação. Com o arquivo do Docker Compose concluído, precisamos apenas executar o comando:
docker-compose up
O Docker irá iniciar todos os containers definidos no arquivo junto com suas configu-rações, apresentando um log para acompanharmos possíveis problemas durante o deploy da aplicação. No código abaixo temos um exemplo de um arquivo docker-compose.yml.
v e r s i o n : ’ 3 ’ s e r v i c e s : web : i m a g e: z e l u c a s / web : v1 p o r t s: - " 5 0 0 0 : 8 0 " n e t w o r k s : - n e w n e t v o l u m e s: - C :\ U s e r s \ z e l u c a s \ D e s k t o p \ t e s t e :/ root / t e s t e r e d i s : i m a g e: r e d i s n e t w o r k s : - n e w n e t n e t w o r k s : n e w n e t : d r i v e r : b r i d g e
29
Containers normalmente executam serviços, e em uma aplicação que possui muitos serviços é necessário a comunicação entre eles. Para todos estes containers poderem se comunicar, é criada uma network onde quem participar da network conseguirá enxergar os outros serviços que também foram criados a partir dos nomes do containers.
3.3
Volume
Quando utilizamos um container Docker seus dados ficarão armazenados em algum local, caso não seja fornecido nenhum local explícito para o armazenamento destes dados, estes serão armazenados dentro do próprio container que, quando deletado, irá perder todos os dados que estavam registrados.
Docker Volume é utilizado para não perdemos os dados que foram armazenados pe-los containers e, também, para compartilhar um espaço entre containers para que estes possam fazer uso de dados criados por outros containers.
Em casos onde os arquivos do volume são os códigos da aplicação que está rodando no container, podemos fazer alterações nos códigos que, automaticamente, eles serão atu-alizadas no container que está rodando a aplicação. Esta prática é muito útil durante a etapa de desenvolvimento de software.
No caso do sistema de recomendação, o volume é utilizado para compartilhar as ima-gens salvas durante a etapa de download e os modelos utilizados para fazer a classificação das fotos.
30
4
MLMA: Arquitetura e
Instanciação
Este capítulo contempla a arquitetura proposta para criação de uma API para classi-ficação de dados, nomeada Machine Learning in Microservices Architecture (MLMA) e logo após uma descrição dos serviços que compõe esta arquitetura. Algumas tabelas com tempos de execução e consumo de memória são apresentadas no exemplo de utilização dessa arquitetura para justificar certas decisões durante o desenvolvimento do projeto.
A motivação deste projeto surgiu pela necessidade de criar uma API para o sistema de recomendação, porém ao perceber que não existem trabalhos que propõem uma arqui-tetura para classificação de dados que fazem uso de Machine Learning, este trabalho propõe uma arquitetura genérica baseada em microsserviços para classificação de dados e apresenta um exemplo de utilização para o caso do sistema de recomendação e o mapeamento da arquitetura em um projeto de análise de texto. A arquitetura atual contempla a etapa de classificação (execução), a etapa de treinamento está sendo estu-dada para uma versão futura. Na próxima seção é apresentada a arquitetura e para cada microsserviço que a compõe, teremos a sua descrição definindo o seu funcionamento.
4.1
Machine Learning in Microservices Architecture
O conceito de arquitetura genérica se dá diante da grande necessidade de modelos de inteligência artificial, sempre aplicados em diferentes escalas e contextos, serem dispo-nibilizados de forma simples para os serviços utilizantes. Fazer com que os modelos de inteligência artificial sejam utilizados de forma prática é uma tarefa complexa, principal-mente devido ao custo computacional de usar esse tipo de tecnologia.
A arquitetura genérica, representada na Figura 10 foi pensada para ser implementada em qualquer projeto que deseja fazer uso de classificação de dados, para isso seria neces-sário apenas mapear as etapas da classificação para os serviços definidos na arquitetura,
31
desde a coleta de dados até a etapa de predição. A API desta arquitetura funciona rece-bendo um dado para classificar e o modelo que seria utilizado. Desta forma, seria possível fazer vários tipos de análises, como de textos para descobrir o domínio de uma frase, ou até mesmo análise de imagens em tempo real, como por exemplo verificar se um motorista está dormindo ao volante.
Na arquitetura proposta nesse trabalho busca-se melhorar o desempenho e a dis-ponibilidade de classificadores multi-label. Esse tipo de classificação dá-se por meio da utilização de diversos classificadores binários e nos permite analisar dados de diferentes perspectivas, de tal forma que um determinado tipo de dado pode ser classificado em vá-rias classes (NASIERDING; KOUZANI, 2012). Desta forma, para que um sistema utilize uma arquitetura de classificação multi-label o custo computacional é amplificado pelo fato da necessidade de vários classificadores binários trabalhando juntos. A arquitetura também pode ser utilizada em problemas mais simples, que não fazem classificação multi-label, pois mesmo para problemas mais simples, as vantagens de utilizar uma arquitetura baseada em microsserviços serão alcançadas.
Na nossa proposta, os recursos são administrados da melhor forma possível para que todo processo que envolve a classificação multi-label seja feita de maneira otimizada, desde da extração de features dos dados até o momento da classificação binárias. Os próximos tópicos explicarão como cada etapa da classificação que foi estabelecida na nossa arquitetura de forma genérica, os componentes que estão tracejados são considerados opcionais.
4.1.1
Flow Controller Service e Post Processing Service
O Flow Controller Service e o Post Processing Service são os serviços iniciais da arquitetura e são opcionais. O objetivo destes serviços é gerar algum tipo de informação a partir do resultado da classificação dos dados. No caso de o Flow Controller Service não ser utilizado, a comunicação será feita entre o Consumer e o Data Collector Service.
Após receber o resultado da classificação, o Flow Controller Service irá fazer requisi-ção para os possíveis serviços que se enquadram como Post Processing Service, que irão transformar o resultado da classificação em alguma informação que será retornada para o usuário na requisição. Podemos ter mais de uma serviço que se enquadre como Post Processing Service, isto vai depender do processamento necessário após a classificação dos dados, e o Flow Controller Service fará integração dos resultados destes serviços.
32
Figura 10: Arquitetura Genérica para classificação de dados. Os dados são enviados pela API pelo componente Consumer, que ao final da análise receberá a informação sobre a classificação.
33
4.1.2
Data Collector Service
O objetivo deste serviço se baseia em extrair as informações, dados ou conteúdo de uma fonte bem definida para colocá-lo no início de um processo de análise.
Não existe, nesta etapa do processo, algum tipo de análise ou conceitos de inteligência artificial ou de análise de dados embutido. Entretanto, diante da vasta variedade de dados possíveis para se trabalhar diante de uma arquitetura genérica, pode-se de dizer que o Data Collector Service foi pensado para ser o mais robusto possível para dar suporte aos mais diferentes contextos.
Os dados trabalhados neste nível podem variar em tipo, tamanho, estrutura e dispo-nibilidade. A primeira e segunda situação, pode ser percebida constantemente diante da massa de dados gerados por usuários, como imagens, dados geoespaciais, texto e séries temporais. Em termos de estruturas, o servido de coleta deve ser robusto o suficiente para suportar dados estruturados e não estruturados, muito comum quando a fonte de dados são redes sociais como o Twitter.
4.1.3
Data Analysis Service
O serviço de análise de dados tem uma função de intermédio entre os dados de três serviços diferentes. Como visto na Figura 10, os serviços de coleta de dados, extração de features e de classificação e predição são intermediados pelo Data Analysis Service.
Nesta etapa, os dados coletados e enviados pelo primeiro serviço citado nesta seção são repassados primeiramente para o serviço de extração de features. Após a extração das informações feitas pelo serviço, os dados retornam em outra estrutura para que possam ser usados. Assim cada dado que possui as features extraídas são processados para que possam servir de entrada no próximo serviço, que possui uma variância na sua estrutura diante do tipo de classificador utilizado. Após o processo de preparação, o serviço de análise de dados envia a nova estrutura de dados criado para a classificação para que no fim do processo possa receber o resultado da classificação.
4.1.4
Preprocessing Service
Em alguns casos, será necessário fazer um pré-processamento dos dados antes do processo de análise, para isso o Preprocessing Service foi pensado. Na etapa de pré-processamento, desta arquitetura, não é extraída alguma informação dos dados, mas
34
feita uma limpeza do que pode atrapalhar a classificação ou alguma modificação para adaptar os dados para algum padrão necessário.
Para ter acesso aos dados, o Preprocessing Service faz acesso ao volume do Doc-ker, onde estão os dados compartilhados pelos containers. Ao terminar a execução do pré-processamento determinado, o novo dado também é salvo no volume para que seja utilizado na etapa de extração de features.
Um exemplo comum como etapa de pré-processamento é o caso de análise de textos, onde podemos encontrar alguns links, caracteres estranhos, stop word (SILVA; RIBEIRO, 2003) e outras informações desnecessárias no processo de classificação.
4.1.5
Features Service
O serviço para de extração de características, chamado aqui de Features Service, é onde o dado, bruto ou pré-processado, será utilizado. Diferente dos serviços anteriores, que trabalham com o local de armazenamento ou limpeza dos dados, o serviço de extração de features precisa trabalhar diretamente com os dados para processá-los de forma adequada (HAYKIN et al., 2009).
Extrair features no contexto de inteligência artificial é o ato de retirar informações ou processar os dados para que eles possam ser aprendidos de forma mais simples pelos algoritmos de treinamento. A arquitetura genérica aqui proposta separa o processo de extração de features do de classificação. Não há queda de desempenho em termos de classificação. Entretanto, em classificação multi-label baseada em sistemas de classificação binária, o ato de separar a extração da classificação pode representar um ganho de tempo de classificação relevante pois utilizamos o serviço de extração somente um vez, enquanto o serviço de análise de dados executa várias chamados do serviço de classificação.
Cada dado bruto que entra no serviço de extração passará por esse somente uma única vez. O dado gerado por esse serviço pode ser reaproveitado para executar várias classificações, já que essa etapa, na maioria dos casos, é a mais custosa.
4.1.6
Predict Service
O serviço de classificação será responsável por gerar a informação mais relevante para o usuários do sistema na etapa genérica do processo. Neste caso, a arquitetura está trabalhando com um conjunto de classificadores binários. Ou seja, cada classificador é
35
responsável por classificador uma determinada classe entre "sim"ou "não".
O grande diferencial da abordagem genérica citada é o aproveitamento de classifica-dores. Em muitos casos de classificadores binários a estrutura do classificador é mantida para todas as classes. A mudança presente nesses classificadores é o modelo de pesos car-regado por eles. Desta forma, o que é feito na arquitetura proposta é o aproveitamento da estrutura dos classificadores para evitar redundância. Assim, a estrutura carrega novos pesos dinamicamente para que possa executar a classificação binária.
O dados estruturado como forma de features ou pré-processado, quando for o caso, entra nesse serviço para que possa sair como conjunto de classificações. O resultado é um vetor de N valores que são relacionados com quantidade de classes presentes nesta arquitetura. Os valores presentes nesse vetor de N posições são referentes à classificação binárias. São valores que variam entre 0 e 1. O valor de cada posição representa a proba-bilidade do dado de entrada pertencer à uma determinada classe. Quanto mais próximo de 1, maior a probabilidade do dado pertencer à classe referente a posição i do vetor de N posições.
4.2
Sistema de Recomendação mapeado na
Arquite-tura Genérica
O sistema de recomendação foi mapeado e implementado utilizando a arquitetura genérica proposta. Sabendo que sempre que fossemos classificar uma imagem seria ne-cessário extrair suas features para cada requisição, o tempo para classificar cada imagem em cada um dos 25 modelos seria muito alto, logo, ao utilizar a arquitetura, as features extraídas serão reaproveitadas na etapa de predição com outros modelos. Na Figura 11 temos a representação da arquitetura do sistema de recomendação.
A arquitetura proposta para servir os modelos utilizados na análise de imagens é baseada em microsserviços e containers com funcionalidades específicas e bem definidas. Nas próximas subseções teremos uma descrição de como cada microsserviço funciona para que fique claro como ocorre a comunicação entre eles.
36
Figura 11: Sistema de Recomendação mapeado na arquitetura genérica proposta. Requisição iniciando pelo Consumer, que envia as fotos, logo após o Flow Controller Service requisita a análise das fotos, e com o resultado da análise gera informação para retornar para o Consumer a partir do Fuzzy Service e Recommendation Service
37
4.2.1
Flow Controller Service
O Flow Controller Service foi desenvolvido com o intuito de receber os resultados da análise das fotos e passar para os serviços que se enquadrem como Post Processing Service, que no caso do sistema de recomendação são as etapas de fuzzification e de recommendation. Ao receber a requisição com as fotos, o Flow Controller Service envia as fotos para o Data Collector Service, que retorna o perfil turístico do usuário, composto por 5 classes (landscape, adventure, historical, urban e shopping) com graus baseados nas fotos do usuário. Com as classes, é requisitado a etapa de fuzzification para o Fuzzy Service, que retorna o profile do usuário, e, por fim, é realizada a recomendação pelo Recommendation Service, para que seja retorna ao usuário os pontos de interesse relevantes.
Este serviço faz apenas requisições HTTP do tipo POST e repassa os resultados, assim, não consome muita memória, inicia rapidamente e, em caso de necessidade, pode ter mais processos criados durante uma nova requisição, sem que prejudique os outros módulos do sistema.
4.2.2
Data Collector Service
Este serviço tem por finalidade baixar todas as imagens que estiverem no json da requisição recebida e irá salvar em uma pasta com o título sendo o id do usuário dentro do volume do Docker. Na Figura 12 temos um exemplo do arquivo json recebido na requisição.
Figura 12: Exemplo do json recebido pelo Data Collector Service
Para cada imagem que for baixada é solicitado a análise da mesma para o Data Analysis Service, enviando na requisição o id da imagem, junto com os modelos que serão utilizados na análise. O retorno do Data Analysis Service será o grau de certeza de que a imagem possui o que o modelo solicitado foi treinado para classificar. Com todos estes graus recebidos, o Data Collector Service concatena os resultados para montar o profile do usuário e retornar para o Flow Controller Service, que irá passar para as etapas de
38
fuzzyfication e recommendation.
4.2.3
Data Analysis Service
Com a imagem acessível pela aplicação, ou seja, com o arquivo da imagem dentro do volume do Docker, passamos para a etapa de análise das fotos. A análise foi dividida em duas etapas, sendo a primeira a extração de features da foto e a segunda passar esse resultado para a etapa de prediction.
Sabendo que a imagem já foi baixada e salva pela Data Collector Service, é necessário enviar na requisição o id do caminho que está a foto juntamente com o nome do arquivo da foto que será analizada, como está sendo utilizado o mecanismo de volume entre os containers Docker, as fotos poderão ser acessadas por todos os serviços que precisarem e tiverem acesso ao volume.
Para cada foto que for analisada será necessário extrair suas features utilizando o Features Service. Como será necessário passar as features pelo Predict Service para cada modelo que for usado na classificação e não é necessário fazer isto sequencialmente, threads são criadas para realizarem requisições simultaneamente e, por fim, os resultados das requisições são concatenados em um json para devolver na resposta. Na Figura 13 temos a representação do funcionamento deste serviço.
Figura 13: Processo de criação de threads para cada modelo utilizado na análise no Data Analysis Service.
Este serviço identifica os endpoints para extrair as features da foto e para passar pela última camada da rede neural pelo nome dos containers que foram criados no arquivo
39
docker-compose.yml. Como todos os containers compartilham uma network, logo, o nome do container substitui o ip do container na url de acesso, assim não há necessidade de alterar o ip de acesso no código que está referenciando os containers da aplicação ao fazer deploy.
4.2.4
Features Service
Como explicado na seção de Transfer Learning, as camadas iniciais e intermediárias da CNN identificam formas e padrões mais complexos, chamamos este resultado de features. Para isso, as camadas da CNN InceptionV3 são pré carregadas na inicialização deste serviço, visto que esta é a etapa mais demorada durante a análise das fotos e não precisa ser feita durante uma requisição.
Ao deixar a CNN carregada na memória, o tempo de extração de features caiu con-sideravelmente, porém isto exige muito recurso de memória. Na Tabela 2 mostramos o quanto o consumo de memória aumenta ao iniciar um novo processo deste serviço. As-sim, o número de serviços foi limitado no arquivo de configuração do uWSGI (servidor utilizado para fazer deploy dos serviços), inicializando um número fixo e bloqueando que novos processos pudessem ser criados automaticamente durante uma nova requisição.
Tabela 2: Memória consumida com N processos do Features Service. Processos Memória
1 420 megabyte 2 840 megabyte 3 1260 megabyte
4.2.5
Predict Service
No Predict Service ocorre a última etapa do reconhecimento da imagem e temos um valor determinando a certeza se na imagem possui o que está sendo analisado no modelo escolhido. Este serviço foi desenvolvido para poder responder a qualquer tipo de modelo requisitado, para isso foi necessário validar que o tempo necessário para carregar os modelos fosse baixo, assim foram carregados alguns dos modelos utilizados na análise das fotos 10 vezes seguidas e foram coletados os tempos de carregamento dos modelos, para depois tirar a média dos tempos, como apresentado na Tabela 3.
40
Tabela 3: Média dos tempos de carregamento dos modelos. Modelo Tempo Beach 0,194 s Museum 0,158 s Restaurant 0,176 s Stadium 0,164 s Shopping 0,174 s
Sendo o tempo de carregamento dos modelos baixo e considerando que estes serão carregados paralelamente, é melhor possuir alguns processos do Predict Service que podem carregar qualquer modelo que está no volume do Docker durante a requisição do que ter um processo ativo para cada modelo que for inserido no sistema, o que consumiria muita memória em um cenário onde fossem utilizados vários modelos para uma só requisição.
Este serviço não consome tanto recurso de memória como o Features Service, porém consome um valor considerável, como mostrado na Tabela 4, e o tempo para iniciar um novo processo deste serviço pode não ser aceitável durante uma requisição, visto que executando alguns testes o tempo de inicialização de um novo processo era de cerca de 2 segundos, logo, foi definido um valor fixo de processos, assim como no Features Service, baseado nos recursos disponíveis. Na Figura 14 temos a representação do que foi descrito utilizando três processos e NGINX (tecnologia que funciona como balanceador de carga e é utilizado em grandes projetos em produção) para distribuir as requisições.
Tabela 4: Memória consumida com N processos do Predict Service. Processos Memória
1 113 megabyte 2 226 megabyte 3 339 megabyte
Ao utilizar o volume do Docker para armazenar os modelos, não há a necessidade de fazer novamente o deploy da aplicação ou de iniciar um novo processo deste serviço, pois os processos compartilham o mesmo espaço em que os arquivos dos modelos estão salvos e só precisam carrega-los durante as requisições, quando for necessário.
41
Figura 14: Utilizando NGINX como balanceador de carga e consumindo os processos criados do Predict Service para carregar qualquer modelo durante uma requisição.
O número de processos é limitado da mesma forma que foi introduzido no Features Service, definindo um número no arquivo de configuração do UWSGI e bloqueando a inicialização de novos processos.
4.2.6
Fuzzy Service e Recommendation Service
O Fuzzy Service e o Recommendation Service enquadram-se como Post Processing Service, pois a partir do resultado da análise das fotos, geram algum tipo de informação. O Fuzzy Service recebe o profile do usuário, composto por 25 classes, e reduz ele para um perfil turístico, composto por 5 classes. Por sua vez, o Recommendation Service recebe o perfil turístico do usuário e retorna POI s da cidade do Natal/RN.
Como esses serviços não consomem muitos recursos, não há problema na criação de novos processos durante uma requisição. Não entraremos em detalhes de como funciona a lógica desses serviços, pois este não é o foco deste trabalho, porém seu funcionamento está bem definido no trabalho de (FIGUEREDO et al., 2018).
42
4.2.7
Tempos de processamento
Os tempos de resposta após a utilização da arquitetura caiu consideravelmente, para um conjunto de 7 fotos é levado cerca de 10 segundos para o usuário ter o resultado em sua tela. É importante salientar que esses testes ainda foram executados em um computador Dell 7567 A-20P, logo o resultado não reflete totalmente a capacidade que pode ser atingida ao utilizar a arquitetura proposta neste trabalho.
Na tabela 5 temos um comparativo dos tempos para cada etapa das abordagens citadas neste trabalho, a primeira é a monolítica, apresentada na Figura 2. A segunda é a arquitetura inicial em serviços, apresentada na Figura 3. Por último, temos os tempos da abordagem ao aplicar a arquitetura MLMA no sistema de recomendação. O resultado dos tempos é igual a média de 5 execuções.
Tabela 5: Tempos de cada etapa para cada abordagem. Etapa Monolítica Arquitetura Inicial MLMA Scene Classifier 29,863 s 30,394 s 9,848 s Fuzzyfication 0,241 s 0,258 s 0,247 s Recommendation 0,079 s 0,067 s 0,71 s
Como podemos observar, os tempos da arquitetura inicial e da abordagem monolítica são muito semelhantes, o que já foi explicado no início deste trabalho. A abordagem seguindo a MLMA tem um bom ganho no desempenho pelo fato de paralelizar etapas da classificação e por pré carregar tudo o que é necessário durante a classificação, como a CNN InceptionV3.
4.2.8
Sistema de Validação
Com os serviços prontos e rodando, fez-se alguns testes utilizando a API criada. O sistema de recomendação está em processo de validação dos seus resultados e, para isso, foi criada uma aplicação web, utilizando JavaEE, que permite que seus usuários informem se concordam ou não com os resultados exibidos. A opinião do usuário é armazenada em um banco de dados em tempo real no Firebase em formato de json. Nas Figuras 15, 16, 17 e 18 temos as telas do sistema.
43
Figura 15: Tela de login
44
Figura 17: Tela de resultado do perfil do usuário
45
Na Figura 19 é exibido todo o fluxo do processo de validação do sistema, algumas imagens das telas são referenciadas durante o fluxo para facilitar o entendimento.
Figura 19: Fluxo passo a passo do Sistema de Validação.
4.3
Classificação de textos mapeado na Arquitetura
Ge-nérica
A área de análise dados possui diversas aplicações e uma delas é a classificação de textos. Como exemplo de classificação de textos temos a análise de sentimentos de Tweets, que são frases enviadas por usuários da rede social Twitter. Nessa análise, normalmente, as frases são identificadas como positivas, neutras ou negativas, da mesma forma que é explicado no trabalho de (PAK; PAROUBEK, 2010).
46
Mapeando um projeto de análise de sentimentos de Tweets à arquitetura genérica, não teríamos os componentes Flow Controller Service e Post Processing Service, pois o resultado da classificação já seria a informação de retorno da API. Os Tweets recebidos na requisição seriam armazenados no componente Data do volume Docker para que sejam acessíveis por outros containers.
Com os dados salvos no volume, o Analysis Service iniciaria o processo de análise do texto, solicitando ao Preprocessing Service a limpeza da frase, que nesse caso significa retirar links, hashtags e stop words. Com o pré-processamento finalizado, o Features Ser-vice faz a extração de features. Com as features extraídas, o processo final é passar pelo Predict Service, que carregará um modelo já treinado para identificação de sentimento de Tweets e fará a classificação, que será retornada como resposta da API.
A descrição aqui feita do mapeamento de análise de sentimentos na arquitetura ge-nérica serve para mostrar que outros projetos que fazem uso de Machine Learning para classificação de dados também podem ter suas etapas identificadas nos componentes pro-postos na arquitetura. Na Figura 20 é demonstrado quais os componentes utilizados no projeto de análise de Tweets descrito.
47
5
Trabalhos Relacionados
Machine Learning continua crescendo como uma forte ferramenta para resolução de problemas. No entanto, implementar ML em aplicações não é uma tarefa fácil e requer um conhecimento específico por parte do desenvolvedor. Para facilitar este processo, (PAHL; LOIPFINGER, 2018) propõe a técnica de encapsular ML como microsserviços, o que chamou de REST ML. Para isso, três tipos de algoritmos que foram considerados relevantes para a área de internet das coisas foram implementados como microsserviços, estes são Feed-Forward Neural Networks, Deep Believe Networks, e Recurrent Neural Networks. Ao final, o autor mostra que a abordagem proposta simplifica a implementação de algoritmos para ML, uma vez que permite o reuso de serviços e de configurações.
Com a utilização de Machine Learning em aplicações, a falta recursos computacio-nais tornam-se um problema. Contudo, soluções aprimoradas com a implementação de algoritmos de paralelização ganham desempenho, é nisso que o trabalho de (YAN et al., 2018) entra em detalhes. Nesse trabalho, é discutido e apresentado ganhos ao paraleli-zar e utiliparaleli-zar serviços que modularizam as camadas de Deep Neural Network (DNN) . Como resultado, o trabalho contribui com um framework chamado SERF, que encontra as melhores configurações de paralelização para os serviços da DNN.
Ao trabalhar com vários serviços, desafios surgem como a maneira correta de hospe-dar esses serviços e qual tipo de tecnologia utilizar. No trabalho de (ANDERSON, 2018), containers Docker são utilizados para hospedar aplicações de monitoramento, esses con-tainers executam em cima de uma máquina virtual criada em uma nuvem OpenStack, que permite a utilização de recursos de diversos computadores ao mesmo tempo (SEFRAOUI; AISSAOUI; ELEULDJ, 2012). Um componente que faz uso de Deep Learning para moni-torar o ambiente em que os containers estão inseridos foi desenvolvido e hospedado em uma máquina virtual separada, com esse componente é possível detectar problemas de segurança, como podemos ver na Figura 21. A solução mostrou-se promissora e funcional, porém, como explicado pelo próprio autor da solução, o componente de monitoramento precisa ser aprimorado.
48
Figura 21: Monitoramento do ambiente dos containers Docker. (Fonte: (ANDERSON, 2018))
Ainda seguindo a linha de monitoramento, o trabalho de (LEE; SHIN; SONG, 2017)
mo-nitora o caminho percorrido por tufões através de imagens de satélite. Para realizar esse monitoramento, Docker e Kubernetes, um administrador para containers Docker ( BERNS-TEIN, 2014), hospedam a aplicação que faz o processamento das imagens e distribuem os recursos computacionais.
Na proposta de (CHOI, 2017), containers também foram utilizados para hospedar uma solução que faz uso de CNN para monitorar a integridade da memória de um sistema. Apesar dos dois últimos trabalhos citados não trabalharem muito o assunto de containers e sistemas distribuídos, mostram que soluções que fazem uso de serviços para classificação de dados e utilizam Docker para controle e deploy desses serviços estão ganhando espaço na literatura.
49
6
Considerações finais
Neste trabalho foi apresentada uma arquitetura genérica para classificação de da-dos, assim como foram introduzidos alguns conceitos necessários para o entendimento da mesma. Ao utilizar essa arquitetura é possível modularizar etapas de aplicações que fazem uso de Machine Learning e obter as vantagens de uma arquitetura baseada em microsserviços.
Para exemplificar o uso da arquitetura, um sistema de recomendações de pontos tu-rísticos que faz análise de fotos foi modularizado e implementado seguindo a definição dos microsserviços propostos. Houve uma diminuição no tempo da requisição para as análises das fotos, porém faz-se necessário mais testes com mais recursos computacionais para que seja possível avaliar o ganho real da utilização da aplicação modularizada em microsser-viços. Ao fim do trabalho, também tivemos um exemplo do mapeamento de um projeto para análise de textos na arquitetura proposta.
Como foi mostrado no capítulo de trabalhos relacionados, outros trabalhos da área de Machine Learning realizaram os experimentos dos seus testes em clusters de computadores com pelo menos 10 nós de processamento. Neste trabalho, o ambiente de teste foi uma limitação para um bom resultado de validação da arquitetura.
Durante o desenvolvimento deste projeto, foi possível aplicar conhecimentos obtidos durante o curso de Engenharia de Software e conhecimentos obtidos ao desenvolver e es-tudar aplicações para o projeto Smart Metropolis da Universidade Federal do Rio Grande do Norte (UFRN), que contempla diversas linhas de pesquisa e desenvolvimento.
6.1
Trabalhos futuros
A arquitetura proposta mostrou-se promissora para os projetos apresentados neste trabalho, porém devemos aplicá-la para novos projetos na área de Machine Learning, para assim aprimorá-la aplicando alterações pontuais, ou adicionando novos microsserviços.
50
Deseja-se, também, adicionar uma etapa de treinamento à arquitetura, onde dados seriam recebidos por requisição e os modelos para classificação seriam treinados.
Para uma melhor validação deste e de outros trabalhos, foi iniciada a instalação de uma nuvem OpenStack no laboratório do Smart Metropolis, que servirá para realizar testes futuros de aplicações mapeadas nesta arquitetura, observando consumo de memória, processamento, armazenamento e os ganhos obtidos ao comparar com uma aplicação monolítica. Com essa nuvem, será possível a utilização de tecnologias como Kubernetes e Docker Swarm (NAIK, 2016) para administração de vários de containers em execução.
Machine Learning aplicado à sistemas distribuídos ainda é uma área em ascensão, existem poucos trabalhos que fazem uma contribuição direta para essa área. Dessa forma, pesquisas na literatura continuarão sendo feitas para que novas contribuições de outros pesquisadores possam ser integradas a este trabalho.
51
Referências
ALSHUQAYRAN, N.; ALI, N.; EVANS, R. A systematic mapping study in microservice architecture. In: IEEE. Service-Oriented Computing and Applications (SOCA), 2016 IEEE 9th International Conference on. [S.l.], 2016. p. 44–51.
ANDERSON, R. From bare metal to private cloud: Introducing devsecops and cloud technologies to naval systems. 2018.
ARMBRUST, M. et al. A view of cloud computing. Communications of the ACM, ACM, v. 53, n. 4, p. 50–58, 2010.
BARJASTEH, I. et al. Cold-start item and user recommendation with decoupled completion and transduction. In: Proceedings of the 9th ACM Conference on
Recommender Systems. New York, NY, USA: ACM, 2015. (RecSys ’15), p. 91–98. ISBN 978-1-4503-3692-5.
BERNSTEIN, D. Containers and cloud: From lxc to docker to kubernetes. IEEE Cloud Computing, IEEE, n. 3, p. 81–84, 2014.
BORRàS, J.; MORENO, A.; VALLS, A. Intelligent tourism recommender systems: A survey. Expert Systems with Applications, v. 41, n. 16, p. 7370 – 7389, 2014. ISSN 0957-4174.
CALçADO, P. How we ended up with microservices. 2015. Sept., 2015. Disponível em: <https://blog.keras.io/building-a-simple-keras-deep-learning-rest-api. html>. Acesso em Outubro 28, 2018.
CHOI, S.-H. Usability of docker-based container system health monitoring by memory dump visualization. 2017.
DOCKER. Docker Customers. 2013. Disponível em: <https://www.docker.com/ customers>. Acesso em Novembro 10, 2018.
FIGUEREDO, M. et al. From photos to travel itinerary: A tourism recommender system for smart tourism destination. In: 4th IEEE International Conference on Big Data Computing Service and Applications. [S.l.: s.n.], 2018.
GRAY, J. A conversation with werner vogels. ACM Queue, v. 4, n. 4, p. 14–22, 2006. HAYKIN, S. S. et al. Neural networks and learning machines. [S.l.]: Pearson Upper Saddle River, 2009.
IGNARRA, L. R. Fundamentos do turismo. Pioneira, São Paulo, 1999.
JANNACH, D.; ZANKER, M.; JESSENITSCHNIG, M. Developing knowledge-based travel advisor systems: A case study. p. 38–53, 01 2009.
52
JARAMILLO, D.; NGUYEN, D. V.; SMART, R. Leveraging microservices architecture by using docker technology. In: IEEE. SoutheastCon, 2016. [S.l.], 2016. p. 1–5.
KRYLOVSKIY, A.; JAHN, M.; PATTI, E. Designing a smart city internet of things platform with microservice architecture. In: IEEE. Future Internet of Things and Cloud (FiCloud), 2015 3rd International Conference on. [S.l.], 2015. p. 25–30.
LEE, M.; SHIN, S.; SONG, S.-K. Design on distributed deep learning platform with big data. 2017.
LITVIN, S. W.; GOLDSMITH, R. E.; PAN, B. Electronic word-of-mouth in hospitality and tourism management. Tourism Management, v. 29, n. 3, p. 458 – 468, 2008. ISSN 0261-5177.
LOHMANN, G. Tourism theory : concepts, models and systems. [S.l.: s.n.], 2017. ISBN 9781780647166.
MELL, P.; GRANCE, T. et al. The nist definition of cloud computing. Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology Gaithersburg, 2011.
MURRAY, C. Deep Learning with Keras on Google Compute Engine. 2017. Out., 2018. Disponível em: <https://medium.com/google-cloud/ keras-inception-v3-on-google-compute-engine-a54918b0058>. Acesso em Outubro 15, 2018.
NAIK, N. Building a virtual system of systems using docker swarm in multiple clouds. In: IEEE. Systems Engineering (ISSE), 2016 IEEE International Symposium on. [S.l.], 2016. p. 1–3.
NASIERDING, G.; KOUZANI, A. Z. Comparative evaluation of multi-label classification methods. In: 2012 9th International Conference on Fuzzy Systems and Knowledge Discovery. [S.l.: s.n.], 2012. p. 679–683.
NEWMAN, S. Building microservices: designing fine-grained systems. [S.l.]: "O’Reilly Media, Inc.", 2015.
ONDIEKI, B. Convolutional neural networks for scene recognition. 01 2015.
PAHL, M.-O.; LOIPFINGER, M. Machine learning as a reusable microservice. In: IEEE. NOMS 2018-2018 IEEE/IFIP Network Operations and Management Symposium. [S.l.], 2018. p. 1–7.
PAK, A.; PAROUBEK, P. Twitter as a corpus for sentiment analysis and opinion mining. In: LREc. [S.l.: s.n.], 2010. v. 10, n. 2010, p. 1320–1326.
PAN, S. J.; YANG, Q. et al. A survey on transfer learning. IEEE Transactions on knowledge and data engineering, Institute of Electrical and Electronics Engineers, Inc., 345 E. 47 th St. NY NY 10017-2394 USA, v. 22, n. 10, p. 1345–1359, 2010.
ROSEBROCK, A. Building a simple Keras + deep learning REST API. 2018. Out., 2018. Disponível em: <https://blog.keras.io/
building-a-simple-keras-deep-learning-rest-api.html>. Acesso em Outu-bro 15, 2018.
