Autor
Dieser Artikel ist der zweite Teil einer Serie, in der wir den Prozess der Protokollierung von Modellen mit Hilfe von Mlflow durchlaufen, sie als API-Endpunkt bereitstellen und sie schließlich entsprechend den Anforderungen unserer Anwendung skalieren. Wir empfehlen Ihnen, unseren vorherigen Artikel zu lesen, in dem wir zeigen, wie Sie eine Tracking-Instanz auf k8s bereitstellen und die praktischen Voraussetzungen (Geheimnisse, Umgebungsvariablen...) überprüfen, da wir hier weiter darauf aufbauen werden.
Im Folgenden zeigen wir, wie Sie ein bereits in Mlflow registriertes Modell für maschinelles Lernen als API-Endpunkt auf k8s bereitstellen.
Teil 2 - Wie kann ich ein Modell als API in Kubernetes bereitstellen?
Einführung
Es liegt auf der Hand, dass die Verfolgung und Optimierung der Leistung von Modellen ein wichtiger Bestandteil der Erstellung von ML-Modellen ist. Die nächste Herausforderung besteht darin, sie in eine Anwendung oder ein Produkt zu integrieren, um ihre Vorhersagen zu nutzen. Dies nennen wir die Verwendung der Modelle oder Inferenz. Es gibt verschiedene Frameworks und Techniken, die uns dies ermöglichen. Wir werden uns hier jedoch auf Mlflow konzentrieren und zeigen, wie effizient und einfach das sein kann.
Erstellen und verteilen Sie das Serving Image
Die verschiedenen hier verwendeten Konfigurationsdateien sind Teil der praktisches Repository Im Grunde genommen müssen wir das:
1. Bereiten Sie das Mlflow-Serving-Docker-Image vor und pushen Sie es in die Container-Registry auf GCP.
cd mlflow-serving-beispieldocker build --tag $/mlflow_serving:v1
--file docker_mlflow_serving .docker push $/mlflow_serving:v1
2. Bereiten Sie die Kubernetes-Bereitstellungsdatei vor
indem Sie den Container-Abschnitt ändern und ihn dem Docker-Image die zuvor an GCR gesendet wurden, der Modellpfad und den Serving Port.
| apiVersion: apps/v1 | |
| freundlich: Einsatz | |
| metadata: | |
| Name: mlflow-serving | |
| Etiketten: | |
| app: serve-ML-model-mlflow | |
| spec: | |
| Repliken: 1 | |
| Selektor: | |
| matchLabels: | |
| app: mlflow-serving | |
| Vorlage: | |
| metadata: | |
| Etiketten: | |
| app: mlflow-serving | |
| spec: | |
| Container: | |
| – Name: mlflow-serving | |
| Bild: GCR_REPO/mlflow_serving:v1 #auschen Sie hier | |
| env: | |
| – Name: MODELL_URI | |
| Wert: “gs://../artifacts/../../artifacts/..“ #auschen Sie hier | |
| – Name: SERVING_PORT | |
| Wert: “8082“ | |
| – Name: GOOGLE_APPLICATION_CREDENTIALS | |
| Wert: “/etc/geheimnisse/keyfile.json“ | |
| volumeMounts: | |
| – Name: gcsfs-creds | |
| mountPfad: “/etc/secrets“ | |
| readOnly: wahr | |
| Ressourcen: | |
| Anfragen: | |
| cpu: “1000m“ | |
| Bände: | |
| – Name: gcsfs-creds | |
| Geheimnis: | |
| secretName: gcsfs-creds | |
| Artikel: | |
| – Schlüssel: keyfile.json | |
| Pfad: keyfile.json |
3. Einsatzbefehle ausführen
kubectl create -f Bereitstellungen/mlflow-serving/mlflow_serving.yaml
4. Die Bereitstellung für den externen Zugriff freigeben
Mit dem folgenden Befehl wird eine neue Ressource erstellt, um den externen Datenverkehr auf unsere API umzuleiten.
kubectl expose deployment mlflow-serving --port 8082 --type="LoadBalancer"
5. Überprüfen Sie die Bereitstellung und fragen Sie den Endpunkt ab
Wenn die Bereitstellung erfolgreich war, sollte mlflow-serving UP sein und ein Pod sollte verfügbar sein. Sie können dies überprüfen, indem Sie Folgendes eingeben kubectl get pods
Der letzte Schritt besteht darin, die externe IP-Adresse zu überprüfen, die dem Load Balancer zugewiesen wurde, der den Verkehr zu unserem API-Container umleitet. kubectl get Dienste und testen Sie die Antwort auf ein paar Abfragen.
Ein Beispielcode zur Durchführung dieser Abfragen finden Sie im Folgenden Notizbuch in dem wir einige Zeilen von data laden, Merkmale auswählen, sie in das JSON-Format konvertieren und sie in einer Post-Anfrage an die API senden.
Wenn Sie nun die Schritte aus dem vorherigen und dem aktuellen Artikel kombinieren, würde unsere endgültige Architektur wie folgt aussehen:
Fazit
In diesem Artikel haben wir gezeigt, dass wir Modelle für maschinelles Lernen mithilfe des Mlflow-Serving-Moduls ganz einfach als API-Endpunkt bereitstellen können.
Wie Sie vielleicht bemerken, wurde in unserem aktuellen Einsatz nur ein Pod erstellt, um das Modell zu bedienen. Das funktioniert zwar gut für kleine Anwendungen, bei denen wir nicht mit mehreren parallelen Abfragen rechnen, könnte aber bei anderen Anwendungen schnell an seine Grenzen stoßen, da ein einzelner Pod nur über begrenzte Ressourcen verfügt. Außerdem kann die Anwendung auf diese Weise nicht mehr als die Rechenleistung eines Knotens nutzen. Im folgenden und letzten Artikel dieser Serie werden wir uns mit dem Problem der Skalierbarkeit befassen. Wir werden zunächst die Engpässe aufzeigen und versuchen, sie zu lösen, um eine skalierbare Anwendung zu erhalten, die die Leistung unseres Kubernetes-Clusters nutzt.
