Auteur
Cet article est la deuxième partie d'une série dans laquelle nous passons en revue le processus d'enregistrement des modèles à l'aide de Mlflow, de les servir en tant que point de terminaison d'API, et enfin de les mettre à l'échelle en fonction des besoins de notre application. Nous vous encourageons à lire notre article précédent dans lequel nous montrons comment déployer une instance de tracking sur k8s et vérifier les prérequis pratiques (secrets, variables d'environnement...) car nous continuerons à nous appuyer sur eux ici.
Dans ce qui suit, nous montrons comment servir un modèle d'apprentissage automatique qui est déjà enregistré dans Mlflow et l'exposer en tant que point d'extrémité d'API sur k8s.
Partie 2- Comment servir un modèle en tant qu'API sur Kubernetes ?
Introduction
Il est évident que le suivi et l'optimisation des performances des modèles constituent une partie importante de la création de modèles de ML. Une fois ces tâches accomplies, le défi suivant consiste à les intégrer dans une application ou un produit afin d'utiliser leurs prédictions. C'est ce que nous appelons le service des modèles ou l'inférence. Il existe différents cadres et techniques qui nous permettent de le faire. Cependant, nous nous concentrerons ici sur Mlflow et nous montrerons à quel point cela peut être efficace et simple.
Construire et déployer l'image de service
Les différents fichiers de configuration utilisés ici font partie de l'application dépôt pratique Fondamentalement, nous devons :
1. Préparez l'image docker du serveur Mlflow et mettez-la dans le registre des conteneurs sur GCP.
cd mlflow-serving-exampledocker build --tag $/mlflow_serving:v1
--file docker_mlflow_serving .docker push $/mlflow_serving:v1
2. Préparez le fichier de déploiement Kubernetes
en modifiant la section du conteneur et en l'associant à l'élément image docker précédemment transmis au GCR, le chemin du modèle et le port de desserte.
| apiVersion: apps/v1 | |
| type: Déploiement | |
| metadata: | |
| nom: mlflow-serving | |
| étiquettes: | |
| app: serve-ML-model-mlflow | |
| spécimen: | |
| répliques: 1 | |
| sélecteur: | |
| matchLabels: | |
| app: mlflow-serving | |
| modèle: | |
| metadata: | |
| étiquettes: | |
| app: mlflow-serving | |
| spécimen: | |
| conteneurs: | |
| – nom: mlflow-serving | |
| image: GCR_REPO/mlflow_serving:v1 1TP45Changer ici | |
| env: | |
| – nom: MODEL_URI | |
| valeur: “gs://../artifacts/../../artifacts/..“ 1TP45Changer ici | |
| – nom: SERVING_PORT | |
| valeur: “8082“ | |
| – nom: IDENTIFIANTS GOOGLE_APPLICATION_CREDENTIALS | |
| valeur: “/etc/secrets/keyfile.json“ | |
| volumeMounts: | |
| – nom: gcsfs-creds | |
| mountPath: “/etc/secrets“ | |
| readOnly: vrai | |
| ressources: | |
| demandes: | |
| cpu: “1000m“ | |
| volumes: | |
| – nom: gcsfs-creds | |
| secret: | |
| NomSecret: gcsfs-creds | |
| articles: | |
| – clé: fichier-clé.json | |
| chemin: fichier-clé.json |
3. Exécutez les commandes de déploiement
kubectl create -f deployments/mlflow-serving/mlflow_serving.yaml
4. Exposer le déploiement pour un accès externe
Avec la commande suivante, une nouvelle ressource sera créée pour rediriger le trafic externe vers notre API.
kubectl expose deployment mlflow-serving --port 8082 --type="LoadBalancer" (équilibreur de charge)"
5. Vérifiez le déploiement et interrogez le point final
Si le déploiement est réussi, mlflow-serving devrait être UP et un pod devrait être disponible. Vous pouvez le vérifier en tapant kubectl get pods
La dernière étape consiste à vérifier l'adresse IP externe qui a été attribuée à l'équilibreur de charge redirigeant le trafic vers notre conteneur API à l'aide de la commande kubectl get services et testez la réponse à quelques requêtes.
Un exemple de code permettant d'effectuer ces requêtes peut être trouvé dans ce qui suit carnet de notes dans laquelle nous chargeons quelques lignes de data, sélectionnons des caractéristiques, les convertissons au format JSON et les envoyons à l'API dans une requête post.
Maintenant, en combinant les étapes réalisées dans nos articles précédent et actuel, notre architecture finale ressemblerait à ce qui suit :
Conclusion
Dans cet article, nous avons montré que nous pouvons facilement déployer des modèles d'apprentissage automatique en tant que point de terminaison d'API à l'aide du module de service Mlflow.
Comme vous pouvez le remarquer, dans notre déploiement actuel, un seul pod a été créé pour servir le modèle. Bien que cela fonctionne bien pour les petites applications où nous n'attendons pas de multiples requêtes parallèles, cela pourrait rapidement montrer ses limites pour d'autres applications car un seul pod a des ressources limitées. De plus, de cette manière, l'application ne pourra pas utiliser la puissance de calcul de plus d'un nœud. Dans le prochain et dernier article de cette série, nous aborderons la question de l'évolutivité. Nous allons d'abord mettre en évidence les goulets d'étranglement et tenter de les résoudre afin d'obtenir une application évolutive qui tire parti de la puissance de notre cluster Kubernetes.
