【ITニュース解説】(II)A Comprehensive Code Analysis of the Worker Service Startup of DolphinScheduler 3.1.9

Apache DolphinSchedulerは、現代のデータ駆動型企業において、データ処理の「中枢神経系」として機能するワークフロー・スケジューリング・システムである。ETL（データの抽出、変換、ロード）タスクから機械学習の訓練、レポート生成、リアルタイム監視に至るまで、企業の重要なビジネスプロセスは安定し、効率的で、拡張性のあるスケジューリングエンジンに依存している。DolphinScheduler 3.1.9は、その中でも安定して広く利用されているバージョンであり、その内部動作を理解することは、システムエンジニアを目指す上で非常に有益である。

本記事では、DolphinScheduler 3.1.9のWorkerサーバーがどのように起動し、動作を開始するのかについて、そのソースコードを詳しく解説する。これは、DolphinSchedulerのMasterサーバーの起動プロセスを解説した前回の記事に続くもので、MasterとWorkerが連携してどのように機能するかの理解を深め、将来的なシステム拡張や性能最適化の基盤を築くことを目的とする。

Workerサーバーの起動プロセスは、org.apache.dolphinscheduler.server.worker.WorkerServerクラスのrun()メソッドが起点となる。このメソッドは、Workerサーバーがその役割を果たすために必要な様々なコンポーネントを順に初期化し、起動させる。具体的には、リモートプロシージャコール（RPC）の開始、タスク関連プラグインの初期化、Worker自身のレジストリセンターへの登録、タスクを管理・実行するためのスレッドの立ち上げ、そしてメッセージの信頼性確保のためのリトライメカニズムの開始といった主要なステップが含まれる。

Workerサーバーが起動する最初の重要なステップは、RPC（Remote Procedure Call）サーバーの開始である。これは、org.apache.dolphinscheduler.server.worker.rpc.WorkerRpcServer#start()メソッドによって実行される。RPCとは、異なるコンピュータ上のプログラム間で、あたかも同じコンピュータ上で動作しているかのように関数を呼び出す仕組みを指す。Workerサーバーの場合、Masterサーバーからタスクの実行要求やタスクの停止要求など、様々なコマンドを受け取るための通信チャネルを確立する役割を担う。具体的には、Nettyというネットワークフレームワークを利用して通信サーバーを立ち上げ、MasterからのTASK_DISPATCH_REQUESTのような特定の種類のメッセージを受け取った際に、それを適切に処理する「プロセッサ」と呼ばれる部品を登録する。これにより、Masterから送信されたタスク要求はWorkerに到達し、waitSubmitQueueというキューに格納され、後の処理のために待機する。

RPCサーバーの起動に続き、タスク関連のプラグインが初期化される。これは、DolphinSchedulerが様々な種類のタスク（例: Shellスクリプト、Sparkジョブ、Hiveクエリなど）を柔軟に実行できるようにするための重要なステップである。taskPluginManager.loadPlugin()が呼び出されることで、タスクの作成、必要なパラメータの解析、実行に必要なリソース情報の取得といった、タスク実行に関連するテンプレートや機能を読み込み、利用可能な状態にする。これにより、WorkerはMasterから送られてくる多種多様なタスク要求に対応できる準備が整う。

次に、Workerサーバーは、自身が稼働していること、そしてMasterサーバーからタスクを受け入れる準備ができていることをレジストリセンターに登録する。本システムでは、ZooKeeperのような分散コーディネーションサービスがレジストリセンターとして機能する。org.apache.dolphinscheduler.server.worker.registry.WorkerRegistryClient#start()メソッドがこの処理を実行する。Workerは、自身のIPアドレスやポート番号、処理能力などの情報をレジストリセンターに登録する。これにより、MasterサーバーはどのWorkerが利用可能であるかをリアルタイムで把握し、タスクを適切に割り当てることが可能になる。また、Workerはレジストリセンターとの接続状態の変化を常に監視する「リスナー」も登録する。もし接続が一時的に失われた場合でも、システムはその変化を検知し、適切な対応をとることができるようにする。

Workerサーバーのコアとなる処理の一つが、Worker管理スレッド（WorkerManagerThread）の起動である。このスレッドは、Masterから受け取ったタスク要求が格納されているwaitSubmitQueueから、タスクを継続的に取り出す役割を担う。org.apache.dolphinscheduler.server.worker.runner.WorkerManagerThread#run()メソッド内で、このスレッドはシステムが停止するまでループし続ける。キューから取り出されたタスクは、Workerサーバーが持つ「スレッドプール」に送られる。スレッドプールとは、複数のタスクを並行して効率的に実行するための仕組みで、タスクの実行が集中してもシステムが過負荷にならないように、利用可能なリソース（スレッド）を管理する。Worker管理スレッドは、スレッドプールに十分な空きリソースがある場合にのみタスクを投入し、タスクの実行をスケジュールする。これにより、Workerは複数のタスクを同時に処理し、全体の処理能力を向上させる。

最後に、メッセージリトライスレッド（messageRetryRunner）が起動する。このスレッドは、WorkerがMasterに送信したメッセージ（例: タスクの実行結果やステータス更新など）が、Masterから正常に受信されたことを示す確認応答（ack）を受け取れなかった場合に備える。ネットワークの一時的な障害やMasterサーバーの一時的な応答不能によってメッセージが失われることを防ぐため、このスレッドは未確認のメッセージを一定の間隔（例えば5分ごと）でポーリングし、Masterに再送を試みる。この仕組みにより、システム全体の信頼性が向上し、タスクの実行状況がMasterに確実に伝達されることが保証される。

DolphinScheduler 3.1.9のWorkerサーバーは、RPC通信の確立、タスク処理能力の準備、自身の可用性の通知、そしてタスクの実行管理と信頼性の確保という一連のプロセスを経て起動する。これにより、Masterサーバーからのタスク要求を受け入れ、効率的かつ安定的に処理する準備が整う。本記事で解説した起動プロセスは、DolphinSchedulerの内部構造を理解するための重要な一歩であり、今後DolphinSchedulerを利用したシステムの設計や開発、運用に携わる上で基盤となる知識を提供する。これにより、システムの安定稼働や性能改善、さらにはビジネスニーズに応じた二次開発へ応用する道が開かれる。