Amazon Web Services ブログ

AWS Mainframe Modernization Blu Age によるバッチジョブの移行と運用

多くの基幹系アプリケーションが現在もメインフレーム上で稼働していますが、急激に変化するビジネス環境に対応するべく、そのモダナイゼーションを図りたいと考えるお客様が増えています。
AWS Mainframe Modernization は、メインフレーム上のアプリケーションをAWSに移行し、稼働し、モダナイズするためのツールとマネージドサービスの集まりです。その中の AWS Blu Age は、アプリケーションの構造やソースコードの依存関係を分析し、リファクタリングすることで、クラウド上で稼働するJavaコードに自動変換します。
メインフレーム上のワークロードを AWS に移行するとき、プログラムやデータの移行だけでなく、多くの場合バッチジョブの運用も検討する必要があります。
このブログでは、ジョブスケジューラーの例として A-AUTO を取り上げ、AWS Blu Age でリファクタリングしたアプリケーションのバッチジョブをスケジューリングし自動実行する方法を紹介します。
注意: AWS Blu Age と A-AUTO の連携は動作確認済であり、本ブログの記述はその確認結果に基づいています。ただし、AWS Blu Age でリファクタリングしたバッチジョブの実行は、ジョブスケジューラーの実装から中立であり、特定のジョブスケジューラー製品に依存するものではありません。また、上述の連携の動作をサポートもしくは保証するものではありません。

バッチジョブ運用の移行に関する課題とソリューション

State Farm Insurance 社のブログには、メインフレームから AWS へのリプラットフォームに際して得られた教訓の一つとして、プラットフォーム間の違いを極小化するため単一のジョブでは無くジョブフローの単位で移行する、という記述があります。例えば、バッチジョブが異常終了したときのリカバリーやリランは、ジョブフローの単位で検討し手順化しておく必要があります。個々のプラットフォームに適した方法でリカバリーやリランの方法を実現しつつ、業務的には従来と同様に処理できるのが望ましいと考えられます。

クラウド移行によりバッチジョブ運用の俊敏性を向上したい場合は、オンプレミス環境のバッチジョブフローの AWS 移行方法検討事例に示されるように、AWS Step Functions によりクラウドネイティブなジョブ運用を実装するアプローチが参考になります。

一方で、バッチジョブの運用が業務的な運用と密接に連動しており、運用を変えたくない場合は、AWS 環境で稼働するジョブスケジューラーによる自動化が現実的な選択肢の一つとなります。

AWS Blu Age によるアプリケーションの自動リファクタリング

AWS Blu Age は、メインフレームやオフコンのモノリシックなレガシーコードを自動的にリファクタリングし、モダンなアプリケーションを生成します。COBOL や PL/I、4GL (RPG や Natural 等) を、Spring Framework ベースの Java コードに変換し、JCL を Groovy スクリプトに変換します。BMS ソースから Angular ベースのコードを生成し、画面のレイアウトとファンクションキーの操作を再現します。この過程で、Db2 for z/OS や Db2 for IBM i, IMS/DB, VSAM に対する入出力は、Amazon Aurora, Amazon Releational Database Service (Amazon RDS) for PostgreSQL, Oracle, IBM Db2 等のデータベースに対する入出力に変換されます。
AWS Blu Age の自動リファクタリングにより、元のレガシーコードの機能をクラウド上で再現することができます。移行後のバッチジョブは、AWS Command Line Interface (AWS CLI) もしくは RESTful API で起動することができます。手作業によるリライトと比較すると、メインフレームアプリケーションに対する変更を最小限に抑えつつ、9～18 ヶ月でモダンな Java アプリケーションにリファクタリングすることが可能です。

ジョブスケジューラーの例: A-AUTO

ユニリタ社のシステム運用ジョブ管理ツール A-AUTO は、IT システム上での業務処理のジョブスケジューリング等の自動化を支援する総合的な運用管理ツールです。分散コンピューティング環境に対応した A-AUTO for UNIX / Windows は Amazon Elastic Compute Cloud (Amazon EC2) 上での稼働をサポートし、AWS 上で実行するバッチジョブのスケジューリングを実現します。

ジョブスケジューラーと AWS Blu Age の連携によって得られる効果

AWS Blu Age によってメインフレームから AWS 上に移行したワークロードを、ジョブスケジューラーと連携して運用することにより、いくつかの効果が期待できます。

  • バッチジョブの集中管理: ジョブスケジューラーの機能により、バッチジョブの運用に関わる日次・週次・月次のスケジュールを予め設定しておき、そのスケジュールに従って自動的に実行することができます。データの到着をジョブの実行トリガーにすることも可能です。複数のジョブの先行/後続の関係をジョブネットワークとして定義し、管理することもできます。
  • バッチジョブ実行状況のリアルタイム監視: ジョブスケジューラーの機能により、バッチジョブおよびジョブネットワークの実行状況をリアルタイムでモニタリングすることができます。
  • 自動フェールオーバー: 高可用性および災害対策の要件に応じて、ジョブスケジューラーおよび AWS Blu Age のアーキテクチャを適切に構成することにより、障害発生時の自動フェールオーバーが可能です。
  • 既存コンピューティング環境で稼働するジョブとの連携: AWS Blu Age をジョブスケジューラーと組み合わせることにより、アプリケーションとバッチジョブ運用を合わせてメインフレームから AWS クラウドに移行し、既存の分散コンピューティング環境とのジョブ連携を維持し拡張することができます。

ソリューション概要

A-AUTO と AWS Blu Age はシングル構成での運用も可能ですが、ミッションクリティカルなワークロードの稼働をサポートするべく、高可用性構成に対応しています。

マルチ AZ 高可用性アーキテクチャ構成例

図 1. A-AUTO と AWS Blu Age のマルチ AZ 高可用性アーキテクチャ
図 1. A-AUTO と AWS Blu Age のマルチ AZ 高可用性アーキテクチャ

  • 稼働系の EC2 インスタンス①上で A-AUTO Server と A-AUTO モニターが稼働します。AUTO モニターは、AWS Blu Age ⑦に対して、バッチジョブの実行を指示し、ジョブのステータスをモニタリングします。
  • 稼働系の EC2 インスタンス①と待機系の EC2 インスタンス②はサイオステクノロジー株式会社の LifeKeeper ③によって HA クラスターを構成します。HA クラスターの仮想 IP アドレスで EC2 インスタンスにアクセスするため、フェールオーバーが発生しても A-AUTO クライアントからのアクセスは影響を受けません。
  • サイオステクノロジー株式会社の DataKeeper ⑥は、稼働系の Amazon Elastic Block Store (Amazon EBS) ボリューム④を待機系の EBS ボリューム⑤にミラーリングし、ロジカル共有ディスクを構成します。この構成例では DataKeeper を使いましたが、利用するジョブスケジューラー製品がサポートする他のクラスタリングソリューションによる構成も可能です。
  • AUTO モニターは、AWS Blu Age ⑦に対して、バッチジョブの実行を指示し、ジョブのステータスをモニタリングします。

この場合の RPO と RTO は以下のようになります。

  • RPO: DataKeeper によるミラーリングのタイムラグ(同期ミラーリングの場合の RPO はゼロ)
  • RTO: 稼働系 EC2 インスタンスから待機系 EC2 インスタンスへのフェールオーバーの設定値(LifeKeeper のハートビート間隔×連続失敗回数)

動作確認結果概要

今回の動作確認により、A-AUTO によるジョブスケジューリングが AWS Mainframe Modernization サービスと正常に連携し、AWS Blu Age によってリファクタリングしたレガシーアプリケーションのバッチジョブを運用できることが実証されました。

EC2 インスタンス上の Windows Server で稼働する A-AUTO にジョブネットワーク AUTO01 を登録し、実行しました。ジョブネットワーク AUTO01 は、AWS Blu Age 上のメインフレームサンプルアプリケーション CardDemo のバッチジョブで構成され、以下の図のような構造になっています。

図 2. AWS Mainframe Modernization サービスにデプロイした CardDemo アプリケーションのアーキテクチャ
図 2. AWS Mainframe Modernization サービスにデプロイした CardDemo アプリケーションのアーキテクチャ

図 3. ジョブネットワーク AUTO01 の構造
図 3. ジョブネットワーク AUTO01 の構造

このジョブネットワークは、3 つのバッチジョブ: SORTTEST, LISTCAT, DUSRSECJ で構成されています。各バッチジョブの実体は共通のスクリプト M2JOB です。スクリプト M2JOB 内で AWS Mainframe Modernization サービスの API を呼び出す AWS CLI コマンドを発行し、バッチジョブの実行を制御します。例えば、バッチジョブの実行は、aws m2 start-batch-job コマンドで開始します。

JCL を変換した結果である Groovy スクリプトは、M2JOB の実行時パラメータとして引き渡します。例えば、先頭のバッチジョブ @M2JOB01 の定義は以下のようになっており、ジョブコード M2JOB に対して、Groovy スクリプト SORTTEST.jcl.groovy が引き渡されていることがわかります。

図 4. バッチジョブ @M2JOB01 の定義
図 4. バッチジョブ @M2JOB01 の定義

ジョブネットワーク AUTO01 の手動実行

図 5. ジョブネットワーク AUTO01 の実行開始操作
図 5. ジョブネットワーク AUTO01 の実行開始操作

ジョブネットワーク AUTO01 の先頭のバッチジョブ @M2JOB01 にホールド属性を設定してあるため、初期状態ではキューイング済みというステータスになります。@M2JOB01 を右クリックしてリリースすることにより、その実行を手動で開始することができます(①→②→③)。すると、バッチジョブ @M2JOB01 が実行中になったことが視覚的にわかります(④)。

このとき、ジョブネットワーク AUTO01 の状態を表示すると、ステータスは「キューイング済み」から「実行中」に変わっています。

図 6. 実行中のジョブネットワーク AUTO01 の状態
図 6. 実行中のジョブネットワーク AUTO01 の状態

実行中ステータスになったバッチジョブ @M2JOB01 の詳細は以下のように確認することができます。

図 7. 実行中のバッチジョブ @M2JOB01 の詳細
図 7. 実行中のバッチジョブ @M2JOB01 の詳細

バッチジョブ @M2JOB01 の詳細画面で[ジョブログ表示]を押すと(①)、その時点でのジョブログが表示されます(②)。実行開始時に一意に発番される execution ID が確認でき(③)、実行開始日時とステータス Running が表示されます。

ジョブネットワーク AUTO01 の各バッチジョブの実行状態の推移は、以下の図のように視覚的に表示されます。実行中のバッチジョブは緑色で表示され、正常終了すると青色に変化します。全てのバッチジョブが青色になったことで、このジョブネットワーク全体が正常終了したことがわかります。

図 8. ジョブネットワーク AUTO01 の実行状態の推移
図 8. ジョブネットワーク AUTO01 の実行状態の推移

AWS Blu Age バッチジョブの実行状態照会

以上から、A-AUTO の管理機能により、AWS Blu Age のバッチジョブの実行を一元的に管理できることがわかったと思います。一連の処理は、AWS マネジメントコンソールを操作せずに実行できました。

一方で、同じバッチジョブの実行状況を AWS マネジメントコンソールで見ても一貫性ある結果になっていることを見てみましょう。以下の操作は、技術的な理解を深めて頂くための参考情報であり、通常のジョブ運用で必要なものではありません。

AWS マネジメントコンソールで AWS Mainframe Modernization のアプリケーションを選ぶと、AWS Blu Age の CardDemo アプリケーションが一覧に表示されています。

図 9. AWS Mainframe Modernization アプリケーション
図 9. AWS Mainframe Modernization アプリケーション

一覧の card-demo-app をクリックし、[バッチジョブ]タブを選ぶと、実行したバッチジョブの一覧が表示されます。[ジョブ名]欄の表示から、A-AUTO で実行したバッチジョブ DUSRSECJ, LISTCAT, SORTTEST を識別することができます。

図 10. CardDemo アプリケーションのバッチジョブ一覧
図 10. CardDemo アプリケーションのバッチジョブ一覧

この中で、上から 3 行目のバッチジョブ SORTTEST をクリックすると、その詳細が以下のように表示されます。

図 11. CardDemo アプリケーションのバッチジョブ SORTTEST の詳細
図 11. CardDemo アプリケーションのバッチジョブ SORTTEST の詳細

リターンコードが 0 であることから、このバッチジョブが正常終了したことがわかります。

実行 ID により、この実行を一意に識別することができます。

このバッチジョブの処理内容は、下方に表示されているスクリプト SORTTEST.jcl.groovy に記述されています。A-AUTO の「図 4 バッチジョブ @M2JOB01 の定義」でパラメータに指定したのは、このスクリプト名でした。

Amazon CloudWatch Logs によるバッチジョブの実行状態照会

CloudWatch Logs のロググループで、AWS Blu Age のコンソールログを照会することができます。

図 12. CloudWatch Logs のロググループ一覧上の AWS Blu Age コンソールログ
図 12. CloudWatch Logs のロググループ一覧上の AWS Blu Age コンソールログ

AWS Blu Age コンソールログのロググループをクリックすると、その詳細が表示されます。

図 13. AWS Blu Age コンソールログのロググループ詳細
図 13. AWS Blu Age コンソールログのロググループ詳細

ログストリームをクリックすると、その内容が以下のように表示されます。各セクションをクリックして展開すると、コンソールに出力されたメッセージが表示されます。この画面のマウスカーソル位置に、AWS Blu Age ジョブ SORTTEST の開始時に出力されたメッセージが表示されています。

図 14. ログストリームの詳細表示
図 14. ログストリームの詳細表示

おわりに

メインフレーム上のワークロードを AWS Blu Age による自動リファクタリングで AWS クラウドに移行する際に、AWS クラウド上で稼働するジョブスケジューラーと連携して AWS Blu Age バッチジョブが動作可能であることが、今回確認できました。現行のバッチプログラムを AWS に移行するとき、現行のバッチジョブ運用を踏襲して運用することが可能です。更に、要件に応じた高可用性構成での運用も可能となります。

AWS Mainframe Modernization に関するご相談は、担当営業にご連絡頂くか、もしくは公式サイトの Web フォーム でお問い合わせください。

著者

皆川 元
フィナンシャルサービスインダストリ技術本部 エマージングソリューション部 ソリューションアーキテクト