メインフレームのリプラットフォーム: AWS 上の Rocket Software のベストプラクティス

レガシーメインフレームアプリケーションは、企業全体の重要な事業運営のバックボーンの一部ですが、これらのシステムにはモダナイゼーションに関する重大な課題があります。メインフレームは何十年にもわたって信頼性が証明されてきましたが、多額の技術的負債を蓄積し、専門知識の需要はますます少なくなり、迅速なイノベーションと機能の導入を妨げています。AWS Mainframe Modernization with Rocket Software は、お客様が切望していたこれらのレガシーアプリケーションの知的財産を元のソースコードのまま維持するための戦略的ソリューションを組織に提供します。このソリューションにより、企業は貴重な既存のビジネスロジックを維持し、運用の継続性を維持しながら、運用コストを削減し、開発サイクルを加速し、最新の開発ツールと方法論を活用できます。AWS でモダナイズすることで、企業はレガシーインフラストラクチャを、将来の成長とイノベーションをサポートするアジャイルなクラウドネイティブシステムに変えることができます。このガイドでは、ビジネス目標、リスク評価、ROI タイムラインに基づいて、AWS で Rocket Software を使ったリプラットフォームの実装に焦点を当てています。ワークロードの計画、移行、検証を最初から最後まで成功させるための 7 つの具体的なベストプラクティスを紹介します。このブログ記事では、標準化された環境、Field-Developed Solutions (FDS) の特定、コード互換性の修正、データ移行戦略、AWS での包括的なテスト手順などのベストプラクティスを紹介します。

ベストプラクティス 1: 移行先アーキテクチャの定義

システム分析および設計文書（System Analysis and Design Document: SA&DD）は、スコープ漏れの管理、テスト作業の軽減、市場投入までの時間の短縮に役立つ重要なプロジェクト成果物です。SA&DD は、以下をマッピングして包括的なターゲットソリューションを定義します。

ハードウェアの仕様と要件
システムサービスと構成
プログラミング言語と開発ツール
サードパーティーのアプリケーションおよび連携 (以下はその一例です)
- データベース管理システム (セルフマネージドシステムと Amazon RDS の両方: Db2 LUW、PostgreSQL)
- ジョブスケジューリングツール
- レポート生成ソフトウェア
- ファイル転送ユーティリティ (SFTP、FTP)
- メールシステム (SMTP)
開発サーバーとエンタープライズサーバー構成
データ移行戦略と計画
コンプライアンスおよび規制要件
セキュリティ管理と監視アプローチ
ソースコードのインベントリと可用性の評価
外部システムとの連携ポイント
パフォーマンス要件とサービスレベル契約 (SLA)

SA&DD は移行プロジェクトの設計図の役割を果たすため、すべてのステークホルダーが移行先アーキテクチャと技術要件を明確に理解できます。プロジェクトライフサイクルの早い段階で潜在的なリスクと技術的ギャップを特定し、積極的な緩和戦略を立てるのに役立ちます。SA&DD の作成の一環として、完全な静的分析を行い、すべてのコンポーネントのインベントリを作成します。コンパイラおよびコンパイラ指令(ディレクティブ)の互換性を検証して文書化し、リスクがあれば文書化します。専任チームを割り当て、発見事項に対処し、コードベース全体に体系的に修正を適用します。これらのステップにより、コーディング標準への準拠が保証され、メンテナンスの必要性が軽減され、下流でのデプロイメントの問題が防止されます。

ベストプラクティス 2: 標準化された Development 環境と Enterprise Server 環境の構築

標準化された開発環境の目標は、すべての開発者に一貫したテンプレートを提供することです。標準化された環境では、ディレクトリ構造とコンパイラ指令を含むプロジェクトプロパティの両方が定義されるため、すべての開発者が同じ条件で作業し、コードが一貫してコンパイルされます。

Rocket Enterprise Developer (ED) と Rocket Enterprise Server (ES) の標準セットアップ

AWS 上の Rocket Enterprise Developer (ED) と Enterprise Server (ES) 向けに、バージョン管理されたゴールデンセットアップを作成します。Amazon EC2 イメージで特定のバージョンを指定し、標準構成として環境を構築します。
ソースコントロールのコンパイラ指令 (例: DIALECT/ARITH/TRUNC、コードページ) や、リンクオプション、およびビルドステップはそのまま使用します。これにより、CI が構成のずれを検出しても、一貫したツールチェーン設定が可能になります。

マスター Enterprise Server (ES) リージョンの作成

Rocket Directory Server と Enterprise Server Common Web Administration 用の Infrastructure as Code を使用してマスター ES リージョンを作成し、すべての CICS/IMS/JES リソース、データセット、セキュリティ、ミドルウェアを定義します。環境固有の設定には AWS Systems Manager と AWS Secrets Manager を使用して、このテンプレートを QA (Quality Assurance) / UAT (User Acceptance Test) 環境に複製します。トラフィック管理用に Network Load Balancer を実装します。一貫性のある環境を確保し、更新を簡素化できるようにするため、メンテナンスに Amazon CloudWatch を AWS Systems Manager を使います。

ベストプラクティス 3: 要件を識別して Field Developed Solutions (FDS) を活用する

FDS (Field Developed Solutions) は、Rocket Software Enterprise Server とサードパーティ製品間の技術ギャップを解消することで、他社製品とをつなぐ架け橋となるソリューションです。分析中、チームはこれらのプラットフォーム間の適切な統合を可能にするためにどの特定の FDS が必要かを特定します。特定すると、該当の FDS を購入し、インストールし、ターゲット環境で一通りテストし、正しく機能することを確認します。カスタムプリンタソリューションなど、標準の FDS が存在しない特別な状況では、Rocket Software のアーキテクトがデリバリーチームと直接協力して、独自の要件を満たす新しいカスタム FDS を開発するためのオプションを検討し、評価することがあります。

ディスカバリーフェーズで FDS を特定するメカニズム

棚卸しとディスカバリー (Enterprise Analyzer (EA) の標準レポートを使用)

プログラムの量、使用されているテクノロジー、複雑さなど、全体的なポートフォリオを把握するには、Application Inventory や Application Summary などの Executive Reports から始めてください。特殊なテクノロジーや例外値の指標は、自社開発のコンポーネントを示している可能性があります。
Inventory Reports を確認すると、COBOL、PL/I、ジョブ制御言語 (JCL) などの言語間で検証済みのファイル数とコード行数 (LOC) を比較できます。JCL が参照している内容と EA が検証できる内容との間に相違がある場合、カスタムユーティリティやコピーブックがベースラインから除外されているケースがよく見られます。
Verification and Reference Reports、特に Missing Files と Unresolved References を使って、解決されないコピーブック、呼ばれているプログラムや JCL プロシージャ (PROC) を一覧表示します。頻繁に参照される未解決の項目は最優先項目として扱います。
JCL Support がプロシージャ、コントロールカード、ユーティリティエイリアスを解析できるようにします。レポートをスキャンして、非標準のユーティリティ名、カスタムプロシージャの命名パターン、データセット識別子に着目し、社内で開発された固有のジョブやライブラリを示す兆候が無いか調べます。
EA で Portability Assessment を実行して、プログラミング言語の方言特有の特徴や標準外の構成要素など、所見や注目ポイントを指摘します。これらの調査結果は、特別な処理を必要とするカスタムルーチンと相関している可能性があり、FDS の強力な指標となります。

Enterprise Analyzer の Code Search を使用したパターンベースの検索

Enterprise Analyzer の Code Search を使用すると、検証済みのソースファイルをすべてスキャンして FDS が必要なパターンがないかどうかを確認できます。あらかじめ定義されたカテゴリから始めて、カスタムクエリを追加します。
Analyzer ワークスペースから Code Search を実行するか、ポートフォリオ全体で繰り返し検出できるように複数のクエリをまとめた Custom Code Search Report を作成します。詳細については、“Analyzing Programs – Staging Program Analysis with Code Search” を参照してください。たとえば、どの SORT パラメータが使用されているかを調べてください。これは、たとえば SORT パラメータに IFTHEN や JOINKEYS が含まれている場合に役立ちます。

ステークホルダーのインプット

社内ツールについて、開発者と運用チームにヒアリングします。
可能な場合は、社内ツールを補完する Rocket Enterprise Developer の同梱ツールや新機能を活用します。
社内で開発されたカスタムユーティリティについては、変更管理履歴を確認して参照します。

一般的な FDS の例:

SORT: Rocket Software の外部 SORT を拡張して、追加の DFSORT オプションと Syncsort オプションをサポートできるようにします。
Simple Mail Transfer Protocol (SMTP): JCL と SMTP を連携してメール送信機能を提供します。
Secure FTP (SFTP): JCL にほとんどまたはまったく変更を加えずに、メインフレーム JCL FTP ステップを SFTP にマッピングするために必要なサポートを提供します。

Rocket Software には、SAS などのサードパーティ言語を統合した FDS がいくつか用意されています。Rocket Software のすべての FDS の一覧をご覧ください。

ベストプラクティス 4: 移行を成功させるためのソースコードの準備

コードデプロイメントは、メインフレームからアプリケーションのソースコードを取り出し、ターゲットの Rocket Software ランタイム環境でビルド、デプロイ、テストするプロセスです。これには、COBOL コードの再コンパイルと、Enterprise Server でサポートされていない言語 (アセンブラなど) のコード変換が含まれます。再コンパイルする前にソースコードの完全性をチェックし、アプリケーションモジュール、コピーブック、JCL/PROC、マクロ、ユーティリティを含むすべてのソースコードが使用可能であることを確認します。

ソースに埋め込まれた 16 進数

チームは 16 進リテラルを使用してバイナリフラグとビットマスク (COMP、COMP-5、BINARY) の設定、パック 10 進数 / COMP-3 フィールドの初期化、レコード分離用の非表示制御文字の挿入、コードページ固有の表示値の表現を行います。移行の課題は、メインフレーム (EBCDIC) とターゲット環境 (ASCII) のコードページの違いから生じます。たとえば、数字の 0 は EBCDIC では X’F0’、ASCII では X’30’ なので、COBOL ステートメント MOVE X’F0F1′ TO ALPHA-FIELD はメインフレームに 01 と表示されますが、正しい ASCII 表示には読み替えが必要です。同様に、EBCDIC レコードセパレータ X’15’ は ASCII ラインフィード X’0A’ とは異なります。すべての環境のエンコーディング標準を SA&DD に文書化します。

ターゲットとなるエンコーディング戦略を決定して文書化します。EBCDIC をそのまま使用する場合は、データセットとリテラルを EBCDIC に保存し、ファイルハンドラーまたは CCSID を明示的に設定します。ASCII または Unicode を採用する場合は、明確に定義された I/O 境界でのみ変換し、表示テキストを表す 16 進数をポータブルリテラル (たとえば 01) または共有コピーブックのエンコーディング対応定数に書き換えます。
16 進数は真のバイナリデータおよびパック形式データ (フラグ、ビットマスク、COMP-3) に限定し、コードコメントや設計成果物にその意図を文書化します。Kiro CLI を使用して、バイナリの可能性があるフィールドを特定し、そのフィールドに関するユニットテストを生成または更新し、Rocket Enterprise Server ランタイムの数値動作がメインフレームのベースラインと一致することを検証します。
16 進数の検出と分類を自動化します。Kiro CLI によるリポジトリ全体にわたる検索を使用して X’.. ‘ などのパターンを特定し、エージェントに使用パターン (表示、パック形式、制御文字) ごとに出現箇所をグループ分けさせ、直接読み替え (テキスト用) または現行のまま維持 (バイナリ用) のいずれかを提案させます。正しい結果が得られるとわかっている小さな入力ファイルを使用して翻訳経路を end-to-end で検証します。表示フィールドが一度だけ翻訳されるのに対し、バイナリフィールドはプラットフォーム間でバイトが同一であることを確認します。
翻訳経路を反復可能なワークフローとしてテストします。データセットとコードページの設定、コピーユーティリティ、ミドルウェアを検証して、二重翻訳や翻訳スキップがないことを確認します。Kiro CLI エージェントは、コマンドラインから既存のユーティリティと比較ツールを呼び出し、ログや差分をキャプチャして、リグレッションやカットオーバーのリハーサル中に再実行できる反復可能なレシピにパッケージ化することで、これらのチェックを調整できます。

緩いコーディング基準で実装されたソースコード

レガシーアプリケーションが寛容なメインフレームコンパイラの動作 (またはショップ固有の拡張機能) に依存していて、より厳しい Rocket コンパイラでは拒否されることがよくあります。コンパイル時によくある問題には、スコープターミネーターの欠落、固定形式の間違い、一貫性のない符号処理、非標準動詞、MOVE CORRESPONDING、未解決の COPY REPLACING、TRUNC/ARITH の違いなどがあります。
これらの問題を軽減するには、メインフレームの動作をエミュレートするようコンパイラーディレクティブの組み合わせをプロファイルとして確立し、コンパイル時に適用します。スコープ、フォーマット、PIC のチェック用の整形ルールと継続的インテグレーション (CI) ルールを追加します。非標準構成を移植可能な同等の構成に置き換えます。数値フィールドとパックフィールドのユニットテストを実装して、回帰事象を早期に検出します。

COBOL 標準の進化

COBOL 言語標準は時間の経過とともに進化し、新しい構文や予約語が次々と追加されてきました。たとえば、ANSI COBOL 85 が組み込み関数を導入したことで、「FUNCTION」は予約語になりました。場合によっては、コンパイルディレクティブを調整することでこれらの違いを緩和できることがあります。Rocket Software の「REMOVE」ディレクティブでは、予約語をデータ項目として使用できます。たとえば、「REMOVE (FUNCTION)」を使用すると、期待どおりの機能を維持しながらコンパイルできます。

コマンドライン (Kiro CLI) で Kiro を使用して作業を加速

Kiro CLI を活用して、自動化されたコード取得、変換、デプロイのワークフローをコマンドラインから直接調整することで、メインフレームのモダナイゼーションを加速します。Kiro CLI は、再コンパイル作業を効率化し、非互換性 (サポートされていないアセンブラ呼び出しなど) を早期に明らかにし、Rocket Softwareのランタイムを一貫してターゲットにすることで、移行の各スプリントをすぐにデプロイ可能なソースコードから開始できるようにします。追加情報については、Kiro CLI (旧 Amazon Q CLI) によるコンパイルの高速化に関する記事 Revolutionizing Mainframe Replatforming with Amazon Q CLI を参照してください。

ベストプラクティス 5: 広範囲にわたるテストが成功のカギ

包括的な統合テストとシステムテストを実行しながら、正確なトポロジ、セキュリティ構成、データエンコーディング、ミドルウェアコンポーネントの機能を再現することで、本番環境を反映した AWS 環境を開発します。

メインフレームのベースラインの確立

定常状態とピーク状態の両方を網羅した、現在のシステムの動作とパフォーマンス指標の包括的なベースライン測定値を確立します。すべてのコンポーネントのスループット、レイテンシー、ストレージの物理 I/O の正確な測定値を文書化します。このベースラインには、メインフレームシステムの詳細な指標を含める必要があります。具体的には、システム管理機能 (SMF) レコード、バッチ処理件数の合計値、クリティカルパスジョブのタイミング、I/O ボリューム、インターフェイスレイテンシーの収集などです。この情報は、AWS への移行が成功したかどうか検証するための決定的な基準となります。ベースラインテストでは、運用範囲全体をカバーする end-to-end の検証を実施します。すべてのジョブ制御言語（JCL）プロシージャを含むバッチスケジュール全体を実行し、すべてのオンライン画面とサービスをテストし、インバウンドとアウトバウンドの両方のインターフェイスを検証し、サードパーティコンポーネント連携（印刷サービス、電子メールシステム、メッセージキュー、スケジューラーを含む）を検証し、Enterprise Server (ES) のセキュリティコントロールを確認し、包括的なデータ移行を実行してタイミングベースラインを確立します。ピーク負荷状態やエッジケースを含め、すべての結果を統計的に有意な形で文書化して、AWS の実装と比較できるように完全なパフォーマンスプロファイルを確認します。自動テストフレームワークを使用して測定の一貫性と再現性を確保し、パフォーマンスメトリクスに影響を与える可能性のあるすべてのテスト条件と環境要因の詳細な記録を維持します。

統合テスト

共用の統合テスト用 Enterprise Server (ES) リージョンまたはローカルの開発用 ES 環境でテストを実行します。エンコーディング選択 (EBCDIC / ASCII)、データセットカタログ、接続設定など、本番環境の設定を正確に複製します。欠陥に対処する際は、可能な限り、標準化された COBOL コンパイラ指令プロファイルを通じて修正を実施してください。これにより、それ以降のビルドでは、数値セマンティクスや符合ルールなどの重要な要素にわたって一貫した動作が維持されます。標準化すべきその他の重要な要素には、想定される CCSID、ファイル編成、レコード区切り文字の処理などがあります。この標準化されたアプローチは、環境特有の問題を防ぎ、すべての環境で再現可能な動作を保証します。

一般的な課題の例

データ形式: メインフレームが別のメインフレームとの間でデータを送受信する場合、可変長ブロック化 (VB) ファイルを直接送信できます。メインフレームが VB ファイルを分散プラットフォームに送信しても、Rocket Software が処理できる VB 形式では届きません。これには、Rocket Field-Developed Solution (FDS) のレコード形式変換ソリューション、もしくは、ETL (Extract, Transform, Load) ツールのカスタム開発が必要です。
文字セットの変更: 分散プラットフォームがメインフレームにデータを送信すると、メインフレーム上の FTP サーバーによって文字セットが ASCII から EBCDIC に自動的に変換されます。同じファイルが ES 環境に送信されても、この文字セット変換機能はありません。Rocket FTP FDS は、組み込みの文字セット変換機能を使用してアウトバウンドデータ転送を処理します。ただし、外部プラットフォームからのインバウンド転送には、文字セット変換のための追加の処理ステップが必要です。

機能的同等性テスト

システムテストでは、統合テストの完了後に機能的同等性を大規模に検証する必要があります。本番レベルのデータ量を使用して、AWS でそのままバッチポートフォリオを実行します。機能的に同等になり、SLA を満たすまで、すべてのアウトプットをベースラインのメトリックスと比較します。カレンダー、依存関係、タイムゾーンルールを明記した詳細な計画文書を作成しましょう。リスタートの手順、リランする際の作業順序、および文書化された移行手順を含めます。移行前後の違いに合わせた最適化を開始する前に現状のままテストを実行することで、環境の違い、エンコーディングの問題、I/O のばらつきを特定するのに役立ちます。スケジューラーの移行には早期に対処し、初期テストではレガシースケジューラーと連携するブリッジ機能またはプラグインを使用して AWS ワークロードを連携動作します。安全な接続経路や、カレンダー機能、リスタート機能がレガシープラットフォームにない場合は、早期の移行を検討します。シャドウ実行または並列実行により、スケジューラーの同等性を検証します。カットオーバー前にモニタリング、アラート、リカバリの手順を練習します。運用が安定したら、機能的な変更を実施せずプラットフォーム移行から切り離したままで、ジョブフローを合理化して重複を排除します。

パフォーマンステスト

パフォーマンステストでは、移行したアプリケーションが移行元システムのベースラインメトリクスを満たしているか、上回っているかを検証する必要があります。テストは、スループット率、レスポンス遅延、リソース使用量という 3 つの主要分野に焦点を当てます。すべてのテストは、実稼働規模のデータ量とワークロードパターンを使用して実行し、正確なパフォーマンス比較を行います。

ベースライン指標

メインフレームの SMF/RMF レコードとジョブアカウンティング指標を使用してパフォーマンスベースラインを確立する
クリティカルパスのタイミングと I/O 量を参考ベンチマークとして文書化する
ピーク時のワークロードパフォーマンス特性とトランザクション応答時間を把握する

ストレージパフォーマンス

ワークロードパターンに基づいて Amazon EFS スループットモード (Elastic / Provisioned) を設定する
Amazon EBS io2/io1 ボリュームを I/O 負荷の高いバッチ処理に活用する
EFS メトリクスの監視: TotalIOBytes, PermittedThroughput, BurstCreditBalance
EBS メトリクスのトラッキング: IOPS, Throughput, Queue Length, Volume Status
詳細については、「AWS Mainframe Modernization のファイルシステム選択」を参照してください。

コンピュートパフォーマンス

EC2 メトリックス (CPU 使用率、ネットワーク I/O、メモリ使用量) の監視と取得
ワークロードの特性 (コンピューティング最適化 / メモリ最適化 / ストレージ最適化) に基づいてインスタンスタイプを最適化する
ストレージを大量に消費する運用の場合は EBS 最適化インスタンスのパフォーマンスを追跡する
詳細については、Scaling for performance with AWS Mainframe Modernization and Micro Focus をご覧ください。

検証プロセス

完全な JCL プロシージャを含む包括的なバッチスケジュールテストを実行する
確立された SLA に照らしてパフォーマンスを監視し、検証する
ジョブの完了時間、リソース使用率、スループット率を追跡する
自動化されたパフォーマンス回帰テストを実施して、一貫した評価を行う

対象分野の専門家 (Subject Matter Expert: SME) による承認

SME は、重要なアウトプットと例外パスを検証する必要があります。さらに、承認が迅速に行われ、透明性があり、監査可能になるよう、照合結果のレポートや、そのタイミング、差分は自動的に提供されるべきです。

ベストプラクティス 6: 一般的なツールを活用して移行を加速

Mainframe Access ツール (MFA)

Rocket Software の MFA は、ユーザーフレンドリーなドラッグアンドドロップインターフェイスと、メインフレームと他のシステム間で複数のデータセットをプルおよびプッシュできるバッチ処理システムの両方を提供します。これにより、FTP ジョブを実行してメインフレームから移行先プラットフォームにファイルをプッシュする必要がなくなります。たとえば、MFA を使用して区分データセット (PDS) ライブラリ、JCL、コントロールカードにアクセスし、インベントリを取得できます。さらに、テスト用のデータセットのダウンロードにも使用できます。
MFA は双方向で動作するため、テスト出力ファイルをメインフレームに送り返して、メインフレームが生成した出力と比較することができます。プロジェクトチームは使い慣れたメインフレームの SuperC ユーティリティを引き続き使用して、即時の検証を実施しつつ、移行先環境で新しいツールを徐々に習得できます。

Data File Converter (DFCONV)

Rocket Software のバッチデータファイルコンバーターである DFCONV は、EBCDIC と ASCII 間の変換など、さまざまな形式間のファイル変換に使用されます^※。これにより、移行したデータセットを ES で使用できるようになります。ワークフローは MFA のバッチまたはコマンドラインインターフェイスを使用してメインフレームからソースデータセットをダウンロードし、DFCONV を使用して必要な形式に変換します。

(※) 訳注: IBM 日本語文字セット (コードページ 930, 939, 1390, 1399) は直接扱う場合に制約がある可能性あり

統合開発環境 (IDE)

Eclipse は、特に Linux プロジェクトの開発とテストのための主要なプラットフォームです。社内標準によって、開発者はマイクロソフトの Visual Studio または VS Code を選択することもあります。Rocket Enterprise Developer と Visual COBOL はどちらも Eclipse や VS Code とシームレスに統合されています。これらの開発者ツールは、Windows 環境と Linux 環境での編集、コンパイル、デバッグをサポートします。

ベストプラクティス 7: 包括的なデータ移行戦略の策定

統合テストデータおよびシステムテストデータを特定する (テスト可能で反復テスト可能なものにする)

統合テストと end-to-end のシステムテストをサポートするために必要なすべてのデータは、できるだけ早く特定する必要があります。現新照合テストを容易にするためには、システムテスト環境をメインフレームと何度か同期させる場合が多いです。

EBCDIC もしくは ASCII いずれでデータを保持するか早い段階で判断する (そしてその方針を変えない)

EBCDIC と ASCII のどちらを選択するかは、データ変換プロセス、アプリケーションの互換性、潜在的なパフォーマンスオーバーヘッドに影響します。EBCDIC を維持することで移行の複雑さを軽減し、正確なデータ表現を維持できますが、ASCII を採用することで最新のプラットフォームやツールとの統合が容易になります。この決定を下す際には、組織固有のアプリケーション要件、データ特性、長期的なモダナイゼーション目標を考慮して、これらの要因を慎重に検討する必要があります。

データレプリケーション計画とカットオーバータイムライン (「移行ウィンドウ」が意味するものを念頭に)

この目標設定は変動が大きく、カットオーバーがいつ行われるかに大きく依存します。データが特定されたら、データの移行に必要な時間の見積もりを行う必要があります。その結果、カットオーバーで利用できる許容可能なダウンタイムを超える時間が発生する可能性があります。その場合は、データカットオーバーの開始日と実際の稼働日に基づいて、静的データと動的データを判断します。静的データは、メインフレーム上で変更されるリスクなしに、本番稼働までの数日または数週間で移行できます。動的データは、本番稼働日に移行する必要がある残りのデータです。end-to-end の移行リハーサルを 2 回以上実行し、移行ウィンドウに対して 20 ～ 30% のバッファーが得られるまで計画を調整します。

履歴データの保存とアクセス (事前移行と事後移行 — いずれにするか選ぶ方法)

多くのお客様が、長年にわたる履歴データを維持することが規制上または法律上の要件となっています。このような履歴データはターゲット環境に移行する必要があります。履歴データの量が多い場合は、運用開始の前または後に履歴データを移行することを検討します。

物理ファイルの移行 (フォーマット、ハンドラー、ツール) — 知っておくべきこと

テキスト以外のデータを含むファイル (COMP や COMP-3 フィールドを含むファイルなど) には、構造ファイルと呼ばれるものが必要です。これはデータファイル内のデータを解釈して表示する方法を定義するもので、Rocket の構造ファイルエディタを使用して作成されます。構造ファイルはコピーブックとコンパイルされたプログラムに基づいて作成されますが、同じ物理ファイル内に複数のレイアウトを含むファイルでは構造が条件付きになるため、複雑さが増します。これらの構造は EBCDIC から ASCII への変換時に使用されます。

データベース移行 (カットオーバーのリスクを最小限に抑えるための戦略的な選択肢)

移行対象のデータベースエンジンを選択するときは、互換性の重要度、コストに関する考慮事項、チームスキル、および長期的な柔軟性のニーズに基づいて、選択肢を慎重に評価します。機能マッピング、データ型変換、コードページを漏れなく文書化し、移行の整合性を確保するために検証クエリを開発することが不可欠です。Db2 LUW (Linux, UNIX, and Windows) は、ベンダーへの依存と柔軟性の低下を伴いますが、メインフレーム Db2 に最も近い動作を実現し、コード変更が少なくて済み、移行リスクも軽減されます。一方、PostgreSQL には、ライセンス料ゼロ、強力な SQL 標準準拠、JSON サポートなどの最新機能、優れたクラウド柔軟性など、大きな利点があります。ただし、Db2 固有の機能のマッピング、潜在的なチームスキルの向上、動作が異なるアプリケーションの変更が必要になります。他に実行可能なマイグレーションパスとしては、Microsoft SQL Server 用や Oracle 用の Host Compatibility Option を使って Db2 スキーマ/データ移行とメインフレーム動作エミュレーションを実現する方法もあります。他に利用できるデータベースオプションについては、Rocket Software に確認してください。

検証とガバナンス

効果的な検証とガバナンスを行うには、エンコーディングを考慮したファイル比較、行単位の比較、コントロール全体の比較、対象を絞ったビジネスクエリ、タイミングデルタの注意深い分析など、移行プロセス全体にわたる統制チェックが必要です。組織は、包括的なマニフェスト、チェックサム、詳細なレポートを保存し、導入前に何度も移行リハーサルを行う必要があります。最も重要なのは、検証ゲートが満たされないまま本番稼働することが無いよう明確な基準を確立し、データの整合性とシステムの信頼性を確保することです。

結論

リプラットフォームしましょう。メインフレームから AWS へのリプラットフォームによる移行は、単なる技術的な移行ではなく、戦略的な進化を表しています。本ブログで紹介した 7 つのベストプラクティスに体系的に従うことで、組織はリスクを最小限に抑え、事業継続性を確保しつつ、メインフレームから AWS へのインフラストラクチャのトランスフォーメーションを成功させることができます。

Amazon Web Services ブログ