Maestro : l’orchestrateur de workflows de Netflix

• Maestro : l’orchestrateur de workflows de Netflix

• TL;DR

  • Netflix a publié le code source de Maestro
  • Il est possible de commencer via le dépôt GitHub, et l’équipe demande de mettre une étoile si vous trouvez le projet utile

• Qu’est-ce que Maestro ?

  • Maestro est un orchestrateur de workflows généraliste et scalable horizontalement, conçu pour gérer des workflows à grande échelle
  • Il gère l’ensemble du cycle de vie de workflows tels que les pipelines de données et les pipelines d’entraînement de modèles de machine learning
  • Les utilisateurs peuvent empaqueter leur logique métier sous différents formats, notamment des images Docker, des notebooks, des scripts bash, du SQL et du Python
  • Contrairement aux orchestrateurs de workflows traditionnels qui ne prennent en charge que les DAG (Directed Acyclic Graph), Maestro prend en charge à la fois les workflows acycliques et cycliques, et inclut plusieurs patterns réutilisables comme les boucles foreach, les sous-workflows et les branchements conditionnels

• Le parcours avec Maestro

  • Des centaines de milliers de workflows ont été migrés avec succès avec un minimum d’interruptions pour les utilisateurs
  • Au cours de l’année écoulée, le nombre de jobs exécutés a augmenté de 87,5 %, avec une moyenne de 500 000 jobs exécutés par jour

• Scalabilité et polyvalence

  • Maestro est un orchestrateur de workflows entièrement managé qui fournit du Workflow-as-a-Service à des milliers d’utilisateurs finaux, d’applications et de services chez Netflix
  • Il prend en charge divers cas d’usage de workflows, notamment les pipelines ETL, les workflows ML et les pipelines de tests AB
  • Netflix considère qu’un orchestrateur unique doit prendre cela en charge, car ses tables de données résident dans un entrepôt de données unique

• Présentation de Maestro

  • Il utilise des définitions de workflows décrites au format JSON
  • Il combine des champs fournis par l’utilisateur et des champs gérés par Maestro pour former une définition d’orchestration à la fois souple et puissante
  • Les définitions de workflows se composent de propriétés et de workflows versionnés
  • Les propriétés incluent des informations sur l’auteur et le propriétaire, ainsi que des paramètres d’exécution
  • Les workflows versionnés incluent un identifiant unique, un nom, une description, des tags, des paramètres de timeout et un niveau de priorité

• Stratégies d’exécution des workflows

  • Stratégie d’exécution séquentielle : exécute les workflows un par un dans l’ordre FIFO
  • Stratégie d’exécution séquentielle stricte : bloque l’exécution en cas d’erreur bloquante et nécessite une résolution manuelle de l’erreur
  • Stratégie d’exécution du premier uniquement : retire les nouvelles instances de workflow de la file d’attente jusqu’à la fin du workflow en cours d’exécution
  • Stratégie d’exécution du dernier uniquement : exécute uniquement le workflow déclenché le plus récemment et arrête les instances déjà en cours d’exécution
  • Stratégie d’exécution parallèle avec limite de concurrence : exécute plusieurs instances de workflow en parallèle selon une limite de concurrence prédéfinie

• Prise en charge des paramètres et du langage d’expression

  • La prise en charge des paramètres dynamiques et de l’injection de code améliore fortement la flexibilité et le caractère dynamique des workflows
  • Un parseur de langage d’expression personnalisé a été développé pour répondre aux enjeux de sécurité et de sûreté
  • Simple and Safe Expression Language (SEL) : un langage d’expression simple et sûr développé pour traiter les risques liés à l’injection de code
  • Paramètres de sortie : les exécutions utilisateur peuvent renvoyer des paramètres de sortie vers le système
  • Workflows paramétrés : ils sont initialisés étape par étape à l’exécution en fonction de paramètres définis par l’utilisateur

• Patterns d’exécution des workflows

  • Prise en charge de Foreach : utilisée pour exécuter de façon répétée la même tâche avec des paramètres différents
  • Prise en charge des branchements conditionnels : exécute les étapes suivantes uniquement lorsque certaines conditions sont remplies
  • Prise en charge des sous-workflows : permet de partager des fonctionnalités communes entre plusieurs workflows

• Runtime des étapes et paramètres d’étape

  • Interface de runtime des étapes : interface qui décrit un job au moment de l’exécution
  • Fusion des paramètres d’étape : injecte des paramètres de runtime et des tags avant l’exécution d’une étape afin de contrôler dynamiquement son comportement

• Dépendances entre étapes et signaux

  • Les dépendances entre étapes permettent d’exprimer les dépendances d’exécution
  • Les signaux sont des fragments de message qui transmettent des informations, y compris des valeurs de paramètres

• Points d’arrêt

  • Il est possible de définir des points d’arrêt sur les étapes du workflow, de manière similaire aux points d’arrêt au niveau du code
  • Lorsqu’un point d’arrêt est atteint, l’étape passe à l’état "en pause" et la progression dans le graphe du workflow s’arrête jusqu’à ce que l’utilisateur la relance manuellement

• Timeline

  • Elle capture tous les événements importants, y compris la timeline d’exécution des étapes
  • Elle est utile pour le débogage et fournit une visibilité sur l’état des étapes

• Politique de retry

  • Une politique de retry est prise en charge pour les étapes qui atteignent un état terminal à la suite d’un échec
  • Elle distingue les retries dus à des erreurs de plateforme de ceux dus à des conditions définies par l’utilisateur

• Vue agrégée

  • Il est possible de voir l’état agrégé de toutes les étapes d’une instance de workflow
  • L’état agrégé est calculé en combinant les données de runtime de l’exécution en cours avec les agrégations de base

• Rollup

  • Fournit un résumé de haut niveau d’une instance de workflow
  • Détaille l’état de chaque étape ainsi que le nombre d’étapes dans chaque état

• Publication d’événements Maestro

  • Génère des événements et les publie vers des systèmes externes lorsqu’une définition de workflow, une instance de workflow ou une instance d’étape change
  • Les événements sont distingués entre événements internes et événements externes

• Bien démarrer avec Maestro

  • Maestro a été largement utilisé chez Netflix, et son code source est désormais publié
  • Le code est disponible dans le dépôt GitHub, et l’équipe demande d’ouvrir une issue GitHub pour toute question ou remarque

• Remerciements

  • Des remerciements sont adressés aux membres de l’équipe ayant contribué au projet Maestro ainsi qu’aux collègues de Netflix

Le résumé de GN⁺

• Maestro est un orchestrateur conçu pour gérer les workflows à grande échelle de Netflix et prend en charge la logique métier sous de nombreux formats
• Les paramètres dynamiques et l’injection de code améliorent fortement sa flexibilité et son caractère dynamique
• Il propose diverses stratégies et patterns d’exécution pour définir et gérer facilement des workflows complexes
• Il est adapté au traitement d’une source de données unique comme l’entrepôt de données de Netflix
• Parmi les autres orchestrateurs offrant des fonctionnalités similaires figurent Apache Airflow et Prefect

[GN⁺]

Commentaire Hacker News

• Impressionné par les blogs techniques d’entreprise et les systèmes internes, mais a fini par comprendre que le code est une dette

  • Préfère utiliser de l’open source, car il faut maintenir le code et y ajouter des fonctionnalités
  • Tout code qui n’est pas crucial pour l’activité est un gaspillage de ressources

• Se demande combien d’itérations sont nécessaires avant que les ingénieurs soient satisfaits d’une solution de workflow

  • Netflix, Uber et Amazon ont tous construit plusieurs solutions
  • Les ingénieurs semblent attirés par l’idée de créer des moteurs de workflow

• Avis du fondateur de Windmill.dev

  • Maestro et Windmill ont beaucoup de points communs
  • Principales différences :
    • Windmill est écrit en Rust
    • Maestro utilise CockroachDB, tandis que Windmill utilise son propre algorithme de sharding
    • Différence de licence : Maestro est sous Apache 2.0, Windmill sous AGPL
    • Par rapport à Maestro, soutenu par Netflix, Windmill est une petite entreprise
    • Maestro manque de documentation pour l’auto-hébergement et d’une UI

• Retour d’expérience avec Activebatch

  • Activebatch offre un environnement d’automatisation puissant avec une simple base MS SQL et une interface GUI Windows
  • Airflow et les autres concurrents open source sont complexes
  • Il est dommage qu’Activebatch ne soit pas plus largement utilisé à cause de son modèle de vente orienté entreprise

• Confusion autour de l’utilisation de Netflix/Conductor

  • Le projet semble utiliser Netflix/Conductor, mais il s’agit d’une version archivée
  • Il n’utilise pas Orkes Conductor

• Avis sur les orchestrateurs

  • L’open source et le développement public sont excellents, mais il existe déjà de nombreux orchestrateurs
  • Il est peu probable qu’une nouvelle option soit adoptée commercialement

• Comparaison avec Temporal

  • Maestro est écrit en Java, tandis que Temporal est écrit en Go

• Évaluation positive du projet

  • Aurait voulu construire quelque chose de similaire pour des projets de ML et de data engineering
  • A hâte de le tester

• Question sur les différences avec Conductor

  • A trouvé de nombreuses similitudes dans le code
  • Utilise JSON comme langage de définition des workflows

• Critique du contenu de l’article

  • Donne l’impression d’avoir été écrit par une IA
  • Il faudrait un exemple de workflow correspondant à un cas d’usage réel