Azure 上の IBM z/OS のオンライン トランザクション処理

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

オンライン トランザクション処理 (OLTP) システムは、ユーザーと直接やり取りする、企業の顔となるものです。 動的に適応可能なインフラストラクチャを使用することで、企業は自社の製品を迅速に商品化して発売し、ユーザーを満足させることができます。

Architecture

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

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

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

ワークフロー

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

  1. ユーザーは、TN3270 や HTTPS などの標準のメインフレーム プロトコルを使用して、TCP/IP を介してメインフレームに接続します。
  2. トランザクション マネージャーは、ユーザーと対話し、アプリケーションを呼び出してユーザーの要求を満たします。
  3. ユーザーは、アプリケーション層のフロントエンドで、CICS/IMS 画面または Web ページを操作します。
  4. トランザクション マネージャーは、COBOL または PL/1 で記述されたビジネス ロジックを使用してトランザクションを実装します。
  5. アプリケーション コードでは、データ層 (通常は DB2、IMS DB、または VSAM) のストレージ機能が使用されます。
  6. トランザクション処理と同時に、他のサービスによって認証、セキュリティ、管理、監視、レポートが提供されます。 これらのサービスは、システム内の他のすべてのサービスとやり取りします。

ここで、このアーキテクチャを Azure に移行する方法について説明します。

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

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

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

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

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

  4. アプリケーション層のバックエンドの COBOL および PL/1 コードによって、ビジネス ロジックが実装されます。 このコードでは、Azure Functions、WebJobs、Azure Spring Apps マイクロサービスなどのサービスを使用できます。 アプリケーションは、Azure Kubernetes Service (AKS) コンテナーで実行できます。

  5. インメモリ データ ストアを使用すると、高スループットの OLTP アプリケーションが高速化されます。 このようなストアの 1 つが、Azure SQL データベースと Azure SQL Managed Instance の機能であるインメモリ OLTP です。 もう 1 つは Azure Cache for Redis です。

  6. データ層には、次のようなものが含まれます。

    1. Azure Storage サービスを使用して実装されたファイル、テーブル、および BLOB。
    2. Azure SQL ファミリからのリレーショナル データベース。
    3. PostgreSQL および MySQL のオープンソース データベースの Azure 実装。
    4. Azure Cosmos DB、NoSQL データベース。

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

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

コンポーネント

このアーキテクチャは、複数の Azure Cloud Services で構成され、リソースの 4 つのカテゴリ (ネットワークと ID、アプリケーション、ストレージ、監視) に分かれています。 以下のセクションでは、それぞれのサービスとその役割について説明します。

ネットワークと ID

  • Azure ExpressRoute を使用すると、オンプレミスのインフラストラクチャと Azure データセンターとの間にプライベート接続を実現できます。
  • Microsoft Entra ID は、オンプレミスのディレクトリと同期できる ID およびアクセス管理のサービスです。
  • Azure Front Door を使用すると、インスタント フェールオーバーを備えたグローバルな HTTP 負荷分散を実現できます。 キャッシュ オプションを使用すると、静的コンテンツの配信を高速化できます。
  • Azure Traffic Manager を使用すると、選択したトラフィック ルーティング方法に基づいて受信 DNS 要求を送信できます。
  • Azure Web Application Firewall は、悪意のある攻撃や、SQL インジェクションやクロスサイト スクリプティングなどの一般的な Web の脆弱性から Web アプリを保護するのに役立ちます。
  • Azure Content Delivery Network (CDN) を使用すると、静的コンテンツをエッジ サーバーにキャッシュして迅速な応答を実現し、ネットワーク最適化を使用して動的コンテンツの応答を改善することができます。 CDN は、ユーザー ベースがグローバルである場合に特に便利です。
  • Azure Application Gateway は、アプリケーション配信コントローラー サービスです。 これは、第 7 層のアプリケーション層で機能し、さまざまな負荷分散機能を備えています。
  • Azure Load Balancer は、第 4 層 (TCP、UDP) のロード バランサーです。 このアーキテクチャでは、Spring Apps と AKS の負荷分散オプションを提供します。

アプリケーション

  • Azure API Management は、API の公開、ルーティング、セキュリティ保護、ログ記録、分析を支援します。 データの表示方法と拡張方法、およびデータにアクセスできるアプリを制御できます。 アプリへのアクセスを制限することも、サード パーティを許可することもできます。
  • Azure App Service は、Web アプリを構築、デプロイ、およびスケーリングするためのフル マネージド サービスです。 .NET、.NET Core、Node.js、Java、Python、または PHP を使用してアプリを構築できます。 アプリは、コンテナー内または Windows 上または Linux 上で実行できます。 メインフレームの移行では、フロントエンド画面または Web インターフェイスを HTTP ベースの REST API としてコード化できます。 これらは、メインフレーム アプリケーションごとに分離できます。また、マイクロサービスベースのシステムを調整するためにステートレスにすることができます。
  • WebJobs は、Web アプリ、API アプリ、またはモバイル アプリと同じインスタンスでプログラムやスクリプトを実行する Azure App Service の機能です。 Web ジョブは、共有可能で再利用可能なプログラム ロジックを実装する場合に適しています。 技術情報については、「Azure App Service で Web ジョブを使用してバックグラウンド タスクを実行する」を参照してください。
  • Azure Kubernetes Service (AKS) は、コンテナー化されたアプリケーションをデプロイおよび管理するためのフル マネージド Kubernetes サービスです。 AKS を使用すると、運用上のオーバーヘッドが Azure にオフロードされるため、Azure でのマネージド ASK クラスターの展開が簡素化されます。
  • Azure Spring Apps は、フル マネージドの Spring Apps サービスであり、Microsoft と VMware によって共同で構築および運用されています。 これを使用すると、Spring マイクロサービスを簡単にデプロイ、管理、実行したり、Java または .NET を使用して Spring アプリケーションを作成したりすることができます。
  • Azure Service Bus は、シンプルなハイブリッド統合のための信頼性の高いクラウド メッセージング サービスです。 Service Bus キューと Storage キューにより、移行されたシステムのビジネス ロジックにフロントエンドを接続できます。
  • Azure Functions は、アプリケーション インフラストラクチャを確立することなく、関数と呼ばれる小さなコードを実行するための環境を提供します。 これを使用して、一括データの処理、システムの統合、IoT との連携、単純な API とマイクロサービスの構築を行うことができます。 マイクロサービスを使用すると、Azure サービスに接続するサーバーを作成して、常に最新の状態にすることができます。
  • Azure Cache for Redis は、コンピューティング リソース間でデータと状態を共有するための、フル マネージド メモリ内キャッシュ サービスです。 これには、オープンソースの Redis (OSS Redis) と、マネージド サービスとしての Redis Labs の商用製品 (Redis Enterprise) の両方が含まれています。 高スループット OLTP アプリケーションのパフォーマンスを向上させるには、それらがスケーリングできるように、また Azure Cache for Redis などのインメモリ データ ストアを利用できるように設計します。

Storage

監視

  • Azure Monitor は、Azure およびオンプレミス環境から個人データを収集、分析し、データに基づいて処理を実行します。
  • Log Analytics は、Azure portal のツールで、強力なクエリ言語を使用して Monitor ログのクエリを実行するために使用されます。 クエリの結果は、対話形式で使用することも、ログ クエリ アラートやブックなどの他の Azure Monitor の機能で使用することもできます。 詳細については、「Azure Monitor の Log Analytics の概要」を参照してください。
  • Application Insights は、Monitor の機能で、アプリケーションの使用状況、可用性、およびパフォーマンスのコード レベルの監視を提供します。 アプリケーションを監視し、パフォーマンスの低下や障害などのアプリケーションの異常を検出して、個人データを Azure portal に送信します。 Application Insights は、ログ、分散トレース、カスタム アプリケーションのメトリックにも使用できます。
  • Azure Monitor アラートは、Monitor の機能です。 詳細については、「Azure Monitor を使用してメトリック アラートを作成、表示、管理する」を参照してください。

シナリオの詳細

発展し続けるビジネス ニーズとデータにより、アプリケーションはインフラストラクチャの問題を発生させることなく、生産および拡張する必要があります。 このワークロード例では、Azure サービスとしてのプラットフォーム (PaaS) サービスを使用して、z/OS メインフレーム OLTP アプリケーションをクラウド内のセキュリティで保護されたスケーラブルな高可用性システムに移行する方法を示します。 このような移行により、金融、医療、保険、および小売企業は、アプリケーションの配信スケジュールを最短にすることができ、アプリケーションの実行にかかるコストを削減するのにも役立ちます。

考えられるユース ケース

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

  • 国際的なユーザー ベースにサービスを提供している。
  • 使用量が時間の経過と共に大きく変化する。つまり、柔軟なスケーリングと使用量ベースの価格によるメリットが得られます。

考慮事項

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

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

  • この OLTP アーキテクチャを複数のリージョンに展開して、geo レプリケートされたデータ層を持つことができます。
  • Azure データベース サービスではゾーン冗長がサポートされているため、障害が発生した場合や、メンテナンス アクティビティを可能にするために、セカンダリ ノードにフェールオーバーすることができます。

セキュリティ

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

  • ExpressRoute により、オンプレミス環境から Azure へのプライベート接続が作成されます。 サイト間 VPN を使用することもできます。
  • Microsoft Entra ID で Azure ロールベースのアクセス制御を使用することで、リソースの認証とアクセスの制御を行うことができます。
  • Azure のデータベース サービスでは、保存データの暗号化など、さまざまなセキュリティ オプションがサポートされています。
  • セキュリティで保護されたソリューションの設計に関する一般的なガイダンスについては、「セキュリティの重要な要素の概要」を参照してください。

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

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

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

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

  • このシナリオでは、Azure Monitor と Application Insights を使用して、Azure リソースの正常性を監視します。 予防的な管理のためのアラートを設定できます。
  • Azure の回復性に関するガイダンスについては、「信頼性の高い Azure アプリケーションの設計」を参照してください。

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

  • このアーキテクチャでは、App Service などの自動スケーリング機能を備えた Azure PaaS サービスが使用されます。
  • Azure での自動スケールのガイダンスについては、「自動スケール」を参照してください。

共同作成者

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

プリンシパル作成者:

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

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

次のステップ

次の関連アーキテクチャと関連する技術情報をご覧ください。