Amazon Web Services ブログ

メインフレームとAWSを統合する共存アーキテクチャ

メインフレームとAWSを統合する共存アーキテクチャ

本記事は 2024 年 9 月 3 日に Migration & Modernization Blog で公開された Integration architectures between mainframe and AWS for coexistence を翻訳したものです。

ブログでは、移行期におけるハイブリッド アーキテクチャの統合パターンとソリューションの設計方法を説明します。

メインフレーム環境のアプリケーションは、コードやデータもしくはその両方を共有することで、複雑に絡み合い密結合している場合があります。大規模なメインフレームアプリケーションを AWS に移行する際は、Strangler Fig パターンを使用した段階的アプローチが推奨されます。段階的アプローチにより、移行 (マイグレーション) または変革 (モダナイゼーション) の過渡期の間、メインフレームと AWS 間のハイブリッドアーキテクチャが構築され、その統合が実現されます。

概要

メインフレームのワークロードは通常、一連のビジネス機能を実行する一連のプログラム、ミドルウェア、データストア、依存関係、およびリソースとして定義されます。AWS は、お客様のビジネスおよび技術戦略の目標に応じて、メインフレームのワークロードをモダナイズするための複数のパターンを提案します。これらのオプションは大きく 2 つのグループに分類できます。

  1. マイグレーション & モダナイゼーション (図 1.1 – 左)
  2. 拡張 & 統合 (図 1.2 – 右)

図 1: AWS Mainframe Modernization パターン

アプリケーションと移行の目的に合わせて、リプラットフォーム、リファクタリング、リライト、リパーチェスなどの各種手法を用い、メインフレームからコンポーネントを切り離して AWS クラウドに移行することを目指します。

ワークロードの拡張と統合は、メインフレームのデータを活用して、AWS 上に新しいビジネス機能を構築することを目的としています。

どちらのアプローチでも、メインフレームと AWS 環境を統合する共存アーキテクチャーが必要です。これには、移行フェーズ中または永続的にメインフレーム上に残るワークロードと、AWS クラウドに作成または移行されたワークロード間の相互作用の管理が含まれます。

アプローチ

通常、大規模なメインフレームのワークロードは並行して実行され、相互に密結合しています。Strangler Fig パターンの場合、各ワークロードは個別に移行されます。全体的に見れば、ワークロードを 1 つずつ順番に移行します。ビジネス価値、アプリケーションの複雑さ、統合ポイント、ビジネスの重要性に基づいてワークロードの移行に優先順位を付けます。時間の経過とともに、メインフレームのワークロードを 1 つずつ分離していきます。

Mainframe application migration by strangling workloads

図 2: ワークロードの絞り込みによるメインフレームアプリケーションの移行

メインフレームワークロードの移行に際しては、それらと強く結び付いた別のワークロードが存在しています。それらのワークロードにはアプリケーション間、データ間、またはアプリケーションとデータ間の統合機能が組み込まれています。図 2 は、一部のワークロードが AWS  に移行され、他のワークロードがメインフレームに残るシナリオを示しています。

図 3 は、3 つの異なるタイプの統合を説明しています。

  • アプリケーション間
  • アプリケーションからデータへ
  • データ間

図 3: 共存のためのハイブリッドアーキテクチャの必要性

さまざまな統合タイプは相互に排他的ではなく、むしろ互いに補完し合うことができます。統合タイプの選択は、主に、ワークロード間のメインフレーム上の既存の統合設定に影響されます。たとえば、ワークロードがアプリケーションコンポーネント (CICS、COBOL、MQ コールなど) を介してワークロード 2 とやり取りする場合は、アプリケーション間のパターンを確立する必要があります。逆に、ワークロードがワークロード 2 のデータにアクセスする必要がある場合は、データからデータへ、またはアプリケーションからアプリケーションへのパターンのいずれかを実装する必要があります。これらのパターンと関連する技術的実装のどちらを選択するかは、主に、スループット、パフォーマンス、プライマリデータの場所という 3 つの重要な基準に基づいて決定されます。

統合パターン

以下のパターンは、共存シナリオでのアプリケーション統合とその利用可能なソリューションについて理解するのに役立ちます。市場には多数の製品がありますが、ここでは数種類について説明します。

パターン 1 – アプリケーション間の統合パターン

アプリケーション間統合パターンとは、2 つのソフトウェアアプリケーションやシステムを接続し、それらが協調して動作できるようにするプロセスを指します。用途や要件に応じて、さまざまなタイプのアーキテクチャと統合方式があります。

アーキテクチャ的には、アプリケーションを統合するための手法として、ハブアンドスポーク、エンタープライズサービスバス (ESB)、API マネジメントなど、複数のパターンが存在します。これらのアーキテクチャパターンでは、メインフレームと他の環境の間で仲介役を果たす、中央統合ハブやミドルウェアプラットフォームが関わります。各アプリケーションはハブ、ESB、またはAPIマネジメントレイヤーにのみ接続すれば良く、それらが接続システム間のデータのルーティングと変換を管理します。このアプローチにより、統合の管理と保守が簡素化されます。中央ハブ、ESB、または API マネジメントレイヤーとメインフレーム間の接続は、図 4 で説明されているポイントツーポイント統合パターンに依存します。

Application to Application integration pattern.

図 4: アプリケーション間の統合パターン

AWS クラウドとメインフレーム間の最も一般的な統合タイプは以下のとおりです。

JCA コネクタを使用したポイントツーポイント

このタイプの統合では、2 つのアプリケーションを相互に直接接続してデータを交換します。Java Connector Architecture (JCA) コネクタを使用したポイントツーポイント統合では、Java EE アプリケーションと CICS、IMS TM、Db2 ストアドプロシージャなどのメインフレームサブシステムとの直接接続を確立する必要があります。JCA コネクタとのポイントツーポイント統合には、Java アプリケーションとメインフレームを直接接続できるため、パフォーマンス、スケーラビリティ、トランザクション性のサポート、セキュリティが向上するなどのメリットがあります。一方、統合システム間の緊密な結合が生じるため、メッセージングや API のように疎結合された統合アプローチに比べて、柔軟性が低下し、保守が困難になります。

CICS、IMS、Db2 との統合に使用される主な 3 つのポイントツーポイントソリューションは次の 3 つです。

  • CICS との統合には CICS Transaction Gateway (CTG) を使用します。CTG は z/OS またはオープンシステム上にデプロイできます。
  • IMS との統合には IMS Connect を使用します。IMS Connect は z/OS 上にデプロイする必要があります。
  • 外部アプリケーションから直接 JDBC 接続して Db2 for z/OS ストアドプロシージャを呼び出す。

JCA コネクタを使用したポイントツーポイント統合の注目すべき点は、その単方向性です。つまり、双方向通信をサポートする IMS Connect の場合を除き、 AWS クラウドからメインフレームに流れ、その逆は行われないということです。

API ベースの統合

RESTful API ベースの統合は、ソフトウェアシステムを統合するための柔軟で標準化されたアプローチを提供します。これにより、相互運用性、スケーラビリティ、および開発の容易さが可能になります。RESTful API は、Web 開発、モバイルアプリ、クラウドコンピューティング、Internet of Things (IoT) など、さまざまな分野で広く使用されています。RESTful API ベースの統合を使用するアプリケーションは、2 つの環境間でのトランザクションコンテキストの伝播が軽減されるように設計する必要があります 。(例えば、SAGA パターンや補償メカニズムを使う) そうしないと、一貫性の問題や同期の問題が発生する可能性があります。

IBM の z/OS Connect や OpenLegacy などのソリューションを使用することで、メインフレームのサブシステムをAPI化することができます。z/OS Connect を使用すると、プログラム、データ、トランザクションなどのメインフレームの資産を RESTful API として公開することができます。これにより、クラウド上の幅広い最新アプリケーションやサービスからこれらの資産にアクセスし、利用することができるようになります。z/OS Connect の大きな利点の 1 つは、双方向の統合機能を持っていることです。これにより、最新のアプリケーションとメインフレームシステムの間で、双方向の通信が可能になります。つまり、最新のアプリケーションがメインフレームからサービスやデータを利用できるだけでなく、メインフレームのトランザクションやアプリケーションが AWS からアプリケーションやサービスを利用することもできるのです。

メッセージ指向とイベント駆動型の統合

アプリケーションは、メッセージを介して非同期に通信します。メッセージはキューに入れられ、システム間で確実に配信されます。メッセージ指向とイベント駆動型の統合は、パブリッシュサブスクライブやリクエストリプライなど、様々なメッセージングパターンをサポートできます。IBM MQ は、メインフレームと AWS 間の通信とデータ交換を促進する主要なメッセージングミドルウェアの 1 つです。パブリッシュサブスクライブパターンやリクエストリプライパターンを活用することで、メインフレームとの統合に使用できます。

もう1つのオプションは、IBM MQ を介して Kafka をメインフレームと統合することです。これには、適切なコネクターを使用してKafkaとMQの間の通信を確立するために、Kafka Connect を使用することが含まれます。Kafka Connect は、メインフレームまたはクラウド上で実行できます。Kafka Connect は、Kafka とメインフレームアプリケーションとのデータストリーミングのためのコネクター構築とデプロイのフレームワークを提供することで、統合プロセスを簡素化します。Kafka を使用すると、メインフレームと AWS の間で追加の統合作業を行うことなく、関連するトピックに追加のコンシューマーがサブスクライブできます。

パターン 2 – データ間の統合パターン

ワークロードが AWS クラウドに移行され、他のワークロードがまだメインフレームにある場合、メインフレームとの間でデータを送信する頻度に応じてさまざまな方法があります。図 5 は、データ転送のニーズと頻度に対応するために構築する必要がある、さまざまな統合パターンを示しています。

Data to data integration patterns

図 5 : データ間の統合パターン

ニアリアルタイムのデータ転送

ニアリアルタイムのデータ転送とは、あるプラットフォームから別のプラットフォームへ、ニアリアルタイムにデータの更新を複製できるプロセスです。関連するツールは、変更ログに基づいてニアリアルタイムでデータを移行するために、変更データキャプチャ (CDC) を使用します。データ転送の要件は、単方向、両方向、または双方向である可能性があります。

単方向とは、メインフレームのデータソースから AWS のデータソースへ、またはその逆方向のいずれかに、データを複製する必要があることを意味します。両方向とは、データのレプリケーションが両方向で行われる必要があるものの、異なる関連性のないテーブルに対して行われることを意味します。一方、双方向は、レプリケーションが両方向で行われる必要があるが、関連するテーブルに対して行われることを意味します。関連するテーブルへの更新によるデータの競合という追加の課題があるため、双方向レプリケーションは最後の手段とすべきです。メインフレームから AWS にアプリケーションを移行する際、一方のプラットフォームのアプリケーションからの更新を、もう一方ですぐに利用できるようになります。

AWS Mainframe Modernization サービスは、Precisely 社の CDC テクノロジーを採用した AWS Mainframe Modernization Data Replication を使用して、メインフレームと AWS 間のデータレプリケーションを実現します。これにより、Db2、IMS、VSAM などのメインフレームや  IBM i データソースから、幅広い AWS クラウドデータベースの宛先へ、およびその逆方向に、異種データをニアリアルタイムで複製することができます。AWS のデータレプリケーションは、レイテンシーの低い CDC テクノロジーを活用しており、ソースデータベースに加えられた変更がニアリアルタイムでターゲットデータベースに伝播されると同時に、データの一貫性、正確性、鮮度、および有効性も確保されます。この機能により、共存シナリオ、分析、新しいチャネルの作成など、さまざまなユースケースが可能になります。

ファイルベースの転送

ほとんどの企業では、メインフレームからデータを移動するためのファイルベースの転送メカニズムが存在します。IBM Sterling Connect:Direct または SFTP のようなメカニズムを使用して、ファイル転送をサポートすることができます。メインフレームとオープンシステム間のファイル転送における課題の1つは、データ形式の違いです。メインフレームの COMP、COMP-3、その他のバイナリフィールドを持たないファイルの場合、SFTP と IBM Sterling Connect:Direct は、そのままデータ転送に使用できます。（EBCDIC を ASCII ベースまたは選択した文字セットに変換）。バイナリフィールドを持つファイルの場合は、特別な変換ソフトウェアが必要です。AWS Mainframe Modernization サービスは、さまざまな共存、拡張、移行のユースケースをサポートするためのファイル転送機能を提供しています。AWS Mainframe Modernization File Transfer を使用すると、完全に管理されたサービスでデータセットとファイルを転送および変換し、AWS Mainframe Modernization サービスと Amazon S3 へのモダナイズ、移行、拡張のユースケースを加速および簡素化できます。

抽出、転送、ロード (ETL)ベースの転送

ETL ベースの転送は、メインフレームから AWS にデータを移動するためのデータ統合および転送メカニズムです。メインフレームのソース (VSAM、Db2 など) のデータは、変換プロセスの一部として抽出、整理、クレンジングされ、AWS にアップロードされます。ETL プロセスのすべてにおいて、ソースとターゲットへの JDBC 接続が使用されます。この方法は、AWS Glue のような ETL 専用ツールや IBM data stage、Informatica、Precisely ETL connect  などの ISV 製品によってサポートされており、メインフレームのデータソースから AWS のデータソースへ、またはその逆方向にデータを移行することができます。

アーカイブデータ転送

仮想テープライブラリ (VTL) のようなメインフレーム独自のストレージソリューションは、複雑なツールを備えたプラットフォームに貴重なデータが保持しています。これにより、それらのデータ検索タスクのためのメインフレームでのコンピューティングおよびストレージのコストが高くなる可能性があります。アーカイブデータ転送のパターンは、メインフレームテープから Amazon S3 にデータを移動するのに役立ちます。BMC AMI Cloud は、顧客がメインフレームのテープを Amazon S3 に移動することを可能にします。

パターン 3 – アプリケーションとデータの統合パターン

このオプションは、プラットフォーム間でアプリケーションとデータの統合を実装することです (図6) 。アプリケーションとデータの統合とは、AWS またはメインフレーム上で実行されているアプリケーションが、AWSまたはメインフレーム上にリモートでホストされているデータにアクセスすることを意味します。

Application to data integration patterns
図 6: アプリケーションとデータの統合パターン

一般的に、ローカルデータへのアクセスを可能にし、リモートデータアクセスに伴う遅延の影響を回避するためには、データ間の統合が望ましいです。データが非常に密接に結合されている場合、データ間の統合パターンを実装することは困難になります。このような場合、アプリケーションとデータの統合の方が適している可能性があります。

アプリケーションとデータの統合パターンの2つのバリエーション

  • データの単一コピーを使用するアプリケーションとデータの統合
  • デュアル書き込みを活用したアプリケーションとデータの統合

データの単一コピーパターン

このパターンのバリエーションでは、AWS またはメインフレームのいずれかに存在する、データの単一の情報源があります。データがローカルにないアプリケーションは、JDBC やゲートウェイなどの技術を使用してリモートアクセスを実行する必要があります。このパターンは、単一のデータコピーを維持することでデータ管理を簡素化しますが、データにアクセスするリモートアプリケーションにレイテンシが発生し、アプリケーション全体のパフォーマンスに影響を与えます。

  1. AWS にアプリケーション、メインフレームにデータベース – このタイプの統合では、クラウド上のアプリケーションがメインフレームデータベースに直接接続されています。Java Connector Architecture (JCA) コネクタを使用したポイントツーポイント統合は、標準化されたインターフェース、パフォーマンスの向上、移植性、スケーラビリティ、クラウド上の Java アプリケーションとメインフレーム上のデータベース間の直接接続を確立することによるトランザクション性とセキュリティのサポートなどの利点を提供します。一方で、JCA や JDBC を使った統合では、統合されるシステム間に密結合をもたらし、その結果、システムの柔軟性が低下しメンテナンスが困難になる傾向があります。JCA コネクタまたは JDBC を使用したポイントツーポイント統合は、本質的に一方向であり、統合はクラウド上のアプリケーションからメインフレームデータベースにのみ流れることを意味します。
  2. メインフレーム上のアプリケーションと AWS 上のデータベース、またはその逆の組み合わせには、様々な統合方法があります。 メインフレーム上のアプリケーションは、Db2 フェデレーテッドサーバーを使用して、AWS 内のデータベースにアクセスすることができ、その逆もまた同様です。これにより、あいまいさを減らすことができ、データのコピーを 1 つだけ保存すればよいため、運用の複雑さを軽減できます。

フェデレーションは、機能ごとにデータベースを分割するスケーリング手法です。メインフレームデータのフェデレーションは、異種データへのリアルタイムアクセスを統一的な方法で提供し、最小限の設定オーバーヘッドで、AWS またはその逆の分散アプリケーションやデータベースでの利用を可能にします。ただし、フェデレーテッドサーバーは、異なるデータストアからのデータ結合に関して、ある程度の複雑さの層を導入するため、クエリのパフォーマンスとアプリケーションのスケーラビリティに影響を与える可能性があります。

仮想化もデータ管理技術のひとつで、アプリケーションはデータのフォーマットや所在に関する技術的な詳細を知らなくても、データにアクセスしたり変更したりすることができます。IBM Data Virtualization Manager for z/OS(IBMz DVM) は、データをコピーまたは移動する必要なく、複数のソースからのデータの単一表現を作成します。このため、AWS 上の分散アプリケーションとデータベースは、メインフレーム上のさまざまなデータストア (IMS、IDMS、または Db2) とファイルシステム (シーケンシャル、VSAM、VSAM CICS、ADABAS、または MQ) にアクセスできます。 仮想化により、アプリケーション開発者からデータ実装を隠蔽し、メインフレーム資産を API として AWS アプリケーションやデータベース上の分散チャネルに安全に公開します。 データ仮想化はデータ連携とは対照的に、データベースの結合や初歩的なデータ処理を使用した単純なデータ処理に限定されています。

デュアル書き込みパターン

このパターンのバリエーションでは、データのコピーが 2 つあり、1 つは AWS 上に、もう 1 つはメインフレーム上にあります。レプリケーションメカニズムを使用する代わりに、アプリケーションは両方のロケーションに対して二重の書き込み ( 挿入/更新 ) を実行します。このパターンでは、読み込み操作はローカルで行われ、書き込み操作はローカルとリモートの両方で行われるため、レイテンシの影響を減らすことができます。 書き込み頻度が低く、読み出し頻度が高いアプリケーションに適しています。大きな欠点は、1 つのトランザクション内で 2 つの書き込みを実行し、データの整合性と一貫性を確保するために、アプリケーションレベルで複雑さが生じることである。 このパターンは、ニアリアルタイムの同期を提供するデータ間統合とは異なり、両方の場所でリアルタイムのデータコピーを提供します。

  1. AWS 上のアプリケーションとメインフレーム上のデータベース – このタイプの統合では、AWS 上とメインフレーム上の両方でデータの同期コピーを保持します。 AWS 上のアプリケーションは、AWS データベースとメインフレームデータベースに同時に直接接続されます。 この統合は、AWS 上の Java EE アプリケーション、AWS 上のデータベース、JDBC を介したメインフレームデータベース間の直接接続を確立する JCA (Java Connector Architecture) コネクタを使用して実現されます。 デュアル書き込みの選択は、アーキテクチャにデータの弾力性を追加しますが、アプリケーションにパフォーマンスの問題をもたらす可能性があります。統合の特性と性質は、AWS 上のアプリケーションとメインフレーム上のデータベースによるデータの単一コピーパターンに似ています。
  2. メインフレーム上のアプリケーションとメインフレームと AWS 上のデータベース – メインフレーム上のアプリケーションをメインフレーム上のデータベースと AWS 上のデータベースに直接統合する様々なチャネルは、メインフレームと AWS 上に同期的にコピーされたデータを保存するという唯一の違いで、データの単一コピーパターンに似ています。

まとめ

大規模な顧客がメインフレームアプリケーションを AWS に移行する際、一部の顧客は、ビッグバン移行に伴うリスクを最小限に抑えるために、Strangler Fig パターンを使用した段階的なアプローチを採用します。このアプローチでは、メインフレームと AWS 間の相互運用性が必要です。この記事では、この相互運用性を促進するさまざまな統合パターンについてまとめました。すべての統合シナリオに対して、万能のソリューションはありません。各パターンには、それぞれ長所と短所があります。これらの統合パターンを選択する際は、慎重な検討が必要です。決定のための主な要因には、スループット、パフォーマンス、トランザクションコンテキストの伝播、整合性、および主要データの場所が含まれます。

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

本記事は、Yann Kindelberger, Chiranjeev Mukherjee, Saikat Chatterjee による “Integration architectures between mainframe and AWS for coexistence” を翻訳したものです。翻訳はソリューションアーキテクトの萩野谷聡が担当しました。