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 des environnements

Les environnements Cloud Composer 1 peuvent avoir les configurations d'architecture suivantes :

Chaque configuration modifie légèrement l'architecture des ressources de projet.

Projets clients et locataires

Lorsque vous créez un environnement, Cloud Composer répartit les ressources de celui-ci entre un projet 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.

Un projet locataire est un projet locataire géré par Google. Le projet locataire offre 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 d'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 dans le projet locataire ou dans le projet client de votre environnement.

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

Cluster de l'environnement

Cluster de l'environnement est un cluster Google Kubernetes Engine en mode Standard ou natif VPC ou basé sur les routes de votre environnement :

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

  • Les pods du cluster de l'environnement exécutent des conteneurs avec d'autres composants de l'environnement, tels que les nœuds de calcul et les 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 implémentés 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 de types de charges de travail StatefulSet, DaemonSets et Jobs.

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

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

Les programmeurs Airflow contrôlent la planification des exécutions DAG et les tâches individuelles 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 des 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 file d'attente de tâches individuelles provenant de vos DAG. Les programmeurs Airflow remplissent la file d'attente, laquelle est utilisée par les nœuds de calcul Airflow 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 après le redémarrage du conteneur.

Serveur Web Airflow

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

Dans Cloud Composer 1, le serveur Web Airflow est une instance de l'environnement flexible App Engine 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 l'accès au serveur Web pour les comptes utilisateur disposant d'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 provient 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. Elle héberge la base de données de métadonnées Airflow.

Pour protéger les informations sensibles de connexion et de workflows, Cloud Composer n'autorise l'accès à la base de données qu'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 réside 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. Vous conservez également un 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 :

  • Cloud SQL Storage : stocke les sauvegardes de bases de données Airflow. Cloud Composer sauvegarde les métadonnées d'Airflow de manière quotidienne afin de minimiser les risques de perte de données.

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

  • Proxy Cloud SQL : connecte d'autres composants de votre environnement à la base de données Airflow.

    Selon votre architecture d'environnement, une ou plusieurs instances de proxy Cloud SQL peuvent jouer des rôles différents.

    Un proxy Cloud SQL s'exécute en tant que déploiement dans le cluster de votre environnement ou dans une instance de l'environnement flexible App Engine dans le projet locataire.

    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. Équilibre la charge du trafic vers l'instance Cloud SQL entre deux instances de proxy Cloud SQL qui s'exécutent dans le projet locataire. Ce composant est utilisé dans les architectures d'environnement d'adresse IP privée et s'exécute en tant que conteneur dans le déploiement proxy Cloud SQL.

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

  • 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 général, ce composant est chargé 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. Collecte les journaux de tous les composants de l'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. Il s'appuie sur le comportement par défaut de Pub/Sub pour la gestion des messages. Ne supprimez pas les sujets Pub/Sub .*-composer-.*. Pub/Sub accepte au maximum 10 000 sujets par projet.

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

Architecture d'environnement IP public

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

Une architecture d'environnement IP public pour Cloud Composer 1 présente les caractéristiques suivantes :

  • Le projet locataire héberge une instance Cloud SQL, un espace de stockage Cloud SQL et une instance de l'environnement flexible App Engine 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 une instance de proxy Cloud SQL située 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 IP privé Cloud Composer dans le projet locataire et le projet client
Figure 2. Architecture d'environnement IP public (cliquez pour agrandir)

Une architecture d'environnement IP privé pour Cloud Composer 1 présente les caractéristiques suivantes :

  • 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 la charge du trafic vers l'instance Cloud SQL entre deux instances de 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 limites 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

Adresse IP privée avec les ressources d'environnement DRS Cloud Composer dans les projets client et client (cliquez pour agrandir)
Figure 3. Architecture d'environnement IP public (cliquez pour agrandir)

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

Dans l'adresse IP privée avec l'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'environnements supplémentaires. 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 des buckets 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 la charge du trafic vers l'instance Cloud SQL entre deux instances de 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 limites 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 de 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.

Comme Cloud Logging fonctionne en flux continu, vous pouvez afficher immédiatement les journaux émis par le programmeur et les nœuds de calcul Airflow 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.

Étapes suivantes