Software AG は、Natural プログラミング言語と Adabas データベースをベースにした、一般的な 4GL メインフレーム プラットフォームを提供しています。 この記事では、Adabas & Natural を実行するメインフレーム コンピューターを使用していて、これらのワークロードを最新化してクラウドに移行する方法を探している組織向けのアーキテクチャを提供します。
メインフレームのアーキテクチャ
この図は、Azure に移行する前の、Software AG の Adabas & Natural モジュールがインストールされたメインフレームの例を示しています。 この例は、IBM z/OS アーキテクチャを示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
A. 入力は、TN3270 や HTTP(S) を含む TCP/IP を介して行われます。 メインフレームへの入力では、標準のメインフレーム プロトコルが使用されます。
B. 受信アプリケーションは、バッチまたはオンライン システムのいずれかになります。
C. Natural、COBOL、PL/I、アセンブラー、またはその他の互換性のある言語が、有効な環境で実行されます。
D. 一般的に使用されるデータおよびデータベース サービスは、階層型またはネットワーク データベース システムおよびリレーショナル データベースの種類です。
E. 一般的なサービスには、プログラムの実行、I/O 操作、エラー検出、環境内の保護が含まれます。
F. ミドルウェアとユーティリティによって、環境内のテープ ストレージ、キュー、出力、Web サービスなどのサービスが管理されます。
G. オペレーティング システムは、エンジンとそれが実行するソフトウェアとの間のインターフェイスを提供します。
H. パーティションは、個別のワークロードを実行し、環境内で作業の種類を分離するために必要です。
Azure アーキテクチャ
次の図は、リファクタリング方法を使用してシステムを最新化して、従来のアーキテクチャを Azure に移行する方法を示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
入力。 入力は通常、リモート クライアントから Azure ExpressRoute を介して、または現在 Azure を実行している他のアプリケーションを介して行われます。 いずれの場合も、TCP/IP 接続がシステムへの主要な接続手段です。 TLS ポート 443 によって、Web ベースのアプリケーションへのアクセスが提供されます。 ユーザーの再トレーニングを最小限に抑えるために、Web ベースのアプリケーションのプレゼンテーション層は、ほぼそのままにしておくことができます。 または、要件に応じて、このレイヤーを最新の UX フレームワークで更新することもできます。 VM への管理者アクセスに対して Azure Bastion ホストを使用すると、開いているポートを最小限に抑えてセキュリティを最大限に高めることができます。
Azure でアクセスします。 Azure では、アプリケーションのコンピューティング クラスターへのアクセスは Azure ロード バランサーを介して提供されます。 この方法では、スケールアウト コンピューティング リソースを使用して入力の作業を処理できます。 レベル 7 (アプリケーション レベル) とレベル 4 (ネットワーク プロトコル レベル) のロード バランサーの両方を使用できます。 使用する型は、アプリケーションの入力がコンピューティング クラスターのエントリ ポイントにどのように到達するかによって異なります。
アプリケーション コンピューティング クラスター。 このアーキテクチャでは、Kubernetes などのコンテナー オーケストレーターにデプロイできるコンテナーで実行されるアプリケーションがサポートされます。 Adabas & Natural コンポーネントは、Linux オペレーティング システム上で運用されているコンテナー テクノロジ内で実行できます。 従来のアプリケーションを最新のコンテナー ベースのアーキテクチャに再設計し、Azure Kubernetes Services 上で動作させることができます。
ApplinX ターミナル エミュレーション (Software AG)。 ApplinXは、コア システム アプリケーションに変更を加えることなく、これらのアプリケーションへの Web 接続と統合を提供するサーバーベースのテクノロジです。 Natural Online は、オンライン ユーザーが Web ブラウザーを介して Natural アプリケーションに接続できるようにします。 ApplinX がない場合、ユーザーは SSH を使用してターミナル エミュレーション ソフトウェアに接続する必要があります。 どちらのシステムもコンテナーで実行されます。
EntireX (Software AG)。 EntireX を使用すると、Integration Server で実行されているサービスを、COBOL や Natural などの言語で記述されたミッションクリティカルなプログラムに簡単に接続できます。 Natural Business Services は、Natural でプログラムされたビジネス機能への API アクセスを可能にします。 どちらのシステムもコンテナーで実行されます。
Adabas (Software AG)。 Adabas は、ハイ パフォーマンス NoSQL データベース管理システムです。 Natural バッチ (Software AG) は、バッチ ジョブを実行するための専用コンポーネントです。 Natural バッチ ジョブ (選択したバッチ ジョブ スケジュール システムによってスケジュールされます) は、パフォーマンスへの影響を避けるために、Adabas データベースと同じノードで実行する必要があります。
ストレージ。 Data Service では、ハイ パフォーマンス ストレージ (Ultra または Premium SSD)、ファイル ストレージ (NetApp)、標準ストレージ (BLOB、アーカイブ、バックアップ) の組み合わせが使用されます。これらは、用途に応じて、ローカル冗長または geo 冗長のいずれかになります。 ノード オペレーティング システムでは、マネージド ディスク ストレージが使用されます。 すべての永続データ (データベース ファイル、保護ログ、アプリケーション データ、バックアップなど) では、Azure NetApp Files が使用されます。 AKS によって、マネージド ディスクに保存されているオペレーティング システム ボリュームが管理されます。 データベースからのすべてのビジネスクリティカルなデータ (ASSO、DATA、WORK の各ファイル、Adabas 保護ログなど) は、Azure NetApp Files で提供できる個別のボリュームに書き込む必要があります。
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 Kubernetes Service は、コンテナー化されたアプリケーションをデプロイおよび管理するためのフル マネージド Kubernetes サービスです。 AKS からは、サーバーレスの Kubernetes、統合された継続的インテグレーションと継続的デリバリー (CI/CD)、エンタープライズ レベルのセキュリティとガバナンスが提供されます。
Azure マネージド ディスクは、Azure によって管理されて Azure Virtual Machines で使用されるブロックレベルの記憶域ボリュームです。 Ultra Disks、Premium SSD、Standard SSD、Standard HDD など、さまざまな種類が使用できます。 このアーキテクチャでは、SSD ディスクが使用されています。
Azure NetApp Files は、NetApp を利用したエンタープライズレベルの Azure ファイル共有を提供します。 Azure NetApp Files を使用すると、コードを変更することなく、複雑なファイルベースのアプリケーションを容易に移行して実行できます。
シナリオの詳細
メインフレーム コンピューターで実行されているアプリケーションは、ほぼ 50 年間、ほとんどのビジネス オペレーションの中核となっています。 これらのメインフレーム システムは、長年にわたって非常に高い信頼性を提供してきましたが、十何世に欠け、場合によっては保守が困難で、運用コストがかかるため、少々問題になっています。
多くの組織が、これらのシステムを最新化する方法を探しています。 これらのシステムを維持し、コストを管理し、システムとの相互作用の柔軟性を高めるために必要な、制約のあるリソースを解放する方法を探しています。
Software AG は、Natural プログラミング言語と Adabas データベースをベースにした、一般的な 4GL メインフレーム プラットフォームを提供しています。
Azure で Adabas & Natural アプリケーションを実行できるパターンには、リホストとリファクターの 2 つがあります。 この記事では、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 は 3 つの VM インスタンス (ノード) で実行され、ユーザー インターフェイス (Natural Online と ApplinX) と API レイヤー (Natural Services と EntireX) のスケーラビリティと可用性を向上させます。
データ レイヤーでは、Adabas は AKS クラスターで実行され、リソースの使用に基づいて自動的にスケールインおよびスケールアウトされます。 同じポッドで Adabas の複数のコンポーネントを実行できます。または、より大きいスケールに対しては、AKS によってそれらをクラスター内の複数のノードに分散できます。 Adabas では、すべての永続データ (データベース ファイル、保護ログ、アプリ データ、バックアップなど) に対して Azure NetApp Files (ハイパフォーマンスの従量制課金ファイル ストレージ サービス) が使用されます。
Operations
リファクタリングでは、より迅速なクラウド導入がサポートされています。 また、DevOps およびアジャイルの作業原則の導入も促進されます。 お客様は開発および運用デプロイのオプションを自在に選択できます。
パフォーマンス効率
Kubernetes には、クラスター オートスケーラーが用意されています。 このオートスケーラーを使用すると、ノード プール内の要求されたコンピューティング リソースに基づいてノードの数が調整されます。 これにより、ノード数に必要な変更がないか、Metrics API サーバーが 10 秒ごとに監視されます。 クラスター オートスケーラーで変更が必要だと判断されると、それに応じて AKS クラスター内のノードの数が増減されます。
セキュリティ
このアーキテクチャは主に Kubernetes 上に構築されています。これには、ポッドのセキュリティ標準やシークレットのようなセキュリティ コンポーネントが含まれます。 Azure には、Microsoft Entra ID、Microsoft Defender for Containers、Azure Policy、Azure Key Vault、ネットワーク セキュリティ グループ、調整されたクラスター アップグレードなどの追加の機能が用意されています。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- マーロン ジョンソン |シニア TPM
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
詳細については、legacy2azure@microsoft.com にお問い合わせください。
次にその他のリソースを示します。
- Adabas & Natural
- Azure Kubernetes Service
- Azure NetApp Files のドキュメント
- Azure 仮想マシンでのメインフレーム リホスト
- メインフレーム コンピューティングを Azure Virtual Machines に移行する