Déployer une solution de capture de données d'inférence de machine learning sur AWS Lambda

La surveillance des prédictions de machine learning (ML) peut contribuer à améliorer la qualité des modèles déployés. La capture des données à partir des inférences effectuées en production peut vous permettre de surveiller vos modèles déployés et de détecter les écarts dans la qualité des modèles. La détection précoce et proactive de ces écarts vous permet de prendre des mesures correctives, telles que le recyclage des modèles, l'audit des systèmes en amont ou la résolution des problèmes de qualité.

AWS Lambda est un service de calcul sans serveur qui peut fournir une inférence ML en temps réel à grande échelle. Dans cet article, nous présentons un exemple de fonctionnalité de capture de données qui peut être déployée sur une charge de travail d'inférence Lambda ML.

En décembre 2020, Lambda a introduit la prise en charge des images de conteneurs comme format d'emballage. Cette fonctionnalité a augmenté la limite de taille du package de déploiement de 500 Mo à 10 Go. Avant le lancement de cette fonctionnalité, la contrainte de taille du package rendait difficile le déploiement de frameworks ML tels que TensorFlow ou PyTorch vers les fonctions Lambda. Après le lancement, l'augmentation de la taille limite des packages a fait du ML une charge de travail viable et attrayante à déployer sur Lambda. En 2021, l'inférence ML était l'un des types de charge de travail connaissant la croissance la plus rapide dans le service Lambda.

Amazon Sage Maker, le service ML entièrement géré d'Amazon, contient sa propre fonctionnalité de surveillance des modèles. Cependant, l'exemple de projet présenté dans cet article montre comment effectuer une capture de données à utiliser dans la surveillance des modèles pour les clients qui utilisent Lambda pour l'inférence ML. Le projet utilise des extensions Lambda pour capturer les données d'inférence afin de minimiser l'impact sur les performances et la latence de la fonction d'inférence. L'utilisation des extensions Lambda minimise également l'impact sur les développeurs de fonctions. En s'intégrant via une extension, la fonction de surveillance peut être appliquée à plusieurs fonctions et maintenue par une équipe centralisée.

Présentation de la solution

Ce projet contient le code source et les fichiers de support pour une application sans serveur qui fournit une inférence en temps réel à l'aide d'un modèle de réponse aux questions pré-entraîné basé sur Distilbert. Le projet utilise le modèle de questions et réponses Hugging Face de traitement du langage naturel (NLP) avec PyTorch pour effectuer des tâches d'inférence en langage naturel. Le projet contient également une solution pour effectuer la capture de données d'inférence pour les prédictions du modèle. L'auteur de la fonction Lambda peut déterminer exactement quelles données de l'entrée de la demande d'inférence et le résultat de la prédiction envoyer à l'extension. Dans cette solution, nous envoyons l'entrée et la réponse du modèle à l'extension. L'extension envoie ensuite périodiquement les données à un Service de stockage simple Amazon (Amazon S3). Nous construisons l'extension de capture de données sous forme d'image de conteneur à l'aide d'un makefile. Nous construisons ensuite la fonction d'inférence Lambda en tant qu'image de conteneur et ajoutons l'image de conteneur d'extension en tant que couche d'image de conteneur. Le diagramme suivant montre un aperçu de l'architecture.

Les extensions Lambda sont un moyen d'augmenter les fonctions Lambda. Dans ce projet, nous utilisons une extension Lambda externe pour enregistrer la demande d'inférence et la prédiction de l'inférence. L'extension externe s'exécute comme un processus distinct dans l'environnement d'exécution Lambda, réduisant ainsi l'impact sur la fonction d'inférence. Cependant, la fonction partage des ressources telles que le processeur, la mémoire et le stockage avec la fonction Lambda. Nous vous recommandons d'allouer suffisamment de mémoire à la fonction Lambda pour garantir une disponibilité optimale des ressources. (Lors de nos tests, nous avons alloué 5 Go de mémoire à la fonction d'inférence Lambda et avons constaté une disponibilité des ressources et une latence d'inférence optimales). Lorsqu'une inférence est terminée, le service Lambda renvoie la réponse immédiatement et n'attend pas que l'extension ait fini de consigner la demande et la réponse dans le compartiment S3. Avec ce modèle, l'extension de surveillance n'affecte pas la latence d'inférence. Pour en savoir plus sur les extensions Lambda regarde ces séries de vidéos.

Contenu du projet

Ce projet utilise le Modèle d'application sans serveur AWS (AWS SAM) interface de ligne de commande (CLI). Cet outil de ligne de commande permet aux développeurs d'initialiser et de configurer des applications ; empaqueter, construire et tester localement ; et déployez sur le cloud AWS.

Vous pouvez télécharger le code source de ce projet depuis le référentiel GitHub.

Ce projet comprend les fichiers et dossiers suivants :

• app/app.py – Code pour la fonction Lambda de l'application, y compris le code pour l'inférence ML.
• application/fichier Docker – Le Dockerfile pour créer l'image du conteneur qui regroupe la fonction d'inférence, le modèle téléchargé depuis Hugging Face et l'extension Lambda construite en tant que couche. Contrairement aux fonctions .zip, les couches ne peuvent pas être attachées aux fonctions Lambda empaquetées dans un conteneur au moment de la création de la fonction. Au lieu de cela, nous construisons le calque et copions son contenu dans l'image du conteneur.
• Extensions – Les fichiers d'extension du moniteur de modèle. Cette extension Lambda est utilisée pour enregistrer l'entrée de la fonction d'inférence et la prédiction correspondante dans un compartiment S3.
• application/modèle – Le modèle téléchargé depuis Hugging Face.
• app/requirements.txt – Les dépendances Python à installer dans le conteneur.
• événements – Événements d'invocation que vous pouvez utiliser pour tester la fonction.
• modèle.yaml – Un fichier descripteur qui définit les ressources AWS de l'application.

L'application utilise plusieurs ressources AWS, notamment des fonctions Lambda et un Passerelle d'API Amazon API. Ces ressources sont définies dans le template.yaml fichier dans ce projet. Vous pouvez mettre à jour le modèle pour ajouter des ressources AWS via le même processus de déploiement qui met à jour le code de votre application.

Pré-requis

Pour cette procédure pas à pas, vous devez disposer des prérequis suivants:

Déployer l'exemple d'application

Pour créer votre application pour la première fois, procédez comme suit :

• Exécutez le code suivant dans votre shell. (Cela construira également l'extension) :

• Créez une image Docker de l'application de surveillance de modèle. Le contenu de la build réside dans le .aws-sam annuaire

docker build -t serverless-ml-model-monitor:latest .

docker tag serverless-ml-model-monitor:latest .dkr.ecr.us-east-1.amazonaws.com/serverless-ml-model-monitor:latest

• Connectez-vous à Amazon ECR :

aws ecr get-login-password --region us-east-1 docker login --username AWS --password-stdin .dkr.ecr.us-east-1.amazonaws.com

• Créez un référentiel dans Amazon ECR :

aws ecr create-repositoryrepository-name serverless-ml-model-monitor--image-scanning-configuration scanOnPush=true--region us-east-1

• Transférez l'image du conteneur vers Amazon ECR :

docker push .dkr.ecr.us-east-1.amazonaws.com/serverless-ml-model-monitor:latest

• Décommenter la ligne n°1 dans application/fichier Docker et modifiez-le pour qu'il pointe vers l'image correcte du référentiel ECR, puis décommentez les lignes n°6 et n°7 dans application/fichier Docker :

WORKDIR /opt
COPY --from=layer /opt/ .

• Reconstruisez l'application :

Nous reconstruisons car Lambda ne prend pas en charge les couches Lambda directement pour le type d'empaquetage d'image de conteneur. Nous devons d'abord créer le composant de surveillance du modèle en tant qu'image de conteneur, le télécharger sur Amazon ECR, puis utiliser cette image dans l'application de surveillance du modèle en tant que couche de conteneur.

• Enfin, déployez la fonction Lambda, l'API Gateway et l'extension :

sam deploy --guided

Cette commande regroupe et déploie votre application sur AWS avec une série d'invites :

• Nom de la pile : Le nom du déployé AWS CloudFormation empiler. Cela doit être unique à votre compte et à votre région, et un bon point de départ serait quelque chose correspondant au nom de votre projet.
• Région AWS : La région AWS dans laquelle vous déployez votre application.
• Confirmer les modifications avant le déploiement : Si défini sur yes, tous les ensembles de modifications vous sont présentés avant leur exécution pour révision manuelle. Si la valeur est non, l'AWS SAM CLI déploie automatiquement les modifications de l'application.
• Autoriser la création de rôles IAM AWS SAM CLI : De nombreux modèles AWS SAM, y compris cet exemple, créent Gestion des identités et des accès AWS (IAM) requis pour la ou les fonctions Lambda incluses pour accéder aux services AWS. Par défaut, celles-ci sont limitées aux autorisations minimales requises. Pour déployer une pile CloudFormation qui crée ou modifie des rôles IAM, le CAPABILITY_IAM la valeur pour capabilities doit être fourni. Si l'autorisation n'est pas fournie via cette invite, pour déployer cet exemple, vous devez explicitement transmettre --capabilities CAPABILITY_IAM à la sam deploy commander.
• Enregistrer les arguments dans samconfig.toml : Si défini sur yes, vos choix sont enregistrés dans un fichier de configuration à l'intérieur du projet afin qu'à l'avenir, vous puissiez simplement exécuter sam deploy sans paramètres pour déployer les modifications dans votre application.

Vous pouvez trouver l'URL de votre point de terminaison API Gateway dans les valeurs de sortie affichées après le déploiement.

Tester l'application

Pour tester l'application, utilisez Postman ou curl pour envoyer une requête au point de terminaison API Gateway. Par exemple:

curl -X POST -H "Content-Type: text/plain" https://.execute-api.us-east-1.amazonaws.com/Prod/nlp-qa -d '{"question": "Where do you live?", "context": "My name is Clara and I live in Berkeley."}'

Vous devriez voir une sortie semblable au code suivant. Le modèle ML déduit du contexte et a renvoyé la réponse à notre question.

{
    "Question": "Where do you live?",
    "Answer": "Berkeley",
    "score": 0.9113729596138
}

Après quelques minutes, vous devriez voir un fichier dans le compartiment S3 nlp-qamodel-model-monitoring-modelmonitorbucket- avec l'entrée et l'inférence enregistrées.

Nettoyer

Pour supprimer l'exemple d'application que vous avez créé, utilisez l'AWS CLI :

aws cloudformation delete-stack --stack-name 

Conclusion

Dans cet article, nous avons implémenté une fonctionnalité de surveillance de modèle en tant qu'extension Lambda et l'avons déployée sur une charge de travail d'inférence Lambda ML. Nous avons montré comment créer et déployer cette solution sur votre propre compte AWS. Enfin, nous avons montré comment exécuter un test pour vérifier la fonctionnalité du moniteur.

Veuillez faire part de vos réflexions ou questions dans la section commentaires. Pour plus de ressources d'apprentissage sans serveur, visitez Terre sans serveur.

À propos des auteurs

Dan Renard est architecte principal de solutions spécialisées au sein de l'organisation mondiale spécialisée pour le sans serveur. Dan travaille avec ses clients pour les aider à tirer parti des services sans serveur afin de créer des applications évolutives, tolérantes aux pannes, hautement performantes et rentables. Dan est reconnaissant de pouvoir vivre et travailler dans la belle ville de Boulder, au Colorado.

Newton Jain est un chef de produit senior chargé de créer de nouvelles expériences pour les clients d'apprentissage automatique, de calcul haute performance (HPC) et de traitement multimédia sur AWS Lambda. Il dirige le développement de nouvelles fonctionnalités visant à augmenter les performances, réduire la latence, améliorer l'évolutivité, améliorer la fiabilité et réduire les coûts. Il aide également les clients AWS à définir une stratégie sans serveur efficace pour leurs applications gourmandes en calcul.

Diksha Sharma est architecte de solutions et spécialiste de l'apprentissage automatique chez AWS. Elle aide les clients à accélérer leur adoption du cloud, notamment dans les domaines du machine learning et des technologies sans serveur. Diksha déploie des preuves de concept personnalisées qui montrent aux clients la valeur d'AWS pour relever leurs défis commerciaux et informatiques. Elle permet aux clients d'acquérir leurs connaissances sur AWS et travaille à leurs côtés pour développer la solution souhaitée.

Véda Raman est un architecte de solutions spécialisé principal pour l'apprentissage automatique basé dans le Maryland. Veda travaille avec ses clients pour les aider à concevoir des applications d'apprentissage automatique efficaces, sécurisées et évolutives. Veda souhaite aider ses clients à tirer parti des technologies sans serveur pour l'apprentissage automatique.

Josh Kahn est le leader technologique mondial du sans serveur et un architecte de solutions principal. Il dirige une communauté mondiale d'experts sans serveur chez AWS qui aide les clients de toutes tailles, des start-ups aux plus grandes entreprises mondiales, à utiliser efficacement les technologies sans serveur AWS.