AWSサーバーレス。メインフレームのクラウドマイグレーションとマイクロサービス化の可能性を探る。 COBOLなどレガシー系プログラムは移行できるのか？

はじめに

いわゆるレガシーシステム（レガシーなIT資産）と呼ばれる、メインフレームやオフコン上で稼働するCOBOLシステムや簡易言語(4GL)のプログラムはいまだに数多く存在しています。一方でクラウド全盛の最近なので、なんとかこれらのレガシーシステム資産をAWS上で、サーバーレス化が実現できないかということを実験してみました。

AWSのサーバレス環境におけるCOBOLプログラムの動作検証の一環として、メインフレーム言語のひとつである4GL / Q言語をCOBOL化、クラウド化、サーバレス化という流れになります。

これにより「AWSマイグレーション」としてWindowsやLinuxなどのオープン系のオンプレ環境だけでなく、いわゆる「レガシー系IT資産」の移行、さらにサーバレス環境を利用することによる、既存資産の部分活用としてのマイクロサービス化の可能性を検証します。

前提条件と環境

今回の技術コラムにおいては、メインフレーム（汎用機・ホスト環境）で動作する4GLと呼ばれる簡易言語系の、いわゆる「レガシー資産」をOpen COBOL化と同時にクラウドへ移行しサーバーレスによるマイクロサービス化までを検証しました。

移行元のプログラム資産は、代表的な4GL（各社メインフレームで専用に動作する簡易言語）のひとつである日立メインフレーム上のQ言語です。クラウド上にメインフレームの各社コンピューターの独自環境をそのまま再現することは困難なので、より汎用的なレガシー系プログラム言語であるCOBOLに異言語変換した後に、AWS上でCOBOLプログラムを動作させるという流れになります。

なお、このQ言語からCOBOLへの異言語変換の部分の詳細については、その他のマイグレーション関連記事を参考にしてください。

移行元の環境と資産

環境　日立メインフレーム（中型機）

OS   VOS K（主に中型機に実装されていた専用OS）

言語　Q言語（日立メインフレーム4GL：第四世代簡易言語）

処理　バッチ処理

移行先の環境

クラウド化の実装

Amazon EC2 (Linux環境)

OpenCOBOL（OSS）

従来、日立系のCOBOL（COBOL85）や4GLをオープン環境へ移行する場合においては、日立プロダクトであるCOBOL2002に移行するのが親和性が高く、移行事例も多数ありますが、今回はさらにクラウドに移行してAWS上で動作させるという観点から、OSSであるOpenCOBOLを選択しました。

サーバーレス化の実装

AWS Lambda

OpenCOBOL（OSS）

検証方法

クラウド化の実装

移行元環境と移行先環境で同一のプログラムを起動し出力されたファイルの内容比較を行うことにより、処理ロジックの移行（ソースコードのリライト型のマイグレーション）が実現できるかを確認します。

比較においては従来のマイグレーションと同様に文字コードの違いによる差異や実行時のタイムスタンプなどの差異については考慮し比較対象外とします。

サーバレス化の実装

基本的には、クラウド化実装検証と同じ条件で実施します。

クラウド化の実装

Amazon EC2への移行については以下の手順で行います。

プログラム移行

従来のマイグレーションと同様に言語変換（リライト）することにより移行します。ただし、従来はQ言語は同じ日立環境であるCOBOL2002への移行が主流であるため、Q言語→COBOL2002→OpenCOBOLへの二段階の変換としました。COBOL2002の段階では日立メインフレーム特有の記述（COBOL2002の機能として提供）が残っているため、それを汎用的なロジックへ再変換しています。

・システムズのQ言語マイグレーション手法を用いてCOBOL変換（ここではOpenCOBOL）を行います。

・JCL（メインフレームのスプリクト言語）をLinux上で動作するシェルプログラムであるbashに変換を行います。

処理データの検証

・移行元、移行先それぞれの処理前後のデータを比較することにより動作検証を行います。

検証方法

・Amazon EC2(Linux)上でbashを起動します。

・bashからOpenCOBOLプログラムを呼び出します。

・出力ファイルの検証を実施します。

サーバーレス化の実装

プログラム移行

・Q言語の業務ロジックをCOBOLに変換し、AWS Lambda上に作成します。

・プログラムのビルド・デプロイはAmazonEC2より実施します。

検証データ

・入出力ファイルはAmazon S3（ファイルストレージ）上に配置します。

検証方法

インプットデータをS3（ファイルストレージ）にアップロードします。

・ファイルアップロードをトリガーとしてAWS Lambdaが起動します。

・AWS Lambda（OpenCOBOL）が呼び出されることにより、出力ファイルが生成されます。

・出力ファイルの検証を実施します。

まとめ：メインフレーム環境からのAWSマイグレーションの可能性について

今回の実験においては、従来型のクラウド環境（仮想環境）であるAmazon EC2への移行、それからAWSのサービスであるAWS Lambdaを用いたサーバーレス環境での動作の２つを検証しました。オンプレのオープン環境への移行に比べて、大きな変化点のないAmazon EC2への移行だけでなくAWS Lambdaに関しての動作確認が取れた点が大きなポイントです。

クラウド化の検証（Amazon EC2への移行）

基本的な移行方法であるAmazon EC2を利用したクラウド化ですが、このクラウド化を進めることにより、いまもなお多く現存するメインフレームやオフコンといった専用機のレガシー資産をクラウドへ移行することが可能となります。

クラウド化を進めたいが、長年のノウハウや普遍的な業務処理が数多く残されているCOBOLや4GL（Ｑ言語ほか）などのロジックやシステム運用を踏襲したい場合、一から作り直すだけでなく、一部流用することで選択肢の幅が広がることになります。

サーバーレス化の検証（AWS Lambdaへの移行）

次に行ったサーバーレス化の検証のねらいは、業務システムやサブシステム単位のサーバーを持たずにマイクロサービス化することが目的です。サービス化、サーバーレス化が実現すると、特定のサブシステムや特定の処理だけがマイクロサービス化されることになり、情報システム部などのIT運用部門がハード保守の呪縛から解き放たれ、より事業部門へのITサービス向上に集中することや経営効率化が可能となります。

それぞれの検証ではプログラムを起動するタイミングが異なります。今回は実験なので、トライアル＆エラーで手探りで進めましたが、実際のクラウド化やサーバーレスマイグレーションにおいては移行後の環境や運用イメージ（オペレーション等も含む）をしっかりと検討し、それを運用設計に落とし込むことによって、仮想環境、サーバーレス環境、それぞれの利点を組み合わせて活用することになります。今回のサーバーレス化検証の中には、単純にストレート移行できないようなケースも発生しました。

今後の可能性と今回の制約事項

メインフレーム等からのクラウド移行（AWSマイグレーション）

実施可能

メインフレームからのAWS環境へのマイグレーションにおいてはプログラムレベルでの移行性検証は成功であると言えます。つまり、Amazon EC2に稼動環境を構築し動作させることはうまくいきました。

また、AWS Lambdaを用いたサーバーレス化においてもプログラム単位での移行性検証は成功したといえるでしょう。

今回は日本語コードの変換やデータの型変換を伴わない、単純なファイルの読み書きであったためデータに起因する問題は発生していませんが、従来メインフレームのマイグレーションにおいては、DB/DCの移行などが大きな課題になります。このあたりは、メインフレームやオフコンからオンプレミスのオープン環境（WindowsやLinux）への、従来のDB/DC移行のノウハウが活かせそうです。

2つの環境への環境コンバージョン、言語コンバージョンとしての検証は成功しましたが、運用面における検証などは実施していません。実際のマイグレーションにおいては言語変換やDB/DC変換とともに移行後の運用イメージなどの詳細検討が、着手前に必要になってくることでしょう。

OpenCOBOL関連の制約事項

今回、実験ということもあり、Ｑ言語からOpenCOBOLへの移行に関しては詳細な移行設計を実施せず、過去に事例として実績のあるQ言語→COBOL2002変換をベースとしたシステムズのＱ言語マイグレーション基準を踏襲することで変換しました。

COBOL2002とOpenCOBOLの言語特性の違いにより検証中にいくつかのエラーが発生しましたが、今回選択したプログラムが比較的単純なものであったこともあり、動作検証優先で実装できました。