Planification de capacité avec Apache Airflow : exemples pratiques

Introduction

Apache Airflow est un orchestrateur puissant, mais ses performances dépendent fortement du dimensionnement de son infrastructure sous-jacente. De nombreuses équipes commencent avec une petite instance et se heurtent ensuite à des murs lorsque la complexité des DAG, le volume de tâches ou la concurrence augmentent. La planification de la capacité n'est pas un événement ponctuel ; c'est une pratique continue qui équilibre coût, performance et fiabilité.

Ce guide présente une approche pratique de la planification de capacité pour Airflow. Vous apprendrez à inventorier votre environnement, à estimer les besoins en ressources, à choisir des options de configuration sûres, à vérifier les performances, à gérer les modes de défaillance et à maintenir une liste de contrôle opérationnelle. Chaque étape majeure comprend des commandes concrètes, des extraits de configuration et des sorties attendues afin que vous puissiez appliquer directement les conseils. À la fin, vous disposerez d'une méthode reproductible pour maintenir votre déploiement Airflow en bonne santé à mesure qu'il évolue.

Inventaire des versions et de l'environnement

Avant d'ajuster un paramètre de capacité, documentez votre configuration actuelle. Connaître votre version d'Airflow, le type d'exécuteur, la base de données, le courtier et la topologie des nœuds est essentiel. Cet inventaire vous aide à identifier les goulots d'étranglement et à planifier les changements en toute sécurité.

Version d'Airflow et exécuteur

Exécutez la commande suivante sur votre hôte Airflow pour vérifier la version :

airflow version

Exemple de sortie attendue :

2.8.1

Ensuite, déterminez quel exécuteur est configuré. Regardez dans airflow.cfg ou vérifiez l'environnement :

airflow config get-value core executor

Les valeurs typiques incluent SequentialExecutor (développement uniquement), LocalExecutor, CeleryExecutor ou KubernetesExecutor. Pour les charges de travail de production au-delà de quelques tâches, CeleryExecutor ou KubernetesExecutor est courant. Le choix de l'exécuteur affecte la façon dont vous faites évoluer les workers et la gestion de la concurrence.

Topologie et composants

Un déploiement Airflow typique comprend :

• Serveur Web : Sert l'interface utilisateur et l'API.
• Planificateur : Analyse les DAG, planifie les tâches et les met en file d'attente.
• Worker(s) : Exécutent les tâches (pour les exécuteurs distribués).
• Base de données de métadonnées : Stocke l'état (PostgreSQL ou MySQL recommandé).
• Courtier de messages : Redis ou RabbitMQ pour Celery.

Documentez le nombre de nœuds, leur CPU, mémoire et disque. Notez également la latence réseau entre les composants, en particulier entre le planificateur et la base de données, car cela peut affecter les performances du planificateur.

Prérequis pour la planification de capacité

Vous avez besoin de données de surveillance pour prendre des décisions éclairées. Assurez-vous de collecter :

• Métriques système : CPU, mémoire, E/S disque, réseau pour chaque composant Airflow.
• Métriques Airflow : Durée des tâches, temps en file d'attente, durée de la boucle du planificateur, temps d'analyse des DAG, nombre de tâches en cours.
• Métriques de base de données : Connexions, latence des requêtes, verrous et taille.

Airflow expose des métriques à StatsD ou Prometheus. Si vous n'avez pas de surveillance, mettez-la en place tôt ; la planification de capacité sans données n'est que conjecture.

Exemple de tableau d'inventaire

Créez un tableau simple comme celui-ci pour enregistrer votre base de référence.

Cette base de référence vous aide à suivre les changements au fil du temps.

Chemin de configuration sûr

Les paramètres liés à la capacité dans Airflow contrôlent la concurrence, le parallélisme et l'utilisation des ressources. Ajustez-les progressivement et testez après chaque changement. Évitez les grands sauts ; des étapes petites et mesurées réduisent les risques.

Paramètres de configuration clés

Ouvrez airflow.cfg (ou utilisez des variables d'environnement) et examinez ces paramètres essentiels :

• parallelism : nombre maximal d'instances de tâches pouvant s'exécuter simultanément sur l'ensemble du cluster Airflow. La valeur par défaut est 32.
• dag_concurrency : nombre maximal d'instances de tâches autorisées à s'exécuter simultanément pour un seul DAG. La valeur par défaut est 16.
• max_active_runs_per_dag : nombre maximal d'exécutions de DAG actives par DAG. La valeur par défaut est 16.
• worker_concurrency (Celery) : nombre de tâches que chaque worker Celery peut exécuter simultanément. La valeur par défaut est 16.
• scheduler_parsing_processes : nombre de processus utilisés par le planificateur pour analyser les fichiers DAG. La valeur par défaut est 2.
• parsing_processes (Airflow 2.3+) : similaire au précédent.
• dag_dir_list_interval : fréquence (en secondes) à laquelle le planificateur analyse le répertoire DAG pour détecter de nouveaux fichiers.

Point de départ pour le dimensionnement

Pour une configuration modeste avec quelques dizaines de DAG et des durées de tâches modérées, les valeurs de départ ressemblent souvent à :

[core]
parallelism = 32
dag_concurrency = 16
max_active_runs_per_dag = 16

[celery]
worker_concurrency = 8

Mais ces valeurs dépendent de votre matériel et de votre charge de travail. Une approche courante consiste à définir worker_concurrency en fonction du CPU et de la mémoire disponibles par worker. Par exemple, si chaque tâche utilise environ 0,5 cœur CPU et 1 Go de RAM, et que votre worker dispose de 4 cœurs CPU et de 16 Go de RAM, alors une worker_concurrency sûre serait min(4/0,5, 16/1) = 8 tâches.

Modifier la configuration en toute sécurité

1. Sauvegardez votre airflow.cfg actuel.
2. Modifiez un paramètre à la fois.
3. Redémarrez le composant affecté (planificateur, worker, etc.).
4. Surveillez les erreurs et les changements de performance.
5. Documentez le changement et son effet.

Par exemple, pour augmenter le parallelism global de 32 à 48, modifiez airflow.cfg :

[core]
parallelism = 48

Puis redémarrez le planificateur :

sudo systemctl restart airflow-scheduler

Vérifiez que la nouvelle valeur est active :

airflow config get-value core parallelism

Sortie :

48

Capacité de la base de données et du courtier

La base de données de métadonnées est souvent le goulot d'étranglement caché. À mesure que le nombre de DAG et le volume de tâches augmentent, le nombre de requêtes de base de données augmente. Surveillez l'utilisation des connexions et la latence des requêtes. Si vous constatez un CPU élevé ou des requêtes lentes, envisagez :

• Augmenter la taille du pool de connexions de base de données (sql_alchemy_pool_size dans la section [database]). La valeur par défaut est 5, mais peut devoir être plus élevée.
• Ajouter des index (Airflow gère son propre schéma ; évitez les modifications manuelles sauf si nécessaire).
• Augmenter les ressources de la base de données ou passer à un service géré.

Pour Celery, le courtier (Redis/RabbitMQ) doit gérer le trafic de messages. Surveillez la mémoire du courtier et le nombre de connexions. Si vous utilisez Redis, définissez maxmemory et une politique d'éviction appropriée. Assurez-vous que le courtier n'est pas un point de défaillance unique pour les pipelines critiques.

Exemple : ajustement des processus d'analyse du planificateur

Si vous avez de nombreux fichiers DAG et que l'analyse est lente, augmentez scheduler_parsing_processes. Supposons que vous ayez actuellement 2 processus d'analyse et que l'analyse DAG prenne 60 secondes, mais que votre boucle de planification puisse tolérer 30 secondes. Vous pouvez passer à 4 processus :

[scheduler]
parsing_processes = 4

Redémarrez le planificateur et observez le temps d'analyse :

airflow dags report

La sortie inclut les temps d'analyse. Vous devriez constater une durée d'analyse réduite si le CPU est disponible.

Vérification et diagnostics

Après les modifications de configuration, vérifiez que le système se comporte comme prévu. Utilisez des contrôles observables et des métriques.

Vérifier la santé du planificateur

Exécutez airflow dags list pour vous assurer que les DAG sont reconnus et ne sont pas cassés.

airflow dags list

Recherchez les DAG avec des erreurs. Une sortie saine montre chaque DAG avec un statut activé et aucune erreur d'importation.

Surveiller les tâches en cours et les files d'attente

Utilisez l'interface utilisateur ou l'interface en ligne de commande pour voir l'état des tâches. Pour l'interface en ligne de commande :

airflow tasks list <dag_id>

Pour vérifier le nombre de tâches en file d'attente :

airflow pools list

Si les tâches restent bloquées à l'état « en file d'attente », cela peut indiquer une capacité de worker insuffisante ou des limites de pool.

Vérification de la connexion à la base de données

Airflow fournit une commande pour vérifier la connectivité à la base de données :

airflow db check

Sortie attendue :

Connexion : OK

Si ce n'est pas OK, examinez la charge de la base de données et les identifiants.

Métriques à surveiller

Métriques clés pour vérifier les décisions de capacité :

• Temps d'attente des tâches : temps entre la planification de la tâche et le début. Un temps d'attente élevé signifie des créneaux de worker insuffisants ou des limites de concurrence élevées.
• Durée de la boucle du planificateur : si constamment supérieure à 60 secondes, le planificateur peut être surchargé.
• Temps d'analyse des DAG : affecte la réactivité du planificateur.
• Temps de requête de la base de données : les requêtes lentes peuvent retarder les mises à jour d'état.
• Utilisation du CPU et de la mémoire des workers : si les workers sont saturés, réduisez la concurrence ou faites évoluer horizontalement.

Exemple de scénario de vérification

Supposons que vous ayez augmenté parallelism à 48. Après redémarrage, exécutez un test de charge avec un DAG qui lance de nombreuses tâches. Utilisez airflow tasks test pour une seule tâche, ou déclenchez une exécution de DAG :

airflow dags trigger example_dag -r test_run

Surveillez ensuite avec airflow dags list-runs -d example_dag et vérifiez que les tâches passent de l'état « en file d'attente » à « en cours » puis « réussite ». Dans l'interface utilisateur, observez le graphique « Gantt » pour voir le chevauchement des tâches et les lacunes de planification.

Si vous voyez de nombreuses tâches en file d'attente mais peu en cours d'exécution, vous avez peut-être atteint les limites de worker_concurrency. Consultez les journaux des workers pour les messages « No free slots ».

Pièges courants et comment les éviter

De nombreuses équipes rencontrent des problèmes similaires lors de la mise à l'échelle d'Airflow. Voici les pièges les plus fréquents, pourquoi ils surviennent et comment les éviter ou s'en remettre.

1. Surcharge de la base de données de métadonnées

Pourquoi cela arrive : augmenter parallelism ou les processus d'analyse du planificateur sans tenir compte de la capacité de la base de données entraîne un flot de connexions et de requêtes. La base de données devient un goulot d'étranglement, provoquant une instabilité du planificateur et des ralentissements de l'interface utilisateur.

Comment éviter : surveillez le CPU, les connexions et la latence de la base de données. Augmentez prudemment sql_alchemy_pool_size (notez le nombre maximal de connexions que votre base de données prend en charge). Utilisez le regroupement de connexions et envisagez des réplicas de lecture pour le serveur Web si nécessaire.

Récupération : réduisez les paramètres de concurrence, augmentez les ressources de la base de données ou désactivez temporairement les DAG lourds. Utilisez airflow db check pour vérifier la connectivité.

2. Ignorer les limites de ressources des workers

Pourquoi cela arrive : définir worker_concurrency trop élevé en se basant uniquement sur le CPU tout en ignorant la mémoire entraîne des kills hors mémoire ou un swapping sévère. Les tâches échouent alors de manière inattendue.

Comment éviter : calculez la concurrence en fonction du CPU et de la mémoire par tâche. Utilisez des définitions de tâches conscientes des ressources (par exemple, resources={'cpu': 0.5, 'memory': '1GB'}) et surveillez l'utilisation réelle. Envisagez d'utiliser KubernetesExecutor pour une allocation fine des ressources.

Récupération : baissez worker_concurrency, ajoutez plus de workers ou optimisez le code des tâches pour utiliser moins de ressources.

3. Sous-estimer la charge du planificateur

Pourquoi cela arrive : à mesure que le nombre de DAG augmente, l'analyse et la planification consomment plus de CPU et de mémoire. Un planificateur unique peut devenir un goulot d'étranglement, provoquant un retard dans l'exécution des tâches.

Comment éviter : surveillez la durée de la boucle du planificateur et le temps d'analyse. Augmentez parsing_processes si le CPU est disponible, ou exécutez plusieurs planificateurs (Airflow 2.3+ le permet) avec une base de données partagée.

Récupération : augmentez les ressources du planificateur, réduisez la complexité de l'analyse des DAG (par exemple, utilisez la sérialisation des DAG) ou répartissez les DAG entre les planificateurs.

4. Négliger la capacité du courtier

Pourquoi cela arrive : Celery utilise un courtier (Redis/RabbitMQ) pour stocker les messages. Un volume de tâches élevé peut épuiser la mémoire du courtier, entraînant une perte de messages ou des déconnexions de workers.

Comment éviter : surveillez la mémoire du courtier et les connexions. Définissez un maxmemory approprié pour Redis et utilisez result_backend pour les grandes charges utiles. Assurez-vous que le courtier est en cluster pour une haute disponibilité.

Récupération : augmentez la mémoire du courtier, réduisez la taille des messages ou purgez les anciens messages (avec prudence). Redémarrez les workers si les connexions sont interrompues.

5. Absence de surveillance ou de base de référence

Pourquoi cela arrive : les équipes ignorent la surveillance et apportent des modifications de configuration à l'aveugle, ce qui conduit à un comportement imprévisible.

Comment éviter : mettez en place des métriques StatsD/Prometheus dès le départ. Établissez des métriques de référence pour votre charge de travail. Utilisez des tableaux de bord pour visualiser les métriques clés.

Récupération : implémentez la surveillance immédiatement. Utilisez les données historiques des journaux pour reconstruire la base de référence si possible.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle lors des revues d'exploitation régulières et avant d'apporter des modifications.

Vérifications quotidiennes

• [ ] Tous les composants Airflow fonctionnent (serveur Web, planificateur, workers).
• [ ] Aucune erreur critique dans les journaux.
• [ ] Profondeur de la file d'attente des tâches dans la plage attendue.
• [ ] Nombre de connexions et latence de la base de données normaux.

Vérifications hebdomadaires

• [ ] Examiner les DAG et tâches lents ; identifier les goulots d'étranglement.
• [ ] Vérifier les temps d'analyse des DAG ; rechercher des fichiers DAG inefficaces.
• [ ] Surveiller l'espace disque sur les workers et la base de données.
• [ ] Purger les anciens journaux si nécessaire (airflow db clean).

Revue mensuelle de capacité

• [ ] Collecter les métriques : CPU moyen et pic, mémoire, tâches par jour.
• [ ] Comparer au mois précédent ; identifier les tendances.
• [ ] Estimer la croissance : nouveaux DAG, volume de données accru.
• [ ] Planifier la mise à l'échelle : ajuster la concurrence, ajouter des workers, mettre à niveau le matériel.
• [ ] Examiner les paramètres de configuration par rapport à l'utilisation réelle.

Liste de contrôle de gestion des changements

Avant de modifier les paramètres liés à la capacité :

• [ ] Documenter les métriques de base actuelles.
• [ ] Identifier le paramètre spécifique à modifier et la justification.
• [ ] Définir un résultat attendu clair (par exemple, réduire le temps d'attente de 20 %).
• [ ] Planifier les étapes de retour en arrière.
• [ ] Effectuer le changement dans une fenêtre contrôlée si possible.
• [ ] Après le changement, surveiller pendant au moins 24 heures.
• [ ] Enregistrer les résultats et mettre à jour le manuel d'exploitation.

Cadre de décision pour la mise à l'échelle

Lorsque les métriques indiquent un goulot d'étranglement, envisagez ces options :

Testez toujours les changements dans un environnement de préproduction si possible.

Conclusion

La planification de capacité pour Apache Airflow est un processus continu qui nécessite de comprendre votre charge de travail, de surveiller les métriques clés et d'apporter des ajustements progressifs. Commencez par un inventaire approfondi des versions, de la topologie et de la configuration actuelle. Ensuite, modifiez les paramètres de capacité par petites étapes mesurables tout en surveillant l'impact. Vérifiez les changements avec des commandes de diagnostic et des métriques concrètes, et préparez-vous aux modes de défaillance avec des plans de retour en arrière. Adoptez une liste de contrôle opérationnelle régulière pour maintenir votre déploiement aligné sur la demande.

En suivant les exemples pratiques de ce guide, vous pouvez éviter les pièges courants tels que la surcharge de la base de données et la contention des workers, en vous assurant que votre cluster Airflow évolue en douceur à mesure que vos pipelines de données se développent. N'oubliez pas que l'objectif n'est pas de surprovisionner mais de maintenir un système équilibré qui fournit une orchestration fiable de manière rentable.