概要
Conductorは、分散マイクロサービス環境におけるワークフロー実行を統一的に管理するOSSプラットフォーム。複数のサービスを跨ぐタスク実行の流れを定義・実行・監視し、エラー時の自動リトライや状態追跡を提供。大規模分散システムでのタスク調整の複雑性を軽減することを目的として開発された。
主な機能
- ワークフロー定義と実行管理：JSON形式でワークフローを定義し、複数のマイクロサービスにまたがるタスク実行を順次または並列で制御
- 状態追跡と可視化：実行中のワークフローの進捗をリアルタイムで監視し、各タスクの実行状態をダッシュボードで確認
- エラーハンドリングと自動リトライ：タスク失敗時の自動リトライ、フォールバック処理、タイムアウト管理を内蔵
- タスク キューイング：実行待ちのタスクをキューで管理し、ワーカープロセスが必要に応じてポーリングして処理
- 動的ワークフロー：実行時に条件分岐やループ、判定結果に基づく動的なタスク追加が可能
- レート制限と優先度制御：タスク実行の頻度や優先順位をカスタマイズして負荷を調整
- 外部システムとの連携：HTTPコール、データベースクエリ、メッセージキュー等への直接呼び出しをサポート
技術スタック
- 言語：Java（バックエンド）
- フレームワーク：Spring Boot（コアサービス）
- データストア：Elasticsearch（ワークフロー履歴の検索）、PostgreSQL/MySQL（メタデータ管理）
- コンテナ化：Docker対応、Kubernetes環境で運用可能
導入方法
CLIを使用した起動
npm install -g @conductor-oss/conductor-cli
conductor server start
このコマンドでConductor サーバーと組み込みUIが起動される。UIは http://localhost:8080 でアクセス可能。
Dockerを使用した起動
docker run -p 8080:8080 conductoross/conductor:latest
このコマンドでConductor サーバーと組み込みUIが起動される。
Java アプリケーションでの利用
Maven依存関係を追加してクライアントライブラリをインポート、ワークフロー定義をJSON形式で作成し、REST APIを通じてConductorに送信。タスク実行はワーカープロセスが定期的にポーリングして処理。
競合との違い
Apache Airflow は主にデータパイプラインとバッチワークフロー向けで、DAG（有向非環状グラフ）中心の設計。一方Conductorは、マイクロサービスの同期・非同期タスク実行をリアルタイムで管理する点が異なり、タスク粒度がより小さく、頻繁に実行されるワークフロー向けに最適化。
Temporal は分散トランザクション管理とアクティビティの信頼性に重点を置き、状態機械の確実な実行保証が強み。一方Conductorはワークフロー定義の柔軟性と既存マイクロサービス環境への統合の容易さで差別化。Temporalはサーバーサイドの状態保持が強いが、Conductorはステートレス性を重視し水平スケーリングに適した構成。
Prefect はモダンなワークフロー管理で、ダイナミックワークフローとクラウド統合が特徴。Conductorはオンプレミス環境での自由度が高く、既存のマイクロサービスアーキテクチャへの直接統合が容易な点で異なる。
こんな人におすすめ
- マイクロサービスを複数運用する開発チーム：サービス間のワークフロー連携を一元管理し、障害時のトレーシングを統一できるプラットフォームが必要な環境
- 分散システムの保守・運用を自動化したいエンジニア：手動でのサービス間調整を減らし、エラーリトライやタイムアウト管理を自動化したい要件
- リアルタイム性が求められるタスク管理が必要なプロダクト開発者：バッチ処理ではなく、リクエストに応じたワークフロー実行が頻繁に起こるシステム
- オンプレミスやカスタムインフラで運用を続ける組織：クラウドロックインを避け、独自の環境で完全なワークフロー管理基盤を構築したい企業
実装の現実的な検討ポイント
Conductorはワークフロー層のオーケストレーションに特化しており、個々のマイクロサービス開発の負担軽減は行わない。既存のHTTP APIやメッセージキューに対応するワーカーの実装は別途必要。データベースなどの外部依存も多いため、運用負荷を見積もる際は監視・バックアップ体制の整備を含めるべき。
成熟したOSSプロジェクトとして金融・eコマース等の大規模企業での採用実績がある。導入前にコミュニティの活発性や自社システムへの適合性を十分検証することが重要。