次の方法で共有

Azure におけるメインフレームとミッドレンジのアーキテクチャに関するデザイン

  • [アーティクル]

メインフレームとミッドレンジのハードウェアは、さまざまなベンダーによるシステムのファミリで構成されています (どれも目標としてハイ パフォーマンス、高スループット、時には高可用性に取り組んできた経歴があります)。 これらのシステムは多くの場合、"スケールアップ" 型でモノリシックでした。つまり、複数の処理ユニット、共有メモリ、共有ストレージを備えた単一の大きなフレームだったということです。

アプリケーションの側面について言うと、多くの場合、プログラムはトランザクションまたはバッチの 2 種類のいずれかで作成されていました。 どちらの場合も、COBOL、PL/I、Natural、Fortran、REXX など、複数のプログラミング言語が使用されていました。 これらのシステムは古くて複雑ですが、Azure への移行経路は多数あります。

データの側面について言うと、通常、データはファイルおよびデータベースに格納されます。 メインフレームおよびミッドレンジ データベースは通常、さまざまな構造になっており、特にリレーショナル、階層、ネットワークなどが挙げられます。 ファイル編成システムにはさまざまな種類があり、その中にはインデックスを付けたり、キーと値のストアとして機能させたりできるものがあります。 さらに、メインフレームのデータ エンコードは、メインフレーム以外のシステムで通常処理されるエンコードとは異なる場合があります。 そのため、データ移行は事前に計画したうえで処理する必要があります。 Azure データ プラットフォームに移行するためのオプションは多数あります。

メインフレームとミッドレンジの概要

レガシ システムを Azure に移行する

多くの場合、メインフレーム、ミッドレンジ、その他のサーバーベースのワークロードは、機能をほとんど、あるいはまったく失わずに Azure に複製できます。 場合によっては、基になるシステムの変更にユーザーが気付かないことがあります。 その他の状況では、レガシ ソリューションをリファクタリングおよびリエンジニアリングして、クラウド向けのアーキテクチャにするためのオプションがあります。 これは、同じまたは類似した機能を維持したままで行われます。 このコンテンツ セット (およびこの記事の後半で紹介するホワイト ペーパーとその他のリソース) で扱うアーキテクチャは、このプロセスを理解するのに役立ちます。

メインフレームとミッドレンジに関する概念

メインフレームのアーキテクチャでは、次の用語を使用します。

メインフレーム

"メインフレーム" は、1950 年代の後半に、大量のオンライン トランザクションとバッチ処理を実行するためのスケールアップ型のサーバーとして設計されました。 そのため、メインフレームにはオンライン トランザクション型 (グリーン スクリーンとも呼ばれています) のソフトウェアと、バッチ実行を処理するためのハイ パフォーマンスの I/O システムが備わっています。 メインフレームは、オンラインおよびバッチ ジョブを実行できることに加えて、信頼性と可用性にも優れています。

メインフレームのストレージ

メインフレームを深く理解するには、さまざまな重複する用語を解読することも必要です。 たとえば、中央ストレージ、物理メモリ、物理ストレージ、およびメイン ストレージは、すべてメインフレーム プロセッサに直接接続されているストレージを指します。 メインフレーム ハードウェアには、プロセッサや他の多くのデバイスが含まれます。たとえば、ダイレクト アクセス ストレージ デバイス (DASD)、磁気テープ ドライブ、一部のユーザー コンソールなどです。 テープと DASD は、システム関数のためにユーザー プログラムによって使用されます。

物理記憶領域の種類:

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

MIPS

1 秒間に実行できる百万単位の命令数 (MIPS) を測定することで、特定のマシンの 1 秒あたりのサイクル数の定数値が得られます。 MIPS は、メインフレームのコンピューティング能力全体を測定するために使用されます。 メインフレーム ベンダーは、MIPS の使用状況に基づいて顧客に課金します。 顧客は、特定の要件を満たすために、メインフレームのキャパシティを増やすことができます。 IBM では、さまざまなメインフレーム間の相対的なキャパシティを示すプロセッサ キャパシティ指標を保持しています。

次の表では、小規模、中規模、大規模なエンタープライズ組織 (SORG、MORG、LORG) での一般的な MIPS しきい値を示します。

顧客のサイズ 通常の MIPS の使用状況
SORG 500 MIPS 未満
MORG 500 MIPS から 5,000 MIPS
LORG 5,000 MIPS 超

メインフレームのデータ

メインフレームのデータは、リレーショナルおよび階層データベースから高スループットのファイル システムまで、さまざまな方法で格納および編成されます。 一般的なデータ システムの中には、リレーショナル データ用の z/OS Db2 と、階層データ用の IMS DB があります。 高スループットのファイル ストレージの場合は、VSAM (IBM の仮想記憶アクセス方式) が使われる場合があります。 次の表では、より多く使用されるいくつかのメインフレーム データ システムと、それに対して使用可能な Azure の移行対象のマッピングを示します。

データ ソース Azure のターゲット プラットフォーム
z/OS Db2 と Db2 LUW Azure SQL DB、Azure VM 上の SQL Server、Azure VM 上の Db2 LUW、Azure VM 上の Oracle、Azure Database for PostgreSQL
IMS DB Azure SQL DB、Azure VM 上の SQL Server、Azure VM 上の Db2 LUW、Azure VM 上の Oracle、Azure Cosmos DB
仮想ストレージアクセス方式 (VSAM)、インデックス付き順次アクセス方式 (ISAM)、その他のフラット ファイル Azure SQL DB、Azure VM 上の SQL Server、Azure VM 上の Db2 LUW、Azure VM 上の Oracle、Azure Cosmos DB
世代別データ グループ (GDG) 名前付け規則の拡張機能を使用して GDG と同様の機能を提供する Azure 上のファイル

ミッドレンジ システム、Unix バリアント、その他のレガシ システム

ミッドレンジ システムとミッドレンジ コンピューターとは、汎用的なパーソナル コンピューターよりも強力ですが、フルサイズのメインフレーム コンピューターよりは強力でないコンピューター システムを指す、大まかに定義された用語です。 ミッドレンジ コンピューターはたいていネットワーク サーバーとして使用されますが、これはクライアント システムの数が小から中程度の場合です。 一般に、コンピューターには、複数のプロセッサ、大量のランダム アクセス メモリ (RAM)、大容量のハード ドライブが搭載されています。 また、通常は、高度なネットワークを可能にするハードウェアと、より業務向けの周辺機器 (大規模なデータ記憶装置など) に接続するためのポートを備えています。

このカテゴリの一般的なシステムには、AS/400、IBM i および p シリーズなどがあります。 Unisys にも一連のミッドレンジ システムがあります。

Unix オペレーティング システム

Unix オペレーティング システムは、最初のエンタープライズ レベルのオペレーティング システムの 1 つです。 Unix は、Ubuntu や Solaris など、POSIX 標準に準拠したオペレーティング システムのベースとなっているオペレーティング システムです。 Unix は、1970 年代に AT&T Laboratories の Ken Thompson、Dennis Ritchie などによって開発されました。 当初の対象は非プログラマではなく、むしろソフトウェアを開発しているプログラマでした。 政府組織や教育機関に配布されると、その両者により、Unix は異なる特殊機能を備えた多種多様なバリエーションやフォークに移植されました。 Unix とそのバリアント (AIX、HP-UX、Tru64 など) は、IBM メインフレーム、AS/400 システム、Sun Sparc、DEC ハードウェアベースのシステムなどのレガシ システムで広く実行されています。

その他のシステム

他のレガシ システムには、DEC VAX、DEC Alpha、DEC PDP など、Digital Equipment Corporation (DEC) のシステム ファミリが含まれています。 最初、DEC システムでは VAX VM オペレーティング システムが実行されていましたが、最終的には Tru64 などの Unix のバリアントに移行しました。 その他のシステムとしては、HP-3000 および HP-9000 システムなど、PA-RISC アーキテクチャに基づくものが挙げられます。

ミッドレンジのデータとストレージ

ミッドレンジのデータは、リレーショナルおよび階層データベースから高スループットのファイル システムまで、さまざまな方法で格納および編成されます。 一般的なデータ システムの中には、リレーショナル データ用の Db2 for i と、階層データ用の IMS DB があります。 次の表では、より多く使用されるいくつかのメインフレーム データ システムと、使用可能な Azure の移行対象のマッピングを示します。

データ ソース Azure のターゲット プラットフォーム
Db2 for i Azure SQL DB、Azure VM 上の SQL Server、Azure Database for PostgreSQL、Azure VM 上の Db2 LUW、Azure VM 上の Oracle
IMS DB Azure SQL DB、Azure VM 上の SQL Server、Azure VM 上の Db2 LUW、Azure VM 上の Oracle、Azure Cosmos DB

エンディアン

エンディアンについては、次の詳細を考慮してください。

  • RISC と x86 プロセッサでは "エンディアン" が異なります。これは、システムがコンピューターのメモリにバイトを格納する方法を説明するために使用される用語です。
  • RISC ベースのコンピューターは、最上位の (「ビッグの」) 値を最初に、つまり最低位のストレージ アドレスに保存するため、ビッグ エンディアン システムとして知られています。
  • ほとんどの Linux コンピューターは、リトル エンディアン システムである x86 プロセッサに基づいているため、最下位の (「リトル」) の値を最初に格納します。

次の図は、ビッグ エンディアンとリトル エンディアンの違いを視覚的に示しています。

エンディアンの説明

アーキテクチャの種類の概要

再ホスト

このオプションは、リフトアンドシフト移行とも呼ばれ、コードを変更する必要がありません。 これを使用すると、既存のアプリケーションを Azure にすばやく移行できます。 各アプリケーションはそのままの状態で移行されるので、コード変更に関連するリスクやコストを伴わずにクラウドのメリットを享受できます。

リホストのアーキテクチャ

リファクター

リファクタリングの場合、アプリケーションに対して最小限の変更が必要です。 これにより、多くの場合、アプリケーション アーキテクチャで Azure のサービスとしてのプラットフォーム (PaaS) を活用することや、追加のクラウド オファリングを活用することができるようになります。 たとえば、既存のアプリケーションのコンピューティング コンポーネントを Azure App Service または Azure Kubernetes Service (AKS) に移行できます。 また、リレーショナルおよび非リレーショナル データベースを、Azure SQL Managed Instance、Azure Database for MySQL、Azure Database for PostgreSQL、Azure Cosmos DB などのさまざまなオプションにリファクターすることもできます。

リファクターのアーキテクチャ

リエンジニアリング

移行のためのリエンジニアリングでは、アプリケーションのアーキテクチャをクラウドのスケーラビリティに最適化するために、アプリケーションの機能とコード ベースを変更および拡張することに重点を置きます。 たとえば、モノリシック アプリケーションを、相互に連携し、簡単にスケーリングできるマイクロサービスのグループに分割できます。 また、リレーショナル データベースと非リレーショナル データベースを、フル マネージドのデータベース ソリューション (SQL Managed Instance、Azure Database for MySQL、Azure Database for PostgreSQL、Azure Cosmos DB など) にリアーキテクトすることもできます。

リエンジニアリングのアーキテクチャ

専用のハードウェア

Azure への (レガシ システムの) 移行のもう 1 つのパターンは、"専用のハードウェア" と呼ばれるものです。 このパターンでは、レガシ ハードウェア (IBM Power Systems など) が Azure データセンター内で実行され、Azure マネージド サービスでハードウェアをラップするため、クラウドの管理と自動化が容易になります。 さらに、このハードウェアから他の Azure IaaS および PaaS サービスに接続して、それらを利用できます。

専用のハードウェアのアーキテクチャ

データ移動と移行

Azure への従来の移行と変換の重要な部分は、データに関する考慮です。 これには、データ移動だけでなく、データのレプリケーションと同期も含まれる場合があります。

データ移動と移行のアーキテクチャ

次のステップ

ホワイト ペーパー、ブログ、ウェビナー、その他のリソースを利用すると移行の助けになり、レガシ システムを Azure に移行する経路を理解できます。

ホワイトペーパー

ウェビナー

ブログ記事

顧客事例

さまざまな業界が、革新的かつ刺激的な方法でレガシ メインフレームおよびミッドレンジ システムから移行しています。 お客様の導入事例と成功事例を以下に示します。