Entrada
Hi!
En aquest article compartiré la meva experiència en la construcció d'una arquitectura de microservei per a un projecte amb xarxes neuronals.
Parlem dels requisits de l'arquitectura, mirem diversos diagrames estructurals, analitzem cadascun dels components de l'arquitectura acabada i també avaluem les mètriques tècniques de la solució.
Gaudeix de llegir
Unes paraules sobre el problema i la seva solució
La idea principal és avaluar l'atractiu d'una persona en una escala de deu punts a partir d'una foto.
En aquest article ens allunyarem de descriure tant les xarxes neuronals utilitzades com el procés de preparació i formació de dades. Tanmateix, en una de les publicacions següents, definitivament tornarem a analitzar el canal d'avaluació a un nivell en profunditat.
Ara passarem pel canal d'avaluació al nivell superior i ens centrarem en la interacció dels microserveis en el context de l'arquitectura global del projecte.
Quan es treballava en el pipeline d'avaluació de l'atractiu, la tasca es va descompondre en els components següents:
- Selecció de cares a les fotos
- Valoració de cada persona
- Representa el resultat
El primer el resolen les forces de pre-entrenats . Per al segon, es va entrenar una xarxa neuronal convolucional a PyTorch, utilitzant - de l'equilibri "qualitat / velocitat d'inferència a la CPU"
Diagrama funcional del pipeline d'avaluació
Anàlisi dels requisits d'arquitectura del projecte
En el cicle vital Les etapes de treball del projecte sobre l'arquitectura i l'automatització del desplegament de models solen estar entre les que consumeixen més temps i recursos.
Cicle de vida d'un projecte ML
Aquest projecte no és una excepció: es va decidir embolicar el canal d'avaluació en un servei en línia, que requeria submergir-nos en l'arquitectura. S'han identificat els requisits bàsics següents:
- Emmagatzematge de registres unificat: tots els serveis haurien d'escriure registres en un sol lloc i haurien de ser convenients d'analitzar
- Possibilitat d'escalat horitzontal del servei d'avaluació - com a coll d'ampolla més probable
- S'ha d'assignar la mateixa quantitat de recursos del processador per avaluar cada imatge per tal d'evitar punts atípics en la distribució del temps per a la inferència.
- (re)implementació ràpida tant de serveis específics com de la pila en conjunt
- La capacitat, si cal, d'utilitzar objectes comuns en diferents serveis
arquitectura
Després d'analitzar els requisits, es va fer evident que l'arquitectura del microservei s'adapta gairebé perfectament.
Per tal de desfer-se dels maldecaps innecessaris, es va triar l'API de Telegram com a interfície.
Primer, mirem el diagrama estructural de l'arquitectura acabada, després passem a una descripció de cadascun dels components i també formalitzem el procés de processament d'imatges amb èxit.
Esquema estructural de l'arquitectura acabada
Parlem amb més detall de cadascun dels components del diagrama, denotant-los Responsabilitat Única en el procés d'avaluació de la imatge.
Microservei "attrai-telegram-bot"
Aquest microservei encapsula totes les interaccions amb l'API de Telegram. Hi ha 2 escenaris principals: treballar amb una imatge personalitzada i treballar amb el resultat d'un pipeline d'avaluació. Vegem els dos escenaris en termes generals.
Quan rebeu un missatge personalitzat amb una imatge:
- Es realitza la filtració, que consisteix en les comprovacions següents:
- Disponibilitat d'una mida d'imatge òptima
- Nombre d'imatges d'usuari que ja estan a la cua
- Quan es passa el filtratge inicial, la imatge es desa al volum docker
- Es produeix una tasca a la cua "a_estimar", que inclou, entre altres coses, el camí a la imatge situada al nostre volum
- Si els passos anteriors es completen correctament, l'usuari rebrà un missatge amb el temps aproximat de processament de la imatge, que es calcula en funció del nombre de tasques a la cua. Si es produeix un error, l'usuari rebrà una notificació explícita enviant un missatge amb informació sobre què podria haver anat malament.
A més, aquest microservei, com un treballador de l'api, escolta la cua "after_estimate", que està destinada a les tasques que han passat pel canal d'avaluació.
Quan rebeu una tasca nova de "after_estimate":
- Si la imatge es processa amb èxit, enviem el resultat a l'usuari; si no, avisem d'un error.
- Eliminació de la imatge que és el resultat del pipeline d'avaluació
Microservei d'avaluació "attrai-estimator"
Aquest microservei és un treballador de l'api i encapsula tot allò relacionat amb el pipeline d'avaluació d'imatges. Aquí només hi ha un algorisme que funciona: analitzem-lo.
Quan rebeu una tasca nova de "to_estimate":
- Executem la imatge a través del canal d'avaluació:
- Carregant la imatge a la memòria
- Portem la imatge a la mida requerida
- Trobar totes les cares (MTCNN)
- Avaluem totes les cares (emboliquem les cares trobades a l'últim pas en un lot i fem una inferència ResNet34)
- Renderitza la imatge final
- Dibuixem els quadres delimitadors
- Dibuix de les valoracions
- Eliminació d'una imatge personalitzada (original).
- Desar la sortida del pipeline d'avaluació
- Col·loquem la tasca a la cua "after_estimate", que escolta el microservei "attrai-telegram-bot" comentat anteriorment.
Graylog (+ mongoDB + Elasticsearch)
és una solució per a la gestió centralitzada de registres. En aquest projecte, es va utilitzar per al propòsit previst.
L'elecció va recaure en ell, i no en l'habitual stack, a causa de la comoditat de treballar-hi des de Python. Tot el que heu de fer per iniciar sessió a Graylog és afegir el GELFTCPHandler del paquet a la resta de gestors de registre arrel del nostre microservei Python.
Com a algú que abans només havia treballat amb la pila ELK, vaig tenir una experiència global positiva mentre treballava amb Graylog. L'únic que és depriment és la superioritat de les funcions de Kibana sobre la interfície web de Graylog.
ConillMQ
és un agent de missatges basat en el protocol AMQP.
En aquest projecte es va utilitzar com a corredor d'api i va treballar en mode durador.
Redis
és un SGBD NoSQL que funciona amb estructures de dades clau-valor
De vegades és necessari utilitzar objectes comuns que implementin determinades estructures de dades en diferents microserveis de Python.
Per exemple, Redis emmagatzema un hashmap de la forma "telegram_user_id => nombre de tasques actives a la cua", que us permet limitar el nombre de sol·licituds d'un usuari a un valor determinat i, per tant, evitar atacs DoS.
Formalitzem el procés d'èxit del processament d'imatges
- L'usuari envia una imatge al bot de Telegram
- "attrai-telegram-bot" rep un missatge de l'API de Telegram i l'analitza
- La tasca amb la imatge s'afegeix a la cua asíncrona "to_estimate"
- L'usuari rep un missatge amb el temps d'avaluació previst
- "attrai-estimator" agafa una tasca de la cua "to_estimate", executa les estimacions a través del pipeline i produeix la tasca a la cua "after_estimate"
- "attrai-telegram-bot" escoltant la cua "after_estimate", envia el resultat a l'usuari
DevOps
Finalment, després de revisar l'arquitectura, podeu passar a la part igualment interessant: DevOps
docker Swarm
— un sistema de clustering, la funcionalitat del qual s'implementa dins del Docker Engine i està disponible de manera immediata.
Mitjançant un "eixam", tots els nodes del nostre clúster es poden dividir en 2 tipus: treballador i gestor. A les màquines del primer tipus es despleguen grups de contenidors (piles), les màquines del segon tipus s'encarreguen d'escalar, equilibrar i . Els directius també són treballadors per defecte.
Clúster amb un responsable líder i tres treballadors
La mida mínima possible del clúster és d'1 node; una única màquina actuarà simultàniament com a gestor líder i treballador. A partir de la mida del projecte i dels requisits mínims de tolerància a fallades, es va decidir utilitzar aquest enfocament.
De cara al futur, diré que des del primer lliurament de producció, que va ser a mitjans de juny, no hi ha hagut cap problema relacionat amb aquesta organització del clúster (però això no vol dir que aquesta organització sigui de cap manera acceptable en qualsevol organització mitjana-gran). projectes, que estan subjectes a requisits de tolerància a errors).
Docker Stack
En mode eixam, és responsable de desplegar piles (conjunts de serveis docker)
Admet configuracions de docker-compose, cosa que us permet utilitzar, a més, opcions de desplegament.
Per exemple, utilitzant aquests paràmetres, els recursos per a cadascuna de les instàncies del microservei d'avaluació eren limitats (assignem N nuclis per a N instàncies, en el propi microservei limitem el nombre de nuclis utilitzats per PyTorch a un)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…És important tenir en compte que Redis, RabbitMQ i Graylog són serveis amb estat i no es poden escalar tan fàcilment com "attrai-estimator"
Prefigurant la pregunta: per què no Kubernetes?
Sembla que utilitzar Kubernetes en projectes de mida petita i mitjana és una sobrecàrrega; tota la funcionalitat necessària es pot obtenir des de Docker Swarm, que és força fàcil d'utilitzar per a un orquestrador de contenidors i també té una barrera d'entrada baixa.
Infraestructura
Tot això es va desplegar en VDS amb les següents característiques:
- CPU: CPU Intel® Xeon® Gold 4 de 5120 nuclis a 2.20 GHz
- RAM: 8 GB
- SSD: 160 GB
Després de les proves de càrrega local, semblava que amb una gran afluència d'usuaris, aquesta màquina seria suficient.
Però, immediatament després del desplegament, vaig publicar un enllaç a un dels taulers d'imatges més populars del CIS (sí, el mateix), després del qual la gent es va interessar i en poques hores el servei va processar amb èxit desenes de milers d'imatges. Al mateix temps, en els moments màxims, els recursos de CPU i RAM no s'utilitzaven ni a la meitat.
Alguns gràfics més
Nombre d'usuaris únics i sol·licituds d'avaluació des del desplegament, segons el dia
Distribució del temps d'inferència del pipeline d'avaluació
Troballes
Per resumir, puc dir que l'arquitectura i l'enfocament de l'orquestració dels contenidors es justificaven completament, fins i tot en els moments punta no hi havia caigudes ni caigudes en el temps de processament.
Crec que els projectes de mida petita i mitjana que utilitzen la inferència en temps real de xarxes neuronals a la CPU en el seu procés poden adoptar amb èxit les pràctiques descrites en aquest article.
Afegiré que inicialment l'article era més llarg, però per no publicar una lectura llarga, vaig decidir ometre alguns punts en aquest article; hi tornarem en publicacions futures.
Podeu fer servir el bot a Telegram - @AttraiBot, almenys fins a finals de la tardor del 2020. Us recordo que no s'emmagatzemen dades d'usuari, ni les imatges originals, ni els resultats del pipeline d'avaluació, tot s'enderroca després del processament.
Font: www.habr.com