Umgebungsarchitektur

Managed Airflow (Gen 3) | Managed Airflow (Gen 2) | Managed Airflow (Legacy Gen 1)

Auf dieser Seite wird die Architektur von Managed Airflow-Umgebungen beschrieben.

Konfigurationen der Umgebungsarchitektur

Managed Airflow (Legacy Gen 1)-Umgebungen können die folgenden Architekturkonfigurationen haben:

Kunden- und Mandantenprojekte

Beim Erstellen einer Umgebung werden die Umgebungsressourcen von Managed Airflow auf ein Mandanten- und ein Kundenprojekt verteilt:

  • 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 und gehört zur Organisation „Google.com“. Das Mandantenprojekt bietet eine einheitliche Zugriffssteuerung und eine zusätzliche Datensicherheitsebene für Ihre Umgebung. Jede Managed Airflow-Umgebung hat ein eigenes Mandantenprojekt.

Umgebungskomponenten

Eine Managed Airflow-Umgebung besteht aus Umgebungskomponenten.

Eine Umgebungskomponente ist ein Element einer verwalteten Airflow-Infrastruktur die in Google Cloud ausgeführt wird Google Cloud, als Teil Ihrer Umgebung. Umgebungskomponenten werden entweder im Mandanten- oder im Kundenprojekt Ihrer Umgebung ausgeführt.

Cluster der Umgebung

Der Cluster der Umgebung ist ein Standard-Modus- VPC-nativer oder routenbasierter Google Kubernetes Engine-Cluster Ihrer Umgebung:

Standardmäßig aktiviert Managed Airflow automatische Knotenupgrades und automatische Knotenreparaturen, um den Cluster Ihrer Umgebung vor Sicherheitslücken zu schützen. Diese Vorgänge erfolgen während Wartungsfenstern, die Sie für Ihre Umgebung angeben.

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 Ihre DAG-Dateien in den Ordner in Ihrem Bucket hochladen, synchronisiert Managed Airflow die DAGs mit den Airflow-Komponenten Ihrer Umgebung./dags

Airflow-Webserver

Der Airflow-Webserver führt die Airflow-UI Ihrer Umgebung aus.

In Managed Airflow (Legacy Gen 1) wird der Airflow-Webserver im Mandantenprojekt Ihrer Umgebung ausgeführt.

Der Airflow-Webserver ist in Identity-Aware Proxy (IAP) eingebunden. Managed Airflow blendet die Details der IAP-Einbindung aus und bietet Zugriff auf den Webserver basierend auf Nutzeridentitäten und IAM-Richtlinienbindungen, die für Nutzer definiert wurden.

In Managed Airflow (Legacy Gen 1) wird der Airflow-Webserver mit einem anderen Dienstkonto als Airflow-Worker und Airflow-Planer ausgeführt. Das Dienstkonto für den Webserver wird beim Erstellen der Umgebung automatisch generiert und von der Webserverdomain abgeleitet. Lautet die Domain beispielsweise example.appspot.com, hat das Dienstkonto die Bezeichnung example@appspot.gserviceaccount.com.

Airflow-Datenbank

Eine 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, Managed Airflow lässt den Datenbankzugriff nur auf das Dienstkonto Ihrer Umgebung zu.

Andere Airflow-Komponenten

Weitere Airflow-Komponenten, die in Ihrer Umgebung ausgeführt werden:

  • Airflow-Planer parsen DAG-Dateien, planen DAG-Ausführungen anhand des Zeitplanintervalls und stellen Aufgaben zur Ausführung durch Airflow-Worker in die Warteschlange. In Managed Airflow (Legacy Gen 1) werden Airflow-DAG-Prozessoren als Teil von Planerkomponenten ausgeführt.

  • Airflow-Worker führen Aufgaben aus, die von Airflow-Planern geplant werden.

Architektur der öffentlichen IP-Umgebung

Ressourcen der öffentlichen IP-Managed Airflow-Umgebung im Mandantenprojekt und im Kundenprojekt
Abbildung 1. Architektur einer öffentlichen IP-Umgebung (zum Vergrößern klicken)

In einer öffentlichen IP-Umgebungsarchitektur für Managed Airflow (Legacy Gen 1):

  • Das Mandantenprojekt hostet eine Cloud SQL-Instanz, Cloud SQL Storage und eine App Engine Flex-Instanz, auf der der Airflow-Webserver ausgeführt wird.
  • Das Kundenprojekt hostet alle anderen Komponenten der Umgebung.
  • Airflow-Planer und -Worker im Kundenprojekt kommunizieren über eine Cloud SQL-Proxy-Instanz im Kundenprojekt mit der Airflow-Datenbank.
  • Der Airflow-Webserver im Mandantenprojekt kommuniziert mit der Airflow-Datenbank über eine Cloud SQL-Proxyinstanz im Mandantenprojekt.

Architektur einer privaten IP-Umgebung

Ressourcen der privaten IP-Managed Airflow-Umgebung im Mandantenprojekt und im Kundenprojekt
Abbildung 2. Architektur einer privaten IP-Umgebung (zum Vergrößern klicken)

In einer Architektur für private IP-Umgebungen:

  • Das Mandantenprojekt hostet eine Cloud SQL-Instanz, Cloud SQL Storage und zwei App Engine-Instanzen, auf denen der Airflow-Webserver ausgeführt wird.
  • Das Kundenprojekt hostet alle anderen Komponenten der Umgebung.
  • 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 durch Load-Balancing auf die Cloud SQL-Instanz zwischen zwei Cloud SQL-Proxy-Instanzen, die sich im Mandantenprojekt befinden. Private IP-Umgebungen verwenden zwei Cloud SQL-Proxy-Instanzen, da das Kundenprojekt aufgrund von Netzwerkeinschränkungen nicht direkt auf die Datenbank zugreift. Es sind zwei Instanzen erforderlich, damit die Komponenten Ihrer Umgebung jederzeit auf die Datenbank zugreifen können.

Private IP mit DRS

Ressourcen der Managed Airflow-Umgebung mit privater IP-Adresse und DRS im Mandantenprojekt und im Kundenprojekt (zum Vergrößern klicken)
Abbildung 3. Architektur einer privaten IP-Umgebung (zum Vergrößern klicken)

Wenn die Organisationsrichtlinie für die Domaineingeschränkte Freigabe (DRS) in Ihrem Projekt aktiviert ist, verwendet Managed Airflow die private IP-Adresse mit der DRS-Umgebungsarchitektur.

In der privaten IP-Umgebungsarchitektur mit DRS:

  • Das Mandantenprojekt hostet eine Cloud SQL-Instanz, Cloud SQL Storage und zwei App Engine-Instanzen, auf denen der Airflow-Webserver ausgeführt wird.

  • Das Mandantenprojekt hostet einen zusätzlichen Bucket der Umgebung. Der Airflow-Webserver greift direkt auf diesen Bucket zu.

  • Das Kundenprojekt hostet alle anderen Komponenten der Umgebung.

  • Das Kundenprojekt hostet den Bucket-Synchronisierungsprozess im Cluster der Umgebung. Dieser Prozess synchronisiert zwei Umgebungsbuckets.

  • 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 durch Load-Balancing auf die Cloud SQL-Instanz zwischen zwei Cloud SQL-Proxy-Instanzen, die sich im Mandantenprojekt befinden. Private IP-Umgebungen verwenden zwei Cloud SQL-Proxy-Instanzen, da das Kundenprojekt aufgrund von Netzwerkeinschränkungen nicht direkt auf die Datenbank zugreift. Es sind zwei Instanzen erforderlich, damit die Komponenten Ihrer Umgebung jederzeit auf die Datenbank zugreifen können.

Einbindung in Cloud Logging und Cloud Monitoring

Managed Airflow kann in Cloud Logging und Cloud Monitoring Ihres Google Cloud Projekts eingebunden werden, sodass Sie eine zentrale Stelle für die Anzeige von Airflow- und DAG-Logshaben.

Cloud Monitoring sammelt und erfasst Messwerte, Ereignisse und Metadaten aus Managed Airflow, mit denen sich mithilfe von Dashboards und Diagrammen aussagekräftige Informationen generieren lassen .

Aufgrund des Streaming-Charakters von Cloud Logging können Sie alle Logs, die von Airflow-Komponenten gesendet werden, sofort aufrufen. Sie müssen also nicht warten, bis Airflow-Logs im Cloud Storage-Bucket Ihrer Umgebung angezeigt werden.

Wenn Sie die Anzahl der Logs in Ihrem Google Cloud Projekt begrenzen möchten, können Sie die Aufnahme aller Logs beenden. Deaktivieren Sie das Logging aber nicht.

Nächste Schritte