{"id":64449,"date":"2021-10-26T16:06:03","date_gmt":"2021-10-26T15:06:03","guid":{"rendered":"https:\/\/www.artefact.com\/?post_type=news&p=64449"},"modified":"2024-09-20T17:45:46","modified_gmt":"2024-09-20T16:45:46","slug":"serving-ml-models-at-scale-using-mlflow-on-kubernetes-part-2-2","status":"publish","type":"blog","link":"https:\/\/www.artefact.com\/fr\/blog\/serving-ml-models-at-scale-using-mlflow-on-kubernetes-part-2-2\/","title":{"rendered":"Servir des mod\u00e8les ML \u00e0 l'\u00e9chelle en utilisant Mlflow sur Kubernetes - Partie 3"},"content":{"rendered":"

Auteur<\/h2><\/div>\"Image\"

Kais Laribi<\/h3><\/div>

Scientifique senior Data \u00e0 Artefact<\/p>\n<\/div><\/div><\/div><\/div><\/div>

<\/span><\/a><\/span>

Lisez notre article sur<\/u><\/p>\n<\/div>

<\/span><\/div>

.<\/p>\n<\/div><\/div><\/div><\/div><\/div>

Cet article est la troisi\u00e8me partie d'une s\u00e9rie dans laquelle nous passons en revue le processus de journalisation des mod\u00e8les \u00e0 l'aide de Mlflow, de les servir sur le moteur Kubernetes et enfin de les mettre \u00e0 l'\u00e9chelle en fonction des besoins de notre application. Bien que cet article puisse \u00eatre utilis\u00e9 ind\u00e9pendamment pour tester n'importe quelle r\u00e9ponse d'API, nous vous recommandons de lire nos deux articles pr\u00e9c\u00e9dents (partie 1 et partie 2) sur la fa\u00e7on de d\u00e9ployer une instance de suivi et de servir un mod\u00e8le en tant qu'API avec Mlflow. Dans la suite de cet article, nous nous int\u00e9resserons \u00e0 la question de la scalabilit\u00e9 et nous l'aborderons avec quelques exp\u00e9riences pour comprendre le comportement du cluster k8s et donner des recommandations sur la fa\u00e7on de g\u00e9rer des charges \u00e9lev\u00e9es.<\/p>\n<\/div><\/div><\/div><\/div><\/div>

Partie 3 - Comment g\u00e9rer des charges \u00e9lev\u00e9es et rendre notre application \u00e9volutive ?<\/h1><\/div>

Introduction<\/h2><\/div>

Dans un sc\u00e9nario classique o\u00f9 un mod\u00e8le d'apprentissage automatique est d\u00e9ploy\u00e9 derri\u00e8re une application ou un produit, plusieurs utilisateurs peuvent interagir avec lui simultan\u00e9ment pour g\u00e9n\u00e9rer des pr\u00e9dictions. Il est donc essentiel d'analyser les capacit\u00e9s de notre infrastructure et de la dimensionner en cons\u00e9quence. Cela devient particuli\u00e8rement int\u00e9ressant en ce qui concerne Kubernetes, car cela pourrait avoir un impact sur les d\u00e9cisions concernant l'utilisation ou non de l'autoscaling, le nombre maximum de n\u0153uds \u00e0 consid\u00e9rer....<\/p>\n<\/div>

Dans ce contexte, les tests de charge permettent de simuler un nombre multiple de requ\u00eates simultan\u00e9es ou incr\u00e9mentales et de surveiller le comportement de l'infrastructure (temps de r\u00e9ponse, utilisation du CPU, utilisation de la m\u00e9moire..) afin de dimensionner correctement les ressources et d'\u00e9viter les goulets d'\u00e9tranglement. Ces tests seront r\u00e9alis\u00e9s ici \u00e0 l'aide d'un outil appel\u00e9 Locust.<\/p>\n<\/div>

Pr\u00e9paration de l'environnement<\/h2><\/div>

Les exigences pour ce Hands-on sont d\u00e9taill\u00e9es dans le premier article de cette s\u00e9rie mais en guise de r\u00e9sum\u00e9, voici les principaux \u00e9l\u00e9ments dont nous avons besoin sp\u00e9cifiquement pour cette partie en supposant que notre mod\u00e8le est d\u00e9j\u00e0 d\u00e9ploy\u00e9 en tant qu'API sur un cluster Kubernetes (mlflow-k8s).<\/p>\n

Pour cette partie de l'exercice pratique, nous aurons besoin de :<\/p>\n<\/div>