SageMaker : Focus sur la mise en service de modèles ML
Une approche MLOps pratique et complète
L’intelligence artificielle s’est très largement démocratisée ces dernières années et le développement de systèmes intelligents tend à devenir un enjeux stratégiques pour de nombreuses entreprises. Néanmoins, trop peu de projets de Machine Learning parviennent au stade de production. SageMaker est le service AWS élaboré spécifiquement pour mener à bien tout projet ML sorti en Novembre 2017. Ce service a pour objectif de rassembler tous les outils permettant aux Data Engineers et Data Scientists de travailler efficacement afin de construire, entraîner et déployer des modèles de Machine Learning.
A travers cet article nous allons explorer SageMaker sous trois axes :
- Une vue d’ensemble de SageMaker
- Une ML Pipeline sur BitBucket permettant d’entraîner et de déployer automatiquement un modèle à travers un exemple pratique avec Tensorflow 2
- Un focus sur la gestion et le paramétrage du serving de modèles sur SageMaker
Vous pourrez trouver le code correspondant à cet article ici : sagemaker-benchmark
Une vue d’ensemble de SageMaker
SageMaker est avant tout un service complet mettant à disposition diverses ressources facilitant le développement ML. Pour n’en citer que quelques-unes principales ; il permet de créer des serveurs Notebook Instances (semblable à des Jupyter Notebooks), des tâches d’entraînement et des Endpoints pour l’inférence.
Les services liés
- S3 (Simple Storage Service) : ce service est utilisé afin de stocker les données d’entraînement, de test et de validation pour tous vos projets SageMaker. Il est utilisé par ce dernier afin de stocker d’autres éléments et en particuliers vos modèles entrainés.
- ECR (Elastic Container Registry) : ce service permet de stocker et répertorier des images Docker (de façon similaire à DockerHub) contenant l’environnement et l’application adéquats à l’entraînement et à l’inférence directement sur AWS.
- EC2 (Elastic Compute Cloud) : ce service est géré de façon totalement transparente par SageMaker. Lors de l’entraînement ou bien lors de déploiement de modèles, SageMaker fait appel aux ressources appropriées afin de s’adapter au besoin en terme de computation. A noter qu’il est possible d’utiliser des Spot Instances réduisant de façon conséquente le prix d’entraînement au dépend d’un impact sur le temps d’exécution.
Différents degrés de flexibilité
SageMaker propose différents niveaux de flexibilité quand il s’agit de construire, d’entraîner et de déployer des modèles. Voici les trois différents niveaux :
- Built-in Algorithms : Vous n’avez qu’à fournir les données et à choisir le type de modèle qui s’adapte bien à votre problématique et SageMaker se charge du reste. Cela est utile si l’on a aucune expérience en Machine Learning et lorsque l’élaboration de son propre modèle n’est pas une nécessité.
- Script Mode : On entre dans la partie où l’on peut élaborer ses propres modèles ! Il suffit simplement de fournir un code d’entraînement qui va définir l’architecture du modèle, la façon dont sont pré-traitées les données avec lesquelles le modèle est nourri, l’entraînement du modèle et la sauvegarde du modèle entraîné. Il est possible de façon équivalente de fournir son code d’inférence afin de spécifier la manière dont sont traitées les données d’entrée et de sortie. SageMaker se charge d’utiliser une image Docker adéquate selon le framework utilisé (Tensorflow, Pytorch, Sklearn … etc) et sa version (voir la liste des deep learning container images disponible)
- Container Mode : Vous pouvez voir ceci comme le Script Mode mais avec plus de liberté sur l’environnement. Il s’agit de créer sa propre image Docker pour l’entraînement et pour l’inférence (ou une pour les deux !). Les codes d’entraînement et d’inférence sont compris directement au sein de l’image. La seule contrainte est qu’il est nécessaire de respecter certaines conventions en terme de structure de dossiers au sein de l’image pour permettre la compatibilité avec SageMaker.
Mise en place d’une Pipeline ML
Nous allons voir comment concevoir une pipeline permettant d’entraîner et de déployer un modèle sur SageMaker en seulement deux clics via BitBucket Pipeline. Ce cas pratique a été réalisé avec le framework Tensorflow 2 en Script Mode avec un jeu de données expérimental déposé sur S3 que l’on ne présente plus ; MNIST. Le but n’étant pas de se concentrer sur les données utilisées ou le framework mais bien sur l’entraînement et le déploiement sur SageMaker.
Il faut donc tout d’abord créer une ressource Git Repository et Notebook Instance sur SageMaker. De cette façon, il est facile d’intégrer le versionnage au sein du serveur de notebook. A la racine du repository git, on a pris soin de déposer un fichier nommé bitbucket-pipelines.yml définissant la pipeline. Dans notre cas, cette dernière se divise en deux parties permettant d’entraîner puis de déployer le modèle sur un Endpoint SageMaker.
Il est nécessaire de préparer au préalable ses données sur S3, de créer un dossier contenant le code d’entraînement, d’inférence et le requirements.txt. Cela constitue le travail majeur de n’importe quel projet ML, dépend du problème que l’on cherche à résoudre et est indépendant de SageMaker.
Le déclenchement de l’entraînement se déroule en seulement deux simples étapes : la création d’un estimateur et l’entraînement de l’estimateur à partir de données sur S3. Cela a pour effet de générer un fichier model.tar.gz contenant le modèle entraîné sur S3.
Nous enregistrons le nom de la tâche d’entraînement comme artéfact pour le passer à la seconde étape de la pipeline, le déploiement.
Il est tout à fait possible de déployer le modèle directement à partir de l’estimateur entraîné via estimator.deploy(...). Néanmoins, nous avons choisi de séparer cette étape afin de montrer que SageMaker permet de découper ces étapes pour plus de flexibilité. Cela peut servir notamment si l’on souhaite importer un modèle entraîné localement sur S3 et le déployer tout de même sur SageMaker. Dans le cas de notre exemple, cela sert si l’on souhaite uniquement entraîner un modèle sans nécessairement le déployer ensuite ; la pipeline est divisée en deux étapes indépendantes.
Le déploiement est tout aussi simple et se réalise en deux étapes : la création du modèle pour le serving et le déploiement en Endpoint de ce dernier à partir du modèle entraîné stocké plus tôt sur S3.
Une fois le modèle déployé sur un Endpoint, vous pouvez l’invoquer afin de réaliser des prédictions sur de nouvelles données.
Voici qui décrit de bout en bout comment concevoir une ML pipeline d’entraînement et de déploiement. D’autres approches peuvent bien entendu être envisagées comme le déclenchement de la pipeline lors du dépôt de nouvelles données sur S3 (S3 Event + Lambda).
La méthode deploy(...)utilisée plus haut permet de réaliser la création transparente pour vous de trois ressources SageMaker : la création d’une ressource Model, d’une Endpoint Configuration et d’un Endpoint. Il est néanmoins possible de découper de façon indépendante la création de ces ressources. Cela permet d’avoir beaucoup plus de contrôle sur les ressources créées et de pouvoir mettre à disposition uniquement les ressources souhaitées lorsque cela est nécessaire. C’est ce que nous allons découvrir dans la prochaine section.
Approfondissement sur les fonctionnalités de serving
SageMaker permet de faciliter le déploiement de modèles ML. Néanmoins, on est assez vite limité par les fonctionnalités qu’offre la librairie sagemakersi l’on souhaite manipuler plus dans le détail les ressources disponibles sur SageMaker. Afin de mieux avoir la main sur les ressources au sein de SageMaker, la librairie boto3 bas niveau est là pour nous aider.
Model
La ressource Model dans SageMaker constitue la première étape au bon déploiement d’un Endpoint. Elle est un tout composé de trois éléments : un modèle entraîné dans S3, une image Docker ainsi que du code spécifiant le fonctionnement de l’inférence. En Script Mode, c’est deux derniers constituants sont séparés tandis qu’en Container Mode, le code d’inférence est directement compris dans l’image, il suffira alors dans ce cas de simplement indiquer l’URI de l’image ECR en paramètre de TensorflowModel(...).
Endpoint Configuration
La ressource Endpoint Configuration permet de configurer les propriétés du Endpoint. Elle permet en particulier de configurer deux aspects du Endpoint : les modèles dont il est composé ainsi que l’activation de la data capture que l’on pourrait qualifier de journaux d’entrée et/ou sortie d’inférence.
L’exemple suivant permet de créer une Endpoint Configuration avec deux ressources Model Sagemaker que l’on aurait créé au préalable où l’une à un poids de 90% et l’autre de 10%. Cela définit la répartition d’appel de chaque modèle lorsque l’Endpoint sera invoqué avec une telle configuration. Cela est particulièrement utile pour du A/B Testing ou bien pour du déploiement Blue/Green. Cette configuration inclue aussi la capture de données qui déposera sur S3, sous la forme de journaux, les entrées et sorties pour chaque appel du Endpoint. Attention ces journaux seront encodés en base64.
Endpoint
La création d’un Endpoint fait appel à la ressource Endpoint Configuration précédemment créée et peut se réaliser comme suit.
Conclusion
Ce qui n’a pas été abordé
SageMaker est un service très complet et cet article n’aborde que quelques facettes de ce service. SageMaker propose de nombreuses autres fonctionnalités comme l’étiquetage automatique de vos jeux de données sur S3, le traitement de données sur S3, l’optimisation d’hyperparamètres, les tâches de transformation par lot permettant de réaliser des prédictions sur de large données sur S3 ou encore le monitoring de vos modèles en production.
Concernant la création d’une API pour faire appel à votre Endpoint si vous ne souhaitez pas passer par le SDK de SageMaker cela se réalise à l’aide d’API Gateway et de AWS Lambda et est très bien décrit dans cet article AWS.
Les coups de coeur
- AWS a fourni un effort considérable afin de faciliter l’utilisation de SageMaker pour les novices en fournissant de très nombreux Notebook d’exemples directement accessibles depuis n’importe quelle instance de Notebook SageMaker.
- Le mode local pour l’entraînement et le déploiement est très pratique pour déboguer. Il vous permet de réaliser des tâches d’entraînement et de déploiement directement sur le serveur de Notebook sans passer par des instances ML dédiées. Ce mode accélère considérablement le temps de débogage de vos scripts d’entraînement, d’inférence et de contenu de containers s’il y a avant l’utilisation en production. Afin de l’activer, il suffit de choisir
instance_type='local'en paramètre des méthodes d’entraînement et de déploiement. - Une des plus grandes forces de SageMaker est la flexibilité de son fonctionnement. Il s’adapte à tous les frameworks ML et son utilisation est possible via différents modes suivant vos besoins : Built-In Algorithms, Script Mode et Container Mode vus plus haut.
- SageMaker a une bonne prise en main et est en même temps très complet lorsqu’on s’y plonge suffisamment ; ce qui en fait un outil d’autant plus intéressant à découvrir.
Aspects négatifs relevés
- Le déploiement d’un Endpoint est relativement long (plusieurs minutes). Lorsque l’on teste les premières fois, on va devoir faire des itérations de déploiement longues pour constater à la toute fin des erreurs.
- SageMaker ne dispose pas de système de pipeline visuel intégré — à la différence des services Microsoft Azure Machine Learning et GCP AI Platform.
- Il n’est actuellement pas possible de travailler à plusieurs simultanément sur un script sur un serveur Notebook Instance SageMaker. Les modifications appliquées par un collègue ne sont pas visibles en direct ce qui ne permet pas un travail collaboratif en temps réel. Au mieux chacun peut travailler séparément sur son propre Jupyter Notebook au sein du même serveur.
Mot de la fin
SageMaker se présente donc comme un service versatile et robuste afin de mener à bien vos projets ML de bout en bout en mettant à disposition, regroupé en un seul endroit, toutes les ressources nécessaires au développement ML et en s’occupant pour vous, et de façon transparente, des instances de computation (auto-scaling etc…). Nous avons pu voir ici la simplicité de la mise en place d’une pipeline ML pour automatiser l’entraînement et le déploiement ainsi que les fonctionnalités des ressources utilisées pour le serving de modèles sur SageMaker. En espérant vous avoir incité à y jeter sérieusement un coup d’oeil et à l’utiliser pour vos prochains projets ML !
Je suis bien entendu heureux d’aider, de répondre à vos questions et en attente de vos retours. N’hésitez pas à m’informer si vous avez apprécié l’angle choisi pour aborder SageMaker !
Neoxia aura le plaisir de présenter en détail un autre service AWS très prochainement dans un nouvel article concernant les fondamentaux de DynamoDB.
