AWS Mainframe Modernization のファイルシステム選択

このブログは 2022 年 10 月 18 日に Maggie Li（Principal Software Engineer）と、Yann Kindelberger（Senior Mainframe Solutions Architect）、Peter West（Senior Migration Engineer）、Phil de Valence（Principal Product Manager）によって執筆された内容を日本語化したものです。原文はこちらを参照してください。

メインフレームアプリケーションは、ビジネスで重要な機能を実行することが多く、回復力や拡張性、コスト効率に優れている必要があります。この必須事項は、ファイルやデータセット、それらをサポートするストレージシステムなど、アプリケーションをサポートする複数のレイヤーとコンポーネントにも適用されます。AWS を使用してこれらのアプリケーションとファイルをモダナイズする場合、アプリケーションのデータプロファイルに応じて最適なファイルシステムを選択することが重要です。さらに、ファイルシステムは、パフォーマンスと可用性、コストなどの複数の側面のバランスをとる厳しい機能要件および非機能要件を満たす必要があります。この記事では、メインフレームアプリケーションと AWS のファイルシステムオプションの一般的な要件について説明し、適切な AWS のファイルシステムを選択するためのアプローチを提供します。

メインフレームアプリケーションファイルシステムのユースケースと要件

メインフレームアプリケーションは、ビジネスデータのためにリレーショナルデータベースやデータセット、ファイル、階層型データベース、転置インデックスデータベース、ネットワークモデルデータベースなどの様々なデータストアとストレージタイプを使用します。データセットは編成と、一般的に論理レコードを持つ構造化されたデータファイルです。AWS メインフレームモダナイゼーションの文脈において、ファイルとデータセットは共通的な検討事項であり、適切なターゲットのソリューションを設計及び選択するためには、十分な分析が必要です。この記事では、ファイルシステムソリューションに依存するファイルベースのユースケースに焦点を当てています。

メインフレームのデータセットタイプには、読み取りまたは書き込みの目的でアクセスができる物理順次（PS）やパーティションデータセット（PDS）、世代別データグループ（GDG）、仮想記憶アクセス方式（VSAM）など多くのタイプがあります。PS および PDS、GDG の各データセットは、レコードごとに順次アクセスされます。VSAM にはアクセス方式が異なる複数の編成があり、VSAM ESDS データセットは順次アクセスされます。VSAM KSDS と RRDS データセットは、順次またはランダム、もしくは動的にアクセスされます。また、VSAM LDS データセットがアプリケーションから直接アクセスされることはほとんどありません。

メインフレームアプリケーションの実行には、主に 2 つの方法があります。 1 つ目は、ユーザーはオンラインでリアルタイムの要求やトランザクションをインタラクティブに実行する方法です。2 つ目は、バッチジョブを自動化して一括処理ができるようにスケジューリングする方法です。メインフレームのオンラインアプリケーションを移行およびモダナイズする場合、対応するデータは高可用性と分散ロック管理のためにリレーショナルデータベースに移行されることがよくあります。一方で、レコードを一括処理するバッチアプリケーションでは、入出力（I/O）集中型のストレージが必要であり、I/O Operations Per Second（IOPS）と、高スループット、低レンテンシーといった高い性能を持つファイルシステムにバッチデータを格納することが好まれます。

メインフレームのバッチジョブは、シングルスレッドであることが多く、バッチユーティリティやプログラムを介して入力データセットを読み取り、出力データセットを書き込みます。ほとんどの場合、1 つのバッチスレッドがデータセットを処理しますが、いくつかのバッチジョブやステップが並列で実行され、データセットにアクセスする場合があります。

メインフレームアプリケーションの高可用性要件について、AWS Well-Architected のベストプラクティスでは、AWS の複数のアベイラビリティゾーン（AZ）に跨ってアプリケーションをデプロイし、AWS のリージョン間でソリューションを設計するよう検討します。従って、高速にフェイルオーバーするために、マルチ AZ でストレージソリューションをデプロイすることが一般的な要件となります。メインフレームアプリケーションは、コアビジネスのデータを格納することが多いため、ソリューションは通常、AZ 間のフェイルオーバーまたはフェイルバック中にデータを失うことなく、データの整合性を維持する必要があります。アプリケーションがマルチ AZ の複数のコンピューティングノードで実行される場合、分散ロックなどのメカニズムを使用して、どの AZ からの読み取り/書き込みアクセスでもデータの整合性を維持する必要があります。

AWS Mainframe Modernization サービスで移行したデータセット

新しい AWS Mainframe Modernization サービスは、メインフレームアプリケーションの移行やモダナイズ、AWS 上で実行するための AWS クラウドネイティブプラットフォームです。これには、オンデマンドツールと、広範な自動化とシンプルなインターフェイスを備えたマネージドランタイム環境が含まれています。このプラットフォームは、自動リファクタリングとリプラットフォームという 2 つの一般的な移行とモダナイゼーションパターンをサポートしています。さらに、この AWS サービスを使用すると、データセットをリレーショナルデータベースに移行してモダナイズドしたり、ファイルシステムに保存することができます。

例えば、AWS Mainframe Modernization Blu Age ソリューションでは、データセットをファイルシステムに格納されたシーケンシャルまたはインデックス付きのファイルに移行するオプションがあります。これを促進するために、BluSAM データアクセスレイヤーを使用し、移行されたデータをモダナイズされたアプリケーションのビジネスロジックに公開することができます。さらに、BluSAM には、低レイテンシーやキャッシュ、圧縮のための最適化が含まれています。

AWS Mainframe Modernization Micro Focus ソリューションでは、データセットをシーケンシャルや、インデックス、相対データセットとしてファイルシステムに格納できます。これは、PS や PDS、GDG、VSAM などの多くのデータセット編成をサポートしています。移行したプログラムは、デフォルトで Micro Focus File Handler Application Programming Interface（API）を呼び出し、すべての標準的なファイル編成ですべての I/O 操作を実行します。

どちらの AWS Mainframe Modernization パターンでも、前述のファイルシステムの可用性や IOPS、スループット、レイテンシー、コスト効率に関する要件と考慮事項が適用されます。

モダナイズされたメインフレームアプリケーション向けに選択可能な AWS ファイルシステム

何百万人ものお客様が、AWS のストレージサービスを利用して、ビジネスの効率化や俊敏性の向上、コスト削減、イノベーションのスピードアップを実現しています。AWS は、ブロックストレージやファイルストレージ、オブジェクトストレージを含む幅広いデータストレージサービスを提供しています。この記事では、以下の主要な高性能ストレージサービスとファイルシステムに焦点を当て、メインフレームアプリケーションのためのそれぞれの特徴について説明します。これらのファイルシステムは、AWS マネジメントコンソールのシンプルなインターフェイスを使用してハードウェア管理を自動化する AWS のマネージドサービスです。

Amazon FSx は、機能豊富で高性能なファイルシステムをクラウド上で簡単かつコスト効率よく作成、実行、スケーリングすることができます。Amazon FSx は、信頼性と、セキュリティ、スケーラビリティ、幅広い機能により、様々なワークロードをサポートします。利用者は、NetApp ONTAP と OpenZFS、Windows File Server、Lustre の 4 つの広く利用されているファイルシステムから選択できます。ここでは、Linux 互換ファイルシステムである NetApp ONTAPと OpenZFS、Lustre に焦点を当てています。

Amazon Elastic File System（Amazon EFS）は、シンプルでサーバーレス、全自動の伸縮可能なファイルシステムです。Amazon EFS ファイルシステムは、ストレージをプロビジョニングすることなく、ギガバイトからペタバイトまでのデータに自動的にスケーリングできます。数千のコンピュータインスタンスが同時に Amazon EFS ファイルシステムにアクセスでき、各コンピュータインスタンスに一貫したパフォーマンスを提供します。また、高い耐久性と可用性を備えています。Amazon EFS は、最低料金や設定費用が不要なので、利用者は使用した分だけを支払うだけです。

Amazon Elastic Block Store（Amazon EBS）は、使いやすく、スケーラブルで高性能なブロックストレージサービスで、ファイルシステムを構成することができます。Amazon EBS は複数のボリュームタイプを提供しており、幅広いアプリケーションに対してストレージのパフォーマンスとコストを最適化することができます。これらのボリュームタイプは、トランザクションワークロード用の SSD バックドストレージ（gp2、gp3、io1、io2）と、スループット集中型ワークロード用の HDD バックドストレージ（sc1 、st1）の 2 つの主要なカテゴリに分類されます。この記事では、Amazon EBS の io2、gp2、st1 について詳しく説明します。

Amazon EC2 インスタンスストアは、Amazon Elastic Compute Cloud（Amazon EC2）インスタンスに一時的なブロックレベルのストレージを提供し、多くの場合、ファイルシステムは事前にフォーマットされています。このストレージは、ホストコンピューターに物理接続されたディスクに配置しています。インスタンスストアのデータは、関連付けられたインスタンスの起動中のみ保持されるため、バッチジョブ内のステップ間で一時的に使用される一時的なデータセットの中間ストレージに適しています。Amazon EC2 のインスタンスタイプによって、使用可能なインスタンスストアのサイズと、インスタンスストアボリュームに使用されるハードウェアのタイプが決まります。インスタンスストアボリュームは、インスタンスの利用料金の一部として含まれます。

メインフレームアプリケーションファイルシステムの機能比較

AWS のストレージ製品を選択することで、特定のメインフレームアプリケーション要件を最適化することができます。各ファイルシステムのオプションには、それぞれの利点と制限があります。次の表は、Amazon EFS と Amazon FSx for Lustre、FSx for NetApp ONTAP、FSx for OpenZFS、Amazon EBS（io2、io2 block express、gp2、st1）の重要ないくつかの機能を比較したものです。

Table 1 – File-system functional capabilities comparison

表 1：ファイルシステムの機能比較

高速フェイルオーバーによる高可用性を実現するために、マルチ AZ にまたがるコンピューティングノードでアプリケーションを実行する必要がある場合は、マルチ AZ の導入オプションが重要になりますが、FSx for NetApp ONTAP と Amazon EFS は共にそのような要件を満たすことができます。

耐久性は、あるファイルが 1 年後に無傷でアクセス可能な状態を維持することができる確率です。データを複数の場所に分散してコピーすることで、耐久性を向上できます。

可用性は、ストレージサービスが必要なときにデータにアクセスができる確率によって測定されます。

定期的に新しい機能が AWS のファイルシステムとストレージオプションに追加されます。ファイルシステムを選択する前に、ストレージサービスの各 Webサイトで最新の機能を確認する必要があります。Amazon FSx については、Amazon FSx ファイルシステムの選択で最新の選択ガイダンスを確認できます。Amazon EFS については、Amazon EFS を選択する場合を参照してください。また、Amazon EBS の場合は、Amazon EBS ボリュームタイプのユースケースと特徴が確認できます。

メインフレームアプリケーションファイルシステムの相対的な性能比較

AWS のファイルシステムオプションのパフォーマンスを比較するために、ファイルシステムを評価するための特定のアプリケーションロジックとデータフォーマットで、いくつかのパフォーマンスベンチマークテストを実行することをお勧めします。これらの AWS ファイルシステムは、オンデマンドで数分単位で利用できる従量課金制であるため、複数のオプションをすばやくテストし、適切なオプションを特定することができます。

例として、特定の AWS が所有する COBOL アプリケーションに対して、複数の AWS ファイルシステムオプションのパフォーマンスを測定するベンチマークを実行しました。このアプリケーションは、様々なバッチワークロードデータアクセスパターンを実行します。このバッチアプリケーションは、データセットへの排他的アクセス（共有なし）を持つ単一の実行スレッドを使用して、バルクデータ処理をシミュレートしています。このテストのデータセットのレコード長は 1,000 バイトです。これらのパフォーマンステストの結果は、テストした AWS 所有のアプリケーションと構成に固有のものであり、他のアプリケーションでは色々な要素が変わるため汎用的に当てはめることはできません。以下の図は、テストした各ファイルシステムオプションを使用して、複数のデータアクセスタイプに対して得られたパフォーマンス結果を示しています。これらの図の ec2_instance は Amazon EC2 インスタンスストアを表していることに注意してください。

Figure 1 – Sequential reads average elapsed time

図 1：シーケンシャルリードの平均経過時間

上の図は、20 ギガバイトのシーケンシャルデータセット（SEQREAD）で 1,000 バイトのレコードをシーケンシャルリードした場合の平均経過時間を示しています。経過時間は短いほど良い値を示しています。また、20 ギガバイトのインデックス付きデータセット（SEQ-ISAMREAD）上の 1,000 バイトレコードのシーケンシャルリードの平均経過時間も示しています。この例では、FSxfor NetApp ONTAP が、マルチ AZ デプロイ機能とシーケンシャルリードの強力なパフォーマンスを兼ね備えています。

Figure 2 – Random reads average elapsed time

図 2：ランダムリードの平均経過時間

上の図は、20 ギガバイトのインデックス付きデータセット（RND-ISAMREAD）で 1000 バイトのレコードをランダムリードした場合の平均経過時間を示しています。経過時間は短いほど良い値を示しています。これらのパフォーマンステストの例では、Amazon EC2 インスタンスストアが高いパフォーマンスを示していますが、このユースケースは、データがローカルに保持され、 Amazon EC2 インスタンスが起動中の一時的な状況に限られます。

Figure 3 – Sequential Writes average elapsed time

図 3：シーケンシャルライトの平均経過時間

上の図は、100 ギガバイトのシーケンシャルデータセットに 1,000 バイトのレコードをシーケンシャルライトした場合の平均経過時間を示しています。経過時間は短いほど良い値を示しています。この例では、Amazon EBS ボリュームは、シングル AZ へデプロイおよび実行されるアプリケーションに適した高いパフォーマンスを示しています。Amazon EBS ボリュームのユースケースとして、マルチ AZ のファイルシステム可用性を必要としないバッチアプリケーションです。

メインフレームアプリケーションファイルシステムの相対的なコスト比較

コストの最適化は、AWS Well-Architected 設計の重要な柱です。機能とパフォーマンスの特性だけでなく、各オプションのコストバランスも考慮してファイルシステムを選択しなければなりません。。そのため、ファイルシステムを評価するための具体的な構成と要件を使用して、いくつかのコスト評価を実行することをお勧めします。各ファイルシステムオプションの料金は、それぞれの Web サイトで確認することができます。また、AWS 料金見積りツールを使用してコストを見積もることもできます。

例として、性能ベンチマークで評価した特定の構成について、複数の AWS ファイルシステムオプションの月額コストを特定の前提で試算しています。色々な要素が変わるため、表 2 の結果は他の構成に汎用的に当てはめることはできません。

Table 2 – File-system monthly cost evaluation

表 2：ファイルシステムの月次コスト評価

メインフレームファイルシステムの選定アプローチ

最適なストレージソリューションは、アプリケーションタイプや、データアクセスのパターン、ファイルサイズ、アクセス方法、必要となるパフォーマンス、可用性、耐久性、コストなどの様々な側面に基づいて変化します。1 つのソリューションで全てを解決できるわけではありません。メインフレームアプリケーションの AWS Well-Architected 設計では、1 つまたは複数のストレージソリューションを使用することができます。

メインフレームアプリケーション向けのファイルシステムを検討する場合は、まず、可用性と展開、耐久性、レプリケーション、スループットなどの機能要件を満たすファイルシステムオプションを特定することをお勧めします。2 つ目に、アプリケーションの技術的な要件を元にサイジングを行い、具体化した構成に対してコストの見積りを行う必要があります。3 つ目に、AWS のオンデマンドファイルシステムを迅速にテストできる利点を活かして、AWS 上でアプリケーション固有の実際のパフォーマンステストを行い、ファイルシステムのパフォーマンスを評価することです。最後に、メインフレームアプリケーションで厳しい I/O 性能要件がある場合は、移行とモダナイゼーションの取り組みの早い段階で概念実証（POC）を実行することで、ファイルシステムオプションを検証できます。

例として、前のセクションで説明したパフォーマンスベンチマークでテストした特定の AWS 所有の COBOL アプリケーションのパフォーマンスとコストの分析を組み合わせました。このため、他のアプリケーションでは色々な要素が変わるため汎用的に当てはめないでください。それでも、より良い選択を決定するために、どのように評価ディメンションを組み合わせことができるかの例を提供します。

Figure 4 – Annual cost for Sequential Writes

図 4：シーケンシャルライトの年次コスト

上の図は、1,000 バイトのデータレコードをデータセットに書き込むための年間コストと、平均応答時間を考慮したさまざまなファイルシステムオプションの位置付けを示しています。バブルの大きさはパフォーマンスのばらつきを表しており、バブルが大きいほど標準偏差が小さく、パフォーマンスが安定していることを意味しています。

ビルドする

AWS は、メインフレームアプリケーションの多くの要件を満たすことができる様々なファイルシステムオプションと構成を提供します。アプリケーションに応じたファイルシステムを選択するためには、機能要件を満たし、パフォーマンスとコストを評価し、その結果をバランスよく考慮して、最適なファイルシステムを定義する必要があります。AWS マネージドのファイルシステムと、AWS Mainframe Modernization サービス、クラウドネイティブのランタイム環境を組み合わせることで、オンデマンドで数分で環境をすばやく作成し、アプリケーションとファイルシステムの最適な構成をテストできます。チュートリアルに従って、マネージドサービスを自分で試し、AWS のクラウドネイティブランタイム環境を構築することができます。

翻訳はプロフェッショナルサービス本部の葉山が担当しました。

著者紹介

Amazon Web Services ブログ