Entrée
Salut!
Dans cet article, je partagerai mon expérience de création d'une architecture de microservices pour un projet utilisant des réseaux de neurones.
Parlons des exigences de l'architecture, examinons divers schémas structurels, analysons chacun des composants de l'architecture finie et évaluons également les mesures techniques de la solution.
Bonne lecture!
Quelques mots sur le problème et sa solution
L’idée principale est d’évaluer l’attractivité d’une personne sur une échelle de dix points à partir d’une photo.
Dans cet article, nous nous éloignerons de la description à la fois des réseaux de neurones utilisés et du processus de préparation et de formation des données. Cependant, dans l’une des publications suivantes, nous reviendrons certainement à l’analyse approfondie du pipeline d’évaluation.
Nous allons maintenant parcourir le pipeline d'évaluation au plus haut niveau et nous concentrer sur l'interaction des microservices dans le contexte de l'architecture globale du projet.
Lors du travail sur le pipeline d'évaluation de l'attractivité, la tâche a été décomposée en les éléments suivants :
- Sélection de visages sur les photos
- Note de chaque personne
- Rendre le résultat
Le premier est résolu par les forces de pré-entraînés . Pour le second, un réseau de neurones convolutifs a été formé sur PyTorch, en utilisant – de la balance « qualité/vitesse d’inférence sur le CPU »
Schéma fonctionnel du pipeline d'évaluation
Analyse des exigences de l'architecture du projet
Dans le cycle de vie Les étapes du projet de travail sur l'architecture et l'automatisation du déploiement des modèles sont souvent parmi les plus longues et les plus gourmandes en ressources.
Cycle de vie d'un projet ML
Ce projet ne fait pas exception : la décision a été prise d'intégrer le pipeline d'évaluation dans un service en ligne, ce qui nécessitait de s'immerger dans l'architecture. Les exigences de base suivantes ont été identifiées :
- Stockage unifié des journaux – tous les services doivent écrire des journaux au même endroit, ils doivent être faciles à analyser
- Possibilité d'une mise à l'échelle horizontale du service d'évaluation - comme goulot d'étranglement le plus probable
- La même quantité de ressources processeur doit être allouée pour évaluer chaque image afin d'éviter les valeurs aberrantes dans la répartition du temps d'inférence.
- (Re)déploiement rapide des services spécifiques et de la pile dans son ensemble
- La possibilité, si nécessaire, d'utiliser des objets communs dans différents services
Architecture
Après avoir analysé les exigences, il est devenu évident que l’architecture des microservices s’adaptait presque parfaitement.
Afin de se débarrasser des maux de tête inutiles, l'API Telegram a été choisie comme interface.
Examinons d'abord le schéma structurel de l'architecture finie, puis passons à une description de chacun des composants, et formalisons également le processus de traitement d'image réussi.
Schéma structurel de l'architecture finie
Parlons plus en détail de chacun des composants du diagramme, en les désignant comme responsabilité unique dans le processus d'évaluation de l'image.
Microservice « atrai-telegram-bot »
Ce microservice encapsule toutes les interactions avec l'API Telegram. Il existe 2 scénarios principaux : travailler avec une image personnalisée et travailler avec le résultat d'un pipeline d'évaluation. Examinons les deux scénarios en termes généraux.
Lors de la réception d'un message personnalisé avec une image :
- La filtration est effectuée et comprend les contrôles suivants :
- Disponibilité d'une taille d'image optimale
- Nombre d'images utilisateur déjà en file d'attente
- Lors du passage du filtrage initial, l'image est enregistrée dans le volume docker
- Une tâche est produite dans la file d'attente « to_estimate », qui comprend entre autres le chemin d'accès à l'image située dans notre volume
- Si les étapes ci-dessus sont terminées avec succès, l'utilisateur recevra un message avec le temps approximatif de traitement de l'image, calculé en fonction du nombre de tâches dans la file d'attente. Si une erreur se produit, l'utilisateur sera explicitement averti en envoyant un message contenant des informations sur ce qui aurait pu mal se passer.
De plus, ce microservice, comme un travailleur de céleri, écoute la file d'attente « after_estimate », destinée aux tâches passées par le pipeline d'évaluation.
Lors de la réception d'une nouvelle tâche de « after_estimate » :
- Si l'image est traitée avec succès, nous envoyons le résultat à l'utilisateur ; sinon, nous signalons une erreur.
- Suppression de l'image qui est le résultat du pipeline d'évaluation
Microservice d’évaluation « atrai-estimateur »
Ce microservice est un travailleur de céleri et encapsule tout ce qui concerne le pipeline d'évaluation d'image. Il n’y a qu’un seul algorithme fonctionnel ici – analysons-le.
Lors de la réception d'une nouvelle tâche de « to_estimate » :
- Exécutons l'image via le pipeline d'évaluation :
- Chargement de l'image en mémoire
- Nous apportons l'image à la taille requise
- Trouver tous les visages (MTCNN)
- Nous évaluons tous les visages (nous enveloppons les visages trouvés à la dernière étape dans un lot et inférons ResNet34)
- Rendre l'image finale
- Dessinons les boîtes englobantes
- Dessiner les notes
- Suppression d'une image personnalisée (originale)
- Enregistrer la sortie du pipeline d'évaluation
- Nous plaçons la tâche dans la file d'attente « after_estimate », qui est écoutée par le microservice « atrai-telegram-bot » évoqué ci-dessus.
Graylog (+ mongoDB + Elasticsearch)
est une solution de gestion centralisée des journaux. Dans ce projet, il a été utilisé aux fins prévues.
Le choix s'est porté sur lui, et non sur le choix habituel stack, en raison de la commodité de travailler avec Python. Tout ce que vous avez à faire pour vous connecter à Graylog est d'ajouter le GELFTCPHandler du package au reste des gestionnaires de journalisation racine de notre microservice python.
En tant que personne qui n'avait auparavant travaillé qu'avec la pile ELK, j'ai eu une expérience globalement positive en travaillant avec Graylog. La seule chose qui est déprimante est la supériorité des fonctionnalités de Kibana sur l'interface Web Graylog.
RabbitMQ
est un courtier de messages basé sur le protocole AMQP.
Dans ce projet, il a été utilisé comme courtier en Céleri et a travaillé en mode durable.
Redis
est un SGBD NoSQL qui fonctionne avec des structures de données clé-valeur
Parfois, il est nécessaire d'utiliser des objets communs qui implémentent certaines structures de données dans différents microservices Python.
Par exemple, Redis stocke un hashmap du formulaire «telegram_user_id => nombre de tâches actives dans la file d'attente», qui vous permet de limiter le nombre de requêtes d'un utilisateur à une certaine valeur et, ainsi, d'empêcher les attaques DoS.
Formalisons le processus de traitement d'image réussi
- L'utilisateur envoie une image au bot Telegram
- "attrai-telegram-bot" reçoit un message de l'API Telegram et l'analyse
- La tâche avec l'image est ajoutée à la file d'attente asynchrone « to_estimate »
- L'utilisateur reçoit un message avec le temps d'évaluation prévu
- "attrai-estimator" prend une tâche de la file d'attente "to_estimate", exécute les estimations via le pipeline et produit la tâche dans la file d'attente "after_estimate"
- "attrai-telegram-bot" écoute la file d'attente "after_estimate", envoie le résultat à l'utilisateur
DevOps
Enfin, après avoir revu l'architecture, vous pouvez passer à la partie tout aussi intéressante – DevOps
Docker Swarm
— un système de clustering dont la fonctionnalité est implémentée dans le Docker Engine et est disponible immédiatement.
À l'aide d'un « essaim », tous les nœuds de notre cluster peuvent être divisés en 2 types : travailleur et gestionnaire. Sur les machines du premier type, des groupes de conteneurs (piles) sont déployés, les machines du deuxième type sont chargées de la mise à l'échelle, de l'équilibrage et . Les managers sont aussi des travailleurs par défaut.
Cluster avec un leader manager et trois travailleurs
La taille minimale possible du cluster est de 1 nœud ; une seule machine agira simultanément en tant que gestionnaire principal et travailleur. Compte tenu de la taille du projet et des exigences minimales en matière de tolérance aux pannes, il a été décidé d'utiliser cette approche.
Pour l'avenir, je dirai que depuis la première livraison de production, qui a eu lieu à la mi-juin, il n'y a eu aucun problème lié à cette organisation en cluster (mais cela ne signifie pas qu'une telle organisation est en aucun cas acceptable dans n'importe quelle moyenne ou grande taille). projets, qui sont soumis à des exigences de tolérance aux pannes).
Pile Docker
En mode swarm, il est responsable du déploiement des stacks (ensembles de services docker)
Il prend en charge les configurations docker-compose, vous permettant d'utiliser en plus les options de déploiement.
Par exemple, en utilisant ces paramètres, les ressources pour chacune des instances du microservice d'évaluation étaient limitées (nous allouons N cœurs pour N instances, dans le microservice lui-même nous limitons le nombre de cœurs utilisés par PyTorch à un)
attrai_estimator:
image: 'erqups/attrai_estimator:1.2'
deploy:
replicas: 4
resources:
limits:
cpus: '4'
restart_policy:
condition: on-failure
…Il est important de noter que Redis, RabbitMQ et Graylog sont des services avec état et qu'ils ne peuvent pas être mis à l'échelle aussi facilement que « attrai-estimator ».
Préfigurant la question : pourquoi pas Kubernetes ?
Il semble que l'utilisation de Kubernetes dans des projets de petite et moyenne taille représente une surcharge ; toutes les fonctionnalités nécessaires peuvent être obtenues à partir de Docker Swarm, qui est assez convivial pour un orchestrateur de conteneurs et présente également une faible barrière à l'entrée.
Infrastructure
Tout cela a été déployé sur VDS avec les caractéristiques suivantes :
- Processeur : processeur Intel® Xeon® Gold 4 à 5120 cœurs à 2.20 GHz
- RAM: 8 Go
- SSD : 160 Go
Après des tests de charge locaux, il semblait qu'avec un afflux important d'utilisateurs, cette machine suffirait.
Mais immédiatement après le déploiement, j'ai publié un lien vers l'un des tableaux d'images les plus populaires de la CEI (oui, le même), après quoi les gens se sont intéressés et en quelques heures, le service a traité avec succès des dizaines de milliers d'images. Dans le même temps, aux moments de pointe, les ressources CPU et RAM n'étaient même pas utilisées à moitié.
Quelques graphiques supplémentaires
Nombre d'utilisateurs uniques et de demandes d'évaluation depuis le déploiement, selon le jour
Distribution du temps d'inférence du pipeline d'évaluation
résultats
Pour résumer, je peux dire que l'architecture et l'approche de l'orchestration des conteneurs se sont pleinement justifiées - même aux moments de pointe, il n'y a eu aucune baisse ni ralentissement du temps de traitement.
Je pense que les projets de petite et moyenne taille qui utilisent dans leur processus l'inférence en temps réel des réseaux de neurones sur le CPU peuvent adopter avec succès les pratiques décrites dans cet article.
J'ajouterai qu'au départ l'article était plus long, mais afin de ne pas publier une lecture longue, j'ai décidé d'omettre certains points de cet article - nous y reviendrons dans les prochaines publications.
Vous pouvez lancer le bot sur Telegram - @AttraiBot, il fonctionnera au moins jusqu'à la fin de l'automne 2020. Permettez-moi de vous rappeler qu'aucune donnée utilisateur n'est stockée - ni les images originales, ni les résultats du pipeline d'évaluation - tout est démoli après traitement.
Source: habr.com