はじめに
デジタルイノベーショングループ所属の朽方です。
私の携わったプロジェクトではJP1運用が多いのですが、「JP1ってどう設計したらよいかよくわからない…😣」とよく相談されるため、初級中級者向けにJP1のジョブ設計、簡単なポイントをまとめてみました。
JP1は自由度が高いため、設計者の個性が強く出ますが、運用管理としては好ましくないジョブ構成というものもありますので、設計の一助になれば幸いです。
JP1とは
JP1は日立製作所が開発・発売している日立オープンミドルウェアシリーズのひとつで、1994年に発売されたソフトウェア。統合システム運用管理ツールと位置付けられ、運用ツールとしての日本国内シェアは約27%でトップクラスである
出典: Wikipedia
類似の製品には、富士通さんのSystemwalker、NTTデータさんのHinemosなどがあります。
ジョブのワークフロー管理機能だけ見ると、DigdagやApache Airflowとも似ていると思います。
JP1導入パターン
まず、JP1のジョブ設計をはじめる以前に最初に決定・確認しなければならないことがあります。
新システムのJP1をどこに構築し、誰が運用するか、そしてJP1設計ルールが準備済みかです。
パターンとしては、ざっくり以下２つになります。
[パターン1] 専用JP1
ジョブ数が数万を超えるような大規模システムは、１システムで専用JP1を用意するケースが多いです。
メリットは、１システムでJP1を専有できるため、他システムのジョブ増大による影響（実行遅延等）を受けることが無い点です。
デメリットは、JP1ライセンスやサーバ運用費など、コストの増大です。災害対策等でサーバ構成を二重化する場合は、さらにコストが増えます。
[パターン2] 相乗りJP1
ジョブ数が数百、数千程度の小・中規模システムであれば、既存JP1サーバに相乗りさせ一括管理も可能です。公式ドキュメントによると、１日の処理ジョブ数１万件以下（最大5万～10万件）、１時間当たりのジョブ量1,000件以下（最大5千件）が推奨されていますので、この範囲に収まるようであれば追加もありでしょう。
主たるメリットは、JP1ライセンスやサーバ運用費など、コストの削減です。また、運用・監視もあちこちのJP1サーバにログインする必要がなく、運用者に優しいです。
デメリットは、各種制約が増え、調整が多くなることです。細かいですが、いくつか具体例をあげてみます。
- 運用部門が厳格なJP1設計ルールを設けておく必要があります。各システムのジョブ設計者が規約無く好き勝手にジョブ設計すると、バベルの塔のようなカオスジョブになります。
- JP1 Viewerでログインすると、同時接続数上限に達しログインできなくなることがよくあります。各システム１、２名利用でも、数十システムもあると上限（デフォルト32）に達してしまいます。
- 共通ユーザが公開されている場合、（主にテスト環境で）A社システム担当者にB社システムのジョブが閲覧される懸念もありますし、その延長でジョブが誤って登録実行される事故もあります。
（スケジューラ毎に専用ユーザを作成する、ジョブ毎にアクセス権を設定する、等で回避は可能です。） - JP1カレンダを変更してスケジュールテストをする際、他システムが影響を受けるため、実施時間をずらすなどの調整が必要になることもあります。
システム規模と運用監視体制を考慮し、しっかりと協議、決定しましょう。
当たり前ですが、パターン1、2いずれでもシステム拡張でジョブ数が増えるとサーバ性能要件も上がり、スケールアップ/スケールアウトさせる必要は出てきます。
JP1設計の進め方
トップダウン型
システム全体のジョブフローのイメージができており、各業務、組織間の依存関係が明快な場合に向いています。ジョブネットの上の階層から、順番にサブジョブネットを設計していきます。設計責任者がすごくしっかりしている場合か、小規模、単純なシステムの場合に向いています。（実際の現場では、そんな都合よく行くことは少ないですけど。。）
ボトムアップ型
システム全体のジョブフローが曖昧でとりあえず手探りで進めるような場合や、各業務、組織間の依存関係が複雑な場合に向いています。
CRUD等を元に枝葉のジョブを１ジョブネットで書き、ジョブネットにグルーピングしていくようなイメージです。DWHのように依存関係が複雑なシステムでよく見ます。
JP1のジョブ設計ポイント
それでは次に、本題のJP1ジョブ設計のポイントに移りましょう。
前述のパターン２の場合は、すでにJP1設計ルールがあるはずです。必ずルールに従って設計を行いましょう。
- ジョブの命名ルールは〇〇
- ジョブネットは△△、□□単位でグルーピングすること
- ジョブネットの階層数は最大N階層まで
- ■■機能は使用不可
など。
個人的に考える設計ポイントは以下です。
- 依存関係を意識して、ジョブネットを作成する
- スケジュール（サイクル）によって、ジョブネットを分割する
- ジョブの正規化に気をつける
ボトムアップ工程での、簡単な例で説明していきましょう。
（あくまで説明用のジョブで、業務的な意味はないです）
＜図1: 1階層＞
中央でファイル監視1～5、取込1～5がパラレルで処理されています。
5セット程度であれば可読性に問題有りませんが、もし50セットの場合はどうでしょう？
＜図2: 1階層⇒サブジョブネット作成＞
ルートジョブネットがすっきりしましたね。可読性を上げるため、ジョブネットにまとめてしまいましょう。これにより依存線を引く回数も5×2本→1×2本まで減らせます。
その他に業務、処理、組織、システム等でジョブをグループ化し、可読性、生産性が高いジョブ設計を意識しましょう。
話がややこしくなるのは、１ジョブが複数のジョブと依存関係持っている場合です。
＜図3: 1階層（ジョブ追加）＞
取込5のデータを使って、「重い処理」を先行して処理したい要件が追加された
とします。１階層で表現すると、上記のようになります。
ジョブネット化し可読性を上げる場合、いくつかパターンがあります。ジョブネット名の整合性、可読性、待ち時間等にトレードオフが発生しますので、４パターンほど見てみましょう。
※ジョブネットを跨ぐ関連線は設定できません
対応パターン①
「ファイル取込」というグループにファイル取込5が含まれていません。例外が存在し、混乱を招きそうです。
対応パターン②
「ファイル取込」というジョブネット名に合っていない「重い処理」が含まれることになります。こちらも運用で混乱を招きそうです。
対応パターン③
ファイル5が取り込み終わっていても、ファイル取込1～4が終わっていない場合、「重い処理」が実行されません。無駄な待ち時間が発生してしまいます。
対応パターン④
ジョブネット間の依存をイベント送受信で実現します。（青線部分）
ファイル取込はグループ化され、各種処理は同じルートジョブネット階層に配置されています。
（例は1階層の小さなジョブですので、そこまでするかという気もします。）
運用上は、パターン④が面倒なため、パターン①～③で楽をしてしまいがちです。
その他に、ジョブネットコネクタ連結、ファイル作成→ファイル監視等でも可能ですが、細かなバリエーションは無数にあるので割愛します。
スケジュールによる分割とジョブの正規化
次に意識したいのはジョブの正規化です。
上のサンプルですが、
- 上段の平日ジョブは、社員が出社している日だけ実施します
- 中段の日次ジョブは、平日でも休日でも毎日行います
- 下段の休日ジョブは、社員が出社していない休日にのみ行うメンテナンス処理です
スケジュールはジョブではなく、ジョブネットに設定するため、ジョブネットを作成しスケジュールを分ける必要があります。
パターン① 2分割
ルートジョブネット「平日ジョブ」（スケジュール：運用日）
ルートジョブネット「休日ジョブ」（スケジュール：休業日）
の２ジョブネット構成です。
パターン② 3分割
ルートジョブネット（スケジュール：絶対日）
サブジョブネット「平日ジョブ」（スケジュール：運用日）
サブジョブネット「休日ジョブ」（スケジュール：休業日）
の３ジョブネット構成です。
違いがわかりますでしょうか。どちらが正解ということは無いのですが、パターン①の場合、「サーバ起動」などの日次ジョブが平日と休日の両ジョブネットで２重に定義されています。これは正規化という観点からは好ましく有りません。
仮にジョブ設定に修正が発生した場合、N箇所対応せねばならず、作業漏れなどが発生しがちです。ほぼ変更が発生しないようなジョブであれば、二重定義も有りかとは思いますが、ジョブ設計方針を確認の上で分割を検討しましょう。
以上、初級中級者向けのJP1設計ポイントでした。