AWS Mainframe Modernization Service (マネージドランタイム環境エクスペリエンス) は、2025 年 11 月 7 日以降、新しいお客様に公開されなくなります。サービスを使用する場合は、2025 年 11 月 7 日までにサインアップしてください。AWS Mainframe Modernization Service (マネージドランタイム環境エクスペリエンス) と同様の機能については、AWS Mainframe Modernization Service (セルフマネージドエクスペリエンス) をご覧ください。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、AWS 「 Mainframe Modernization の可用性の変更」を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS Blu Age ブルーサム

メインフレームシステム (以降のトピックでは「レガシー」と呼びます) では、ビジネスデータは VSAM (仮想ストレージアクセス方法) を使用して保存されることがよくあります。データは "データセット" に含まれる "レコード" (バイト配列) に保存されます。

データセット組織には次の 4 つがあります。

AWS Blu Age リファクタリングアプローチを使用してレガシーアプリケーションをモダナイズする場合、モダナイズされたアプリケーションは、データアクセスロジックを維持しながら VSAM ストアドデータにアクセスすることを意図しなくなりました。Blusam コンポーネントが答えです。レガシー VSAM データセットのエクスポートからデータをインポートでき、モダナイズされたアプリケーションが専用の管理ウェブアプリケーションとともに操作するための API を提供します。「AWS Blu Age Blusam管理コンソール」を参照してください。

Blusam API を使用すると、データアクセスロジック (シーケンシャル、ランダム、相対読み取り、レコードの挿入、更新、削除) を保持できます。一方、コンポーネントアーキテクチャは、キャッシュ戦略と RDBMS ベースのストレージの組み合わせに依存するため、限られたリソースで高スループットの I/O オペレーションが可能になります。

Blusam インフラストラクチャ

Blusam は、未加工レコードデータとキーインデックス (該当する場合) の両方について、データセットストレージの PostgreSQL RDBMS に依存します。お気に入りのオプションは、Amazon Aurora PostgreSQL 互換エンジンを使用することです。このトピックで示す例および図は、このエンジンを使用した場合のものです。

キャッシュ

ストレージ自体に加えて、 はキャッシュ実装と組み合わせるとより高速にBlusam動作します。

現在、EhCache と Redis の 2 つのキャッシュエンジンがサポートされており、それぞれのユースケースは次のように異なります:

ロック

データセットとレコードへの同時アクセスを処理するために、 Blusamは設定可能なロックシステムに依存します。ロックは、データセットとレコードのレベルで適用されます:

Blusam ロックシステムの設定は、キャッシュ設定に応じて行う必要があります。

Blusam 組み込みとレガシーからのデータ移行

データセットの保存: レコードとインデックス

各レガシーデータセットBlusamは、 にインポートされると専用テーブルに保存されます。テーブルの各行は 2 つの列を使用してレコードを表します。

CardDemo アプリケーションで使用される KSDS データセットの内容の例を次に示します:

データセットのメタデータとキーインデックスについて: 各データセットは、metadata という名前のテーブルの 2 つの行に関連付けられます。これはデフォルトの命名規則です。カスタマイズ方法については、「Blusam の設定」を参照してください。

また、大規模または超大規模のデータセットインデックス (該当する場合) は、ページ分割メカニズムを使用して保存され、インデックスページのバイナリシリアル化データが専用テーブル (データセットキーごとに 1 つのテーブル) の行に保存されます。インデックスの各ページは、次の列を持つ行に保存されます。

テーブル名は、データセット名とキー内部名をつないで作成されます。この名前には、キーのオフセット、キーが重複を許可するかどうか (許可する場合は true に設定)、キーの長さなど、キーに関する情報が含まれます。例えば、"AWS_LARGE_KSDS" という名前のデータセットに次の 2 つのキーが定義されているとします:

この場合、2 つのキーに関連するインデックスが次のテーブルに保存されます。

ライトビハインドメカニズムを使用した I/O スループットの最適化

挿入/更新/削除オペレーションのパフォーマンスを最適化するために、Blusamエンジンは設定可能な書き込みビハインドメカニズムに依存します。このメカニズムは、一括更新クエリを使用して永続化オペレーションを処理する専用スレッドのプール上に構築され、Blusamストレージへの I/O スループットを最大化します。

Blusam エンジンは、アプリケーションによってレコードに対して実行されるすべての更新オペレーションを収集し、処理のためにディスパッチされるレコードのロットを専用スレッドにビルドします。その後、一括更新クエリを使用して、ロットがBlusamストレージに保持され、アトミック永続化オペレーションの使用が回避され、ネットワーク帯域幅の最適な使用が保証されます。

このメカニズムで、遅延 (デフォルトは 1 秒) とロットサイズ (デフォルトは 10,000 レコード) を設定することができます。永続性クエリは、次の 2 つの条件のうちいずれかの条件が満たされるとすぐに作成されます。

ライトビハインドメカニズムの設定方法については、「オプションプロパティ」を参照してください。

適切なストレージスキームの選択

前のセクションで説明したように、データセットの保存方法は "重量" に合わせて選択します。しかし、何を基準にデータセットの小、中、大を判断するのでしょうか? ストレージをページ分割する方法はどのような場合に選択するのでしょうか?

これらは次に応じて判断します。

非ページ分割のインデックスストレージスキームを使用する場合、すべてのキーインデックスとレコードを集めたサイズが、データセットをオープンするときに、サーバーのメモリに毎回読み込まれます。また、キャッシュを処理する場合は、すべてのデータセットレコードが通常の方法でキャッシュに事前に読み込まれるため、キャッシュのインフラストラクチャ側のメモリリソースが枯渇する可能性があります。

消費されるメモリの量を、定義したキーの数、キー値の長さ、レコードの数、同時にアクセスするデータセットの数、そしてユースケースごとの知識を考慮しながら、おおまかに評価しておくとよいでしょう。

詳細についてはデータセットのメモリフットプリントの見積りを参照してください。

Blusam 移行

特定のデータセットに対して適切なストレージスキームを選択したら、レガシーデータセットを移行してBlusamストレージに入力する必要があります。

そのためにレガシーデータセットの未加工バイナリをエクスポートしますが、これは文字セットを変換せずに行います。レガシーシステムからデータセットエクスポートを転送する際に、バイナリ形式が破損しないよう注意してください。例えば、FTP を使用する場合はバイナリモードを使用してください。

レコードのみを未加工バイナリ形式でエクスポートしてください。このインポートメカニズムでは、キーやインデックスをエクスポートする必要がありません。キーやインデックスはすべて、インポートメカニズムによってオンザフライで再計算されます。

データセットのバイナリエクスポートが利用可能になると、そのバイナリエクスポートBlusamを既存の に移行するためのいくつかのオプションがあります。

AWS Mainframe Modernization マネージド環境の場合：

or

or

Amazon EC2 の AWS Blu Age ランタイムの場合：

or

Groovy スクリプトを使用してデータセットをインポートする

このセクションでは、groovy スクリプトを作成してレガシーデータセットを にインポートする方法について説明しますBlusam。

最初にいくつかインポートする必要があります。

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry
import java.util.ArrayList; //used for alternate keys if any

その後、インポートするデータセットごとに、次のパターンでコードを作成します。

次の 5 つのサービス実装を、下記の識別子を使用して取得できます:

KSDS または ESDS に標準と大規模のどちらのバージョンのサービスを選択するかは、データセットのサイズや、適用するストレージ方法によって異なります。ストレージ方法を適切に選択する方法については、「適切なストレージスキームの選択」を参照してください。

データセットを に正常にインポートするにはBlusam、ロードサービスに適切なプロパティを指定する必要があります。

一般的なプロパティ:

データセットの種類に依存するプロパティ:

キーコンストラクタ呼び出し:

以下に、データ読み込みのさまざまなシナリオを示す Groovy サンプルを紹介します。

2 つの代替キーを使用した大規模な KSDS の読み込み:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry
import java.util.ArrayList;

// Loading a large KSDS into Blusam
def map = [:]
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", "largeKsdsSample");
map.put("inFilePath", "/work/samples/largeKsdsSampleExport");
map.put("recordLength", 49);
map.put("primaryKey", new Key(0, 18));
ArrayList altKeys = [new Key(true, 10, 8), new Key(false, 0, 9)]
map.put("alternateKeys", altKeys);
map.put("indexingPageSizeInMb", 25);
def service = ServiceRegistry.getService("BluesamLargeKSDSFileLoader");
service.runService(map);

代替キーを使用しない可変レコード長の ESDS の読み込み:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry

// Loading an ESDS into Blusam
def map = [:]
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", "esdsSample");
map.put("inFilePath", "/work/samples/esdsSampleExport");
map.put("recordLength", 0);
def service = ServiceRegistry.getService("BluesamESDSFileLoader");
service.runService(map);

可変レコード長のデータセットをエクスポートする場合は、読み取り時にレコードを分割できるように、Record Decriptor Word (RDW) 情報を含める必要があります。

固定レコード長の RRDS の読み込み:

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry

// Loading a RRDS into Blusam
def map = [:]
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", "rrdsSample");
map.put("inFilePath", "/work/samples/rrdsSampleExport");
map.put("recordLength", 180);
def service = ServiceRegistry.getService("BluesamRRDSFileLoader");
service.runService(map);

マルチスキーマモードでのデータセットのロード：

マルチスキーマモード: 一部のレガシーシステムでは、VSAM ファイルはファイルセットに整理されているため、プログラムは指定されたパーティション内のデータにアクセスして変更することができます。最新のシステムでは、各ファイルセットがスキーマとして扱われ、同様のデータパーティショニングとアクセスコントロールが可能になります。

application-main.yml ファイルでマルチスキーマモードを有効にするには、「」を参照してくださいBlusam の設定。このモードでは、ランタイム情報のインメモリレジストリである共有コンテキストを使用して、データセットを特定のスキーマにロードできます。データセットを特定のスキーマにロードするには、データセット名の前に関連するスキーマ名を付けます。

マルチスキーマモードの特定のスキーマに KSDS ファイルをロードする：

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry
import java.util.ArrayList;
import com.netfective.bluage.gapwalk.rt.shared.SharedContext;

// Loading a KSDS into Blusam
def map = [:]
String schema = "schema1";
String datasetName = schema+"|"+"ksdsSample";
SharedContext.get().setCurrentBlusamSchema(schema);
schema = SharedContext.get().getCurrentBlusamSchema();
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", datasetName);
map.put("inFilePath", "/work/samples/ksdsSampleExport");
map.put("recordLength", 49);
map.put("primaryKey", new Key(0, 18));
map.put("indexingPageSizeInMb", 25);
def service = ServiceRegistry.getService("BluesamKSDSFileLoader");
service.runService(map);

マルチスキーマモードの特定のスキーマにラージ KSDS ファイルをロードする：

import com.netfective.bluage.gapwalk.bluesam.BluesamManager
import com.netfective.bluage.gapwalk.bluesam.metadata.Key;
import com.netfective.bluage.gapwalk.rt.provider.ServiceRegistry
import java.util.ArrayList;
import com.netfective.bluage.gapwalk.rt.shared.SharedContext;

// Loading a Large KSDS into Blusam
def map = [:]
String schema = "schema1";
String datasetName = schema+"|"+"largeKsdsSample";
SharedContext.get().setCurrentBlusamSchema(schema);
schema = SharedContext.get().getCurrentBlusamSchema();
map.put("bluesamManager", applicationContext.getBean(BluesamManager.class));
map.put("datasetName", datasetName);
map.put("inFilePath", "/work/samples/LargeKsdsSampleExport");
map.put("recordLength", 49);
map.put("primaryKey", new Key(0, 18));
map.put("indexingPageSizeInMb", 25);
def service = ServiceRegistry.getService("BluesamLargeKSDSFileLoader");
service.runService(map);

さらに、設定エントリ (application-main.yml設定ファイルで設定) を使用してインポートプロセスを微調整できます。

Blusam の設定

設定は、application-main.yml設定ファイル (またはBlusam管理コンソール -- BAC -- アプリケーションのスタンドアロンデプロイ用のapplication-bac.yml設定ファイル) でBlusam行われます。

Blusam は、次の 2 つの側面で設定する必要があります。

Blusam ストレージとキャッシュアクセス設定

シークレットマネージャーまたはデータソースを使用してBlusamストレージとキャッシュへのアクセスを設定する方法については、「」を参照してくださいAWS Blu Age ランタイムの設定。

Blusam エンジン設定

Blusam サポートを無効にする

まず、 bluesam.disabledプロパティを に設定することで、Blusamサポートを完全に無効にできることに注意してくださいtrue。アプリケーションの起動時に、Blusam無効化を通知する情報メッセージがサーバーログに表示されます。

BLUESAM is disabled. No operations allowed.

この場合、 に関する追加の設定Blusamは必要ありません。Blusam関連する機能 (プログラムまたは REST 呼び出し) を使用しようとすると、Java コード実行UnsupportedOperationExceptionで が生成され、 に関する関連する説明メッセージが無効Blusamになります。

Blusam エンジンプロパティ

Blusam エンジン設定プロパティは、bluesam キープレフィックスの下に再グループ化されます。

必須プロパティ

オプションプロパティ

Blusam ロック: プロパティにはプレフィックスが付きます locks

ライトビハインドメカニズム: 以下のプロパティには write-behind キーのプレフィックスが付きます。

埋め込み EhCache の微調整: 以下のプロパティには ehcache キーのプレフィックスが付きます:

マルチスキーマ設定プロパティ

設定例:

dataSource:
  bluesamDs:
    driver-class-name: org.postgresql.Driver
    ...
    ...
bluesam:
  locks:
    lockTimeOut: 700
  cache: ehcache
  persistence: pgsql
  ehcache:
    resource-pool:
      size: 8GB
  write-behind:
    enabled: true
    threads: 8
    batchsize: 5000  
  pgsql:
    dataSource : bluesamDs 

サンプル設定スニペット ( でマルチスキーマモードが有効になっているBlusam):

dataSource:
  bluesamDs:
    driver-class-name: org.postgresql.Driver
    ...
    ...
bluesam:
  locks:
    lockTimeOut: 700
  cache: ehcache
  persistence: pgsql
  ehcache:
    resource-pool:
      size: 8GB
  write-behind:
    enabled: true
    threads: 8
    batchsize: 5000 
  multiSchema: true 
  pgsql:
    dataSource : bluesamDs
    schemas: 
      - "schema1"
      - "schema2" 
      - "schema3"
    fallbackSchema: schema3

Blusam 管理コンソール

Blusam 管理コンソール (BAC) は、Blusamストレージの管理に使用されるウェブアプリケーションです。BAC の詳細については、「AWS Blu Age Blusam管理コンソール」を参照してください。

付録

データセットのメタデータの一般的な属性

データセットのメタデータの一般的なシリアル化属性リスト:

データセットのメモリフットプリントの見積り

小または中規模のデータセットの場合、メタデータ (さまざまなキーのサイズとインデックス) はメモリにすべて読み込まれます。モダナイズされたアプリケーションの実行に使用されるサーバーをホストするマシンに適切なリソースを割り当てるには、Blusam特にメタデータに関して、データセットによって誘発されるメモリ消費量を把握する必要があります。このセクションでは、その実践的な方法を説明します。

指定された式は、「大規模」ストレージ戦略を使用するのではなく、Blusam小規模から中規模のデータセットにのみ適用されます。

Blusam データセットメタデータ

Blusam データセットの場合、メタデータは 2 つの部分に分割されます。

内部メタデータフットプリントの計算

レコードサイズマップ

まず、内部メタデータは、すべてのレコードのサイズ (整数値) を保持するマップを、その RBA (相対バイトアドレス - 長整数値) と一緒に格納します。

そのデータ構造では、メモリフットプリント (バイト単位) は 80 * number of records のように計算されます。

これはすべての種類のデータセットで同じです。

インデックス

KSDS のプライマリキーまたは ESDS と KSDS の代替キーのインデックスにおいて、フットプリントの計算は次の 2 つの要因によって変わります。

以下のグラフは、キーのサイズ (x 軸) に対する、レコードあたりのキーインデックスのサイズ (y 軸) を示しています。

これを基に、データセットの特定のキーインデックスのフットプリントは次の式で計算されます:

index footprint = number of records * ( 83 + 8 (key length / 8))

"/" は整数除算を表します。

例:

特定のデータセットのフットプリント合計は、すべてのキーインデックスのフットプリントと、レコードサイズマップのフットプリントの合計で計算します。

例えば、データセット 2 の例ではキーが 1 つだけですが、グローバルフットプリントは次のように計算されます。