レガシーシステムを捨てると失うもの大事なもの――挽回した3社の事例

令和の時代にも残る昭和の資産の中で、「無くしたいのに無くせない」メインフレームやオフコンなどのレガシーシステム。マイグレーションのポイントは「バッチ処理」にあった。

[土肥正弘，ドキュメント工房]

10月17日に開催された「アシストテクニカルフォーラム2019 in 東京」に登壇したアシスト　情報基盤技術統括部 技術3部　宮本玲氏

　メインフレームやオフコンといったレガシーシステムを、オープンシステムに移行させる「レガシーマイグレーション」。しかし、大量データを扱う一部のミッションクリティカルな基幹業務のためにレガシーシステムを撤廃できない、とITのモダナイゼーションに苦労するケースは珍しくない。変化への対応が難しく運用コストもかかるレガシーシステムの撤廃とITの刷新を成功させるにはどうしたらよいのか。

　アシストの情報基盤技術統括部でETL（Extract、Transform、Load）やデータ連携領域の経験を積んだ宮本玲氏は「モダナイゼーションの成功にはバッチ処理にまつわる課題の解決が不可欠」だとアドバイスし、レガシーの撤廃を実現した3社の事例を交えながらモダナイゼーションのコツについて紹介した。中には「ある方法」によってJavaやPL/SQLによるバッチ開発よりも6倍以上の処理性能を実現したケースがある。その方法とは。

レガシーシステムのオープンの難敵がバッチ処理プログラム

　メインフレームやオフコンのメリットは、大量データの一括処理（バッチプログラム）を時間内で完了できる性能と、障害が少ない安定性や信頼性だ。さらに、ベンダーがハードに最適化されたOSやアプリケーションを一貫して提供し、手厚く運用をサポートするというメリットもある。

　一方で、運用コストは高止まりし、年を追うごとにレガシーシステムの知見を持つ開発技術者も減るため、維持はますます厳しくなる。長年の機能追加によってプログラムも複雑化し、改修するにも膨大な時間やコストがかかる始末だ。

　WindowsやLinuxをOSとするオープンシステムのメリットは、開発技術者を獲得しやすく、各種パッケージの適用も含めて簡単にシステムを改修、拡張でき、比較的少ないコストで運用可能なことだ。

　しかし、ベストオブブリード（複数ベンダー製品の組み合わせ）で構成されるオープンシステムは、単体では処理性能、安定性、信頼性の面でレガシーシステムに劣ると言われる。

　マイグレーションも簡単ではない。レガシーシステムのプログラムをそのままオープン系言語に置き換えるリホスト（業務要件やアプリケーションを変えずにそのままオープン系サーバに移行）方式では、移行は比較的容易でも改修や機能追加が難しい。リライト（アプリケーションをJavaなどで書き換える）やリビルド（業務ロジックも含め新言語で完全に書き換える）を実施すれば変化に対応しやすくなるものの、技術習得の期間や開発コストがかかる。言うまでもなく、どの方式でも開発人員の確保が課題だ。

バッチ処理における課題解決のポイント

　宮本氏は、「ITモダナイゼーションではオープンシステム移行後の『処理量の多さ』『時間内に処理を完了できること』『ミッションクリティカルな業務への対応』を考える必要があり、一方で『変化への対応』『運用コストの削減』『人材の有効活用』という期待にも応えなければならない。これらを満たすために、バッチ処理の性能と安定性、生産性の確保が不可欠だ」と課題を整理する。

図1　バッチ処理の課題解決のポイント

　具体的には何をしなければならないのだろうか。

　宮本氏はまず、「データベース処理と汎用（はんよう）言語処理のバランスをとること」を挙げた。一般的にバッチ処理プログラムは、JP1に代表されるようなジョブ管理ツールから起動され、SQLなどによるデータベース処理が実施されるとともに、他システムとファイルを連携させて得たデータが汎用言語によって処理される。

　宮本氏が経験したマイグレーション事例には必ずファイル処理が含まれており、それが各システムの責任分界を明確にすることで信頼性を確保していたという。

　そのファイルのデータをそのままデータベースに取り込む方が良いのか、いったんデータを加工、整形しデータベースにロードしたほうがよいのかを検討する必要があるとして「SQLなどによるデータベース処理と、汎用言語（JavaやC言語、COBOLなど）による処理とのバランスが肝心」と述べた。

　さらに同氏は、レガシーシステムとオープンシステムはミドルウェア構造が異なり、「オープンシステムでデータ量が増えた場合に、それに応じて性能をスケールできる」ことも重要だとする

　同様に「バッチ処理内部のロジック構造がバルク処理であること」も考慮しなければならない。アプリケーション開発者は、同じ処理を何度もプログラムに記述する「ループ処理）を作り込む傾向にあるが、大量データの場合は一度に複数件の読み込みとデータベースへのロードが可能なバルク処理の方がリソースを有効に活用でき、性能（処理効率）を上げられる。

図2　課題解決の要素

処理性能が6倍の事例も　ETLツール導入によるバッチ処理の高速化

　こうした希求に応える手法として、宮本氏はETLツールを「バッチ処理エンジン」として利用することを推奨する。

　ETLツールは、大量データを高速に加工、整形できるツールだ。データのソート、結合、コピー、マージ、集計、加工および変換などの機能をパッケージ化している。データベースまたはアプリケーションでそれらの機能を担うよりも処理を高速化できる。宮本氏はETLツールの「Syncsort DMExpress」を利用したITモダナイゼーション事例を幾つか紹介した。

処理性能6倍、生産性5倍　自動車部品メーカー小島プレス工業のモダナイゼーション

　同社は、販売や物流管理を含むメインフレームのバッチ処理基盤をオープン化するため、PL/SQLやJavaによる開発を検討したが、処理性能とスキルの習得に不安があった。そこで、DMExpressを評価したところ、PL/SQLで65分かかっていたバッチ処理を10分で完了でき、処理性能は6倍も向上することが分かった。実装時間も、PL/SQLでは28時間掛かるところをDMExpressで5時間に短縮でき、生産性は5倍以上になる。

　最終的にDMExpressを導入し、Oracle Databaseとの組み合わせによってメインフレームの撤廃に成功した。現在は、取引先ごとのデータのバッチ処理や、グループ内企業のバッチ開発にもETLツールを利用し、1000本以上のバッチ処理プログラムを安定稼働させている。なお、DMExpressはGUIによる開発が可能なため、同社の8人の開発担当者は全員がバッチ処理基盤の開発スキルを身に付けた。

オープン化でバッチ処理が6時間以上に――薬品販売会社、メディパルホールディングスの事例

　同社はメインフレームのオープン化のため、Oracleを利用したバッチ処理をPL/SQLで開発したが、データ量が多い場合には、処理に6時間以上もかかることが分かった。

　そこでDMExpressを採用し、処理時間を1時間30分にまで短縮できた。ピーク時には総数4000本を超える処理も規定時間内に完了させ、薬品供給のタイミングにも関わる最新情報も確実に反映している。開発効率を上げたことで、開発リソースを別のプロジェクトに再配置できたという副次的な効果もあった。

電力会社グループのIT企業、中電シーティーアイの事例

　同社もDMExpressの有効性を検証したところ、Javaプログラムの6多重で10分25秒かかっていたバッチ処理が3分19秒で完了した。さらに、テストにかかる時間は128時間から33時間に短縮できたという。DMExpressを共通ETL基盤として運用してきた3年間の間で、製品起因の障害発生は一度もなかった。

ETLツールのどこが効いたのか？

　宮本氏は、成功事例ではETLツールの次のような特徴が生かされているとする。1つはバッチ処理のボトルネックとなりやすいソート処理を速くする仕組みだ。ソート処理とはデータ結合や集計処理などの前提となるレコードのキーによる並べ替えのこと。

　DMExpressは50年前からメインフレームの大量データ処理を担ってきたSncsortの技術が生かされている。実際に、アシストの技術者がC言語で構築した同処理プログラムと比較し、少量データで2〜3倍の性能を実現している。さらに、データ処理量が増加した場合、C言語ではデータ量が2倍になると処理時間が8倍に増加するが、DMExpressでは2倍に増加するのみで生産性も高い。

　その他、処理の実行時にシステムリソースや処理対象データを自動分析し、リソースの使用方法を自動調整する仕組みがあること、マルチプロセスやマルチスレッドの並列処理が可能なこと、データの特徴を自動的に判断して処理を切り分け、全体の処理の並列度を上げるなどして処理を高速化できること、DBへの入出力を高速化する機能を有し、自動的に処理効率を最適化できることなどが挙がった。

　最後に宮本氏は、「こうした特長を生かせる部分にETLツールを採用し、そうでない部分にはJavaなどの汎用言語による開発を検討するなど、バランスのとれたバッチ開発が成功につながる」と提言した。

図3　課題と期待にETLツールがどう応えるのか