Amazon Web Services ブログ

ユニシスメインフレームからAWSへの5ステップでの移行

この記事はAstadia社のレガシーモダナイゼーションサービスのバイスプレジデントである Craig Marbleによるものです。

ユニシスメインフレームをお持ちの場合は、あなたはビジネスのバックボーンとして機能している信頼性の高いプラットフォームとアプリケーションポートフォリオの構築に投資していると思います。しかし、今日の技術環境は、ユニシス、メインフレームが提供できるよりも低コストで、より柔軟性と俊敏性を必要としています。

Amazon Web Services（AWS）のコンサルティングパートナーであるAstadiaでは、ユニシスメインフレームのアプリケーションワークロードを実行するための現代的で柔軟性のある選択としてAWSを利用しており、ユニシスメインフレームのアプリケーションとデータへの過去の投資を活用していることがわかりました。

慎重に計画、管理、実行すると、ユニシスメインフレームワークロードをAWSに移行することの利点は数多くあります。 Pay-as-you-goモデルのコスト削減に加えて、ユニシスメインフレームアプリケーションセットがAWSに完全に移行されると、実証済みのビジネスロジックを最新のテクノロジーと統合して、データ分析やモバイル対応を可能にし、新しい市場、顧客、パートナーにビジネスを拡大します。これを念頭に置いて、ユニシスメインフレームアプリケーションをクラウドに移行することは、贅沢と言うより必要にせまられてということのようです。

この記事では、ユニシスメインフレームアプリケーションをAWSに移行するのに役立つ５つのステップを紹介します。

元のアプリケーションのソースコードとデータを再利用し、最新のAWSサービスに移行することをお勧めします。 ユニシスメインフレームの移行を可能にするツールは、既存のコードをそのまま維持することができますが、一部のコンポーネントを置き換えてデータストレージを再考する必要があります。

このような最小限の変更のアプローチは、手作業の書き換えやパッケージの置き換えに比べてプロジェクトのコストとリスクを削減し、20年または30年の投資を活用しながら新しい市場を活用するための新技術との統合のメリットを享受します。ひとたび移行されると、アプリケーションは、既存のスタッフが現代化を進めるのに十分な特性をもつようになります。また価値ある知識野蓄積を新しいデベロッパーに伝えています。

ステップ１：ディスカバー

まず、環境内のすべてのアプリケーション、言語、データベース、ネットワーク、プラットフォーム、およびプロセスをカタログ化して分析する必要があります。アプリケーション間のとすべての連携ポイントと、外部連携ポイントを文書化します。できるだけ多くの自動分析を使用し、すべてを一元的なリポジトリにまとめます。

Astadiaは、Micro Focus Enterprise Analyzerなどの商用分析ツールと独自に開発したパーサーを組み合わせて、従来のコードを迅速かつ効率的に分析します。この分析出力は、Astadia Code変換エンジンに供給される移行ルールを確立するために使用されます。これらのルールは、プロジェクト全体を通じて更新され、洗練されます。

ステップ２：デザイン

すべてのソースコード、データ構造、および最終形の要件を分析した後、ソリューション設計をするときが来ました。設計には、以下の詳細を含める必要があります。

  • AWSインスタンスの詳細：インスタンスタイプについて言うと、汎用Tインスタンスは、開発、テスト、または統合環境に向いていますが、汎用Mインスタンスは本番環境、本番前環境、およびパフォーマンスが要求される環境に向いています。
  • トランザクション負荷：一般的な非機能要件ですが、1秒あたりのトランザクション数が多いなどのパフォーマンス要件、または迅速な応答時間は、メインフレームのワークロードの実行にとって重要な場合が多いです。このことはネットワーク、ストレージ、コンピューティングの設計とサイズ設定を慎重に行う必要があるということです。
  • バッチ要件：バッチアプリを動かすほとんどすべてのユニシスメインフレームは、通常I/O集約型で、ストレージやデータストアからのレイテンシーが非常に短い事が要求されます。これは分散システムの課題であるため、バッチインフラストラクチャは早期に設計してテストする必要があります。
  • プログラミング言語の変換と置換：移行対象先でサポートされていない言語や使用できない言語は、ツールで変換したり、新しい機能に置き換えることができます。
  • 外部システムとの統合：ユニシスメインフレームは、一般的にサテライトやパートナーシステムのバックエンドまたは記録システム（SOR）であり、移行後にはプロトコル、インターフェイス、レイテンシー、帯域幅などの統合を維持する必要があります。
  • サードパーティのソフトウェア要件：各ISV（Independent Software Vendor）はAWS上で機能的に同等のソフトウェアを利用できる場合もあれば、そうでない場合もあるため、特定の移行パスの定義が必要です。
  • 将来要件の計画：ビジネス、IT戦略、優先順位は、特に将来のパフォーマンスと統合機能に関わるため、アーキテクチャの決定を左右します。

ソースコードには、Sperry MAPPER、Burroughs LINC、COBOL、またはECLが含まれます。データストアには、DMS（ネットワーク接続）、DMSII（階層型）、またはRDMS（リレーショナル型）が含まれます。

このデザインがUnisys ClearPath Libraマッピングを探す方法は次のとおりです。

図2 – Unisys Libra（Burroughs）メインフレーム移行アーキテクチャのコアコンポーネントは、レガシーコードを実行するための一連のエミュレータとユーティリティを使用するメインフレームクラウドフレームワークです。

 

同様のマッピングは、TIP、MASM、BIS（Mapper）、ECLを含むUnisys ClearPath Doradoシステムでも実行できます。

図2のアーキテクチャのコアコンポーネントは、レガシーコードを実行するための一連のエミュレータとユーティリティを使用するメインフレームクラウドフレームワークです。 OpenMCSは、移行されたコードをサポートするUnisys COMSの必要なトランザクション処理機能を提供するAstadiaのメッセージ制御システムです。このメインフレームクラウドフレームワークは、コンピュートリソースとしてAmazon Elastic Compute Cloud（Amazon EC2）上で動作します。

ほとんどの場合、ユニシスメインフレームの階層型およびフラットファイルのデータ構造は、Amazon Relational Database Service（Amazon RDS）内のリレーショナルデータベース管理システム（RDBMS）ソリューションに移行されます。ソリューションの弾力性は、Network Load BalancerやAuto Scaling Groupsと言ったElastic Load Balancingによって容易になります。

どのユニシスメインフレーム移行ツールを使用するかを選択する必要があります。プロジェクトのコストとリスクを大幅に削減するため、変更の必要最小限のものを選択することをお勧めします。たとえば、Astadiaは通常、開発にはMicro Focus Visual COBOLを使用し、ユニシストランザクションモニターをエミュレートするにはAstadiaのOpenMCSを使用します。この組み合わせにより、Unisys COBOLアプリケーションをWindowsおよびLinuxに移行する際に、元のソースへの変更を最小限に抑えることができます。

ただし、エミュレーションツールでは満たされない要件を満たすために独自開発のソリューションを設計する必要があります。 COBOLはほぼ常に移行されますが、AlgolやMASMなどの言語で書かれたプログラムは、ターゲットエミュレート環境でサポートされていないため、書き直す必要があります。

一部のプログラム機能は、ターゲットオペレーティングシステムや他のターゲットプラットフォームのコンポーネントに置き換えられる可能性があるため、ギャップを見つけるために少し分析が必要です。例えば、いくつかの旧式のアセンブラソート関数は、RDBMSのSQL節に置き換えることができます。また、データ移行戦略を定義する必要があります。フラットファイルを同じ旧式のフラット形式に保つことができますが、現代のSQLベースのツールとの統合を容易にし、実証済みのRDBMSでスケーラビリティを促進するために、それらをリレーショナルに変換することをお勧めします。変換ツールまたは抽出変換ロード（ETL）プログラムを使用して、階層型データをリレーショナル・データに変換する必要があります。

ステップ３：モダナイズ

これは、Astadia Code Transformation Engineを利用してソースコードを大幅に変更する反復的な自動化プロセスです。変更されたコードがコンパイルされると、単体テストの準備が整います。そうでない場合、開発者はエラーを確認し、修正プログラムを見つけて、移行ルールを更新し、プログラムをエンジンから再度実行する必要があります。多くの場合、あるプログラムのエラー修正は、他のプログラムで同じエラーを修正するために一括して適用され、規模の経済性を活用することができます。

 

図3 – 近代化プロセスを進めるにつれて、移行ルールが改善されたAstadiaコード変換エンジンは、後続のソースコードを移行するためにより迅速かつ正確になります。

 

より多くのソースコードファイルを使用して近代化プロセスを進めていくと、移行ルールが改善されたコード変換エンジンが、後続のソースコードを移行するためにより迅速かつ正確になります。これは、ソースコードファイルが同じ変換規則を必要とする同じコーディングパターンを繰り返す傾向があるためです。これは、開発者がAWSに移行しないレガシーコンポーネントを置き換えるためのソースを作成する場合も同様です。

この手順には、新しいデータベースの構築と検証も含まれます。これを容易にするために、Astadiaはレガシー・データ・ファイルのレイアウトとデータベース・スキーマを分析し、ETLプログラムだけでなくターゲット・データベースのフラット・ファイルとリレーショナル・スキーマを生成してデータを移行するDDL変換ツールを開発しました。ターゲットファイルとデータベース環境が検証されると、静的データをコードの移行や開発作業と並行して移行することができます。

頻繁に変更される動的データ – データは、カットオーバー中に本番環境に移行されます。

ステップ４：テスト

テストに関する良いニュースは、主に変更されたコードに焦点を当てる必要があることです。ほとんどのコードは変更されていないので、コードの各行を単体テストするという決定をしないとは思いますが、テストは次の項目に重点を置く必要があります。

  • 統合
  • データアクセス
  • ASCIIとEBCDICを使用することによって影響を受ける可能性のあるソートルーチン
  • データ型の変更に対応するコードの修正
  • 新しく開発されたコード

非メインフレームプラットフォーム（T27クライアントプラットフォームなど）から実行されるContinuous Integration/Continuous Deployment（CI/CD）パイプラインテストは、変更されずに維持され、DevOpsのベストプラクティスに従います。

レガシーアプリケーションの多くにはテストスクリプトとドキュメントがほとんどないため、テストスクリプトを開発するために時間とリソースを費やす必要があります。アプリケーションをAWS上でより頑強にするために、適切なテスト手順を開発する時間を投資することをお勧めします。また、負荷やストレステストを実行して、アプリケーションが大量のボリュームを処理できるようにする必要があります。

ステップ５：実装

移行されたアプリケーションのテスト、検証、および最適化が完了したら、それらのアプリケーションを展開するプロセスを開始できます。実際には、AWSインスタンスの作成や設定、Unisysメインフレームエミュレーションソフトウェア（Astadia OpenMCSなど）のインストールと設定、静的データの移行、その他のインフラストラクチャやフレームワークアクティビティなど、初期のフェーズと並行して多くの展開アクティビティが開始されます。

場合によっては、これを達成するために環境を複製することも、既存の環境を再利用することもできます。このような複製は、通常、AWS CloudFormationやAWS OpsWorksなどの自動化ツールによって容易になります。これらの詳細は、アプリケーションおよびデータの特性、および企業の標準または嗜好によって異なります。動的データを移行して検証した後、本番モードへの切り替えを完了できます。

Unisysメインフレーム移行のためのその他のリソース

すべてのUnisysメインフレームシステムは、特定の言語、サブシステム、バージョン、およびデータストアでユニークです。さらに、それぞれの場合で独自の機能要件、非機能要件や標準があります。 Astadiaは、上記の手順をお客様のニーズに合わせて調整し、ユニークな独自のツールセットを活用して、Unisys MainframeからAWSへの移行を成功させることができます。

 

Astadiaのユニークな機能と、UnisysからAWSへの参照アーキテクチャをご覧ください。

レガシー近代化の詳細については、astadia.com/insightsをご覧ください。

翻訳はPartner SA 諸岡が担当しました。原文はこちらです。