SAPでよくある「夜間バッチ問題」をどう解決するか
INDEX LINK
はじめに
SAP ERPのシステムでは、アドオンプログラムをJP1登録し、夜間バッチ処理を実装することが多いと思います。
夜間バッチは定常業務を安価に自動化できる手法ですが、どちらかといえばアナログなやり方で、さまざまな問題が生じます。
今回は、運用年数が長くなるほどに問題が増える夜間バッチ処理の解決方法について解説します。
1.夜間バッチ処理でありがちな問題
まず、夜間バッチ処理でありがちな問題を把握しておきましょう。
1-1.そもそもスケジュールが空いていない
夜間バッチ処理を実装するためには、夜間のバッチ実装スケジュールに空きがなければいけません。
このとき、スケジュールに空きがないと実装自体が困難になります。
例えば以下のようなケースです。
・業務時間終了後、システムの20時にオンライン処理が終わる
・最初のバッチ処理が21時10分に開始
・前提ジョブの実行が21時半に終わる
・新規実装するバッチ処理は処理終了までに1時間半を要する見込み
・後続のバッチ処理が開始されるまでに70分程の空きしかない
バッチ処理はジョブ登録されたうえで、既定の時刻になると自動的に実行される仕組みがほとんどです。
ただし、あるジョブが実行されるためには前提のジョブが正常終了している必要があります。
また、後続のジョブの開始までに処理が終了していなければなりません。
こうした事情から、運用期間が長くなるほどに夜間ジョブの登録数が増え、スケジュールに余裕がなくなるのです。
上の例では、新規バッチ処理のためのジョブに90分の処理時間が必要ですが、空きが70分しかなく、ジョブスケジュール全体の見直しが必要になっています。
ジョブスケジュールの見直しは、ジョブの再配置やJP1上での軽微な改修、既存プログラムの見直しなどを含むため、工数が大きくなりがちです。
1-2.繁忙期の帳票作成に時間がかかりすぎる
夜間バッチ処理で法定帳票に必要なデータ処理を行っている場合、繁忙期になるとデータ量が増え、著しく処理速度が落ちることで業務に支障をきたす場合があります。
上の例のように、最終的にはジョブスケジュール全体の見直しが入る可能性もあるでしょう。
また、プログラムの処理方法を変更して時間効率を高めるやり方もあります。
しかし、バッチ処理は「一定量のデータを溜めて、任意のタイミングで一括処理する」という方法だけに、処理速度の改善には限界があります。
安定した処理が可能である一方で、ソフトウェア側だけでの処理速度改善は難しいのです。
2.夜間バッチ問題を解決する方法
夜間バッチに関する問題はシンプルなものが多いのですが、それだけに解決方法にも限りがあります。
現実的な解決方法としては以下が挙げられるでしょう。
2-1.データベースパフォーマンスのチューニング
データベースクエリの実行計画を分析し、必要に応じてインデックスを追加することで、データアクセスの効率を高めます。
また、データベースの設定（キャッシュサイズ、クエリオプティマイザのパラメータなど）を調整し、バッチ処理に特化した設定に最適化することも重要です。
DBのチューニングは確かに効果的なのですが、コストがかかります。
またテストの準備などである程度の期間が必要であり、「できるだけ安くなんとかしたい」という場合には不向きかもしれません。
2-2.バッチ処理アルゴリズムの最適化
バッチ処理を行うアルゴリズム自体を見直し、無駄な処理がないか、より効率的なアルゴリズムに変更できないか検討します。
例えば、データの前処理やフィルタリングを効率的に行うためのアルゴリズム改善、並行処理が可能な箇所の検討などが含まれます。
アドオンプログラムの内部処理がいまいちな場合は、かなり効果的です。
無駄にループしていないか、1件1件Insertしてコミットしていないか、などをチェックしていくことで処理時間が大幅に短縮されることもあります。
また、意外と見落としがちなのが「ほかのバッチと同じテーブルに書き込んでいる」というケースです。
ジョブスケジュールで同時刻に他のバッチが動いている場合、まったく同じテーブルに対して書き込みを行っているとパフォーマンスが低下します。
2-3.メモリとCPUの使用の最適化
バッチ処理プログラムが使用するメモリの量を監視し、メモリリークや無駄なメモリ使用を特定します。
また、CPU使用率が高い箇所をプロファイリングツールで特定し、アルゴリズムの最適化や並行処理の導入を検討します。
2-4.分散処理と負荷分散
バッチ処理を複数のマシンやプロセスで分散して実行することで、単一のマシンにかかる負荷を軽減します。
このためには、Apache HadoopやApache Sparkのような分散処理フレームワークの利用を検討すると良いでしょう。
2-5.非同期処理の導入
データの読み書きや外部システムとの通信などを非同期で行い、待ち時間中のCPUのアイドルを防ぐ方法です。
これには、非同期プログラミングの技術やメッセージキューを使用することが含まれます。
ただし、これは業務やシステムの仕様上難しいこともあるので、あくまでも参考として頭の片隅置いておくくらいでよいでしょう。
2-6.HANA DBの導入でオンライン処理してしまう
大抵の問題はこれで解決してしまうと思います。
HANA DBはバッチ処理の時間短縮に非常に強いのですが、いっそのこと日中にオンラインで処理してしまうことで、夜間バッチの問題を一気に解決できます。
例えば、MySQLを使ったBOM（部品表）の階層データ作成などは、どうしても長時間になりがちで、夜間バッチに組み込まれていることが多いでしょう。
また、CTEなどによる再帰的な問い合わせによってテーブルを参照し、階層データを作り上げていくという手法の性質上、高速化が難しいという側面もあります。
しかし、HANA DBならば標準で組み込まれている階層関数（HIERARCHY Function）により、超高速（ほぼリアルタイム）で階層データが作れるので、夜間バッチに組み込む必要すらありません。
その効果は凄まじく、100万件あたり1000秒以上かかっていた処理が、0.01秒に短縮されるレベルです。
つまり、バッチ処理という方法論を使う必要がないのです。
まとめ
今回は夜間バッチ処理でありがちな問題と解決方法について紹介しました。
夜間バッチ処理は、方法論としてとても優れていますが、現在のビジネス環境には合っていません。
また、長年にわたる基幹システム運用でジョブスケジュールの枠を使い切ってしまっていると、有効打が存在しないこともあります。
こうした場合は、HANAのもつ機能を駆使してオンライン化してしまう方向で検討してみても良いでしょう。
