Comment Amazon Search exécute des projets de machine learning résilients à grande échelle avec Amazon SageMaker

Si vous avez recherché un article à acheter sur amazon.com, vous avez utilisé les services Amazon Search. Chez Amazon Search, nous sommes responsables de l'expérience de recherche et de découverte de nos clients dans le monde entier. En arrière-plan, nous indexons notre catalogue mondial de produits, déployons des flottes AWS hautement évolutives et utilisons l'apprentissage automatique (ML) avancé pour faire correspondre des produits pertinents et intéressants à la requête de chaque client.

Nos scientifiques forment régulièrement des milliers de modèles ML pour améliorer la qualité des résultats de recherche. Soutenir l'expérimentation à grande échelle présente ses propres défis, en particulier lorsqu'il s'agit d'améliorer la productivité des scientifiques formant ces modèles ML.

Dans cet article, nous partageons comment nous avons construit un système de gestion autour de Amazon Sage Maker des emplois de formation, permettant à nos scientifiques de lancer et d'oublier des milliers d'expériences et d'être avertis en cas de besoin. Ils peuvent désormais se concentrer sur des tâches à forte valeur ajoutée et résoudre des erreurs algorithmiques, économisant ainsi 60 % de leur temps.

Le défi

Chez Amazon Search, nos scientifiques résolvent les problèmes de récupération d'informations en expérimentant et en exécutant de nombreuses tâches de formation de modèles ML sur SageMaker. Pour suivre l'innovation de notre équipe, la complexité de nos modèles et le nombre d'emplois de formation ont augmenté au fil du temps. Les tâches de formation SageMaker nous permettent de réduire le temps et les coûts de formation et d'ajustement de ces modèles à grande échelle, sans avoir besoin de gérer l'infrastructure.

Comme tout dans de tels projets ML à grande échelle, les tâches de formation peuvent échouer en raison de divers facteurs. Cet article se concentre sur les pénuries de capacité et les défaillances dues à des erreurs d'algorithme.

Nous avons conçu une architecture avec un système de gestion des tâches pour tolérer et réduire la probabilité d'échec d'une tâche en raison d'une indisponibilité de capacité ou d'erreurs d'algorithme. Il permet aux scientifiques de déclencher et d'oublier des milliers de tâches de formation, de les réessayer automatiquement en cas d'échec transitoire et d'être informés du succès ou de l'échec si nécessaire.

Vue d'ensemble de la solution

Dans le diagramme de solution suivant, nous utilisons les tâches de formation SageMaker comme unité de base de notre solution. Autrement dit, une tâche représente la formation de bout en bout d'un modèle ML.

Le flux de travail de haut niveau de cette solution est le suivant :

1. Les scientifiques invoquent une API pour soumettre une nouvelle tâche au système.
2. Le travail est enregistré auprès du New statut dans un magasin de métadonnées.
3. Un planificateur de travaux récupère de façon asynchrone New travaux du magasin de métadonnées, analyse leur entrée et essaie de lancer des travaux de formation SageMaker pour chacun d'eux. Leur statut passe à Launched or Failed en fonction du succès.
4. Un moniteur vérifie la progression des travaux à intervalles réguliers et signale leur Completed, Failedou InProgress état dans le magasin de métadonnées.
5. Un notificateur est déclenché pour signaler Completed ainsi que Failed emplois aux scientifiques.

La conservation de l'historique des travaux dans le magasin de métadonnées permet également à notre équipe d'effectuer une analyse des tendances et de surveiller l'avancement du projet.

Cette solution de planification des tâches utilise des composants sans serveur faiblement couplés basés sur AWS Lambda, Amazon DynamoDB, Service de notification simple d'Amazon (Amazon SNS) et Amazon Event Bridge. Cela garantit une évolutivité horizontale, permettant à nos scientifiques de lancer des milliers de travaux avec un effort opérationnel minimal. Le schéma suivant illustre l'architecture sans serveur.

Dans les sections suivantes, nous allons plus en détail sur chaque service et ses composants.

DynamoDB en tant que magasin de métadonnées pour les exécutions de tâches

La facilité d'utilisation et l'évolutivité de DynamoDB en ont fait un choix naturel pour conserver les métadonnées des tâches dans une table DynamoDB. Cette solution stocke plusieurs attributs des travaux soumis par les scientifiques, facilitant ainsi le suivi des progrès et l'orchestration du flux de travail. Les attributs les plus importants sont les suivants :

• ID de travail – Un ID de travail unique. Cela peut être généré automatiquement ou fourni par le scientifique.
• Statut du travail – L'état du travail.
• JobArgs – Autres arguments requis pour créer une tâche de formation, tels que le chemin d'entrée dans Amazon S3, l'URI de l'image de formation, etc. Pour obtenir la liste complète des paramètres requis pour créer une tâche d'entraînement, reportez-vous à CréerTrainingJob.

Lambda pour la logique de base

Nous utilisons trois à base de conteneurs Fonctions Lambda pour orchestrer le flux de travaux :

• Submit Job – Cette fonction est invoquée par les scientifiques lorsqu'ils ont besoin de lancer de nouvelles tâches. Il agit comme une API pour plus de simplicité. Vous pouvez également l'affronter avec Passerelle d'API Amazon, si besoin. Cette fonction enregistre les tâches dans la table DynamoDB.
• Lancer des tâches – Cette fonction récupère périodiquement New travaux de la table DynamoDB et les lance à l'aide de SageMaker CréerTrainingJob commande. Il réessaie sur les échecs transitoires, tels que ResourceLimitExceeded ainsi que CapacityError, pour instrumenter la résilience dans le système. Il met ensuite à jour l'état du travail comme Launched or Failed en fonction du succès.
• Surveiller les tâches – Cette fonction assure le suivi périodique de la progression du travail à l'aide du DécrireFormationEmploi commande et met à jour la table DynamoDB en conséquence. Il interroge Failed travaux à partir des métadonnées et évalue s'ils doivent être soumis à nouveau ou marqués comme définitivement échoués. Il publie également des messages de notification aux scientifiques lorsque leurs travaux atteignent un état terminal.

EventBridge pour la planification

Nous utilisons EventBridge pour exécuter les fonctions Launch Jobs et Monitor Jobs Lambda selon un calendrier. Pour plus d'informations, reportez-vous à Didacticiel : Planifier des fonctions AWS Lambda à l'aide d'EventBridge.

Alternativement, vous pouvez utiliser Flux Amazon DynamoDB pour les déclencheurs. Pour plus d'informations, voir Flux DynamoDB et déclencheurs AWS Lambda.

Notifications avec Amazon SNS

Nos scientifiques sont notifié par e-mail via Amazon SNS lorsque leurs travaux atteignent un état terminal (Failed après un nombre maximum de tentatives), Completedou Stopped.

Conclusion

Dans cet article, nous avons expliqué comment Amazon Search ajoute de la résilience aux charges de travail de formation de modèles ML en les planifiant et en les réessayant en cas de pénurie de capacité ou d'erreurs d'algorithme. Nous avons utilisé les fonctions Lambda conjointement avec une table DynamoDB en tant que magasin de métadonnées central pour orchestrer l'ensemble du flux de travail.

Un tel système de planification permet aux scientifiques de soumettre leurs travaux et de les oublier. Cela leur fait gagner du temps et leur permet de se concentrer sur l'écriture de meilleurs modèles.

Pour aller plus loin dans vos apprentissages, vous pouvez visiter Génial SageMaker et retrouvez en un seul endroit, toutes les ressources pertinentes et à jour nécessaires pour travailler avec SageMaker.

---

À propos des auteurs

Luochao Wang est ingénieur logiciel chez Amazon Search. Il se concentre sur les systèmes distribués évolutifs et les outils d'automatisation sur le cloud pour accélérer le rythme de l'innovation scientifique pour les applications d'apprentissage automatique.

Ishan Bhatt est ingénieur logiciel dans l'équipe Amazon Prime Video. Il travaille principalement dans l'espace MLOps et a de l'expérience dans la création de produits MLOps au cours des 4 dernières années à l'aide d'Amazon SageMaker.

Patni abhinandais est ingénieur logiciel senior chez Amazon Search. Il se concentre sur la construction de systèmes et d'outils pour la formation évolutive en apprentissage profond distribué et l'inférence en temps réel.

Eiman Elnahrawy est un ingénieur logiciel principal chez Amazon Search qui dirige les efforts d'accélération, de mise à l'échelle et d'automatisation de l'apprentissage automatique. Son expertise couvre plusieurs domaines, notamment l'apprentissage automatique, les systèmes distribués et la personnalisation.

Sofiane Hamiti est un architecte de solutions spécialisé en IA / ML chez AWS. Il aide les clients de tous les secteurs à accélérer leur parcours AI / ML en les aidant à créer et à opérationnaliser des solutions d'apprentissage automatique de bout en bout.

Dr Romi Datta  est un responsable principal de la gestion des produits au sein de l'équipe Amazon SageMaker responsable de la formation, du traitement et du magasin de fonctionnalités. Il travaille chez AWS depuis plus de 4 ans, occupant plusieurs postes de direction dans la gestion des produits dans SageMaker, S3 et IoT. Avant AWS, il a occupé divers postes de gestion de produits, d'ingénierie et de leadership opérationnel chez IBM, Texas Instruments et Nvidia. Il a une maîtrise et un doctorat. en génie électrique et informatique de l'Université du Texas à Austin et un MBA de la Booth School of Business de l'Université de Chicago.

RJ est un ingénieur de l'équipe Search M5 qui dirige les efforts de construction de systèmes d'apprentissage en profondeur à grande échelle pour la formation et l'inférence. En dehors du travail, il explore différentes cuisines culinaires et pratique des sports de raquette.