Auteur
Dit artikel is het tweede deel van een serie waarin we het proces doorlopen van het loggen van modellen met behulp van Mlflow, ze serveren als API endpoint en ze uiteindelijk opschalen naargelang de behoeften van onze applicatie. We raden u aan om ons vorige artikel te lezen, waarin we laten zien hoe u een volginstantie op k8s kunt implementeren en de praktische vereisten (geheimen, omgevingsvariabelen...) kunt controleren, omdat we daar hier verder op zullen bouwen.
In het volgende laten we zien hoe u een machine-learningmodel dat al geregistreerd is in Mlflow kunt serveren en als API-eindpunt op k8s kunt blootstellen.
Deel 2- Hoe een model als API op Kubernetes serveren?
Inleiding
Het is duidelijk dat het bijhouden en optimaliseren van de prestaties van modellen een belangrijk onderdeel is van het maken van ML-modellen. De volgende uitdaging is om ze te integreren in een toepassing of product om hun voorspellingen te gebruiken. Dit noemen we modellen serveren of inferentie. Er zijn verschillende raamwerken en technieken waarmee we dit kunnen doen. Toch zullen we ons hier richten op Mlflow en laten zien hoe efficiënt en eenvoudig het kan zijn.
De serverafbeelding bouwen en implementeren
De verschillende configuratiebestanden die hier gebruikt worden, maken deel uit van de praktijkgerichte opslagplaats In principe moeten we:
1. Bereid het Mlflow serving docker image voor en push het naar de containerregistry op GCP.
cd mlflow-serving-voorbeelddocker build --tag $/mlflow_serving:v1
--bestand docker_mlflow_serving .docker push $/mlflow_serving:v1
2. Het Kubernetes implementatiebestand voorbereiden
door de containersectie te wijzigen en deze toe te wijzen aan de docker-afbeelding eerder naar GCR geduwd, het modelpad en de serverende poort.
| apiVersion: apps/v1 | |
| vriendelijk: Inzet | |
| metadata: | |
| naam: mlflow-serving | |
| etiketten: | |
| app: dien-ML-model-mlflow | |
| spec: | |
| replica's: 1 | |
| selector: | |
| matchLabels: | |
| app: mlflow-serving | |
| sjabloon: | |
| metadata: | |
| etiketten: | |
| app: mlflow-serving | |
| spec: | |
| containers: | |
| - naam: mlflow-serving | |
| Afbeelding: GCR_REPO/mlflow_serving:v1 1TP45Wissel hier | |
| omgeving: | |
| - naam: MODEL_URI | |
| waarde: “gs://../artifacts/../../artifacts/..“ 1TP45Wissel hier | |
| - naam: DIENSTPOORT | |
| waarde: “8082“ | |
| - naam: GOOGLE_TOEPASSING_GEGEVENS | |
| waarde: “/etc/secrets/sleutelbestand.json“ | |
| volumeMounts: | |
| - naam: gcsfs-creds | |
| mountPath: “/etc/secrets“ | |
| alleen-lezen: Echt | |
| middelen: | |
| verzoekt: | |
| cpu: “1000m“ | |
| volumes: | |
| - naam: gcsfs-creds | |
| geheim: | |
| secretName: gcsfs-creds | |
| items: | |
| - toets: sleutelbestand.json | |
| pad: sleutelbestand.json |
3. Implementatieopdrachten uitvoeren
kubectl create -f deployments/mlflow-serving/mlflow_serving.yaml
4. Stel de implementatie open voor externe toegang
Met de volgende opdracht wordt een nieuwe resource aangemaakt om extern verkeer om te leiden naar onze API.
kubectl expose deployment mlflow-serving --port 8082 --type="LoadBalancer"
5. Controleer de implementatie en vraag het eindpunt op
Als de implementatie succesvol is, zou mlflow-serving UP moeten zijn en zou er één pod beschikbaar moeten zijn. U kunt dat controleren door te typen kubectl get pods
De laatste stap is het controleren van het externe IP-adres dat werd toegewezen aan de loadbalancer die het verkeer omleidt naar onze API-container met behulp van kubectl get diensten en test de respons op een paar query's.
Een voorbeeldcode om deze query's uit te voeren vindt u in het volgende notebook waarin we enkele rijen van data laden, kenmerken selecteren, converteren naar JSON-formaat en in een postverzoek naar de API sturen.
Als we nu de stappen uit ons vorige en huidige artikel combineren, ziet onze uiteindelijke architectuur er als volgt uit:
Conclusie
In dit artikel hebben we laten zien dat we eenvoudig machine learning-modellen kunnen implementeren als een API eindpunt met behulp van de Mlflow serving module.
Zoals u misschien ziet, is er in onze huidige implementatie slechts één pod aangemaakt om het model te bedienen. Hoewel dit goed werkt voor kleine toepassingen waar we niet meerdere parallelle queries verwachten, zou het snel zijn grenzen kunnen laten zien op andere toepassingen, aangezien een enkele pod beperkte bronnen heeft. Bovendien kan de applicatie op deze manier niet meer dan één node aan rekenkracht gebruiken. In het volgende en laatste artikel van deze serie zullen we het schaalbaarheidsprobleem aanpakken. We zullen eerst de knelpunten belichten en proberen deze op te lossen om een schaalbare applicatie te krijgen die gebruik maakt van de kracht van ons Kubernetes-cluster.
