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.