Maestro : l’orchestrateur de workflows de Netflix

 (netflixtechblog.com)
4 points par GN⁺ 2024-07-24 | 1 commentaires | Partager sur WhatsApp
  • Netflix a publié en open source Maestro, son orchestrateur scalable horizontalement pour les workflows Data/ML à grande échelle, et l’utilise déjà en interne après avoir migré des centaines de milliers de workflows avec un minimum d’interruptions
  • Contrairement aux orchestrateurs centrés sur les DAG, il gère à la fois des workflows acycliques et cycliques, avec des boucles foreach, des sous-workflows et des branchements conditionnels fournis comme patterns au niveau du moteur
  • Sur l’année écoulée, le nombre de jobs exécutés a augmenté de 87,5 % ; actuellement, le système exécute en moyenne chaque jour plusieurs milliers d’instances de workflow et environ 500 000 jobs, avec près de 2 millions de jobs terminés lors des journées les plus chargées
  • Les définitions basées sur JSON combinent stratégie d’exécution, paramètres, expressions SEL, signaux, points d’arrêt, timeline, politique de retry et rollup pour prendre en charge le contrôle opérationnel et le débogage
  • Dans un environnement comme celui de Netflix, où les tables de données sont regroupées dans un seul data warehouse, répartir les workflows sur plusieurs clusters augmente fortement les coûts de coordination et dégrade l’expérience utilisateur ; une architecture avec un orchestrateur unique chargé de l’ensemble des flux devient donc essentielle

Publication de Maestro et ampleur de son exploitation chez Netflix

  • Netflix a publié le code source de Maestro via le repository GitHub de Maestro
  • Maestro est un orchestrateur de workflows scalable horizontalement qui gère les workflows Data/ML à grande échelle, comme les pipelines de données et les pipelines d’entraînement de modèles de machine learning
  • Il gère l’ensemble du cycle de vie du workflow, du démarrage à la fin, en prenant en charge les retries, la mise en file d’attente et la répartition des jobs vers les moteurs de calcul
  • Les utilisateurs peuvent empaqueter leur logique métier sous différentes formes, notamment des images Docker, des notebooks, des scripts bash, du SQL et du Python
  • Après l’avoir présenté précédemment, Netflix a migré des centaines de milliers de workflows vers Maestro tout en minimisant les interruptions pour les utilisateurs
  • Échelle d’exploitation récente :
    • 87,5 % de hausse du nombre de jobs exécutés sur l’année écoulée
    • Plusieurs milliers d’instances de workflow exécutées chaque jour en moyenne
    • Environ 500 000 jobs exécutés par jour en moyenne
    • Près de 2 millions de jobs terminés lors des journées les plus chargées

Prendre en charge scalabilité et diversité avec un orchestrateur unique

  • Maestro est un orchestrateur entièrement managé qui fournit en interne chez Netflix du Workflow-as-a-Service à des milliers d’utilisateurs finaux, d’applications et de services
  • Il prend en charge les pipelines ETL, les workflows ML, les pipelines de tests AB et les pipelines de déplacement de données entre plusieurs stockages
  • Son architecture scalable horizontalement est conçue pour gérer à la fois un grand nombre de workflows et un grand nombre de jobs au sein d’un même workflow
  • Les workflows de Netflix sont étroitement interconnectés ; les répartir en petits groupes sur plusieurs clusters nécessiterait des mécanismes de coordination supplémentaires et dégraderait l’expérience utilisateur
  • Comme les tables de données résident dans un data warehouse unique, Netflix estime qu’un orchestrateur unique doit gérer tous les workflows qui y accèdent

Modèle de définition des workflows

  • Les définitions de workflows de Maestro sont rédigées au format JSON
  • La définition d’orchestration combine des champs fournis par l’utilisateur et des champs gérés par Maestro ; un exemple est disponible dans le wiki du repository Maestro
  • La définition d’un workflow se divise globalement en deux zones :
    • properties : inclut les informations d’auteur et de propriétaire ainsi que les paramètres d’exécution
    • versioned workflow : inclut les métadonnées du workflow et la définition du graphe
  • Les properties conservent des attributs clés comme les informations d’auteur et de propriétaire, la stratégie d’exécution et les paramètres de concurrence, même lorsque la version du workflow change
  • En cas de changement de propriétaire, le nouveau propriétaire peut reprendre la propriété du workflow existant sans créer une nouvelle version
  • Le versioned workflow inclut un identifiant unique, un nom, une description, des tags, des paramètres de timeout et un niveau de criticité low, medium ou high pour la priorisation
  • Toute modification du workflow crée une nouvelle version, et par défaut la version active ou la plus récente est utilisée
  • Un workflow est composé de steps, qui sont les nœuds du graphe défini par l’utilisateur
    • Un step peut représenter un job, un autre workflow via un subworkflow step, ou une boucle via un foreach step
    • Un step inclut un identifiant unique, un type de step, des tags, des paramètres d’entrée et de sortie, des dépendances, une politique de retry, un mode d’échec et des sorties de step
    • Le système prend en charge des politiques de retry configurables selon le type d’erreur

Run Strategy : contrôler l’ordre d’exécution

  • Maestro décide de lancer ou non une nouvelle instance de workflow à l’aide de run strategies prédéfinies

  • Sequential Run Strategy

    • C’est la stratégie par défaut, avec une exécution une par une dans l’ordre FIFO
    • Indépendamment du succès ou de l’échec de l’exécution précédente, l’instance suivante dans la file démarre dès qu’une instance atteint un état terminal comme success ou failed

  • Strict Sequential Run Strategy

    • L’exécution suit l’ordre de déclenchement, mais elle est bloquée si l’historique de l’instance précédente contient une blocking error
    • Les nouvelles instances restent dans la file jusqu’au redémarrage manuel de l’instance en échec ou jusqu’à sa levée de blocage
    • Cette stratégie est utile pour les workflows peu sensibles au temps mais critiques pour le métier

  • First-only Run Strategy

    • Les nouvelles instances ne sont pas conservées dans la file tant que le workflow en cours n’est pas terminé
    • S’il existe déjà une instance en cours, toute nouvelle instance entrant dans la file est supprimée, ce qui désactive de fait la mise en file d’attente
    • En évitant l’accumulation de nouvelles instances, cette stratégie aide à prévenir les problèmes d’idempotence

  • Last-only Run Strategy

    • Cette stratégie garantit que seule l’instance déclenchée la plus récemment est exécutée
    • Si une instance est déjà en cours, elle est interrompue et remplacée par l’instance nouvellement déclenchée
    • Elle est utile lorsque seules les données les plus récentes comptent, comme pour les workflows qui traitent à chaque fois le dernier snapshot complet d’une table

  • Parallel with Concurrency Limit Run Strategy

    • Plusieurs instances sont exécutées en parallèle dans la limite de concurrence prédéfinie
    • Cela permet de faire du fan-out et de répartir l’exécution pour traiter de grands volumes de données dans un temps imparti
    • Le backfill de données anciennes est un cas d’usage courant

Paramètres et expressions SEL

  • Dans Maestro, les paramètres servent à contrôler la logique d’exécution, à partager l’état entre le workflow et les steps, ainsi qu’entre steps amont et aval
  • Maestro prend en charge des paramètres dynamiques avec injection de code, ce qui permet de définir des workflows fortement paramétrés
  • L’injection de code peut toutefois créer des risques de sécurité et de stabilité
    • Si un utilisateur écrit une boucle infinie qui continue d’ajouter des éléments à un tableau, le serveur peut tomber en panne par OOM
    • Déplacer le code injecté dans la logique métier augmente la charge pour l’utilisateur et crée un couplage fort entre la définition du workflow et la logique métier
  • Pour atténuer ces risques, Netflix a développé son propre langage d’expression : SEL (Simple, Secure, and Safe Expression Language)
  • SEL suit la grammaire et la syntaxe des Java Language Specifications, mais n’en prend en charge qu’un sous-ensemble adapté aux cas d’usage de Maestro
  • SEL prend en charge les types de données des paramètres Maestro, la gestion des erreurs, le traitement des dates et heures, ainsi que des méthodes utilitaires prédéfinies
  • Pour garantir la stabilité, il inclut des contrôles d’exécution comme des limites sur les itérations de boucle, des vérifications de taille de tableau et des limites sur la taille mémoire des objets
  • La documentation SEL est disponible dans la documentation GitHub de Maestro

Paramètres de sortie et workflows paramétrés

  • Maestro permet, via une callable step execution, de renvoyer les résultats d’exécution utilisateur au système sous forme de paramètres de sortie
  • Les données de sortie sont transmises via la REST API de Maestro, sans que le runtime du step accède directement à la base de données de Maestro
  • Les workflows statiques sont simples, mais pour refléter de petites différences, il peut être nécessaire de dupliquer plusieurs fois le même workflow ; sans paramètres, ni le workflow ni les jobs ne peuvent partager leur état
  • Les workflows entièrement dynamiques sont difficiles à gérer et à supporter, et ils compliquent aussi le débogage, le troubleshooting et la réutilisation
  • Les workflows paramétrés sont initialisés au runtime step par step à partir de paramètres définis par l’utilisateur, ce qui offre à la fois de la flexibilité dans le contrôle à l’exécution et une bonne maintenabilité
  • La prise en charge des paramètres dans Maestro permet de créer des workflows paramétrés complexes, comme des pipelines de données de backfill

Modèles d’exécution de workflows au niveau du moteur

  • Maestro prend directement en charge dans le moteur des modèles communs de dataflow et de workflow
  • Cette prise en charge native par le moteur permet d’optimiser ces modèles et d’assurer une implémentation cohérente

  • Foreach

    • Le modèle foreach est modélisé à l’origine comme une étape dédiée dans la définition du workflow
    • Chaque itération de la boucle foreach est traitée en interne comme une instance de workflow distincte
    • L’exécution des étapes à l’intérieur du bloc de définition foreach, c’est-à-dire l’exécution du sous-graphe, est déléguée à une instance de workflow distincte
    • L’étape foreach surveille et agrège l’état des instances de workflow chargées de chaque itération
    • Il est souvent utilisé pour les backfills de données ou l’ajustement de modèles de machine learning, où la même tâche est exécutée avec des paramètres différents à chaque itération
    • Les utilisateurs n’ont pas besoin d’écrire directement des centaines de milliers d’itérations dans la définition du workflow, et il devient aussi moins nécessaire de créer un nouveau workflow lorsque la portée du foreach change

  • Conditional Branch

    • La branche conditionnelle permet d’exécuter les étapes suivantes uniquement lorsqu’une condition spécifique d’une étape amont est satisfaite
    • La condition est définie avec une expression SEL et évaluée à l’exécution
    • Il est possible de construire un flux qui effectue une opération de récupération après l’échec d’une étape de vérification d’audit, puis relance la tâche

  • Subworkflow

    • Le subworkflow permet à une étape de workflow d’exécuter un autre workflow, afin de partager des fonctionnalités communes entre plusieurs workflows
    • Cela permet de construire des graphes de workflow sous la forme de « workflow as a function »
    • Chez Netflix, on observe aussi des workflows complexes composés de centaines de subworkflows, qui traitent les données de centaines de tables en combinant des subworkflows fournis par plusieurs équipes
    • foreach, branche conditionnelle et subworkflow peuvent être combinés ensemble
    • Il est possible de traiter en boucle un ensemble de subworkflows
    • Il est possible d’exécuter des boucles foreach imbriquées
    • En combinant branche conditionnelle et subworkflow, on peut créer des workflows d’auto-récupération qui gèrent les erreurs et relancent automatiquement les tâches

Step Runtime et fusion des paramètres

  • Maestro utilise le step runtime pour décrire le travail au moment de l’exécution
  • L’interface step runtime définit deux types d’informations
    • un ensemble d’API de base qui contrôlent le comportement d’exécution d’une instance d’étape
    • une structure de données simple qui suit l’état du runtime de l’étape et le résultat de son exécution
  • Maestro fournit des implémentations comme foreach step runtime et subworkflow step runtime
  • Chaque implémentation définit sa propre logique pour les opérations start, execute et terminate
  • L’état du runtime sert à déterminer la transition d’état suivante de l’étape et à juger si elle a échoué ou si elle est terminée
  • Le résultat d’exécution contient les artefacts de l’étape et la timeline de son historique d’exécution, accessibles par les étapes suivantes

  • Step Parameter Merging

    • Maestro prend en charge l’injection de runtime parameters et de tags afin de contrôler dynamiquement le comportement des étapes
    • La map des paramètres d’étape est initialement vide, puis fusionnée dans l’ordre suivant
    • Default General Parameters : paramètres de base communs à toutes les étapes, comme workflow_instance_id, step_instance_uuid, step_attempt_id, step_id, utilisés comme valeurs réservées internes à Maestro et que l’utilisateur ne peut pas fournir
    • Injected Parameters : paramètres générés dynamiquement par le step runtime, pouvant varier selon le schéma propre à chaque type d’étape
    • Default Typed Parameters : paramètres par défaut liés à un type d’étape spécifique, comme loop_params et loop_index pour une étape foreach
    • Workflow and Step Info Parameters : informations d’identification liées à l’étape et au workflow, comme workflow_id
    • Undefined New Parameters : nouveaux paramètres d’étape définis par l’utilisateur au démarrage ou au redémarrage d’une instance de workflow
    • Step Definition Parameters : paramètres d’étape définis par l’utilisateur au moment de la définition
    • Run and Restart Parameters : valeurs fournies par l’utilisateur au démarrage ou au redémarrage pour écraser les paramètres déjà définis, fusionnées en dernier

Dépendances d’étape et signaux

  • Dans le graphe de workflow de Maestro, les étapes peuvent exprimer des dépendances d’exécution via des step dependencies
  • Les step dependencies spécifient des conditions liées aux données nécessaires à l’exécution d’une étape
  • Ces conditions sont généralement définies à partir de signaux
  • Un signal est un message qui contient des informations comme des valeurs de paramètres, et peut être publié par la sortie d’une étape ou par des systèmes externes comme SNS ou Kafka
  • Les signaux sont utilisés à la fois pour le modèle de trigger et pour le modèle de dépendance de signal de type publisher-subscriber
  • Une étape peut publier un signal de sortie afin de débloquer l’exécution de plusieurs étapes qui en dépendent
  • Une définition de signal inclut une liste de paramètres mappés, et Maestro peut effectuer un signal matching à partir d’une partie seulement des champs
  • Maestro prend en charge des signal operators comme < et > sur les valeurs des paramètres de signal
  • Netflix a construit plusieurs abstractions sur le concept de signal
    • Lorsqu’un workflow ETL met à jour une table et émet un signal, une étape de workflow aval qui dépend de ces données peut être exécutée
    • Le signal lineage permet d’explorer les anciennes instances de signal ainsi que les étapes de workflow qui ont publié ou consommé ce signal
    • Le signal trigger garantit l’exécution exactly-once pour les workflows qui s’abonnent à un signal unique ou à un ensemble de signaux joints
  • Comme les workflows ou les étapes ne s’exécutent que lorsque les conditions de signal spécifiées sont remplies, cela permet d’économiser des ressources

Débogage et visibilité d’exécution

  • Breakpoint

    • Maestro permet de définir des points d’arrêt sur les étapes d’un workflow
    • Lorsqu’une instance de workflow atteint une étape avec point d’arrêt, cette étape passe à l’état paused
    • La progression du graphe de workflow s’arrête jusqu’à ce que l’utilisateur la reprenne manuellement
    • Si plusieurs instances d’une même étape de workflow sont arrêtées sur un point d’arrêt, la reprise de l’une d’elles n’affecte que cette instance, tandis que les autres restent à l’état paused
    • Lorsque le point d’arrêt est supprimé, toutes les instances d’étape qui étaient bloquées reprennent
    • C’est utile pendant le développement initial d’un workflow pour inspecter l’exécution des étapes et les données produites
    • Dans le modèle foreach, si un point d’arrêt est défini sur une seule étape, toutes les itérations s’arrêtent sur cette étape pour permettre le débogage
    • Cela peut aussi servir à prendre en charge une intervention humaine pendant l’exécution ou une modification de l’état d’une étape en cours d’exécution

  • Timeline

    • Maestro inclut une timeline d’exécution des étapes, qui enregistre les événements majeurs, comme les changements de machine d’état et leurs raisons
    • Les événements d’exemple incluent des transitions comme Created et Evaluating params
    • Les step runtimes implémentés peuvent ajouter des événements à la timeline afin de présenter des informations d’exécution à l’utilisateur final
    • Un exemple de timeline est disponible dans sample-step-instance-failed.json

Nouvelle tentative, vue agrégée, rollup

  • Politiques de nouvelle tentative

    • Maestro prend en charge des politiques de nouvelle tentative pour les steps qui se terminent en état d’échec
    • Les utilisateurs peuvent configurer le nombre de nouvelles tentatives, le délai entre elles, des tentatives à intervalle fixe et une stratégie d’exponential backoff
    • Les nouvelles tentatives se divisent en deux types
    • platform retry : gestion des erreurs au niveau de la plateforme, indépendantes de la logique utilisateur
    • user retry : nouvelle tentative selon des conditions définies par l’utilisateur
    • Chaque type peut avoir sa propre politique de nouvelle tentative
    • Les nouvelles tentatives automatiques sont utiles pour traiter des erreurs temporaires pouvant être résolues sans intervention de l’utilisateur
    • Pour les steps non idempotents, il est possible de définir le nombre de nouvelles tentatives à 0 afin de les éviter

  • Vue agrégée

    • Comme une instance de workflow peut avoir plusieurs exécutions, l’utilisateur doit pouvoir voir l’état agrégé de tous les steps
    • La vue agrégée est calculée en fusionnant la vue agrégée de base avec l’état des steps de l’exécution en cours
    • Par exemple, si lors de la première exécution step1 et step2 réussissent, step3 échoue et step4 et step5 n’ont pas encore démarré, un redémarrage recommence à partir de step3, tandis que step1 et step2 peuvent être ignorés grâce à leur état de réussite précédent
    • Si tous les steps réussissent, la vue agrégée affiche l’état d’exécution de l’ensemble des steps

  • Rollup

    • Le rollup fournit un résumé de haut niveau d’une instance de workflow, en indiquant l’état de chaque step et le nombre de steps par état
    • Il agrège en dépliant les steps de l’instance actuelle ainsi que ceux des workflows non inline imbriqués, comme subworkflow et foreach
    • Si un workflow réussi comporte trois steps, dont l’un est un subworkflow de cinq steps, le rollup affichera 7 steps réussis
    • Dans le rollup, seuls les steps feuilles sont agrégés ; les autres steps sont traités comme des pointeurs vers le workflow concret
    • Les références aux steps non réussis sont également conservées afin de pouvoir accéder aux steps problématiques dans les workflows imbriqués
    • Le rollup agrégé est calculé en combinant les données d’exécution du run en cours avec le rollup de base
    • Le rollup d’un step subworkflow reflète directement le rollup de l’instance de subworkflow
    • Le rollup d’un step foreach combine le rollup de base des itérations, en excluant celles ciblées par le redémarrage lors d’une exécution précédente, avec le rollup des itérations en cours d’exécution
    • En raison de ce processus, le modèle de rollup est eventually consistent ; si des foreach imbriqués et des subworkflow s’enchaînent sur plusieurs niveaux, le calcul peut devenir complexe et récursif

Publication d’événements et intégrations externes

  • Lorsqu’une définition de workflow, une instance de workflow ou une instance de step change, Maestro génère un événement, le traite en interne puis le publie vers des systèmes externes
  • Les événements Maestro se divisent en événements internes et externes
    • internal event : suit les changements internes du cycle de vie des workflows, des instances de workflow et des instances de step, et est publié dans une file interne
    • external event : contient les informations de changement d’état de Maestro consommées par les services en aval, et est envoyé vers des files externes comme SNS ou Kafka
  • Le processeur d’événements Maestro s’abonne à la file interne pour récupérer les internal event, les traite selon leur type puis, si nécessaire, les convertit en external event
  • À la dernière étape, le notification publisher publie les événements externes pour que les services en aval puissent les consommer
  • Les services en aval sont majoritairement orientés événements, et les événements Maestro contiennent les messages nécessaires pour détecter les différents changements de Maestro
  • Les types de changement se répartissent largement en deux catégories
    • workflow change : actions au niveau du workflow, comme des modifications de la définition du workflow ou des properties
    • instance status change : transitions d’état d’une instance de workflow ou d’une instance de step

Comment démarrer

  • Le code de Maestro est disponible sur github.com/Netflix/maestro
  • Les questions, avis et commentaires peuvent être déposés via les GitHub issues du dépôt Maestro
  • Netflix espère que la scalabilité et la facilité d’usage offertes par Maestro permettront aussi d’accélérer le développement de workflows en dehors de Netflix

À lire aussi

1 commentaires

 
GN⁺ 2024-07-24
Avis sur Hacker News

  • Avant, j’étais impressionné par ce genre de blogs techniques d’entreprise et de systèmes internes propriétaires, mais ce n’est plus le cas. Parce que le code est une dette.
    Plutôt que de recréer des choses comme cron/Celery/Airflow, je préfère utiliser de l’open source éprouvé, avec un long historique de maintenance et d’améliorations. Quelqu’un doit bien maintenir, corriger les bugs et ajouter des fonctionnalités. Bien sûr, exception faite si cela s’accompagne d’une promotion et d’une hausse de salaire/RSU.
    Il faut comprendre que le code qui ne relève pas du cœur de métier qui rapporte de l’argent à l’entreprise détourne l’attention et consomme des ressources.

    • Je pense que ce billet de blog existe précisément pour cette raison. L’idée est de rendre ce logiciel open source afin de ne plus avoir à tout maintenir uniquement en interne.
      Ils l’ont créé parce qu’il répondait à un besoin que l’open source existant ne couvrait pas, et maintenant ils cherchent à le transformer à son tour en open source établi, pour continuer à l’utiliser tout en partageant la charge de maintenance. Comment ce type d’outil pourrait-il apparaître dès le départ autrement ? Quelqu’un doit bien le créer.
    • La vision selon laquelle « le code est une dette » est trop extrême, et elle est fortement liée à une façon de penser qui veut minimiser-maximiser tout ce qui existe à la manière d’un MBA.
      Heureusement qu’il y a des gens qui n’ont pas peur de créer de nouveaux systèmes et de pousser de nouvelles idées. Même du point de vue d’une entreprise, les solutions ordinaires et averses au risque ont leurs limites. Les entreprises les plus rentables sont souvent assez audacieuses techniquement.
      Le code n’est pas une dette : c’est ce qui fait tourner les rouages de l’entreprise.
    • L’open source établi est souvent le résultat de la publication d’outils internes par de grandes entreprises. Airflow, que tu cites directement, en est un bon exemple, et dans ce domaine Temporal aussi. Il faut bien que quelqu’un soit assez « stupide » pour créer quelque chose de nouveau.
    • L’expression « un long historique de maintenance et d’améliorations » porte en elle d’énormes présupposés.
      Je me demande si tu prévois aussi de contribuer toi-même à la communauté. Construire ou acheter est toujours un débat important, mais penser que, du côté de l’« achat », les coûts de maintenance et de fiabilité sont exactement nuls me paraît naïf.
    • La condition « ce qui n’est pas le cœur de métier de l’entreprise » est importante. Pour une équipe expérimentée dans un domaine où les performances comptent, le point de bascule où du code externe devient une dette de faible qualité/faible contrôle n’est pas si éloigné.

  • Je me demande combien d’itérations supplémentaires il faudra pour que les ingénieurs soient satisfaits des solutions de workflow. Avant Maestro, Netflix avait déjà plusieurs solutions comme Metaflow, Uber en a aussi construit plusieurs, et Amazon avait au moins une bonne dizaine de moteurs de workflow internes.
    Il est intéressant de voir que beaucoup de personnes, dans de nombreuses entreprises, veulent créer des moteurs de workflow. Ce n’est pas une critique de qui que ce soit ni de Netflix ; j’y vois plutôt une observation qui mérite une discussion légère.

    • Le problème, c’est que l’orchestration de workflows couvre un domaine extrêmement vaste. Les entreprises doivent résoudre plusieurs problèmes différents, si bien que toute solution devient un énorme produit doté de nombreuses fonctionnalités connexes et, en grandissant, tend à devenir un gros monolithe à la philosophie très affirmée. Résultat : presque personne n’est satisfait.
      En réalité, il y a cinq préoccupations centrales : la planification des ressources, la résolution des dépendances, une API/DSL pour créer des tâches et des workflows, l’exécution planifiée à la cron, et la conscience du domaine, qui expose les informations métier dans les workflows ETL ou ML/IA.
      Il n’existe pas de solution unique qui fasse tout cela proprement. Les entreprises finissent donc par construire leur propre solution ou contourner les limites des produits existants, ce qui alimente un cycle d’insatisfaction permanente.
      Je ne pense pas que ce soit un problème qu’une startup puisse résoudre en proposant « la solution ». Il faut le traiter comme un écosystème open source composé de bons modules enfichables.
    • Metaflow repose sur Maestro ; l’un ne remplace pas l’autre.
      « Users can use Metaflow library to create workflows in Maestro to execute DAGs consisting of arbitrary Python code. » est indiqué sur https://netflixtechblog.com/orchestrating-data-ml-workflows-....
      La section sur l’orchestration de cet article (https://netflixtechblog.com/supporting-diverse-ml-systems-at...) explique en détail comment Metaflow s’articule avec Maestro, Airflow, Argo Workflows et Step Functions.
    • J’ai créé mon propre moteur de workflow, mais il était tellement bogué et si peu flexible qu’il a failli ruiner un projet sans rapport.
      Je commence à penser qu’un moteur de workflow peut être, dans une certaine mesure, une odeur de conception. Une fois qu’on a créé quelque chose de réutilisable, il semble séduisant de pouvoir l’utiliser pour d’innombrables workflows, mais ces workflows n’ont presque rien en commun, à part le fait d’avoir besoin de plus d’une étape asynchrone.
      Les données sont différentes, les API sont différentes, et les retours nécessaires de la part des utilisateurs ou d’autres systèmes pour continuer sont différents.
    • C’est probablement parce qu’on n’a pas encore trouvé de moteur/orchestrateur de workflow capable de gérer des tâches variées tout en restant facile à comprendre et à exploiter.
      Il est vraiment facile de créer un moteur de workflow sur mesure optimisé pour un cas d’usage précis. À mon avis, la convergence ne s’est pas encore produite parce qu’un tel outil n’a pas encore été créé.
      Si l’on regarde les outils qui ont récemment conquis rapidement leur domaine, Terraform a résolu l’IaC, et Kubernetes les problèmes difficiles du calcul distribué. Les deux sont très complexes, mais ils résolvent des problèmes difficiles. En revanche, les moteurs de workflow généralistes sont complexes à comprendre, difficiles à exploiter, et leur expérience reste mitigée, si bien que beaucoup de gens n’essaient même pas.
    • Le nommage, l’invalidation du cache, et maintenant les moteurs de workflow ? :)
      https://github.com/meirwah/awesome-workflow-engines

  • Je suis le fondateur de https://windmill.dev ; Windmill présente beaucoup de similitudes avec Maestro.
    Dans la description de Maestro, le passage qui parle d’« orchestrateur de workflows à montée en charge horizontale, généraliste, pour gérer des workflows à grande échelle, des pipelines de données et des pipelines d’entraînement de modèles ML » serait tout aussi exact si l’on remplaçait Maestro par Windmill. Ce qu’ils appellent rollup, c’est ce que nous appelons openflow state.
    Les principales différences sont que Windmill est écrit en Rust plutôt qu’en Java, et que Maestro utilise CockroachDB pour stocker l’état, tandis que nous utilisons PostgreSQL à la fois pour l’état et les files. Cela dit, je comprends pourquoi ils utilisent CockroachDB. Windmill aussi a dû créer son propre algorithme de sharding pour assurer la montée en charge horizontale sur de très grosses instances client.
    Maestro est sous Apache 2.0, tandis que Windmill est sous AGPL, une licence moins favorable. Avec le soutien de Netflix, leurs moyens sont en pratique illimités, alors que nous sommes une entreprise bien plus petite, même si nous sommes rentables.
    Maestro ne dispose pas encore d’une documentation suffisante pour l’auto-hébergement avec Kubernetes ou docker-compose, et il ne semble pas y avoir d’interface pour créer quelque chose, ou en tout cas ce n’est pas encore clair dans la documentation. Dans l’ensemble, c’est tout de même assez chouette qu’il ait été publié en open source ; nous allons continuer à le suivre et essayer de le benchmarker dès que possible.

    • Si vous envisagez Windmill, vous devriez d’abord regarder ceci : https://www.windmill.dev/docs/advanced/local_development
      Je ne comprends pas pourquoi il faut se « synchroniser » avec Windmill, pourquoi il y a un IDE intégré à Windmill, ni pourquoi c’est aussi compliqué. On dirait qu’ils ont commencé avec l’objectif de créer un effet de verrouillage, avant même de bâtir un bon produit ou de trouver leur adéquation au marché.
    • La comparaison est intéressante, mais même si Maestro est sous licence Apache, s’il dépend de CockroachDB, ce n’est pas idéal, car CockroachDB lui-même n’est pas open source.
      À mon avis, une base de code AGPL vaut mieux qu’une dépendance qui n’est pas open source. Bien sûr, avec le temps, quelqu’un pourrait ajouter la prise en charge d’une autre base de données.

  • Je suis un peu confus sur ce qui se passe ici. Ce projet semble utiliser Netflix/conductor [0]. Or, quand on va sur ce dépôt, on voit qu’il est archivé, avec un message indiquant qu’il a été remplacé par une version interne non open source de Netflix et par un fork communautaire non nommé. Ils font sans doute référence à Orkes Conductor [1].
    Pourtant, ici, il ne semble pas utiliser Orkes Conductor, mais la version Netflix abandonnée, com.netflix.conductor:conductor-core:2.31.5 [2]. Et c’est une vieille version.
    [0] https://github.com/Netflix/conductor
    [1] https://github.com/conductor-oss/conductor
    [2] https://github.com/Netflix/maestro/blob/e8bee3f1625d3f31d84d...

  • Je me demande si quelqu’un a déjà utilisé ActiveBatch. Pour moi, c’est le logiciel par excellence dont j’aimerais avoir un équivalent pour les utilisateurs non corporate.
    J’ai continué à essayer d’autres « concurrents », mais avec ActiveBatch, il suffit de connecter une simple base MS SQL, d’installer l’interface graphique Windows et les agents d’exécution, et en quelques clics on obtient un environnement d’automatisation robuste basé sur une GUI. Pas besoin d’écrire du code, et si on le souhaite, on peut en écrire dans n’importe quel langage.
    Airflow peut être puissant, mais il se cache derrière une barrière de complexité, si bien que la plupart des gens ne voient jamais vraiment de quoi il est capable. C’est pareil pour les autres concurrents « open source ».
    Je ne comprends pas pourquoi personne n’arrive à créer un système solide, basé sur une DB et privilégiant la GUI. J’ai aussi essayé des services en ligne, mais ils ne soutiennent pas la comparaison. Peut-être que les produits payants plus simples échouent à cause du coût de maintenance des extensions.
    C’est vraiment dommage qu’ActiveBatch soit enfermé derrière un modèle de vente aux entreprises idiot. Cela empêche cet excellent logiciel de se diffuser dans une communauté plus large. On dirait un secret bien gardé.

  • Un conseil : mieux vaut ne pas dépendre des outils que Netflix publie en open source. Ils ont un long historique d’abandon du support après l’annonce.
    Quelqu’un aura sans doute coché une case sur sa grille d’évaluation pour promotion grâce à ce billet de blog et à la publication du code, mais il ne faut pas construire une activité sur ce genre de solution.

  • Je ne vois pas pourquoi il faudrait envisager ça plutôt qu’une solution plus établie comme Temporal. Maestro est écrit en Java, et Temporal semble être écrit en Go

    • Le code Go de Temporal est un peu étrange. Il me semble qu’ils utilisaient Java auparavant, puis sont passés à Go, et ce Go a l’air très « Java-esque »
      Ou alors c’est peut-être moi qui connais mal Fx
      https://github.com/temporalio/temporal/blob/main/service/mat...
      Le problème auquel je me suis heurté à plusieurs reprises avec Temporal, c’est que la documentation est très insuffisante. C’est quelque chose qu’on installe au cœur du métier, mais il est vraiment difficile de comprendre ce qui se passe réellement après avoir traversé plusieurs couches et une documentation très obscure
      Maestro semble ne pas avoir de documentation. Dans ce cas, Temporal gagne par défaut
    • Netflix utilise aussi Temporal : https://temporal.io/in-use/netflix
    • J’ai l’impression que Maestro n’est pas une alternative à Temporal, mais plutôt une alternative à Airflow. Temporal n’est pas un orchestrateur de workflows. Il y a des recoupements dans l’architecture interne, mais ce sont des conceptions différentes pour des cas d’usage différents
    • Une partie du cœur de Temporal n’a-t-elle pas été réécrite en Rust ?

  • C’est un projet qui a vraiment l’air très bien. Dans presque tous les projets hybrides ML + ingénierie des données dont je me suis occupé, j’ai envisagé de construire quelque chose de très similaire, probablement en pire
    J’ai hâte de le tester moi-même

  • Comme je construis orchestra dans ce domaine, voici mon avis : le fait de le rendre open source et de le développer publiquement est clairement excellent. Mais, comme ils le disent eux-mêmes, c’est un orchestrateur, et il existe déjà beaucoup de solutions antérieures, notamment Airflow
    J’ai donc du mal à voir ce que cela apporte réellement à ce domaine, au-delà d’ajouter une option de plus que personne n’utilisera en environnement commercial
    Promo éhontée : https://getorchestra.io

  • Je me demande si c’est significativement différent de Conductor, qui avait été archivé auparavant. En parcourant le code, je vois pas mal de similitudes, et ils utilisent aussi JSON comme langage de définition des workflows