2021.4.22

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

  • ITインフラ&オペレーション

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


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

Asakusa Frameworkバッチ処理設計のポイント

Asakusa Frameworkを用いたバッチ処理の設計におけるポイントについてご説明します。バッチ処理設計にあたっては、ノーチラス・テクノロジーズ社で提供されている設計ガイド に則り、以下4つの観点で検討を進めました。
  • バッチ処理一覧
  • 外部インターフェース設計
  • データフロー設計
  • データモデル定義

バッチ処理一覧

対象バッチの一覧と処理概要を実行単位に整理します。
本検証ではあらかじめ対象のバッチ処理が定まっているため省略しました。

外部インターフェース設計

バッチ処理における入出力方式を検討します。

Asakusa Frameworkでは、Direct I/Oと呼ばれる、分散ファイルシステム上のファイルを読み込み、書き出しを行う方式と、WindGate と呼ばれる外部システム連携ツールを選択可能です。WindGateを使用することで、RDBMSなどの外部システムと柔軟に連携することが可能ですが、Direct I/Oに比べて速度が上がりづらいというデメリットがあります。

本検証で対象にしたバッチ処理においては、処理内で使用するデータサイズが大きく速度面に不安があったこと、前後のバッチ処理とのデータ連携を考えた際に、ファイルでの入出力で問題がなかったことから、Direct I/Oを採用しました。

データフロー設計

検証対象のバッチ処理の流れを整理し、それぞれの処理での入力データ、処理内容、出力データを詳細に定義します。

Asakusa Frameworkの処理ではあらかじめ用意された「演算子」と呼ばれるAPIを使用します。演算子には複数の種類があり、データの更新を行う演算子や、結合・集計処理を行う演算子などを組みあわせてバッチ処理の流れを定義していきます。そのため、データフロー設計の中でどの演算子を使って処理を行うかも含めて整理しました。

データモデル定義

データフロー定義で整理した入力データ、出力データに対して、項目の整理を行います。

バッチ処理の中では、処理対象レコードに対してデータの追加が必要となることがあります。その場合には、中間モデルとして追加データを定義したモデルを別途用意する必要があるため、中間モデルについてもあわせて整理しました。

上記4つのポイントに沿ってバッチ処理設計を進めましたが、今回対象としたCOBOLバッチ処理では、Asakusa Frameworkで直接対応することができないファイル形式を扱っていたため、本処理の前後に以下の処理を追加しています。

前処理内容

  • 参照マスタデータをファイルとしてエクスポート
    Direct I/Oでは処理に使用するデータはローカルファイルとして保存している必要があるため、事前にDBからエクスポートしています。
  • ファイル形式変換(固定長→CSV)
    一般的なCOBOLプログラムで扱うデータは固定長データの例が多くありますが、Asakusa FrameworkはCSVまたはTSVなどの区切り文字がないと処理できません。そのため、固定長ファイルである処理対象データをCSV形式へ変換しています。
図1. 前処理の概要

続いて、後処理について説明します。

後処理内容

  • ファイル形式変換(CSV→固定長)
    前処理と同様、Asakusa FrameworkからはCSVとして結果ファイルを出力し、後処理の中で固定長ファイルに変換しています。
  • 出力ファイルの結合およびソート処理
    対象バッチで出力するファイルは、マルチレイアウトファイルでしたが、Asakusa Frameworkではマルチレイアウトファイルの出力に対応していませんでした。そのため、ファイルをレイアウト別に分割して出力し、後処理内で結合しています。また、出力順も保持されないため、後続バッチ処理でレコード順番が重要となるファイルについては別途ソート処理を行っています。
図2. 後処理の概要

本記事では、Asakusa Frameworkでの設計のポイントについてご説明しました。処理設計の際にはAsakusa Framework内で対応できる範囲とできない範囲を見極め、対応できない場合は前後処理の中で対応することを含めて柔軟に検討していく必要があります。

次回は、Visual COBOLを用いて実装をしていく中で注意すべきポイントと、Asakusa Frameworkの処理のチューニング内容についてご紹介します。

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

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

関連する取り組みレポート