Architektur für MLOps mit TFX, Kubeflow Pipelines und Cloud Build

In diesem Dokument wird die Gesamtarchitektur eines ML-Systems mit Bibliotheken von TensorFlow Extended (TFX) beschrieben. Außerdem wird erläutert, wie Sie mit Cloud Build und Kubeflow Pipelines Continuous Integration (CI), Continuous Delivery (CD) und Continuous Training (CT) für das ML-System einrichten.

In diesem Dokument beziehen sich die Begriffe ML-System und ML-Pipeline auf Schulungspipelines des ML-Modells und nicht auf die Modellbewertung oder Vorhersagepipelines.

Dieses Dokument richtet sich an Data Scientists und ML-Entwickler, die ihre CI/CD-Verfahren anpassen möchten, um ML-Lösungen in die Produktion in Google Cloud zu verschieben und die Qualität, Wartbarkeit und Anpassungsfähigkeit ihrer ML-Pipelines zu garantieren.

In diesem Dokument werden folgende Themen behandelt:

  • Informationen zu CI/CD und Automatisierung in ML
  • Entwerfen einer integrierten ML-Pipeline mit TFX
  • Orchestrieren und Automatisieren der ML-Pipeline mit Kubeflow Pipelines
  • Einrichten eines CI/CD-Systems für die ML-Pipeline mit Cloud Build

MLOps

Zum Einbinden eines ML-Systems in eine Produktionsumgebung müssen Sie die Schritte in Ihrer ML-Pipeline orchestrieren. Außerdem müssen Sie die Ausführung der Pipeline für das kontinuierliche Training Ihrer Modelle automatisieren. Zum Ausprobieren neuer Ideen und Features müssen Sie CI/CD-Verfahren in den neuen Implementierungen der Pipelines anwenden. Die folgenden Abschnitte bieten einen allgemeinen Überblick über CI/CD und CT in ML.

ML-Pipeline-Automatisierung

In einigen Anwendungsfällen kann manuelles Trainieren, Validieren und Bereitstellen von ML-Modellen ausreichend sein. Dieser manuelle Ansatz funktioniert, wenn Ihr Team nur wenige ML-Modelle verwaltet, die nicht neu trainiert oder nicht häufig geändert werden. In der Praxis funktionieren Modelle jedoch häufig nicht, wenn sie in der realen Welt bereitgestellt werden. Das liegt daran, dass sie sich nicht an Änderungen der Umgebungsdynamik oder der Daten anpassen, die diese Dynamiken beschreiben.

Damit sich Ihr ML-System an solche Änderungen anpassen kann, müssen Sie die folgenden MLOps-Techniken anwenden:

  • Automatisieren Sie die Ausführung der ML-Pipeline, um neue Modelle für neue Daten neu zu trainieren und neue Muster zu erfassen. CT wird weiter unten in diesem Dokument im Abschnitt ML mit Kubeflow Pipelines behandelt.
  • Richten Sie ein Continuous Delivery-System ein, um häufig neue Implementierungen der gesamten ML-Pipeline bereitzustellen. CI/CD wird später in diesem Dokument im Abschnitt CI/CD-Einrichtung für ML in Google Cloud erläutert.

Sie können die ML-Produktionspipelines automatisieren, um Ihre Modelle mit neuen Daten neu zu trainieren. Sie können Ihre Pipeline bei Bedarf, nach einem Zeitplan, bei Verfügbarkeit neuer Daten, bei einer Verschlechterung der Modellleistung, bei erheblichen Änderungen der statistischen Attribute der Daten oder anhand anderer Bedingungen auslösen.

CI/CD-Pipeline im Vergleich zur CT-Pipeline

Die Verfügbarkeit neuer Daten ist ein Trigger, um das ML-Modell neu zu trainieren. Die Verfügbarkeit einer neuen Implementierung der ML-Pipeline (einschließlich neuer Modellarchitektur, Feature Engineering und Hyperparameter) ist ein weiterer wichtiger Trigger für die neue Ausführung der ML-Pipeline. Diese neue Implementierung der ML-Pipeline dient als neue Version des Modellvorhersagedienstes, z. B. als Mikrodienst mit einer REST API für die Onlinebereitstellung. So unterscheiden sich die beiden Fälle:

  • Zum Trainieren eines neuen ML-Modells mit neuen Daten wird die zuvor bereitgestellte CT-Pipeline ausgeführt. Es werden keine neuen Pipelines oder Komponenten bereitgestellt. Nur ein neuer Vorhersagedienst oder ein neu trainiertes Modell wird am Ende der Pipeline bereitgestellt.
  • Zum Trainieren eines neuen ML-Modells mit einer neuen Implementierung wird eine neue Pipeline über eine CI/CD-Pipeline bereitgestellt.

Wenn Sie neue ML-Pipelines schnell bereitstellen möchten, müssen Sie eine CI/CD-Pipeline einrichten. Diese Pipeline ist für die automatische Bereitstellung neuer ML-Pipelines und -Komponenten verantwortlich, wenn neue Implementierungen für verschiedene Umgebungen (z. B. Entwicklung, Test, Staging, Vorproduktion, Canary und Produktion) verfügbar und genehmigt sind.

Das folgende Diagramm zeigt die Beziehung zwischen der CI/CD-Pipeline und der ML-CT-Pipeline.

Die Ausgabe der CI/CD-Pipeline ist die CT-Pipeline.

Abbildung 1. CI/CD- und ML-CT-Pipelines

Die Ausgabe für diese Pipelines sieht so aus:

  • Bei einer neuen Implementierung stellt eine erfolgreiche CI/CD-Pipeline eine neue ML-CT-Pipeline bereit.
  • Bei neuen Daten liefert eine erfolgreiche CT-Pipeline einen neuen Modellvorhersagedienst.

TFX-basiertes ML-System entwerfen

In den folgenden Abschnitten wird erläutert, wie Sie ein integriertes ML-System mit TensorFlow Expand (TFX) erstellen, um eine CI/CD-Pipeline für das ML-System einzurichten. Obwohl es mehrere Frameworks zum Erstellen von ML-Modellen gibt, ist TFX eine eingebundene ML-Plattform für die Entwicklung und Bereitstellung von ML-Produktionssystemen. Eine TFX-Pipeline ist eine Abfolge von Komponenten, die ein ML-System implementieren. Diese TFX-Pipeline wurde für skalierbare, leistungsstarke ML-Aufgaben entwickelt. Zu diesen Aufgaben gehören die Modellierung, das Training, die Validierung, die Bereitstellung von Inferenzen und die Verwaltung von Bereitstellungen. Das sind die Schlüsselbibliotheken von TFX:

TFX-ML-System im Überblick

Das folgende Diagramm zeigt, wie die verschiedenen TFX-Bibliotheken in ein ML-System eingebunden werden.

Schritte eines TFX-basierten ML-Systems

Abbildung 2. Ein typisches TFX-basiertes ML-System

Abbildung 2 zeigt ein typisches TFX-basiertes ML-System. Die folgenden Schritte können manuell oder über eine automatisierte Pipeline ausgeführt werden:

  1. Datenextraktion: Der erste Schritt besteht darin, die neuen Trainingsdaten aus ihren Datenquellen zu extrahieren. Die Ausgaben dieses Schritts sind Datendateien, die zum Trainieren und Bewerten des Modells verwendet werden.
  2. Datenvalidierung: Die Daten werden von TFDV mit dem erwarteten Rohdatenschema überprüft. Das Datenschema wird in der Entwicklungsphase vor der Systembereitstellung erstellt und korrigiert. Die Datenvalidierungsschritte erkennen Anomalien, die sich sowohl auf die Datenverteilung als auch auf Schemaabweichungen beziehen. Die Ausgaben dieses Schritts sind eventuelle Anomalien und eine Entscheidung, ob nachgelagerte Schritte ausgeführt werden sollen.
  3. Datentransformation: Nach der Validierung der Daten werden die Daten aufgeteilt und für die ML-Aufgabe vorbereitet. Dazu werden Datentransformationen und Feature Engineering-Vorgänge mit TFT durchgeführt. Die Ausgaben dieses Schritts sind Datendateien zum Trainieren und Bewerten des Modells, die normalerweise in das Format TFRecords transformiert werden. Außerdem helfen die erzeugten Transformationsartefakte beim Erstellen der Modelleingaben und beim Exportieren des gespeicherten Modells nach dem Training.
  4. Modelltraining und -abstimmung: Verwenden Sie zum Implementieren und Trainieren des ML-Modells die APIs tf.estimator oder tf.Keras mit den transformierten Daten, die im vorherigen Schritt erstellt wurden. Um die Parametereinstellungen auszuwählen, die zum besten Modell führen, können Sie Keras-Tuner, eine Hyperparameter-Abstimmungsbibliothek für Keras, oder andere Dienste wie Katib verwenden. Die Ausgabe dieses Schritts ist ein gespeichertes Modell, das zur Bewertung verwendet wird, und ein weiteres gespeichertes Modell, das zur Onlinebereitstellung des Modells für die Vorhersage verwendet wird.
  5. Modellbewertung und -validierung: Wenn das Modell nach dem Trainingsschritt exportiert wird, wird es mit einem Test-Dataset zum Bestimmen der Modellqualität mit TFMA bewertet. Mithilfe von TFMA wird die Modellqualität als Ganzes bewertet und ermittelt, welcher Teil des Datenmodells nicht funktioniert. Diese Bewertung trägt dazu bei, dass das Modell nur dann zur Bereitstellung hochgestuft wird, wenn es die Qualitätskriterien erfüllt. Die Kriterien können eine gleichmäßige Leistung für verschiedene Teilmengen von Daten (z. B. demografische Merkmale und Standorte) und eine verbesserte Leistung im Vergleich zu früheren Modellen oder einem Benchmark-Modell umfassen. Die Ausgabe dieses Schritts besteht aus einer Reihe von Leistungsmesswerten und der Entscheidung, ob das Modell in die Produktion hochgestuft werden soll.
  6. Modellbereitstellung für die Vorhersage: Nachdem das neu trainierte Modell validiert wurde, wird es als Mikrodienst bereitgestellt, um Onlinevorhersagen mit TensorFlow Serving bereitzustellen. Die Ausgabe dieses Schritts ist ein bereitgestellter Vorhersagedienst des trainierten ML-Modells. Sie können diesen Schritt ersetzen, indem Sie das trainierte Modell in einem Modell-Registry speichern. Anschließend wird ein separates Modell zur Bereitstellung des CI/CD-Prozesses gestartet.

Eine Anleitung für die TFX-Bibliotheken finden Sie unter ML mit TensorFlow Extended (TFX).

TFX-ML-System in Google Cloud

In einer Produktionsumgebung müssen die Komponenten des Systems auf einer zuverlässigen Plattform skaliert ausgeführt werden. Das folgende Diagramm zeigt, wie die einzelnen Schritte der TFX-ML-Pipeline mit einem verwalteten Dienst in Google Cloud ausgeführt werden. Dies sorgt für Flexibilität, Zuverlässigkeit und Leistung im großen Maßstab.

Schritte eines TFX-basierten ML-Systems in Google Cloud

Abbildung 3. TFX-basiertes ML-System in Google Cloud

In der folgenden Tabelle werden die in Abbildung 3 gezeigten Google Cloud-Hauptdienste beschrieben:

Schritt TFX-Bibliothek Google Cloud-Dienst
Datenextraktion und -validierung TensorFlow Data Validation Dataflow
Datenumwandlung TensorFlow Transform Dataflow
Modelltraining und -abstimmung TensorFlow AI Platform Training
Modellbewertung und -validierung TensorFlow Model Analysis Dataflow
Modellbereitstellung für die Vorhersage TensorFlow bereitstellen AI Platform Prediction
Speicher für Modellartefakte AI Hub
  • Dataflow ist ein vollständig verwalteter, serverloser und zuverlässiger Dienst zum Ausführen von Apache Beam-Pipelines in großem Maßstab in Google Cloud. Mit Dataflow werden die folgenden Prozesse skaliert:

    • Berechnen von Statistiken zur Validierung der eingehenden Daten
    • Datenvorbereitung und -transformation
    • Auswerten des Modells für ein großes Dataset
    • Berechnen von Messwerten für verschiedene Aspekte des Bewertungs-Datasets
  • Cloud Storage ist ein hochverfügbarer und dauerhafter Speicher für binäre große Objekte. Cloud Storage hostet Artefakte, die während der Ausführung der ML-Pipeline erzeugt werden, darunter:

    • Datenanomalien (falls vorhanden)
    • Transformierte Daten und Artefakte
    • Exportiertes (trainiertes) Modell
    • Modellbewertungsmesswerte
  • AI Hub ist ein gehostetes Repository für Unternehmen zum Erkennen, Freigeben und Wiederverwenden von KI- und ML-Assets. Wenn Sie trainierte und validierte Modelle sowie deren relevante Metadaten speichern möchten, können Sie AI Hub als Modell-Registry verwenden.

  • AI Platform ist ein verwalteter Dienst zum Trainieren und Bereitstellen von ML-Modellen in großem Maßstab. AI Platform Training unterstützt nicht nur TensorFlow-, Scikit-learn- und XGboost-Modelle, sondern auch Modelle, die mit einem vom Nutzer bereitgestellten benutzerdefinierten Container in einem Framework implementiert werden. Außerdem ist ein skalierbarer Bayes'scher Optimierungsdienst für eine Hyperparameterabstimmung verfügbar. Trainierte Modelle können in AI Platform Prediction als Mikrodienst mit einer REST API bereitgestellt werden.

ML-System mit Kubeflow Pipelines orchestrieren

In diesem Dokument wurde beschrieben, wie Sie ein TFX-basiertes ML-System entwerfen und jede Komponente des Systems in großem Maßstab in Google Cloud ausführen. Sie benötigen jedoch einen Orchestrator, um diese verschiedenen Komponenten des Systems miteinander zu verbinden. Der Orchestrator führt die Pipeline in einer Reihenfolge aus und wechselt anhand der definierten Bedingungen automatisch von einem Schritt zum nächsten. Beispielsweise kann eine definierte Bedingung den Modellbereitstellungsschritt nach dem Modellbewertungsschritt ausführen, wenn die Bewertungsmesswerte vordefinierte Schwellenwerte erreichen. Die Orchestrierung der ML-Pipeline ist sowohl in der Entwicklungs- als auch in der Produktionsphase nützlich:

  • Während der Entwicklungsphase hilft die Orchestrierung den Data Scientists, den ML-Test so auszuführen, dass nicht jeder Schritt manuell ausgeführt werden muss.
  • Während der Produktionsphase unterstützt die Orchestrierung die Ausführung der ML-Pipeline anhand eines Zeitplans oder bestimmter Auslösungsbedingungen zu automatisieren.

ML mit Kubeflow Pipelines

Kubeflow ist ein Open-Source-Framework für Kubernetes zum Entwickeln und Ausführen von mobilen ML-Arbeitslasten. Kubeflow Pipelines ist ein Kubeflow-Dienst, mit dem Sie ML-Systeme erstellen, orchestrieren und automatisieren können, wobei jede Komponente des Systems auf Kubeflow, Google Cloud oder anderen Cloud-Plattformen ausgeführt werden kann. Die Kubeflow Pipelines-Plattform besteht aus folgenden Komponenten:

  • Einer Benutzeroberfläche zum Verwalten und Verfolgen von Tests, Jobs und Ausführungen.
  • Einem Modul zum Planen von mehrstufigen ML-Workflows. Kubeflow-Pipelines verwenden Argo zur Orchestrierung von Kubernetes-Ressourcen.
  • Einem Python SDK zum Definieren und Bearbeiten von Pipelines und Komponenten.
  • Notebooks für die Interaktion mit dem System über das Python SDK.
  • Einem ML-Metadatenspeicher zum Speichern von Informationen zu Ausführungen, Modellen, Datasets und anderen Artefakten.

Im Folgenden wird eine Kubeflow-Pipeline dargestellt:

  • Eine Reihe von containerisierten ML-Aufgaben oder Komponenten. Eine Pipeline-Komponente ist eigenständiger Code, der in ein Docker-Image gepackt wird. Eine Komponente übernimmt Eingabeargumente, erstellt Ausgabedateien und führt einen Schritt in der Pipeline aus.

  • Eine Spezifikation der Reihenfolge der ML-Aufgaben, die über eine domainspezifische Python-Sprache (DSL) definiert wird. Die Topologie des Workflows wird implizit definiert, indem die Ausgaben eines vorgelagerten Schritts mit den Eingaben eines nachgelagerten Schritts verbunden werden. Ein Schritt in der Pipeline-Definition ruft eine Komponente in der Pipeline auf. In einer komplexen Pipeline können Komponenten mehrmals in Schleifen oder unter bestimmten Bedingungen ausgeführt werden.

  • Eine Reihe von Pipeline-Eingabeparametern, deren Werte an die Komponenten der Pipeline übergeben werden, einschließlich der Kriterien zum Filtern von Daten und des Speicherorts der von der Pipeline erzeugten Artefakte.

Das folgende Diagramm zeigt eine Beispielgrafik von Kubeflow Pipelines.

Grafik der ML-Pipeline mit Kubeflow Pipelines

Abbildung 4. Eine Beispielgrafik von Kubeflow Pipelines

Kubeflow Pipelines-Komponenten

Damit eine Komponente in der Pipeline aufgerufen werden kann, müssen Sie so einen Komponentenvorgang erstellen:

  • Einfache Python-Komponente implementieren: Diese Komponente erfordert nicht, dass Sie für jede Codeänderung ein neues Container-Image erstellen. Sie ist für eine schnelle Iteration in einer Notebookumgebung vorgesehen. Mit der Funktion kfp.components.func_to_container_op können Sie eine einfache Komponente aus Ihrer Python-Funktion erstellen.

  • Wiederverwendbare Komponente erstellen: Für diese Funktion muss Ihre Komponente eine Komponentenspezifikation in der Datei component.yaml enthalten. Die Komponentenspezifikation beschreibt Kubeflow Pipelines die Komponente in Bezug auf Argumente, die auszuführende Docker-Container-Image-URL und die Ausgaben. Komponentenvorgänge werden während der Pipelinekompilierung automatisch aus den component.yaml-Dateien mit der Funktion ComponentStore.load_components im Kubeflow Pipelines SDK erstellt. Wiederverwendbare component.yaml-Spezifikationen können für AI Hub freigegeben werden, um sie in verschiedenen Kubeflow Pipelines-Projekten zusammenzusetzen.

  • Vordefinierte Google Cloud-Komponenten verwenden: Kubeflow Pipelines bietet vordefinierte Komponenten, die verschiedene verwaltete Dienste in Google Cloud ausführen, indem sie die erforderlichen Parameter angeben. Mit diesen Komponenten können Sie Aufgaben mithilfe von Diensten wie BigQuery, Dataflow, Dataproc und AI Platform ausführen. Diese vordefinierten Google Cloud-Komponenten sind auch in AI Hub verfügbar. Ähnlich wie bei der Verwendung wiederverwendbarer Komponenten werden diese Komponentenvorgänge automatisch aus den vordefinierten Komponentenspezifikationen über ComponentStore.load_components erstellt. Für die Ausführung von Jobs in Kubeflow und anderen Plattformen stehen weitere vordefinierte Komponenten zur Verfügung.

Sie können auch die TFX Pipeline DSL und TFX-Komponenten verwenden. Eine TFX-Komponente kapselt Metadatenfunktionen. Der Treiber stellt Metadaten für den Executor bereit, indem er den Metadatenspeicher abfragt. Der Publisher akzeptiert die Ergebnisse des Executors und speichert sie in Metadaten. Sie können auch Ihre benutzerdefinierte Komponente implementieren, die dieselbe Einbindung mit den Metadaten hat. TFX bietet eine Befehlszeilenschnittstelle, die den Python-Code der Pipeline in einer YAML-Datei kompiliert und den Argo-Workflow beschreibt. Anschließend können Sie die Datei an Kubeflow Pipelines senden.

Das folgende Diagramm zeigt, wie eine containerisierte Aufgabe in Kubeflow Pipelines andere Dienste wie BigQuery-Jobs, verteilte AI Platform-Trainingsjobs und Dataflow-Jobs aufrufen kann.

Architektur von Kubeflow Pipelines in Google Cloud

Abbildung 5. ML-Pipeline mit Kubeflow Pipelines und verwalteten Google Cloud-Diensten

Mit Kubeflow Pipelines können Sie eine ML-Produktionspipeline durch Ausführung der erforderlichen Google Cloud-Dienste orchestrieren und automatisieren. In Abbildung 5 dient Cloud SQL als ML-Metadatenspeicher für Kubeflow Pipelines.

Die Kubeflow Pipelines-Komponenten sind nicht auf die Ausführung von TFX-Diensten in Google Cloud beschränkt. Diese Komponenten können alle daten- und rechenbezogenen Dienste ausführen, einschließlich Dataproc für SparkML-Jobs, AutoML und anderer Computing-Arbeitslasten.

Das Containerisieren von Aufgaben in Kubeflow Pipelines bietet folgende Vorteile:

  • Entkoppelt die Ausführungsumgebung von der Codelaufzeit.
  • Bietet eine Reproduzierbarkeit des Codes zwischen der Entwicklungs- und Produktionsumgebung, da die zu testenden Elemente in der Produktion identisch sind.
  • Isoliert jede Komponente in der Pipeline. Jede kann eine eigene Laufzeitversion sowie verschiedene Sprachen und Bibliotheken haben.
  • Hilft bei der Zusammenstellung komplexer Pipelines.
  • Lässt sich in ML-Metadatenspeicher zur Nachverfolgbarkeit und Reproduzierbarkeit einbinden

Eine umfassende Einführung in Kubeflow Pipelines und ein Beispiel für TFX-Bibliotheken finden Sie im Blogpost Getting started with Kubeflow Pipelines.

Kubeflow Pipelines auslösen und planen

Wenn Sie eine Kubeflow-Pipeline in der Produktion bereitstellen, müssen Sie ihre Ausführungen entsprechend den im Abschnitt ML-Pipeline-Automatisierung beschriebenen Szenarien automatisieren.

Kubeflow Pipelines bietet ein Python SDK für den programmatischen Betrieb der Pipeline. Die Klasse kfp.Client enthält APIs zum Erstellen von Tests sowie zum Bereitstellen und Ausführen von Pipelines. Mit dem Kubeflow Pipelines SDK können Sie Kubeflow Pipelines mit den folgenden Diensten aufrufen:

Kubeflow Pipelines bietet auch einen integrierten Planer für wiederkehrende Pipelines in Kubeflow Pipelines.

CI/CD für ML in Google Cloud einrichten

Kubeflow Pipelines ermöglicht die Orchestrierung von ML-Systemen, die mehrere Schritte umfassen, einschließlich Datenvorverarbeitung, Modelltraining und -bewertung sowie Modellbereitstellung. In der Data Science-Testphase können Sie mit Kubeflow Pipelines schnell das gesamte System testen. In der Produktionsphase können Sie mit Kubeflow Pipelines die Pipelineausführung anhand neuer Daten automatisieren, um das ML-Modell zu trainieren oder neu zu trainieren.

CI/CD-Architektur

Das folgende Diagramm zeigt eine allgemeine Übersicht über CI/CD für ML mit Kubeflow Pipelines.

Architektur von CI/CD für ML-Pipeline mit Kubeflow Pipelines

Abbildung 6: Allgemeine Übersicht über CI/CD für Kubeflow Pipelines

Der Kern dieser Architektur ist Cloud Build, ein verwalteter Dienst, der Ihre Builds in der Google Cloud-Infrastruktur ausführt. Cloud Build kann Quellen aus Cloud Source Repositories, GitHub oder Bitbucket importieren und dann einen Build gemäß Ihren Spezifikationen ausführen und Artefakte wie erstelle Docker-Container oder Python-TAR-Dateien erzeugen.

Cloud Build führt Ihren Build als eine Reihe von Build-Schritten aus, die in einer Build-Konfigurationsdatei (cloulbuild.yaml) definiert sind. Jeder Build-Schritt wird in einem Docker-Container ausgeführt. Sie können entweder die von Cloud Build bereitgestellten unterstützten Build-Schritte verwenden oder eigene Build-Schritte schreiben.

Der Cloud Build-Prozess, der das erforderliche CI/CD für Ihr ML-System ausführt, kann entweder manuell oder über automatisierte Build-Trigger ausgeführt werden. Trigger führen Ihre konfigurierten Build-Schritte aus, wenn Änderungen an die Build-Quelle weitergeleitet werden. Sie können einen Build-Trigger festlegen, um die Build-Routine bei Änderungen am Quell-Repository oder nur dann auszuführen, wenn Änderungen bestimmten Kriterien entsprechen.

Darüber hinaus können Sie Build-Routinen (Cloud Build-Konfigurationsdateien) haben, die als Reaktion auf verschiedene Trigger ausgeführt werden. Sie können beispielsweise folgenden Konfigurationen haben:

  • Eine Build-Routine beginnt, wenn Commits für einen Entwicklungszweig vorgenommen werden.
  • Eine Build-Routine beginnt, wenn Commits für den Master-Zweig vorgenommen werden.

Sie können Substitutionen für Konfigurationsvariablen verwenden, um die Umgebungsvariablen beim Build zu definieren. Diese Substitutionen werden aus ausgelösten Builds übernommen. Zu diesen Variablen gehören $COMMIT_SHA, $REPO_NAME, $BRANCE_NAME, $TAG_NAME und $REVISION_ID. Andere nicht triggerbasierte Variablen sind $PROJECT_ID und $BUILD_ID. Substitutionen sind für Variablen geeignet, deren Wert bis zur Erstellung des Builds nicht bekannt ist. Mit Substitutionen können Sie auch eine vorhandene Build-Anfrage mit anderen Variablenwerten wiederverwenden.

Anwendungsfall eines CI/CD-Workflows

Ein Quellcode-Repository enthält normalerweise die folgenden Elemente:

  • Den Python-Quellcode für die Implementierung der Komponenten von Kubeflow Pipelines, einschließlich Datenvalidierung, Datentransformation, Modelltraining, Modellbewertung und Modellbereitstellung.
  • Python-Einheitentests zum Testen der in der Komponente implementierten Methoden.
  • Dockerfiles, die zum Erstellen von Docker-Container-Images erforderlich sind (eines für jede Kubeflow Pipelines-Komponente).
  • Die Datei component.yaml, die die Komponentenspezifikationen der Pipeline definiert. Diese Spezifikationen werden verwendet, um die Komponentenvorgänge in der Pipeline-Definition zu erzeugen.
  • Ein Python-Modul (z. B. das Modul pipeline.py), in dem der Kubeflow Pipelines-Workflow definiert ist.
  • Andere Skripts und Konfigurationsdateien, einschließlich der cloudbuild.yaml-Dateien.
  • Notebooks für explorative Datenanalysen, Modellanalysen und interaktive Tests von Modellen.
  • Eine Einstellungsdatei (z. B. die Datei settings.yaml), einschließlich Konfigurationen der Pipeline-Eingabeparameter.

Im folgenden Beispiel wird eine Build-Routine ausgelöst, wenn ein Entwickler Quellcode aus seiner Data-Science-Umgebung an den Entwicklungszweig weiterleitet.

Beispiel für Build-Schritte

Abbildung 7. Beispiele für Build-Schritte, die von Cloud Build ausgeführt werden

Wie in Abbildung 7 gezeigt, führt Cloud Build die folgenden Build-Schritte aus:

  1. Das Quellcode-Repository wird in die Cloud Build-Laufzeitumgebung im Directory /workspace kopiert.
  2. Einheitentests werden ausgeführt.
  3. (Optional) Eine statische Codeanalyse wie Pylint wird ausgeführt.
  4. Wenn die Tests erfolgreich sind, werden die Docker-Container-Images erstellt, eines für jede Kubeflow Pipelines-Komponente. Die Images sind mit dem Parameter $COMMIT_SHA getagged.
  5. Die Docker-Container-Images werden in Container Registry hochgeladen.
  6. Die Image-URL wird in jeder component.yaml-Datei mit den erstellten und getaggten Docker-Container-Images aktualisiert.
  7. Der Kubeflow Pipelines-Workflow wird kompiliert, um die Datei workflow.tar.gz zu erstellen.
  8. Die Datei workflow.tar.gz wird in Cloud Storage hochgeladen.
  9. Die kompilierte Pipeline wird in Kubeflow Pipelines bereitgestellt. Dazu sind folgende Schritte erforderlich:
    1. Pipelineparameter aus der Datei settings.yaml lesen.
    2. Einen Test erstellen oder einen vorhandenen Test verwenden.
    3. Die Pipeline in Kubeflow Pipelines bereitstellen und ihren Namen mit einer Version taggen.
  10. Optional: Die Pipeline mit den Parameterwerten als Teil eines Integrationstests oder einer Produktionsausführung ausführen. Die ausgeführte Pipeline stellt schließlich ein Modell als API in AI Platform bereit.

Ein umfassendes Cloud Build-Beispiel, das die meisten dieser Schritte abdeckt, finden Sie unter A Simple CI/CD Example with Kubeflow Pipelines and Cloud Build.

Weitere Überlegungen

Beachten Sie beim Einrichten der ML-CI/CD-Architektur in Google Cloud Folgendes:

  • Für die Data-Science-Umgebung können Sie einen lokalen Computer oder eine AI Platform Notebooks-Instanz verwenden, die auf einer Deep Learning VM (DLVM) basiert.
  • Sie können die automatisierte Cloud Build-Pipeline so konfigurieren, dass Trigger übersprungen werden, z. B. wenn nur Dokumentationsdateien bearbeitet oder die Testnotebooks geändert werden.
  • Sie können die Pipeline für Integrations- und Regressionstests als Build-Test ausführen. Bevor die Pipeline in der Zielumgebung bereitgestellt wird, können Sie mit der Methode wait_for_pipeline_completion die Pipeline in einem Beispiel-Dataset ausführen, um die Pipeline zu testen.
  • Als Alternative zu Cloud Build können Sie auch andere Build-Systeme wie Jenkins verwenden. Eine einsatzbereite Bereitstellung von Jenkins steht im Google Cloud Marketplace zur Verfügung.
  • Sie können die Pipeline so konfigurieren, dass sie anhand verschiedener Trigger automatisch in verschiedenen Umgebungen bereitgestellt wird, einschließlich Entwicklung, Tests und Staging. Darüber hinaus können Sie die Bereitstellung in bestimmten Umgebungen manuell vornehmen, z. B. in der Vorproduktion oder in der Produktion, in der Regel nach Erhalt einer Releasegenehmigung. Sie können mehrere Build-Routinen für verschiedene Trigger oder für unterschiedliche Zielumgebungen haben.
  • Sie können Apache Airflow, ein beliebtes Orchestrierungs- und Planungs-Framework, für allgemeine Workflows verwenden, das Sie mit dem vollständig verwalteten Cloud Composer-Dienst ausführen können. Weitere Informationen zum Orchestrieren von Datenpipelines mit Cloud Composer und Cloud Build finden Sie unter CI/CD-Pipeline für Ihren Datenverarbeitungsworkflow einrichten.
  • Wenn Sie eine neue Version des Modells für die Produktion bereitstellen, stellen Sie sie als Canary-Release bereit, um eine Vorstellung von ihrer Leistung zu erhalten (CPU-, Arbeitsspeicher- und Laufwerksnutzung). Bevor Sie das neue Modell für die Bereitstellung des gesamten Live-Traffics konfigurieren, können Sie auch A/B-Tests ausführen. Konfigurieren Sie das neue Modell so, dass 10 % bis 20 % des Live-Traffics bereitgestellt werden. Wenn das neue Modell eine bessere Leistung als das aktuelle Modell erzielt, können Sie es so konfigurieren, dass der gesamte Traffic verarbeitet wird. Andernfalls wird vom Serving-System ein Rollback zum aktuellen Modell durchgeführt.

Nächste Schritte