MLOps für Python-Modelle, die Azure Machine Learning verwenden

Diese Referenzarchitektur zeigt, wie eine Pipeline für Continuous Integration (CI), Continuous Delivery (CD) und erneutes Training für eine KI-Anwendung mit Azure DevOps und Azure Machine Learning implementiert werden kann. Die Lösung basiert auf dem Dataset „scikit-learn diabetes“, kann aber leicht an jedes KI-Szenario und andere gängige Buildsysteme wie Jenkins oder Travis angepasst werden.

Eine Referenzimplementierung für diese Architektur ist auf GitHub verfügbar.

Architektur

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Diese Architektur umfasst folgende Dienste:

Azure Pipelines Dieses Build- und Testsystem basiert auf Azure DevOps und wird für die Erstellung und Freigabe von Pipelines verwendet. Azure Pipelines unterteilt diese Pipelines in logische Schritte, die als Aufgaben bezeichnet werden. So vereinfacht z. B. die Aufgabe Azure CLI die Arbeit mit Azure-Ressourcen.

Azure Machine Learning ist ein Clouddienst für das bedarfsorientierte Trainieren, Bewerten, Bereitstellen und Verwalten von Machine Learning-Modellen. Diese Architektur verwendet das Azure Machine Learning Python SDK, um einen Arbeitsbereich, Computeressourcen, die Machine Learning-Pipeline und das Bewertungsbild zu erstellen. Ein Azure Machine Learning-Arbeitsbereich stellt den Bereich bereit, in dem Sie Modelle für maschinelles Lernen testen, trainieren und bereitstellen können.

Azure Machine Learning Compute ist ein Cluster von bedarfsgesteuerten virtuellen Computern mit automatischer Skalierung sowie GPU- und CPU-Knotenoptionen. Der Trainingsauftrag wird auf diesem Cluster ausgeführt.

Azure Machine Learning-Pipelines bieten wiederverwendbare Workflows für maschinelles Lernen, die szenarioübergreifend wiederverwendet werden können. Training, Modellauswertung, Modellregistrierung und Bilderstellung erfolgen in unterschiedlichen Schritten innerhalb dieser Pipelines für diesen Anwendungsfall. Die Pipeline wird am Ende der Erstellungsphase veröffentlicht oder aktualisiert und beim Eintreffen neuer Daten ausgelöst.

Azure Blob Storage Blobcontainer werden zum Speichern der Protokolle aus dem Bewertungsdienst verwendet. In diesem Fall werden sowohl die Eingabedaten als auch die Modellvorhersage gesammelt. Nach einer gewissen Transformation können diese Protokolle für das erneute Trainieren des Modells verwendet werden.

Azure Container Registry Das bewertende Python-Skript wird als Docker-Image verpackt und in der Registrierung versioniert.

Azure Container Instances Als Teil der Releasepipeline wird die QA- und Stagingumgebung nachgeahmt, indem das bewertende Webdienstbild für Container Instances bereitgestellt wird, was eine einfache, serverlose Möglichkeit bietet, einen Container auszuführen.

Azure Kubernetes Service Nachdem das bewertende Webdienstbild in der QA-Umgebung ausführlich getestet wurde, wird es in der Produktionsumgebung auf einem verwalteten Kubernetes-Cluster bereitgestellt.

Azure Application Insights Dieser Überwachungsdienst wird verwendet, um Leistungsanomalien zu erkennen.

MLOps-Pipeline

Diese Lösung veranschaulicht die End-to-End-Automatisierung verschiedener Phasen eines KI-Projekts mit Tools, die den Softwareentwicklern bereits vertraut sind. Das Problem des maschinellen Lernens besteht darin, den Fokus auf der DevOps-Pipeline zu halten. Die Lösung verwendet das Dataset scikit-learn diabetes und erstellt ein lineares Regressionsmodell, um die Wahrscheinlichkeit von Diabetes vorherzusagen.

Diese Lösung basiert auf den folgenden drei Pipelines:

• Buildpipeline Erstellt den Code und führt eine Reihe von Tests durch.
• Pipeline zum erneuten Training Trainiert das Modell erneut, entweder nach einem Zeitplan oder wenn neue Daten verfügbar sind.
• Releasepipeline Operationalisiert das Bewertungsbild und stuft es in verschiedenen Umgebungen sicher höher.

In den nächsten Abschnitten werden die einzelnen Pipelines beschrieben.

Buildpipeline

Die CI-Pipeline wird bei jedem Einchecken des Zeitcodes ausgelöst. Sie veröffentlicht eine aktualisierte Azure Machine Learning-Pipeline, nachdem sie den Code erstellt und eine Reihe von Tests durchgeführt hat. Die Buildpipeline besteht aus den folgenden Aufgaben:

• Codequalität Mit diesen Tests wird sichergestellt, dass der Code den Teamstandards entspricht.

• Komponententest Mit diesen Tests wird sichergestellt, dass der Code funktioniert, über ausreichende Code Coverage verfügt und stabil ist.

• Datentest Diese Tests bestätigen, dass die Datenmuster mit dem erwarteten Schema und der erwarteten Verteilung übereinstimmen. Passen Sie diesen Test für andere Anwendungsfälle an, und führen Sie ihn als separate Datenintegritätspipeline aus, die beim Eintreffen neuer Daten ausgelöst wird. Verschieben Sie beispielsweise die Datentestaufgabe in eine Datenerfassungspipeline, damit Sie sie früher testen können.

Die folgenden einmaligen Aufgaben fallen beim Einrichten der Infrastruktur für Azure Machine Learning und das SDK für Python an:

• Erstellen Sie den Arbeitsbereich, in dem alle Ressourcen für Azure Machine Learning gehostet werden.
• Erstellen Sie die Computeressourcen, die den Trainingsauftrag ausführen.
• Erstellen Sie die Machine Learning-Pipeline mit dem aktualisierten Trainingsskript.
• Veröffentlichen Sie die Machine Learning-Pipeline als REST-Endpunkt, um den Trainingsworkflow zu orchestrieren. Im nächsten Abschnitt wird dieser Schritt beschrieben.

Pipeline zum erneuten Training

Die Machine Learning-Pipeline orchestriert das erneute Trainieren des Modells auf asynchrone Weise. Das erneute Trainieren kann nach einem Zeitplan ausgelöst werden oder wenn neue Daten verfügbar sind, indem Sie den REST-Endpunkt der veröffentlichten Pipeline aus dem vorherigen Schritt aufrufen.

Diese Pipeline umfasst die folgenden Schritte:

• Trainieren eines Modells Das Python-Trainingsskript wird auf der Azure Machine Learning Compute-Ressource ausgeführt, um eine neue Modelldatei zu erhalten, die im Ausführungsverlauf gespeichert wird. Da das Training die rechenintensivste Aufgabe in einem KI-Projekt ist, verwendet die Lösung Azure Machine Learning Compute.

• Bewerten eines Modells Bei einem einfachen Bewertungstest wird das neue Modell mit dem bestehenden Modell verglichen. Erst wenn das neue Modell bessere Ergebnisse liefert, wird es höher gestuft. Andernfalls wird das Modell nicht registriert, und die Pipeline wird abgebrochen.

• Registrieren des Modells Das neu trainierte Modell wird in der Azure Machine Learning-Modellregistrierung registriert. Dieser Dienst bietet eine Versionskontrolle für die Modelle sowie Metadatentags, sodass sie leicht reproduziert werden können.

Releasepipeline

Diese Pipeline zeigt, wie Sie das Bewertungsbild operationalisieren und in verschiedenen Umgebungen sicher höher stufen können. Diese Pipeline ist in zwei Bereiche, QA und Produktion, unterteilt:

Qualitätssicherungsumgebung

• Modellieren von Artefakttriggern. Releasepipelines werden jedes Mal ausgelöst, wenn ein neues Artefakt verfügbar ist. Ein neues, in der Azure Machine Learning-Modellverwaltung registriertes Modell wird als ein Releaseartefakt behandelt. In diesem Fall wird für jedes neu registrierte Modell eine Pipeline ausgelöst.

• Erstellen eines Bewertungsimages. Das registrierte Modell wird zusammen mit einem Bewertungsskript und Python-Abhängigkeiten (Conda-YAML-Datei) in ein Docker-Operationalisierungsimage gepackt. Das Bild wird automatisch über Azure Container Registry versioniert.

• Bereitstellen in Container Instances: Dieser Dienst wird verwendet, um eine Nicht-Produktionsumgebung zu erstellen. Auch hier wird das Bewertungsbild bereitgestellt, das vor allem zum Testen verwendet wird. Container Instances bietet eine einfache und schnelle Möglichkeit, das Docker-Image zu testen.

• Testen des Webdiensts: Ein einfacher API-Test stellt sicher, dass das Bild erfolgreich bereitgestellt wird.

Produktionsumgebung

• Bereitstellen auf Azure Kubernetes Service: Dieser Dienst wird für die Bereitstellung von Bewertungsimages als bedarfsorientierter Webdienst in einer Produktionsumgebung verwendet.

• Testen des Webdiensts: Ein einfacher API-Test stellt sicher, dass das Bild erfolgreich bereitgestellt wird.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Skalierbarkeit

Eine Buildpipeline für Azure DevOps kann für Anwendungen beliebiger Größe skaliert werden. Buildpipelines verfügen über einen maximalen Timeout, der je nach Agent, auf dem sie ausgeführt werden, variiert. Builds können für immer auf selbstgehosteten Agents (privaten Agents) ausgeführt werden. Für von Microsoft gehostete Agents für ein öffentliches Projekt können Builds sechs Stunden lang ausgeführt werden. Für private Projekte beträgt der Grenzwert 30 Minuten.

Um den maximalen Timeout zu verwenden, legen Sie die folgende Eigenschaft in Ihrer Azure Pipelines YAML-Datei fest:

jobs:
- job: <job_name>
  timeoutInMinutes: 0

Im Idealfall sollten Sie Ihre Buildpipeline schnell fertig stellen und nur Komponententests und eine Teilmenge anderer Tests durchführen. Auf diese Weise können Sie die Änderungen schnell überprüfen und bei auftretenden Problemen beheben. Führen Sie zeitintensive Tests außerhalb der Geschäftszeiten durch.

Die Releasepipeline veröffentlicht einen Webdienst zur Echtzeitbewertung. Eine Freigabe in die Qualitätssicherungsumgebung erfolgt über Container Instances, aber Sie können auch einen anderen Kubernetes-Cluster verwenden, der in der Qualitätssicherungs-/Stagingumgebung ausgeführt wird.

Skalieren Sie die Produktionsumgebung entsprechend der Größe Ihres Azure Kubernetes Service-Clusters. Die Größe des Clusters hängt von der zu erwartenden Last für den bereitgestellten Bewertungswebdienst ab. Für Architekturen mit Echtzeitbewertung ist der Durchsatz eine wichtige Optimierungsmetrik. Für Szenarien ohne Deep Learning sollte die CPU ausreichend bemessen sein, um die Last zu verarbeiten. Für Deep Learning-Workloads, bei denen sich die Geschwindigkeit als Engpass erweisen kann, bieten GPUs im Allgemeinen jedoch eine bessere Leistung als CPUs. Azure Kubernetes Service unterstützt sowohl CPU- als auch GPU-Knotentypen, was der Grund dafür ist, dass diese Lösung Kubernetes Service für die Imagebereitstellung verwendet. Weitere Informationen finden Sie unter GPUs und CPUs für die Bereitstellung von Deep Learning-Modellen.

Skalieren Sie die Pipeline für das erneute Training je nach Anzahl der Knoten in Ihrer Azure Machine Learning Compute-Ressource zentral hoch oder herunter, und verwenden Sie die Option Automatische Skalierung zur Verwaltung des Clusters. In dieser Architektur werden CPUs verwendet. Für Deep Learning-Workloads sind GPUs die bessere Wahl und werden durch Azure Machine Learning Compute unterstützt.

Verwaltung

• Überwachen des Auftrags zum erneuten Trainieren: Machine Learning-Pipelines orchestrieren das erneute Training über einen Computercluster hinweg und bieten eine einfache Möglichkeit zur Überwachung der Computer. Verwenden Sie die Machine Learning-Benutzeroberfläche von Azure, und suchen Sie im Abschnitt „Pipelines“ nach den Protokollen. Alternativ werden diese Protokolle auch in ein Blob geschrieben und können von dort aus ebenfalls mit Tools wie Azure Storage-Explorer gelesen werden.

• Anmeldung. Azure Machine Learning bietet eine einfache Möglichkeit zur Protokollierung in den einzelnen Schritten des Machine Learning-Lebenszyklus. Die Protokolle werden in einem Blobcontainer gespeichert. Weitere Informationen hierzu finden Sie unter Aktivieren der Protokollierung in Azure Machine Learning. Für eine umfassendere Überwachung konfigurieren Sie Application Insights für die Verwendung der Protokolle.

• Sicherheit. Alle Geheimnisse und Anmeldeinformationen werden in Azure Key Vault gespeichert und in Azure Pipelines über Variablengruppen abgerufen.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Azure DevOps ist für Open-Source-Projekte und kleine Projekte mit bis zu fünf Benutzern kostenlos. Für größere Teams erwerben Sie einen Tarif, der auf der Anzahl der Benutzer basiert.

„Compute“ ist der größte Kostenfaktor in dieser Architektur dessen Kosten je nach Anwendungsfall variieren. Diese Architektur verwendet Azure Machine Learning Compute, aber es sind auch andere Optionen verfügbar. Durch Azure Machine Learning entstehen keine zusätzlichen Kosten zu den Kosten, die für die virtuellen Computer anfallen, die ihren Computecluster unterstützen. Konfigurieren Sie Ihren Computecluster so, dass er mindestens 0 Knoten hat, damit er, wenn er nicht verwendet wird, auf 0 Knoten herunterskaliert werden kann und somit keine Kosten anfallen. Die Computekosten sind vom Knotentyp abhängig, von der Anzahl der Knoten sowie vom Bereitstellungsmodus (niedrige Priorität oder dediziert). Sie können die Kosten für Machine Learning und andere Dienste mit dem Azure-Preisrechner schätzen.

Bereitstellen dieses Szenarios

Befolgen Sie die Schritte im Leitfaden zu den ersten Schritten im GitHub-Repository, um diese Referenzarchitektur bereitzustellen.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• Praneet Singh Solanki | Senior Software Engineer

Nächste Schritte

• Sie möchten mehr erfahren? Sehen Sie sich den verwandten Lernpfad an: Starten des Machine Learning-Lebenszyklus mit MLOps