Architektur der Cloud Composer-Umgebung

Beim Erstellen einer Umgebung werden die Umgebungsressourcen von Cloud Composer auf ein von Google verwaltetes Mandantenprojekt und Ihr Kundenprojekt verteilt.

Umgebungskonfigurationen

Cloud Composer-Umgebungen können in drei Konfigurationen erstellt werden: Öffentliche IP-Adresse, private IP-Adresse und private IP mit domaineingeschränkte Freigabe (DRS). Die Architektur von Projektressourcen ändert sich durch jede Konfiguration geringfügig.

Öffentliche IP-Adresse

In einer öffentlichen IP-Konfiguration werden Umgebungsressourcen zwischen Kunden- und Mandantenprojekten verteilt. Das Mandantenprojekt hostet eine Cloud SQL-Instanz, um die Airflow-Datenbank auszuführen, und eine Flex-VM in Google App Engine, um den Airflow-Webserver auszuführen.

Der Airflow-Planer, die Worker und der Webserver stellen mithilfe von Cloud SQL-Proxy-Prozessen eine Verbindung zur Airflow-Datenbank her, wie in der folgenden Abbildung dargestellt:

Öffentliche IP-Cloud Composer-Umgebungsressourcen im Mandantenprojekt und im Kundenprojekt (zum Vergrößern klicken)
Öffentliche IP-Adresse-Cloud Composer-Architektur (zum Vergrößern klicken)

Private IP-Adresse

In einer privaten IP-Konfiguration werden Cloud Composer-Ressourcen auf die Kunden- und Mandantenprojekte verteilt. Das Mandantenprojekt hostet eine Cloud SQL-Instanz, um die Airflow-Datenbank auszuführen, sowie eine Flex-VM in Google App Engine, um den Airflow-Webserver und den Cloud SQL-Proxyprozesse auszuführen.

Der Airflow-Planer und die Worker stellen eine Verbindung zu Cloud SQL-Proxyprozessen her, die im Mandantenprojekt ausgeführt werden. Dabei wird ein HAProxy-Prozess verwendet, der im GKE-Cluster ausgeführt wird. Der HAProxy-Prozess verteilt den Traffic durch Load-Balancing auf die Cloud SQL-Instanz zwischen zwei Cloud SQL-Proxy-Instanzen, die im Mandantenprojekt ausgeführt werden, wie in der folgenden Abbildung dargestellt:

Private IP-Cloud Composer-Umgebungsressourcen im Mandantenprojekt und im Kundenprojekt (zum Vergrößern klicken)
Private IP-Cloud Composer-Architektur (zum Vergrößern klicken)

Private IP mit Domaineingeschränkte Freigabe

Wenn die Organisationsrichtlinie für die domaineingeschränkte Freigabe aktiviert ist, erstellt Cloud Composer im Mandantenprojekt einen zusätzlichen Bucket, auf den der Webserver direkt zugreifen kann. Außerdem wird auf dem GKE-Cluster von Cloud Composer ein weiterer Prozess ausgeführt, um Daten aus dem Cloud Storage-Bucket im Kundenprojekt mit dem Cloud Storage-Bucket im Mandantenprojekt zu synchronisieren.

Ressourcen der Cloud Composer-DRS-Umgebung im Mandantenprojekt und im Kundenprojekt (zum Vergrößern klicken)
Cloud Composer-DRS-Architektur (zum Vergrößern klicken)

Ressourcen für Mandantenprojekte

Für eine einheitliche Zugriffssteuerung über Identity and Access Management und eine erhöhte Datensicherheit stellt Cloud Composer Cloud SQL und App Engine im Mandantenprojekt bereit.

Cloud SQL

Cloud SQL speichert die Airflow-Metadaten. Zum Schutz vertraulicher Verbindungs- und Workflowinformationen beschränkt Cloud Composer den Datenbankzugriff auf das Standardkonto oder auf das angegebene benutzerdefinierte Dienstkonto, mit dem die Umgebung erstellt wurde. Die Airflow-Metadaten werden von Cloud Composer täglich gesichert, um potenzielle Datenverluste zu minimieren.

Das zum Erstellen der Cloud Composer-Umgebung verwendete Dienstkonto ist das einzige Konto, das auf Ihre Daten in der SQL-Datenbank zugreifen kann. Für die Remote-Autorisierung des Zugriffs auf Ihre Cloud SQL-Datenbank über eine Anwendung, einen Client oder einen anderen Google Cloud-Dienst stellt Cloud Composer den Cloud SQL-Proxy im GKE-Cluster bereit.

App Engine

Der Airflow-Webserver wird in der flexiblen App Engine-Umgebung gehostet. Standardmäßig ist der Airflow-Webserver in Identity-Aware Proxy (IAP) eingebunden. Cloud Composer blendet die Details der IAP-Einbindung aus und ermöglicht die Verwendung der Cloud Composer IAM-Richtlinie zum Verwalten des Webserverzugriffs. Wenn nur dem Airflow-Webserver Zugriff gewährt werden soll, weisen Sie die Rolle composer.user oder verschiedene Cloud Composer-Rollen zu, die Zugriff auf andere Ressourcen in Ihrer Umgebung ermöglichen.

Ressourcen im Kundenprojekt

Cloud Composer stellt Cloud Storage, Google Kubernetes Engine, Cloud Logging und Cloud Monitoring in Ihrem Kundenprojekt bereit.

Cloud Storage

Cloud Storage bietet den Storage-Bucket für das Staging von DAGs, Plug-ins, Datenabhängigkeiten und Logs. Zur Bereitstellung von Workflows (DAGs) kopieren Sie die Dateien in den Bucket für Ihre Umgebung. Cloud Composer sorgt für die Synchronisierung der DAGs zwischen Workern, Planern und Webservern. Mit Cloud Storage können Sie Ihre Workflow-Artefakte in den Ordnern data/ und logs/ speichern, ohne Größenbeschränkungen berücksichtigen zu müssen. Sie haben damit die Möglichkeit, den Zugriff auf Ihre Daten uneingeschränkt zu steuern.

Google Kubernetes Engine

Cloud Composer stellt standardmäßig Kernkomponenten wie Airflow-Planer, Worker-Knoten und CeleryExecutor in einem GKE-Cluster bereit. Für zusätzliche Skalierbarkeit und Sicherheit unterstützt Cloud Composer auch VPC-native Cluster mit Alias-IP-Adressen.

Redis wird als Message Broker für CeleryExecutor verwendet und als StatefulSet-Anwendung ausgeführt. Nachrichten bleiben somit auch nach einem Neustart des Containers erhalten.

Wenn Sie Planer und Worker unter GKE ausführen, verwenden Sie den KubernetesPodOperator zum Ausführen beliebiger Container-Arbeitslasten. Standardmäßig aktiviert Cloud Composer automatische Upgrades und automatische Reparaturen, um die GKE-Cluster vor Sicherheitslücken zu schützen.

Cloud Composer führt die meisten internen Prozesse in Google Kubernetes Engine-Pods aus, die dem Kubernetes Pod-Lebenszyklus unterliegen. Ein wichtiges Ergebnis ist, dass Pods entfernt werden können. Dies kann beispielsweise der Fall sein, wenn ein bestimmter Pod viel Arbeitsspeicher von einem Knoten belegt. Wenn dieser Pod eine DAG-Aufgabe ausführt, schlägt die Aufgabe aus dem entfernten Pod fehl. Häufige Ursachen für die Pod-Bereinigung in Cloud Composer sind Aufgaben und die gemeinsame Planung von Workern. Weitere Informationen zur Fehlerbehebung bei DAG-Aufgaben, die aufgrund von Pod-Bereinigungen fehlschlagen, finden Sie unter Fehlerbehebung bei DAGs.

Die Planer- und Worker-Knoten sowie der Webserver von Airflow werden mit verschiedenen Dienstkonten ausgeführt.

  • Planer und Worker: Wenn Sie beim Erstellen der Umgebung kein Dienstkonto angeben, wird die Umgebung unter dem standardmäßigen Compute Engine-Dienstkonto ausgeführt.
  • Webserver: Das Dienstkonto wird beim Erstellen der Umgebung automatisch generiert und von der Webserverdomain abgeleitet. Lautet die Domain beispielsweise foo-tp.appspot.com, hat das Dienstkonto die Bezeichnung foo-tp@appspot.gserviceaccount.com.

Informationen zu serviceAccount und airflowUri finden Sie in den Umgebungsdetails.

Cloud Logging und Cloud Monitoring

Cloud Composer kann in Cloud Logging und Cloud Monitoring eingebunden werden, sodass damit eine zentrale Stelle für alle Dienst- und Workflowlogs zu Airflow vorhanden ist.

Aufgrund des Streaming-Charakters von Cloud Logging können Sie alle Logs, die vom Airflow-Planer und von den Airflow-Workern gesendet werden, sofort aufrufen. Sie müssen also nicht auf die Synchronisierung des Airflow-Logging-Moduls warten. Da die Logs von Cloud Logging für Cloud Composer auf google-fluentd beruhen, haben Sie außerdem Zugriff auf alle Logs, die von den Planer- und Worker-Containern generiert werden. Diese Logs vereinfachen die Fehlerbehebung und enthalten nützliche Informationen zu Komponenten auf Systemebene und Airflow-Abhängigkeiten.

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

Airflow-Konfigurationsinformationen

Einige Airflow-Parameter sind für Cloud Composer-Umgebungen vorkonfiguriert und können nicht geändert werden. Andere Parameter konfigurieren Sie beim Erstellen der Umgebung.

Zur erfolgreichen Ausführung von Workflows verwendet Cloud Composer die folgenden Konfigurationen:

  • Das Back-End des Cloud Composer-Dienstes wird mit dem GKE-Dienst-Agent über Pub/Sub in Form von Abos koordiniert. Das Verwalten von Nachrichten beruht auf dem Standardverhalten von Pub/Sub. Löschen Sie keine .*-composer-.*-Themen. Pub/Sub unterstützt maximal 10.000 Themen pro Projekt.
  • Der Cloud Composer-Dienst koordiniert das Logging mit Cloud Logging. Wenn Sie die Anzahl der Logs in Ihrem Google Cloud-Projekt begrenzen möchten, beenden Sie die gesamte Aufnahme von Logs. Deaktivieren Sie das Logging aber nicht.
  • Ändern Sie nicht die Richtlinienbindung von Identity and Access Management für das Cloud Composer-Dienstkonto, z. B. service-your-project-number@cloudcomposer-accounts.iam.gserviceaccount.com.
  • Ändern Sie nicht das Airflow-Datenbankschema.

Wichtige Hinweise

  • Alle Kontingente oder Limits der eigenständigen Google Cloud-Produkte, die von Cloud Composer für das Airflow-Deployment verwendet werden, gelten auch für Ihre Umgebung.
  • Eine Cloud Composer-Version mit einer stabilen Airflow-Version kann Airflow-Updates enthalten, die von einer späteren Airflow-Version zurückportiert werden.
  • Die Planer- und Worker-Knoten haben unterschiedliche Kapazitäten und werden unter einem anderen Dienstkonto als der Airflow-Webserver ausgeführt. Führen Sie keine komplexen Berechnungen durch und greifen Sie nicht auf Google Cloud-Ressourcen zu, auf die der Webserver während des DAG-Parsens keinen Zugriff hat. Dadurch vermeiden Sie DAG-Fehler auf dem Airflow-Webserver.
  • Beim Löschen der Umgebung werden die folgenden Daten in Ihrem Kundenprojekt nicht gelöscht: Cloud Storage-Bucket für Ihre Umgebung, Logging-Logs und der nichtflüchtige Speicher, der von der Redis-Warteschlange verwendet wird, die auf dem GKE-Cluster ausgeführt wird. Exportieren und löschen Sie die Daten gegebenenfalls, um zu vermeiden, dass Ihrem Google Cloud-Konto Gebühren in Rechnung gestellt werden.