「絶対に失敗しない！ラスボス『アセンブラの多いメインフレーム』『日本製メインフレーム』からのパブリッククラウドへの移行」

＜TmaxSoft/日本ティーマックスソフトについて＞

当社は1997年に韓国で創立され、オンラインのトランザクショナル処理を行うTPモニターの製造販売で業務を開始。現在はグローバル本社を米国シカゴ、R&Dセンターを韓国においてビジネスを推進している。韓国のミドルウェア市場では40％以上のシェアを誇り、自社製のRDBMSは既に7000件以上の納入事例がある。全従業員の8割以上がエンジニアで、韓国5大メガバンクを含め、4500社以上に弊社ソリューションが導入されている。製品ラインナップはミドルウェア、データベースが中心となる。日本では、「脱メインフレームのソリューション・オープンフレーム」を提供している。

＜メインフレーム維持の課題と脱レガシーの難しさ＞

2022年も「脱メインフレーム」の動きが報じられている。しかし、メインフレームからの脱却はけっして簡単ではない。特に日本ではアセンブラが多いメインフレームが多く、脱メインフレーム推進を妨げる要因になっている。「日経クロステック」の記事ではその難しさから「ラスボス」に例えるほどだ。メインフレームの維持には高額な維持費、IT人材の不足、システムの肥大・老朽化などリスクが多い。一方、データや機能を維持したままで旧システムから新システムに移行するいわゆる「レガシー・マイグレーション」は70％以上が未完了だ。レガシー・マイグレーションが失敗したのは、独自アプリや他システムとのスパゲティ化、新・旧両方のシステムを理解できるエンジニアの不足、無謀な目標設定による予算超過などが原因とみられる。そこで、TmaxSoftはクラウド化、クラウドネイティブ化、クラウドからクラウドネイティブ化の3つのクラウドジャーニーで安全に脱メインフレームを行う、DX化を実現している。

＜モダナイゼーションソリューション選択のポイント＞

他社の脱メインフレームソリューションは、コンパイラ、コンバージョンツールを提供する言語系ソリューションで、アプリの動作環境まで保証していない。従ってコンバージョンが終わった後、テストや運用中に問題が発生しても解決できないリスクがある。TmaxSoftは言語系プラスインフラ系ソリューションであり、言語ツールと共に、ミドルウェア、データベースのセットを提供している。言語を含めメインフレームのミッドウェアやデータベース、セキュリティと同等性能をOpenFrameが提供し、アプリの動作保証もしている。米国の調査会社ISGのメインフレーム・モダナイゼーション・ソフトウェア部門で、2年連続でリーダークラスの認証を獲得している。リーダークラスに認証された日本企業はTmaxSoft Japn 1社のみである。2019年以降のデータによると、オープンフレームのリホストの移行先は、ほとんどがパブリッククラウドとなっている。日本でも大手・中堅保険会社がMicrosoft Azureを採用している。日本ではMicrosoft Azureが多いが、TmaxSoftではAWS、GCPにも対応しており、グローバルなパブリッククラウド・ベンダーともパートナーシップを強化している。またプライベート・クラウドへの移行も対応している。IBM Zのメインフレームと、Microsoft Azure上のTmaxSoftのOpenFrameのベンチマークテストを行うと、OpenFrameはメインフレームより5倍から10倍の速度で処理を完了した。OpenFrame on Azureは低コストで高パフォーマンス且つ拡張性があることが証明された。

TmaxSoftのOpenFrameはIBMのメインフレームのシスプレックスと同等のクラスタリングをクラウド上で実現した。TmaxSoftは富士通、AWSなどの国内やグローバル企業110社のパートナーと共に、3000社を超えるプロジェクトを成功させてきた。顧客の脱メインフレームを、パートナー会社と共に支援している。

＜TmaxSoft 脱メインフレームソリューション OpenFrameについて＞

TmaxSoftが提供する脱メインフレームの手法にはリホスト、リライト、リビルドの3種類がある。「リホスト」はアプリケーションの言語ロジックを変更せずにそのままクラウド上に移行する。アプリケーションを変更するリライトには2種類あり、「単純リライト」はCOBOLを1対1のJavaに変換し、「リアーキテクチャ」はJava変換した後、マイクロサービス化している。COBOLをクラウド環境で使い続ける顧客には「OpenFrame7」、Java化したい顧客には「OpenFrame21」を提供している。

OpenFrame7のリホストはメインフレームで使用されているファイル、階層型ネットワーク型のデータをRDB化し、TmaxSoft独自のTibero RDBMSで運用する。これにより様々なツールからAPIで連携し、SQLでのアクセスが可能になる。本来ならアプリケーションのアーキテクチャが違うと自動移行はできない。しかし、TmaxSoftが提供するミドルウェアのデータベースのスペックが、メインフレームのミドルやデータベースと同等機能であり、COBOLのアプリを解釈できることで自動移行を可能にした。階層型、ネットワーク型など多様な方法でモダナイゼーションできるのも特徴だ。特にアセンブラの自動移行が可能なのは、オープンソフトウェアの中でもOpenFrameだけである。現在、取り組み中の大手保険会社には1500本以上のアセンブラがあった。OpenFrameのアセンブラの自動移行の機能が評価され、案件受注に繋がった。OpenFrame21は「リアーキテクチャ」を行い、レガシーシステムを最新のミドルウェアに自動移行する。同じRDBデータを共有するため、リホスト、リアーキテクチャを混在させるハイブリッド運用もでき、アプリ開発などのデータの利活用も可能だ。

＜OpenFrameを活用した移行プロジェクトの進め方＞

移行プロジェクトは約1年をかけて以下の手順を踏む。

まず顧客から資産を受け取り、資産分析を行う。プロジェクト費用を提案し、PoCに移る。一部の業務を顧客指定のインフラに移し、データが安全に移行できるか確認する。その後本番に入り、移行業務、現新テストを行う。現新テストではメインフレームとオープンフレームのインプット・アウトプットを確認して、結合テストを行って全ての移行が完了する。

まず、顧客から受け取ったデータの互換性調査を行う。非互換が見つかった場合はオープンフレームに機能を追加したり、データに手を加えたりして対応する。同時にデータ移行方式を決定しながら、インフラサーバーの構築、ソフトウェアのインストールを準備し、テストに備える。顧客からOS設定やユーザーの情報をもらい、その移行も計画する。準備が整うと、データ資産、プログラム資産、定義体・マスタファイル資産の移行を進める。移行後、現新比較テストに続いて、結合・総合テストを実行する。

データ資産はメインフレーム上のVSAMをリプロしてできたSAMファイルをEBCDICのまま移行環境に移す。各データのレイアウト情報をスキーマ生成し、変換用スキーマを作成。マイグレーションツールを使用して、S-JISにコンバートする。

プログラム資産はメインフレームの各言語ソースコードをEBCDICのまま移行環境に移し、マイグレーションツールを使い、S-JISにコード変換する。ソースコードをPreコンパイラ、または各言語コンパイラにかけて、実行形式バイナリを生成する。

定義体・マスタファイル資産は、個別に変換の仕方が変わる。マスタファイルの場合は、EBCDICのまま移行環境に持っていき、マイグレーションツールでコード変換。MAPコンパイラを通して、MAPファイルとMAPファイルCopy句を生成する。

テストフェーズの期間は、単体テストで6ヶ月、総合・結合テストで2ヶ月程度になる。 まずメインフレームのデータを現行のメインフレームとオープンフレームに同じデータを入力する。処理後にアウトプットがメインフレームとオープンフレームが同じであるかを確認する。オンラインで同じ画面を操作し、操作後の結果が同じになることを確認する。バッチは、同じデータを入力し、バッチ処理後のアウトプットも同じになることを確認する。各ミドルウェアの単体テストも実施する。

結合テストではバッチジョブやオンライン業務を通じて、ミドルウェアを連携した動作が正常に行われるか確認。最後の総合テストは業務観点からテスト対象を絞り、正しいロジックで動作しているか確認する。 TmaxSoft Japnはこれからも「OpenFrame7」「OpenFrame21」により、日本の脱メインフレーム化に貢献していく。

◆講演企業情報
日本ティーマックスソフト株式会社：https://www.tmaxsoft.co.jp/