編集

次の方法で共有

Adabas & Natural を実行するメインフレーム コンピューター システムをリファクターする

Azure Kubernetes Service (AKS)
Azure ExpressRoute
Azure Managed Disks
Azure NetApp Files

Software AG は、Natural プログラミング言語と Adabas データベースをベースにした、一般的な 4GL メインフレーム プラットフォームを提供しています。 この記事では、Adabas & Natural を実行するメインフレーム コンピューターを使用していて、これらのワークロードを最新化してクラウドに移行する方法を探している組織向けのアーキテクチャを提供します。

メインフレームのアーキテクチャ

この図は、Azure に移行する前の、Software AG の Adabas & Natural モジュールがインストールされたメインフレームの例を示しています。 この例は、IBM z/OS アーキテクチャを示しています。

Azure に移行する前に、Software AG の Adabas & Natural を使用するメインフレーム アーキテクチャを示す図。

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

A. 入力は、TN3270 や HTTP(S) を含む TCP/IP を介して行われます。 メインフレームへの入力では、標準のメインフレーム プロトコルが使用されます。

B. 受信アプリケーションは、バッチまたはオンライン システムのいずれかになります。

C. Natural、COBOL、PL/I、アセンブラー、またはその他の互換性のある言語が、有効な環境で実行されます。

D. 一般的に使用されるデータおよびデータベース サービスは、階層型またはネットワーク データベース システムおよびリレーショナル データベースの種類です。

E. 一般的なサービスには、プログラムの実行、I/O 操作、エラー検出、環境内の保護が含まれます。

F. ミドルウェアとユーティリティによって、環境内のテープ ストレージ、キュー、出力、Web サービスなどのサービスが管理されます。

G. オペレーティング システムは、エンジンとそれが実行するソフトウェアとの間のインターフェイスを提供します。

H. パーティションは、個別のワークロードを実行し、環境内で作業の種類を分離するために必要です。

Azure アーキテクチャ

次の図は、リファクタリング方法を使用してシステムを最新化して、従来のアーキテクチャを Azure に移行する方法を示しています。

Azure への移行後の従来のアーキテクチャを示す図。

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

  1. 入力。 入力は通常、リモート クライアントから Azure ExpressRoute を介して、または現在 Azure を実行している他のアプリケーションを介して行われます。 いずれの場合も、TCP/IP 接続がシステムへの主要な接続手段です。 TLS ポート 443 によって、Web ベースのアプリケーションへのアクセスが提供されます。 ユーザーの再トレーニングを最小限に抑えるために、Web ベースのアプリケーションのプレゼンテーション層は、ほぼそのままにしておくことができます。 または、要件に応じて、このレイヤーを最新の UX フレームワークで更新することもできます。 VM への管理者アクセスに対して Azure Bastion ホストを使用すると、開いているポートを最小限に抑えてセキュリティを最大限に高めることができます。

  2. Azure でアクセスします。 Azure では、アプリケーションのコンピューティング クラスターへのアクセスは Azure ロード バランサーを介して提供されます。 この方法では、スケールアウト コンピューティング リソースを使用して入力の作業を処理できます。 レベル 7 (アプリケーション レベル) またはレベル 4 (ネットワーク プロトコル レベル) のロード バランサーを使用できます。 ただし、使用するロード バランサーの種類は、アプリケーション入力がコンピューティング クラスターのエントリ ポイントにどのように到達するかによって異なります。 レイヤー 7 のトラフィックには、Web アプリケーション ファイアウォール機能を備えた Azure Application Gateway を使用することをお勧めします。

  3. アプリケーション コンピューティング クラスター。 このアーキテクチャは、Azure Kubernetes Service (AKS) にデプロイできるコンテナーで実行されるアプリケーションをサポートします。 Adabas & Natural コンポーネントは、Linux ベースのコンテナー内で実行できます。 従来のアプリケーションを最新のコンテナー ベースのアーキテクチャに再設計し、AKS 上で動作させることができます。

  4. ApplinX ターミナル エミュレーション (Software AG)。 ApplinXは、コア システム アプリケーションに変更を加えることなく、これらのアプリケーションへの Web 接続と統合を提供するサーバーベースのテクノロジです。 Natural Online は、オンライン ユーザーが Web ブラウザーを介して Natural アプリケーションに接続できるようにします。 ApplinX がない場合、ユーザーは SSH を使用してターミナル エミュレーション ソフトウェアに接続する必要があります。 どちらのシステムもコンテナーで実行されます。

  5. EntireX (Software AG)。 EntireX を使用すると、Integration Server で実行されているサービスを、COBOL や Natural などの言語で記述されたミッションクリティカルなプログラムに簡単に接続できます。 Natural Business Services は、Natural でプログラムされたビジネス機能への API アクセスを可能にします。 どちらのシステムもコンテナーで実行されます。

  6. Adabas (Software AG)。 Adabas は、ハイ パフォーマンス NoSQL データベース管理システムです。 Natural バッチ (Software AG) は、バッチ ジョブを実行するための専用コンポーネントです。 Natural バッチ ジョブ (選択したバッチ ジョブ スケジュール システムによってスケジュールされます) は、パフォーマンスへの影響を避けるために、Adabas データベースと同じノードで実行する必要があります。

  7. ストレージ。 Data Service では、ハイ パフォーマンス ストレージ (Ultra または Premium SSD)、ファイル ストレージ (NetApp)、標準ストレージ (BLOB、アーカイブ、バックアップ) の組み合わせが使用されます。これらは、用途に応じて、ローカル冗長または geo 冗長のいずれかになります。 ノード オペレーティング システムでは、マネージド ディスク ストレージが使用されます。 すべての永続データ (データベース ファイル、保護ログ、アプリケーション データ、バックアップなど) では、Azure NetApp Files が使用されます。 AKS によって、マネージド ディスクに保存されているオペレーティング システム ボリュームが管理されます。 データベースからのすべてのビジネスクリティカルなデータ (ASSO、DATA、WORK の各ファイル、Adabas 保護ログなど) は、Azure NetApp Files の個別ボリュームに書き込む必要があります。

  8. CONNX。 CONNX for Adabas モジュールを使用すると、.NET、ODBC、OLE DB、JDBC を介して、OS/390、z/OS、VSE、Linux、Solaris、HP-UX、AIX、Windows 上の Adabas データ ソースへの安全性の高いリアルタイムの読み取り/書き込みアクセスが提供されます。 CONNX は、Adabas や他のデータ ソース (Azure SQL Database、Azure Database for PosgreSQL、Azure Database for MySQL など) へのコネクタを使用するデータ仮想化レイヤーを提供します。

コンポーネント

  • Azure ExpressRoute により、接続プロバイダーが提供するプライベート接続を介して、オンプレミス ネットワークが Microsoft クラウドへと拡張されます。 ExpressRoute を使用して、Azure や Office 365 などの Microsoft クラウド サービスへの接続を確立できます。 または、バックアップとして、Azure VPN Gateway との接続を確立することもできます。 ただし、セキュリティが強化された高速プライベート接続を介して Azure 環境に接続できるように、ExpressRoute を使用することをお勧めします。

  • AKS は、コンテナー化されたアプリケーションをデプロイおよび管理するためのフル マネージド Kubernetes サービスです。 AKS からは、サーバーレスの Kubernetes、統合された継続的インテグレーションと継続的デリバリー (CI/CD)、エンタープライズ レベルのセキュリティとガバナンスが提供されます。 このシナリオでは、Adabas & Natural コンテナーが AKS にデプロイされます。

  • Azure マネージド ディスクは、Azure によって管理されて Azure Virtual Machines で使用されるブロックレベルの記憶域ボリュームです。 Ultra Disks、Premium SSD、Standard SSD、Standard HDD など、さまざまな種類が使用できます。 このアーキテクチャでは、SSD ディスクが使用されています。 このシナリオでは、すべてのオペレーティング システム ボリュームが Azure マネージド ディスクに格納されます。

  • Azure NetApp Files は、NetApp を利用したエンタープライズレベルの Azure ファイル共有を提供します。 Azure NetApp Files を使用すると、コードを変更することなく、複雑なファイルベースのアプリケーションを容易に移行して実行できます。 このシナリオでは、すべての永続データ (データベース ファイル、保護ログ、アプリケーション データ、バックアップ ファイルなど) に Azure NetApp Files が使用されます。

シナリオの詳細

メインフレーム コンピューターで実行されているアプリケーションは、ほぼ 50 年間、ほとんどのビジネス オペレーションの中核となっています。 これらのメインフレーム システムは、長年にわたって非常に高い信頼性を提供してきましたが、十何世に欠け、場合によっては保守が困難で、運用コストがかかるため、少々問題になっています。

多くの組織が、これらのシステムを最新化する方法を探しています。 これらのシステムを維持し、コストを管理し、システムとの相互作用の柔軟性を高めるために必要な、制約のあるリソースを解放する方法を探しています。

Software AG は、Natural プログラミング言語と Adabas データベースをベースにした、一般的な 4GL メインフレーム プラットフォームを提供しています。

2 つのクラウド合理化パターン (リホストとリファクタリング) を使用すると、Azure で Adabas & Natural アプリケーションを実行できます。 この記事では、Azure Kubernetes Service (AKS) で管理されているコンテナーを使用してアプリケーションをリファクターする方法について説明します。 詳細については、この記事で後述する「コンテナーベースのアプローチ」をご覧ください。

考えられるユース ケース

このアーキテクチャの適用対象は、Adabas & Natural を実行するメインフレーム コンピューターを使用していて、これらのワークロードを最新化してクラウドに移行することを計画しているすべての組織です。

考慮事項

コンテナーベースのアプローチ

Azure の柔軟性、信頼性、および機能を最大限に活用するには、メインフレーム アプリケーションを再設計する必要があります。 モノリシック アプリケーションをマイクロサービスとして書き直し、コンテナーベースのアプローチを使用してデプロイすることをお勧めします。 コンテナーによって、実行に必要なすべてのソフトウェアが 1 つの実行可能パッケージにバンドルされます。 これには、アプリケーションのコードと、アプリの実行に必要な関連構成ファイル、ライブラリ、依存関係が含まれています。 コンテナ化されたアプリケーションは、迅速にデプロイされ、継続的インテグレーション (CI) や継続的配置 (CD) などの一般的な DevOps プラクティスをサポートします。

Adabas & Natural コンテナーはポッドで実行され、それぞれが特定のタスクを実行します。 ポッドは、同じノード上にまとめられ、ホスト名や IP アドレスなどのリソースを共有する 1 つ以上のコンテナーの単位です。 ポッド内のコンポーネントは、基になるプラットフォームから切り離されているため、独立してスケーリングされ、高可用性をサポートします。 コンテナ化されたアプリケーションも移植可能で、任意のインフラストラクチャで均一かつ一貫して実行されます。

コンテナ化されたサービスとそれに関連付けられているネットワークおよびストレージ コンポーネントは、調整および管理する必要があります。 AKS (クラスターとリソースの管理を自動化するマネージド Kubernetes サービス) をお勧めします。 必要なノードの数を指定すると、AKS がコンテナーを適切なノードに適合させて、リソースを最大限に活用します。 AKS では、自動ロールアウトとロールバック、サービス検出、負荷分散、ストレージ オーケストレーションもサポートされています。 また、AKS では自己修復がサポートされており、コンテナーに障害が発生すると、AKS によって新しいコンテナーが開始されます。 さらに、コンテナーの外部にシークレットと構成設定を安全に格納できます。

この記事のアーキテクチャ図は、Adabas & Natural のコンテナーベースの実装を示しています。 AKS を設定するときに、お使いのノードの Azure VM サイズを指定します。これにより、ストレージの CPU、メモリ、種類 (ハイパフォーマンスのソリッドステート ドライブ (SSD) や通常のハード ディスク ドライブ (HDD) など) が定義されます。 ユーザー インターフェイス (Natural Online と ApplinX) および API レイヤー (Natural Services と EntireX) のスケーラビリティと可用性を高めるには、Natural を 3 つ以上の VM インスタンス (ノード) で実行する必要があります。

データ レイヤーでは、Adabas は AKS クラスターで実行され、リソースの使用に基づいて自動的にスケールインおよびスケールアウトされます。 同じポッドで Adabas の複数のコンポーネントを実行できます。または、より大きいスケールに対しては、AKS によってそれらをクラスター内の複数のノードに分散できます。 Adabas では、すべての永続データ (データベース ファイル、保護ログ、アプリ データ、バックアップなど) に対して Azure NetApp Files (ハイパフォーマンスの従量制課金ファイル ストレージ サービス) が使用されます。

Natural バッチ ポッドは、Adabas ポッドと同じ可用性ゾーン (データセンター) に配置します。 近接配置グループを使用して、Adabas & Natural のバッチ ポッドを同じ可用性ゾーン内の同じノード プールに配置する必要があります。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。

このアーキテクチャは主に Kubernetes 上に構築されています。これには、ポッドのセキュリティ標準やシークレットのようなセキュリティ コンポーネントが含まれます。 Azure には、Microsoft Entra ID、Microsoft Defender for Containers、Azure Policy、Azure Key Vault、ネットワーク セキュリティ グループ、調整されたクラスター アップグレードなどの追加の機能が用意されています。 リファクタリングされたコンテナーは、プライベート API サーバーと内部 IP アドレスを介した受信アクセスが可能なプライベート AKS クラスターにデプロイする必要があります。 すべての送信トラフィックは、エグレス ファイアウォール レイヤーを介してルーティングする必要があります。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させることです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。

リファクタリングでは、より迅速なクラウド導入がサポートされています。 また、DevOps およびアジャイルの作業原則の導入も促進されます。 お客様は開発および運用デプロイのオプションを自在に選択できます。

パフォーマンス効率

パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。

Kubernetes には、クラスター オートスケーラーが用意されています。 このオートスケーラーを使用すると、ノード プール内の要求されたコンピューティング リソースに基づいてノードの数が調整されます。 これにより、ノード数に必要な変更がないか、Metrics API サーバーが 10 秒ごとに監視されます。 クラスター オートスケーラーで変更が必要だと判断されると、それに応じて AKS クラスター内のノードの数が増減されます。 

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

  • マーロン ジョンソン |シニア TPM

共同作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

詳細については、legacy2azure@microsoft.com にお問い合わせください。

次にその他のリソースを示します。