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 :

• Architecture IP publique

• Architecture d'adresse IP privée avec appairages de VPC

• Adresse IP privée avec architecture de partage restreint de domaine (DRS)

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.

Attention : N'introduisez pas de modifications dans le cluster de l'environnement. Les clusters pour Cloud Composer et les charges de travail déployées sont gérés par Google. Il est possible de modifier la configuration du cluster de votre environnement, mais cela peut endommager votre environnement. Si vous supprimez le cluster d'un environnement, il ne peut pas être restauré. Vous devez supprimer l'environnement et en créer un autre.

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 un accès au serveur Web en fonction des identités des utilisateurs et des liaisons de stratégie IAM définies pour les utilisateurs.

Le serveur Web Airflow s'exécute sur un compte de service différent de celui des nœuds de calcul Airflow et des programmeurs Airflow. Le compte de service pour le 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 [e-mail].

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.

Attention : La modification du schéma de base de données Airflow ou l'exécution des commandes Airflow resetdb, initdb ou upgradedb peuvent endommager l'environnement de Cloud Composer.

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.

Remarque : En raison d'une restriction des services sur App Engine, les dossiers data/ et logs/ ne sont pas disponibles pour le serveur Web Airflow.

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.

  Votre environnement IP public peut comporter une ou plusieurs instances du proxy Cloud SQL, en fonction du volume de trafic vers la base de données Airflow.

  Dans le cas d'un environnement IP public, un proxy Cloud SQL s'exécute en tant que déploiement dans le cluster de votre environnement.

  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 à destination de l'instance Cloud SQL entre deux instances de proxy Cloud SQL exécutées dans le projet locataire. Dans le cas de Cloud Composer 1, ce composant est utilisé dans des environnements IP privés et s'exécute en tant que conteneur dans le déploiement du 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 signale les données d'état de l'environnement, qui seront utilisées ultérieurement, par exemple, dans 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 des buckets. Ce processus synchronise les buckets d'environnement dans les projets client et locataires. 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

  

  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 dans le projet locataire communique avec la base de données Airflow via une instance de proxy Cloud SQL située dans le projet locataire.

  Architecture de l'environnement IP privé

  

  Figure 2. Architecture d'environnement IP public (cliquez pour agrandir)

  Dans une architecture d'environnement IP privé:

  • 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

  

  Figure 3. Architecture d'environnement IP public (cliquez pour agrandir)

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

  Dans l'architecture de l'adresse IP privée avec 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 du 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 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

  • Créez un environnement
  • Présentation de la gestion des versions.