定期的に実行する処理の基盤について考えてみる

こんにちは、技術開発グループの松原です。

定期的に実行する処理というと一般的にはWindows環境以外ではcronが思い浮かぶかと思います。 cronは手軽に設定、実行できる反面、サーバに入らないとログが確認できない、スケジュールが確認できない、cronの実行サーバがSPOFになりやすいなどの側面があるかと思います。 そこでcronと同じように定期的に処理を実行することができる出来るソフトウェアについて軽く調査をしてみました。

調査対象の選定の観点は以下の通りです。

• 冗長化構成が取れそうなこと
• cron同様にスケジューリングが可能なこと
• Webから実行結果が見られること

Rundeck

各所で言われている、すごいcronです。 RundeckはWebアプリ上で操作できるJava製のスケジューラです。 ただし一部の操作については、Webアプリ上だけでは完結できないことがあります。

構成

構築する際に必要になるのは以下のソフトウェアです。

• Java
• Rundeck
• H2（もしくはDatabase、MySQLとか）

基本的な動作としては、RundeckサーバからJobを実行するサーバへSSHで接続しJobを実行する、となります。

手軽に動作の確認をするのであればanvils-demoでVagrantが公開されているので確認ができます。
以降の内容はRundeck 2.6.4で動作確認をしています。

出来ること

• WebUIでの実行履歴・ログの確認
• WebUIからジョブの登録
• Jobの依存関係の設定
  ただしこれは、DAGのようなマップではなく、Step実行のイメージ
• cron書式でJobの設定が可能
• 処理失敗時に処理を継続・中断するかの設定
• リトライ回数の設定
• エラー時の挙動を設定可能
• SLA（タイムアウト）が指定できる
• 実行結果が永続化される
• 実行結果を通知
  メール、HipChat※、Slack※ に通知可能
• ユーザ管理、認可が可能。
  設定ファイル、またはLDAPで管理可能

※ プラグインが必要

Jobの依存関係

下図のようにJob2内にJob1を含むといような定義の仕方で、依存関係を定義できます。

イマイチなところ

• Jobのリトライ時でも別のJob実行となるため、リトライなのか別のジョブとして実行されたのか判断し辛い
• ユーザ、ノードの管理をWebUI上で実施
  設定ファイルとして保存する必要
• Jobの依存先のJob名を変更すると実行時にエラーになる

ジョブ実行ノードの冗長化構成について

1. Orchestratorを『Rundum Subset』にして並列実行しないようにして、失敗時にはRetryするようにする。
2. ACT-ACT構成にして同時実行数を１にして『Rundum Subset』を指定することで、どちらかのノードでJobが実行する。

OrchestratorをRundum Subsetにすることで、実行時にJob実行対象となるノードをランダムで選択し実行するという挙動になります。
そのためRetry時に、実行に失敗したノートは別のノードでJobが実行される可能性が出てきます。 再度実行に失敗したノードでJobが実行されることもあります。

雑感

構成も複雑でなく導入も容易であり素直にcronをWebアプリケーションとして置き換えたらこうなるという印象です。
リトライ、タイムアウト機能や通知機能などcronに不足している部分も補ってくれ、cron以外のワンショットの処理を行う用途にも向いています。

Azukaban

Hadoopとかと相性が良いワークフロー管理ツールです。 AzukabanはWebアプリ上で操作できるJava製のスケジューラです。 ただし一部の操作については、Webアプリ上だけでは完結できないことがあります。

構成

構築する際に必要になるのは以下のソフトウェアです。

• Java
• Azkaban
• H2（もしくはDatabase、MySQLとか）

Azkabanは最小構成で利用できるsolo-serverがある。
solo-serverを利用するとWeb ServerとExecutor Serverを分ける必要は無くなる。 以降の内容はAzkaban 3.0.0で動作確認をしています。

出来ること

• WebUIでの実行履歴・ログの確認
• Jobの依存関係の設定
  DAG形式で依存関係が定義
• 処理失敗時に処理を継続・中断するかの設定
• リトライ回数の設定
• SLA（タイムアウト）が指定できる
• 実行結果が永続化される
• 実行結果を通知
  メールのみ
• ユーザ管理、認可が可能
  設定ファイル、またはLDAP※で管理可能

※ プラグインが必要

Jobの依存関係

下図のようにDAG形式でジョブを依存関係を定義できます。
また、公式サイトにJobフロー図のようにJob内でJobを呼び出すことで依存関係の定義ができます。

イマイチなところ

• 公式ページでは2.5.0までのバイナリしか公開されていないため最新版（3.0.0）を試す場合にはビルドが必要になる
  　ただし、gradleでビルド可能なため比較的容易にビルド可能
• WebUIの操作だけでJobの登録が行えない
  Jobの定義をファイルとして記述し、アップロードが必要
• ユーザ、ノードの管理をWebUI上で実施
  設定ファイルとして保存する必要
• 実行結果の通知方法がメールのみ

ジョブ実行ノードの冗長化構成について

Azkaban3.0になり、Multiple Executor Modeが追加されました。 ドキュメントには以下のような記述もあり、将来的にはジョブの冗長化を視野に入れているようです。

There were several reasons for splitting these services: we will soon be able to scale the number of executions and fall back on operating Executors if one fails. Also, we are able to roll our upgrades of Azkaban with minimal impact on the users.

雑感

構成としてはExecutorで実行するという構成のため、Jobの実行先は特定のノードのみという印象を受けます。
また公式で提供されているプラグインを見ると、cronの置き換えとして使うといよりも、Hadoopなどと組み合わせて使うというのが妥当な使い方に見えます。
もしくはDAG形式で依存関係を設定できるため、cronで定義するには難しい複雑な依存関係が必要な場合に向いているかと思います。

Mesos + Chronos

クラスタリソースマネージャであるMesos上でジョブの実行管理を行うソフトウェアです。
Mesosと連携しているため、一部の確認結果確認等はMesos上で行う必要があります。

構成

構築する際に必要になるのは以下のソフトウェアが必要になります。

• Java
• Maven
• ZooKeeper
• Mesos
• Chronos

以降の内容はChronos 2.4.0、Mesos 0.27.1で動作確認をしています。

出来ること

• WebUIでの実行履歴・ログの確認
• Jobの依存関係の設定 　DAG形式の依存関係が定義
• 処理失敗時に処理を継続・中断するかの設定
• リトライ回数の設定
• SLAを指定できる。 　ジョブ単体のSLAでなく、Retryを含めたJob失敗の定義
• 実行結果が永続化される 　ただし、全Mesos Masterを停止すると実行ログが消失する。 　ジョブ自体は、ZooKeeperに永続化される。
• 実行結果を通知可能 　メール、Slackで通知可能

Jobの依存関係

下図のようにJob間の依存関係（親となるJob）を定義できます。

イマイチなところ

• ユーザ管理が行えない 　誰がなにを行ったのか監査が必要ケースに問題に可能性がある
• リトライをしないという設定が行えない
• Chronos上だけでは直近の１回の実行結果しか確認できないため、Mesosでの確認が必要になる
• ワンショットでの実行はジョブ単位でしかできない 　依存関係のあるジョブは実行されない。
• スケジュールがUTCでしか行えず、繰り返しの設定がなれるまでは直感的ではない

ジョブ実行ノードの冗長化構成について

Mesos Slaveは複数台で構成できるため特に意識することなく、ジョブ実行ノードを冗長化できます。 どのMesos Slaveで実行されるのかは意識しないで良いです。

雑感

機能としては比較的シンプルになっているが、Mesosとの組み合わせ使う必要があるため元々Mesosの導入している/検討しているような場合は導入を行いやすいかと思います。 逆にもともとMesosを導入していない場合や、小規模な環境では導入障壁がやや高いかと思います。 また、スケジュール設定がUTCでしか行えないため、慣れが必要かと思います。

番外

kala

kalaはChronosのようなジョブスケジューラを実現しようとしているGo言語で書かれたソフトウェアです。
ただし現在は、Alpha stageだからProduction環境では使わないようにとの注意書きがREADMEに書かれており、まだシングルノードでしか動かないようです。
将来的に機能が充実してくると面白いのではないかと思います。

horenso

horensoは新しくジョブ実行ツールなどの導入を行わず利用できるcronのラッパー用のツールです。
Go言語で作成されており、バイナリを置くだけで利用することができます。
以下のようなコマンドで、horensoを実行して今まで利用していたジョブの内容を最後に書くようにすることで利用できます。

 horenso --reporter /path/to/report.pl -- /path/to/yourjob

reporterを指定することでSlackやHipChatなどにも通知することができます。

総評

cronの置き換えとして使うなら、cronだけでは実現の難しい通知、リトライ、タイムアウトなどが利用することができるRundeckが比較的容易に導入することも出来良いかと思います。
現状のcronに通知機能だけつけたいというような用途であれば、horensoを使うというのが良いのではないかと思います。