Konzepte MLOps (DevOps für Machine Learning)

Was ist MLOps?

MLOps oder auch CD4ML (Continuous Delivery for Machine Learning) wenden DevOps-Prinzipien der Softwareentwicklung auf Machine Learning (ML) an. Vorhandene Best Practices werden um die Anforderungen von Machine Learning erweitert, sodass sich durch Automatisierungen schnelle Ausrollzyklen für neue Software ergeben. Dabei wird der gesamte Lebenszyklus von Machine Learning – sowohl die Entwicklung als auch der Betrieb – überwacht und gesteuert. Folgende wesentliche Komponenten sind dabei zu beachten:

• Datenversionierung
• Modellversionierung
• Reproduzierbarkeit von Experimenten
• Tracking von Experimenten (z.B. Parameter und Metriken für jedes Training)
• Machine Learning Pipelines
• Monitoring aller Schritte des ML-Systems
• Produktiver Einsatz von ML-Modellen
• Management der Infrastruktur
• Continuous Delivery Orchestration
• Unterschiedliche Teamrollen

Diese Komponenten werden im weiteren Verlauf einzeln beleuchtet. Ich werde mich zwecks Technologien und Tools hauptsächlich auf Open Source Tools fokussieren. Die üblichen Cloudanbieter stellen Plattformen und Services wie das Microsoft Azure Machine Learning Studio oder AWS SageMaker zur Verfügung, die viele der genannten Komponenten als Features beinhalten. Für diese Cloud-Services werden in der Regel die Nutzung und der Ressourcenverbrauch zur Kostenermittlung herangezogen.

Wer braucht MLOps und wozu?

Die kurze Antwort: Jedes ML Projekt benötigt zumindest Teile der oben genannten Komponenten, selbst wenn ein produktiver Einsatz nicht feststeht. Beispielsweise sind Prinzipien wie eine Daten- und Modellversionierung sowie das Dokumentieren von Metriken und Parametern grundsätzlich in jedem ML-Projekt dringend zu empfehlen.

Der Schwerpunkt von MLOps zielt auf das Automatisieren aller Workflows ab, um so ein schnelles und kontinuierliches Ausrollen von qualitativ hochwertigen Modellen und Software in den produktiven Betrieb zu ermöglichen. Nach einem bekannten Paper von Google aus dem Jahr 2015 ist der Zeitaufwand für die Entwicklung von eigentlichem ML-Code sehr viel geringer als der Aufwand für das technische Umfeld und infrastrukturelle Themen eines Machine Learning Systems. Laut den Autoren lauern an vielen Stellen Gefahren wie z.B. technische Schulden, die häufig stark unterschätzt werden. Das Paper zeigt damit, dass das Bewusstsein für MLOps und im Speziellen für die Wartbarkeit und Operationalisierung von Machine Learning besonderer Aufmerksamkeit bedarf.

Komponenten von MLOps

Daten- und Modellversionierung sowie Reproduzierbarkeit von Experimenten. Zusätzlich zur Code-Versionierung ist im Machine Learning Kontext eine Daten- und Modellversionierung erforderlich, um reproduzierbare Experimente zu ermöglichen. Hierfür können Open Source Tools wie DVC oder MLflow eingesetzt werden.

Tracking von Experimenten. Machine Learning ist von Natur aus durch ein experimentelles Vorgehen geprägt: Üblicherweise probieren Data Scientists viele Algorithmen mit verschiedenen Parameterkonfigurationen und unterschiedlichen Daten und Features aus, um die bestmögliche Lösung für ihr Problem zu finden. Dieser Vorgang muss mit allen relevanten Parametern und Versionen dokumentiert werden. Nur so lässt sich im Nachhinein feststellen, welches Ergebnis unter welchen Bedingungen zustande gekommen ist. Für diesen Zweck habe ich das Open Source Tool MLflow  in einem weiteren Blogpost ausführlicher beschrieben.

ML-Pipelines. Alle Teilschritte eines Machine Learning Trainings wie beispielsweise die Datenextrahierung, Datenvalidierung, Datenvorverarbeitung, Modelltraining, Modelltuning und Modellevaluierung werden als Pipeline mit definierten Inputs und Outputs abgebildet, damit eine Automatisierung dieser Schritte möglich wird. Es gibt viele Möglichkeiten eine Pipeline zu orchestrieren und auszuführen. Je nach Projekt sind von Glue Code bis hin zu Tools wie Apache Airflow, Kubeflow, Apache Beam oder Cloud-Pipelines einsetzbar. Im Fokus sollte die Standardisierung der ML-Pipelines stehen, die sowohl Monitoring als auch Debugging einzelner Schritte erlauben. Weitere projektspezifische Anforderungen wie z.B. Skalierbarkeit sind ebenfalls zu beachten. Eine exemplarische ML-Pipeline mit Kubeflow und MLflow wird hier erläutert.

Monitoring. MLOps soll dazu befähigen, ein Monitoring für alle Schritte des ML-Systems zu erreichen. Das beinhaltet unter anderem ein Modell-Monitoring im Betrieb, Deployment-Monitoring, Monitoring der Pipeline Orchestration und Monitoring der Parameter und Metriken für verschiedene Trainingsdurchläufe und Modelle. Beim Modell-Monitoring wird die Performance der Modelle im produktiven Einsatz durch echte Daten gemessen. Anhand verschiedener Statistiken kann abgeleitet werden, ob beispielsweise ein sogenannter Concept Drift im Laufe der Zeit stattgefunden hat. Dabei hat sich die Verteilung der Daten so signifikant verändert, dass die Vorhersagen der ML-Modelle nicht mehr akkurat sind. Diese Erkenntnis sollte eine neue Trainingsschleife mit aktuellen Daten auslösen. Weitere Gründe für das Triggern eines neuen Trainings könnten sein: manuelles und zeitbasiertes Auslösen; Verfügbarkeit neuer Daten; schlechte Performance des Modells. Des Weiteren sollte im Falle einer Service-Architektur ein Performance Monitoring betrieben werden, um Metriken wie Queries pro Sekunde, Modell-Latenzen oder Verfügbarkeiten zu überwachen. Ein Beispiel für ein ausführliches Monitoring eines ML-Empfehlungsdienstes in Produktion wird in diesem Blogpost demonstriert.

Produktiver Einsatz von ML-Modellen. Darunter fällt u.a. die technische Umsetzung von Machine Learning Modellen für den produktiven Einsatz. Hierbei gilt es, geeignete Technologien und/oder Plattformen entsprechend den Anforderungen an die ML-Applikation zu betrachten und zu evaluieren. Falls z.B. mehrere Tausend Anfragen pro Sekunde zu erwarten sind, ist eine service-orientierte, skalierende Architektur mittels Kubernetes oder Managed Cloud Kubernetes Services (wie z.B. Amazon Elastic Kubernetes Service oder Azure Kubernetes Service) in Erwägung zu ziehen. Wie ein ML-Modell als skalierbarer Service in Kubernetes mit KFServing ausgerollt werden kann, ist in diesem Blogpost beschrieben.

Management der Infrastruktur. Je nach der Größe eines Machine Learning Projektes ist es sinnvoll, mehrere Umgebungen wie eine Entwicklungs-, Test- und Produktionsumgebung einzusetzen. Konzepte wie Infrastructure as Code für eine dynamische Bereitstellung einer Infrastruktur on demand können dafür verwendet werden. Eine beliebte Open Source Lösung ist z.B. Terraform.

Continuous Delivery Orchestration. Zusammen mit den bisherigen Komponenten fehlt nur noch eine übergeordnete Orchestration, mit der die Machine Learning Pipelines wie dem Trainingsprozess automatisiert ausgerollt werden. Wichtig an dieser Stelle ist, noch mal den Unterschied zwischen einer ML-Pipeline (z.B. Trainingsprozess) und einer Deployment-Pipeline (Ausrollen einer ML-Pipeline) zu betonen. Schließlich können sich auch ML-Pipelines verändern und müssen daher versioniert und getestet werden, bevor sie als automatisierte Pipeline in die Produktion überführt werden können. Bekannte CI/CD Tools sind zum Beispiel Jenkins oder Gitlab CI/CD und natürlich existieren noch viele weitere.

Unterschiedliche Teamrollen. Je nach MLOps-Reifegrad eines Projektes treten die folgenden typischen Rollen auf: Data Scientists, ML Ops Engineers und eventuell Data Engineers. Natürlich kann entsprechend der Projektanforderungen eine Person mehrere Rollen innehaben. Ein Data Engineer stellt die Datengrundlage für Analysen wie Machine Learning bereit. Data Scientists beginnen meistens mit einer explorativen Datenanalyse, führen verschiedene Datenvorverarbeitungen und Merkmalsextraktionen durch, konzipieren State of the Art ML-Modelle und evaluieren die Ergebnisse. ML Ops Engineers sind verantwortlich für das Ausrollen, Warten und Monitoring der ML-Applikation.

Der Blogpost gibt eine Übersicht über wichtige Aspekte von MLOps bzw. der Operationalisierung von Machine Learning. In weiteren Blogposts werde ich gezielt auf einzelne Komponenten eingehen.