編集

次の方法で共有


Azure で一般的なメインフレームをリホストする

Azure Virtual Machines
Azure Virtual Network
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Site Recovery

リホストは、従来のメインフレーム アプリケーションをそのままオープン システムで実行する方法です。 このパスは、メインフレーム ハードウェアからアプリケーションを移動して、クラウドネイティブ環境の Windows または Linux プラットフォームで実行する最も早い方法です。 COBOL や PL/1 などのレガシ言語で記述されたアプリケーション コードが、そのまま移行されて新しい環境で再コンパイルされ、ビジネス ロジックは変更されません。 リホストは、アプリケーションのロジックを維持するために役立ちます。 同時に、リホストによって、新しい環境用にアプリケーションを再コーディングすることに伴うリスクとコストが最小限に抑えられます。

リホストは、古いメインフレーム ハードウェアを維持する場合の課題に対処するためのコスト効率の高い方法です。 リホストは、一般に "リフトアンドシフト" と呼ばれ、ミッション クリティカルなアプリケーションとコア アプリケーションをメインフレームからクラウドに移行します。 この方法では、基になるハードウェアが、たとえば IBM メインフレームから x86 に変更されます。 ただし、機能とビジネス ロジックはそのままです。 この移行は、エンドユーザーの観点では最も迅速で最も影響が少ない方法です。 アプリケーションでは、ユーザーが慣れている同じインターフェイスと外観が維持されます。

チームでクラウド機能を検討している場合、アプリケーションのリホストは、自動スケーリング、マネージド ストレージ、コンテナーなどのクラウド機能を使用する優れた方法です。 このアーキテクチャは、ワークロードをデプロイするための 2 つの方法が強調された一般的なリホストの例を示しています。 Azure Kubernetes Service (AKS) または Azure Virtual Machines を使用できます。 どの方法を使用するかは、アプリケーションの移植性と優先事項によって異なります。

考えられるユース ケース

Azure でリホストを使用すると、多くのシナリオでメリットが得られる場合があります。 考えられるユース ケースを次にいくつか示します。

  • コストの最適化: メインフレーム ハードウェアとそれに関連するライセンスまたはソフトウェアの高い運用コストとメンテナンス コストを大幅に削減したい場合。
  • 場所に依存しない: データセンターからの撤退を計画しており、レガシ アプリケーションをホストするためのセキュリティで保護された、高可用性で信頼性の高い代替のプラットフォームが必要な場合。
  • 最小限の中断: 日常業務の継続性を維持しつつ、ミッション クリティカルなメインフレーム アプリケーションを移行する必要がある場合。
  • ユーザーへの影響を最小限に抑える: 古いハードウェアからアプリケーションを移行するが、ユーザーには同じインターフェイスまたはより優れたインターフェイスを引き続き提供する場合。
  • スキルアップをほとんど必要としない: コードに重大な変更を加えずに、アプリケーションをクラウドでリホストする場合。 開発チームには使い慣れたコード ベースが引き続き提供され、同時に新しい言語でのコストのかかる開発、テスト、再習得が排除されます。

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

移行前のアーキテクチャを次に示します。

Azure に移行する前のメインフレーム アプリケーションを示す図。

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

メインフレームのデータフロー

  1. TCP/IP (TN3270、HTTP、HTTPS を含む) を介して入力が行われます。

  2. メインフレームへの入力では、標準のメインフレーム通信プロトコルが使用されます。

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

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

  5. 使用されるデータおよびデータベース サービスは、階層データベース、ネットワーク データベース、リレーショナル データベースです。

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

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

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

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

アーキテクチャ

次のアーキテクチャは、Microsoft Azure でリホストされるソリューションを示しています。

Azure に移行した後のメインフレーム アプリケーションを示す図。

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

データフロー

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

  2. アプリケーションのコンピューティング クラスターへのアクセスは、Azure Load Balancer を使用して行われます。 この方法では、コンピューティング リソースをスケールアウトして入力の作業を処理できます。 レベル 7 のアプリケーション レベルとレベル 4 のネットワーク プロトコル レベルのロードバランサーの両方を使用できます。 使用する型は、アプリケーションの入力がコンピューティング クラスターのエントリ ポイントにどのように到達するかによって異なります。

  3. アプリケーション コンピューティング クラスターの使用は、アプリケーションでコンピューティング クラスター内の仮想マシン (VM) がサポートされるか、Kubernetes などのコンテナー コンピューティング クラスターにデプロイしたコンテナーでアプリケーションが実行されるかによって異なります。 従来の言語で記述されたアプリケーション用のほとんどのメインフレーム パートナー ソフトウェアでは、VM を使用することが選択されます。 一部のメインフレーム システム パートナー ソフトウェアでは、コンテナーへのデプロイもサポートされることがあります。

  4. アプリケーション サーバーでは、コンピューティング クラスターの入力を受け取り、Azure Redis Cache またはリモート ダイレクト メモリ アクセス (RDMA) を使用してアプリケーションの状態とデータを共有します。 アプリケーション・サーバーでは、さまざまな COBOL または PL/1 アプリケーション・プログラムをホストします。 トランザクション システム マネージャーは、顧客情報制御システム (CICS) と情報管理システム (IMS) のワークロードを処理できる Azure 上のエミュレーターです。 Azure のバッチ システム エミュレーターは、ジョブ制御言語 (JCL) の役割を果たします。

  5. システム、ユーティリティ、データ管理には、VM でホストされる Azure サービスまたはその他のパートナー ソフトウェアを使用できます。

  6. メインフレームのデータが、Azure データベースに移行されます。 Azure では、Azure SQL Database、Azure Virtual Machines 上の SQL Server、Azure SQL Managed Instance など、さまざまな効率的なデータ ストレージ サービスが提供されます。 選択を行う際には、ワークロードの種類、複数データベースにまたがるクエリ、2 フェーズ コミットの要件など、考慮すべき多くの要因があります。 Azure データ サービスでは、クラスター内の複数のコンピューティング リソースで共有できるスケーラブルで可用性の高いデータ ストレージが提供されます。 これらのサービスを geo 冗長にして、フェールオーバーが発生した場合にディザスター リカバリーのデータベース インスタンスがアクティブになるように構成できます。

  7. AKS によって、Azure でのメインフレームの最新化ワークロードのスケールアウトとスケールダウンが可能になり、クラウド プラットフォームの利点を活用できます。 AKS クラスターを複数デプロイする場合は、AKS を使用できるリージョンを選択します。 その後、ペアのリージョンを使用して、回復性の高いアーキテクチャを実現できます。 AKS クラスターの複数のインスタンスを複数のリージョンと高可用性構成で実行することが重要です。

  8. Azure Data Factory では、Azure 内と外部ソースの両方でのデータ インジェストと複数のデータ ソースとの同期が提供されます。 Azure Blob Storage は、外部データ ソースの汎用ランディング ゾーンです。

  9. VM とコンテナー クラスター コンポーネントのディザスター リカバリーには、Azure Site Recovery を使用します。 Azure Site Recovery では、運用環境をレプリケートしてフェールオーバー リージョンに同期します。

コンポーネント

  • Virtual Machines: Virtual Machines は、オンデマンドのスケーラブルなコンピューティング リソースです。 Azure VM は、VM を実行する物理的なハードウェアを購入して維持する手間を省き、仮想化がもたらす柔軟性を提供します。

  • Azure Virtual Network: Virtual Network は、Azure 内のプライベート ネットワークの基本的な構成要素です。 Virtual Network では、Virtual Machines などのさまざまな種類の Azure リソースが、他の Azure リソース、インターネット、オンプレミスのネットワークと安全に通信することができます。 Virtual Network は、独自のデータ センターで運用する従来のネットワークに似ています。 ただし、スケール、可用性、分離性など、Azure のインフラストラクチャの利点が提供されます。

  • Azure Virtual Network のインターフェイス カード: ネットワーク インターフェイスによって、Azure VM がインターネット、Azure、オンプレミスのリソースと通信できるようになります。 このアーキテクチャに示されているように、同じ Azure VM にさらにネットワーク インターフェイス カードを追加できます。 このようにすると、Solaris の子 VM が独自の専用ネットワーク インターフェイス デバイスと IP アドレスを持つことになります。

  • Azure Disk Storage: マネージド ディスクは、Azure によって管理されて Azure VM で使用されるブロックレベルの記憶域ボリュームです。 使用可能なディスクの種類は、Azure Ultra Disk Storage、Azure Premium SSD、Azure Standard SSD、Azure Standard HDD です。 このアーキテクチャでは、Premium SSD または Ultra Disk Storage をお勧めします。

  • Azure Files: Azure Files では、業界標準のサーバー メッセージ ブロック (SMB) プロトコルを介してアクセスできるフル マネージド ファイル共有をクラウドで提供します。 Azure ファイル共有は、クラウドまたはオンプレミスにデプロイされた Windows、Linux、macOS で同時にマウントできます。

  • Azure ExpressRoute: ExpressRoute を利用すると、接続プロバイダーによって提供されるプライベート接続を介して、オンプレミスのネットワークを Microsoft クラウドに拡張できます。 Microsoft Azure や Microsoft 365 などの Microsoft クラウド サービスへの接続を確立することもできます。

  • AKS: フル マネージド Kubernetes サービスを使用して、コンテナー化されたアプリケーションをより簡単にデプロイおよび管理します。 Azure Kubernetes Service (AKS) では、サーバーレスの Kubernetes、統合された継続的インテグレーションと継続的デリバリー (CI/CD) エクスペリエンス、エンタープライズ グレードのセキュリティとガバナンスが提供されます。 開発チームと運用チームを単一のプラットフォーム上で統合し、迅速かつ確実にアプリケーションをビルド、デリバリー、スケーリングします。

  • Azure Container Registry: OCI ディストリビューションのフル マネージド Geo レプリケーション インスタンスを使用して、コンテナー イメージと成果物を構築、格納、保護、スキャン、レプリケート、管理します。 AKS や Azure Red Hat OpenShift などの環境を接続したり、App Service、Machine Learning、Batch などの Azure サービスを接続したりします。

  • Site Recovery: Site Recovery では、デプロイの容易さ、コスト効率、信頼性が提供されます。 計画的な停止や予期しない停止中にアプリケーションの実行を継続できるように、Site Recovery を介してレプリケーション、フェールオーバー、復旧のプロセスがデプロイされます。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性設計レビューチェックリスト」を参照してください。

  • Azure の機能を最大限に活用するには、デプロイにコンテナーベースのアプローチを使用します。 このアプローチは、インフラストラクチャを管理することなく、アプリケーションがオンデマンドでスケーリングし、容量の柔軟なプロビジョニングを実現する必要がある場合に役立ちます。 また、イベント ドリブンの自動スケーリングとトリガーを追加することもできます。 コンテナーによって、実行に必要なすべてのソフトウェアが 1 つの実行可能パッケージにバンドルされます。 これには、アプリケーションのコードと、アプリの実行に必要な関連する構成ファイル、ライブラリ、依存関係が含まれています。
  • コンテナ化されたサービスとそれに関連付けられているネットワークとストレージ コンポーネントを調整および管理する必要があります。 AKS は、クラスターとリソースの管理が自動化される優れたオプションです。 必要なノードの数を指定すると、AKS がコンテナーを適切なノードに適合させて、リソースを最大限に活用します。 AKS では、自動ロールアウトとロールバック、サービス検出、負荷分散、ストレージ オーケストレーションもサポートされています。 また、AKS では自己修復がサポートされます。 コンテナーに障害が発生すると、AKS によって新しいコンテナーが開始されます。 コンテナーの外部にシークレットと構成設定を安全に格納することもできます。
  • このアーキテクチャでは、Azure データセンターで障害が発生した場合の迅速なフェールオーバーおよびディザスター リカバリーのために、Site Recovery を使用して Azure VM をセカンダリ Azure リージョンにミラーリングします。
  • AKS デプロイのアプローチでワークロードのアップタイムを最大化するには、ビジネス継続性のために、異なるリージョンの複数の AKS クラスターにアプリケーションをデプロイすることをお勧めします。 AKS では複数のリージョン間でのストレージのレプリケーションが可能であるため、アプリケーションの状態を複数のクラスターで利用できます。
  • VM ベースのデプロイのアプローチでワークロードのアップタイムを最大化するには、Azure Virtual Machine Scale Sets の使用を検討してください。 Virtual Machine Scale Sets では、負荷分散が行われる VM のグループを作成して管理することができます。 需要または定義されたスケジュールに応じて、VM インスタンスの数を自動的に増減させることができます。 スケール セットは、アプリケーションの高可用性を実現します。また、多数の VM の一元的な管理、構成、更新を可能にします。

セキュリティ

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

  • このソリューションでは、Azure ネットワーク セキュリティ グループを使用して、Azure リソース間のトラフィックが管理されます。 詳細については、「ネットワーク セキュリティ グループ」を参照してください。
  • Azure Bastion は、開いているポートを最小化することで、管理者アクセス セキュリティを最大化します。 Bastion は、TLS 経由で Azure ポータルから直接、ネットワーク VM に安全かつシームレスに RDP/SSH 接続できます。

コストの最適化

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

Azure では、Windows VM で実行することによってコストが最適化されます。 Windows VM では、使用していないときに VM をオフにできるほか、既知の使用パターンに合わせてスケジュールを記述できます。 Azure では、適切な数またはリソースの種類を識別し、時間の経過に伴う支出を分析して、超過出費のないようにビジネス ニーズに合わせてスケーリングします。

このアーキテクチャのサービス コストを見積もるには、Azure 料金計算ツールを使用します。

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

オペレーショナル エクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。 詳細については、「オペレーショナル エクセレンス設計レビュー チェックリスト」を参照してください。

  • ターゲット アーキテクチャは、Azure Cloud Services で機能します。
  • コンテナーベースのデプロイでは、DevOps およびアジャイルの作業原則の導入が促進されます。
  • お客様は開発および運用デプロイのオプションを自在に選択できます。

パフォーマンス効率

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

  • このソリューションには、ロード バランサーによってパフォーマンスの効率性が組み込まれています。 1 つのプレゼンテーションまたはトランザクション サーバーで障害が発生した場合は、ロード バランサーの背後にあるサーバーにワークロードが引き継がれます。
  • Kubernetes には、クラスター オートスケーラーが用意されています。 このオートスケーラーを使用すると、ノード プール内の要求されたコンピューティング リソースに基づいてノードの数が調整されます。

共同作成者

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

プリンシパル作成者:

その他の共同作成者:

次のステップ

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