obelisk

オベリスク

WASM コンポーネント モデル上に構築された決定論的ワークフロー エンジン

プロジェクトのステータス/免責事項

これはプレリリースです。

このリポジトリには、ローカル開発およびテスト用のバックエンド コードが含まれています。このソフトウェアには、CLI、gRPC、またはデータベース スキーマに対する下位互換性の保証はありません。

サポートされているプラ​​ットフォーム

• Linux x64

基本原則

• まずスキーマ。ワークフローとアクティビティの間のインターフェイスとして WASM コンポーネント モデルの WIT 言語を使用します。
• バックエンド開発者の喜び
  • エグゼキューター、ワークフロー、アクティビティを実行するための単一プロセス。外部アクティビティ用のエスケープ ハッチを備えています (計画中)。
  • エラー、タイムアウト、サーバークラッシュ後のワークフロー実行継続時の自動再試行。
  • 可観測性 (計画) - パラメーターと結果、および関数階層を保存する必要があります。
  • コンポーザビリティ - ネストされたワークフロー、サポートされている言語で記述されたアクティビティの呼び出し
  • 既存のワークフローを再生してフォークします (予定)。問題を修正して続行します。

コンセプトと特徴

• いつでも停止して再試行できるように、冪等性 (再試行可能) である必要があるアクティビティ。この契約はアクティビティ自体によって履行されなければなりません。

  • WASI アクティビティは WASM サンドボックスで実行されます
    • WASI 0.2 HTTP クライアントを使用して HTTP サーバーに接続できます。
    • ファイルシステムへの読み取り/書き込みが可能 (予定)。
  • 最大実行期間のサポート。その後、実行は中断されて断続的なタイムアウトになります。
  • エラー発生時の再試行 - WASM トラップ (パニック) 時、またはエラー結果が返された場合。
  • 指数バックオフを使用してタイムアウト時に再試行します。
  • 実行結果は永続化されます。
  • 親ワークフローの実行をホットに保つか、イベント履歴をアンロードして再実行するパフォーマンス オプション。

• 決定論的なワークフロー

  • 再実行可能: 実行は状態が変化するたびに保持されるため、割り込みまたはエラーの後に再実行できます。
  • 環境から隔離された WASM サンドボックスで実行
  • データベースエラー、タイムアウト、さらにはトラップ（パニック）などの障害が発生した場合に自動的に再試行されます。
  • 子ワークフローまたはアクティビティを生成し、結果が到着するまでブロックするか、結果を非同期的に待機できます。
  • ワークフローは、実行 (計画) の決定性を変更しない追加のログ メッセージやその他の変更を加えて再生できます。
  • 結合セットを使用すると、子の実行が完了するまでブロックするか、待機していない (計画されていない) ものをキャンセルするなど、構造化された同時実行が可能になります。

• WASI Webhook

  • URL パスとしてマウントされ、HTTP トラフィックを処理します。
  • 子ワークフローまたはアクティビティを生成できます。

• 仕事盗み実行者

  • 現在保留中の実行のバッチを定期的にロックし、実行を開始/継続します。
  • 期限切れのロックを持つ古いハング実行をクリーンアップします。バジェットのある実行は再試行されます (計画的)。
  • 同時実行制御 - 同時に実行できるワーカーの数を制限します。

インストール

ドッカー

CONTAINER_ID= $( docker run -d getobelisk/obelisk )
docker logs --follow $CONTAINER_ID | grep " Serving gRPC requests " 

docker exec $CONTAINER_ID obelisk client component list
# See Usage for more details

事前に構築されたバイナリ

GitHub リリース ページから最新リリースをダウンロードします。

crates.io の最新バージョンを使用する

Cargo-binstall を使用してダウンロードする

cargo binstall --locked obelisk

またはカーゴを使用して構築する

cargo install --locked obelisk

ニックスフレーク

nix --extra-experimental-features nix-command --extra-experimental-features flakes run github:obeli-sk/obelisk

使用法

サンプル構成ファイルの生成

obelisk server generate-config

サーバーの起動

obelisk server run

ロードされた関数のリストの取得

obelisk client component list

実行する関数の送信 (ワークフローまたはアクティビティ)

 # Call fibonacci(10) activity from the workflow 500 times in series.
obelisk client execution submit testing:fibo-workflow/workflow.fiboa ' [10, 500] ' --follow

マイルストーン

マイルストーン 1: バイナリのリリース - 完了

• obeliskアプリケーションを起動し、Linux バイナリとして実行する
• ワークフローと wasm アクティビティのスケジュール、タイムアウトと失敗時の再試行
• sqlite を使用した永続化
• 結合セットを使用した子ワークフロー/アクティビティの同時起動
• wasm コンポーネントの構成とスケジューリングのための基本的な CLI
• Github リリース、docker イメージ、crates.io への公開、 cargo-binstallサポート

マイルストーン 2: CLI を介したリモート操作の許可 - 完了

• コンポーネントと一般的な構成を TOML ファイルに移動する
• OCIレジストリからコンポーネントをプルします
• オベリスク イメージを Docker Hub (ubuntu、alpine) に公開します。
• オベリスククライアントコンポーネントのプッシュ
• 実行管理用の gRPC API
• 最上位の親を追跡する
• 作成時の Params の型チェック、システム内のすべての関数の型のイントロスペクション
• ロギングとトレースの構成、OTLP コレクターへのイベントの送信

マイルストーン 3: Webhook、Verify、構造化同時実行性、Web UI - 開始

• HTTP Webhook トリガーは、新しい実行 (ワークフローとアクティビティ) を開始でき、応答を送信する前に結果を待つことができます。
• アクティビティと Webhook の stdout と stderr (構成可能) を転送します。
• 分散トレース、OTLP によって収集されたコンポーネントからのログのサポート
• -await-nextを介した任意の実行結果 (トラップ、タイムアウト、エラーのバリアントなど) から他の実行結果へのマッピング
• サーバー検証 - コンポーネントをダウンロードし、TOML 構成をチェックし、コンポーネントのインポートとエクスポートを照合します。
• 結合セットの構造化された同時実行 - すべての子の実行が完了するまで親をブロックします
• 実行、イベント履歴、関係を表示するための HTML ベースの UI
• 各コンポーネントのインポートとエクスポートを WIT 形式で印刷します。
• 異種結合セットにより、1 つの結合セットで複数の関数シグネチャと遅延を組み合わせることが可能
• アクティビティ、Webhook 用のディレクトリ マッピングを使用してファイル システムを公開する
• アクティビティ、Webhook のネットワーク構成を公開する
• アクティビティのキープアライブ、完了までロックを延長
• C#、Go、JS、Python の例

将来のアイデア

• 実行管理のための対話型 CLI
• 外部アクティビティ gRPC API
• OpenAPI アクティビティ ジェネレーター
• WASM アクティビティからプロセスを生成し、その出力を読み取る
• バックプレッシャー: 保留中のキューの制限、またはエビクション戦略により、 LimitReachedで速度が低下します。
• 外部エグゼキュータのサポート - WIT エクスポートのみに基づいて実行を開始します。外部実行者は、sqlite データベースへの書き込みアクセスを共有する必要があります。
• ワークフロー/アクティビティを実行者に制限するラベル
• 定期的なスケジュール設定
• 期限の伝播
• キャンセルの伝播
• キュー容量の設定、実行送信へのバックプレッシャーの追加
• 障害が注入されたシステムの動作をシミュレートする機能
• 活動をお知らせします。呼び出された場合、戻り値は API エンドポイント経由で提供される必要があります。
• オープンな通知アクティビティを含む実行をリストするための API。
• 待機ポイント中または実行終了後に呼び出すことができる読み取り専用のクエリ関数。
• オプションの stdout、stderr 永続化 / 転送
• インターフェイスインポートを介して呼び出し元から、それをエクスポートする多くのコンポーネントの 1 つへのスマートな依存関係ルーティング。
• スマートな再試行 - 再試行予算。アクティビティがリクエストの特定の割合に失敗した場合に再試行を無効にします。
• 再試行に追加される設定可能なジッター
• ワークフロー メモリ スナップショットによる高速再生
• WASM 導入環境全体で動作する、ワークフロー用のタイムトラベリング デバッガー
• 非決定論が検出された場合に承認システムを使用して、一連のワークフローをホットフィックスする機能
• ワークフローとアクティビティ全体で文字列をその起源までトレースします
• Webhook マッピング: 単一関数を実行し、HTTP と WIT で定義されたパラメーターと戻り値の間を変換します。
• 送信 HTTP および Webhook の分散トレース コンテキスト転送
• WIT で永続的なエラーのバリアントを注釈として指定できるようにする
• (分散) サガのサポート - アクティビティのロールバックを定義し、失敗したワークフローでロールバックを呼び出します。

ソースから構築する

nix flakes を使用して開発の依存関係をセットアップします。

nix develop
# or `direnv allow`, after simlinking .envrc-example -> .envrc

または、すべての依存関係を手動でダウンロードします。dev-deps.txt と Ubuntu ベースの検証を参照してください。 Dockerfile プログラムを実行します。

cargo run --release

テストの実行

./scripts/test.sh

madsimシミュレータを使用した決定論的テスト

./scripts/test-madsim.sh

貢献する

このプロジェクトにはロードマップがあり、機能は特定の順序で追加およびテストされます。機能に貢献したい場合は、GitHub でその機能について議論してください。当社がパッチやその他の貢献を受け入れるためには、当社の貢献者ライセンス契約 (「CLA」) に同意する必要があります。 CLA の現在のバージョンはここで見つけることができます。