新旧問わず多くのシステムで、バッチ処理が行われています。バッチ処理といっても夜間バッチやオンラインバッチなど用途や規模、複雑さなど、様々ですが、共通して言えることはほとんどモニタリングが行われず、あってもバッチの開始、終了および異常終了時のアラート通知だけのモニタリングが一般的です。バッチ処理は時間通りに終わるもので、オンライン処理に比べ障害が少ないという認識がモニタリングをしない要因の一つにあります。

しかしながら、サービスの停止や売上や顧客信用度に直結する現在、障害時の復旧の速さもさることながら、障害を事前に防ぐための日常的なパフォーマンスのチェックも重要となってきています。また、オンプレミス環境からクラウド環境への移行においても、客観的な性能データを用いた設計、開発、テストを行うことで、安定稼働に繋げることが可能となります。

今回はバッチ処理をJENNIFERでモニタリングすることの有効性を紹介します。

チューニングの必要性

バッチ処理では設計・導入当初から時間の経過と共に稼働環境が変化していきます。ビジネスの拡大により、データ件数の増加、データの複雑化が進み、度重なる機能追加も発生します。日々のバッチ処理で主体的にチューニングまで行うことは、人的リソースや時間的にも厳しい状況が少なくありません。

しかし、チューニングが必要なケースはいつ発生するか分かりません。実際、次のようなケースが発生したことはないでしょうか？

・処理時間が想定を超えてしまう突き抜け状態
・アプリケーションの処理や他システム連携処理が想定時間よりも長くかかるようになった
・オンラインとバッチの並行処理でのハードウェアのリソース不足が発生する

このような事態に陥った場合、場当たり的な対応ではなく恒久的な対処が必要となってきます。

インフラ環境の強化

先ず、最初に考える対応は、サーバの分散処理や並列処理またはCPUやメモリといったハードウェアのリソースの増強を検討することでしょう。

しかしながら、ハードウェアの増強、例えばCPUやメモリを2倍にしてもスループットは2倍とはなりません。CPUをアプリケーションがうまく使いこなせなければ、それほど役には立ちません。また、予算に制限がなければ問題はありませんが、現実的にはかけられるコストとの相談になるでしょう。

このようにハードウェアの強化の最適値を算出することは、非常に困難と言えます。そこで実際の処理時間を計測し、その数値を元に最適値を算出する必要性が出てきます。

処理時間の計測と課題

一口にバッチ処理時間といってもアプリケーション処理時間や、SQL時間、外部呼出し時間など、複数の要素の時間で構成されています。これらの処理時間を把握し、ボトルネックを特定してから原因に対して適切な対処をする必要があります。

この課題に対してJENNIFERは、バッチ処理専用のモニタリング機能で開始から終了までの各要素の時間を効率よく把握することができます。

また、もう一つの課題としては人的リソースの問題です。各システムのログを収集してデータを分析するためには、それ相応の時間に知識と経験が必要となりますが、対応できるエンジニアは多くなく、複数のプロジェクトを掛け持ちして時間的に余裕がないことが多いです。

そこで、JENNIFERでモニタリングをすることで、運用担当者がデータ収集、ボトルネックとなりそうなポイントの絞込みまで行うことが可能となり、人的な問題も解消することができます。

JENNIFERのバッチ処理モニタリング画面

誰でもできるモニタリング

日常的なモニタリングとしては、バッチ処理の開始、終了、異常終了の３つに対応します。

①バッチ処理の開始

バッチ処理の開始については、開始時点でアラートを発生させる方法が一般的です。しかし、　毎日、多くのバッチ処理が開始される度にアラートが通知されると、内容を確認することもなくなってきます。また、バッチ処理が開始されない場合はアラートが通知されないため、誰も気づかない可能性が高くなります。JENNIFERではAIイベント機能を使用して、過去データとの比較から定時にバッチ処理が開始しない場合に、アラートを発生させることが可能です。これは開始の日付または曜日と開始時間が決まっているバッチ処理に適用できます。

②バッチ処理の終了

バッチ処理が想定した時間内に終了した場合は問題ありませんが、終了しない「実行時間の突き抜け状態」の場合にはアラートを発生させることが重要です。特に夜間バッチのように業務開始までに終了しなければならない処理は緊急対応が求められます。JENNIFERでは定義した時間にバッチジョブ（トランザクション）が終了しない場合にアラートを発生させることが可能です。

③バッチ処理の異常終了

バッチ処理の異常終了時には、バッチ処理プログラムがジョブ管理ツールに異常終了の結果を返すケースが多いです。そこからJENNIFERで原因と思われる箇所の絞込みを行います。そのモニタリング機能は直感的な操作が可能なため、システム開発の未経験者でも問題なく使用することができます。原因を絞り込み、開発担当者と連携することで迅速な障害復旧を可能とします。

モニタリングを継続する

バッチ処理のチューニングの目的は、システムを最適化して求められる業務性能を満たすことですが、対応方法は様々です。過去の分析との比較は、原因の絞り込みや対策の立案に役立てることができます。また、立案と並行して、新たな監視項目の追加や閾値の見直しをすることで、性能管理の仕組みをブラッシュアップすることができます。

システムの状態を継続的に計測し、把握する活動は、即座に価値を生み出すものではありませんが、最悪の事態に備えるために一定の対価を支払うという意味で、保険と似ています。問題が顕在化してから対処し、再発防止策を講じるといった方法だけでは限界が生じます。システムライフサイクルの中で問題が発生する可能性やその影響を考慮して、適切な性能管理を検討することが肝要です。