Architektur für MLOps mit TensorFlow Extended, Vertex AI Pipelines und Cloud Build

Last reviewed 2024-06-28 UTC

In diesem Dokument wird die Gesamtarchitektur eines ML-Systems (maschinelles Lernen) mit Bibliotheken von TensorFlow Extended (TFX) beschrieben. Außerdem wird erläutert, wie Sie mit Cloud Build und Vertex AI 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 Vertex AI 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 Vertex AI 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 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 trainiert eine erfolgreiche CT-Pipeline ein neues Modell und stellt es als Vorhersagedienst bereit.

TFX-basiertes ML-System entwerfen

In den folgenden Abschnitten wird erläutert, wie Sie ein integriertes ML-System mit TensorFlow Extended (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 betten den Transformationsprozess nach dem Training in das exportierte gespeicherte Modell ein.
  4. Modelltraining und -abstimmung: Verwenden Sie zum Implementieren und Trainieren des ML-Modells die API tf.Keras mit den transformierten Daten, die im vorherigen Schritt erstellt wurden. Sie können den Parameter Keras-Tuner, eine Hyperparameter-Abstimmungsbibliothek für Keras, verwenden, um die Parametereinstellungen auszuwählen, die zum besten Modell führen. Alternativ können Sie andere Dienste wie Katib, Vertex AI Vizier oder den Hyperparameter-Tuner von Vertex AI 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.

Ein Beispiel für die Verwendung der TFX-Bibliotheken finden Sie in der offiziellen TFX Keras-Komponentenanleitung.

TFX-ML-System in Google Cloud

In einer Produktionsumgebung müssen die Komponenten des Systems auf einer zuverlässigen Plattform in großem Maßstab 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 Vertex AI Training
Modellbewertung und -validierung TensorFlow Model Analysis Dataflow
Modellbereitstellung für Vorhersagen TensorFlow bereitstellen Vertex-AI-Prediction
Modellspeicherung – Vertex AI Model Registry
  • 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
  • Vertex AI Training ist ein verwalteter Dienst zum Trainieren von ML-Modellen in großem Maßstab. Sie können Modelltrainingsjobs mit vordefinierten Containern für TensorFlow, scikit-learn, XGBoost und PyTorch ausführen. Sie können jedes Framework auch mit Ihren eigenen benutzerdefinierten Containern ausführen. Für Ihre Trainingsinfrastruktur können Sie Beschleuniger und mehrere Knoten für verteiltes Training verwenden. Außerdem ist ein skalierbarer Bayesscher optimierungsbasierter Dienst für eine Hyperparameterabstimmung verfügbar.
  • Vertex AI Prediction ist ein verwalteter Dienst, der Batchvorhersagen ausführen soll, wobei Ihre trainierten Modelle und Onlinevorhersagen verwendet werden, indem die Modelle als Mikrodienst mit einer REST API bereitgestellt werden. Der Dienst kann auch in Vertex Explainable AI und Vertex AI Model Monitoring eingebunden werden, um Ihre Modelle zu verstehen und Benachrichtigungen zu erhalten, wenn es eine Abweichung und Drift eines Features oder einer Featureattribution gibt.
  • Mit Vertex AI Model Registry können Sie den Lebenszyklus Ihrer ML-Modelle verwalten. Sie können Ihre importierten Modelle versionieren und sich die zugehörigen Leistungsmesswerte ansehen. Ein Modell kann dann für Batchvorhersagen verwendet oder für die Onlinebereitstellung mit Vertex AI Prediction bereitgestellt werden.

ML-System mit Vertex AI 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. Schritte können auch parallel ausgeführt werden, um Zeit zu sparen, z. B. das Validieren der Bereitstellungsinfrastruktur und das Bewerten des Modells. 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 hilft die Orchestrierung dabei, die Ausführung der ML-Pipeline anhand eines Zeitplans oder bestimmter Auslösebedingungen zu automatisieren.

ML mit Vertex AI Pipelines

Vertex AI Pipelines ist ein von Google Cloud verwalteter Dienst, mit dem Sie ML-Pipelines orchestrieren und automatisieren können, bei denen jede Komponente der Pipeline containerisiert in Google Cloud oder auf anderen Cloud-Plattformen ausgeführt werden kann. Generierte Pipeline-Parameter und -Artefakte werden automatisch in Vertex ML Metadata gespeichert, was die Verfolgung von Herkunft und Ausführung ermöglicht. Der Vertex AI Pipelines-Dienst besteht aus Folgendem:

  • Einer Benutzeroberfläche zum Verwalten und Verfolgen von Tests, Jobs und Ausführungen.
  • Einem Modul zum Planen von mehrstufigen ML-Workflows.
  • Einem Python SDK zum Definieren und Bearbeiten von Pipelines und Komponenten.
  • Einbindung in Vertex ML Metadata, um Informationen zu Ausführungen, Modellen, Datasets und anderen Artefakten zu speichern.

Folgendes ist eine Pipeline, die in Vertex AI Pipelines ausgeführt wird:

  • Eine Reihe von containerisierten ML-Aufgaben oder Komponenten. Eine Pipeline-Komponente ist eigenständiger Code, der in ein Docker-Image gepackt wird. Eine Komponente führt einen Schritt in der Pipeline aus. Sie nimmt Eingabeargumente an und erzeugt Artefakte.
  • 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 ein Beispiel für Vertex AI Pipelines.

Grafik der ML-Pipeline unter Verwendung von Vertex AI Pipelines.

Abbildung 4. Beispielgrafik von Vertex AI Pipelines.

Kubeflow Pipelines SDK

Mit dem Kubeflow Pipelines SDK können Sie Komponenten erstellen, ihre Orchestrierung definieren und die Komponenten als Pipeline ausführen. Weitere Informationen zu Kubeflow Pipelines-Komponenten finden Sie in der Kubeflow-Dokumentation unter Komponenten erstellen.

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 in die Metadaten hat. Sie können Ihre TFX-Pipelines mit tfx.orchestration.experimental.KubeflowV2DagRunner in einer Vertex AI Pipelines-kompatiblen YAML-Datei kompilieren. Anschließend können Sie die Datei zur Ausführung an Vertex AI Pipelines senden.

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

Architektur von Vertex AI Pipelines in Google Cloud.

Abbildung 5. Vertex AI Pipelines, das von Google Cloud verwaltete Dienste aufruft.

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

Pipeline-Komponenten sind nicht auf die Ausführung von TFX-bezogenen 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.

Die Containerisierung von Aufgaben in Vertex AI 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 Vertex ML Metadata einbinden, um Pipeline-Ausführungen und -Artefakte nachverfolgbar und reproduzierbar zu machen.

Eine umfassende Einführung in Vertex AI Pipelines finden Sie in der Liste der verfügbaren Notebook-Beispiele.

Vertex AI Pipelines auslösen und planen

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

Mit dem Vertex AI SDK können Sie die Pipeline programmatisch betreiben. Die Klasse google.cloud.aiplatform.PipelineJob enthält APIs zum Erstellen von Tests sowie zum Bereitstellen und Ausführen von Pipelines. Mit dem SDK können Sie Vertex AI Pipelines daher von einem anderen Dienst aus aufrufen, um planer- oder ereignisbasierte Trigger zu erreichen.

Vertex AI Pipelines-Trigger.

Abbildung 6. Flussdiagramm mit mehreren Triggern für Vertex AI-Pipelines unter Verwendung von Pub/Sub und Cloud Run-Funktionen.

In Abbildung 6 sehen Sie ein Beispiel für das Auslösen des Vertex AI Pipelines-Dienstes zum Ausführen einer Pipeline. Die Pipeline wird mit dem Vertex AI SDK aus einer Cloud Run-Funktion ausgelöst. Die Cloud Run-Funktion selbst ist ein Abonnent von Pub/Sub und wird basierend auf neuen Nachrichten ausgelöst. Jeder Dienst, der die Ausführung der Pipeline auslösen möchte, kann im entsprechenden Pub/Sub-Thema veröffentlichen. Im obigen Beispiel gibt es drei Veröffentlichungsdienste:

  • Cloud Scheduler veröffentlicht Nachrichten nach einem Zeitplan und löst daher die Pipeline aus.
  • Cloud Composer veröffentlicht Nachrichten als Teil eines größeren Workflows, z. B. im Rahmen eines Datenaufnahme-Workflows, der die Trainingspipeline auslöst, nachdem neue Daten in BigQuery aufgenommen wurden.
  • Cloud Logging veröffentlicht eine Nachricht basierend auf Logs, die Filterkriterien erfüllen. Sie können die Filter so einrichten, dass der Empfang neuer Daten oder sogar Abweichungs- und Drift-Benachrichtigungen erkannt werden, die vom Vertex AI Model Monitoring-Dienst generiert wurden.

CI/CD für ML in Google Cloud einrichten

Vertex AI 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 helfen Vertex AI Pipelines beim schnellen Testen des gesamten Systems. In der Produktionsphase können Sie mit Vertex AI 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 Vertex AI Pipelines.

Architektur von CI/CD für ML-Pipeline mit Vertex AI Pipelines.

Abbildung 7: Allgemeine Übersicht über CI/CD mit Vertex AI Pipelines.

Der Kern dieser Architektur ist Cloud Build. Cloud Build kann Quellcode aus der Artifact Registry, GitHub oder Bitbucket importieren und dann einen Build gemäß Ihren Spezifikationen ausführen und Artefakte wie 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 (cloudbuild.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 Build-Routinen haben, die ausgelöst werden, wenn Commits für den Entwicklungszweig oder den Hauptzweig durchgeführt 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, $BRANCH_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 Quellcode des Python-Pipelines-Workflows, in dem der Pipeline-Workflow definiert ist
  • Den Quellcode der Python-Pipelinekomponenten und die entsprechenden Komponentenspezifikationsdateien für die verschiedenen Pipelinekomponenten wie Datenvalidierung, Datentransformation, Modelltraining, Modellbewertung und Modellbereitstellung.
  • Dockerfiles, die zum Erstellen von Docker-Container-Images erforderlich sind (eines für jede Pipelinekomponente).
  • Python-Unit- und -Integrationstests zum Testen der in der Komponente und der Gesamtpipeline implementierten Methoden.
  • Andere Skripts, einschließlich der Datei cloudbuild.yaml, Testtrigger und Pipelinebereitstellungen.
  • Konfigurationsdateien (z. B. die Datei settings.yaml), einschließlich Konfigurationen der Pipeline-Eingabeparameter.
  • Notebooks für explorative Datenanalysen, Modellanalysen und interaktive Tests von Modellen.

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 8. Beispiele für Build-Schritte, die von Cloud Build ausgeführt werden

Cloud Build führt in der Regel die folgenden Build-Schritte aus, die auch in Abbildung 7 dargestellt sind:

  1. Das Quellcode-Repository wird in die Cloud Build-Laufzeitumgebung im Directory /workspace kopiert.
  2. Unit- und Integrationstests ausführen.
  3. Optional: Führen Sie eine statische Codeanalyse mit einem Analysetool wie Pylint aus.
  4. Wenn die Tests erfolgreich sind, werden die Docker-Container-Images erstellt, und zwar eines für jede Pipeline-Komponente. Die Images sind mit dem Parameter $COMMIT_SHA getagged.
  5. Die Docker-Container-Images werden in Artifact Registry hochgeladen (siehe Abbildung 7).
  6. Die Image-URL wird in jeder component.yaml-Datei mit den erstellten und getaggten Docker-Container-Images aktualisiert.
  7. Der Pipeline-Workflow wird kompiliert, um die Datei pipeline.json zu erstellen.
  8. Die Datei pipeline.json wird in Artifact Registry hochgeladen.
  9. Optional: Die Pipeline mit den Parameterwerten als Teil eines Integrationstests oder einer Produktionsausführung ausführen. Die ausgeführte Pipeline generiert ein neues Modell und kann das Modell auch als API in Vertex AI Prediction bereitstellen.

Ein produktionsreifes End-to-End-MLOps-Beispiel mit CI/CD unter Verwendung von Cloud Build finden Sie in den End-to-End-Beispielen für Vertex Pipelines auf GitHub.

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 Vertex AI Workbench verwenden.
  • 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() auf den Abschluss der Ausführung der gesendeten Pipeline warten.
  • 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

Beitragende

Autoren:

Weiterer Mitwirkender: Wyatt Gorman | HPC Solutions Manager