メインフレームから Azure に切り替える

[アーティクル]
07/11/2023

Azure は、従来のメインフレームアプリケーションを実行するための代替プラットフォームとして、高可用環境にハイパースケールのコンピューティングとストレージを提供します。メインフレーム環境に関連するコストをかけずに、最新のクラウドベースのプラットフォームの価値と敏捷性が手に入ります。

このセクションでは、メインフレームプラットフォームから Azure への切り替えに関する技術的なガイダンスを提供します。

Mainframe and Azure

MIPS と vCPU

メインフレームのワークロードを実行するために必要な仮想中央処理装置 (vCPU) の数を決定するための汎用のマッピング式はありません。ただし、100万命令毎秒 (MIPS) のメトリックは、多くの場合、Azure 上の vCPU にマップされます。 MIPS では、特定のマシンの 1 秒あたりのサイクル数を一定の値にすることで、メインフレームの全体的なコンピューティング能力を測定します。

小規模な組織では 500 MIPS 未満で済みますが、大規模な組織は通常 5,000 MIPS を超えます。 1 MIPS あたり 1,000 ドルの場合、大規模な組織では 5,000 MIPS のインフラストラクチャをデプロイするために年間約 500 万ドルを費やします。この規模の一般的な Azure デプロイの年間コスト見積もりは、MIPS インフラストラクチャのコストの約 1/10 です。

Azure による vCPU への MIPS の正確な計算は、vCPU の種類と実行している正確なワークロードによって変わります。ただし、ベンチマーク調査は、必要となる vCPU の数と種類を見積もるための優れた基盤となります。最近の HPE zRef ベンチマークは、以下の見積もりを提供しています。

オンライン (CICS) ジョブの場合、HPE ProLiant サーバー上で実行される Intel ベースのコアあたり 288 MIPS。
COBOL バッチジョブの場合、Intel コアあたり 170 MIPS。

このガイドでは、オンライン処理の場合は vCPU あたり 200 MIPS、バッチ処理の場合は vCPU あたり 100 MIPS と見積もります。

Note

このような見積もりは、新しい仮想マシン (VM) シリーズが Azure で使用できるようになると変わる可能性があります。

高可用性とフェールオーバー

メインフレームシステムでは、メインフレームの結合と Parallel Sysplex を使用する場合、ファイブナインの可用性 (99.999%) が提供されることがよくあります。それでも、システム運用者は、保守と初期プログラム読み込み (IPL) のためのダウンタイムをスケジュールする必要があります。実際の可用性は、ハイエンドの Intel ベースのサーバーに匹敵するツーナインまたはスリーナインに近づきます。

対照的に、Azure はコミットメントベースのサービスレベルアグリーメント (SLA) を提供します。この場合、複数ナインの可用性が既定であり、ローカルまたは地域ベースのサービスのレプリケーションに最適化されています。

Azure は、ローカルでも他の地域内でも、複数のストレージデバイスからデータをレプリケートすることで可用性を向上します。 Azure ベースの障害が発生した場合、コンピューティングリソースはローカルまたはリージョンレベルでレプリケートされたデータにアクセスできます。

Azure SQL Database や Azure Cosmos DB などの Azure のサービスとしてのプラットフォーム (PaaS) リソースを使用すると、Azure で自動的にフェールオーバーを処理できます。 Azure サービスとしてのインフラストラクチャ (IaaS) を使用する場合、フェールオーバーは、SQL Server の Always On 機能、フェールオーバークラスタリングインスタンス、可用性グループなどの特定のシステム機能に依存します。

スケーラビリティ

メインフレームは通常スケールアップしますが、クラウド環境はスケールアウトします。メインフレームは結合機能 (CF) を使用してスケールアウトできますが、ハードウェアとストレージのコストが高いため、メインフレームのスケールアウトは高価です。

さらに、CF は密結合コンピューティングを提供しますが、Azure のスケールアウト機能は疎結合です。クラウドは、使用量ベースの課金モデルでは、オンデマンドのコンピューティング能力、ストレージ、およびサービスのスケールによって、正確なユーザー仕様に合わせてスケールアップまたはスケールダウンできます。

バックアップと回復

一般的に、メインフレームのお客様は、災害時に備えてディザスターリカバリーサイトを保守するか、独立したメインフレームプロバイダーを利用しています。ディザスターリカバリーサイトとの同期は、通常、データのオフラインコピーを使用して実行されます。どちらの方法も高コストが発生します。

自動化された geo 冗長性は、メインフレームの結合機能を介しても利用できます。この方法はコストが高く、通常、ミッションクリティカルなシステム用に予約されています。対照的に、Azure には、実装が簡単で費用対効果の高いバックアップ、復旧、および冗長性のオプションがあり、ローカルレベルまたはリージョンレベルで、または geo 冗長性を介して利用できます。

ストレージ

メインフレームのしくみを理解するには、さまざまな重複する用語を解読することも必要です。たとえば、一般的に、中央ストレージ、物理メモリ、物理ストレージ、およびメインストレージは、すべてメインフレームプロセッサに直接接続されているストレージを指します。

メインフレームハードウェアには、プロセッサや他の多くのデバイスが含まれます。たとえば、ダイレクトアクセスストレージデバイス (DASD)、磁気テープドライブ、一部のユーザーコンソールなどです。テープと DASD は、システム関数のためにユーザープログラムによって使用されます。

メインフレーム用の物理ストレージには、次のような種類があります。

中央ストレージ: メインフレームプロセッサ上に直接配置され、これはプロセッサまたは物理ストレージとも呼ばれます。
補助ストレージ: メインフレームとは別に配置されます。この種類には、DASD 上のストレージが含まれ、ページングストレージとも呼ばれます。

クラウドには、柔軟でスケーラブルなオプションが幅広く用意されており、必要なオプションに対してのみ料金を支払います。 Azure Storage は、データオブジェクトのための高度にスケーラブルなオブジェクトストア、クラウドのためのファイルシステムサービス、信頼性の高いメッセージングストア、および NoSQL ストアを提供します。 VM の場合、マネージドディスクとアンマネージドディスクは、永続的でセキュリティで保護されたディスクストレージを提供します。

メインフレームの開発とテスト

メインフレーム移行プロジェクトの主なけん引役は、アプリケーション開発の変化する面です。組織は、ビジネスニーズに対する開発環境の俊敏性と応答性を高める必要があります。

一般的に、メインフレームには、QA やステージング LPAR など、開発用とテスト用に別の論理パーティション (LPAR) があります。メインフレーム開発ソリューションには、コンパイラ (COBOL、PL/I、アセンブラー) とエディターが含まれます。最も一般的なものは、IBM メインフレーム上で稼働する z/OS オペレーティングシステム用の対話式システム生産性向上機能 (ISPF) です。その他には、ROSCOE Programming Facility (RPF) や、CA Librarian や CA-Panvalet などの Computer Associates ツールがあります。

エミュレーション環境とコンパイラは x86 プラットフォーム上で使用できるので、一般的に開発とテストはメインフレームから Azure に移行する最初のワークロードになる可能性があります。 Azure の DevOps ツールの可用性と普及により、開発環境とテスト環境の移行が加速しています。

ソリューションを Azure 上で開発およびテストし、メインフレームへの展開の準備が整ったら、コードをメインフレームにコピーしてそこでコンパイルする必要があります。

次のステップ

メインフレームアプリケーションの移行