Architecture d'Apache Airflow expliquée avec des exemples pratiques

Introduction

Apache Airflow est la principale plateforme open source pour la création, la planification et la surveillance de pipelines de données. À la base, Airflow vous permet de définir des flux de travail sous forme de code, les rendant versionnables, testables et maintenables. Comprendre son architecture est essentiel pour les équipes de développement et d'exploitation qui doivent construire des systèmes d'orchestration de données fiables. Ce guide explique les composants clés d'Airflow, comment les données et le contrôle circulent dans le système, et les considérations pratiques pour son exécution en production.

Nous commencerons par un inventaire des versions et de l'environnement pour établir une base de référence, puis nous parcourrons des chemins de configuration sûrs, des techniques de vérification, des modes de défaillance et de reprise, et enfin nous fournirons une liste de contrôle opérationnelle. En chemin, vous verrez des exemples concrets, des commandes et des extraits de configuration qui illustrent chaque concept.

Inventaire des versions et de l'environnement

Avant de déployer ou d'exploiter Airflow, vous devez savoir exactement quelle version vous utilisez, quels composants sont impliqués et la topologie de l'environnement. Les versions d'Airflow peuvent varier considérablement en comportement, il est donc essentiel de fixer la version.

Version d'Airflow

Airflow suit une gestion sémantique des versions. Au moment de la rédaction, la dernière version stable est la 2.8.1. Consultez toujours la documentation officielle pour la version que vous utilisez. Pour connaître la version installée, exécutez :

airflow version

Exemple de sortie :

2.8.1

Si vous utilisez un environnement Python, vous pouvez également vérifier avec :

pip show apache-airflow | grep Version

Sortie :

Version: 2.8.1

Inventaire des composants essentiels

Airflow se compose de plusieurs composants principaux qui peuvent s'exécuter sur une seule machine pour le développement ou sur plusieurs machines pour la production. Les principaux composants sont :

• Scheduler : déclenche les flux de travail planifiés et soumet les tâches à l'exécuteur.
• Executor : gère l'exécution des tâches. Les exécuteurs courants incluent SequentialExecutor, LocalExecutor, CeleryExecutor et KubernetesExecutor.
• Webserver : fournit l'interface utilisateur pour surveiller et gérer les DAG et les tâches.
• Base de données de métadonnées : stocke l'état et les métadonnées. Généralement PostgreSQL ou MySQL.
• Répertoire des DAG : un dossier contenant les fichiers de définition des DAG, généralement écrits en Python.

Dans une configuration de production typique, ces composants sont distribués. Par exemple, le scheduler et le webserver peuvent s'exécuter sur des machines distinctes, avec des workers Celery exécutant les tâches. Pour ce guide, nous supposons une installation fraîche sur un seul serveur Ubuntu 22.04 LTS avec Python 3.10 et PostgreSQL 14 comme base de métadonnées. La topologie est :

Prérequis

Avant d'installer Airflow, assurez-vous que votre environnement répond à ces prérequis :

• Python 3.8, 3.9, 3.10 ou 3.11
• pip 20.2.4 ou supérieur
• Une base de données telle que PostgreSQL 11+, MySQL 8+ ou SQLite pour le développement uniquement
• Suffisamment d'espace disque pour les journaux et les DAG
• Dépendances système : libpq-dev pour PostgreSQL, libmysqlclient-dev pour MySQL

Installation d'Airflow

Airflow doit être installé dans un environnement virtuel Python dédié. Utilisez les commandes suivantes pour installer Airflow 2.8.1 avec le support PostgreSQL :

python3 -m venv airflow_env
source airflow_env/bin/activate
pip install "apache-airflow[postgres]==2.8.1"

Après l'installation, initialisez la base de métadonnées :

export AIRFLOW_HOME=~/airflow
airflow db init

Cela crée les tables nécessaires dans la base de données configurée. Vous pouvez ensuite démarrer le webserver et le scheduler pour une configuration de développement :

airflow webserver -p 8080
airflow scheduler

Mais ce n'est que le début. Dans les sections suivantes, nous configurerons Airflow pour un environnement de type production et expliquerons l'architecture en profondeur.

Chemin de configuration sûr

Le comportement d'Airflow est contrôlé par des options de configuration définies dans airflow.cfg, par des variables d'environnement ou par des arguments en ligne de commande. Un chemin de configuration sûr signifie apporter des modifications de manière contrôlée et réversible. Nous nous concentrerons sur les paramètres clés qui affectent l'architecture et les performances, et nous fournirons un exemple concret de configuration d'un exécuteur Celery avec PostgreSQL et Redis.

Hiérarchie de configuration

Airflow lit la configuration dans cet ordre :

• Fichier airflow.cfg (par défaut dans $AIRFLOW_HOME)
• Variables d'environnement avec le préfixe AIRFLOW__ (par exemple, AIRFLOW__CORE__SQL_ALCHEMY_CONN)
• Options en ligne de commande (priorité la plus élevée)

Pour la production, l'utilisation de variables d'environnement est courante pour éviter de stocker des secrets dans des fichiers. Cependant, pour ce guide, nous modifierons directement le fichier airflow.cfg par souci de clarté.

Sections de configuration clés

• [core] : paramètres généraux comme dags_folder, executor.
• [database] : chaîne de connexion SQLAlchemy.
• [celery] : paramètres spécifiques à Celery.
• [scheduler] : comportement du scheduler.
• [webserver] : paramètres de l'interface web.

Exemple : Configuration de CeleryExecutor avec PostgreSQL et Redis

Supposons que nous voulions mettre en place une architecture distribuée utilisant CeleryExecutor pour l'exécution de tâches en parallèle sur plusieurs machines worker. Nous aurons besoin d'une base de données PostgreSQL pour les métadonnées et de Redis comme broker Celery.

1. Configuration de PostgreSQL

Créez une base de données et un utilisateur pour Airflow :

CREATE DATABASE airflow;
CREATE USER airflow_user WITH PASSWORD 'strongpassword';
GRANT ALL PRIVILEGES ON DATABASE airflow TO airflow_user;

2. Configuration d'Airflow

Modifiez airflow.cfg :

[core]
executor = CeleryExecutor
dags_folder = /opt/airflow/dags

[database]
sql_alchemy_conn = postgresql+psycopg2://airflow_user:strongpassword@postgres-01/airflow

[celery]
broker_url = redis://redis-01:6379/0
result_backend = db+postgresql://airflow_user:strongpassword@postgres-01/airflow

3. Initialisation de la base de données

Exécutez :

airflow db init

Sortie attendue :

DB: postgresql+psycopg2://airflow_user:***@postgres-01/airflow
[2024-02-20 12:34:56,789] {db.py:1486} INFO - Creating tables
INFO [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO [alembic.runtime.migration] Will assume transactional DDL.
...
Done.

4. Création de l'utilisateur Airflow

Créez un utilisateur administrateur pour la connexion au webserver :

airflow users create \
    --username admin \
    --firstname Admin \
    --lastname User \
    --role Admin \
    --email [email protected]

5. Démarrage des services

Démarrez le scheduler, le webserver et un worker Celery :

airflow scheduler
airflow webserver -p 8080
airflow celery worker

Chaque commande s'exécute dans un terminal séparé ou en tant que service. La sortie attendue comprend des journaux montrant le scheduler analysant les DAG, le webserver démarrant et le worker s'enregistrant auprès du broker.

Choix d'implémentation délimités

Lorsque vous apportez des modifications de configuration, limitez-les à un seul composant ou à une seule fonctionnalité à la fois. Par exemple, si vous changez l'exécuteur, testez-le avec un DAG simple avant de déployer des flux de travail plus complexes. Conservez l'ancienne configuration comme solution de repli. Utilisez un contrôle de version pour tous les fichiers de configuration et les DAG.

Comprendre les DAG et les opérateurs

Un DAG (Directed Acyclic Graph) définit le flux de travail. C'est un script Python qui crée un objet DAG et définit des tâches à l'aide d'opérateurs. Les opérateurs déterminent ce qu'une tâche fait. Par exemple, BashOperator exécute une commande shell, PythonOperator appelle une fonction Python et EmailOperator envoie un e-mail.

Exemple de fichier DAG example_hello_world.py :

from datetime import datetime
from airflow import DAG
from airflow.operators.bash import BashOperator
from airflow.operators.python import PythonOperator

def print_hello():
    print("Hello from Python!")
    return "Hello returned value"

with DAG(
    'hello_world',
    start_date=datetime(2024, 1, 1),
    schedule_interval='@daily',
    catchup=False,
) as dag:
    bash_task = BashOperator(
        task_id='bash_task',
        bash_command='echo "Hello from Bash!"',
    )
    python_task = PythonOperator(
        task_id='python_task',
        python_callable=print_hello,
    )
    bash_task >> python_task  # définit la dépendance

Ce DAG comporte deux tâches : une tâche bash et une tâche Python, la tâche Python dépendant de la tâche bash. L'intervalle de planification est défini sur quotidien.

Planification et flux de données

Le scheduler est le cœur d'Airflow. Il vérifie en permanence les DAG, déclenche les tâches selon le calendrier et les dépendances, et les soumet à l'exécuteur. Le flux de données dans Airflow peut être résumé comme suit :

1. Le scheduler lit les fichiers DAG du dossier des DAG et les analyse.
2. Le scheduler détermine quelles tâches sont prêtes à être exécutées en fonction du calendrier, des dépendances et de l'état dans la base de métadonnées.
3. Le scheduler soumet les instances de tâches à l'exécuteur.
4. L'exécuteur exécute la tâche, soit localement, soit sur un worker, et met à jour l'état de la tâche dans la base de métadonnées.
5. Le webserver lit la base de métadonnées pour afficher les états des tâches et les journaux.

Le flux de contrôle (décisions du scheduler) est séparé du flux de données (exécution des tâches). Cette séparation permet de faire évoluer l'exécuteur indépendamment du scheduler.

Vérification et diagnostics

Après avoir configuré Airflow, vous devez vérifier qu'il fonctionne correctement. Cette section couvre les vérifications observables et les résultats attendus.

Vérifier le scheduler et le webserver

• Vérifiez si le processus du scheduler est en cours d'exécution :

ps aux | grep 'airflow scheduler'

La sortie attendue inclut le processus du scheduler.

• Accédez à l'interface du webserver à http://airflow-web-01:8080. Vous devriez voir la page d'accueil d'Airflow.

Vérifier l'analyse des DAG

Le scheduler analyse périodiquement les DAG. S'il y a une erreur dans un fichier DAG, elle apparaîtra dans l'interface utilisateur avec un message d'erreur en rouge. Vous pouvez également tester manuellement un fichier DAG en exécutant :

python /path/to/dag_file.py

Si aucune erreur ne se produit, le fichier DAG est syntaxiquement correct. Cependant, notez que cela ne garantit pas que les tâches s'exécuteront correctement.

Vérifier la connectivité de la base de données

Vérifiez que le scheduler peut se connecter à la base de métadonnées :

airflow db check

Sortie attendue :

Connection: OK

Si la connexion échoue, vous verrez une erreur indiquant le problème, comme un échec d'authentification ou une base de données non démarrée.

Vérifier l'exécuteur

Pour CeleryExecutor, vérifiez l'état du worker Celery :

airflow celery inspect active

Cette commande interroge le worker pour connaître les tâches actives. Si le worker est en marche, elle retournera une liste vide lorsqu'aucune tâche n'est en cours d'exécution :

[]

Vous pouvez également vérifier la connexion au broker en exécutant :

airflow celery flower

Flower est un outil web de surveillance de Celery. Il démarrera sur le port 5555 par défaut.

Exécuter un DAG de test

Créez un DAG simple qui affiche un message, puis déclenchez-le manuellement et observez les journaux des tâches.

1. Ajoutez le fichier DAG au dossier des DAG.
2. Dans l'interface utilisateur, activez le DAG (basculez l'interrupteur).
3. Cliquez sur le bouton "Trigger DAG".
4. Allez dans la vue Graph et observez la tâche devenir verte, indiquant le succès.
5. Cliquez sur l'instance de tâche et ouvrez les journaux. Vous devriez voir la sortie de la tâche.

Exemple de sortie de journal pour la tâche bash :

[2024-02-20 13:00:00,123] {bash.py:135} INFO - Running command: echo "Hello from Bash!"
[2024-02-20 13:00:00,456] {bash.py:142} INFO - Output:
[2024-02-20 13:00:00,789] {bash.py:146} INFO - Hello from Bash!
[2024-02-20 13:00:01,012] {bash.py:150} INFO - Command exited with return code 0

Métriques de surveillance

Airflow expose des métriques au format StatsD. Vous pouvez configurer statsd_on = True dans airflow.cfg et définir statsd_host et statsd_port. Utilisez ensuite un outil comme Prometheus avec l'exportateur StatsD pour collecter et visualiser les métriques. Les métriques clés incluent :

• scheduler.tasks.running
• scheduler.tasks.starving
• dag_processing.import_errors
• executor.open_slots

Surveiller régulièrement ces métriques aide à garantir la santé de votre déploiement Airflow.

Modes de défaillance et reprise

Même avec une configuration soignée, Airflow peut tomber en panne. Comprendre les modes de défaillance courants et comment les récupérer est crucial.

Points de défaillance courants

Étapes de reprise

Défaillance du scheduler

Si le scheduler plante, vérifiez les journaux situés dans $AIRFLOW_HOME/logs/scheduler/. Recherchez une trace de pile ou des erreurs de mémoire insuffisante. Redémarrez le scheduler :

airflow scheduler

S'il plante à plusieurs reprises, recherchez la cause. Les problèmes courants incluent des problèmes de connexion à la base de données ou un bug dans un DAG qui provoque une consommation excessive de ressources.

Panne de la base de métadonnées

Si la base de données est en panne, restaurez-la à partir d'une sauvegarde si nécessaire. Assurez-vous que le service de base de données est en cours d'exécution et accessible. Vérifiez la chaîne sql_alchemy_conn dans airflow.cfg pour détecter les erreurs.

Worker de l'exécuteur en panne

Pour Celery, si un worker tombe en panne, les tâches resteront dans la file d'attente. Démarrez un nouveau worker :

airflow celery worker

Vous devrez peut-être redémarrer le worker s'il consomme trop de mémoire. Surveillez les workers avec Flower.

Panne du broker

Si Redis tombe en panne, le scheduler et les workers ne peuvent pas communiquer. Redémarrez Redis et assurez-vous que la chaîne de connexion est correcte. Envisagez d'utiliser Redis avec la persistance activée pour éviter la perte de données.

Erreur d'analyse du DAG

Corrigez l'erreur de syntaxe dans le fichier DAG. Le scheduler reprendra automatiquement le fichier corrigé après un court intervalle (par défaut min_file_process_interval est de 30 secondes).

Stratégies de retour en arrière et de reprise

• Retour en arrière du code des DAG : Si une nouvelle version d'un DAG cause des problèmes, revenez au fichier DAG de la version précédente en utilisant le contrôle de version. Le scheduler analysera l'ancien code. Utilisez catchup=False pour éviter un remplissage rétroactif non intentionnel.
• Remplissage rétroactif avec prudence : Pour ré-exécuter des dates historiques, utilisez la commande airflow dags backfill. Par exemple :

airflow dags backfill -s 2024-02-01 -e 2024-02-10 hello_world

Cela exécutera le DAG pour chaque jour du 1er au 10 février. Soyez prudent lors de l'utilisation du remplissage rétroactif en production car il peut déclencher de nombreuses tâches et surcharger les ressources.

• Effacer les états des tâches : Si une tâche échoue, vous pouvez effacer son état pour la ré-exécuter. Dans l'interface utilisateur, cliquez sur la tâche échouée et sélectionnez "Clear". Alternativement, en utilisant la CLI :

airflow tasks clear -s 2024-02-20 -e 2024-02-20 hello_world bash_task

Cela efface l'état de l'instance de tâche pour cette date, provoquant sa ré-exécution.

Vérifications après reprise

Après toute reprise, vérifiez :

• Le scheduler émet des battements de cœur (vérifiez les journaux pour les messages "Heartbeat").
• Le webserver est accessible et affiche les DAG.
• L'exécuteur traite les tâches (vérifiez les démarrages de tâches dans les journaux).
• La connexion à la base de données est saine (airflow db check).

Pièges courants et comment les éviter

Les pièges d'Airflow proviennent souvent d'une mauvaise compréhension de son architecture ou d'une mauvaise configuration des composants. Voici les erreurs les plus courantes que nous voyons, pourquoi elles se produisent et comment les éviter ou les récupérer.

1. Utiliser SQLite en production

Pourquoi cela arrive : SQLite est la base de métadonnées par défaut et fonctionne bien pour un test local rapide, donc les équipes le laissent parfois inchangé lors du passage en production.

Comment éviter : Configurez toujours une base de données robuste comme PostgreSQL ou MySQL pour tout déploiement non trivial. SQLite ne prend pas bien en charge les écritures simultanées et peut provoquer des blocages du scheduler. Définissez sql_alchemy_conn dans [database] sur une base de données de qualité production dès le premier jour.

Reprise : Si vous découvrez SQLite en production, migrez vers PostgreSQL/MySQL en exportant les métadonnées (en utilisant airflow db export) et en les important dans la nouvelle base de données après avoir modifié la chaîne de connexion. Redémarrez ensuite le scheduler et le webserver.

2. Ignorer start_date et catchup

Pourquoi cela arrive : Les nouveaux utilisateurs définissent souvent start_date à la date actuelle et laissent catchup=True (par défaut dans Airflow 1.x) sans se rendre compte que le scheduler tentera de remplir rétroactivement chaque intervalle manqué.

Comment éviter : Définissez catchup=False sur le DAG, sauf si vous souhaitez explicitement des remplissages rétroactifs. Choisissez une start_date statique et dans le passé, pas datetime.now(), pour éviter les problèmes de fuseau horaire.

Reprise : Si un DAG déclenche de manière inattendue de nombreuses tâches de remplissage rétroactif, définissez catchup=False et effacez les instances de tâches indésirables en utilisant l'interface utilisateur ou la CLI.

3. Surcharger le scheduler avec trop de DAG ou des intervalles courts

Pourquoi cela arrive : Les équipes créent de nombreux DAG avec schedule_interval toutes les minutes voire toutes les secondes, sans tenir compte du surcoût d'analyse et de planification du scheduler.

Comment éviter : Surveillez scheduler.tasks.starving et les temps d'analyse des DAG. Regroupez les petites tâches dans des DAG plus grands lorsque c'est possible, et utilisez des intervalles raisonnables (par exemple, pas moins de 5 minutes pour la plupart des cas d'utilisation). Envisagez d'utiliser un processeur de DAG dédié si nécessaire.

Reprise : Si le scheduler est submergé, réduisez le nombre de DAG ou augmentez les intervalles. Vous pouvez également ajuster scheduler.max_tis_per_query et scheduler.parsing_processes en fonction de votre matériel.

4. Ne pas définir result_backend pour Celery

Pourquoi cela arrive : CeleryExecutor nécessite un backend de résultats pour stocker les résultats des tâches. S'il n'est pas configuré, les tâches peuvent s'exécuter mais la base de métadonnées ne sera pas mise à jour correctement, ce qui conduit à des exécutions en double ou des états bloqués.

Comment éviter : Définissez toujours result_backend dans [celery] soit sur une base de données (comme montré précédemment), soit sur un broker de messages comme Redis.

Reprise : Mettez à jour airflow.cfg avec le bon result_backend, redémarrez le scheduler et les workers, et effacez toutes les instances de tâches bloquées.

5. Stocker des secrets dans les fichiers DAG ou airflow.cfg

Pourquoi cela arrive : Les développeurs codent souvent en dur les identifiants dans le code DAG ou la configuration pour plus de commodité.

Comment éviter : Utilisez les connexions et variables Airflow stockées dans la base de métadonnées (chiffrées au repos si configuré) ou un backend de secrets externe comme HashiCorp Vault ou AWS Secrets Manager. Ne mettez jamais de secrets dans le code.

Reprise : Si des secrets ont été exposés, faites-les pivoter immédiatement et déplacez-les vers le backend de secrets. Mettez à jour les DAG pour utiliser Connection.get_connection_from_secrets() ou des variables d'environnement.

6. Absence de surveillance ou d'alerte

Pourquoi cela arrive : Les petites équipes peuvent négliger la surveillance au départ, s'appuyant sur des vérifications manuelles.

Comment éviter : Configurez les métriques StatsD et intégrez-les avec Prometheus/Grafana. Configurez des alertes pour les métriques clés comme import_errors > 0, scheduler.tasks.starving > seuil ou worker en panne.

Reprise : Commencez par activer StatsD et exportez vers un système de surveillance. Créez des tableaux de bord et des règles d'alerte progressivement.

Liste de contrôle opérationnelle

L'exécution d'Airflow en production nécessite une discipline opérationnelle continue. Voici une liste de contrôle reproductible pour les revues quotidiennes, hebdomadaires et mensuelles. Pour chaque élément, attribuez un seul responsable (par exemple, un ingénieur spécifique de votre équipe) et définissez une cadence de revue.

Vérifications quotidiennes

Effectuez ces vérifications quotidiennement. Responsabilité : L'ingénieur de données de garde (par exemple, Priya Shah, ingénieure de données) examine cette liste chaque matin.

• [ ] Processus du scheduler en cours d'exécution et émettant des battements de cœur (responsable : Priya Shah, vérifiez les journaux pour les messages "Heartbeat").
• [ ] Webserver réactif (responsable : Priya Shah, curl ou accès à l'interface utilisateur).
• [ ] Aucune erreur d'importation dans les DAG (responsable : Priya Shah, vérifiez le tableau de bord de l'interface utilisateur ou la métrique import_errors).
• [ ] Aucune tâche bloquée en état de file d'attente trop longtemps (responsable : Priya Shah, consultez les durées des tâches).
• [ ] Pas d'échecs excessifs de tâches (responsable : Priya Shah, surveillez les métriques d'échec).
• [ ] Connexion à la base de données stable (responsable : Priya Shah, exécutez airflow db check).

Vérifications hebdomadaires

Effectuez ces vérifications chaque lundi matin. Responsabilité : Le responsable de la plateforme de données (par exemple, Marcus Chen, responsable de la plateforme de données) est propriétaire de cette revue.

• [ ] Examinez les journaux des tâches pour détecter des anomalies (responsable : Marcus Chen).
• [ ] Surveillez l'utilisation des ressources (CPU, mémoire) du scheduler, du webserver et des workers (responsable : Marcus Chen).
• [ ] Vérifiez l'espace disque pour les journaux et les fichiers DAG ; faites tourner les journaux si nécessaire (responsable : Marcus Chen).
• [ ] Vérifiez les sauvegardes de la base de métadonnées (responsable : Marcus Chen).
• [ ] Examinez les modifications du code DAG pour détecter des problèmes potentiels (responsable : Marcus Chen).

Vérifications mensuelles

Effectuez ces vérifications le premier jour ouvrable de chaque mois. Responsabilité : Le responsable de l'ingénierie des données (par exemple, Sarah Johnson, responsable de l'ingénierie des données) est propriétaire de cette revue.

• [ ] Appliquez les correctifs de sécurité et mettez à jour Airflow vers une version stable après test (responsable : Sarah Johnson).
• [ ] Examinez les comptes d'utilisateurs et les autorisations (responsable : Sarah Johnson).
• [ ] Testez les procédures de reprise après sinistre (responsable : Sarah Johnson).
• [ ] Examinez les performances et envisagez de faire évoluer l'exécuteur si nécessaire (responsable : Sarah Johnson).
• [ ] Validez que les DAG sont toujours alignés sur les exigences métier (responsable : Sarah Johnson).

Exemple de commande de surveillance

Utilisez la CLI Airflow pour lister les DAG et leurs planifications :

airflow dags list

Sortie :

DAG ID       | Schedule | Owner
-------------------------------------
hello_world  | @daily   | admin

Cela permet de s'assurer que les DAG attendus sont présents et correctement planifiés.

Conclusion

Comprendre l'architecture d'Apache Airflow est fondamental pour construire des pipelines de données fiables. Nous avons couvert les composants essentiels, le flux de données et de contrôle, la configuration sûre avec une configuration Celery pratique, les étapes de vérification, les modes de défaillance et de reprise, les pièges courants et une liste de contrôle opérationnelle. En suivant les directives de ce guide, vous pouvez déployer et maintenir Airflow efficacement.

Comme prochaines étapes, envisagez de :

• Expérimenter avec différents exécuteurs pour voir comment ils affectent la mise à l'échelle.
• Explorer des fonctionnalités avancées comme XComs pour passer des données entre les tâches.
• Mettre en œuvre la surveillance avec Prometheus et Grafana pour une meilleure visibilité.
• Intégrer un backend de secrets pour la gestion des identifiants.
• Mettre en place un CI/CD pour vos DAG afin d'assurer la qualité du code.

Airflow est un outil puissant, et avec une solide compréhension architecturale, vous pouvez l'exploiter pour orchestrer des flux de travail complexes en toute confiance.