AWS Mainframe Modernization

解決する課題

メインフレームは長年にわたり基幹業務を支えてきた一方で、専用ハードウェアと高額なライセンス、限られた技術者、改修のしづらさといった課題を抱えがちです。新しいハードへの更新コストや、COBOL などレガシー言語を扱える人材の確保が年々難しくなり、ビジネスのスピードを縛る要因になっています。AWS Mainframe Modernization は、こうしたメインフレーム資産を AWS のマネージドなランタイムへ移し、または近代的な言語へ作り替えることで、運用負荷とコストを下げながら既存の業務ロジックを生かし続けることを目的としたサービスです。

• 高額なメインフレームのハードウェアやライセンス費用を削減したい
• COBOL や PL/I を扱える技術者の減少に備え、保守しやすい環境へ移したい
• 長年蓄積した業務ロジックを捨てずにクラウドへ移行したい
• 移行の進め方やリスクが読めず、段階的に安全に近代化したい

主要概念と用語

• リプラットフォーム: 既存のコードをほぼそのまま動かせるよう、互換ランタイム上へ載せ替える方式。改修を最小限に抑えて短期間で移せる
• リファクタ（自動変換）: COBOL などのコードを Java といった近代的な言語へ自動的に書き換え、汎用的な環境で動かせるようにする方式
• アセスメント: 既存のソースコードや資産を分析し、規模・依存関係・移行の難所を可視化する工程。移行計画の土台になる
• ランタイム環境: 移行後のアプリケーションを実行するマネージドな実行基盤。アプリのデプロイ先となる
• アプリケーション定義: 移行したアプリをサービスに登録する単位。実行に必要な構成やリソースをまとめて管理する
• バッチとオンライン: メインフレーム特有の処理形態。夜間などにまとめて流すバッチ処理と、対話的に応答するオンライン処理の双方を扱う
• データレプリケーション / 変換: 階層型・固定長などメインフレーム特有のデータを、移行先で扱える形へ移す仕組み
• 開発・テストツール: 移行したコードの編集、ビルド、テストを支援する周辺ツール群

仕様・制限・クォータ

• 移行方式として、既存コードを生かすリプラットフォームと、近代言語へ作り替えるリファクタの二つを選べる
• 主に COBOL や PL/I といったメインフレームで広く使われてきた言語の資産を対象とする
• メインフレーム特有のバッチ処理とオンライン処理の双方をマネージド環境で実行できる
• 移行作業は「アセスメント → 移行・変換 → テスト → 本番運用」という流れで進む
• 対応する言語の細目、扱えるデータ形式、登録できるアプリケーション数などの上限はサービス側で定められており、大規模移行では事前確認が欠かせない

内部の仕組み

リプラットフォーム方式では、メインフレーム上の COBOL や PL/I のコードを大きく書き換えずに、AWS 側の互換ランタイムで実行できるようにします。既存の業務ロジックをそのまま生かせるため、改修リスクを抑えつつ短期間でクラウドへ載せ替えられるのが特徴です。一方のリファクタ方式では、レガシー言語のコードを Java などの近代的な言語へ自動的に変換し、汎用的なクラウド環境で動かせる形にします。長期的な保守性や人材確保のしやすさを重視する場合に向きます。

どちらの方式でも、移行の前段では既存資産を分析するアセスメントを行い、コードの規模や依存関係、移行上の難所を把握して計画を立てます。移行・変換のあとは、移行先で正しく動くかをテストで検証し、問題がなければマネージドなランタイム環境へデプロイして本番運用に移ります。バッチとオンラインの双方の処理形態を扱えるため、夜間バッチや対話型のオンライン業務をまとめて近代化できます。

設計パターン / ベストプラクティス

• アセスメントを起点にする: いきなり移さず、まず資産分析で規模と依存関係を可視化し、優先順位と方式を決める
• 資産ごとに方式を選ぶ: すべてを同じ方式に揃えず、リプラットフォームとリファクタを業務特性に応じて使い分ける
• 段階的に移行する: 影響範囲の小さい業務から先に移し、知見をためながら基幹業務へ広げてリスクを抑える
• テストを仕組み化する: 移行前後で結果が一致するかを検証する仕組みを用意し、業務ロジックのずれを早期に発見する
• データ移行を別途計画する: アプリだけでなく、メインフレーム特有のデータ形式の変換と移行も合わせて設計する
• 切り戻し方針を決める: 本番切替後に問題が出た場合の判断基準と手順を事前に準備しておく

運用・監視

• 移行したアプリケーションの稼働状態やランタイムの健全性は、コンソールや API で確認できる
• CloudWatch と連携し、アプリの稼働状況やリソースの状態を監視できる
• バッチ処理の実行結果やオンライン業務の応答を追跡し、移行前の挙動と差がないかを継続的に確かめる
• ログを集約し、エラーや想定外の挙動を早期に検知できる体制を整える
• 不要になった検証用リソースやテスト環境を片付け、ムダな課金を残さないようにする

コスト

• 主なコストは、移行後のアプリケーションを実行する**ランタイム環境（コンピュート）**の利用に対して発生する
• 移行や変換、テストの作業で一時的に使うリソースにも費用がかかるため、不要になったら速やかに片付ける
• メインフレームのハードウェアや専用ライセンスの費用から解放される点が、近代化による大きなコストメリットになる
• データ移行に伴うデータ転送やストレージの費用も合わせて見積もる
• 必要な処理能力に応じてランタイムの規模を調整し、過剰なリソースを抱えないようにする

セキュリティ

• アプリケーションやデータの保存時暗号化は KMS の鍵で管理できる
• 移行や運用での通信は転送時の暗号化を行い、業務データが平文で流れないようにする
• サービスの操作権限や、アプリが引き受けるロールは IAM で最小権限に絞る
• ランタイム環境は VPC 内に配置し、必要なネットワーク経路だけを開ける設計にする
• 基幹業務のデータを扱うため、アクセス記録を残し、誰が何を操作したかを追跡できるようにする

関連サービス・比較

サーバー丸ごとを移す AWS Application Migration Service（MGN） とよく対比されます。MGN は一般的なサーバーをディスクごとリフト＆シフトするのに対し、Mainframe Modernization はメインフレーム特有のコードやデータを互換ランタイムへ載せ替えたり近代言語へ作り替えたりする点が異なります。なお他クラウドにも同種のメインフレーム移行支援の取り組みはありますが、対象や方式の細部は各サービスで異なります。

ハンズオン / CLI例

# 登録済みのアプリケーション一覧を確認
aws m2 list-applications

# 移行先で動かすアプリケーションを作成（リプラットフォーム例）
aws m2 create-application \
  --name my-mainframe-app \
  --engine-type microfocus \
  --definition content="file://app-definition.json"

# 作成したアプリケーションをランタイム環境へデプロイ
aws m2 create-deployment \
  --application-id app-1234567890abcdef0 \
  --environment-id env-1234567890abcdef0 \
  --application-version 1

# デプロイ後のアプリケーションを起動して稼働を開始
aws m2 start-application \
  --application-id app-1234567890abcdef0