JOB WORKING!!をリリースして自分で使ってみた感想

# 自己紹介
某ユーザ系Sierの運用SEとして3年ほど働き、今は職場を変え、VB6のリプレースからAIみたいな研究開発まで、何でもやっている20代男性です。もし今より良い条件を提示されたら転職したいです（小声）
専門はインフラ（特に通信ネットワーク。YAMAHA好き）、話せる言語はTypeScript、 JavaScript、Java、PHP、HTML、C#、C++、VB、Shell、Batなどなどです。
[即売会](https://portal.circle.ms/Circle/Index/10383391)で本を出してます。
GitHubは[こちら](https://github.com/nrck)。

# JOB WORKING!!って？
さて、本題です。

JOB WORKING!!とは世界で一番可愛いジョブ管理運用システムです。スケジューリングを行う[Poplar Server](https://github.com/nrck/PoplarServer)、Webコンソールを担う[Mahiru Server](https://github.com/nrck/MahiruServer)、実際にジョブを実行する[Kotori Agent](https://github.com/nrck/KotoriAgent)の3機能で構成されています。また、低スペックマシンでも稼動するように、概ね60MB（Poplar Server単体）程度のメモリ使用と抑えてあります。
このJOB WORKING!!は定形の処理（ジョブ）を、順序立てて、異なる端末で行う際に効果を発揮します。
ちなみに[Node.js](https://nodejs.org/ja/)上で動きます。逆に言えばNode.jsが動く環境ならどこでも動きますので、OSや筐体に依存せず動作させることが可能です。（多分）

- 類似ソフトウェア
 - [JobScheduler](http://www.sos-berlin.com/jobscheduler)　Javaで動きます。
 - [Senjyu](https://senjufamily.nri.co.jp/tool/job_control.html)　NRIがリリースしている製品です。
 - [JP1/AJS](http://www.hitachi.co.jp/Prod/comp/soft1/jp1/products/list/ajs/)　日立の製品ですね。エンタープライズな環境ならこれが多いイメージです。

# そもそもジョブって？
ところでジョブって何でしょうか。
ここで言うジョブとは、定形だった処理のことを指します。所謂バッチジョブってやつですね。
「今どきバッチ処理かよ」って思われるかもしれませんが、案外まだまだ現役です。下記に例を示します。

- 毎日HH:mmにデータ転送する
- 毎週aaa曜日のHH:mmに再起動する
- 毎月d日にバックアップ処理を行う

合わせて覚えていただきたいのですが、本システムではこのジョブを束ねて順序立てたものを、ジョブネットと言います。そして、これらジョブネットの開始から終了までを統括するのがJOB WORKING!!の使命です。

# cron or タスクスケジューラじゃだめなの？
ありがちな疑問です。今更、移行するの面倒くさいですし、ぶっちゃけた話、1つ2つの処理をJOB WORKING!!に載せる方がコストです。
では、どういうときに役立つのでしょうか。

> このJOB WORKING!!は定形の処理（ジョブ）を、順序立てて、異なる端末で行う際に効果を発揮します。

冒頭にも書きましたが、「順序立てて」「異なる端末で」実行するときに効果を発揮します。
まずは「順序立てて」の具体例を下記に示しましょう。

## 順序立てて実行する場合

> 1. 毎日3:00に録画完了したtsファイルをエンコードする
> 2. エンコード終了後、エンコード対象のtsファイルを削除する
> 3. 削除後サーバの再起動を行う

この場合はcronやタスクスケジューラで対応するには、少し工夫が必要でしょう。例えば、すべての処理を1つのシェルスクリプトに記載し、逐次行うよう記述したりする工夫（？）が必要です。
他には2.と3.の開始時刻を、当て勘で決め打ちしてしまう強引なやり方もとれます。しかし、エンコード処理が長引いた場合、エンコード中にファイル削除が実行されたり、再起動が走ったりと散々な結果になるでしょう。

その他に考慮しなければならないことはまだあります。
前の処理の結果によっては、リカバリーを実施しなければいけないですし、場合によっては処理を中断しなければいけない場面も発生するでしょう。

例えば、1.のエンコード処理で失敗したのに、次の2.でファイル削除を実施した場合、動画データは永久に消滅することでしょう。1.で失敗した場合は「後続の処理を行わない」や「2.をスキップして、3.を実施する」といった処置が必要です。これを行えるのがJOB WORKING!!の強みです。

続いて「異なる端末で」の具体例を下記に示しましょう。

## 異なる端末で実行する場合

> 1. Aサーバで録画が完了したtsファイルをBサーバにFTPでコピーする
> 2. Bサーバでエンコード処理を行う
> 3. Aサーバのtsファイルを削除する

エンコード処理をスペックの高いBサーバに移管してみました。
もうこうなったらcronやタスクスケジューラでは対応しきれません。素直にJOB WORKING!!を使ってください。

# 自分で使ってみた
長々と"良さ"を語ってきました。
ここからは自分で使ってみたときの感想です。流石に自分で使っていないのに、おすすめするのはアレですね。
インストール方法や、環境構築等は別記事で後日投稿したいと思います。

## 前提・要件
- 録画サーバとJOB WORKINGサーバの2台が稼働中です。
- 録画サーバでは放送番組の少ない毎週月曜日の早朝3:00に再起動を実施しています。
- それ以外に、HDDの空き容量確認、デバイスチェック等を毎日行います。
- 録画サーバでは3つのサービス（Chinachu、Mirakurun、Zabbix）が稼動しているため、安全に停止させた後、再起動を行う必要があります。
- また、システム領域以外のデータはNASに保存してあるため、マウントする必要があります。

## 作ったジョブネット
> 1. 処理開始ツイート
> 2. Chinachuの停止
> 3. Mirakurunの停止
> 4. Zabbix Agentの停止
> 5. サーバリブート（月曜日のみ）
> 6. ブートチェック（月曜日のみ）
> 7. NASをマウント（月曜日のみ）
> 8. Zabbix Agentの開始
> 9. HDD空き容量の確認
> 10. PT3の状態確認
> 11. Mirakurunの開始
> 12. Chinachuの開始
> 13. 時刻同期
> 14. 処理終了ツイート

14個の処理を毎日3:00から順次実行し、月曜日だけ5～7を実施します。
6.はJOB WORKING!!サーバで実行します。それ以外は録画サーバで実行します。

## で、結局どうなの？
正直設定は面倒です。しかし、こういった初期設定はどのツールを使っても発生する作業なので目をつむります。（改善はしたい）

ジョブの実行制御をすべてJOB WORKINGサーバで行っているため、時刻の変更や曜日の変更が用意だと思います。例えば、開始時間を3:00から3:30に変えたい場合も、ジョブネットの開始時刻を3:30に書き換えるだけで終わりです。こういった部分はメリットかと思います。

ジョブの実行結果、処理時間がログに残るので後々の分析に役立ちます。例えば、ある処理だけが線形的に処理時間が延びていることを発見したり、特定の曜日だけ処理時間が変動したりすることを発見できたりできます。

自分が作ったものですから、やはり愛着が湧きますよね（自画自賛）

# 改善点
- webコンソールがダサい
- なんか設定項目がたくさんある
- インストールがだるい
- たまにバグる
- 他の製品との差別化・・・・

まだ初期リリースの段階ですので、これから改善していきたいと思います・・・。イケているWebUIを作れるパワーがほしいです。
バグや改善要望はissuesに挙げてもらえればなるべく汲み取ります。よろしくおねがいします。

# まとめ
- 自分の要件に合えば使ってみよう！
- OSSのモノでジョブ管理したいならJOB WORKING!!を使ってみよう！
- 自鯖運用ライフの充実に限らず、AWSとかAzureにも突っ込んでみよう！

という感じでまとめました。雑で申し訳ありません。一番上のまとめが全てだと思います。


最後になりますが、これを閲覧していただいた皆様のサーバ運用ライフが、充実したものになっていただければ幸いです。

# 宣伝
2018/10/08(月祝)に池袋サンシャインにて[技術書典５](https://techbookfest.org/event/tbf05)が開催されます。
私が主宰を務める「きじのしっぽ」もサークル参加しておりますので是非お越しください！