Entrada
Oi!
Neste artigo compartilharei minha experiência na construção de uma arquitetura de microsserviços para um projeto utilizando redes neurais.
Vamos falar sobre os requisitos da arquitetura, observar vários diagramas estruturais, analisar cada um dos componentes da arquitetura finalizada e também avaliar as métricas técnicas da solução.
Aproveite a leitura!
Algumas palavras sobre o problema e sua solução
A ideia principal é avaliar a atratividade de uma pessoa em uma escala de dez pontos com base em uma foto.
Neste artigo deixaremos de descrever as redes neurais utilizadas e o processo de preparação e treinamento de dados. No entanto, numa das publicações seguintes, voltaremos definitivamente à análise aprofundada do pipeline de avaliação.
Agora passaremos pelo pipeline de avaliação no nível superior e nos concentraremos na interação de microsserviços no contexto da arquitetura geral do projeto.
Ao trabalhar no pipeline de avaliação de atratividade, a tarefa foi decomposta nos seguintes componentes:
- Selecionando rostos em fotos
- Avaliação de cada pessoa
- Renderize o resultado
O primeiro é resolvido pelas forças de pré-treinados . Para o segundo, uma rede neural convolucional foi treinada em PyTorch, usando – do equilíbrio “qualidade/velocidade de inferência na CPU”
Diagrama funcional do pipeline de avaliação
Análise dos requisitos de arquitetura do projeto
No ciclo de vida os estágios de trabalho do projeto na arquitetura e na automação da implantação do modelo estão frequentemente entre os mais demorados e que consomem mais recursos.
Ciclo de vida de um projeto de ML
Este projeto não é exceção - foi tomada a decisão de envolver o pipeline de avaliação em um serviço online, o que exigiu uma imersão na arquitetura. Foram identificados os seguintes requisitos básicos:
- Armazenamento unificado de logs – todos os serviços devem gravar logs em um só lugar, devem ser fáceis de analisar
- Possibilidade de escalonamento horizontal do serviço de avaliação – como gargalo mais provável
- A mesma quantidade de recursos do processador deve ser alocada para avaliar cada imagem, a fim de evitar discrepâncias na distribuição do tempo para inferência
- (Re)implantação rápida de serviços específicos e da pilha como um todo
- A capacidade, se necessário, de usar objetos comuns em diferentes serviços
Arquitetura
Depois de analisar os requisitos, ficou óbvio que a arquitetura de microsserviços se encaixava quase perfeitamente.
Para se livrar de dores de cabeça desnecessárias, a API do Telegram foi escolhida como frontend.
Primeiro, vamos dar uma olhada no diagrama estrutural da arquitetura finalizada, depois passar para a descrição de cada um dos componentes e também formalizar o processo de processamento de imagem bem-sucedido.
Diagrama estrutural da arquitetura acabada
Vamos falar mais detalhadamente sobre cada um dos componentes do diagrama, denotando-os como Responsabilidade Única no processo de avaliação de imagens.
Microsserviço “attrai-telegram-bot”
Este microsserviço encapsula todas as interações com a API do Telegram. Existem 2 cenários principais: trabalhar com uma imagem personalizada e trabalhar com o resultado de um pipeline de avaliação. Vejamos ambos os cenários em termos gerais.
Ao receber uma mensagem personalizada com uma imagem:
- A filtragem é realizada, consistindo nas seguintes verificações:
- Disponibilidade de tamanho de imagem ideal
- Número de imagens do usuário já na fila
- Ao passar pela filtragem inicial, a imagem é salva no volume docker
- Uma tarefa é produzida na fila “to_estimate”, que inclui, entre outras coisas, o caminho para a imagem localizada em nosso volume
- Caso as etapas acima sejam concluídas com sucesso, o usuário receberá uma mensagem com o tempo aproximado de processamento da imagem, que é calculado com base na quantidade de tarefas na fila. Caso ocorra algum erro, o usuário será explicitamente notificado através do envio de uma mensagem com informações sobre o que pode ter acontecido.
Além disso, esse microsserviço, como um trabalhador de aipo, escuta a fila “after_estimate”, que se destina a tarefas que passaram pelo pipeline de avaliação.
Ao receber uma nova tarefa de “after_estimate”:
- Se a imagem for processada com sucesso, enviamos o resultado ao usuário; caso contrário, notificamos sobre um erro.
- Removendo a imagem que é o resultado do pipeline de avaliação
“Atrai-estimador” de microsserviço de avaliação
Este microsserviço é um trabalhador de aipo e encapsula tudo relacionado ao pipeline de avaliação de imagem. Há apenas um algoritmo funcional aqui – vamos analisá-lo.
Ao receber uma nova tarefa de “to_estimate”:
- Vamos executar a imagem no pipeline de avaliação:
- Carregando a imagem na memória
- Trazemos a imagem para o tamanho necessário
- Encontrando todos os rostos (MTCNN)
- Avaliamos todas as faces (envolvemos as faces encontradas na última etapa em um lote e inferência do ResNet34)
- Renderize a imagem final
- Vamos desenhar as caixas delimitadoras
- Desenhando as classificações
- Excluindo uma imagem personalizada (original)
- Salvando a saída do pipeline de avaliação
- Colocamos a tarefa na fila “after_estimate”, que é ouvida pelo microsserviço “attrai-telegram-bot” discutido acima.
Graylog (+ mongoDB + Elasticsearch)
é uma solução para gerenciamento centralizado de logs. Neste projeto, foi utilizado para o fim a que se destina.
A escolha recaiu sobre ele, e não sobre o habitual pilha, devido à conveniência de trabalhar com ela em Python. Tudo que você precisa fazer para logar no Graylog é adicionar o GELFTCPHandler do pacote para o restante dos manipuladores do logger raiz do nosso microsserviço python.
Como alguém que anteriormente havia trabalhado apenas com a pilha ELK, tive uma experiência geral positiva ao trabalhar com o Graylog. A única coisa deprimente é a superioridade dos recursos do Kibana em relação à interface web do Graylog.
RabbitMQ
é um corretor de mensagens baseado no protocolo AMQP.
Neste projeto foi utilizado como corretor para Celery e funcionou em modo durável.
Redis
é um SGBD NoSQL que funciona com estruturas de dados de valor-chave
Às vezes, é necessário usar objetos comuns que implementem determinadas estruturas de dados em diferentes microsserviços Python.
Por exemplo, o Redis armazena um hashmap no formato “telegram_user_id => número de tarefas ativas na fila”, que permite limitar o número de solicitações de um usuário a um determinado valor e, assim, evitar ataques DoS.
Vamos formalizar o processo de processamento de imagem bem-sucedido
- O usuário envia uma imagem para o bot do Telegram
- "attrai-telegram-bot" recebe uma mensagem da API do Telegram e a analisa
- A tarefa com a imagem é adicionada à fila assíncrona “to_estimate”
- O usuário recebe uma mensagem com o horário de avaliação planejado
- “attrai-estimator” pega uma tarefa da fila “to_estimate”, executa as estimativas através do pipeline e produz a tarefa na fila “after_estimate”
- “attrai-telegram-bot” ouvindo a fila “after_estimate”, envia o resultado para o usuário
DevOps
Finalmente, depois de revisar a arquitetura, você pode passar para a parte igualmente interessante – DevOps
Docker swarm
— um sistema de cluster cuja funcionalidade é implementada dentro do Docker Engine e está disponível imediatamente.
Usando um “enxame”, todos os nós do nosso cluster podem ser divididos em 2 tipos – trabalhador e gerente. Nas máquinas do primeiro tipo são implantados grupos de contêineres (pilhas), as máquinas do segundo tipo são responsáveis por dimensionar, balancear e . Os gerentes também são trabalhadores por padrão.
Cluster com um gerente líder e três trabalhadores
O tamanho mínimo possível do cluster é de 1 nó; uma única máquina atuará simultaneamente como gerente líder e trabalhador. Com base no tamanho do projeto e nos requisitos mínimos de tolerância a falhas, decidiu-se utilizar esta abordagem.
Olhando para o futuro, direi que desde a primeira entrega de produção, que ocorreu em meados de Junho, não houve problemas associados a esta organização de cluster (mas isto não significa que tal organização seja de alguma forma aceitável em qualquer empresa de médio e grande porte). projetos, que estão sujeitos a requisitos de tolerância a falhas).
Pilha Docker
No modo swarm, ele é responsável por implantar stacks (conjuntos de serviços docker)
Ele suporta configurações docker-compose, permitindo que você use parâmetros de implantação adicionais.
Por exemplo, usando esses parâmetros, os recursos para cada uma das instâncias de microsserviço de avaliação foram limitados (alocamos N núcleos para N instâncias, no próprio microsserviço limitamos o número de núcleos usados pelo PyTorch a um)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…É importante observar que Redis, RabbitMQ e Graylog são serviços com estado e não podem ser escalonados tão facilmente como “attrai-estimator”
Prenunciando a questão – por que não o Kubernetes?
Parece que usar o Kubernetes em projetos de pequeno e médio porte é uma sobrecarga; todas as funcionalidades necessárias podem ser obtidas no Docker Swarm, que é bastante fácil de usar para um orquestrador de contêineres e também tem uma baixa barreira de entrada.
Infra-estrutura
Tudo isso foi implantado no VDS com as seguintes características:
- CPU: CPU Intel® Xeon® Gold 4 de 5120 núcleos a 2.20 GHz
- RAM: 8 GB
- SSD: 160GB
Após testes de carga local, parecia que com um grande fluxo de usuários, esta máquina seria suficiente.
Mas, imediatamente após a implantação, postei um link para um dos imageboards mais populares do CIS (sim, aquele mesmo), após o qual as pessoas se interessaram e em poucas horas o serviço processou com sucesso dezenas de milhares de imagens. Ao mesmo tempo, em momentos de pico, os recursos de CPU e RAM não eram nem metade utilizados.
Mais alguns gráficos
Número de usuários únicos e solicitações de avaliação desde a implantação, dependendo do dia
Distribuição do tempo de inferência do pipeline de avaliação
Descobertas
Resumindo, posso dizer que a arquitetura e a abordagem de orquestração de contêineres se justificaram plenamente - mesmo nos momentos de pico não houve quedas ou quedas no tempo de processamento.
Acredito que projetos de pequeno e médio porte que utilizam inferência em tempo real de redes neurais na CPU em seus processos podem adotar com sucesso as práticas descritas neste artigo.
Acrescento que inicialmente o artigo era mais longo, mas para não postar uma leitura longa, resolvi omitir alguns pontos deste artigo - voltaremos a eles em publicações futuras.
Você pode cutucar o bot no Telegram - @AttraiBot, ele funcionará pelo menos até o final do outono de 2020. Deixe-me lembrá-lo de que nenhum dado do usuário é armazenado - nem as imagens originais, nem os resultados do pipeline de avaliação - tudo é demolido após o processamento.
Fonte: habr.com