Architektur der Cloud Composer-Umgebung

Cloud Composer 1 | Cloud Composer 2

Auf dieser Seite wird die Architektur von Cloud Composer 2-Umgebungen beschrieben.

Konfigurationen der Umgebungsarchitektur

Cloud Composer 2-Umgebungen können die folgenden Architekturkonfigurationen haben:

Jede Konfiguration verändert die Architektur der Umgebungsressourcen geringfügig.

Kunden- und Mandantenprojekte

Wenn Sie eine Umgebung erstellen, verteilt Cloud Composer die Ressourcen der Umgebung auf einen Mandanten und ein Kundenprojekt.

Das Kundenprojekt ist ein Google Cloud-Projekt, in dem Sie Ihre Umgebungen erstellen. Sie können in einem Kundenprojekt mehrere Umgebungen erstellen.

Mandantenprojekt ist ein von Google verwaltetes Mandantenprojekt. Das Mandantenprojekt bietet eine einheitliche Zugriffssteuerung und eine zusätzliche Datensicherheit für Ihre Umgebung. Jede Cloud Composer-Umgebung hat ein eigenes Mandantenprojekt.

Umgebungskomponenten

Eine Cloud Composer-Umgebung besteht aus Umgebungskomponenten.

Eine Umgebungskomponente ist ein Element einer verwalteten Airflow-Infrastruktur, die in Google Cloud als Teil Ihrer Umgebung ausgeführt wird.

Umgebungskomponenten werden entweder im Mandanten oder im Kundenprojekt Ihrer Umgebung ausgeführt.

Einige Komponenten Ihrer Umgebung basieren auf eigenständigen Google Cloud-Produkten. Für diese Produkte gelten außerdem Kontingente und Limits für diese Umgebungen. Beispielsweise verwenden Cloud Composer-Umgebungen VPC-Peering. Für Ihr Kundenprojekt gelten Kontingente für die maximale Anzahl von VPC-Peering. Wenn Ihr Projekt diese maximale Anzahl an Peerings erreicht hat, können Sie keine weiteren Umgebungen erstellen.

Cluster der Umgebung

Der Cluster der Umgebung ist ein VPC-nativer Google Kubernetes Engine-Cluster im Autopilot-Modus Ihrer Umgebung:

  • Umgebungsknoten sind VMs im Cluster der Umgebung.

  • Pods im Cluster der Umgebung führen Container mit anderen Umgebungskomponenten wie Airflow-Workern und Planern aus. Pods werden auf Umgebungsknoten ausgeführt.

  • Arbeitslastressourcen des Clusters Ihrer Umgebung verwalten Pod-Gruppen im Cluster Ihrer Umgebung. Viele Komponenten Ihrer Umgebung sind als unterschiedliche Arten von Arbeitslastressourcen implementiert. Airflow-Worker werden beispielsweise als Deployments ausgeführt. Zusätzlich zu Deployments hat Ihre Umgebung auch StatefulSets, DaemonSets und Arbeitslasttypen.

Cloud Composer aktiviert standardmäßig automatische Knotenupgrades und automatische Knotenreparaturen, um den Cluster Ihrer Umgebung vor Sicherheitslücken zu schützen. Diese Vorgänge finden innerhalb von Wartungsfenstern statt, die Sie für Ihre Umgebung angeben.

Airflow-Planer, Worker und Redis-Warteschlange

Airflow-Planer steuern die Planung der DAG-Ausführungen und einzelner Aufgaben von DAGs. Planer verteilen Aufgaben an Airflow-Worker mithilfe einer Redis-Warteschlange, die als Anwendung im Cluster der Umgebung ausgeführt wird. Airflow-Planer werden als Deployments im Cluster Ihrer Umgebung ausgeführt.

Airflow-Worker führen einzelne Aufgaben aus DAGs aus der Redis-Warteschlange aus. Airflow-Worker werden als Deployments im Cluster Ihrer Umgebung ausgeführt.

Redis-Warteschlange enthält eine Warteschlange mit einzelnen Aufgaben Ihrer DAGs. Die Warteschlange wird von Airflow-Planern gefüllt. Airflow-Worker übernehmen ihre Aufgaben daraus. Die Redis-Warteschlange wird im Cluster Ihrer Umgebung als StatefulSet-Anwendung ausgeführt, sodass Nachrichten nach Neustarts von Containern beibehalten werden.

Airflow-Webserver

Auf dem Airflow-Webserver wird die Aiflow-UI Ihrer Umgebung ausgeführt.

In Cloud Composer 2 wird der Airflow-Webserver als Deployment im Cluster Ihrer Umgebung ausgeführt.

Identity-Aware Proxy wird nicht für den Zugriff in Cloud Composer 2 verwendet.

Airflow-Datenbank

Die Airflow-Datenbank ist eine Cloud SQL-Instanz, die im Mandantenprojekt Ihrer Umgebung ausgeführt wird. Sie hostet die Airflow-Metadatendatenbank.

Zum Schutz vertraulicher Verbindungs- und Workflowinformationen erlaubt Cloud Composer nur Datenbankzugriff auf das Dienstkonto Ihrer Umgebung.

Bucket der Umgebung

Der Bucket der Umgebung ist ein Cloud Storage-Bucket, in dem DAGs, Plug-ins, Datenabhängigkeiten und Airflow-Logs gespeichert werden. Der Bucket der Umgebung befindet sich im Kundenprojekt.

Wenn Sie die DAG-Dateien in den Ordner /dags im Bucket Ihrer Umgebung hochladen, synchronisiert Cloud Composer die DAGs mit Workern, Planern und dem Webserver Ihrer Umgebung. Sie können Ihre Workflow-Artefakte in den Ordnern data/ und logs/ speichern, ohne sich über Größenbeschränkungen Gedanken machen zu müssen. Sie haben die vollständige Zugriffssteuerung für Ihre Daten.

Andere Komponenten der Umgebung

Eine Cloud Composer-Umgebung hat mehrere zusätzliche Umgebungskomponenten:

  • Cloud SQL Storage: Speichert die Sicherungen der Airflow-Datenbank. Cloud Composer sichert die Airflow-Metadaten täglich, um potenziellen Datenverlust zu minimieren.

    Cloud SQL Storage wird im Mandantenprojekt der Umgebung ausgeführt. Sie können nicht auf die Inhalte von Cloud SQL Storage zugreifen.

  • Cloud SQL-Proxy: Verbindet andere Komponenten Ihrer Umgebung mit der Airflow-Datenbank.

    Ihre Umgebung kann eine oder mehrere Cloud SQL-Proxy-Instanzen haben, die je nach Umgebungsarchitektur unterschiedliche Rollen haben.

    Ein Cloud SQL-Proxy wird als Deployment im Cluster der Umgebung oder in einer App Engine Flex-Instanz im Mandantenprojekt ausgeführt aus.

    Bei der Bereitstellung im Cluster Ihrer Umgebung autorisiert Cloud SQL Proxy auch den Zugriff auf Ihre Cloud SQL-Instanz über eine Anwendung, einen Client oder einen anderen Google Cloud-Dienst.

  • HAProxy. Load-Balancing für den Traffic zur Cloud SQL-Instanz zwischen zwei Cloud SQL-Proxy-Instanzen, die im Mandantenprojekt ausgeführt werden. Diese Komponente wird in Architekturen privater IP-Umgebungen verwendet und als Container in der Bereitstellung von Cloud SQL Proxy ausgeführt.

  • Airflow-Monitoring: Meldet Umgebungsmesswerte an Cloud Monitoring und löst den DAG airflow_monitoring aus. Der DAG airflow_monitoring meldet die Daten zum Umgebungsstatus, die später gesichert werden, z. B. im Monitoring-Dashboard der Umgebung. Airflow-Monitoring wird als Deployment im Cluster der Umgebung ausgeführt.

  • Der Composer-Agent führt Umgebungsvorgänge aus, z. B. das Erstellen, Aktualisieren, Aktualisieren und Löschen von Umgebungen. Im Allgemeinen ist diese Komponente für die Einführung von Änderungen in Ihrer Umgebung verantwortlich. Wird als Job im Cluster der Umgebung ausgeführt.

  • Airflow InitDB erstellt eine Cloud SQL-Instanz und ein anfängliches Datenbankschema. Airflow InitDB wird als Job im Cluster der Umgebung ausgeführt.

  • FluentD. Erfasst Logs aus allen Umgebungskomponenten und lädt die Logs in Cloud Logging hoch. Wird als DaemonSet im Cluster der Umgebung ausgeführt.

  • Pub/Sub-Abos: Ihre Umgebung kommuniziert mit ihrem GKE-Dienst-Agent über Pub/Sub-Abos. Es verwaltet die Nachrichten über das Standardverhalten von Pub/Sub. Löschen Sie keine .*-composer-.*-Pub/Sub-Themen. Pub/Sub unterstützt maximal 10.000 Themen pro Projekt.

Architektur einer öffentlichen IP-Umgebung

Öffentliche IP-Umgebung in Cloud Composer-Ressourcen im Mandantenprojekt und im Kundenprojekt
Abbildung 1. Architektur der öffentlichen IP-Umgebung (zum Vergrößern klicken)

In einer Architektur für eine öffentliche IP-Umgebung für Cloud Composer 2:

  • Im Mandantenprojekt werden eine Cloud SQL-Instanz und ein Cloud SQL-Speicher gehostet.
  • Im Kundenprojekt werden alle anderen Komponenten der Umgebung gehostet.
  • Airflow-Planer und -Worker im Kundenprojekt kommunizieren über eine Cloud SQL-Proxy-Instanz im Kundenprojekt mit der Airflow-Datenbank.

Private IP-Adresse

Private IP-Umgebung in Cloud Composer-Ressourcen im Mandantenprojekt und im Kundenprojekt
Abbildung 2. Architektur der privaten IP-Umgebung (zum Vergrößern klicken)

In einer Architektur für private IP-Umgebungen für Cloud Composer 2:

  • Im Mandantenprojekt werden eine Cloud SQL-Instanz und ein Cloud SQL-Speicher gehostet.
  • Im Kundenprojekt werden alle anderen Komponenten der Umgebung gehostet.
  • Airflow-Planer und -Worker stellen über den HAProxy-Prozess im Cluster der Umgebung eine Verbindung zur Airflow-Datenbank her.
  • Der HAProxy-Prozess verteilt den Traffic auf die Cloud SQL-Instanz zwischen zwei Cloud SQL-Proxyinstanzen, die sich im Mandantenprojekt befinden. Private IP-Umgebungen verwenden zwei Cloud SQL-Proxy-Instanzen, da das Kundenprojekt aufgrund von Netzwerkbeschränkungen nicht direkt auf die Datenbank zugreift. Es sind zwei Instanzen erforderlich, damit Komponenten Ihrer Umgebung jederzeit auf die Datenbank zugreifen können.

Einbindung in Cloud Logging und Cloud Monitoring

Cloud Composer kann in Cloud Logging und Cloud Monitoring Ihres Google Cloud-Projekts eingebunden werden , sodass Sie an einem zentralen Ort die Airflow-Dienst- und Workflow-Logs ansehen können.

Cloud Monitoring erfasst und nimmt Messwerte, Ereignisse und Metadaten aus Cloud Composer auf, um Statistiken durch Dashboards und Diagramme zu generieren.

Da Streaming von Cloud Logging genutzt wird, können Sie sich die Logs ansehen, die der Airflow-Planer und die Worker sofort ausgeben, anstatt darauf zu warten, dass Airflow-Logs im Cloud Storage-Bucket Ihrer Umgebung angezeigt werden. Da die Cloud Logging-Logs für Cloud Composer auf google-fluentd basieren, haben Sie Zugriff auf alle Logs, die von Airflow-Planern und -Workern erstellt werden.

Wenn Sie die Anzahl der Logs in Ihrem Google Cloud-Projekt begrenzen möchten, beenden Sie die gesamte Logaufnahme. Deaktivieren Sie Logging nicht.

Nächste Schritte