Architecture des environnements Cloud Composer

Cloud Composer 1 | Cloud Composer 2

Cette page décrit l'architecture des environnements Cloud Composer 1.

Configurations d'architecture d'environnement

Les environnements Cloud Composer 1 peuvent présenter les configurations d'architecture suivantes:

Chaque configuration modifie légèrement l'architecture des ressources d'environnement.

Projets clients et locataires

Lorsque vous créez un environnement, Cloud Composer répartit les ressources de cet environnement entre un locataire et un projet client.

Le projet client est un projet Google Cloud dans lequel vous créez vos environnements. Vous pouvez créer plusieurs environnements dans un même projet client.

Le projet locataire est un projet locataire géré par Google. Le projet locataire fournit un contrôle d'accès unifié et une couche de sécurité des données supplémentaire pour votre environnement. Chaque environnement Cloud Composer possède son propre projet locataire.

Composants de l'environnement

Un environnement Cloud Composer est constitué de composants d'environnement.

Un composant d'environnement est un élément d'une infrastructure Airflow gérée qui s'exécute sur Google Cloud dans votre environnement.

Les composants d'environnement s'exécutent soit dans le locataire, soit dans le projet client de votre environnement.

Certains composants de votre environnement sont basés sur des produits Google Cloud autonomes. Les quotas et limites applicables à ces produits s'appliquent également à vos environnements. Par exemple, les environnements Cloud Composer utilisent des appairages VPC. Les quotas sur le nombre maximal d'appairages VPC s'appliquent à votre projet client. Par conséquent, une fois que votre projet atteint ce nombre maximal d'appairages, vous ne pouvez pas créer d'environnements supplémentaires.

Cluster de l'environnement

Cluster de l'environnement est unAccès standard modeVPC natif ouBasé sur le routage Cluster Google Kubernetes Engine de votre environnement:

  • Les nœuds d'environnement sont des VM du cluster de l'environnement.

  • Les pods du cluster de l'environnement exécutent des conteneurs avec d'autres composants d'environnement, tels que des nœuds de calcul et des programmeurs Airflow. Les pods s'exécutent sur des nœuds d'environnement.

  • Les ressources de charge de travail du cluster de votre environnement gèrent des ensembles de pods dans le cluster de votre environnement De nombreux composants de votre environnement sont mis en œuvre sous la forme de différents types de ressources de charge de travail. Par exemple, les nœuds de calcul Airflow s'exécutent en tant que déploiements. En plus des déploiements, votre environnement dispose également d'objets StatefulSet, DaemonSet et Tasks.

Par défaut, Cloud Composer active les mises à niveau automatiques des nœuds et la réparation automatique des nœuds pour protéger le cluster de votre environnement contre les failles de sécurité. Ces opérations ont lieu pendant les intervalles de maintenance que vous spécifiez pour votre environnement.

Planificateurs Airflow, nœuds de calcul et file d'attente Redis

Les planificateurs Airflow contrôlent la planification des exécutions de DAG et des tâches individuelles à partir des DAG. Les programmeurs distribuent les tâches aux nœuds de calcul Airflow à l'aide d'une file d'attente Redis qui s'exécute en tant qu'application dans le cluster de votre environnement. Les programmeurs Airflow s'exécutent en tant que déploiements dans le cluster de votre environnement.

Les nœuds de calcul Airflow exécutent des tâches individuelles à partir de DAG en les extrayant de la file d'attente Redis. Les nœuds de calcul Airflow s'exécutent en tant que déploiements dans le cluster de votre environnement.

La file d'attente Redis contient une liste de tâches individuelles issues de vos DAG. Les programmeurs Airflow remplissent la file d'attente. Les nœuds de calcul Airflow l'utilisent pour effectuer leurs tâches. La file d'attente Redis s'exécute en tant qu'application StatefulSet dans le cluster de votre environnement, de sorte que les messages persistent lors du redémarrage du conteneur.

Serveur Web Airflow

Le serveur Web Airflow exécute l'interface utilisateur Aiflow de votre environnement.

Dans Cloud Composer 1, le serveur Web Airlfow est une instance App Engine Flex qui s'exécute dans le projet locataire de votre environnement.

Le serveur Web Airflow est intégré à Identity-Aware Proxy. Cloud Composer masque les détails de l'intégration IAP et fournit un accès au serveur Web pour les comptes utilisateur disposant des autorisations suffisantes pour accéder au serveur Web.

Le serveur Web Airflow s'exécute sur un compte de service différent de celui des nœuds de calcul et des programmeurs Airflow. Le compte de service du serveur Web est généré automatiquement lors de la création de l'environnement et est dérivé du domaine du serveur Web. Par exemple, si le domaine est example.appspot.com, le compte de service est example@appspot.gserviceaccount.com.

Base de données Airflow

La base de données Airflow est une instance Cloud SQL qui s'exécute dans le projet locataire de votre environnement. Il héberge la base de données de métadonnées Airflow.

Pour protéger les informations sensibles sur les connexions et les workflows, Cloud Composer autorise l'accès à la base de données uniquement au compte de service de votre environnement.

.

Bucket de l'environnement

Le bucket de l'environnement est un bucket Cloud Storage qui stocke les DAG, les plug-ins, les dépendances de données et les journaux Airflow. Le bucket de l'environnement se trouve dans le projet client.

Lorsque vous importez vos fichiers DAG dans le dossier /dags du bucket de votre environnement, Cloud Composer synchronise les DAG avec les nœuds de calcul, les programmeurs et le serveur Web de votre environnement. Vous pouvez stocker vos artefacts de workflow dans les dossiers data/ et logs/ sans vous soucier des limites de taille, et conserver le contrôle total des accès à vos données.

Autres composants de l'environnement

Un environnement Cloud Composer comporte plusieurs composants d'environnement supplémentaires:

  • Stockage Cloud SQL Stocke les sauvegardes de base de données Airflow. Cloud Composer sauvegarde les métadonnées Airflow quotidiennement afin de minimiser la perte potentielle de données.

    Cloud SQL Storage s'exécute dans le projet locataire de votre environnement. Vous ne pouvez pas accéder au contenu de l'espace de stockage Cloud SQL.

  • Proxy Cloud SQL. Connecte les autres composants de votre environnement à la base de données Airflow.

    Votre environnement peut avoir une ou plusieurs instances de proxy Cloud SQL qui jouent des rôles différents, en fonction de l'architecture de votre environnement.

    Un proxy Cloud SQL s'exécute en tant que déploiement dans le cluster de votre environnement ou dans une instance App Engine Flex dans le projet locataire. (Installation de Python groupée).

    Lorsqu'il est déployé dans le cluster de votre environnement, le proxy Cloud SQL autorise également l'accès à votre instance Cloud SQL depuis une application, un client ou un autre service Google Cloud.

  • HAProxy : La charge équilibre le trafic vers l'instance Cloud SQL entre deux instances de proxy Cloud SQL exécutées dans le projet locataire. Ce composant est utilisé dans les architectures d'environnement d'adresses IP privées et s'exécute en tant que conteneur dans le déploiement du proxy Cloud SQL.

  • Surveillance Airflow. Il consigne les métriques d'environnement dans Cloud Monitoring et déclenche le DAG airflow_monitoring. Le DAG airflow_monitoring signale les données d'état de l'environnement, qui sont ensuite intentées en justice, par exemple, sur le tableau de bord de surveillance de votre environnement. Airlfow Monitoring s'exécute en tant que déploiement dans le cluster de votre environnement.

  • L'agent Composer effectue des opérations sur les environnements telles que la création, la mise à jour, la mise à niveau et la suppression d'environnements. En règle générale, il permet d'introduire des modifications dans votre environnement. S'exécute en tant que tâche dans le cluster de votre environnement.

  • Airflow InitDB crée une instance Cloud SQL et un schéma de base de données initial. Airflow InitDB s'exécute en tant que tâche dans le cluster de votre environnement.

  • FluentD : Collectt les journaux de tous les composants d'environnement et les importe dans Cloud Logging. S'exécute en tant que DaemonSet dans le cluster de votre environnement.

  • Abonnements Pub/Sub : Votre environnement communique avec son agent de service GKE via des abonnements Pub/Sub. Elle s'appuie sur le comportement par défaut de Pub/Sub pour gérer les messages. Ne supprimez pas les sujets Pub/Sub .*-composer-.*. Pub/Sub accepte un maximum de 10 000 sujets par projet.

  • Synchronisation des buckets. Ce processus synchronise les buckets d'environnement dans les projets client et locataire. Ce composant est utilisé dans l'architecture des adresses IP privées avec l'environnement DRS. Ce composant s'exécute en tant que conteneur dans les pods d'autres composants utilisant des buckets d'environnement.

Architecture de l'environnement IP public

Ressources de l'environnement Cloud Composer d'adresse IP publique dans le projet locataire et le projet client
Figure 1. Architecture de l'environnement IP public (cliquez pour agrandir)

Dans une architecture d'environnement d'adresse IP publique pour Cloud Composer 1, procédez comme suit:

  • Le projet locataire héberge une instance Cloud SQL, un espace de stockage Cloud SQL et une instance App Engine Flex qui exécute le serveur Web Airflow.
  • Le projet client héberge tous les autres composants de l'environnement.
  • Les programmeurs et les nœuds de calcul Airflow du projet client communiquent avec la base de données Airflow via des instances de proxy Cloud SQL situées dans le projet client.
  • Le serveur Web Airflow du projet locataire communique avec la base de données Airflow via une instance de proxy Cloud SQL située dans le projet locataire.

Adresse IP privée

Ressources de l'environnement Cloud Composer d'adresse IP privée dans le projet locataire et le projet client
Figure 2. Architecture de l'environnement IP privée (cliquez pour agrandir)

Dans une architecture d'environnement d'adresse IP privée pour Cloud Composer 1:

  • Le projet locataire héberge une instance Cloud SQL, un espace de stockage Cloud SQL et deux instances App Engine qui exécutent le serveur Web Airflow.
  • Le projet client héberge tous les autres composants de l'environnement.
  • Les programmeurs et les nœuds de calcul Airflow se connectent à la base de données Airflow via le processus HAProxy dans le cluster de l'environnement.
  • Le processus HAProxy équilibre le trafic vers l'instance Cloud SQL entre deux instances du proxy Cloud SQL situées dans le projet locataire. Les environnements IP privés utilisent deux instances de proxy Cloud SQL, car le projet client n'accède pas directement à la base de données en raison des limitations du réseau. Deux instances sont nécessaires pour vous assurer que les composants de votre environnement ont accès à la base de données à tout moment.

Adresse IP privée avec DRS

Ressources de l'environnement Cloud Composer d'adresse IP privée avec partage restreint de domaine dans le projet locataire et le projet client (cliquez pour agrandir)
Figure 3 Architecture de l'environnement IP privée (cliquez pour agrandir)

Si la règle d'administration de partage restreint de domaine est activée dans votre projet, Cloud Composer utilise l'adresse IP privée avec l'architecture de l'environnement DRS.

Dans Private IP avec une architecture d'environnement DRS:

  • Le projet locataire héberge une instance Cloud SQL, un espace de stockage Cloud SQL et deux instances App Engine qui exécutent le serveur Web Airflow.

  • Le projet locataire héberge un bucket d'environnement supplémentaire. Le serveur Web Airflow accède directement à ce bucket.

  • Le projet client héberge tous les autres composants de l'environnement.

  • Le projet client héberge le processus de synchronisation de bucket dans le cluster de l'environnement. Ce processus synchronise deux buckets d'environnement.

  • Les programmeurs et les nœuds de calcul Airflow se connectent à la base de données Airflow via le processus HAProxy dans le cluster de l'environnement.

  • Le processus HAProxy équilibre le trafic vers l'instance Cloud SQL entre deux instances du proxy Cloud SQL situées dans le projet locataire. Les environnements IP privés utilisent deux instances de proxy Cloud SQL, car le projet client n'accède pas directement à la base de données en raison des limitations du réseau. Deux instances sont nécessaires pour vous assurer que les composants de votre environnement ont accès à la base de données à tout moment.

Intégration à Cloud Logging et Cloud Monitoring

Cloud Composer s'intègre à Cloud Logging et à Cloud Monitoring pour votre projet Google Cloud afin de centraliser l'affichage du service Airflow et des journaux de workflow.

Cloud Monitoring collecte et ingère des métriques, des événements et des métadonnées à partir de Cloud Composer pour générer des insights via des tableaux de bord et des graphiques.

En raison de la nature des flux de Cloud Logging, vous pouvez afficher les journaux émis par le programmeur et les nœuds de calcul Airflow immédiatement au lieu d'attendre que les journaux Airflow apparaissent dans le bucket Cloud Storage de votre environnement. Les journaux Cloud Logging pour Cloud Composer étant basés sur google-fluentd, vous avez accès à tous les journaux produits par les programmeurs et les nœuds de calcul Airflow.

Pour limiter le nombre de journaux dans votre projet Google Cloud, vous pouvez arrêter l'ingestion de tous les journaux. Ne désactivez pas Logging.

Étape suivante