|
|
|
|---|
2018年に経産省から提出されたDXレポートでは、
「データを活用できない企業は、競争力を失って淘汰されていく」という内容を読み取ることができると思います。
「DXの推進」が進んだところに「競争力強化」というテーマがあるとすれば、その対極には、「先延ばしにしてきた課題」とも言える「レガシーシステムへの対処」があるように思います。
DXレポートで指摘されるレガシーシステムの問題点は、ざっくりまとめると以下の3点と捉えられます。
・変化に対応できない （対応が遅くなる）
・属人化している （しかも高齢化している）
・コストが高い
DXレポートではこれらを総称して「技術的負債」と呼ばれており、技術的負債を抱えるシステム（＝レガシ－システム）への適切な対処が必要とされています。
レガシーシステムというと、やはり多いのはメインフレームやオフコン。
レガシーシステムはバッチ処理のかたまりと言っても過言ではなく、オンライン処理も基本的にはバッチ処理と同じような構造と言えます。
|
|
|
先日、数年前にメインフレームを撤廃されたお客様が発した言葉です。
取引先の要件に応じたり、グループ会社の処理を巻き取ったりするために、新規のバッチ処理は実は依然としてある状態で、いまでも1,000本ほどのバッチジョブを運用されているとのことでした。
ITのトレンドとしてはバッチ処理は減っていく傾向にあるように思います。
ですが、データ量が増えたり、処理間隔が短くなったりと、むしろバッチ処理が増えていることも結構多いのかもしれません。
バッチ処理が中核となっているレガシーシステムの技術的負債を精算し、現代的なアーキテクチャーへと模様替えを図ることを”レガシーモダナイゼーション”と言います。
レガシーシステムのモダナイゼーションを行う際に、注意いただきたい点が「処理性能の担保」です。
プログラムとデータの変換に関心が行きがちですが、処理性能の源泉となる基盤の相違への意識が薄れがちです。
メインフレームでは、入出力専用のサブシステムをハードウェアで持ちCPUへの負荷の集中を回避しています。
対してオープン系のH/Wでは、入出力でもCPUを使うためプロジェクトの中盤になって処理性能にまつわる課題が顕在化し、その対応に追われる...といったケースが散見されます。
そもそもレガシーシステムのバッチ処理では、次のような特性を伴うことが多いです。
・処理量が多い
・制約時間が厳しい
・ミッションクリティカル
そしてこれらの特性がモダナイゼーション化の課題とも言うことができます。
では、ここでバッチ処理の実装についてみていきたいと思います。
スクラッチでの開発を例にすると、以下の要素の組み合わせとなります。
・PL/SQLなどストアドプロシジャとSQLによるデータベース上のデータ処理実装
・JavaやC++、COBOLなどの汎用言語によるファイルベースのデータ処理実装
処理量がさほど多くなく、キャパシティが十分なデータベースではストアドプロシジャによる実装で性能問題が出るケースは稀です。
一方で、データベースのキャパシティ（特にメモリ）を超える重いバッチ処理が更に多重で実行されるような場合には、データベース全体の処理性能が急激に劣化するリスクが伴います。
このような場合に、全件突き合わせのような処理をデータベース上のデータ処理ではなく、
汎用言語によるファイルベースで処理することで、データベースの負荷が下がりバッチ処理全体の処理性能が向上する可能性があります。
このようにバッチ処理の性能の観点では、データベース上のデータ処理とファイルベースでのデータ処理のバランスを取った設計が重要になります。
もちろん、バッチ処理が性能観点で適切に設計・実装されている必要があります。
バッチ処理の設計において、機能的な処理ロジックのみを考慮すると、ループ処理を基本とした実装になりやすい傾向があります。
この実装は、データ量が少ない場合には問題になりませんが、データ量が多くなるにつれて性能問題を抱えやすくなります。
1件のデータ処理としてのロジックを中心に考えた設計が、大量のレコード件数分繰り返されたときには全体としてまったく最適でなくなる、という症状です。
バッチ処理設計においては全件処理が可能かどうかを分析し、可能な場合には処理プロセス毎にまとめて処理し後続のプロセスに渡していく、という処理データ量に適した実装方式が求められます。
全件処理のようなバッチ処理は、結合処理と集計処理を複合的に組み合わせたデータ処理がほとんどです。
各処理工程で結合キーや集計キーでレコードを並べ替えるため、内部的なソート処理が実施されています。
ソート処理では必ず全件データを展開して並べ替える必要があるため、処理データ件数に比例して処理時間のボトルネックになりやすく性能がポイントと言えます。
つまりは、バッチ処理においては、ソートを含む結合処理や集計処理を高速にさばけることが理想となります。
前述のレガシーシステムのバッチ処理特性(下記3つ)をクリアし、
1.処理量が多い
2.制約時間が厳しい
3.ミッションクリティカル
DXに向けたモダナイゼーションとして、
1.変化への対応力
2.人材のフル活用
3.コスト削減
の上記3項目の達成を目指すチャレンジのポイントは、
1.処理性能 →「処理量が多い」「制約時間が厳しい」への対応
2.安定性 →「ミッションクリティカル」「コスト削減」への対応
3.生産性 →「変化への対応力」「人材のフル活用」への対応
この3点に効果的にアプローチできる実装方式を選択することにあります。
そこで前述の従来の実装に、以下の選択肢を加えることをオススメします。
ETLツールなどデータ処理エンジンによるデータ処理実装
一般的にETLツールの利用メリットは、以下2点にまとめることができます。
▶開発生産性
・ツールの習得コストが高くない
・習得コストが低いので開発者のアサインの幅が広がる
・GUIで簡単に開発できる
▶保守性
・ツールの習得コストが高くない
・GUIで可読性が高い
・習得コストが低くGUIで可読性も高いので引き継ぎコストが低い
よって、前述の「処理性能」「安定性」「生産性」の3点の内、「生産性」に対してはどのETLツールも貢献できます。
しかし「処理性能」と「安定性」については、ETLツールごとに強い弱いといった差も含め、
そのアプローチ方法や実績に大きな違いがでてきます。
「処理性能」…高い処理性能を発揮するための独自のテクノロジーを持っているか？
「安定性」…ミッションクリティカルな適用領域への実績があるか？
ちなみに弊社のラインナップの一つである「Syncsort DMExpress」。
レガシーモダナイゼーションの3つポイントに効果的にアプローチが可能です！
●処理性能
独自のテクノロジーにより世界一を記録した超高速処理を実現。
●安定性
シンプルな製品構成やリソースの効率的な使用により安定稼働を実現。
●生産性
GUIとステップツリー形式による選択式の簡単開発の実現。
DMExpressは、ミッションクリティカルな領域での実績含め、レガシーマイグレーションでの採用実績が多数あり、多くのお客様から高性能なバッチ処理開発ツールとして高い評価をいただいております。
バッチ処理システム構築における処理方式のご検討に加えていただき、お役立ちの機会をいただけますと幸いです。
|
|---|
<目次＞
1. レガシーモダナイゼーションとは
2. オープン化における課題
3. バッチを移行する開発手法の検討
4. DMExpressのご紹介
5. 3社のレガシーモダナイゼーション事例
|
|
|
|---|
1997年アシスト入社後、IBMメインフレーム環境のアプリケーション性能管理ツールの技術全般を担当。
2005年から、最も賢い超高速ETLツール「Syncsort DMExpress」の技術を担当し、製品マネージャとして製品事業全般に従事。
現在、DataSpiderも含めた、DI製品全般の技術マネージャを担当。
宮本 玲（Akira Miyamoto）
