Entrada
Hi!
En este artículo, compartiré mi experiencia en la creación de una arquitectura de microservicios para un proyecto que utiliza redes neuronales.
Hablemos de los requisitos de la arquitectura, veamos varios diagramas estructurales, analicemos cada uno de los componentes de la arquitectura terminada y también evaluemos las métricas técnicas de la solución.
¡Disfruta leyendo!
Algunas palabras sobre el problema y su solución.
La idea principal es evaluar el atractivo de una persona en una escala de diez puntos basándose en una fotografía.
En este artículo dejaremos de describir tanto las redes neuronales utilizadas como el proceso de preparación y entrenamiento de datos. Sin embargo, en una de las siguientes publicaciones, definitivamente volveremos a analizar el proceso de evaluación en profundidad.
Ahora pasaremos por el proceso de evaluación en el nivel superior y nos centraremos en la interacción de los microservicios en el contexto de la arquitectura general del proyecto.
Al trabajar en el proceso de evaluación del atractivo, la tarea se dividió en los siguientes componentes:
- Seleccionar caras en fotografías
- Calificación de cada persona
- renderizar el resultado
El primero se resuelve mediante las fuerzas de los preentrenados. . Para el segundo, se entrenó una red neuronal convolucional en PyTorch, utilizando – del equilibrio “calidad / velocidad de inferencia en la CPU”
Diagrama funcional del proceso de evaluación.
Análisis de los requisitos de la arquitectura del proyecto.
en el ciclo de vida Las etapas de trabajo del proyecto sobre la arquitectura y la automatización de la implementación del modelo suelen estar entre las que consumen más tiempo y recursos.
Ciclo de vida de un proyecto ML
Este proyecto no es una excepción: se tomó la decisión de envolver el proceso de evaluación en un servicio en línea, lo que requirió sumergirnos en la arquitectura. Se identificaron los siguientes requisitos básicos:
- Almacenamiento de registros unificado: todos los servicios deben escribir registros en un solo lugar, deben ser fáciles de analizar
- Posibilidad de escalamiento horizontal del servicio de evaluación, como el cuello de botella más probable
- Se debe asignar la misma cantidad de recursos del procesador para evaluar cada imagen a fin de evitar valores atípicos en la distribución del tiempo para la inferencia.
- (Re)implementación rápida tanto de servicios específicos como de la pila en su conjunto
- La capacidad, si es necesario, de utilizar objetos comunes en diferentes servicios.
Arquitectura
Después de analizar los requisitos, resultó obvio que la arquitectura de microservicios encaja casi a la perfección.
Para deshacerse de dolores de cabeza innecesarios, se eligió la API de Telegram como interfaz.
Primero, veamos el diagrama estructural de la arquitectura terminada, luego pasemos a una descripción de cada uno de los componentes y también formalicemos el proceso de procesamiento exitoso de imágenes.
Diagrama estructural de la arquitectura terminada.
Hablemos con más detalle de cada uno de los componentes del diagrama, denotándolos Responsabilidad Única en el proceso de evaluación de imágenes.
Microservicio “attrai-telegram-bot”
Este microservicio encapsula todas las interacciones con la API de Telegram. Hay dos escenarios principales: trabajar con una imagen personalizada y trabajar con el resultado de un proceso de evaluación. Veamos ambos escenarios en términos generales.
Al recibir un mensaje personalizado con una imagen:
- Se realiza la filtración, que consta de las siguientes comprobaciones:
- Disponibilidad de tamaño de imagen óptimo
- Número de imágenes de usuarios que ya están en cola
- Al pasar el filtrado inicial, la imagen se guarda en el volumen acoplable
- Se produce una tarea en la cola “to_estimate”, que incluye, entre otras cosas, la ruta a la imagen ubicada en nuestro volumen.
- Si los pasos anteriores se completan con éxito, el usuario recibirá un mensaje con el tiempo aproximado de procesamiento de la imagen, que se calcula en función de la cantidad de tareas en la cola. Si se produce un error, se notificará explícitamente al usuario enviando un mensaje con información sobre lo que pudo haber salido mal.
Además, este microservicio, como un trabajador de apio, escucha la cola "after_estimate", que está destinada a tareas que han pasado por el proceso de evaluación.
Al recibir una nueva tarea de “after_estimate”:
- Si la imagen se procesa exitosamente, enviamos el resultado al usuario; si no, notificamos un error.
- Eliminar la imagen que es el resultado del proceso de evaluación
Microservicio de evaluación “attrai-estimator”
Este microservicio funciona con apio y encapsula todo lo relacionado con el proceso de evaluación de imágenes. Aquí sólo hay un algoritmo que funciona: analicémoslo.
Al recibir una nueva tarea de “to_estimate”:
- Ejecutemos la imagen a través del proceso de evaluación:
- Cargando la imagen en la memoria
- Llevamos la imagen al tamaño requerido.
- Encontrar todas las caras (MTCNN)
- Evaluamos todas las caras (envolvemos las caras encontradas en el último paso en un lote e inferimos ResNet34)
- Renderizar la imagen final
- Dibujemos los cuadros delimitadores.
- Dibujando las calificaciones
- Eliminar una imagen personalizada (original)
- Guardar el resultado del proceso de evaluación
- Colocamos la tarea en la cola "after_estimate", que es escuchada por el microservicio "attrai-telegram-bot" mencionado anteriormente.
Graylog (+ mongoDB + Elasticsearch)
es una solución para la gestión centralizada de registros. En este proyecto, se utilizó para el propósito previsto.
La elección recayó en él, y no en la habitual. stack, debido a la conveniencia de trabajar con él desde Python. Todo lo que necesita hacer para iniciar sesión en Graylog es agregar GELFTCPHandler desde el paquete. al resto de los controladores de registro raíz de nuestro microservicio de Python.
Como alguien que anteriormente solo había trabajado con la pila ELK, tuve una experiencia positiva en general mientras trabajaba con Graylog. Lo único deprimente es la superioridad de las funciones de Kibana sobre la interfaz web de Graylog.
RabbitMQ
es un intermediario de mensajes basado en el protocolo AMQP.
En este proyecto se utilizó como corredor de Apio y trabajó en modo duradero.
Redis
es un DBMS NoSQL que funciona con estructuras de datos clave-valor
A veces es necesario utilizar objetos comunes que implementen determinadas estructuras de datos en diferentes microservicios de Python.
Por ejemplo, Redis almacena un mapa hash del formato "telegram_user_id => número de tareas activas en la cola", lo que le permite limitar el número de solicitudes de un usuario a un valor determinado y, así, prevenir ataques DoS.
Formalicemos el proceso de procesamiento de imágenes exitoso.
- El usuario envía una imagen al bot de Telegram
- "attrai-telegram-bot" recibe un mensaje de la API de Telegram y lo analiza
- La tarea con la imagen se agrega a la cola asincrónica “to_estimate”
- El usuario recibe un mensaje con el tiempo de evaluación planificado.
- "attrai-estimator" toma una tarea de la cola "to_estimate", ejecuta las estimaciones a través del proceso y produce la tarea en la cola "after_estimate"
- "attrai-telegram-bot" escuchando la cola "after_estimate", envía el resultado al usuario
DevOps
Finalmente, después de revisar la arquitectura, puede pasar a la parte igualmente interesante: DevOps.
Enjambre Docker
— un sistema de agrupación en clústeres, cuya funcionalidad se implementa dentro de Docker Engine y está disponible de fábrica.
Usando un "enjambre", todos los nodos de nuestro clúster se pueden dividir en 2 tipos: trabajador y administrador. En las máquinas del primer tipo se despliegan grupos de contenedores (pilas), las máquinas del segundo tipo se encargan de escalar, equilibrar y . Los gerentes también son trabajadores por defecto.
Clúster con un líder directivo y tres trabajadores.
El tamaño mínimo de clúster posible es 1 nodo; una sola máquina actuará simultáneamente como administrador líder y trabajador. Según el tamaño del proyecto y los requisitos mínimos de tolerancia a fallos, se decidió utilizar este enfoque.
De cara al futuro, diré que desde la primera entrega de producción, que tuvo lugar a mediados de junio, no ha habido problemas asociados con esta organización del clúster (pero esto no significa que dicha organización sea de ninguna manera aceptable en cualquier empresa mediana o grande). proyectos, que están sujetos a requisitos de tolerancia a fallos).
Pila acoplable
En modo enjambre, es responsable de implementar pilas (conjuntos de servicios acoplables)
Admite configuraciones de Docker-Compose, lo que le permite utilizar adicionalmente parámetros de implementación.
Por ejemplo, usando estos parámetros, los recursos para cada una de las instancias del microservicio de evaluación eran limitados (asignamos N núcleos para N instancias, en el microservicio en sí limitamos la cantidad de núcleos utilizados por PyTorch a uno)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…Es importante tener en cuenta que Redis, RabbitMQ y Graylog son servicios con estado y no se pueden escalar tan fácilmente como "attrai-estimator".
Presagiando la pregunta: ¿por qué no Kubernetes?
Parece que usar Kubernetes en proyectos pequeños y medianos es una sobrecarga; toda la funcionalidad necesaria se puede obtener de Docker Swarm, que es bastante fácil de usar para un orquestador de contenedores y también tiene una barrera de entrada baja.
Infraestructura
Todo esto fue desplegado sobre VDS con las siguientes características:
- CPU: CPU Intel® Xeon® Gold 4 de 5120 núcleos a 2.20 GHz
- RAM: 8 GB
- SSD: 160GB
Después de las pruebas de carga locales, parecía que con una gran afluencia de usuarios, esta máquina sería suficiente.
Pero, inmediatamente después de la implementación, publiqué un enlace a uno de los tableros de imágenes más populares de la CEI (sí, ese mismo), después de lo cual la gente se interesó y en unas pocas horas el servicio procesó con éxito decenas de miles de imágenes. Al mismo tiempo, en los momentos pico, los recursos de CPU y RAM no se utilizaban ni la mitad.
Algunos gráficos más
Número de usuarios únicos y solicitudes de evaluación desde la implementación, según el día
Distribución del tiempo de inferencia del canal de evaluación
Hallazgos
En resumen, puedo decir que la arquitectura y el enfoque de la orquestación de contenedores se justificaron plenamente: incluso en los momentos pico no hubo caídas ni caídas en el tiempo de procesamiento.
Creo que los proyectos pequeños y medianos que utilizan inferencia en tiempo real de redes neuronales en la CPU en su proceso pueden adoptar con éxito las prácticas descritas en este artículo.
Agregaré que inicialmente el artículo era más largo, pero para no publicar una lectura larga, decidí omitir algunos puntos en este artículo; volveremos a ellos en publicaciones futuras.
Puedes pinchar el bot en Telegram: @AttraiBot, funcionará al menos hasta finales de otoño de 2020. Permítanme recordarles que no se almacenan datos del usuario, ni las imágenes originales ni los resultados del proceso de evaluación; todo se elimina después del procesamiento.
Fuente: habr.com