サーバ1台で実現！並列分散処理によるCOBOLバッチ処理高速化のポイント(概要編)

検証内容

実証実験では、バッチ処理が長時間化しているCOBOL基幹システムを対象に、以下の内容を検証しました。

• サーバ１台から適用できる並列分散技術を用いて、運用が高コストとなる大規模な並列分散処理基盤がない場合でも、低コストで処理が高速化することを検証
• COBOLプログラムの分散処理化にかかる開発コストを抑えるにあたり、COBOL統合開発環境製品を活用して、既存のCOBOL資産をどの程度再利用できるかを検証

＊本稿は、2020年12月3日にプレスリリースを行った内容の詳細について紹介しております。合わせてご参照ください。

対象システム概要

本検証の対象は、オープン系COBOL環境で実行している、約8千ステップからなるシングルスレッドのCOBOLバッチ処理です。処理対象のデータ量はタイミングにより変わりますが、データ量に比例して処理時間が増加しており、今後データ件数が増加した場合に、定められた時間内に処理が完了できなくなる可能性がありました。

表1. 検証対象バッチの処理データ量および処理時間

	データ量が少ない場合	データ量が多い場合
処理対象データ	50万レコード程度	100万レコード程度
対象データサイズ	10GB程度 （関連マスタデータも含める）	12GB程度 （関連マスタデータも含める）
処理時間	03:11:10	06:15:58

バッチ処理の概要としては、入力となる処理対象データに対して、1レコードずつRDBへのアクセスを伴うデータの加工処理を行い、最終的に複数のファイル出力を行う処理となっています。

対象システム環境と検証環境の比較

今回検証に利用したハードウェアおよびソフトウェア情報は以下の通りです。

表2. ハードウェア情報

	対象システム環境 （オープン系COBOL環境）	検証環境 （並列分散処理環境）
CPUコア数	POWER8 processor 4.02GHz 8コア	XeonG 6140 2.3GHz 8コア
メモリサイズ	256 G bytes	256 G bytes
OS	UNIX系OS
ノード数	1台	1台

表3. ソフトウェア情報

	対象システム環境 （オープン系COBOL環境）	検証環境 （並列分散処理環境）
実行環境	Micro Focus COBOL Server 2.3J	Micro Focus COBOL Server 5.0J M3 for Batch Processing 0.1.2 （エムキューブド® フォー・バッチ・プロセッシング。以下、M3BP） Java SE Development Kit 1.8 Asakusa Framework 0.10.4
統合開発環境	Micro Focus Visual COBOL 2.3J （以下、Visual COBOL）	Micro Focus Visual COBOL 5.0J

「M³BP」と「Asakusa Framework」および「Visual COBOL」を組み合わせたバッチ処理の高速化事例は世界初※の事例となります。今回なぜこれらの技術を採用したのか、その背景についてご説明します。

※当社調べ（マイクロフォーカス社、ノーチラス・テクノロジーズ社への確認結果による）

技術選定のポイント

並列分散処理技術について

オープンソースの並列分散処理技術として有名なのはApache Hadoop(以下、Hadoop)や Apache Spark(以下、Spark)です。これらの手法は成熟したエコシステムを持ち、数百ギガやテラバイト級のバッチ処理においても高いスケーラビリティを示す、優れたフレームワークです。

一方で、今回対象としている基幹バッチのように、処理データ量が数十ギガ程度であることを考えると、データサイズに対してシステム基盤が大掛かりなものとなり、お客様のコスト負担も増加してしまいます。そこで、今回は基盤技術としてフィックスターズ社が開発したオープンソースのM³BPを採用しました。
M³BPは、小規模～中規模データを対象とし、1台のサーバ上で並列分散処理を行うためのデータ処理エンジンです。処理中の中間データをメモリ上に展開するため、処理対象データ量に応じたメモリ領域が必要となりますが、複数サーバでのクラスタ構成が不要となります。また、HadoopやSparkの場合に発生するネットワークやストレージのI/Oが減ることで、より処理が高速化するため、高い費用対効果が見込めました。

分散処理用バッチ開発フレームワークについて

分散処理環境におけるバッチアプリケーションを開発する為のJavaアプリケーションフレームワークとしては、ノーチラス・テクノロジーズ社が提供するAsakusa Frameworkを採用しました。Asakusa Frameworkが優れている点として、Hadoop MapReduceやSparkといった分散処理特有の文法を意識せず開発が可能となる点や、テストや外部システム連携用のユーティリティが豊富である点が挙げられます。また、コンパイル設定を変えるだけで、単一のソースコードからHadoopやSpark、M³BP上で実行するためのバイナリファイルの生成が可能となります。

そのため、バッチ処理が小規模～中規模（数十G byte程度）の場合には、実行環境として導入コストが低く費用対効果の高いM³BPを適用し、サーバ１台のメモリ上に収まらないような、より大規模なデータ処理が必要になるに従って、実行基盤をSparkやHadoopへ移行させるなど、柔軟に構成の変更が可能となります。

バッチ開発環境について

コストを抑えて基幹バッチを再構成するにあたっては、どれだけ現行の資産を再利用できるかが重要なポイントとなります。本検証においてはCOBOLプログラムをAsakusa Framework上で実行するため、Javaプログラムとして再開発する必要がありましたが、Micro Focus 社の提供するCOBOL総合開発環境製品であるVisual COBOLを活用することで省力化しました。
Visual COBOLには、手続き型の COBOL プログラムからJVMクラスバイナリを生成する機能があります。また、COBOLプログラムを修正する場合にも、Javaと同様の統合開発環境であるEclipse IDE上で作業でき、スムーズな開発が可能でした。

検証結果

処理速度について

並列分散環境での処理時間は以下の通りです。表内で”本処理”と表記しているAsakusa Frameworkでのバッチ処理時間以外にも、前処理、後処理でかかった時間も参考情報として記載しています。

表4. 計測結果

	対象システム環境 オープン系COBOL環境での 処理時間	検証環境 並列分散処理環境（M3BP）での 処理時間
前処理	該当処理なし	00:50:35
後処理	該当処理なし	00:01:05
本処理	06:15:58	00:17:16

オープン系COBOL環境では6時間15分程度かかっていた本処理が、Asakusa FrameworkとM³BPを使用した並列分散処理環境では17分程度となり、大規模な分散処理基盤がない場合であっても、約20倍高速となることが分かりました。

Asakusa Frameworkで使用するデータはローカルに配置されている必要があり、前処理としてDBからのエクスポートに50分程度の時間がかかっています。ただし、バッチ処理毎に全量エクスポートする必要はないため、差分同期の仕組みの検討や、本処理とは別の時間帯で事前エクスポートすることで、効率的に実行することができると考えています。

現行COBOL資産の再利用について

約8千ステップであった既存COBOLソースコードのうち約93%が再利用でき、さらに約63%はコードの修正なく再利用可能でした。

RDBからの呼び出し箇所や関連データの結合処理など、Asakusa Frameworkの作法に依存するコードや、COBOLから生成したJavaクラスを呼び出すためのラッパークラスの作成が一部必要となりましたが、Visual COBOLを活用することで再開発にかかるコストを抑えることが可能でした。

次回以降は、具体的な前処理、後処理の内容と本検証において苦労した／工夫したポイントについてご紹介します。

 

 

＊エムキューブド®は、株式会社フィックスターズの登録商標です。

＊Asakusa Framework™は、株式会社ノーチラス・テクノロジーズの登録商標です。

＊Visual COBOL は、英国、米国、およびその他の国における Micro Focus、その子会社、関連会社の商標です。

＊Hadoop®、Spark™は、Apache Software Foundationの登録商標または商標です。