Apache DolphinScheduler 3.xは、そのアーキテクチャを根本から覆しました。1.3を使用しているチームは、アップグレードを行う前にクラスターレイアウトの再構築とデータベーススキーマの書き換えを行う必要があります。従来のシングルノードのマスターは姿を消し、ジョブのスケジューリング、保存、ログ記録の方法が異なる、プラグイン駆動型の分散型システムへと置き換わりました。
なぜこの変更が重要なのか
バージョン1.3は、すべてのスケジューリング決定を処理する中央集権的なマスターに依存しており、組み込みのタスクタイプはわずか12種類でした。3.xでは、タスクタイプやストレージアダプターをプラグインとしてロードするマイクロカーネルへと刷新されました。また、マスターとワーカーがレジストリサービスを介して通信できるようにすることで、単一障害点（SPOF）を排除しています。運用者はスケーラビリティとレジリエンス（回復力）を手に入れ、開発者はコアコードを修正することなく、JARファイルを配置するだけでスケジューラーを拡張できるようになります。
アーキテクチャの刷新
- マイクロカーネル・プラグインシステム – タスク定義、リソースハンドラー、カスタムヘルスチェックは、現在それぞれ独立したモジュールとして存在しています。新しいタスクタイプを追加するには、プラグインをクラスパスに配置し、対象のノードを再起動するだけです。
- 分散型コーディネーション – マスターとワーカーはレジストリを介して互いを検出します。レジストリには、従来のデフォルトであるZooKeeper、JDBCベースのリレーショナルデータベース、またはEtcdクラスターを使用できます。既存のスタックに合わせたテクノロジーを選択してください。
- 拡張されたタスクカタログ – 組み込みタスクは12種類から30種類以上に増加し、クラウドネイティブなワークロードや機械学習パイプラインをカバーしています。
- MasterServer vs WorkerServer – MasterServerは、現在DAGのパーティショニング、サブミッション、およびヘルスモニタリングを担当します。WorkerServerは、ログのストリーミングも行う純粋な実行エンジンとして機能します。この分離により責任範囲が明確になり、各レイヤーを個別にサイジングできるようになります。
- Watcherによるフォールトトレランス – Watcherはレジストリを監視し、ノードの障害を検知します。マスターまたはワーカーが停止すると、レジストリが自動フェイルオーバーをトリガーします。
- gRPCによるログ転送 – リモートログの取得は、NettyベースのプロトコルからgRPCへと移行しました。ソースによると、これによりパフォーマンスが向上しています。
見逃せないデータベースのリファクタリング
スキーマの刷新は、アップグレードにおける最も具体的な障壁となります。
| 1.3 テーブル | 3.x テーブル | 変更内容 |
|---|---|---|
t_ds_process_definition |
t_ds_workflow_definition |
UIおよびAPIの語彙に合わせるため、「process」という用語が「workflow」に変更されました。 |
t_ds_process_instance |
t_ds_workflow_instance |
実行時のレコードについても、同様の意味的な変更が行われました。 |
名称変更に加えて、3.xでは以前はJSONブロブ内に格納されていたタスクのメタデータを専用のリレーショナルテーブルに抽出しており、データ管理がよりクリーンになっています。
移行チェックリスト
- すべてをバックアップする – 1.3のデータベースダンプをフルエクスポートし、
confディレクトリをコピーします。 - 古いテーブルを新しい名前にマッピングする –
t_ds_process_definitionをt_ds_workflow_definitionに、t_ds_process_instanceをt_ds_workflow_instanceにリネームするスクリプトを実行します。その後、外部キー制約を確認してください。 - JSONタスクフィールドを移行する – JSONエンコードされたタスクデータを新しいリレーショナルテーブルにコピーします。いくつかのDAGをテストして、スケジューラーが新しいレイアウトを正しく読み取れることを確認します。
- レジストリを選択する – すでにZooKeeperを使用している場合はそれを継続し、そうでない場合はJDBCベースのレジストリまたはEtcdクラスターをセットアップして、すべてのノードを新しいアドレスに向けます。
- プラグインをデプロイする – 1.3で使用していたカスタムタスクタイプを3.x互換のプラグインとしてパッケージ化し、各MasterServerにデプロイします。
- まずMasterServerを展開する – 移行済みのデータベースを指す新しいMasterServerインスタンスを起動します。既存のワークフローがリストに表示され、ヘルスダッシュボードにエラーが表示されないことを確認します。
- WorkerServerを追加する – WorkerServerを一つずつ起動します。レジストリで正常に登録されていることを確認し、ログがgRPC経由で流れることを確認します。
- スモークテストを実行する – 最も一般的なタスクタイプをカバーする、リスクの低いDAGをいくつか実行します。UIにログが表示されること、およびタスクステータスの更新が正しく伝播することを確認します。
- フェイルオーバーを監視する – MasterServerのクラッシュをシミュレートし、Watcherがスタンバイを昇格させる様子を確認します。実行中のタスクが手動の再起動なしに継続することを確認します。
注意すべき点
新しいプラグインモデルは強力ですが、カスタム開発のハードルは上がります。
結論： 1.3から3.xへの移行は、単なるバージョンのアップグレードではありません。データベースのリネーム、JSONからリレーショナル形式への移行、そしてプラグイン対応のレジストリ駆動型モデルに基づいたクラスターの再設計を、連携して行う必要があります。チェックリストに従ってステップバイステップで進め、早期にテストを実施してください。そうすることで、スケールアウトが可能で、自動復旧し、モダンなクラウドサービスと同じプロトコルで動作するスケジューラーを実現できます。