Jenkinsをジョブ管理ツールとして使うアイデア

@akiko_pusuさんのJenkinsの事例を読んで、Jenkinsをジョブ管理ツールとして使うアイデアについて考えたことをラフなメモ書き。
間違っていたらあとで直す。

【元ネタ】
Jenkinsをバッチ監視ツールとして運用する事例: プログラマの思索

2枚の絵でわかるJP1ジョブ管理の仕組み - あしのあしあと

Monitoring external jobs - 日本語 - Jenkins Wiki

Jenkinsをメトリクス収集ツールとして使うアイデア: プログラマの思索

【1】基幹系業務システムの命は、Cobolで書かれたバッチ処理だ。
Webシステムやクライアントアプリから収集された業務データ、売上データは、夜間にバッチ処理で一括集計されて、日次や月次の商品有高帳、損益計算書、貸借対照表などを出力する。
これらの数値をにらめっこしながら、経営者は日々の経営方針を微修正しながら経営していく。
だから、経営者は細かい売上データや利益データにうるさい。

バッチ処理のアーキテクチャは、ジョブネットが基本だ。
ジョブネットは、バッチ処理というジョブをカレンダーやスケジュールの実行順序で実施する仕組み。

ジョブネットとは【job net】 - 意味/解説/説明/定義 ： IT用語辞典

Cobolプログラムを直列につなげたものの集合がジョブになり、ジョブをスケジュール通り実行する順番につなげたものがジョブネット図。
バッチ処理のアーキテクチャは、ジョブネット図をいかに固めるかが大事。

ジョブの流れは、直列であるとは限らない。
ジョブは分岐するときもあれば、逆に合流するときもある。

例えば、2枚の絵でわかるJP1ジョブ管理の仕組み - あしのあしあとに書かれているように、出荷ジョブから商品出荷→在庫引当という流れもあるし、出荷→出荷種別確認という流れもある。
逆に、複数のジョブがひとつのジョブに合流する場合もある。

すると、スケジュールに従って各ジョブが実行されて、ジョブが分岐するのは良いが、合流する時、合流してくる両方のジョブが正常に終わらなければ、滞留したまま停止してしまい、ジョブが異常終了する時がある。

つまり、ジョブネット図は、プロジェクト管理で出てくるPERT図のように、ジョブには先行・後行関係が存在し、その制約によって表現されるものである。
並列処理してよいジョブもあれば、先行のジョブが終わらなければ次に進めないジョブもある。
バッチ処理のアーキテクチャでは、そのような制約をジョブネット図へ全て反映しなければ、想定した動きにならない。

【2】ジョブネットを制御するジョブ管理システムの製品は、Tivoli、A-AUTO、千手などが有名だろう。
これらの製品は、当初はメインフレームで生まれ、オープン化の流れによって、WindowsServerやUnix上でも使えるようになった。

IBM Tivoli - Japan

A-AUTO って何？: プログラマの思索

ジョブ管理、ジョブスケジューラなら「A-AUTO」 - 株式会社ビーエスピー

運用管理ソフトウェア：Senju Family：NRI

これら既成の製品とJenkinsを比較して、ジョブ管理ツールとして必要な機能を洗い出してみよう。

【3】Jenkinsをジョブ管理システムとして使う場合、何が必要で、何に注意すればいいのか？
まず、Jenkinsでジョブに相当するものは何か？
それは、SCMからビルドする処理や、ログ集計する処理など、一塊のバッチ処理。

Jenkinsでジョブネットに相当するものは何か？
それは、JenkinsのBuild Pipeline Pluginのように、一連のジョブを実行順序で並べて表示した機能に相当するだろう。

JenkinsとGitとSpockで独り継続的インテグレーション - Log for Backup - Naoki_Rinの学習

Jenkins でビルドパイプライン - エンジニアきまぐれTips

何もわからない / Jenkins でビューを色々いじると仕事が捗る #jenkinsci

しかし、Build Pipeline Pluginを見る限り、既成のジョブ管理システムのジョブネット修正ツールに比べると、機能は貧弱な点がある。
Jenkinsにジョブネットを表現し、制御できるような機能が追加されると良いだろうと思う。

また、バッチ処理で注意すべき点は、ジョブ同士でやり取りするデータ。
例えば、電文のような128byteとか512byteのような文字列のテキストファイル、またはCSVファイルやログのようなテキストファイル、またはRDBのテーブルだったりする。
この時、電文やCSVなどのテキストファイルの場合、データをソートしたり、集約化したりするなど、SQLでやる操作をプログラムで自作する必要があったりする。
Cobolのような原始的なプログラミング言語は、リスト処理がさほど強力でないので、正直実装しにくいと思う。
むしろ、PerlやRubyのようなスクリプト言語の方が実装しやすいと思う。

【4】ジョブ管理ツールの機能としては、ジョブのスケジューリング、ジョブの異常を検知するなどのジョブ監視、ジョブの実行ログを収集するなどのメトリクス収集機能があげられるだろう。

このうち、3番目のジョブの実行ログを収集したり集計したり表示する機能は、Jenkinsは十分に必要な機能が実装されている。
不足したメトリクス集計表示の機能は、簡単に自作できる。

ジョブのスケジューリングは、月末のMM月DD日実行とか、毎日HH時に実行などのジョブ実行をスケジュール化する機能。
この機能はCronに相当する。
つまり、ジョブネットで表現された各ジョブは、Cronで実行すればいい。

但し、実際の業務のスケジュールは毎月のように変わる。
業界や会社ごとに、営業日は異なるから、毎月のスケジュールをきちんと作ることは重要だ。
例えば、日本の会社は月に1回、請求締めで顧客から売掛金をまとめて回収したり、仕入れ代金を一括払いするから、それらをジョブのスケジュールに組み込んでおく必要がある。

従って、Cronをそのまま埋め込むのは多分保守しづらい。
既成の製品は、スケジュールをインポートしたりエクスポートする機能があるので、Jenkinsでもそのような機能があれば、例えば、開発環境で実施したスケジュル設定情報を本番環境へそのまま移行する作業が簡単になる利点がある。

ジョブの監視をJenkinsで実現するには、Monitoring external jobs - 日本語 - Jenkins Wikiを使えばよいらしい。

また、Jenkinsでは、ビルドエラーが発生したらメール送信する機能が元々あるので、ジョブの異常を検知したら即メールする機能へ流用することもできる。
つまり、異常検知を関係者へフィードバックする機能はJenkinsに既にあり、そのまま流用できるし、Redmineへメールを送信したら、チケットが自動登録されるような仕組みへ発展させることもできる。

但し、ジョブの数が多いと、ジョブ監視の実装をそれぞれ行うのは手間がかかる。
Jenkinsのジョブ監視の設定も、既存の製品のように、もっと手軽に実現できるとよいだろう。

【5】以上のようにJenkinsをジョブ管理ツールと見なす場合、流用できる機能は結構あるが、まだ不十分な機能も多い。
だが、JenkinsはOSSなので不足した機能は自作すればいい。

特に、JenkinsはGroovyというスクリプト言語と相性が抜群に良いので、Groovyを使って実装する方法もあるだろう。
Jenkinsのプラグインは数えきれないほどたくさん作られており、ネット上でノウハウも公開されているので、不足した機能は皆でどんどん作っていけばいい。

Jenkinsには、たくさんの可能性が秘められていると思う。