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

2021.05.18

  • クラウド・マルチクラウド
  • 内製化支援

1台のサーバ上で構築可能なオープンソースの並列処理基盤を用いて、コストを抑えてCOBOLバッチ処理を約20倍高速化した実証実験について、詳細をご説明します。本稿では、第3弾「実装編」としてMicro Focus Visual COBOLとAsakusa Frameworkを用いたバッチ処理において、実装時に考慮した点やチューニングにおけるポイントを解説します。


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

Micro Focus Visual COBOL利用における注意点

本検証では並列処理プログラムからCOBOLモジュールを利用可能にするための開発コストを抑えるにあたり、マイクロフォーカス社が提供するCOBOL統合開発環境製品である「Micro Focus Visual COBOL(以下、Visual COBOL)」を使用しました。

本製品を使用し、COBOLプログラムをJavaプログラムとしてコンパイルした上で、分散処理フレームワークであるAsakusa Frameworkから呼び出しを行っています。Visual COBOLを用いることで、既存のCOBOLプログラムの約63%はコードの修正なく再利用可能でしたが、以下のポイントについては、既存モジュールの修正が必要となるため注意が必要でした。

Cプログラムの書き換え

COBOLモジュール内からCプログラムを呼び出している場合、Javaプログラムへの自動コンパイルをすることはできません。そのため、JavaプログラムからCプログラムを呼び出すための仕組み(JNI/JNA)の検討や、Javaプログラムへの書き換えが必要となります。

マルチスレッド処理の対応

COBOLモジュール内でWORKING-STORAGE SECTIONに定義したデータ項目はVisual COBOLを使ってJVM上で直接実行可能なバイトコードへコンパイルすると、staticフィールドとなってしまいます。
一方、Asakusa DSL(Domain Specific Language)で記述したバッチのコードはAsakusaコンパイラで並列処理(マルチスレッド)プログラムとして生成されるため、データ競合が発生する可能性があります。

そのため、staticでないフィールドにコンパイルされるLOCAL-STORAGE SECTIONで定義するように手動での修正が必要となりました。

ラッパープログラムの作成

COBOL固定長文字列型などの一部のデータ型は、Javaプログラムで対応していません。そのため、COBOL-Javaプログラム間でパラメータ連携する際は、データ型を変換するためのラッパープログラムが必要となりました。

また、COBOLプログラムが手続き型COBOLの場合には、複数のJavaクラスからの呼び出しができないため、こちらもクラス型COBOLのラッパープログラムを作成し、その中から手続き型COBOLの処理を呼び出すように修正しました。

Visual COBOLにはラッパープログラムを自動生成するためのSMARTLINKAGEと呼ばれる機能がありますが、COBOLモジュール内にOCCURS項目が定義されている場合など、条件によっては利用できません。OCCRUS句で定義されたデータはCOBOL内では「参照渡し」ですが、スタック・マシンのJVM上では「参照渡し」が使えません。JVM上では「値渡し」であるため、OCCURS句のデータをそれぞれオブジェクトに詰め込み「値渡し」するためのラッパークラスを手動で作成する必要があります。

Visual COBOLを使うことで大幅に省力化は可能ですが、上記のようなプログラム改修は必要となるため、工数の見積もりの段階で、どの程度改修が必要となるかを考慮する必要があります。

Asakusaデータ結合処理のチューニング

今回の検証対象のバッチ処理では、対象のトランザクションデータに対して、データ量が10GByte程度となるマスタデータを結合し、処理を行ったうえで出力を行います。

図1. 処理概要

Asakusa DSLでは、「演算子」とよばれるAPIが提供されており、この「演算子」を使ってバッチ処理フローを開発していきます。「演算子」は、その処理内容でいくつかに分類されており、今回の結合処理では「結合演算子」を利用しました。また、「演算子」は、その性能特性からも分類されており、今回は下記のものを検証しました。「演算子」(API)によって結合処理におけるパフォーマンスに大きく差が出るため注意が必要でした。

MasterJoin系演算子の利用

トランザクションデータとマスタデータが完全一致するキー項目を持ち、1対1で対応する際に使用可能。

CoGroup系演算子の利用

トランザクションデータとマスタデータが完全一致するキー項目を持つ場合に使用可能。1対多、多対多でも使用可能。

ビューAPIを使ったユーザ演算子の利用

演算子は独自に開発できます。これはユーザ演算子とよばれます。今回は、任意の演算子と組み合わせてプログラム内でマスタデータにアクセスできるユーザ演算子を開発しました。最も柔軟にデータの結合が可能でした。
 
検証対象のバッチ処理では、トランザクションデータとマスタデータを前方一致で1対多結合する処理があります。当初はビューAPIを用いてプログラムのロジックで前方一致を判定し結合していましたが、JVMのヒープ領域を70GByte程度割り当てた場合であってもOutOfMemoryエラーが発生し、処理が完了しない問題がありました。
 
そこで、ビューAPIの利用箇所はすべてCoGroup演算子を利用するようにチューニングしました。その際、CoGroupではトランザクションデータとマスタデータが完全一致するキー項目を持つことが前提となるため、マスタデータとトランザクションデータにそれぞれ前方の文字を保持させたインデックス項目を追加することで対応しました。
実現したい処理:キー項目を使用し、マスタデータを1対多、前方一致で結合したい。ただし、CoGroupでは前方一致に対応していない。 実装におけるポイント:キー項目をもとにインデックス項目を作成することで、完全一致で結合することが可能になる。 

今回は前方一致であったため、このような方法をとることができましたが、中間一致等の曖昧検索があるバッチ処理においては、別の方法を検討する必要があります。

Asakusa Frameworkを用いた場合、実装自体はJavaエントリーレベルで十分対応できますが、本検証では処理設計に不備があったため手戻りが発生してしまいました。

そのため、Asakusa Frameworkを用いた開発においては、挙動や前提知識についてしっかりと理解した上で設計に臨むことが重要となります。

まとめ

本連載では、3回にわたりM³BP、Asakusa FrameworkとVisual COBOLを活用したバッチ処理高速化事例についてご紹介しました。

レガシーシステムのオープン化においては、オープン系言語で再開発するためのコストや処理性能の低下が多く課題となります。既存のバッチ処理に対して、Asakusa FrameworkやVisual COBOLが適用できるかは事前検証が必要ですが、上記の課題に対して非常に有効な組み合わせだと考えます。

三菱総研DCSでは、基幹バッチの並列処理環境もしくは並列分散処理環境をクラウド上で利用できるソリューションの2021年中の提供開始を目指しています。

  • Asakusa Framework™は、株式会社ノーチラス・テクノロジーズの登録商標です。
  • Visual COBOL は、英国、米国、およびその他の国における Micro Focus、その子会社、関連会社の商標です。

関連するソリューション・サービス

関連するナレッジ・コラム