Airflow géré (3e génération) | Airflow géré (2e génération) | Airflow géré (1re génération héritée)
Cette page décrit l'architecture des environnements Airflow gérés.
Configurations d'architecture des environnements
Les environnements Airflow gérés (1re génération héritée) peuvent avoir les configurations d'architecture suivantes :
- Architecture IP publique
- Architecture IP privée avec appairages VPC
- Architecture IP privée avec partage limité au domaine (DRS)
Projets clients et locataires
Lorsque vous créez un environnement, Airflow géré répartit les ressources de celui-ci entre un projet locataire et un projet client :
Le projet client est un Google Cloud projet 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 et appartient à l'organisation Google.com. Le projet locataire offre contrôle des accès unifié et une couche de sécurité des données supplémentaire pour votre environnement. Chaque environnement Airflow géré possède son propre projet locataire.
Composants d'environnement
Un environnement Airflow géré 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.
Cluster de l'environnement
Le cluster de l'environnement est un cluster Google Kubernetes Engine en mode Standard ou natif VPC ou basé sur les routes de votre environnement :
Par défaut, Airflow géré 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.
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, Airflow géré synchronise les DAG avec les composants Airflow de votre environnement.
Serveur Web Airflow
Le serveur Web Airflow exécute l'interface utilisateur d'Airflow de votre environnement.
Dans Airflow géré (1re génération héritée), le serveur Web Airflow s'exécute dans le projet locataire de votre environnement.
Le serveur Web Airflow est intégré à Identity-Aware Proxy. Airflow géré masque les détails d'intégration d'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.
Dans Airflow géré (1re génération héritée), 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. Elle héberge la base de données de métadonnées Airflow.
Pour protéger les informations sensibles de connexion et de workflows, Airflow géré n'autorise l'accès à la base de données qu'au compte de service de votre environnement.
Autres composants Airflow
Les autres composants Airflow qui s'exécutent dans votre environnement sont les suivants :
Les programmeurs Airflow analysent les fichiers DAG, planifient l'exécution des DAG en fonction de l'intervalle de programmation et mettent en file d'attente les tâches que les nœuds de calcul Airflow exécuteront. Dans Airflow géré (1re génération héritée), les processeurs DAG Airflow s'exécutent dans le cadre des composants du programmeur.
Les nœuds de calcul Airflow exécutent les tâches planifiées par les programmeurs Airflow.
Architecture d'environnement IP public
Une architecture d'environnement IP public pour Airflow géré (1re génération héritée) 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.
Architecture d'environnement IP privé
Une architecture d'environnement IP privé 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
Si la stratégie d'organisation de partage limité au domaine (DRS) est activée dans votre projet, Airflow géré utilise l'architecture d'environnement IP privée avec DRS.
Dans l'architecture d'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 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
Airflow géré s'intègre à Cloud Logging et à Cloud Monitoring de votre Google Cloud projet afin de centraliser l'affichage des journaux Airflow et DAG.
Cloud Monitoring collecte et ingère des métriques, des événements et des métadonnées à partir d'Airflow géré 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 les composants Airflow au lieu d'attendre que les journaux Airflow apparaissent dans le bucket Cloud Storage de votre environnement.
Pour limiter le nombre de journaux dans votre Google Cloud projet, vous pouvez arrêter toutes les ingestions de journaux. Ne désactivez pas Logging.