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 naar gelang de behoeften van onze applicatie. We raden je aan om ons vorige artikel te lezen, waarin we laten zien hoe je een trackinginstantie op k8s implementeert en de praktische vereisten (geheimen, omgevingsvariabelen...) controleert, omdat we daar hier verder op zullen bouwen.
In het volgende artikel laten we zien hoe je een machine learning model dat al geregistreerd is in Mlflow serveert en het blootstelt als een API endpoint op k8s.
Deel 2- Hoe dien je een model als API op Kubernetes?
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 applicatie of product om hun voorspellingen te gebruiken. Dit noemen we modellen serveren of inferentie. Er zijn verschillende frameworks 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 zijn onderdeel van de hands-on repository In principe moeten we:
1. Bereid de Mlflow serving docker image voor en push het naar de containerregistry op GCP.
cd mlflow-serving-exampledocker build --tag ${GCR_REPO}/mlflow_serving:v1
--file docker_mlflow_serving .docker push ${GCR_REPO}/mlflow_serving:v1
2. Bereid het Kubernetes implementatiebestand voor
door de container sectie aan te passen en deze te koppelen aan het docker image dat eerder naar GCR is geduwd, het modelpad en de serverpoort.
| apiVersie: apps/v1 | |
| soort: Inzet | |
| metadata: | |
| naam: mlflow-serving | |
| labels: | |
| app: ml-model-mlflow serveren | |
| spec: | |
| replica's: 1 | |
| selecteur: | |
| matchLabels: | |
| app: mlflow-serving | |
| sjabloon: | |
| metadata: | |
| labels: | |
| app: mlflow-serving | |
| spec: | |
| containers: | |
| - naam: mlflow-serving | |
| afbeelding: GCR_REPO/mlflow_serving:v1 #verander hier | |
| nv: | |
| - naam: MODEL_URI | |
| waarde: "gs://../artifacts/../../artifacts/..". #Hier wijzigen | |
| - naam: SERVING_PORT | |
| waarde: "8082" | |
| - naam: GOOGLE_APPLICATION_CREDENTIALS | |
| waarde: "/etc/secrets/keyfile.json". | |
| volumeMounts: | |
| - naam: gcsfs-creds | |
| mountPath: "/etc/secrets". | |
| alleen-lezen: waar | |
| middelen: | |
| verzoeken: | |
| cpu: "1000m | |
| volumes: | |
| - naam: gcsfs-creds | |
| geheim: | |
| geheimeNaam: gcsfs-creds | |
| artikelen: | |
| - sleutel: sleutelbestand.json | |
| pad: sleutelbestand.json |
3. Voer de implementatiecommando's uit
kubectl create -f deployments/mlflow-serving/mlflow_serving.yaml
4. Stel de implementatie open voor externe toegang
Met het volgende commando wordt een nieuwe resource gemaakt 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. Je kunt dit controleren door kubectl get pods
De laatste stap is het controleren van het externe IP-adres dat is toegewezen aan de loadbalancer die het verkeer omleidt naar onze API-container met behulp van kubectl get services en de respons op een paar queries te testen.
Een voorbeeldcode om deze query's uit te voeren is te vinden in het volgende notitieblok, waarin we een paar rijen van data laden, kenmerken selecteren, ze converteren naar JSON-formaat en ze in een postverzoek naar de API sturen.
Als we nu de stappen uit onze vorige en huidige artikelen 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 je misschien hebt opgemerkt, is er in onze huidige implementatie slechts één pod aangemaakt om het model te bedienen. Hoewel dit goed werkt voor kleine applicaties waar we niet meerdere parallelle queries verwachten, kan het snel zijn grenzen tonen op andere applicaties, omdat een enkele pod beperkte bronnen heeft. Bovendien zal de applicatie op deze manier niet in staat zijn om meer dan één node rekenkracht te 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.
