Maestro: Netflixのワークフローオーケストレーター
(netflixtechblog.com)- Netflixは、大規模なData/MLワークフロー向けの水平スケーリング型オーケストレーター Maestroをオープンソースとして公開し、社内では数十万件のワークフローを最小限の中断で移行して運用している
- DAG中心のオーケストレーターとは異なり、非循環・循環ワークフローの両方を扱い、foreachループ・サブワークフロー・条件分岐をエンジンレベルのパターンとして提供する
- 過去1年間で実行ジョブ数が87.5%増加し、現在は1日平均で数千件のワークフローインスタンスと約50万件のジョブを実行し、繁忙日には約200万件のジョブを完了している
- JSONベースの定義に実行戦略、パラメータ、SEL式、シグナル、ブレークポイント、タイムライン、再試行ポリシー、ロールアップを組み合わせ、運用制御とデバッグを支援する
- Netflixのようにデータテーブルが単一のデータウェアハウスに集約された環境では、ワークフローを複数クラスタに分割すると調整コストとユーザー体験の低下が大きくなるため、単一オーケストレーターが全体の流れを担う構成が重要になる
Maestro公開とNetflix内での運用規模
- NetflixはMaestro GitHub repositoryを通じてMaestroのソースコードを公開した
- Maestroは、データパイプラインや機械学習モデルの学習パイプラインのような大規模Data/MLワークフローを管理する水平スケーリング型ワークフローオーケストレーターである
- ワークフローの開始から終了までライフサイクル全体を管理し、再試行・キューイング・コンピュートエンジンへのジョブ分配を処理する
- ユーザーはビジネスロジックをDockerイメージ、ノートブック、bashスクリプト、SQL、Pythonなどさまざまな形式でパッケージ化できる
- Netflixは以前の紹介以降、数十万件のワークフローをMaestroへ移行し、その過程でユーザーへの中断を最小限に抑えた
- 最近の運用規模:
- 過去1年間で実行ジョブ数が87.5%増加
- 1日平均で数千件のワークフローインスタンスを実行
- 1日平均で約50万件のジョブを実行
- 繁忙日には約200万件のジョブを完了
単一オーケストレーターで拡張性と多様性を支援
- MaestroはNetflix社内で数千人のエンドユーザー、アプリケーション、サービスにWorkflow-as-a-Serviceを提供するフルマネージド型オーケストレーターである
- ETLパイプライン、MLワークフロー、ABテストパイプライン、複数ストレージ間のデータ移動パイプラインをサポートする
- 水平スケーリング構造は、多数のワークフロー数と単一ワークフロー内部の多数のジョブ数の両方を処理できるよう設計されている
- Netflixのワークフローは相互に密接につながっており、小さなグループに分けて複数クラスタで管理すると追加の調整メカニズムが必要になり、ユーザー体験も低下する
- データテーブルが単一のデータウェアハウスにあるため、そこへアクセスするすべてのワークフローを単一オーケストレーターが処理すべきだという判断である
ワークフロー定義モデル
- Maestroのワークフロー定義はJSON形式で記述される
- ユーザー提供フィールドとMaestro管理フィールドを組み合わせてオーケストレーション定義を構成し、例はMaestro repository wikiにある
- ワークフロー定義は大きく2つの領域に分かれる
- properties: 作成者・所有者情報と実行設定を含む
- versioned workflow: ワークフローメタデータとグラフ定義を含む
- propertiesはワークフローバージョンが変わっても、作成者・所有者情報、実行戦略、同時実行設定のような中核属性を保持する
- 所有権が変わった場合、新しいワークフローバージョンを作成せずに、新しい所有者が既存ワークフローの所有権を引き継げる
- versioned workflowは、一意識別子、名前、説明、タグ、タイムアウト設定、優先度付けのためのcriticalityレベルlow・medium・highを含む
- ワークフロー変更時には新しいバージョンを作成し、デフォルトではアクティブ版または最新バージョンが使われる
- ワークフローは、ユーザー定義グラフのノードであるstepで構成される
- stepはジョブ、subworkflow stepによる別ワークフロー、foreach stepによるループを表せる
- stepには一意識別子、stepタイプ、タグ、入出力パラメータ、依存関係、再試行ポリシー、失敗モード、step出力などが含まれる
- エラー種別ごとに設定可能な再試行ポリシーをサポートする
実行順序を制御するRun Strategy
- Maestroは、事前定義されたrun strategyによって新しいワークフローインスタンスを実行するかどうかを決定する
-
Sequential Run Strategy
- デフォルト戦略であり、FIFO順で1件ずつ実行する
- 前回実行の成功可否に関係なく、インスタンスが成功または失敗などの終了状態に達すると、キュー内の次のインスタンスを開始する
-
Strict Sequential Run Strategy
- トリガーされた順序で実行するが、前のインスタンス履歴にblocking errorがある場合は実行を止める
- 失敗したインスタンスを手動で再起動するかunblock処理するまで、新しいインスタンスはキューに残る
- 時間感度は低いが、ビジネス上重要度の高いワークフローに有用である
-
First-only Run Strategy
- 実行中のワークフローが完了するまでは、新しいインスタンスをキューに保持しない
- 現在実行中のインスタンスがある場合、新たにキューに入ったインスタンスを削除し、キューイングを事実上無効化する
- 新しいインスタンスを積み上げないことで、冪等性の問題を避ける助けになる
-
Last-only Run Strategy
- 常に直近でトリガーされたインスタンスが実行されるようにする
- 既存の実行中インスタンスがある場合はそれを中断し、新たにトリガーされたインスタンスを実行する
- 毎回テーブル全体の最新スナップショットを処理するワークフローのように、最新データだけが必要な場合に有用である
-
Parallel with Concurrency Limit Run Strategy
- 事前定義された同時実行上限の範囲内で複数インスタンスを並列実行する
- 大量データを制限時間内に処理できるよう、実行をfan-outして分散できる
- 古いデータのバックフィルが一般的なユースケースである
パラメータとSEL式
- Maestroでは、パラメータは実行ロジックの制御、ワークフローとstep間の状態共有、上流と下流step間の状態共有に使われる
- Maestroはコード注入を伴う動的パラメータをサポートし、複雑なパラメータ化ワークフローを定義できるようにしている
- コード注入はセキュリティと安定性のリスクを生みうる
- ユーザーが無限ループを書いて配列に項目を追加し続けると、サーバーがOOMで停止する可能性がある
- 注入コードをビジネスロジック側へ移すとユーザー負担が増え、ワークフロー定義とビジネスロジックが強く結び付く
- Netflixはこれを緩和するため、独自の式言語であるSEL(Simple, Secure, and Safe Expression Language) を開発した
- SELはJava Language Specificationsの文法と構文に従いつつ、Maestroのユースケース向けに調整したサブセットをサポートする
- SELはMaestroパラメータ型のデータ型、エラー発生、日付・時刻処理、事前定義ユーティリティメソッドをサポートする
- 安定性確保のため、ループ反復回数の制限、配列サイズ検査、オブジェクトのメモリサイズ制限といったランタイムチェックを含む
- SELの文書はMaestro GitHub documentationにある
出力パラメータとパラメータ化ワークフロー
- Maestroはcallable step executionを通じて、ユーザーの実行結果を出力パラメータとしてシステムへ返せる
- 出力データはMaestro REST APIを通じて渡され、stepランタイムがMaestroデータベースへ直接アクセスすることはない
- 静的ワークフローは単純だが、小さな違いを反映するだけでも同じワークフローを何度も複製する必要が生じることがあり、パラメータがなければワークフローとジョブは状態を共有できない
- 完全に動的なワークフローは管理とサポートが難しく、デバッグ・問題解決・再利用も困難である
- パラメータ化ワークフローは、ユーザー定義パラメータに基づいてランタイム時にstepごとに初期化され、実行時制御の柔軟性と管理しやすさを両立する
- Maestroのパラメータサポートにより、バックフィル用データパイプラインのような複雑なパラメータ化ワークフローの生成が可能になる
エンジンレベルのワークフロー実行パターン
- Maestroは共通のデータフローとワークフローパターンをエンジンで直接サポートする
- エンジンによる直接サポートにより、パターンの最適化と一貫した実装方式が可能になる
-
Foreach
- foreach パターンは、もともとワークフロー定義内の専用stepとしてモデル化される
- foreachループの各反復は、内部的に個別のワークフローインスタンスとして処理される
- foreach定義ブロック内のstep実行、つまりsub-graph実行は、別個のワークフローインスタンスに委譲される
- foreach stepは、各反復を担当するワークフローインスタンスの状態を監視し、収集する
- 反復ごとに異なるパラメータで同じジョブを実行するデータバックフィルや機械学習モデルのチューニングでよく使われる
- ユーザーは数十万件の反復をワークフロー定義に直接記述する必要がなく、foreachの対象範囲が変わるたびに新しいワークフローを作る必要も減る
-
Conditional Branch
- 条件分岐 は、アップストリームstepの特定条件が満たされたときにのみ後続stepを実行させる
- 条件はSEL式で定義され、ランタイムに評価される
- 監査チェックstepが失敗したときに復旧処理を行った後、再びジョブを実行するフローを構成できる
-
Subworkflow
- subworkflow は、1つのワークフローstepが別のワークフローを実行することで、共通機能を複数のワークフローで共有できるようにする
- 「workflow as a function」の形でワークフローグラフを構成できる
- Netflixでは、複数のチームが提供するsubworkflowを組み合わせて数百テーブルのデータを処理する、数百のsubworkflowで構成された複雑なワークフローも見られる
- foreach、条件分岐、subworkflowは組み合わせて使える
- subworkflowの集合をループ処理できる
- ネストしたforeachループを実行できる
- 条件分岐とsubworkflowを組み合わせて、エラーを処理しジョブを自動リトライする自動復旧ワークフローを作成できる
Step Runtimeとパラメータマージ
- Maestroは、実行時点のジョブを記述するために step runtime を使用する
- step runtimeインターフェースは2種類の情報を定義する
- stepインスタンスの実行動作を制御する基本API群
- stepランタイム状態と実行結果を追跡するシンプルなデータ構造
- Maestroはforeach step runtime、subworkflow step runtimeのような実装を提供する
- 各実装は、start、execute、terminate動作に対する独自ロジックを定義する
- ランタイム状態は、stepの次の状態遷移を決定し、失敗または終了したかどうかを判断するために使われる
- 実行結果にはstepアーティファクトとstep実行履歴タイムラインが含まれ、後続stepからアクセスできる
-
Step Parameter Merging
- Maestroは、step動作を動的に制御するためにruntime parameterとtag注入をサポートする
- step parameter mapは最初は空で、次の順序でマージされる
- Default General Parameters:
workflow_instance_id、step_instance_uuid、step_attempt_id、step_idのような全step共通の基本パラメータで、Maestro内部の予約値として使われるためユーザーは渡せない - Injected Parameters: step runtimeで動的に生成されるパラメータで、stepタイプごとのschemaによって異なる場合がある
- Default Typed Parameters: 特定のstepタイプに関連する基本パラメータで、foreach stepの
loop_params、loop_indexなどが該当する - Workflow and Step Info Parameters:
workflow_idのようなstepおよびワークフロー関連の識別情報 - Undefined New Parameters: ワークフローインスタンスの開始または再起動時に、ユーザーが新たに指定したstepパラメータ
- Step Definition Parameters: 定義時点でユーザーが記述したstepパラメータ
- Run and Restart Parameters: 開始または再起動時に、ユーザーが既存の定義パラメータを上書きするために提供した値で、最後にマージされる
Step DependenciesとSignal
- Maestroワークフローグラフのstepは、step dependency によって実行依存関係を表現できる
- step dependencyは、step実行に必要なデータ関連条件を指定する
- 条件は通常signalをベースに定義される
- signalは、パラメータ値のような情報を含むメッセージであり、step出力やSNS・Kafkaのような外部システム経由で発行できる
- signalは、triggerパターンとpublisher-subscriber型のsignal dependencyパターンの両方に使われる
- 1つのstepは出力signalを発行することで、そのsignalに依存する複数のstepの実行を解放できる
- signal definitionはマッピングされたパラメータ一覧を含み、Maestroは一部フィールドだけで signal matching を実行できる
- Maestroはsignalパラメータ値に対して
<、>のような signal operators をサポートする - Netflixはsignalの概念の上に複数の抽象化を構築している
- ETLワークフローがテーブルを更新してsignalを送ると、そのデータに依存するダウンストリームワークフローstepを実行できる
- signal lineage は、過去のsignalインスタンスと、そのsignalを発行または消費したワークフローstepを追跡できるようにする
- signal triggerは、1つまたは結合されたsignal集合を購読するワークフローに対してexactly-once executionを保証する
- 指定されたsignal条件が満たされたときにのみワークフローやstepを実行するため、リソースを節約できる
デバッグと実行可視性
-
Breakpoint
- Maestroではワークフローstepに ブレークポイント を設定できる
- ワークフローインスタンスがブレークポイントが設定されたstepに到達すると、そのstepはpaused状態になる
- ユーザーが手動で再開するまでワークフローグラフの進行は停止する
- 同じワークフローstepの複数インスタンスがブレークポイントで停止している場合、1つを再開してもそのインスタンスだけが影響を受け、残りはpaused状態のまま維持される
- ブレークポイントを削除すると、停止していたすべてのstepインスタンスが再開される
- 初期のワークフロー開発時にstep実行と出力データを点検するのに有用である
- foreachパターンで単一のstepにブレークポイントを設定すると、すべての反復がそのstepで停止し、デバッグできる
- 実行中の人手による介入や、実行中stepの状態変更のサポートにも利用できる
-
Timeline
- Maestroはstep実行タイムラインを含み、状態マシンの変更やその理由のような主要イベントを記録する
- 例示的なイベントには
Created、Evaluating paramsのような遷移が含まれる - 実装されたstep runtimeは、エンドユーザーに実行情報を表示するためにタイムラインイベントを追加できる
- タイムラインの例は sample-step-instance-failed.json にある
リトライ、Aggregated View、Rollup
-
Retry Policies
- Maestroは、失敗して終了状態に到達したstepに対してリトライポリシーをサポートする
- ユーザーは、リトライ回数、リトライ間の遅延、固定間隔リトライ、exponential backoff戦略を設定できる
- リトライは2つのタイプに分かれる
- platform retry: ユーザーロジックとは無関係なプラットフォームレベルのエラーに対応
- user retry: ユーザー定義条件に基づくリトライ
- 各タイプはそれぞれ別個のリトライポリシーを持てる
- 自動リトライは、ユーザーの介入なしで解決可能な一時的エラーの処理に有用である
- 冪等性のないstepは、リトライを避けるためにリトライ回数を0に設定できる
-
Aggregated View
- 1つのworkflow instanceは複数のrunを持てるため、ユーザーはすべてのstepの集計状態を確認できる必要がある
- aggregated viewは、基本のaggregated viewと現在のrunのstep状態をマージして計算される
- 例えば最初の実行でstep1・step2は成功、step3は失敗、step4・step5は未開始だった場合、再起動はstep3から始まり、step1・step2は以前の成功状態によりskipされることがある
- すべてのstepが成功すると、aggregated viewは全stepのrun状態を表示する
-
Rollup
- rollupはworkflow instanceの上位レベルの要約を提供し、各stepの状態と状態ごとのstep数を表す
- 現在のインスタンスと、subworkflow・foreachのようなネストされたnon-inline workflowのstepを展開して集計する
- 成功したworkflowが3つのstepを持ち、そのうち1つが5 stepのsubworkflowである場合、rollupは成功step数を7と表示する
- rollupではleaf stepのみを集計し、他のstepは具体的なワークフローを指すポインターとして扱う
- 成功していないstepの参照も保持し、ネストされたワークフロー内の問題のあるstepへ移動できるようにする
- aggregated rollupは、現在のrunのruntime dataとbase rollupを組み合わせて計算される
- subworkflow stepのrollupは、subworkflow instanceのrollupをそのまま反映する
- foreach stepのrollupは、前回実行のbase rollupから再起動対象の反復を除いたものと、現在実行中の反復のrollupを組み合わせる
- この過程のため、rollupモデルはeventually consistentであり、ネストされたforeachやsubworkflowが多段に入ると計算は複雑かつ再帰的になりうる
イベント発行と外部連携
- ワークフロー定義、workflow instance、step instanceが変更されると、Maestroはイベントを生成し、内部処理後に外部システムへ発行する
- Maestroイベントは内部イベントと外部イベントに分かれる
- internal event: workflow、workflow instance、step instanceのライフサイクル内部の変更を追跡し、内部キューに発行される
- external event: ダウンストリームサービスが消費するMaestroの状態変更情報を含み、SNS・Kafkaのような外部キューへ送信される
- Maestro event processorは内部キューを購読してinternal eventを取得し、イベントタイプに応じて処理した後、必要に応じてexternal eventへ変換する
- 最後の段階のnotification publisherが外部イベントを発行し、ダウンストリームサービスが消費できるようにする
- ダウンストリームサービスの大半はイベントベースであり、Maestro eventはMaestroのさまざまな変更を検知するために必要なメッセージを含む
- 変更タイプは大きく2つのカテゴリに分かれる
- workflow change: ワークフロー定義やpropertiesの変更のようなワークフローレベルの動作
- instance status change: workflow instanceまたはstep instanceの状態遷移
始め方
- Maestroのコードはgithub.com/Netflix/maestroで確認できる
- 質問、意見、コメントはMaestroリポジトリのGitHub issueに投稿できる
- Netflixは、Maestroが提供する拡張性と使いやすさによって、Netflix外部でのワークフロー開発も迅速に進められることを期待している
1件のコメント
Hacker News の意見
以前はこうした企業の技術ブログや社内の独自システムに感心していたが、今はそうではない。コードは負債だからだ
cron/Celery/Airflow のようなものを作り直すより、保守と改善の履歴が長い既製のオープンソースを使いたい。誰かが保守し、バグを直し、機能を追加しなければならないからだ。もちろん昇進や給与/RSU の増加が付いてくるなら話は別
会社に稼ぎをもたらす中核業務ではないコードは、注意を分散させリソースを食うものだと認識すべきだ
既存の既製オープンソースでは解決できないニーズがあったため作られ、今それを再び既製のオープンソースに変えて使い続けながら、保守負担を分担しようとしている過程だ。こうしたツールが最初からどうやって生まれるというのか。誰かが作らなければならない
新しいシステムを作り、新しいアイデアを推し進めることを恐れない人たちがいるのは幸いだ。企業の観点でも、平凡でリスク回避的な解法だけでは限界がある。最も収益性の高い企業は、技術的にはかなり大胆なほうだ
コードは負債ではなく、会社の歯車を回すものだ
自分でもコミュニティに貢献するつもりがあるのか気になる。作るか買うかは常に重要な議論だが、「買う」側には保守と信頼性のコストが正確に 0 だと見るのは素朴に見える
エンジニアがワークフローソリューションに満足するには、あと何回の反復が必要なのか気になる。Netflix には Maestro 以前にも Metaflow など複数のソリューションがあり、Uber も複数のソリューションを作っており、Amazon には社内ワークフローエンジンが少なくとも十数個はあった
さまざまな会社の多くの個人がワークフローエンジンを作りたがるという点が興味深い。誰かや Netflix をけなそうという話ではなく、軽く話してみる価値のある観察だと思う
実際には 5 つの中核的な関心事がある。リソーススケジューリング、依存関係解決、タスクとワークフローを作るための API/DSL、cron のようなスケジュール実行、そして ETL や ML/AI ワークフローでドメイン情報を表に出すドメイン認識だ
これらすべてをきれいにこなす単一のソリューションはない。だから会社は既存の既製品の欠点を埋めるために自作したり回避策を取ったりし、全員が不満を抱き続ける循環が続く
スタートアップ 1 社が「解決策」として作れる問題ではないと思う。優れたプラグイン型モジュールコンポーネントから成るオープンソースエコシステムで解くべきだ
“Users can use Metaflow library to create workflows in Maestro to execute DAGs consisting of arbitrary Python code.” と https://netflixtechblog.com/orchestrating-data-ml-workflows-... に書かれている
この記事のオーケストレーションセクション（https://netflixtechblog.com/supporting-diverse-ml-systems-at...）には、Metaflow が Maestro、Airflow、Argo Workflows、Step Functions とどのように連携するかが詳しく説明されている
ワークフローエンジンはある程度設計の臭いなのかもしれないと思い始めている。一度再利用可能なものを作れば数多くのワークフローに使えそうで魅力的に見えるが、非同期ステップが 2 つ以上必要だということ以外、ワークフロー同士にはほとんど共通点がない
データも違い、API も違い、先へ進むためにユーザーや他のシステムから受け取る必要のあるフィードバックも違う
特定のユースケースに最適化されたカスタムワークフローエンジンを作るのは本当に簡単だ。まだ収束が起きていない理由は、そうしたツールがまだ作られていないからだと思う
最近それぞれの領域を急速に制したツールを見ると、Terraform は IaC、Kubernetes は分散コンピューティングの難問を解決した。どちらも非常に複雑だが、難しい問題を解いている。一方、汎用ワークフローエンジンは理解するのが複雑で、運用が難しく、体験も曖昧なため、多くの人がそもそも試そうとしない
https://github.com/meirwah/awesome-workflow-engines
https://windmill.dev の創業者ですが、Windmill は Maestro と共通点が多いです。
Maestro の説明で「大規模なワークフロー、データパイプライン、ML モデル学習パイプラインを管理する、汎用の水平スケール可能なワークフローオーケストレーター」とある部分は、Windmill に置き換えてもそのまま正確に当てはまります。彼らが rollup と呼んでいるものは、私たちが openflow state と呼んでいるものです。
主な違いは、Windmill は Java ではなく Rust で書かれており、Maestro は状態保存に CockroachDB を使う一方、私たちは状態とキューの両方に PostgreSQL を使っている点です。ただ、CockroachDB を使う理由は理解できます。Windmill も非常に大規模な顧客インスタンスで水平スケールするために、独自のシャーディングアルゴリズムを作る必要がありました。
Maestro は Apache 2.0 で、Windmill はより制約の強い AGPL です。Netflix の支援を受けて資金は事実上無限にありますが、私たちは黒字化しているとはいえ、はるかに小さな会社です。
Maestro には Kubernetes や docker-compose ベースのセルフホスティング文書が十分になく、何かを作るための UI がないか、少なくとも文書からはまだよく見えていません。それでも全体としてオープンソース化されたのはかなり素晴らしいことで、引き続き注視し、できるだけ早くベンチマークしてみるつもりです。
なぜ Windmill と「同期」しなければならないのか、なぜ Windmill の中に IDE が入っているのか、なぜこんなに複雑なのか分かりません。良いプロダクトを作ったりプロダクトマーケットフィットを見つけたりする前に、ロックインを狙って始めているように見えます。
オープンソースではない依存関係よりは、AGPL のコードベースのほうがまだましだと思います。もちろん、時間がたてば誰かが代替データベース対応を追加する可能性はあります。
ここで何が起きているのか少し混乱しています。このプロジェクトは Netflix/conductor [0] を使っているように見えます。ところがそのリポジトリに行ってみるとアーカイブされており、Netflix の社内向け非オープンソース版と、名前の挙がっていないコミュニティフォークに置き換えられたというメッセージがあります。おそらく Orkes Conductor [1] のことを指しているようです。
しかしこれは Orkes Conductor を使っておらず、停止された Netflix 版である
com.netflix.conductor:conductor-core:2.31.5[2] を使っているように見えます。しかも古いバージョンです。[0] https://github.com/Netflix/conductor
[1] https://github.com/conductor-oss/conductor
[2] https://github.com/Netflix/maestro/blob/e8bee3f1625d3f31d84d...
[0] https://techcrunch.com/2023/12/13/orkes-forks-conductor-as-n...
ActiveBatch を使ったことがある人がいるのか気になります。私にとっては、非エンタープライズユーザー向けの同等製品があってほしい最高のソフトウェアです。
他の「競合製品」も使い続けようとしましたが、ActiveBatch はシンプルな MS SQL DB を接続し、Windows GUI と実行エージェントをインストールすれば、数クリックで堅牢な GUI ベースの自動化環境ができます。コードを書かなくてもよく、望めばどんな言語でもコードを書けます。
Airflow は強力かもしれませんが、複雑さの壁の向こうに隠れていて、本当の能力が何であれ、ほとんどの人には見えません。他の「オープンソース」競合製品も同じです。
なぜ誰かが堅牢な DB ベースの GUI ファーストなシステムを作れないのか分かりません。オンラインサービスも使ってみましたが、比較になりません。より単純な有料製品が失敗する理由は、拡張機能の維持コストのせいかもしれません。
ActiveBatch が愚かなエンタープライズ営業モデルの背後に閉じ込められているのは本当に残念です。この優れたソフトウェアがより広いコミュニティに広まるのを妨げています。隠れた秘宝のようです。
助言するなら、Netflix がオープンソースとして公開したツールには依存しないほうがいいです。発表したあとサポートを打ち切った前例が長くあります。
誰かはこのブログ記事とコード公開で昇進評価シートにチェックを付けられたのでしょうが、こうしたソリューションの上にビジネスを築くべきではありません。
Temporal のようにより定着しているものの代わりに、なぜこれを検討すべきなのか分からない。Maestro は Java で書かれていて、Temporal は Go で書かれているように見える
あるいは自分が Fx をよく知らないだけかもしれない
https://github.com/temporalio/temporal/blob/main/service/mat...
Temporal で繰り返しぶつかった問題は、ドキュメントが非常に不足していることだ。ビジネスの中核に導入するものなのに、何層ものレイヤーと非常に難解なドキュメントをくぐり抜けて、実際に何が起きているのかを理解するのが本当に難しい
Maestro にはドキュメントがないように見える。だとしたら Temporal の不戦勝だ
本当に良さそうなプロジェクトだ。自分が担当したほぼすべての ML + データエンジニアリング の混合プロジェクトで、これとほとんど同じもの、たぶんもっと悪いバージョンを作るかどうか考えたことがある
実際に試してみるのが楽しみだ
この領域で Orchestra を作っているので自分の考えを書いてみると、オープンソースにして公開で開発するのは間違いなく素晴らしい。だがこれは本人たちも言っているようにオーケストレーターであり、すでに Airflow などをはじめ先行するものがあまりに多い
なので、商用環境では誰も使わないであろう選択肢をもう一つ増やすこと以外に、この領域へ実際に何を加えるのかは見えにくい
厚かましい宣伝: https://getorchestra.io
これが以前アーカイブされた Conductor と意味のある違いがあるのか気になる。コードをざっと見ると類似点がかなりあり、ワークフロー定義言語として JSON を使う点も同じだ
Maestro は Conductor を中核として使っている
https://github.com/Netflix/maestro/blob/main/maestro-engine/...
https://netflixtechblog.com/orchestrating-data-ml-workflows-...