Checklist des opérations de production Apache Airflow (avec exemples pratiques)

Intro

Cette version française explique Apache Airflow production operations checklist with practical examples avec le même objectif pratique que l article source : aider le lecteur à comprendre le contexte, les décisions à prendre et les points à vérifier avant de passer à l action.

Apache Airflow devient fiable en production lorsqu'on le traite comme un service critique : configuration intentionnelle, signaux de santé mesurables et entraînement à la reprise. Cette Apache Airflow checklist propose des étapes concrètes et des exemples copiables pour renforcer la plateforme sur la configuration, le monitoring, l'Apache Airflow maintenance, les sauvegardes, les mises à niveau, la sécurité et la performance. Un flux de travail par étapes réduit le risque, limite les régressions et permet un pilote contrôlé avant de monter en charge.

Workflow global

Adoptez un flux par étapes pour vos Apache Airflow operations :

1. Planifier

• Définir des objectifs de disponibilité (SLO) pour le scheduler et les DAGs critiques.
• Documenter les dépendances de données et les quotas des systèmes externes.

1. Configurer

• Appliquer des valeurs durcies dans airflow.cfg et les variables d'environnement.
• Créer pools, connexions, variables et secrets.

1. Valider

• Parser les DAGs de façon non interactive et échouer vite en cas d'erreur d'import.
• Dry-run des DAGs critiques et prouver l'idempotence des tâches.

1. Observer

• Émettre des métriques, centraliser les logs et définir des alertes avec seuils clairs.
• Surveiller saturation du scheduler/worker, temps de parsing et files de tâches.

1. Maintenir

• Faire tourner les clés, purger les anciens logs et XComs, archiver l'historique.
• Exécuter des DAGs de vérification périodiques pour tester connectivité et alertes.

1. Améliorer

• Trier les motifs d'échec et les DAGs lents.
• Ajuster pools, retries et schedules sur la base d'évidences.

Checklist de configuration de production

Appliquez ces réglages avant la montée en charge. Adaptez-les à votre environnement.

Paramètres de base (airflow.cfg)

[core]
executor = CeleryExecutor            # ou KubernetesExecutor
load_examples = False
fernet_key = YOUR_32_BYTE_BASE64_KEY
sql_alchemy_conn = postgresql+psycopg2://airflow:*****@db:5432/airflow
parallelism = 64                     # slots globaux
max_active_tasks_per_dag = 16
max_active_runs_per_dag = 1

[logging]
remote_logging = True
remote_base_log_folder = s3://your-bucket/airflow-logs
logging_level = INFO

[scheduler]
min_file_process_interval = 30
max_tis_per_query = 256
scheduler_heartbeat_sec = 5
parsing_processes = 4

[metrics]
statsd_on = True
statsd_host = metrics.local
statsd_port = 8125

[email]
email_backend = airflow.utils.email.send_email_smtp

[webserver]
rbac = True
expose_config = False

Conseils :

• Définir fernet_key et utiliser un secrets backend pour connexions et variables.
• Garder max_active_runs_per_dag bas pour les DAGs lourds afin d'éviter l'effet « meute ».
• Activer remote_logging pour centraliser les logs des tâches.

Pools et files

Les pools protègent les systèmes partagés de la surcharge.

# Exemple : limiter les requêtes vers l'entrepôt de données à 5 tâches
airflow pools set dw_pool 5 "Data warehouse concurrency"

Utilisez le pool dans les tâches :

from airflow.operators.python import PythonOperator

PythonOperator(
    task_id="load_dw",
    python_callable=load_fn,
    pool="dw_pool",
)

Valeurs par défaut sensées pour les DAGs

from datetime import datetime, timedelta
from airflow import DAG
from airflow.operators.python import PythonOperator

default_args = {
    "owner": "data-eng",
    "depends_on_past": False,
    "retries": 2,
    "retry_delay": timedelta(minutes=5),
    "email_on_failure": True,
    "email": ["[email protected]"],
}

dag = DAG(
    dag_id="example_daily_etl",
    default_args=default_args,
    start_date=datetime(2024, 1, 1),
    schedule_interval="0 2 * * *",
    catchup=False,
    max_active_runs=1,
    tags=["etl"],
)

PythonOperator(
    task_id="extract",
    python_callable=extract_fn,
    dag=dag,
    pool="dw_pool",
)

Fiabilité de la base de données

• Utiliser une base Postgres managée avec sauvegardes automatiques et limites de connexions.
• Configurer la taille du pool de connexions et des sondes de santé.
• Isoler la base de métadonnées Airflow des charges analytiques lourdes.

Monitoring et alerting

Mesurez ce qui compte et alertez sur des symptômes actionnables.

Health checks

• Sonder les endpoints de santé du webserver et du scheduler toutes les 30 s.
• Alerter si le heartbeat du scheduler s'arrête, ou si l'âge des tâches en file dépasse le SLO.

Métriques à collecter

• Scheduler : dag_parsing.errors, dag.parsing.time, scheduler.heartbeat.
• Cycle de vie des tâches : tasks.queued, tasks.running, tasks.failed, tasks.duration.
• Saturation exécuteur/workers : usage des pools, concurrence workers, longueur des files.
• Résultats des DAGs : taux de succès par DAG, nombre de retries, SLA manquées.

Seuils d'exemple :

• Alerter si tasks.failed pour un DAG > 3 en 15 minutes.
• Alerter si l'âge d'une tâche en file > 10 minutes pour les DAGs critiques.
• Alerter si dag.parsing.time p95 > 2 s ou si les erreurs d'import augmentent.

Logs centralisés

Conserver 14 à 30 jours de logs « chauds »; archiver les plus anciens vers un objet storage. Inclure run_id, try_number et task_id pour la corrélation.

Routage des alertes

• Orienter les alertes critiques vers l'astreinte (paging).
• Les non-critiques vers chat ou email.
• Inclure run_id, statut des dépendances amont et étapes de remédiation suggérées.

Opérations et maintenance

Établissez des routines prévisibles.

Hebdomadaire

• [ ] Revoir les DAGs les plus en échec et les tâches les plus retentées.
• [ ] Purger les XComs de plus de 30 jours.
• [ ] Vérifier que les pools reflètent les limites aval actuelles.
• [ ] Contrôler les erreurs de parsing et les temps d'import.

Mensuel

• [ ] Faire tourner les clés de service et fernet_key si la politique l'exige.
• [ ] Archiver les logs plus anciens que la fenêtre de rétention.
• [ ] Lancer VACUUM/ANALYZE si applicable.
• [ ] Auditer les rôles Airflow et les accès utilisateurs.

Commandes utiles

# Lister les erreurs d'import sans exécuter
airflow dags list-import-errors

# Rejouer une tâche spécifique en sécurité (exemple)
airflow tasks clear -s 2024-07-01 -e 2024-07-01 example_daily_etl load --reset-dagruns

# Nettoyage XCom via script de maintenance (exemple)
python cleanup_xcoms.py --older-than-days 30

Sauvegardes et reprise après sinistre

Sauvegardez trois éléments : base de métadonnées, code des DAGs, et logs. Testez la restauration.

Plan de sauvegarde

• Base de métadonnées : plein quotidien, WAL/incrémental toutes les 5-15 minutes.
• Référentiel de DAGs : contrôle de version + snapshot nocturne.
• Logs : archivage vers objet storage avec règles de cycle de vie.

Exemple Postgres

pg_dump -Fc -h db -U airflow airflow > airflow_$(date +%F).dump

Exercices de reprise

• Trimestriel : restaurer la base sur une nouvelle instance et pointer un Airflow de test dessus.
• Vérifier le chargement des DAGs/connexions et que backfill/replay fonctionne.
• Définir RPO/RTO et vérifier que les sauvegardes les respectent.

Mises à niveau et gestion des changements

Traitez les upgrades comme des changements planifiés avec garde-fous.

Checklist

• [ ] Lire les release notes du core et des provider packages.
• [ ] Geler les versions; mettre à niveau les providers avec Airflow quand possible.
• [ ] Lancer les migrations DB d'abord en staging.
• [ ] Valider l'import des DAGs et dry-run des DAGs critiques.
• [ ] Sauvegarder base de métadonnées et DAGs avant l'upgrade.
• [ ] Prévoir un rollback (versions et snapshot DB).

Séquence type

1. Geler les versions actuelles et sauvegarder la DB.
2. Mettre à niveau les paquets Airflow.
3. Exécuter airflow db upgrade.
4. Démarrer seulement le scheduler; observer logs et métriques.
5. Démarrer les workers; surveiller files et échecs.
6. Promouvoir si stable; sinon rollback.

Sécurité et contrôle d'accès

Réduisez l'exposition et protégez les identifiants.

• Activer RBAC et appliquer le moindre privilège.
• Désactiver expose_config et restreindre l'accès webserver au réseau de confiance.
• Utiliser un secrets backend pour connexions et variables; éviter le clair.
• Imposer TLS pour l'UI et la base de métadonnées.
• Journaliser les actions utilisateurs pour audit.
• Valider les entrées des DAGs; ne jamais faire confiance aux paramètres externes sans contrôle.

Performance et montée en charge

Évitez les arriérés et les oscillations.

Scheduler

• Augmenter max_tis_per_query pour réduire les allers-retours DB (tester prudemment).
• Aligner parsing_processes sur les CPUs disponibles.
• Surveiller dag.parsing.time et les erreurs d'import.

Workers et exécuteurs

• Dimensionner la concurrence des workers; ne pas saturer les systèmes aval.
• Utiliser des pools pour les services partagés; ajuster selon erreurs et retries.
• Préférer les opérateurs « deferrable » pour les attentes longues afin de libérer des slots.

Conception des DAGs

• Éviter des milliers de tâches par run; regrouper en batchs.
• Limiter le backfill via max_active_runs_per_dag et commencer petit.
• Régler retries et retry_delay en fonction des SLA aval.

Base de données

• Activer le pooling de connexions; suivre nombre de connexions et requêtes lentes.
• VACUUM/ANALYZE périodiques pour stabiliser les plans de requêtes.

Pièges de production courants et correctifs

Problème : tempêtes de rattrapage après déploiement

• Cause : nouveau DAG avec start_date ancien et catchup=True.
• Correctif : catchup=False pour jobs streaming/nearline; si backfill requis, exécuter par fenêtres contrôlées.

Problème : gonflement des XComs

• Cause : payloads volumineux poussés en XCom.
• Correctif : stocker les gros objets ailleurs et passer des références; purger les anciens XComs.

Problème : explosion de tâches dynamiques

• Cause : mapping trop granulaire.
• Correctif : regrouper en lots; utiliser pools et max_active_tasks_per_dag.

Problème : parsing lent des DAGs

• Cause : imports lourds ou appels réseau au parse-time.
• Correctif : déplacer l'I/O dans l'exécution de l'opérateur; mettre en cache la config; alléger le code de parsing.

Problème : capteurs instables et timeouts

• Cause : poke_interval court ou timeouts serrés.
• Correctif : augmenter poke_interval; utiliser des capteurs deferrable; définir des timeouts et retries sensés.

Problème : ratés de planification (misfires) et dérive

• Cause : durées de tâches supérieures à l'intervalle de schedule.
• Correctif : augmenter l'intervalle ou découper les tâches; max_active_runs_per_dag=1.

Plan pilote local

Démarrez avec un seul DAG peu risqué et un objectif mesurable.

Objectif pilote

• Prouver que le monitoring, les alertes et la reprise de base fonctionnent pour un chemin critique.

Périmètre

• Un DAG quotidien, source non critique, 2-3 tâches.

Étapes

1. Implémenter le DAG avec pools, retries et email_on_failure.
2. Ajouter des métriques et vérifier leur présence dans le dashboard.
3. Provoquer un succès et un échec contrôlé; vérifier des alertes avec run_id et task_id.
4. Pratiquer la reprise : nettoyer une tâche en échec et relancer; vérifier l'idempotence.
5. Consigner les résultats et ajuster seuils ou tailles de pools.

Critères de succès

• Alertes < 2 minutes après l'échec.
• Médiane de durée dans la cible; pas d'accumulation en file.
• Temps de reprise sous le SLO convenu.

Conclusion

Des Apache Airflow best practices simples - configuration disciplinée, signaux de santé visibles, routines de maintenance et exercices de reprise - améliorent durablement la fiabilité d'Apache Airflow production. Servez-vous de cette Apache Airflow checklist pour durcir les réglages clés, surveiller les bonnes métriques, sauvegarder l'essentiel et ajuster pour un flux stable. Lancez un pilote étroit, mesurez, puis appliquez les mêmes pratiques à l'échelle. Au besoin, coordonnez avec vos écosystèmes de data orchestration (par ex. Apache Spark, NiFi, Apache Hop) et votre Python automation pour un ensemble cohérent.