Para avaliar as soluções foram executados alguns testes. Inicialmente, avaliamos o tempo necessário para o carregamento dos modelos, assim, podemos validar que mesmo em um servidor remoto o acesso aos dados do volume não deve ter um impacto grande nos tempos de execução. A média dos tempos de execução das soluções apresentadas neste trabalho são exibidas e discutidas. A fim de validar a escalabilidade do sistema também são executados testes de carga utilizando o software Apache JMeter.
Capítulo 5. Avaliação 49 tempo de execução, assim avaliamos a performance para fazer esse carregamento. Foram carregados alguns dos modelos utilizados na análise das fotos, 100 vezes seguidas, coletando os tempos de carregamento para calcularmos a média dos tempos, como apresentado nas Tabelas 5 e 6. Modelo Tempo Beach 0,314 s Museum 0,287 s Restaurant 0,286 s Stadium 0,261 s Shopping 0,328 s
Tabela 5 – Média dos tempos de carrega- mento dos modelos com AWS Lambda e S3. Modelo Tempo Beach 0,218 s Museum 0,168 s Restaurant 0,193 s Stadium 0,181 s Shopping 0,197 s
Tabela 6 – Média dos tempos de carre- gamento dos modelos com OpenWhisk.
Sendo o tempo de carregamento dos modelos baixo e considerando que estes serão carregados paralelamente, para o caso de uma arquitetura em microsserviços é 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.
Na tabela 7 temos um comparativo dos tempos para cada etapa das abordagens citadas neste trabalho, a primeira é a monolítica, apresentada na Figura 17. A segunda é a arquitetura MLMA que faz uso de microsserviços, apresentada no trabalho (RIBEIRO et al., 2019). As duas últimas são referentes às soluções Serverless. O resultado dos tempos é igual a média de 100 execuções após a realização de um warm-up no ambiente.
Etapa Monolítica MLMA MLSA (Lambda) MLSA (OpenWhisk) Scene Classifier 26,831 s 8,164 s 10,593 s 8,471 s
Fuzzyfication 0,219 s 0,233 s 0,247 s 0,241 s Recommendation 0,062 s 0,065 s 0,071 s 0,066 s Tabela 7 – Tempos de cada etapa para cada abordagem.
Como podemos observar, o tempo da etapa de Scene Classifier da abordagem monolítica é muito superior ao das outra soluções por não paralelizar nenhuma etapa e não otimizar o uso de memória da aplicação. As abordagens seguindo a MLMA, MLSA (Lambda) e MLSA (OpenWhisk) possuem uma diminuição no tempo de execução
Capítulo 5. Avaliação 50 em relação à solução monolítica de 69,5%, 60% e 68,4% respectivamente. Isto ocorre pelo fato de paralelizarem etapas da classificação e por pré carregarem tudo o que é necessário antes da classificação, como a CNN InceptionV3.
Para avaliar a escalabilidade da solução desenvolvida com Serverless no ambiente da AWS foi preparado um script de requisições simultâneas, começando com 1 usuário enviando 7 fotos e incrementando o número de usuários em 1 a cada 1 segundo de execução do script, até atingir 100 usuários. Na Figura 23 é apresentado como funcionarão as requisições desse script, sendo o eixo X o tempo e o eixo Y o número de usuários (threads).
Figura 23 – Representação do número de usuários por tempo de execução
Este teste foi executado sem realizar o warm-up do ambiente, assim garantimos que não havia nenhuma função inicializada. Ao executar o teste todos os usuários receberam seus resultados corretamente, isto significa que todas as requisições foram atendidas por funções que já estavam executando ou novas funções foram criadas para atender a demanda de requisições. Sabendo que 100 threads foram disparadas durante o experimento, tivemos um total de 700 fotos enviadas para classificação, ou seja, o processo de extração de features ocorreu 700 vezes.
No AWS CloudWatch podemos monitorar a quantidade de funções que estavam executando simultaneamente alguma requisição. Como o Features Service é o que mais consome recursos computacionais dos que foram definidos na arquitetura deste trabalho, ele foi o investigado nesta avaliação. Na Figura 24 é apresentada a quantidade de funções do Predict Service que estão respondendo as requisições feitas no teste, o eixo X representa o momento que as funções estavam sendo executadas e o eixo Y representa o número total de funções executando simultaneamente.
Apesar do gráfico gerado no AWS CloudWatch possuir pouca granularidade, pode- mos observar que o pico de funções executando simultaneamente é de 448, o que significa que a partir do momento que 448 funções foram criadas, não houve mais a necessidade da criação de novas funções para atender as próximas requisições. Como cada função
Capítulo 5. Avaliação 51
Figura 24 – Representação do número de funções executando simultaneamente
do Predict Service possui 1536 megabytes de memória, o total de recursos de memória utilizando neste teste foi de aproximadamente 688 gigabytes.
Montar uma infraestrutura física para suportar esse nível de escalabilidade e custo de recursos computacionais é inviável. Apesar do alto valor de uso de memória, o custo de utilização de funções Lambda é muito baixo, permitindo que essa quantidade de uso seja possível em um projeto real. Todos os testes executados neste trabalho não geraram custos, pois todo o uso de recursos computacionais utilizados estavam dentro da faixa fornecida gratuitamente pela AWS.
Com a finalidade de garantir que no último teste de carga apresentado há o momento em que não é necessária a criação de novas funções, executamos um script que faz requisições diretas para o Features Service, a ideia do script é executar 100 requisições, fazendo uma requisição por segundo, e em cada uma delas enviar 7 fotos para a extração de features, assim simulando o comportamento do sistema. As requisições desse experimento também podem ser representados pela Figura 23.
Executando o script obtivemos o resultado da Figura 25, onde o eixo X representa o tempo decorrido do experimento e o eixo Y o tempo de resposta das requisições. Cada pico apresentado no gráfico representa momentos em que foi necessária a criação de novas funções, isso ocorre devido ao tempo de inicialização das funções em Cold-start. Como há um momento que não aparecem mais picos podemos concluir que o sistema já foi escalado o suficiente para atender o nível de demanda que está recebendo.
Capítulo 5. Avaliação 52
Figura 25 – Tempo médio de resposta das requisições no decorrer da execução do script
5.2.1
Discussão
Ao aplicar a arquitetura genérica aqui proposta no sistema de recomendação, obtivemos bons resultados de processamento comparados à solução monolítica na etapa de Scene Classifier, que engloba toda a etapa de processamento das imagens, pois as features extraídas das imagens durante o processo de predição são reaproveitadas ao trocar apenas a última camada da rede neural, evitando repetições desnecessárias no processamento das imagens. A diferença de tempo entre as soluções MLMA, MLSA (Lambda), MLSA (OpenWhisk) se dão, principalmente, nos tempos de criação dos containers e de acesso aos
dados em tempo de execução.
As etapas de Fuzzyfication e Recommendation se resumem a códigos simples e sequenciais com a finalidade de gerar a recomendação final para o usuário, nestas etapas não há muito uso de recursos computacionais ou processamento, logo não encontramos muita diferença nos tempos de execução obtidos nos testes.
Para aplicar a arquitetura e fazer todos os componentes conversarem corretamente entre sí foi necessário realizar várias configurações nos códigos dos serviços e, para o caso de Serverless, no arquivo que define as funções criadas (Apresentado anteriormente na Figura 9). Assim, é visível que a aplicação da arquitetura exige tempo e esforço, que, dependendo da solução que for utilizá-la, pode não ser vantajoso. Um framework que simplifique essa etapa seria cômodo para a utilização da solução.
Apesar de arquiteturas baseadas em microsserviços apresentarem diversas vantagens, que já foram abordadas anteriormente, manter um sistema utilizado por vários usuários nesse tipo de arquitetura pode ser uma tarefa complexa, pois é necessário configurar toda a parte de escalabilidade e comunicações entre os serviços (chamadas HTTP), fazendo com o que uso de Serverless seja mais interessante, pois podem hospedar e executar sistemas modularizados sem que seja necessário definir configurações para a escalabilidade do sistema.
53
6 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 algoritmos de ML como serviç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 serviç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.
Para modelar os serviços, Pahl utilizou uma arquitetura de middleware (PAHL; CARLE; KLINKER, 2016) que já estava preparada para armazenamento e comunicação de dados. Apesar dessa solução engoblar a etapa de treinamento, o que não foi tratado neste trabalho de mestrado, ela não trabalha a fragmentação das etapas de ML em serviços menores, não paraleliza as etapas de processamento dos dados, não informa os recursos computacionais utilizados para executar os testes e não deixa claro o caminho que deve ser seguido para implementar a solução em algum outro projeto.
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 paralelizar e utilizar 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 de uma DNN.
Ao trabalhar com vários serviços, desafios surgem como a maneira correta de hospedar 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 containers 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 monitorar 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 26. 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.
O componente de monitoramento visto na arquitetura de (ANDERSON, 2018) é onde ocorre a etapa de classificação dos dados capturados dos containers. Assim, o uso
Capítulo 6. Trabalhos Relacionados 54
Figura 26 – Arquitetura para monitoramento do ambiente dos containers Docker. (Fonte: (ANDERSON, 2018))
de Machine Learning nesse projeto está centralizado apenas nesse componente, que não possui um tratamento de fragmentação das etapas, escalabilidade e paralelização. Apesar do trabalho não apresentar testes com tempos de execução, a arquitetura MLSA poderia ser aplicada especificamente neste componente de monitoramento, trazendo os benefícios da tecnologia Serverless e uma melhora no desempenho ao classificar os dados.
Ainda seguindo a linha de monitoramento, o trabalho de (LEE; SHIN; SONG, 2017) monitora 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 (BERNSTEIN, 2014), hospedam a aplicação que faz o processamento das imagens e distribuem os recursos computacionais. Enquanto que 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. Ambas as soluções se assemelham ao que é apresentado na arquitetura MLMA na ideia de utilizar conteiners Docker para os serviços, mas sem técnicas de otimização para o tempo de processamento dos dados ou escalabilidade.
A fim de validar o uso de Deep Learning e Serverless, o trabalho de (ISHAKIAN; MUTHUSAMY; SLOMINSKI, 2018) realiza testes com AWS Lambda e três redes neurais diferentes (SqueezeNet, ResNet e ResNeXt). As redes utilizadas não são tão precisas e pesadas quanto a Inception V3. O autor valida o uso de ML com Serverless e afirma que em um ambiente Serverless com recursos de GPU teríamos resultados melhores de execução. Os testes executados neste trabalho são semelhantes aos apresentados no Capítulo 3 desta dissertação, como exemplo na Figura 27 temos a latência ao fazer predições utilizando a rede neural ResNet com as funções em Cold-start, o eixo X representa a quantidade de memória das funções e o eixo Y o intervalo de tempo em segundos.
Capítulo 6. Trabalhos Relacionados 55
Figura 27 – Execução de funções em Cold-start utilizando a rede ResNet (Fonte: (ISHA- KIAN; MUTHUSAMY; SLOMINSKI, 2018))
SAMY; SLOMINSKI, 2018) possuem um padrão muito similar com os obtidos neste trabalho, pois a latência tende a diminuir com o aumento de memória para as funções Lambda. Embora o autor tenha feito validações com três tipos de redes neurais, o estudo não sugere a fragmentação e paralelização das etapas de classificação das imagens para uma melhor performance, assim como foi apresentado nesta dissertação.
A etapa de treinamento de modelos de ML também é uma etapa importante e pode ser vantajosa de executar em servidores remotos. Assim, (FENG et al., 2018) explora o treinamento de modelos utilizando Serverless e compara os tempos de execução com um computador Desktop utilizando técnicas de paralelismo. Os resultados mostraram-se promissores, validando o uso de Serverless na etapa de treinamento de redes neurais, mas o autor explica que uma limitação da solução é a quantidade de dados utilizados durante o treinamento e a latência para fazer o download de todos os dados necessários. Apesar do trabalho não abordar a etapa de predição, é dado um bom direcionamento para a criação de uma solução genêrica que faça uso de Serverless para o treinamento de modelos de ML, aproveitando técnicas de paralelização, que é um trabalho futuro almejado desta dissertação.
Dentre os trabalhos relacionados estudados, o que mais se assemelha à solução MLSA apresentada é o de (PAHL; CARLE; KLINKER, 2016), que encapsula algoritmos de ML como serviços sem aplicar técnicas de paralelização, mas não foi possível fazer uma análise comparativa de tempos de execução pelo fato de não estar claro como reproduzir ou utilizar a solução apresentada pelo autor.
56
7 Conclusão
Neste trabalho, foi apresentada uma arquitetura genérica para classificação de dados, 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 Serverless. Como resultado deste trabalho foi publicado um artigo com título de A Microservice Based Architecture Topology for Machine Learning Deployment (RIBEIRO et al., 2019) na conferência IEEE International Smart Cities Conference, Casablanca/Morocco.
7.1
Contribuições
As principais contribuições deste trabalho são: (i) validar o uso de Serverless com modelos de Machine Learning para classificação de dados; (ii) propor uma arquitetura baseada em Serveless para classificação de dados; (iii) apresentar a aplicação da arquitetura proposta em um projeto existente que foi utilizado de maneira monolítica; (iv) avaliar a arquitetura proposta em comparação com outras soluções desenvolvidas utilizando microsserviços e arquitetura monolítica.
Validar o uso de Serverless com modelos de Machine Learning para classificação de dados. O Capítulo 3 mostra a utilização de funções serverless para hospedar um serviço de classificação de imagem. São apresentadas as possibilidades armazenamento dos dados ao utilizar esse tipo de tecnologia para explicar as decisões tomadas. A rede neural utilizada no experimento foi a Inception V3.
Propor uma arquitetura baseada em Serveless para classificação de da- dos. No Capítulo 4 é apresentada a arquitetura genêrica proposta neste trabalho. O funcionamento de cada componente da arquitetura é descrito, explicando como ocorre a comunicação entre eles.
Apresentar a instanciação da arquitetura proposta em um projeto real que foi desenvolvido de forma monolítica. Para exemplificar o uso da arquitetura, um sistema de recomendações de pontos turísticos que faz análise de fotos (FIGUEREDO et al., 2018) foi modularizado e implementado seguindo a definição dos componentes propostos na arquitetura genêrica deste trabalho.
Avaliar a arquitetura proposta em comparação com outras soluções de- senvolvidas utilizando microsserviços e arquitetura monolítica. Nos resultados apresentados no capítulo 5 temos que houve uma diminuição no tempo da requisição para as análises das fotos com a solução proposta. Serverless foi avaliado e testado como uma solução para servir modelos de Machine Learning, tendo bons resultados e sendo uma solução promissora. Temos o comparativo dos tempos de cada etapa da plataforma para
Capítulo 7. Conclusão 57 cada abordagem utilizada. Uma discussão sobre os resultados obtidos é feita.
7.2
Limitações
Ambiente de teste. 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. Esforço para mapear e desenvolver um projeto na arquitetura proposta. Apesar da arquitetura estar bem modularizada e explicada, há um esforço considerável para aplicá-la. Toda a comunicação entre os componentes precisa ser implementada e configurada. Além disso, caso exista apenas um modelo de predição que faz todas as classificações de alguma solução, seria necessário retreinar os modelos, assim obtendo as vantagens de paralelização com classificadores multi-label.
Outros trabalhos que façam validações semelhantes para fazer compara- ções. Ao pesquisar na literatura, não foi encontrado trabalhos que apresentassem outras alternativas de arquitetura em nuvem para soluções de Machine Learning e poucos faziam validações de classificação em servidores remotos.
Ameaças à validade da experimentação. Como os testes foram executados utilizando diferentes conexões domésticas de internet, há a possibilidade de oscilação da conexão. Assim, os testes foram executados diversas vezes para tentar mitigar este problema e garantir a qualidade dos resultados.
7.3
Trabalhos futuros
Este trabalho apresenta um arquitetura para ser utilizada em projetos que façam uso de Machine Learning, para a continuação do estudo é almejado:
Criação de um framework. Um framework para criação de serviços de nuvem para projeto de Machine Learning seguindo a arquitetura proposta. O objetivo deste framework é diminuir o esforço para mapear e desenvolver um projeto na arquitetura proposta.
Treinamento de modelos. A arquitetura contempla a etapa de classificação, ou seja, os modelos de predição devem estar treinados e prontos para classificar os dados recebidos. A etapa de treinamento de modelos pode ser estudada e mapeada para executar em servidores remotos, assim como foi apresentado por (FENG et al., 2018).
Mais testes e comparações com novos trabalhos. Visto que Machine Learning em serviços de nuvem não é uma área que tenha sido muito explorada, novos trabalhos relacionados estão surgindo constantemente. Mais testes e comparações com esses novos trabalhos são essenciais para validar e aprimorar a solução apresentada.
58
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. Citado na página 21. ANDERSON, R. From bare metal to private cloud: Introducing devsecops and cloud technologies to naval systems. 2018. Citado 3 vezes nas páginas 10, 53 e 54.
ARMBRUST, M. et al. A view of cloud computing. Communications of the ACM, ACM, v. 53, n. 4, p. 50–58, 2010. Citado na página 15.
BALDINI, I. et al. Serverless computing: Current trends and open problems. In: Research Advances in Cloud Computing. [S.l.]: Springer, 2017. p. 1–20. Citado na página 22. BARNARD, K. CNCF Survey: Use of Cloud Native Technologies in Production Has Grown Over 200%. 2018. Aug., 2018. Disponível em: <<https://www.cncf.io/blog/2018/08/29/
cncf-survey-use-of-cloud-native-technologies-in-production-has-grown-over-200-percent/ >>. Acesso em Dezembro 20, 2019. Citado 2 vezes nas páginas 9 e 23.
BERNSTEIN, D. Containers and cloud: From lxc to docker to kubernetes. IEEE Cloud Computing, IEEE, n. 3, p. 81–84, 2014. Citado na página 54.
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. Citado na página 38.
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. Citado na página 21.