Azure Logic Apps を使ったメインフレームとミッドレンジのモダン化
このガイドでは、Azure Logic Apps を使用してメインフレームおよびミッドレンジ環境を最新化することで、組織がビジネス価値と機敏性を高める方法について説明します。 現在のビジネスの世界はハイパーイノベーションの時代を迎えており、企業の効率性、コスト削減、成長、ビジネスの連携を獲得することを常に求めています。 組織は最新化する方法を模索しており、効果的な戦略の 1 つは既存のレガシ資産を使用しながらビジネス価値を高めることです。
メインフレームおよびミッドレンジ システムに投資している組織にとって、これは、人類を月に送り込み、現在の金融市場の構築に貢献したプラットフォームを最大限に活用し、クラウドと人工知能 (AI) を使ってその価値を拡張することを意味します。 このシナリオでは、レガシ投資のために AI の世界への扉を開くことで、Azure Logic Apps と、メインフレームおよびミッドレンジ システムと統合するためのそのネイティブ機能が活躍します。 他の機能の中でも、Azure Logic Apps には、Microsoft の最も戦略的な顧客の中核で 20 年以上にわたってメインフレームとミッドレンジの統合に使用されてきた Host Integration Server (HIS) のコア機能が組み込まれています。 その結果、Azure Logic Apps はメインフレームおよびミッドレンジ システム向けのサービスとしての統合プラットフォーム (iPaaS) になりました。
エンタープライズ開発者が Azure Logic Apps を使って統合ワークフローを構築すると、コードをほとんどまたはまったく使わないか、少ないカスタム コードで、新しいアプリケーションをより迅速に提供できます。 Visual Studio Code と Visual Studio を使う開発者は、メインフレーム システムやインフラストラクチャに関する知識が不要なので、IBM メインフレーム開発ツールとテクノロジを使う開発者よりも生産性が高くなります。 ビジネス アナリストや意思決定者が Azure Logic Apps を使うと、重要なレガシ情報をより迅速に分析し、報告できるようになります。 メインフレーム データ ソース内のデータに直接アクセスできるので、メインフレーム開発者が複雑なメインフレーム構造を抽出して変換するプログラムを作成する必要がなくなります。
メインフレームおよびミッドレンジ システムを統合するためのクラウド ネイティブ機能
1990 年以来、Microsoft は Microsoft Communications Server を通じてメインフレームおよびミッドレンジ システムとの統合を提供してきました。 Microsoft Communications Server のさらなる進化により、2000 年に Host Integration Server (HIS) が誕生しました。 HIS はシステム ネットワーク アーキテクチャ (SNA) ゲートウェイとして始まりましたが、HIS は IBM データ ストア (DB2、VSAM、Informix)、IBM トランザクション システム (CICS、IMS、IBM i)、IBM メッセージング (MQ シリーズ) を含むように拡張されました。 Microsoft の戦略的なお客様は、20 年以上にわたってこれらのテクノロジを使ってきました。
Azure でアプリケーションとデータを実行するお客様がこれらのテクノロジを引き続き使用できるように、Azure Logic Apps と Visual Studio にはこれらの機能が段階的に組み込まれています。 たとえば、Visual Studio で実行する HIS Designer for Logic Apps や 3270 Design Tool は、Azure Logic Apps でメインフレームとミッドレンジの統合に使用する内臓コネクタに必要なメタデータ アーティファクトの作成をサポートします。 これらの内臓コネクタは、Standard ロジック アプリ ワークフローと同じコンピューティング リソースを使用して実行されます。 この設計により、低遅延シナリオを実現できるだけでなく、ディザスター リカバリーや高可用性の顧客ニーズに対応できる範囲が広がります。
メインフレームとミッドレンジの統合に関する Microsoft の機能の詳細については、次のセクションに進んでください。
Microsoft HIS Designer for Logic Apps
このツールを使うと、Azure Logic Apps 用にメインフレームおよびミッドレンジ システムのメタデータ成果物を作成できます。また、Microsoft Visual Studio と連携し、グラフィカル デザイナーが用意されているので、メタデータ オブジェクトを作成、表示、編集し、メインフレーム成果物にマップすることができます。 Azure Logic Apps は、これらのマップを使って、メインフレームおよびミッドレンジ システムのプログラムとデータをミラー化します。 詳細については、HIS Designer for Logic Apps に関する記事を参照してください。
Microsoft 3270 Design Tool
このツールを使うと、アプリケーション内のタスクの画面、ナビゲーション パス、メソッド、パラメーターを記録できるので、このようなタスクを 3270 コネクタ アクションとして追加して実行できます。 HIS Designer for Logic Apps はトランザクション システムとデータをターゲットとしていますが、3270 Design Tool は 3270 アプリケーションをターゲットとしています。 詳細については、3270 Design Tool に関する記事を参照してください。
IBM メインフレームおよびミッドレンジ システム用の Azure Logic Apps コネクタ
以下のセクションでは、サービス プロバイダーベースの組み込みコネクタについて説明します。これを使うと、Azure Logic Apps で Standard ワークフローを作成するときに、IBM メインフレームおよびミッドレンジ システムにアクセスして操作することができます。
Note
次のコネクタの一部は、グローバル Azure で実行される "共有" コネクタとして使用できますが、このガイドでは、Azure Logic Apps で Standard ワークフローを作成する場合にのみ使用できる、組み込みのサービス プロバイダーベースのコネクタを中心に説明します。
IBM 3270
この 3270 用の Azure Logic Apps コネクタを使うと、Standard ワークフローで、通常は 3270 エミュレーター画面を操作して実行する IBM メインフレーム アプリケーションにアクセスして実行できます。 コネクタは TN3270 ストリームを使います。 詳細については、「Azure Logic Apps と IBM 3270 コネクタを使用して IBM メインフレーム上の 3270 画面駆動型アプリを Azure と統合する」を参照してください。
IBM Customer Information Control System (CICS)
この CICS 用 Azure Logic Apps コネクタには、Standard ワークフローが CICS プログラムと対話して統合できるように、複数のプロトコル (TCP/IP、HTTP など) が用意されています。 LU6.2 を使用して CICS 環境にアクセスする必要がある場合は、Host Integration Server (HIS) を使用する必要があります。 詳細については、IBM CICS コネクタを使って IBM メインフレーム上の CICS プログラムを Azure Logic Apps の Standard ワークフローと統合する方法に関する記事を参照してください。
IBM DB2
この DB2 用 Azure Logic Apps コネクタを使うと、Standard ワークフローと、オンプレミスまたは Azure にある DB2 データベース間の接続が可能になります。 このコネクタを使うと、企業の IT プロフェッショナルや開発者は、DB2 データベース管理システムに保存されている重要な情報に直接アクセスできます。 詳細については、Azure Logic Apps を使った IBM DB2 リソースへのアクセスと管理に関する記事を参照してください。
IBM ホスト ファイル
このホスト ファイル用 Azure Logic Apps "コネクタ" は、Host Integration Server の "フラット ファイル パーサー" 機能のシン ラッパーを提供します。 このオフライン "コネクタ" は、ホスト ファイルとの間でバイナリ データを解析または生成する操作を提供します。 これらの操作を行うには、バイナリ データを生成する何らかのトリガーまたは別のアクションでこのデータを取得する必要があります。 詳細については、Azure Logic Apps を使った IBM ホスト ファイルの解析と生成に関する記事を参照してください。
IBM i
この IBM i 用 Azure Logic Apps コネクタを使用すると、Standard ワークフローでは TCP/IP を使って IBM i システム上で実行されている COBOL および RPG プログラムと対話して統合できます。 LU6.2 を使って IBM i 環境にアクセスする必要がある場合は、Host Integration Server (HIS) を使用する必要があります。 詳細については、IBM i コネクタを使って IBM ミッドレンジ上の COBOL および RPG プログラムを Azure Logic Apps の Standard ワークフローと統合する方法に関する記事を参照してください。
IBM Information Management System (IMS)
この IMS 用 Azure Logic Apps コネクタは IBM IMS Connect コンポーネントを使います。これは、TCP/IP を使って Standard ワークフローから IMS トランザクションへのハイ パフォーマンス アクセスを提供します。 このモデルでは、データの処理に IMS メッセージ キューを使います。 詳細については、IBM IMS コネクタを使って IBM メインフレーム上の IMS プログラムを Azure Logic Apps の Standard ワークフローと統合する方法に関する記事を参照してください。
IBM MQ
この MQ 用 Azure Logic Apps コネクタを使うと、Standard ワークフローと、オンプレミスまたは Azure の IBM MQ サーバー間の接続が可能になります。 また、Microsoft では、Host Integration Server と BizTalk Server との IBM MQ 統合機能もあります。 詳細については、「Azure Logic Apps で IBM MQ サーバーからワークフローに接続する」を参照してください。
メインフレームおよびミッドレンジ システムの最新化に関する課題
メインフレームおよびミッドレンジ システムでは、プログラム、データ、ファイル、およびツールを含む複数の環境をホストできます。 長年にわたり、ハードウェアのアップグレードにもかかわらず、これらの環境はリファクタリングされていないか、放置されたまま成長し、限界に達している可能性があります。 これらの環境は、さまざまなプログラミング パターンや手法に従う複数の開発者や IT 管理者によって維持されていたり、市場で不足している専門知識を必要とするタスクに役立つ他の関係者を募集したりする場合もあります。 経験豊富な専門家のプールの縮小に加えて、これらすべての要因は、メインフレームおよびミッドレンジ環境を最新化する複雑で困難な仕事を生み出します。
次の一覧は包括的なものではありませんが、成功した最新化戦略の定義には、次のタスクを処理する方法が最小限に含まれています。
- お客さまの環境に関する現在のサービス レベル インジケーターと目標を保守する。
- レガシ データと移行されたデータの共存を管理する。
- 共存中に環境間で DevOps を実行する。
- アプリケーションの相互依存関係を管理する。
- メインフレーム スケジューラとジョブの将来を定義する。
- 商用市販の成果物 (COTS) 製品を置き換えるための戦略を定義します。
- 機能と非機能のハイブリッド テスト アクティビティを実施する。
- 外部の依存関係またはインターフェイスを保守する。
これらのタスクを念頭に置いて、お客様は通常、メインフレームおよびミッドレンジ システムの最新化を行うために、次のいずれかのパスを選びます。
ビッグバン
このアプローチは主にウォーターフォール ソフトウェア デリバリー モデルに基づいていますが、イテレーションは段階的に行います。 ビッグ バン アプローチは、コード行数が少なく、アプリケーション密度が低く、よく知られているレガシ システムまたはプログラミング言語があるため、メインフレームまたはミッドレンジ システムが小さく複雑さが少ない環境を持つお客様により採用されています。
アジャイル ウェーブ
このアプローチは、ソフトウェア エンジニアリングのアジャイル原則に従っています。 アジャイル ウェーブ アプローチは、コード行数が多く、アプリケーション密度が高く、あまり知られていないシステムまたはプログラミング言語、および多数の依存関係とインターフェイスがあるため、メインフレームまたはミッドレンジ システムが大きく複雑さが多い環境を持つお客様により採用されています。
これらのパスのどちらを選ぶかは、組織のニーズとシナリオによって決まります。 各パスには、考慮すべき利点と欠点があります。 以下のセクションでは、これらのモダン化アプローチについて詳しく説明します。
ビッグ バンまたはウォーターフォール
通常、ビッグ バン移行には次のフェーズがあります。
構想: キックオフ
計画: スコープ、時間、リソースなどの計画成果物を特定して準備します。
構築: 計画の成果物が承認された後に始まります
また、このフェーズでは、依存関係に対するすべての作業を特定することが想定され、場合によっては移行アクティビティを始めます。 移行作業を完了するために、複数のイテレーションが行われます。
安定化またはテスト: 移行された環境、依存関係、アプリケーションをメインフレーム環境のテスト領域に対してテストするときに始まります。
デプロイ: すべてが承認されると、運用環境への移行が始まります。
通常、このアプローチを選ぶ組織は、ロック時間、移行スコープ、リソースに重点を置いています。 この過程は前向きな選択のように思えますが、次のようなリスクがあります。
移行には数か月、場合によっては数年かかることがあります。
運用環境へのデプロイはより危険です。
移行作業の開始時や計画時に実行した分析は、通常は情報が古くなっているため、正確ではなくなります。
通常、組織はデリバリーに伴うデリバリー リスクを軽減するために包括的なドキュメントを作成することに重点を置きます。
ただし、計画成果物の用意に費やされる時間は、正反対の効果を引き起こします。 実行よりも計画に重点を置くと、実行に遅れが生じる傾向があり、長期的にはコストが増加します。
アジャイル ウェーブ
アジャイル アプローチは結果指向であり、成果物の計画ではなくソフトウェアの構築に重点を置いています。 アジャイル デリバリーの初期段階は、組織の障壁を打ち破り、移行チームを調整する必要があるため、混沌として複雑になる場合があります。 ただし、数回のスプリント実行後に移行チームが成熟すると、移行はよりスムーズになります。 このアプローチのゴールは、機能を運用環境に頻繁にリリースし、ビッグ バン アプローチよりも早くビジネス価値をもたらすことです。
通常、アジャイル ウェーブ型の移行には次のスプリントがあります。
スプリント ゼロ (0)
- チーム、初期作業バックログ、コアの依存関係を定義します。
- 提供する機能と実用最小限の製品 (MVP) を特定します。
- 厳選したセットの作業項目またはユーザー ストーリーでメインフレームの準備を開始し、作業を開始します。
スプリント 1、2、...、N
各スプリントにはゴールがあり、チームは出荷の考え方をそこに設定します。つまり、移行ゴールを達成し、成果物を運用環境にリリースすることに集中します。 チームはスプリントのグループを使って、特定の機能または機能のウェーブを提供できます。 各機能には、統合ワークロードのスライスが含まれています。
ジョブや相互依存関係などの共有要素があり、環境全体に影響を及ぼします。 成功する戦略では、ジョブを部分的に有効にし、モダン化のためにアプリケーションを再設計し、相互依存関係が多いシステムを最後まで残して、最初に移行作業の量を減らし、次にモダン化作業のスコープを完了することに重点を置きます。
Microsoft では、レガシ システムの成長を制限しながら、新しいプラットフォームへの投資に焦点を当てることで、反復的なアジャイル ウェーブ ベースのモデルに従って、メインフレームおよびミッドレンジ システム ワークロードを最新化することをお勧めします。 このアプローチでは、最新化された環境を導入しながら、既存のビジネス価値を維持することで実装リスクを大幅に軽減します。 そうすることで、チームは、ビジネスの競争力を高めるのに役立つテクノロジ スキルを活用することもできます。 このシナリオでは、Azure Logic Apps が最新化の過程で役立ちます。
モダン化のパターン
優れた設計には、コンポーネントの設計とデプロイの一貫性と整合性、管理と開発を簡素化する保守容易性、他のアプリケーションやシナリオでコンポーネントとサブシステムを再利用できる再利用性などの要素が含まれています。 クラウドホステッド型のアプリケーションとサービスの場合、設計と実装のフェーズで行われる決定は、品質と総所有コストに大きな影響があります。
Azure アーキテクチャ センターには、テスト済みの設計および実装パターンが用意されており、対処する問題、パターンを適用する際の考慮事項、Microsoft Azure に基づく例が説明されています。 複数の設計および実装パターンがありますが、メインフレームのモダン化に最も関連する複数のパターンとして "破損対策レイヤー" パターン、"ストラングラー フィグ" パターン、"Saga" パターン、"コレオグラフィ" パターンがあります。
破損対策レイヤー パターン
どのモダン化アプローチを選ぶかに関係なく、Azure Logic Apps を使って "破損対策レイヤー" を実装する必要があります。 このサービスは、メインフレームのレガシ システムと Azure 間のファサードまたはアダプター レイヤーになります。 効果的なアプローチを実現するには、メインフレーム統合ワークロードとして統合または共存するメインフレーム ワークロードを特定します。 統合ワークロードごとに戦略を作成します。これは、メインフレーム アプリケーションを移行するために有効にする必要がある一連のインターフェイスです。
詳細については、「破損対策レイヤー」を参照してください。
ストラングラー フィグ パターン
破損対策レイヤーを実装すると、モダン化は段階的に行われます。 このフェーズでは、段階的にモダン化できるメインフレームのワークロードまたは機能を特定する "ストラングラー フィグ" パターンを使う必要があります。 たとえば、CICS アプリケーションのモダン化を選んだ場合、多くの場合、CICS プログラムだけでなく、3270 アプリケーションと、それらに対応する外部の依存関係、データ、ジョブもモダン化する必要があります。
最終的に、メインフレーム システムのすべてのワークロードまたは機能を新しいシステムに置き換えると、移行プロセスは完了です。つまり、レガシ システムを廃止できます。
詳細については、「ストラングラー フィグ パターン」を参照してください。
Saga パターンとコレオグラフィ パターン
2 フェーズコミット (2PC) プロトコルのような分散トランザクションには、トランザクションを続行する前に、トランザクション内のすべての参加要素についてコミットまたはロールバックが必要です。 クラウド ハイブリッド アーキテクチャは、分散トランザクション モデルではなく、最終的な整合性パラダイムに従った方がうまくいきます。
"Saga" 設計パターンは、分散トランザクション シナリオでサービス間の一貫性を管理する方法です。 saga はトランザクションのシーケンスです。この saga によって各サービスが更新され、次のトランザクション ステップをトリガーするメッセージまたはイベントが発行されます。 また、ステップが失敗すると、その前のトランザクションを無効にする補正トランザクションを実行されます。 詳細については、「Saga distributed transactions pattern (Saga 分散トランザクション パターン)」を参照してください。
Azure Logic Apps では、ワークフローは saga を調整するコレオグラファーとして機能します。 ワークフロー アクションはアトミックであるため、個別に再実行できます。 [スコープ] アクションの種類では、別のアクションのグループが成功または失敗した後にのみ、アクションのグループを実行する機能が提供されます。 Azure Logic Apps はスコープ レベルで補正トランザクションを実行し、Azure Event Grid と Azure Service Bus では特定のドメインに必要なイベント管理が提供されます。 Azure 統合サービスを構成するこれらのサービスはすべて、ミッション クリティカルなシナリオで信頼性の高い統合プラットフォームが必要な場合に、顧客に必要とされるサポートが提供されます。 詳細については、「コレオグラフィ パターン」を参照してください。
この記事ではいくつかのモダン化パターンを取り上げていますが、複雑なソリューションにはさらに多くのパターンが必要であり、組織のモダン化の目標を明確に理解する必要があります。 レガシ資産の価値を高めるタスクは困難ですが、このオプションは、このような資産への投資を維持し、ビジネス価値を長持ちさせるための最善の方法です。