La conférence Habr n’est pas une première histoire. Auparavant, nous organisions des événements Toaster assez importants pour 300 à 400 personnes, mais nous avons désormais décidé que de petites réunions thématiques seraient pertinentes, dont vous pouvez définir l'orientation, par exemple, dans les commentaires. La première conférence de ce format s'est tenue en juillet et était dédiée au développement backend. Les participants ont écouté des reportages sur les caractéristiques de la transition du backend vers le ML et sur la conception du service Quadrupel sur le portail des Services de l'État, et ont également participé à une table ronde dédiée au Serverless. Pour ceux qui n’ont pas pu assister personnellement à l’événement, nous vous racontons dans cet article les choses les plus intéressantes.
Du développement backend à l’apprentissage automatique
Que font les ingénieurs de données en ML ? En quoi les tâches d'un développeur backend et d'un ingénieur ML sont-elles similaires et différentes ? Quel chemin faut-il emprunter pour changer de premier métier en deuxième ? C'est ce qu'a raconté Alexander Parinov, qui s'est lancé dans l'apprentissage automatique après 10 ans de travail back-end.
Alexandre Parinov
Aujourd'hui, Alexander travaille comme architecte de systèmes de vision par ordinateur chez X5 Retail Group et contribue aux projets Open Source liés à la vision par ordinateur et à l'apprentissage profond (github.com/creafz). Ses compétences sont confirmées par sa participation au top 100 du classement mondial de Kaggle Master (kaggle.com/creafz), la plateforme la plus populaire de compétitions de machine learning.
Pourquoi passer au machine learning
Il y a un an et demi, Jeff Dean, responsable de Google Brain, le projet de recherche sur l'intelligence artificielle basé sur l'apprentissage profond de Google, a décrit comment un demi-million de lignes de code dans Google Translate avaient été remplacées par un réseau neuronal Tensor Flow composé de seulement 500 lignes. Après avoir entraîné le réseau, la qualité des données a augmenté et l'infrastructure est devenue plus simple. Il semblerait que ce soit notre brillant avenir : nous n’avons plus besoin d’écrire du code, il suffit de fabriquer des neurones et de les remplir de données. Mais en pratique, tout est bien plus compliqué.
Infrastructure ML chez Google
Les réseaux de neurones ne représentent qu’une petite partie de l’infrastructure (le petit carré noir sur l’image ci-dessus). De nombreux autres systèmes auxiliaires sont nécessaires pour recevoir des données, les traiter, les stocker, vérifier la qualité, etc., nous avons besoin d'une infrastructure pour la formation, le déploiement du code d'apprentissage automatique en production et le test de ce code. Toutes ces tâches sont exactement similaires à ce que font les développeurs backend.
Processus d'apprentissage automatique
Quelle est la différence entre le ML et le back-end ?
En programmation classique, nous écrivons du code et cela dicte le comportement du programme. En ML, nous avons un petit code de modèle et de nombreuses données que nous transmettons au modèle. Les données en ML sont très importantes : le même modèle formé sur différentes données peut montrer des résultats complètement différents. Le problème est que les données sont presque toujours dispersées et stockées dans différents systèmes (bases de données relationnelles, bases de données NoSQL, logs, fichiers).
Versionnement des données
Le ML nécessite de versionner non seulement le code, comme dans le développement classique, mais aussi les données : il est nécessaire de bien comprendre sur quoi le modèle a été formé. Pour ce faire, vous pouvez utiliser la populaire bibliothèque Data Science Version Control (dvc.org).
Balisage des données
La tâche suivante est l'étiquetage des données. Par exemple, marquez tous les objets de l'image ou dites à quelle classe ils appartiennent. Ceci est effectué par des services spéciaux comme Yandex.Toloka, dont le travail est grandement simplifié par la présence d'une API. Des difficultés surviennent en raison du « facteur humain » : vous pouvez améliorer la qualité des données et réduire au minimum les erreurs en confiant la même tâche à plusieurs interprètes.
Visualisation dans Tensor Board
La journalisation des expériences est nécessaire pour comparer les résultats et sélectionner le meilleur modèle en fonction de certaines mesures. Il existe un large éventail d'outils de visualisation - par exemple, Tensor Board. Mais il n’existe pas de manière idéale de stocker les expériences. Les petites entreprises se contentent souvent d'une feuille de calcul Excel, tandis que les grandes utilisent des plates-formes spéciales pour stocker les résultats dans une base de données.
Il existe de nombreuses plateformes de machine learning, mais aucune ne couvre 70 % des besoins
Le premier problème auquel on doit faire face lors de la mise en production d'un modèle entraîné est lié à l'outil préféré des data scientists - Jupyter Notebook. Il n'y a aucune modularité, c'est-à-dire que la sortie est une telle "chaussure" de code qui n'est pas divisée en morceaux logiques - modules. Tout est mélangé : classes, fonctions, configurations, etc. Ce code est difficile à versionner et à tester.
Comment gérer cela ? Vous pouvez vous résigner, comme Netflix, et créer votre propre plateforme qui vous permettra de lancer ces ordinateurs portables directement en production, de leur transférer des données en entrée et d'obtenir des résultats. Vous pouvez forcer les développeurs qui mettent le modèle en production à réécrire le code normalement, en le divisant en modules. Mais avec cette approche, il est facile de se tromper et le modèle ne fonctionnera pas comme prévu. Par conséquent, l’option idéale est d’interdire l’utilisation de Jupyter Notebook pour le code du modèle. Si, bien sûr, les data scientists sont d’accord.
Modèle comme une boîte noire
Le moyen le plus simple de mettre un modèle en production est de l’utiliser comme boîte noire. Vous avez une sorte de classe de modèle, on vous a donné les poids du modèle (paramètres des neurones du réseau entraîné), et si vous initialisez cette classe (appelez la méthode prédire, donnez-lui une image), vous obtiendrez un certain prédiction comme résultat. Ce qui se passe à l’intérieur n’a pas d’importance.
Processus de serveur séparé avec modèle
Vous pouvez également lancer un certain processus distinct et l'envoyer via une file d'attente RPC (avec des images ou d'autres données sources. En sortie, nous recevrons des prédictions.
Un exemple d'utilisation d'un modèle dans Flask :
@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)
Le problème de cette approche est la limitation des performances. Disons que nous avons du code Phyton écrit par des data scientists qui est lent et que nous voulons obtenir des performances maximales. Pour ce faire, vous pouvez utiliser des outils qui convertissent le code en natif ou le convertir dans un autre framework adapté à la production. Il existe de tels outils pour chaque framework, mais il n’y en a pas d’idéal ; vous devrez les ajouter vous-même.
L'infrastructure en ML est la même que dans un backend classique. Il existe Docker et Kubernetes, uniquement pour Docker, vous devez installer le runtime de NVIDIA, qui permet aux processus à l'intérieur du conteneur d'accéder aux cartes vidéo de l'hôte. Kubernetes a besoin d'un plugin pour pouvoir gérer des serveurs avec des cartes vidéo.
Contrairement à la programmation classique, dans le cas du ML, l'infrastructure comporte de nombreux éléments mobiles différents qui doivent être vérifiés et testés - par exemple, le code de traitement des données, le pipeline de formation des modèles et la production (voir le diagramme ci-dessus). Il est important de tester le code qui connecte les différents éléments du pipeline : il existe de nombreux éléments et des problèmes surviennent très souvent aux limites des modules.
Comment fonctionne AutoML
Les services AutoML promettent de sélectionner le modèle optimal pour vos besoins et de le former. Mais il faut comprendre : les données sont très importantes en ML, le résultat dépend de leur préparation. Le balisage est effectué par des personnes, ce qui est semé d'erreurs. Sans contrôle strict, le résultat peut être un déchet, et il n'est pas encore possible d'automatiser le processus ; une vérification par des spécialistes - des data scientists - est nécessaire. C'est là qu'AutoML tombe en panne. Mais cela peut être utile pour sélectionner une architecture, lorsque vous avez déjà préparé les données et que vous souhaitez exécuter une série d’expériences pour trouver le meilleur modèle.
Comment se lancer dans l'apprentissage automatique
Le moyen le plus simple d'accéder au ML est de développer en Python, qui est utilisé dans tous les frameworks d'apprentissage en profondeur (et les frameworks standards). Cette langue est pratiquement obligatoire pour ce domaine d'activité. Le C++ est utilisé pour certaines tâches de vision par ordinateur, par exemple dans les systèmes de contrôle des voitures autonomes. JavaScript et Shell - pour la visualisation et des choses aussi étranges que l'exécution d'un neurone dans le navigateur. Java et Scala sont utilisés pour travailler avec le Big Data et pour l'apprentissage automatique. R et Julia sont appréciés des personnes qui étudient les statistiques mathématiques.
Le moyen le plus pratique d’acquérir une expérience pratique pour commencer est sur Kaggle : la participation à l’un des concours de la plateforme donne plus d’un an d’étude théorique. Sur cette plateforme, vous pouvez prendre le code publié et commenté de quelqu'un d'autre et essayer de l'améliorer, de l'optimiser pour vos besoins. Bonus – votre rang Kaggle affecte votre salaire.
Une autre option consiste à rejoindre l'équipe ML en tant que développeur backend. Il existe de nombreuses startups de machine learning où vous pouvez acquérir de l'expérience en aidant vos collègues à résoudre leurs problèmes. Enfin, vous pouvez rejoindre l'une des communautés de data scientists - Open Data Science (ods.ai) et autres.
L'orateur a publié des informations supplémentaires sur le sujet sur le lien
"Quadrupel" - un service de notifications ciblées du portail "Services de l'Etat"
Evgeny Smirnov
L'orateur suivant était le chef du département de développement des infrastructures d'administration électronique, Evgeny Smirnov, qui a parlé de Quadruple. Il s'agit d'un service de notification ciblé pour le portail Gosuslugi (gosuslugi.ru), la ressource gouvernementale la plus visitée sur Runet. L'audience quotidienne est de 2,6 millions, au total il y a 90 millions d'utilisateurs enregistrés sur le site, dont 60 millions confirmés. La charge sur l'API du portail est de 30 XNUMX RPS.
Technologies utilisées dans le backend des Services de l'Etat
« Quadrupel » est un service de notification ciblée, à l'aide duquel l'utilisateur reçoit une offre de service au moment qui lui convient le mieux en mettant en place des règles de notification spéciales. Les principales exigences lors du développement du service étaient des paramètres flexibles et un temps suffisant pour les envois.
Comment fonctionne Quadrupel ?
Le schéma ci-dessus montre l'une des règles de fonctionnement du Quadrupel à l'aide de l'exemple d'une situation avec nécessité de remplacer un permis de conduire. Tout d'abord, le service recherche les utilisateurs dont la date d'expiration expire dans un mois. Une bannière leur est présentée avec une offre pour bénéficier du service approprié et un message est envoyé par e-mail. Pour les utilisateurs dont le délai est déjà expiré, la bannière et l'e-mail changent. Après un échange réussi de droits, l'utilisateur reçoit d'autres notifications - avec une proposition de mise à jour des données d'identité.
D'un point de vue technique, ce sont des scripts groovy dans lesquels le code est écrit. L’entrée est une donnée, la sortie est vrai/faux, correspond/ne correspond pas. Il existe plus de 50 règles au total - depuis la détermination de l'anniversaire de l'utilisateur (la date actuelle est égale à la date de naissance de l'utilisateur) jusqu'aux situations complexes. Chaque jour, ces règles identifient environ un million de correspondances, c'est-à-dire des personnes qui doivent être informées.
Canaux de notification quadruples
Sous le capot de Quadrupel se trouvent une base de données dans laquelle les données des utilisateurs sont stockées, ainsi que trois applications :
- Ouvrier destiné à la mise à jour des données.
- API REST récupère et livre lui-même les bannières sur le portail et l'application mobile.
- Planificateur lance des travaux sur le recalcul des bannières ou des mailings de masse.
Pour mettre à jour les données, le backend est piloté par les événements. Deux interfaces - rest ou JMS. Les événements sont nombreux ; avant d'être enregistrés et traités, ils sont agrégés afin de ne pas faire de requêtes inutiles. La base de données elle-même, la table dans laquelle les données sont stockées, ressemble à un magasin de valeurs clés - la clé de l'utilisateur et la valeur elle-même : des drapeaux indiquant la présence ou l'absence de documents pertinents, leur durée de validité, des statistiques agrégées sur l'ordre des prestations par cet utilisateur, et ainsi de suite.
Après avoir enregistré les données, une tâche est définie dans JMS afin que les bannières soient immédiatement recalculées - celles-ci doivent être immédiatement affichées sur le Web. Le système démarre la nuit : des tâches sont lancées dans JMS à intervalles utilisateur, selon lesquels les règles doivent être recalculées. Ceci est récupéré par les processeurs impliqués dans le recalcul. Ensuite, les résultats du traitement sont envoyés à la file d'attente suivante, qui enregistre les bannières dans la base de données ou envoie les tâches de notification des utilisateurs au service. Le processus prend 5 à 7 heures et est facilement évolutif car vous pouvez toujours soit ajouter des gestionnaires, soit créer des instances avec de nouveaux gestionnaires.
Le service fonctionne plutôt bien. Mais le volume de données augmente à mesure qu’il y a plus d’utilisateurs. Cela entraîne une augmentation de la charge sur la base de données - même en tenant compte du fait que l'API Rest examine la réplique. Le deuxième point est JMS, qui s'est avéré peu adapté en raison de sa consommation mémoire élevée. Il existe un risque élevé de débordement de file d'attente provoquant le blocage de JMS et l'arrêt du traitement. Il est impossible de relancer JMS après cela sans effacer les journaux.
Il est prévu de résoudre les problèmes en utilisant le sharding, ce qui permettra d'équilibrer la charge sur la base de données. Il est également prévu de modifier le schéma de stockage des données et de remplacer JMS par Kafka, une solution plus tolérante aux pannes qui résoudra les problèmes de mémoire.
Backend en tant que service vs. Sans serveur
De gauche à droite : Alexandre Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend en tant que service ou solution sans serveur ? Les participants à la discussion sur cette question urgente lors de la table ronde étaient :
- Ara Israelyan, CTO CTO et fondateur de Scorocode.
- Nikolay Markov, ingénieur de données senior chez Aligned Research Group.
- Andrey Tomilenko, chef du département de développement de RUVDS.
La conversation a été modérée par le développeur senior Alexander Borgart. Nous présentons les débats auxquels les auditeurs ont également participé dans une version abrégée.
— Qu'est-ce que le sans serveur selon vous ?
Andrew: Il s'agit d'un modèle informatique - une fonction Lambda qui doit traiter les données pour que le résultat dépende uniquement des données. Le terme vient soit de Google, soit d'Amazon et de son service AWS Lambda. Il est plus facile pour un fournisseur de gérer une telle fonction en lui allouant un pool de capacité. Différents utilisateurs peuvent être comptabilisés indépendamment sur les mêmes serveurs.
Nicholas: Pour faire simple, nous transférons une partie de notre infrastructure informatique et de notre logique métier vers le cloud, vers l'externalisation.
ara: De la part des développeurs - une bonne tentative d'économiser des ressources, de la part des spécialistes du marketing - de gagner plus d'argent.
— Le sans serveur est-il la même chose que les microservices ?
Nicholas: Non, Serverless est plutôt une organisation architecturale. Un microservice est une unité atomique d'une certaine logique. Le sans serveur est une approche, pas une « entité distincte ».
ara: Une fonction Serverless peut être packagée dans un microservice, mais ce ne sera plus Serverless, elle cessera d'être une fonction Lambda. Dans Serverless, une fonction ne commence à fonctionner qu'au moment où elle est demandée.
Andrew: Ils diffèrent dans leur vie. Nous avons lancé la fonction Lambda et l'avons oubliée. Cela a fonctionné pendant quelques secondes et le client suivant peut traiter sa demande sur une autre machine physique.
— Qu'est-ce qui évolue le mieux ?
ara: lors d'une mise à l'échelle horizontale, les fonctions Lambda se comportent exactement de la même manière que les microservices.
Nicholas: Quel que soit le nombre de répliques que vous définissez, il y en aura autant ; Serverless n'a aucun problème de mise à l'échelle. J'ai créé un ensemble de répliques dans Kubernetes, lancé 20 instances « quelque part » et 20 liens anonymes vous ont été renvoyés. Avant!
— Est-il possible d'écrire un backend sur Serverless ?
Andrew: Théoriquement, mais cela n'a aucun sens. Les fonctions Lambda s'appuieront sur un référentiel unique – nous devons garantir la garantie. Par exemple, si un utilisateur a effectué une certaine transaction, la prochaine fois qu'il contactera, il devrait voir : la transaction a été effectuée, les fonds ont été crédités. Toutes les fonctions Lambda seront bloquées lors de cet appel. En fait, un ensemble de fonctions sans serveur se transformeront en un seul service avec un point d'accès goulot d'étranglement à la base de données.
— Dans quelles situations est-il judicieux d'utiliser une architecture sans serveur ?
Andrew: Tâches qui ne nécessitent pas de stockage partagé - le même minage, blockchain. Où il faut beaucoup compter. Si vous disposez de beaucoup de puissance de calcul, vous pouvez définir une fonction telle que « calculer le hachage de quelque chose ici... » Mais vous pouvez résoudre le problème du stockage de données en prenant, par exemple, les fonctions Lambda d'Amazon et leur stockage distribué. . Et il s'avère que vous écrivez un service régulier. Les fonctions Lambda accéderont au stockage et fourniront une sorte de réponse à l'utilisateur.
Nicholas: Les conteneurs qui s'exécutent en Serverless sont extrêmement limités en ressources. Il y a peu de mémoire et tout le reste. Mais si toute votre infrastructure est entièrement déployée sur un cloud - Google, Amazon - et que vous avez un contrat à durée indéterminée avec eux, il existe un budget pour tout cela, alors pour certaines tâches, vous pouvez utiliser des conteneurs sans serveur. Il est nécessaire d'être à l'intérieur de cette infrastructure, car tout est conçu pour être utilisé dans un environnement spécifique. Autrement dit, si vous êtes prêt à tout lier à l'infrastructure cloud, vous pouvez expérimenter. L’avantage est que vous n’avez pas à gérer cette infrastructure.
ara: Le fait que Serverless ne vous oblige pas à gérer Kubernetes, Docker, à installer Kafka, etc. est une auto-illusion. Les mêmes Amazon et Google l'installent. Une autre chose est que vous avez un SLA. Autant tout externaliser plutôt que de le coder vous-même.
Andrew: Le sans serveur en lui-même est peu coûteux, mais vous devez payer cher pour d'autres services Amazon, par exemple la base de données. Des gens les ont déjà poursuivis en justice parce qu'ils facturaient des sommes folles pour le portail API.
ara: Si on parle d'argent, alors il faut prendre en compte ce point : vous devrez tourner à 180 degrés toute la méthodologie de développement de l'entreprise afin de transférer tout le code vers Serverless. Cela prendra beaucoup de temps et d'argent.
— Existe-t-il des alternatives intéressantes au sans serveur payant d'Amazon et de Google ?
Nicholas: Dans Kubernetes, vous lancez une sorte de travail, il s'exécute et meurt - c'est assez sans serveur d'un point de vue architectural. Si vous souhaitez créer une logique métier vraiment intéressante avec des files d’attente et des bases de données, vous devez y réfléchir un peu plus. Tout cela peut être résolu sans quitter Kubernetes. Je ne prendrais pas la peine de traîner une implémentation supplémentaire.
— Dans quelle mesure est-il important de surveiller ce qui se passe dans Serverless ?
ara: Dépend de l'architecture du système et des exigences de l'entreprise. Essentiellement, le fournisseur doit fournir des rapports qui aideront l'équipe de développement à comprendre les problèmes possibles.
Nicholas: Amazon dispose de CloudWatch, où tous les journaux sont diffusés, y compris ceux de Lambda. Intégrez le transfert de journaux et utilisez un outil distinct pour l'affichage, les alertes, etc. Vous pouvez placer des agents dans les conteneurs que vous démarrez.
- Résumons-le.
Andrew: Il est utile de réfléchir aux fonctions Lambda. Si vous créez vous-même un service - pas un microservice, mais un service qui écrit une requête, accède à la base de données et envoie une réponse - la fonction Lambda résout un certain nombre de problèmes : avec le multithreading, l'évolutivité, etc. Si votre logique est construite de cette manière, vous pourrez à l'avenir transférer ces Lambda vers des microservices ou utiliser des services tiers comme Amazon. La technologie est utile, l’idée est intéressante. La question de savoir dans quelle mesure cela est justifié pour les entreprises reste ouverte.
Nikolay : Le sans serveur est mieux utilisé pour les tâches opérationnelles que pour le calcul d'une logique métier. J'y pense toujours comme un traitement d'événements. Si vous l'avez sur Amazon, si vous êtes sur Kubernetes, oui. Sinon, vous devrez déployer beaucoup d’efforts pour que Serverless soit opérationnel par vous-même. Il est nécessaire d’examiner une analyse de rentabilisation spécifique. Par exemple, l'une de mes tâches est désormais la suivante : lorsque des fichiers apparaissent sur le disque dans un certain format, je dois les télécharger sur Kafka. Je peux utiliser WatchDog ou Lambda. D'un point de vue logique, les deux options conviennent, mais en termes de mise en œuvre, Serverless est plus compliqué, et je préfère la manière la plus simple, sans Lambda.
ara: Le sans serveur est une idée intéressante, applicable et très belle techniquement. Tôt ou tard, la technologie atteindra le point où n’importe quelle fonction sera lancée en moins de 100 millisecondes. Il ne sera alors en principe plus question de savoir si le temps d’attente est critique pour l’utilisateur. Dans le même temps, l'applicabilité de Serverless, comme l'ont déjà dit des collègues, dépend entièrement du problème commercial.
Nous remercions nos sponsors qui nous ont beaucoup aidés :
- Espace de conférence informatique «» pour le site de la conférence.
- Calendrier des événements informatiques et publication "» pour obtenir des informations et des actualités.
- «"pour les cadeaux.
- pour la co-création.
- "Association pour les communications électroniques" pour son implication et son expérience.
- Sponsor principal - pour tous!
Source: habr.com