Surveillance des SLAs et Profilage des Performances dans Airflow

L'un des grands défis rencontrés dans la gestion des flux de travail avec Airflow réside dans le suivi des SLA (Service Level Agreements), une fonctionnalité à la fois précieuse et problématique. Bien qu'Airflow fournisse un mécanisme natif pour surveiller les SLAs, la mise en œuvre de ce dernier laisse souvent à désirer, présentant des imperfections qui peuvent rendre la surveillance des SLAs difficile. Ce problème est bien connu dans la communauté, et certains utilisateurs considèrent cette fonctionnalité comme défectueuse. Si la surveillance des SLAs est cruciale pour vos processus, une approche recommandée consiste à utiliser un outil externe, tel que Healthchecks, qui offre des alertes suppressives via une API REST pour gérer ces accords. En l'associant à des opérateurs HTTP ou à de simples requêtes de rappels, il devient possible de garantir un système d'alerte SLA dynamique et résilient, mieux adapté aux exigences complexes des flux de travail.

L'optimisation continue d'Airflow passe également par la collecte de métriques supplémentaires, bien que parfois plus complexes à obtenir. Le temps de démarrage des tâches, par exemple, constitue un indicateur clé, notamment lorsque vous utilisez un exécuteur Kubernetes. Calculer la différence entre start_date et execution_date pour chaque instance de tâche permet d'identifier des goulets d'étranglement potentiels en dehors d'Airflow, notamment au niveau des ressources d'infrastructure ou des contraintes réseau. Le suivi des échecs de tâches et des tentatives de reprise est également crucial : une fréquence élevée de ces événements peut indiquer une instabilité de l'environnement ou des interactions problématiques avec d'autres services, et leur analyse permet de mieux comprendre les causes sous-jacentes.

Le temps de parsing des DAGs mérite également une attention particulière. Un temps de parsing élevé, souvent causé par des imports lourds ou des appels bloquants pendant le processus de parsing, peut avoir un impact considérable sur le respect des délais de planification des tâches. Le suivi de ce paramètre permet de détecter les problèmes de performance au niveau du planificateur, ce qui est essentiel pour maintenir des flux de travail rapides et efficaces.

Pour gérer plusieurs équipes ou utilisateurs dans un même déploiement Airflow, il existe des solutions comme l'exécuteur Celery, qui permet de répartir les tâches entre différents workers. Cependant, cette approche de partage de ressources peut conduire à des conflits si elle n'est pas soigneusement gérée. L'utilisation de mécanismes de queue pour diriger les tâches vers des workers spécifiques, accompagnée de politiques de sécurité locales pour chaque worker, peut offrir un certain niveau d'isolement. Néanmoins, des outils supplémentaires, comme des linters ou des hooks de pré-engagement, peuvent être nécessaires pour appliquer des règles de sécurité et éviter les collisions entre tâches de différents utilisateurs.

Comment assurer l'isolation multi-locataire dans Airflow : Une approche basée sur des rôles et des permissions

L’exécuteur Kubernetes d'Airflow est un outil puissant et hautement isolé, chaque processus s'exécutant dans son propre Pod. Cette configuration offre un environnement extrêmement sécurisé avec un minimum de configuration. Si l'isolation du travail est d'une importance capitale, l'exécuteur Kubernetes s'avère être l'option la plus simple et la plus sécurisée. Dans le cas où des contextes de sécurité spécialisés sont nécessaires, l'utilisation d'un remplacement de Pod et de sélecteurs de nœuds avec des taints ou des images spécifiques représente la meilleure approche. Cependant, l'architecture actuelle d'Airflow, qui inclut le planificateur et le déclencheur, ne permet pas de rendre ces composants multi-locataires de manière native. Ces composants auront toujours un accès complet aux DAGs et seront responsables de leur planification dans le DagBag. Si, pour une raison quelconque, vous avez besoin d'une isolation dans ces composants, la seule option est d'exploiter des déploiements Airflow supplémentaires.

Quant à l’interface Web d’Airflow, elle permet de mettre en place une forme de multi-locataire grâce à l’attribution de rôles et de permissions. Les utilisateurs peuvent être affectés à des rôles spécifiques, leur accordant ou restreignant l'accès à différents objets d'Airflow. Pour garantir un contrôle d'accès précis, Airflow offre un système de permissions qui se compose de noms d’objets (tels que DAG, Task, Variable, etc.) et de verbes (création, lecture, modification, suppression). Ces permissions sont ensuite appliquées à des rôles, et quand un utilisateur avec un rôle spécifique tente d'accéder à une ressource, il peut y accéder si ses permissions sont adéquates.

Pour structurer un environnement multi-locataire dans Airflow, il est essentiel de définir des rôles personnalisés en fonction des besoins organisationnels. Par exemple, dans une configuration avec plusieurs utilisateurs ayant des répertoires distincts contenant leurs propres DAGs, l’objectif est de veiller à ce qu'ils ne puissent pas accéder aux DAGs des autres utilisateurs via l'interface Web. Ce processus implique la création d'un rôle personnalisé, l'attribution de permissions et la gestion de l'accès via des scripts administratifs.

Un exemple de mise en œuvre de cette isolation via l'API Airflow pourrait ressembler à ceci :

python
Copy code
def __add_users(user_name, password, email, first_name='', last_name='', role='Public'):

    with get_application_builder() as appbuilder:
        role = appbuilder.sm.find_role(role)
        if appbuilder.sm.find_user(user_name):
            print(f"{user_name} already exist in the db")
            return
        user = appbuilder.sm.add_user(
            user_name, first_name, last_name, email, role, password
        )
def _add_users():
    users = [
        ("user_1", "user_1", "[email protected]"),
        ("user_2", "user_2", "[email protected]"),
    ]
    for u in users:
        __add_users(*u)

Ce code montre comment ajouter un utilisateur en utilisant les bibliothèques de base d'Airflow, avec un rôle par défaut « Public », qui restreint l'accès. Une autre approche consiste à utiliser des plugins d'authentification pour gérer la création d'utilisateurs de manière plus sécurisée.

python
Copy code
dag_bag = DagBag(os.path.join("dags", d))
for action in [READ, EDIT, CREATE, DELETE]:
    for d_id in dag_bag.dags.keys():
        perm: Permission | None = appbuilder.sm.create_permission(action, f"DAG:{d_id}")
        appbuilder.sm.add_permission_to_role(role, perm)

Cette configuration garantit que les utilisateurs auront un accès restreint et spécifique à leurs propres DAGs, sans interférer avec ceux des autres.

L'ajout de rôles et de permissions spécifiques au sein d'Airflow, ainsi que l'isolation via des Pods Kubernetes et une gestion fine des accès à l'interface Web, constitue une approche robuste pour assurer une séparation claire des environnements dans un cadre multi-locataire. Cela est particulièrement utile dans des scénarios où plusieurs équipes ou projets doivent coexister dans une même instance d'Airflow, tout en préservant la confidentialité et la sécurité des données et des processus.

Il est essentiel de noter que l'approche de multi-locataire ne se limite pas à la configuration de rôles et de permissions dans l'interface Web. L'isolation complète des utilisateurs requiert également une vigilance particulière sur la manière dont les DAGs sont chargés et gérés dans Airflow. En d'autres termes, une approche proactive, impliquant des stratégies de sécurité et de gestion des ressources en backend, s'avère indispensable pour garantir un environnement réellement sécurisé et isolé, notamment lorsque des déploiements multiples sont nécessaires pour répondre aux exigences d'isolement.