20. Januar 2021
5 Min.

Ausrollen und Betreiben von ML-Modellen in Produktion mit KFServing

In diesem Blogpost setzen wir die MLOps-Serie fort. Dazu werden die Themen Serverless Modell-Serving, Autoscaling, Traffic Management und Versionsverwaltung behandelt. Mithilfe von KFServing können diese Themen sehr einfach und schnell in einem Kubernetes Cluster umgesetzt werden, was praktisch an einem Session-basierten ML-Empfehlungsdienst für Artikel in einem Webshop gezeigt wird. Das technische und fachliche Monitoring wird in Teil 2 dieses Beitrags aufgegriffen.

Herausforderung

Der Sprung eines ML-Modells von der Entwicklungsphase in den Produktionseinsatz ist oftmals ein sehr großer. Dafür sind komplexe Herausforderungen rund um die ganzheitliche ML-Applikation und die Infrastruktur zu bewältigen. Zunächst stehen architektonische Fragestellungen wie der Aufbau einer Cloud-Infrastruktur oder die Integration in ein vorhandenes IT-System an. Es folgen weitere infrastrukturelle Anforderungen wie beispielsweise die Wahl von Open-Source oder kommerzieller Software, Skalierbarkeit, Verfügbarkeit, Sicherheit und Erweiterbarkeit. Welcher Grad der Automatisierung wird für das kontinuierliche Ausrollen neuer Modelle und Software angestrebt? Welche Technologien und Tools werden zu diesem Zweck eingesetzt?

Die Liste der Herausforderungen ist je nach Anwendungsfall und Gegebenheiten beliebig erweiterbar. Unterhalb der Infrastruktur- und Architekturebene kommen unter Umständen weitere Fragestellungen auf wie z.B: Wie kann ich ein Pre- und Postprocessing für meinen Service verknüpfen? Wie können unterschiedliche ML-Frameworks wie TensorFlow, XGBoost, Scikit-Learn oder Pytorch als Service ausgerollt werden?

KFServing

KFServing ist eine Komponente des OpenSourceProjektes Kubeflow und stellt eine auf Kubernetes basierte Plattform bereit, um Data Scientists von infrastrukturellen Aufgaben beim Ausrollen und Betreiben von ML-Modellen verschiedener Frameworks zu befreien. Dabei werden ML-Modelle als Function as a Service auf eine sehr schnelle und einfache Art und Weise deployed, wie wir später sehen werden. KFServing stellt Funktionen wie eine automatische anfragenbasierte Skalierung der Services auf CPUs und GPUs, Explainer, Batching, A/B Testing, Multi-Armed-Bandits sowie Traffic– und Versions-Management zur Verfügung. Durch die Knative-Integration werden verschiedene Monitoring-Themen wie Outlier Detection, Drift Detection, Performance und RequestMonitoring als Erweiterungen ermöglicht. Des Weiteren lässt sich KFServing alleinstehend ohne andere Kubeflow-Komponenten auf Kubernetes installieren.

Use Case: Session-basierter Recommender für Produkte in einem Webshop

Das ML-Modell, was in diesem Blogpost in Produktion ausgerollt und betrieben werden soll, stellt auf Basis von bereits angeklickten Produkten Empfehlungen für einen fiktiven Webshop bereit:

Examplarische User-Session und zugehörige Empfehlung als Prediction

Exemplarische User-Session und Top5-Empfehlungen

In der ersten Tabelle ist ein Beispiel für eine User-Session zu sehen. Jede Zeile steht für den Aufruf des Benutzers für einen Artikel. In den Spalten sind eine Kurzbeschreibung der Kategorie sowie die Item-ID angegeben. Die zweite Tabelle zeigt den Output des ML-Recommenders auf Basis der Session. In diesem Fall sind die Top 5 Empfehlungen nach der Wahrscheinlichkeit aufgelistet. Der Benutzer hat sich in diesem Beispiel für Lampen interessiert und verschiedene Produkte angeschaut. Das ML-Modell hat gelernt, ähnliche Lampen vorzuschlagen. Der Code für das Modell-Training und die Vorverarbeitung sind im zugehörigen Repository hinterlegt.

Bei diesem Anwendungsfall kann man sich leicht vorstellen, dass zu Stoßzeiten viele Anfragen auf einmal aufkommen können. Dadurch stellt die automatische Skalierung des ML-Services auf der Grundlage von Requests eine Kernfunktion dar. Glücklicherweise steht diese Funktionalität jedem ausgerolltem Service mit KFServing automatisch zur Verfügung, was wir uns nachher anschauen werden.

Serverless Deployment des Recommender Modells als skalierbarer Service

Das Ausrollen des ML-Recommenders kann mittels der Python API von KFServing oder einer simplen YAML-Datei erfolgen. Betrachten wir zunächst die YAML-Datei, die per „kubectl apply“ deployed werden kann:


Das TensorFlow-Modell liegt ausfallsicher in einem S3 Bucket in der Amazon Cloud. Die AWS Credentials werden durch den Service Account namens sa bereitgestellt. Die wichtigen und notwendigen Einstellungen sind die Angaben des ML-Frameworks (TensorFlow) und die Runtime-Version sowie der Modell-Pfad als Storage-Uri. Die Angabe der minReplicas für den Service sind optional. Beim Setzen von 0 Replicas wird der Service bei Nichtnutzung komplett heruntergefahren. Auf der einen Seite spart das Ressourcen und auf der anderen Seite muss der Service erst hochgefahren werden, wenn eine Anfrage eintrifft. Beispielsweise kann bei großen ML-Modellen eine lange Downloadzeit auftreten. Dadurch wird die Antwortzeit bei einem Cold Start dementsprechend groß.

Damit ist der Recommender auch schon ausgerollt und wir können uns Themen rund um den Betrieb widmen. Im Jupyter-Notebook ist das gleiche Deployment über die Python API von KFServing als alternative Variante zu finden.

Betrieb in Produktion

Für das erfolgreiche Betreiben eines ML-Modells in Produktion sind je nach Anwendungsfall unterschiedliche Gesichtspunkte zu beachten. Ein zentraler ist das technische und fachliche Monitoring. Unter den technischen Aspekt fällt u.a. das Performance Monitoring des kompletten Clusters als auch der Services. Das fachliche Monitoring ist stark vom Use Case abhängig. So können Bereiche wie Outlier Detection, Adversarial Detection oder Concept Drift eine Rolle spielen, um beispielsweise zu erkennen, dass das aktuelle Modell im Laufe der Zeit obsolet geworden ist. Da das Monitoring einen größeren Bereich widerspiegelt, behandeln wir dieses Thema im zweiten Teil dieses Blogposts. Weitere wichtige Funktionen für den Betrieb eines ML-Modells in Produktion sind das Autoscaling, Traffic Management und das Ausrollen neuer Versionen.

Autoscaling

Der ausgerollte Recommender Service muss wie bereits beschrieben hochgradig verfügbar und skalierbar sein. Standardmäßig läuft über KFServing immer ein einzelner Pod als Deployment unseres Modells. Falls nun vermehrt Anfragen an den Service auftreten, werden automatisch weitere Pods gestartet:

Skalierte Pods

Skalierte Pods

Diese automatische Skalierung der Services wird durch Knative-Serving ermöglicht. Mit Knative-Serving können Deployments von und zu 0 anhand der Anfragenanzahl skaliert werden. Die Skalierung erfolgt hardwareübergreifend, also sowohl auf CPUs, GPUs oder TPUs. Die standardmäßg genutzten Metriken für die Skalierung reichen für die meisten Fälle aus, ansonsten kann man diese bei Bedarf anpassen.

Traffic Management

Istio bietet als weitere Schicht im KFServing-Ökosystem eine Plattform, um Services in Kubernetes zu überwachen, zu sichern, zu kontrollieren und den Traffic zu steuern. Ein Ziel von KFServing ist u.a., sogenannte Canary Deployments ohne Änderungen der Architektur und Infrastruktur zu ermöglichen. Canary Deployments sind eine Art A/B Test, bei dem das aktuelle Modell einen Großteil des Traffics erhält und nur ein sehr geringer Anteil an das neue, zu testende Modell weitergeleitet wird, um gewisse Anforderungen zu validieren. In KFServing ist ein Canary Deployment sehr leicht entweder über eine YAML-Datei oder die Python API umzusetzen:


Wir verifizieren den tatsächlichen Traffic-Split mithilfe von „kubectl get inferenceservices -n kfserving-test“:

Beschreibung des Inferenceservice

Beschreibung des Inferenceservice

Damit wurde mit nur einem Befehl das Canary Deployment gegeben durch 90% des Traffics an das alte und 10% an das neue Modell ausgeführt! Falls das neue Modell ausreichend getestet wurde, kann das alte komplett entfernt werden. Dazu muss nur die Zeile beginnend mit canaryTrafficPercent entfernt und angewendet werden. Auf die Weise können auch neue oder alte Modellversionen ohne Canary Deployment ausgerollt werden.

Fazit

In diesem Blogpost haben wir durch die Open-Source-Plattform KFServing auf eine sehr schnelle und einfach Art ein TensorFlow-Modell Serverless als production-ready Service ausgerollt. Durch Knative-Serving ist automatisch eine anfragenbasierte Skalierung gegeben, die sowohl mit CPUs, GPUs oder TPUs funktioniert. Zudem wurde mit einem einzelnen Befehl ein Canary Deployment umgesetzt, ohne Änderungen an der Architektur vorgenommen zu haben. Abschließend wurde das alte Modell durch das neue ersetzt.

In Teil 2 dieses Beitrags thematisieren wir das Monitoring.

Artikel kommentieren