次の方法で共有

IBM z/OS OLTP ワークロードを Azure に移行する

Azure Front Door
Azure Traffic Manager
Azure Kubernetes Service (AKS)
Azure Spring Apps
Azure Cache for Redis

オンライントランザクション処理(OLTP)システムは、顧客と直接やり取りするため、ビジネスの顔です。 動的に適応可能なインフラストラクチャに移行することで、ビジネスは製品を迅速に作成して発売し、顧客が製品をより早く使用できるようになります。

アーキテクチャ

次の図は、Azure に移行する前に z/OS メインフレームで実行される OLTP システムのアーキテクチャを示しています。

z/OS 上の OLTP アーキテクチャーの図。

ワークフロー

次のワークフローは、前の図に対応しています。

  1. ユーザーは、TN3270 や HTTPS などの標準メインフレーム プロトコルを使用して、伝送制御プロトコル (TCP) またはインターネット プロトコル (IP) 経由でメインフレームに接続します。

  2. トランザクション・マネージャーは、ユーザーと対話し、アプリケーションを呼び出してユーザーの要求を満たします。

  3. アプリケーション層のフロントエンドでは、ユーザーは顧客情報管理システム (CICS) または情報管理システム (IMS) の画面または Web ページと対話します。

  4. トランザクション・マネージャーは、Common Business-Oriented Language (COBOL) または Programming Language One (PL/I) で書かれたビジネス・ロジックを使用して、トランザクションを実装します。

  5. アプリケーション・コードは、DB2、IMS DB、VSAM などのデータ層のストレージ機能を使用します。

  6. トランザクション処理に加えて、認証、セキュリティ、管理、監視、およびレポート作成を提供するサービスもあります。 これらのサービスは、システム内の他のすべてのサービスと対話します。

次の図は、このアーキテクチャを Azure に移行する方法を示しています。

z/OS OLTP ワークロードを Azure に移行するアーキテクチャを示す図。

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

  1. メインフレームのユーザーは、3270 端末とオンプレミス接続に精通しています。 移行されたシステムでは、パブリック インターネットまたは Azure ExpressRoute 経由で実装されたプライベート接続を介して Azure アプリケーションと対話します。 Microsoft Entra ID は認証を提供します。

  2. 入力要求は、Azure Front Door や Azure Traffic Manager などのグローバル ロード バランサー サービスに送られます。 ロードバランサーは、地理的に分散したユーザーベースに対応できます。 サポートされているワークロードに対して定義されたルールに従って要求をルーティングします。 これらのロード バランサーは、Azure Application Gateway または Azure Load Balancer と連携して、アプリケーション レイヤーの負荷を分散できます。 Azure Content Delivery Network サービスは、迅速な応答のために静的コンテンツをエッジ サーバーにキャッシュします。 Web アプリケーション ファイアウォール (WAF) は、サービスのセキュリティ保護に役立ちます。

  3. アプリケーション層のフロントエンドでは、Azure App Service などの Azure サービスを使用して、アプリケーション画面を実装し、ユーザーと対話します。 これらの画面は、メインフレーム画面の移行バージョンです。

  4. アプリケーション層のバックエンドにある COBOL コードと PL/I コードは、ビジネス・ロジックを実装します。 このコードでは、Azure Functions、WebJobs、Azure Spring Apps マイクロサービスなどのサービスと機能を使用できます。 アプリケーションは、Azure Kubernetes Service (AKS) コンテナーで実行できます。

  5. インメモリ データ ストアは、高スループットの OLTP アプリケーションを高速化します。 例としては、Azure SQL Database と Azure SQL Managed Instance の機能である In-Memory OLTP や、Azure Cache for Redis などがあります。

  6. データレイヤーには、次のものを含めることができます。

    • Azure Storage を使用して実装されたファイル、テーブル、BLOB 。
    • Azure SQL ファミリのリレーショナル データベース。
    • PostgreSQL と MySQL のオープンソース データベースの Azure 実装。
    • Azure Cosmos DB は NoSQL データベースです。

    これらのストアには、アプリケーション層が使用するためにメインフレームから移行されたデータが格納されます。

  7. Application Insights や Azure Monitor などの Azure ネイティブ サービスは、システムの正常性を事前に監視します。 Azure Monitor ログは、Azure ダッシュボードを使用して統合できます。

コンポーネント

このアーキテクチャは、いくつかの Azure クラウド サービスで構成されています。 これは、ネットワークと ID、アプリケーション、ストレージ、監視の 4 つのリソースカテゴリに分類されます。 次のセクションでは、各リソースのサービスとその役割について説明します。

ネットワークと ID

アプリケーション アーキテクチャを設計するときは、パブリック インターネットまたはプライベート接続を介した対話中にセキュリティ、パフォーマンス、管理性を確保するために、ネットワークと ID コンポーネントに優先順位を付けることが重要です。 アーキテクチャの次のコンポーネントは、この要件に効果的に対処するために不可欠です。

  • ExpressRoute は、オンプレミス インフラストラクチャと Azure データセンター間のプライベート接続を伝送します。

  • Microsoft Entra ID は、オンプレミスのディレクトリと同期できる ID およびアクセス管理サービスです。

  • Azure Front Door は、即時フェールオーバーによるグローバル HTTP 負荷分散を提供します。 そのキャッシングオプションは、静的コンテンツの配信を高速化できます。

  • Traffic Manager は、選択したトラフィック ルーティング方法に基づいて、ドメイン ネーム システムの受信要求を転送します。

  • Azure WAF は 、悪意のある攻撃や一般的な Web の脆弱性 (SQL インジェクションやクロスサイト スクリプティングなど) から Web アプリを保護するのに役立ちます。

  • Content Delivery Network は、静的コンテンツをエッジ サーバーにキャッシュして迅速な応答を可能にし、ネットワークの最適化を使用して動的コンテンツの応答を改善します。 Content Delivery Network は、ユーザー ベースがグローバルである場合に特に便利です。

  • Application Gateway は、アプリケーション配信コントローラー サービスです。 これは、第 7 層のアプリケーション層で機能し、さまざまな負荷分散機能を備えています。

  • ロードバランサ ーは、レイヤー4(TCPまたはユーザーデータグラムプロトコル)ロードバランサーです。 このアーキテクチャでは、Azure Spring Apps と AKS の負荷分散オプションが提供されます。

アプリケーション

Azure は、アプリケーションのより安全でスケーラブルで効率的なデプロイをサポートするマネージド サービスを提供します。 上記のアーキテクチャで使用されるアプリケーション層サービスは、アプリケーション アーキテクチャの最適化に役立ちます。

  • Azure API Management は、API の発行、ルーティング、セキュリティ保護、ログ記録、分析をサポートしています。 データの表示方法と拡張方法、およびデータにアクセスできるアプリを制御できます。 アプリへのアクセスを制限したり、サードパーティを許可したりできます。

  • App Service は、Web アプリを構築、デプロイ、スケーリングするためのフル マネージド サービスです。 アプリは、.NET、.NET Core、Node.js、Java、Python、または PHP を使用して構築できます。 アプリは、コンテナー内、または Windows または Linux で実行できます。 メインフレームの移行では、フロントエンド画面または Web インターフェイスを HTTP ベースの REST API としてコード化できます。 これらはメインフレームアプリケーションに従って分離でき、マイクロサービスベースのシステムを調整するためにステートレスにすることができます。

  • WebJobs は、Web アプリ、API アプリ、またはモバイル アプリと同じインスタンスでプログラムまたはスクリプトを実行する App Service の機能です。 Web ジョブは、共有可能で再利用可能なプログラム ロジックを実装するのに適しています。 詳細については、「 App Service の WebJobs を使用したバックグラウンド タスクの実行」を参照してください。

  • AKS は、コンテナー化されたアプリケーションをデプロイおよび管理するためのフル マネージド Kubernetes サービスです。 AKS は、運用オーバーヘッドを Azure にオフロードすることで、マネージド AKS クラスターの Azure へのデプロイを簡略化します。

  • Azure Spring Apps は、Microsoft と VMware が共同で構築および運用するフル マネージド Spring サービスです。 Azure Spring Apps を使用すると、Spring マイクロサービスを簡単にデプロイ、管理、実行し、Java または .NET を使用して Spring アプリケーションを作成できます。

  • Azure Service Bus は、シンプルなハイブリッド統合のための信頼性の高いクラウド メッセージング サービスです。 Service Bus キューと Storage キューは、移行されたシステムのビジネス ロジックにフロントエンドを接続できます。

  • Azure Functions は、アプリケーション インフラストラクチャを確立することなく、関数と呼ばれる小さなコードを実行するための環境を提供します。 これを使用して、一括データの処理、システムの統合、モノのインターネットとの連携、シンプルなAPIとマイクロサービスの構築を行うことができます。 マイクロサービスを使用して、Azure サービスに接続し、常に最新の状態に保つサーバーを作成します。

  • Azure Cache for Redis は、コンピューティング リソース間でデータと状態を共有するためのフル マネージドのインメモリ キャッシュ サービスです。 これには、マネージド サービスとして、オープンソースの Redis と Redis Labs の商用製品である Redis Enterprise が含まれます。 高スループットの OLTP アプリケーションのパフォーマンスを向上させるには、スケーリングし、Azure Cache for Redis などのインメモリ データ ストアを使用するように設計します。

ストレージとデータベース

このアーキテクチャは、スケーラブルで安全性の高いクラウドストレージと、柔軟でインテリジェントなデータ管理のためのマネージドデータベースに対応しています。

モニタリング

次の監視ツールは、包括的なデータ分析とアプリケーションのパフォーマンスに関する貴重な洞察を提供します。

  • Azure Monitor は、Azure 環境とオンプレミス環境から個人データを収集、分析、および処理します。

    Azure Monitor アラートは Monitor の機能です。 詳細については 、「Azure Monitor を使用してメトリック アラートを作成、表示、管理する」を参照してください。

  • Log Analytics は、強力なクエリ言語を使用して Azure Monitor ログのクエリを実行するために使用する Azure portal のツールです。 クエリの結果を操作したり、ログ クエリ アラートやブックなどの他の Azure Monitor 機能と共に使用したりできます。 詳細については、「Azure Monitor の Log Analytics の概要」を参照してください。

  • Application Insights は、アプリケーションの使用状況、可用性、パフォーマンスをコードレベルで監視する Azure Monitor の機能です。 アプリケーションを監視し、平凡なパフォーマンスや障害などの異常を検出し、個人データを Azure portal に送信します。 また、Application Insights を使用して、ログ記録、分散トレース、およびカスタム アプリケーション メトリックを行うこともできます。

シナリオの詳細

ビジネス・ニーズとデータの進化により、アプリケーションはインフラストラクチャの問題を引き起こすことなく拡張し、結果を出す必要があります。 このワークロードの例では、Azure のサービスとしてのプラットフォーム (PaaS) サービスを使用して、z/OS メインフレーム OLTP アプリケーションをクラウド内のより安全でスケーラブルで可用性の高いシステムに移行する方法を示します。 この移行により、金融、医療、保険、小売業の企業は、アプリケーションの配信スケジュールを最小限に抑えることができます。 また、アプリケーションの実行コストを削減するのにも役立ちます。

考えられるユース ケース

このアーキテクチャは、次の特性を持つ OLTP ワークロードに最適です。

  • 彼らは国際的なユーザーベースにサービスを提供しています。

  • その使用量は時間とともに大きく異なるため、柔軟なスケーリングと使用量ベースの価格設定の恩恵を受けることができます。

考慮事項

これらの考慮事項では、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、「 Well-Architected Framework」を参照してください。

信頼性

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

  • この OLTP アーキテクチャは、複数のリージョンにデプロイできます。 また、geo レプリケートされたデータ レイヤーを持つこともできます。

  • Azure データベース サービスはゾーン冗長性をサポートしており、障害が発生した場合やメンテナンス アクティビティを許可するために、セカンダリ ノードにフェールオーバーできます。

安全

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

  • ExpressRoute は、オンプレミス環境から Azure へのプライベート接続を作成します。 サイト間 VPN を使用することもできます。

  • Microsoft Entra ID は、Azure ロールベースのアクセス制御を使用して、リソースを認証し、アクセスを制御できます。

  • Azure のデータベース サービスでは、保存時のデータ暗号化など、さまざまなセキュリティ オプションがサポートされています。

  • より安全なソリューションを設計する方法に関する一般的なガイダンスについては、「 セキュリティのクイック リンク」を参照してください。

コストの最適化

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

Azure 料金計算ツールを使用して、実装のコストを見積もります。

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

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

このシナリオでは、Azure Monitor と Application Insights を使用して、Azure リソースの正常性を監視します。 予防的な管理のためのアラートを設定できます。

パフォーマンス効率

パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。

  • このアーキテクチャでは、自動スケーリング機能を備えた App Service などの Azure PaaS サービスを使用します。

  • 詳細については、自動スケーリングのページを参照してください。

貢献者達

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主要な著者:

  • Ashish Khandelwal | プリンシパル エンジニアリング アーキテクチャ マネージャー
  • Nithish Aruldoss | エンジニアリング アーキテクト

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

以下の関連アーキテクチャおよび関連技術情報を参照してください。