「アシストにはこれからも頼りたい」基幹システムのバッチ刷新、監視集約・統合管理で業務効率化

株式会社ジェイテクト では、長年に渡り複数システムのジョブ管理でJP1を利用してきました。
2017年から始まった、基幹システムをホストからオープンシステムへと再構築するプロジェクトでも、ジョブ管理はJP1を利用することが最初に決まったと言います。これには、アシストのJP1サポートを高く評価していることも一因と、株式会社ジェイテクトの原幸輝氏は言います。

原氏 　私自身がJP1を利用したシステムでも、エラーが出たときなどサポートの方には何度も助けていただきました。本番稼働後にはJP1ではなくキックされた先のバッチ異常もありましたが、調査と回避策検討まで一緒にしていただくなど、他社にはない手厚いサポートで大変助かりました。その様なサポートの良さもあり、基幹システムを刷新する際にジョブ管理はJP1をアシストから採用することを最初に決めました。

同時期には、監視業務全般の見直しも検討が進められていました。

原氏 　従来、JP1と言えばジョブ管理と思っていました。同僚がアシストのセミナーに参加し、監視から運用全般までを製品群として持っていると知り、たまたま監視ツールを探していたため、詳細を確認、検討した結果、JP1の監視ツールとZabbixもまとめて採用しました。

基幹システムの刷新は、オープン系でいちからバッチ基盤を作る必要がありました。アプリケーション数は30と多く、アプリケーション毎に担当SEも違えば開発ベンダーも違い、並行して開発が進むというものでした。これに対応するためJP1/AJS3の利用でも、いくつかの工夫をしています。

開発時のミスで、他のアプリケーションファイルが削除されることが無いよう、アプリケーション単位でお互いに干渉しない構成が求められます。これに対し、分けられるところは全て分け、影響しないようにしたと原氏は言います。

原氏 　アプリケーションとデータベースはサーバを分けています。ジョブスケジューラーはJP1ユーザーとジョブグループ、バッチはOSユーザーとフォルダを分けて権限を付け、Oracle Databaseはスキーマで分けました。JP1だけでなくOracle Databaseもアシストに構築してもらい、この構成の提案を受けました。

アプリケーションごとに要件の変わらないログは共通仕様が求められました。これは、コーディングの標準化でも可能ですが、JP1/ASを利用しています。

原氏 　ログ仕様が揃うだけでなく、自動的にログが出力され1行コードを書く必要すらない。JP1/AJS3に連携できるため、開発者はJP1/AJS3-Viewだけを見れば良く、わざわざログをサーバに見に行く必要がない。これにより、かなり開発効率が良くなりました。

開発は順次進行するため、システムには拡張性が求められます。1日あたりのジョブ実行数は、当初12,000回の要求があり、全30アプリケーションでは数万回が予想されたため、これに対応できる構成が求められました。そこで、JP1/AJS3の性能面とバッチ属性を踏まえ、無駄なくリソース増強が可能なようにJP1/AJS3スケジューラーサービスを分ける工夫をしたと言います。

原氏 　弊社では日次などで動く「通常ジョブ」と、Web系などオンラインで要求される「即時実行ジョブ」で、スケジューラーサービスを分離しました。通常ジョブの負荷が高くなってきたら通常ジョブを増やし、即時実行の負荷が高くなればそちらを増やしと、必要なものを無駄なく増強できる拡張設計としました。

現在までに、順次アプリケーションの開発、本番稼働を迎えていますが、開発や運用での混乱はなく、1日あたり十数万回のジョブが性能的な課題も無く、安定して実行されています。

基幹再構築を始める時期、それまで使っていた監視ツールのサポートが終了ということもあり、単純なソフトウェア変更だけでなく、運用の見直しも行うことにしました。過去の運用状況から業務の見直しは、監視の仕組み、対応遅延の対策、対応状況の共有、そしてこれらを一連の仕組みとして確立するなどの視点で検討が進められました。

それまでの運用は、OSとミドルウェアの監視はソフトで行っていましたが、機器は個別に監視設定をしていたため手間がかかっていました。通知方法はどちらもメールであったため、担当者の認識が遅れ対応が遅れることもありました。

これを、個別の監視設定ではなく監視システムへの集約。すぐに異常に気が付くことができ、見逃さない仕組み作りを検討しました。

原氏 　新監視システムでは、OS、ミドルウェア、機器などの監視はZabbixにまとめました。監視集約により、個別設定に比べてメンテナンスの手間も削減されました。監視情報はJP1/IMに自動連携し、各業務担当のグループ長席にパトランプを設置し、光らせるようにしました。物理的に止めるまでパトランプが鳴るので、担当者の見逃しはなくなりました。Oracle Databaseは、Oracle EMCCに監視設定を集約し、JP1/IMにアラート連携を行い、以後はOSなどと同じ様に対応できるようにしています。

異常通知に対応するインシデントは、従来対応が完了したら報告書を回付する運用だったため、調査中なのか処置中なのかをリアルタイムに解る仕組みではありませんでした。

これを、インシデント管理ツールを利用することで、対応状況の共有ができるようにしています。

原氏 　異常対応は、JP1/IMからインシデント管理のJP1/SSに自動連携し、リアルタイムに情報を更新するようにしました。自動起票が行われるため、初動での起票もされ、起票漏れが無くなります。また、室内に大型モニターを設置しJP1/SSの画面を出すことで、全員に対応状況が共有できるようにしました。なおシステム対応は、復旧完了で一旦クローズしますが、問題管理にエスカレーションし、再発防止が完了するまでフォローをする仕組みとしました。

なお、コロナ禍で在宅勤務となってからは、運用を一部見直しをされています。

原氏 　在宅勤務でパトランプ運用ができなくなりましたので、利用者に影響が出ているか一目でわかるような仕組みを作り、各担当者の端末から見れるようにしました。また、対策会議は、パトランプがなると会議テーブルに集まって対策検討をしていましたが、今はリモート会議をしています。

原氏 　基幹システムの再構築は今も継続中で、大型アプリケーション開発が控えています。監視システムはできたものの、運用改善は未だこれからも進めていく必要があります。引き続きアシスト様にご支援いただきながら今後も課題を乗り越えていきます。

※お客様情報は取材時の内容に基づくものです。