脱メインフレームで直面した処理性能問題

「COBOL」「JCL」計7000本のAWS移行　2000社を支える給与サービスを襲った危機

計7000本に及ぶレガシープログラム群を抱えるメインフレームのクラウド化は、安易に進めると処理速度低下という致命的なリスクを招く。三菱総研DCSはいかにしてこの課題を乗り越えたのか。

　稼働し続けてきたメインフレームにおける維持・運用費用の増加や複雑化したプログラム群の扱いは、企業の情報システム部門にとって頭の痛い課題だ。これに対して、既存のソースコードを有効活用しながら移行リスクを最小限に抑えられる「リホスト方式」でのクラウド移行は、現実的な解決策になる。

　しかし、ここに大きな落とし穴がある。「取りあえずクラウドサービスに載せ替えれば動く」と安易に考えて検証を進めると、「メインフレームと同等の処理性能が出ない」という壁にぶつかることがある。特に、大量のバッチ処理が中心となるシステムでは、I/O（入出力）のボトルネックが致命的な遅延を招き、業務に実害を及ぼすリスクが跳ね上がる。

　システムインテグレーターの三菱総研DCSが提供する主力の人事給与サービス「PROSRV」は、メインフレームから「Amazon Web Services」（AWS）へのリホスト移行において、この“死角”に直面した。2026年7月時点で導入企業約2000社、月間55万人分の処理を支える同サービスは、「1円の誤りも許されない」というシビアな要件を抱えている。給与計算で処理遅延が起きれば、その代償は計り知れない。

　移行プロジェクトを支援したエクサと共に、約4000本の「COBOL」プログラムと約3000本の「Job Control Language」（JCL）によるジョブ定義について、不要なプログラムの棚卸しと整理を進めていた三菱総研DCSは、検証段階で処理速度に関する課題を突き付けられた。年間で最大の高負荷期となる12月の「年末調整処理」を遅延なく完遂するために、どのような対策が必要だったのか。

検証段階で見つかった「処理遅延」の危機

この記事の著者

関連記事

• 

  150万行のCOBOL、どう捨てる？　米保険大手が挑む「脱メインフレーム」の着地点

• 

  60年前のコードが今も動く――英国の銀行システムを縛る“技術負債”