メインフレームから AWS への移行途中の過渡期に於ける両環境併存のための連携アーキテクチャ

このブログ記事では、移行途中の過渡期に於けるハイブリッドアーキテクチャの連携パターンと連携ソリューションを設計する方法を紹介します。

多くの一般的なメインフレーム環境には、データやコードを共有するアプリケーション間の複雑で密結合されたシステム間連携があります。メインフレームアプリケーションを AWS クラウドに移行するとき、大規模な移行には Strangler fig パターンを使用した段階的なアプローチが推奨されます。インクリメンタルなアプローチでは、過渡期 (移行) フェーズまたはトランスフォーメーション (モダナイゼーション) フェーズ中に、メインフレームと AWS クラウド間のハイブリッドアーキテクチャを構成する連携を実装することになります。

概要

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

マイグレーション & モダナイゼーション (図 1.1 — 左側)
拡張 & 連携 (図 1.2 — 右側)

図 1. AWS Mainframe Modernization パターン

ワークロードのマイグレーションまたはモダナイゼーションは、アプリケーションと移行の目的に応じた一連の戦略 (replatform, refactor, rewrite, repurchase) に従ってメインフレームからコンポーネントをオフロードし、AWS クラウドに移行することを目的としています。

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

いずれのアプローチでも、メインフレームと AWS 環境との共存を促進する連携アーキテクチャが必要です。これには、移行の過渡期もしくは恒久的にメインフレームに残されるワークロードと、AWS クラウドに移行または作成されるワークロードとの間の相互作用を管理することが含まれます。

アプローチ

一般的に、大規模なメインフレームワークロードは同時並行的に実行され、互いに密結合しています。Strangler fig パターンでは、各ワークロードは個別に移行されます。ハイレベルで見ると、個々のワークロードが段階的に次々と移行されます。ビジネス価値、アプリケーションの複雑さ、連携ポイント、およびビジネスの重要性に基づいて、ワークロードの移行に優先順位を付けます。時間の経過とともに、メインフレームのワークロードは一つずつ切り離されていきます。

図 2. ワークロードに Strangler fig パターンを適用したメインフレームアプリケーションの移行

メインフレームワークロードの移行を開始しようとすると、メインフレームと密に連携されているワークロードは他にもあることがわかります。それらには、アプリケーション間連携、データ間連携、そしてアプリケーションからデータへの連携があります。図 3 では、一部のワークロードを AWS に移行し、他のワークロードがメインフレームに残るシナリオを示しました。
図 3 に示す連携は、以下の 3 種類です。

アプリケーション間の連携
アプリケーションからデータに対する連携
データ間の連携

図 3. 移行前後のシステムが併存するハイブリッドアーキテクチャが必要

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

連携パターン

以下のパターンは、併存シナリオにおけるアプリケーション連携と利用可能なソリューションを理解するのに役立ちます。これらの機能を実現する製品は市場に出回っていますが、ここではそのうちのいくつかについて説明します。

パターン 1 — アプリケーション間の連携パターン

アプリケーション同士の連携は、アプリケーション間連携パターンと呼ばれ、2 つのソフトウェアアプリケーションまたはシステムを接続して連携させるプロセスを指します。アーキテクチャと連携にはいくつかのタイプがあり、それぞれ目的が異なり、さまざまなニーズに応えます。

アーキテクチャ的には、アプリケーション連携ための Hub-and-Spoke、Enterprise Service Bus (ESB)、API マネジメントなど、複数のパターンがあります。これらのアーキテクチャパターンには、メインフレームと他の環境との間の仲介役として機能する中央集権型の連携ハブやミドルウェアプラットフォームが含まれます。各アプリケーションをハブ、ESB、または API マネジメント層と連携するだけで、接続されたシステム間のデータルーティングと変換が管理されます。このアプローチにより、連携の管理と保守を簡素化できます。中央ハブ、ESB、または API マネジメント層とメインフレームの間は、図 4 に示す point-to-point の連携パターンで接続します。

図 4. アプリケーション間連携パターン

AWS クラウドとメインフレーム間の最も一般的な連携タイプをいくつか紹介します。

JCA コネクタを使った point-to-point 連携

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

CICS、IMS、Db2 と統合するための 3 つの主な point-to-point 連携ソリューションを以下に示します。

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

JCA コネクタを使用した point-to-point 連携のもう 1 つの注目すべき点は、その単方向性です。つまり、双方向通信をサポートする 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 Connect を使用した Kafka と MQ 間の通信を伴います。Kafka Connect はメインフレームでもクラウドでも実行できます。Kafka とメインフレームアプリケーション間でデータをストリーミングするコネクタを構築およびデプロイするためのフレームワークを提供することで、連携プロセスを簡素化します。Kafka を使うと、メインフレームと AWS クラウド間で追加の連携作業を行わなくても、より多くのコンシューマーが自分のドメインに関連するトピックを購読できるようになります。

パターン 2 — データ間の連携パターン

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

図 5. データ間連携パターン

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

ニアリアルタイムのデータ転送は、あるプラットフォームから別のプラットフォームにニアリアルタイムで複製しデータを更新できるようにする処理です。本機能を実現するツールは Change Data Capture (CDC) を使用して、変更ログに基づいてニアリアルタイムでデータを移行します。データ転送のニーズは、単方向、単方向と逆向き単方向の組み合わせ、あるいは双方向である可能性があります。

単方向とは、メインフレームのデータソースから AWS データソースに、またはその逆にデータを複製する必要があることを意味します。単方向と逆向き単方向の組み合わせとは、データのレプリケーションを双方向で行う必要があるものの、異なるテーブルや無関係なテーブルに対して行う場合です。双方向とは、関連する複数のテーブルで両方向にレプリケーションを実行する必要があることを意味します。双方向レプリケーションは、関連テーブルの更新によるデータ競合という課題が増えるため、最終手段にすべきです。アプリケーションをメインフレームから AWS に移行すると、あるプラットフォームのアプリケーションからの更新を別のプラットフォームでもすぐに利用できるようになります。

AWS Mainframe Modernization サービスは、CDC テクノロジーと AWS Mainframe Modernization Data Replication powered by Precisely を使って、メインフレームと AWS 間のデータレプリケーション機能を提供します。これにより、Db2、IMS、VSAM などのメインフレームや IBM i (AS/400) のデータソースから、さまざまな AWS クラウドデータベースに向けて、またはその逆に、異種データをニアリアルタイムで複製できます。AWS のデータレプリケーションでは、低レイテンシー CDC テクノロジーが活用されています。このテクノロジーでは、ソースデータベースに加えた変更がニアリアルタイムでターゲットデータベースに伝達されると同時に、データの一貫性、正確性、鮮度、有効性も確保されます。この機能により、併存シナリオや、データ分析、新規チャネルの展開など、さまざまなユースケースが可能になります。

ファイルベースの転送

ほとんどの企業には、メインフレームからデータを移動するためのファイルベースの転送メカニズムがあります。NDM (Network Data Mover) や SFTP のような仕組みを使ってファイル転送をサポートできます。メインフレームとオープンシステム間のファイル転送における課題の 1 つは、データ形式の違いです。メインフレームの COMP、COMP-3、その他のバイナリフィールドがないファイルの場合、SFTP と NDM はそのままデータ転送を行うことができます (EBCDIC を ASCII ベースまたは選択した文字セットに変換)。バイナリフィールドを含むファイルには、特定の変換ソフトウェアが必要です。AWS Mainframe Modernization サービスでは、併存、拡張、移行のさまざまなユースケースをサポートするファイル転送機能を提供しています。AWS Mainframe Modernization File Transfer を利用すると、フルマネージドサービスを使ってデータセットとファイルを転送および変換できるため、AWS Mainframe Modernization service サービスと Amazon S3 へのモダナイゼーション、移行、拡張のユースケースを加速および簡素化することができます。

Extract, Transfer, and Load (ETL) ベースの転送

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

アーカイブされたデータの転送

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

パターン 3 — アプリケーションからデータへの連携パターン

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

図 6. アプリケーションからデータへの連携パターン

一般に、リモートデータアクセスに伴うレイテンシーの影響を回避しつつローカルデータアクセスを可能にするには、データ間の連携を行うことをお勧めします。ただし、データが密結合されている場合、データ間連携パターンの実装は困難になります。このような場合は、アプリケーションからデータへの連携の方が適している場合があります。

アプリケーションからデータへの連携パターンには 2 つのバリエーションがあります。

一元管理するデータに対してアプリケーションから連携するパターン
二重書き込みによりアプリケーションからデータに連携するパターン

データ一元管理パターン

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

AWS 上のアプリケーション、メインフレーム上のデータベース — このタイプの連携では、クラウド上のアプリケーションがメインフレームデータベースに直接接続します。Java Connector Architecture (JCA) コネクタとの point-to-point 連携には、クラウド上の Java アプリケーションがメインフレーム上のデータベースに直接接続することで、標準化されたインターフェイス、パフォーマンス、移植性、スケーラビリティ、トランザクション性とセキュリティのサポートなどのメリットがあります。JCA や JDBC で連携すると、システム間が密結合になるため、柔軟性が低下し、保守が難しくなります。JCA Connector または JDBC を使用した point-to-point 連携は、本質的に単方向です。つまり、クラウド上のアプリケーションからメインフレームデータベースに向かう方向にのみ連携します。
メインフレーム上のアプリケーション、AWS 上のデータベース、またはその逆 — メインフレーム上のアプリケーションを AWS 上のデータベースに直接連携したり、その逆を行ったりするさまざまなチャネルがあります。メインフレーム上のアプリケーションは Db2 フェデレーテッドサーバーを使用して AWS のデータベースにアクセスでき、その逆も可能です。これにより、あいまいさが減り、データのコピーを 1 つ保存するだけで済むため、運用の複雑さが軽減されます。

フェデレーションは、データベースを機能ごとに分割するスケーリング手法です。メインフレームデータのフェデレーションにより、異種データに対しても統一された方法でリアルタイムでアクセスできるようになります。これにより、設定のオーバーヘッドを最小限に抑えながら、AWS 上の分散アプリケーションやデータベースを利用したり、その逆を行ったりできます。フェデレーションサーバーでは、異なるデータストアのデータを結合するという点で、ある程度複雑になり、クエリのパフォーマンスとアプリケーションのスケーラビリティに影響する可能性があります。

仮想化は、形式や保存場所に関する技術的な詳細を知らなくても、アプリケーションがデータにアクセスして変更できるようにするデータ管理手法の 1 つです。IBM Data Virtualization Manager for z/OS (IBMz DVM) は、データをコピーまたは移動することなく、複数のソースからのデータを単一形式で表示できます。このため、AWS 上の分散アプリケーションやデータベースは、メインフレーム上のさまざまなデータストア (IMS、IDMS、または Db2) やファイルシステム (順次ファイル、VSAM、VSAM CICS、ADABAS、または MQ) にアクセスできます。仮想化によってデータ実装がアプリケーション開発者から見えなくなり、メインフレーム資産が API として AWS アプリケーションやデータベース上の分散チャネルに安全に公開されます。また、データ仮想化は、データフェデレーションとは対照的に、データベース結合と基本的なデータ処理を使用する単純なデータ処理に限定されます。

二重書き込みパターン

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

AWS 上のアプリケーションと AWS とメインフレーム上のデータベース — このタイプの連携では、AWS とメインフレームの両方にデータの同期コピーが保持されます。AWS 上のアプリケーションは、AWS データベースとメインフレームデータベースに同時に直接接続されます。この連携は JCA (Java Connector Architecture) コネクタを使用して実現されます。このコネクタでは、AWS 上の Java EE アプリケーション、AWS 上のデータベース、およびメインフレームデータベースを JDBC 経由で直接接続します。二重書き込みを選択すると、アーキテクチャにデータの耐障害性が向上しますが、アプリケーションのパフォーマンス上の問題が発生する可能性があります。この連携パターンの特徴と特性は、AWS 上のアプリケーションとメインフレーム上のデータベースのデータパターンのシングルコピーと似ています。
メインフレーム上のアプリケーションと、メインフレームと AWS 上のデータベース — メインフレーム上のアプリケーションをメインフレームデータベースや AWS 上のデータベースに直接統合するさまざまなチャネルは、データの同期コピーを AWS だけでなくメインフレームにも保存するという唯一の違いを除いて、データ一元管理パターンと似ています。

結論

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

移行を始める際には、AWS のメインフレームモダナイゼーションのスペシャリスト (mainframe@amazon.com) に連絡することをお勧めします。

Amazon Web Services ブログ