AWS Migration & Transfer Vol2｜MGN×Snow×Storage GW×MF

なぜ Migration & Transfer Vol2 か — 移行4層アーキテクチャ概観

Migration & Transfer を設計・運用するとき、「データを移す仕事」と「サーバ・物理資産を動かす仕事」は性質が根本的に異なる。前者はネットワーク越しの継続的なデータ転送が中心であり、後者は物理デバイスの輸送・エージェントによるブロックレベルレプリケーション・メインフレームのコード変換が中心となる。AWS はこの二軸を9つのサービスでカバーしており、二部作として整理すると全体像が見えやすくなる。

Vol1 でデータ転送基盤を構築し、本 Vol2 でサーバ本体・物理ストレージ・レガシーシステムを AWS へ移行することで、Migration & Transfer 二部作が完成する。

Migration & Transfer 統合4層アーキテクチャ概観（Mermaid01）

flowchart TD
  subgraph VOL1["Migration and Transfer Vol1 — データ移行軸"]
 DMS["DMS（DB継続レプリケーション）"]
 SCT["SCT（スキーマ変換）"]
 HUB["Migration Hub（進捗統合管理）"]
 TF["Transfer Family（SFTP/FTPS/FTP管理）"]
 DS["DataSync（S3/EFS高速転送）"]
  end

  subgraph L1["Layer 1: サーバ移行（エージェント型）— Vol2"]
 MGN_SVC["AWS Application Migration Service (MGN)<br/>エージェント配置 / Wave設計 / カットオーバー / ロールバック"]
  end

  subgraph L2["Layer 2: 物理輸送・エッジ — Vol2"]
 SNOW["AWS Snow Family<br/>Snowball Edge / Snowcone<br/>物理輸送ライフサイクル / クラスタ運用"]
  end

  subgraph L3["Layer 3: ハイブリッドストレージ統合 — Vol2"]
 SG_SVC["AWS Storage Gateway<br/>File / Volume Cached+Stored / Tape<br/>キャッシュサイジング / SMB・NFS認証"]
  end

  subgraph L4["Layer 4: メインフレーム近代化 — Vol2"]
 MF_SVC["AWS Mainframe Modernization<br/>Micro Focus / AWS Blu Age<br/>リファクタ / リプラットフォーム / Wave Group"]
  end

  VOL1 -->|"データ転送基盤確立後"| L1
  L1 -->|"サーバ移行完了後"| L2
  L2 -->|"物理データ取込完了後"| L3
  L3 -->|"ハイブリッド統合完了後"| L4
  L4 -->|"近代化完了"| AWS_NATIVE["AWS ネイティブ運用（フルクラウド移行達成）"]

上記 Mermaid01 は Migration & Transfer 二部作の統合4層アーキテクチャを示す。Vol1 がデータの流れを制御し、Vol2 がサーバ・物理資産・レガシーシステムの移行を担う。二部作を組み合わせることで、AWS への移行プロジェクトにおけるデータとインフラ両軸の設計が完成する。

Vol1 との役割分担

Vol1 と本記事 Vol2 は同一の Migration & Transfer サービス群を扱うが、主題が明確に異なる。

Vol1 を先に読んで「データを送る基盤」を習得し、本 Vol2 で「サーバ本体とレガシーシステムを動かす設計」を完成させるのが理想的な学習順序である。

本記事で獲得できる設計力

本記事 Vol2 を通じて以下の設計力を習得できる。

• (a) MGN でエージェント配置・Wave設計・launch template・カットオーバー手順・ロールバック戦略を確立する設計力
• (b) Snow Family で Snowball Edge/Snowcone 選定・物理輸送ライフサイクル・物理セキュリティ・クラスタ運用を構築する設計力
• (c) Storage Gateway で File/Volume Cached・Stored/Tape 3種運用・キャッシュサイジング・SMB/NFS認証を設計する設計力
• (d) Mainframe Modernization でリファクタ vs リプラットフォーム判断・Micro Focus/AWS Blu Age 活用・Wave Group設計を実装する設計力
• (e) 詰まり7選＋アンチパターン演習5問でサーバ移行・物理輸送の設計力を実践で体得する経験
• (f) Vol1×Vol2 統合移行アーキテクチャ＋選定フローチャートでデータとサーバの両軸を統合設計できる総合設計力

旧 Migration 本番運用 Vol1 との位置関係

本シリーズには既に「Migration 本番運用 Vol1（Re-host/Re-platform 概観）」が存在する。あちらは 6Rs（Re-host・Re-platform・Re-factor・Re-purchase・Re-retire・Retain）の判断基準と Lift & Shift の概要を扱う入門編である。本記事はその深堀り編として位置づけられており、MGN の具体的な Wave 設計フローや Snow Family の物理輸送ライフサイクルなど、本番環境で即日実践できる粒度まで掘り下げる。旧 Vol1 がサービス選定の「なぜ」を教えるなら、本 Vol2 はサービス運用の「どう」を教える記事として役割が完結する。

移行プロジェクトにおける Vol2 4サービスの活用場面

Vol2 の4サービスは、移行プロジェクトのフェーズと移行対象の種類によって使い分ける。以下に典型的な活用場面を整理する。

MGN × Snow Family の組み合わせ

ネットワーク帯域が細い拠点では、まず Snow Family でデータ（DB ダンプ・大容量ファイル）を AWS へ物理輸送し、MGN でサーバ移行を並行して進める。Snow Family の物理輸送はディスク全量のコピーに特化し、MGN は差分レプリケーションで最終的なカットオーバーをカバーするという役割分担が成立する。

Storage Gateway による移行中のブリッジ

MGN でサーバを移行した後も、オンプレ側に残るファイルサーバやバックアップ系のサーバは Storage Gateway でハイブリッド接続を維持することで、段階的な移行を実現できる。Storage Gateway を「橋渡し」として使い、オンプレアクセスを維持しながら徐々にクラウドネイティブな構成へ移行する設計が有効である。

Mainframe Modernization の位置づけ

メインフレームシステムは MGN では移行できない（エージェントをインストールできない専用 OS のため）。Mainframe Modernization は独立したサービスとして、COBOL/JCL プログラムを解析・変換し、Linux/Java/Angular ベースのアプリケーションとして AWS 上で動作させる。このため、メインフレームを持つ企業の移行プロジェクトでは MGN（汎用サーバ）+ Mainframe Modernization（メインフレーム）の2トラック並行進行が典型的なパターンとなる。

第26軸目 二部作完成 / 64→65記事化達成

本記事の公開により、Migration & Transfer 軸が Vol1（データ転送）× Vol2（サーバ移行）として完結し、第26軸目の二部作が完成する。これによりシリーズ全体の記事数は 64 → 65記事 へと更新される。Migration & Transfer という広大なサービス群を二部作で完全カバーすることで、AWS への移行プロジェクト設計力を体系的に習得できる形が整った。次の §2 以降で MGN・Snow Family・Storage Gateway・Mainframe Modernization それぞれの本番運用設計を詳述する。

AWS Application Migration Service (MGN) 本番運用 — エージェント配置 / Wave設計 / カットオーバー / ロールバック戦略

AWS Application Migration Service（MGN）は、オンプレミスや他クラウドのサーバをブロックレベルで AWS へ継続レプリケーションし、Test Launch・Production Launch によるカットオーバーを実現するサービスである。エージェントベースの仕組みを採用しており、OS レベルで動作することから Windows・Linux を問わず広範なソースサーバに対応する。

§1 の fig01（本§より前に掲載）は MGN の Wave 設計とカットオーバーフロー全体を示す。以下、各フェーズを順番に詳述する。

MGNエージェント配置設計

対応 OS・要件

MGN エージェント（AWS Replication Agent）は以下の環境でサポートされる。

ネットワーク疎通要件

エージェントは AWS レプリケーションエンドポイントへの HTTPS アウトバウンド接続を必要とする。

ダイレクトインターネット接続が不可の環境では、VPC インターフェースエンドポイント（PrivateLink）を使用することでトラフィックを AWS ネットワーク内に留めることができる。エンドポイントは com.amazonaws.<region>.mgn および com.amazonaws.<region>.s3 を作成する。

Replication Server Subnet の選定

Staging Area（レプリケーション先）を配置するサブネットはプライベートサブネットを推奨する。ソースサーバのエージェントは TCP 1500 で Replication Server へ接続するため、サブネット間のルーティングとセキュリティグループ設定が必要となる。

Source Server（オンプレミス）
  → TCP 1500 / TLS → Replication Server（Staging Area Subnet、プライベート）
  → EBS（暗号化レプリカボリューム）
  → Conversion Server（カットオーバー時のみ起動）
  → Target EC2（本番 Subnet）

レプリケーション設計

Staging Area と Replication Server

Staging Area は S3 + EBS でレプリカデータを保持する中間領域である。常時稼働するのは Replication Server（t3.small 相当）のみであり、コストは比較的低く抑えられる。

帯域制御（スロットリング）

MGN はレプリケーション帯域をスロットリングする機能を持つ。業務時間帯の帯域圧迫を防ぐために、スロットリングポリシーを設定する。

{
  "bandwidthThrottling": 100,
  "comment": "Unit: Mbps. 業務時間帯（9:00-19:00 JST）は 100 Mbps に制限"
}

初期同期フェーズ（Initial Sync）は全ディスクデータを転送するため最も帯域を消費する。Initial Sync 完了後は差分レプリケーション（Continuous Replication）に移行し、帯域消費量は大幅に減少する。MGN コンソールで「Healthy」ステータスに遷移したことを確認してから Test Launch へ進む。

EBS 暗号化設計

レプリケーション先の EBS ボリュームには KMS カスタマーキー（Customer Managed Key）を使用することを推奨する。デフォルトの AWS マネージドキーでも暗号化は有効だが、カスタマーキーを使用することでキーのローテーション制御・監査ログの詳細化が可能になる。

KMS Key Policy 最小権限例:
  Principal: MGN Service Role（AWSApplicationMigrationServiceRole）
  Action: kms:GenerateDataKey, kms:Decrypt, kms:CreateGrant
  Resource: arn:aws:kms:<region>:<account-id>:key/<key-id>

Wave設計

MGN では、移行対象のサーバ群を「Wave」単位に分割して順次カットオーバーを進める。Wave 設計の品質がプロジェクト成否を大きく左右する。

Wave 単位の分割粒度

Wave 依存関係グラフの作成

Wave を設計する際は、まず依存関係グラフ（DAG）を作成する。グラフのノードはサーバ（またはサービス）、エッジは「Aが動作するにはBが必要」の依存関係を表す。依存関係グラフが完成したら、トポロジカルソートで Wave 順序を決定する。

依存関係の例:
  [DB サーバ] ← [AP サーバ] ← [Web サーバ] ← [CDN/ロードバランサ]

Wave 順序:
  Wave 1: DB サーバ（依存なし・最優先）
  Wave 2: AP サーバ（DB 移行後に着手）
  Wave 3: Web サーバ（AP 移行後に着手）

Wave Group の活用

MGN の Wave Group 機能を使うと、複数の Wave をまとめて管理しカットオーバースケジュールを一元化できる。大規模移行では Wave Group を「フェーズ1（非重要系）・フェーズ2（基幹系）・フェーズ3（決済系）」のように段階的に設計する。

Wave Group A（フェーズ1: 非重要系）
  └─ Wave 1: 開発/検証サーバ群（5台）
  └─ Wave 2: 静的コンテンツ配信サーバ（3台）

Wave Group B（フェーズ2: 基幹系）
  └─ Wave 3: DB サーバ（2台）
  └─ Wave 4: AP サーバ（8台）
  └─ Wave 5: Web サーバ（10台）

Wave Group C（フェーズ3: 決済・認証系）
  └─ Wave 6: 決済 AP サーバ（4台）
  └─ Wave 7: 認証サーバ（3台）

並列度の制御

同一 Wave 内のサーバを並列カットオーバーする場合、Replication Server の帯域と Final Sync のタイムアウト設定を考慮する。並列台数が多いと Final Sync 時間が延びリスクが増すため、1 Wave あたりの並列カットオーバーは 10〜20 台以内を推奨する。Final Sync の推定所要時間は「最終24時間の変更量（GB）÷ 実効帯域（Gbps）」で概算できる。

カットオーバー手順

MGN のカットオーバーは Test Launch → 検証 → Production Launch → DNS 切替 の順で実施する。

Step 1: Test Launch（本番前テスト）

Test Launch は本番環境に一切影響を与えずにカットオーバー後の動作を確認できる機能である。ソースサーバの運用を継続しながら、レプリカから EC2 インスタンスを起動して動作確認する。

MGN コンソール → Source Server 選択
  → [Test and Cutover] → [Launch Test Instance]
  → EC2 起動（Conversion Server 経由でブートドライバ適用）
  → 動作確認
  → [Terminate Test Instances]（確認後は即削除）

Test Launch 時の確認項目：

Test Launch 完了後、テストインスタンスは必ず Terminate Test Instances で削除する（稼働中は EC2 課金が発生する）。

Step 2: Production Launch（本番カットオーバー）

Test Launch での検証が完了したら本番カットオーバーを実施する。カットオーバー直前に以下の事前確認を行う。

MGN コンソール → Source Server 選択
  → [Test and Cutover] → [Launch Cutover Instance]
  → Final Sync（最後の差分転送）自動実行
  → Conversion Server 起動（ブートドライバ・NIC 設定適用）
  → Target EC2 起動

Production Launch 後の確認項目：
– ターゲット EC2 のヘルスチェック通過
– アプリケーション正常起動と疎通確認
– 他システムとの接続疎通（VPC Peering・Route 53 エンドポイント確認）

Step 3: DNS 切替

Production Launch 確認後、トラフィックをオンプレミスから AWS へ切り替える。

DNS 切替後、元のオンプレサーバへのトラフィックがゼロになったことをアクセスログで確認してから「Mark as Cutover」を実行し、MGN の管理ステータスを更新する。

ロールバック戦略

MGN の最大の特長の一つが、Production Launch 後でも継続レプリケーションを維持し続けることでロールバックを可能にする設計である。

継続レプリケーションの維持

Production Launch 後も、ソースサーバ（オンプレ側）は MGN エージェントが動作し続け、AWS 側への差分レプリケーションが継続する。これにより、カットオーバー後に問題が発覚した場合の切り戻し基盤が確保される。

カットオーバー後の状態（ロールバック可能フェーズ）：
  オンプレサーバ（稼働中・エージェント動作中）
 → 差分レプリケーション継続 → AWS EBS（最新状態を維持）

問題発覚時：
  DNS を元の IP に戻す
  → オンプレサーバを主系に戻す
  → AWS 側インスタンスを停止

旧環境保持期間の設計

切り戻し手順

1. AWS 側ターゲット EC2 を停止（データ書き込みを止める）
2. DNS を元のオンプレ IP に戻す（TTL が短縮済みなら数分で切替完了）
3. オンプレサーバのアプリケーションを主系として再起動
4. MGN コンソールで継続レプリケーションが再開していることを確認
5. ロールバック報告書を作成し、原因分析と再カットオーバー計画を策定

注意事項: AWS 側でディスク書き込みが発生した後に切り戻す場合、AWS 側の変更はオンプレへ自動同期されない。DNS 切替後のデータ変更量を最小化するため、切り戻し判断は可能な限り早期に行うことが重要である。Production Launch から 1 時間以内のロールバックが最もリスクが低い。

launch template 設計

MGN の launch template は EC2 Launch Templates として定義し、カットオーバー時の EC2 設定を事前に確定させる。

必須設定項目と推奨値

LaunchTemplate:
  InstanceType: r5.xlarge
  IamInstanceProfile:
 Arn: arn:aws:iam::123456789012:instance-profile/MGN-TargetInstanceProfile
  TagSpecifications:
 - ResourceType: instance
Tags:
  - Key: Environment
 Value: Production
  - Key: MigratedBy
 Value: MGN
  - Key: WaveID
 Value: Wave3
  - Key: CostCenter
 Value: Migration2026
  SecurityGroupIds:
 - sg-0abcdef1234567890
  SubnetId: subnet-0fedcba9876543210
  UserData: |
 #!/bin/bash
 hostnamectl set-hostname prod-appserver-01
 timedatectl set-timezone Asia/Tokyo
 systemctl enable myapp
 systemctl start myapp

launch template のバージョン管理

Wave ごとに launch template のバージョンを分けて管理することを推奨する。カットオーバー後に問題が発生した場合、どのバージョンでカットオーバーしたかを追跡できるため原因分析が容易になる。

launch-template-wave3-v1  ← Test Launch 時に作成・検証
launch-template-wave3-v2  ← Test Launch 結果を反映して修正
launch-template-wave3-v2  ← Production Launch では最終確認済みバージョンを使用

本番運用 キーポイント

AWS Snow Family 本番運用 — Snowball Edge / Snowcone / 物理輸送ライフサイクル

Snow Family の位置づけと全体像

AWS Snow Family は、ネットワーク帯域が不足している環境や物理的にインターネット接続が困難な現場でペタバイト規模のデータをAWSへ物理輸送するためのマネージドサービス群である。「帯域転送に 1 週間以上かかるデータ量」が Snow Family を検討すべき基準として広く使われている。データ転送だけでなく、AWS Lambda・EC2 相当のエッジコンピューティング機能も内包しており、現場処理→クラウド送信のパイプラインとしても機能する。

本セクションでは Snowball Edge Compute Optimized / Storage Optimized / Snowcone の 3 デバイス特性、ユースケース別選定基準、注文〜返送ライフサイクル、物理セキュリティ機構、Edge クラスタ運用の 5 軸で本番設計要点を整理する。

Snow Family 3デバイス比較

Snowball Edge Compute Optimized の強み: GPU を搭載できる唯一のデバイスであり、工場ライン・石油掘削設備など電力や通信インフラが不安定な現場でも機械学習推論やリアルタイム画像処理が実行できる。ML フレームワーク (TensorFlow / PyTorch) を EC2 AMI として持ち込み、エッジでの推論結果だけをクラウドへ送信する「エッジ推論 + クラウド集約」パターンに最適である。

Snowball Edge Storage Optimized の強み: 80 TB HDD と S3 互換オブジェクトストレージ (210 TB まで拡張可能) という大容量が最大の特徴である。データセンター廃止・データウェアハウス全体移行・映像アーカイブ大量取込など「まずデータ量を AWS に移動させる」フェーズで主役となる。クラスタモードで最大 15 台を連結することで有効容量を線形に拡張できる。

Snowcone の強み: 2 kg 台の重量と DataSync エージェント内蔵により、撮影現場・船舶・医療移動診断車など「PC バッグに入れて持ち込める」ユースケースを開拓する。帯域が細くても DataSync 経由でのバックグラウンド送信と物理輸送の双方に対応する。

ユースケース別選定基準

Snow Family デバイスの選定は「データ容量・帯域不足度・物理環境制約」の 3 軸で判断する。

帯域損益分岐点の計算例: 100 TB のデータを転送するとき、1 Gbps 専用線では約 9 日かかる。Snow Family の物理輸送 (注文〜データ取込完了) は通常 7〜14 日であるため、帯域が 500 Mbps 以下の環境では Snow Family の方が実質の転送完了日数が短くなる場合がある。実際には「転送中の業務継続コスト」「帯域占有による既存業務影響」も加味して判断する。

物理環境制約チェックリスト:

• 電源: 単相 200V 15A 以上を確保できるか (Snowcone はモバイルバッテリー対応)
• 室温: 0〜45 ℃ の動作範囲内か (Snowcone は -20〜45 ℃ と広め)
• 床耐荷重: Storage Optimized 22 kg × 台数 + ラック重量
• ネット接続: Snowcone は完全 Air-gap 環境でも物理輸送のみで運用可
• S3 バケット: Job 作成時にリージョン指定が確定し後変更不可

注文〜返送ライフサイクル

Snow Family の物理輸送プロセスは 7 ステップで管理される。fig02 はこのライフサイクルを可視化したものである。

Step 1: Job 作成

AWS マネジメントコンソールまたは AWS CLI で Snow Family Job を作成する。Job 作成後に変更できない項目が多いため、事前設計が重要である。

• Job タイプ: Import (→ AWS)・Export (AWS →)・Local Compute and Storage
• S3 バケット: データの取込 / 書出先 (別リージョン指定は不可)
• KMS 暗号化キー: デフォルト管理キーまたはカスタマー管理キー (CMK)
• SNS 通知: ステータス変化を E-mail / SNS Topic で受信
• 配送先住所と連絡先担当者

Step 2: デバイス出荷 (AWS → 現地)

Job 作成から通常 2〜5 営業日でデバイスが配送される。到着時に「E-Ink ラベルに表示された追跡番号」と「AWS コンソールのデバイスシリアル番号」が一致することを確認する。外装・デバイス本体の破損・改ざん検知シール剥離がないか目視確認し、異常があれば AWS サポートへ即時報告する。

Step 3: 現地受領・電源投入・ロック解除

デバイスを電源に接続し、LCD パネルまたは OpsHub (GUI 管理ツール) でネットワーク設定を行う。ロック解除には AWS コンソールから取得する「クライアントアンロックコード」が必要である。アンロックコードは Job 作成者のみが取得可能なため、現地担当者と Job 管理者が異なる場合は事前に安全なチャンネルで共有しておく。

Step 4: データ転送 (現地 → デバイス)

AWS Snowball クライアント CLI または S3 互換 API (Storage Optimized の場合) でデータをコピーする。転送速度の目安は Storage Optimized で最大 1 Gbps (NIC 2 系統ボンディング)、Compute Optimized NVMe では最大 100 Gbps ローカル帯域である。大容量転送では以下の並列化を推奨する。

Step 5: 返送 (現地 → AWS)

転送完了後、デバイスの電源を切りシャットダウンする。E-Ink ラベルが自動更新され返送先 AWS 施設の住所が表示されるため、梱包して宅配業者に引き渡すだけで返送が完了する。自分で送り状を作成する必要はない。返送後は AWS コンソールでデバイスが「In Transit (Return)」ステータスに変化したことを確認する。

Step 6: AWS Import (AWS 施設でのデータ取込)

デバイスが AWS 施設に到着後、約 2〜5 営業日で S3 バケットへのデータ取込が完了する。この過程でデバイス内データは自動的に消去されるため、機密データの残留リスクはない。消去は NIST 800-88 準拠のメディア消去手順で実施される。

Step 7: 検証

S3 バケットのオブジェクト数・容量を Transfer 完了通知受信後に確認する。S3 インベントリレポートと転送元ファイルリストを突き合わせ、欠損・破損がないことを確認する。Snowball クライアントが生成する転送ログ (job-log.txt) にはファイル単位のチェックサム結果が記録されているため、これを照合ツールと組み合わせると効率的である。

物理セキュリティ設計

Snow Family デバイスは「物理輸送中のデータ保護」を多層防御で実現している。

TPM (Trusted Platform Module) 2.0

デバイス内の暗号化キー管理に TPM 2.0 を使用する。キーマテリアルはデバイスの CPU 内にのみ存在し、外部読み出しは物理的に不可能な構造になっている。デバイスが一定回数の認証失敗を検知した場合、TPM がキーを自動破棄する (ブルートフォース耐性)。

改ざん検知シール

デバイスの蓋部分には改ざん検知シールが貼付されており、不正開封を試みると不可逆的に「VOID」表示に変化する。受領時の目視確認フローに「シール確認」を必ず組み込む。

KMS 連携暗号化

デバイス上のデータは 256-bit AES-GCM で暗号化され、暗号化キーは AWS KMS で管理される。KMS CMK を指定することでカスタマーマネージドな鍵ローテーションが可能になる。デバイスがアンロックされていない状態では KMS と通信できずデータアクセス不可であるため、紛失・盗難時のデータ漏洩リスクを極小化できる。

E-Ink ラベル

デバイスの側面に E-Ink ディスプレイが搭載されており、出荷時と返送時で表示住所が自動切替される。物理的な送り状の貼り間違いリスクがなく、デバイスの現在ステータスが常に視覚的に確認できる。

物理セキュリティ チェックリスト:

クラスタ運用 (Edge クラスタモード)

Snowball Edge Storage Optimized は最大 15 台のクラスタを組み、S3 互換オブジェクトストレージとしてオンプレアプリケーションに提供できる。

クラスタの基本構成

クラスタ最小構成は 3 台 (クォーラム維持のため奇数台推奨)。各ノードは AWS コンソールで「クラスタ Job」として一括作成する。ノード間通信には 10 GbE または 25 GbE の専用スイッチを使用する。クラスタ Job に割り当てる S3 バケットはノード間で共通化され、単一の S3 エンドポイントとしてアプリケーションに公開される。

HA 構成と障害耐性

ノードが障害になると自動的にクラスタから除外され、残存ノードでサービスを継続する。交換デバイスの投入はコンソールでの「ノード追加」操作と物理接続のみで完了する。

S3 互換オブジェクトストレージ

クラスタ上の S3 互換 API は AWS S3 API のサブセットを実装している。対応操作: PUT / GET / DELETE / HEAD / LIST (Bucket / Object)。非対応: S3 Versioning・ライフサイクルルール・クロスリージョンレプリケーション。アプリケーション側は AWS SDK の endpoint_url パラメータをデバイス IP に変更するだけで S3 互換ストレージを利用できる。

ローカルコンピューティング連携

EC2 インスタンス (AMI は AWS コンソールからデプロイ) が S3 互換ストレージと同一デバイス上で動作するため、データを外部に転送せずにローカル処理してからクラスタに書き込む「ローカル処理 + ローカル保存」パターンが実現できる。Lambda 関数のデプロイも可能なため、イベントドリブンなエッジ処理パイプラインを構築できる。

OpsHub による GUI 管理とモニタリング

AWS OpsHub は Snow Family デバイスをローカル GUI で管理するための無償ツールである。データ転送 CLI の操作に不慣れな担当者でも、OpsHub を使えばドラッグ&ドロップ感覚でファイル転送・デバイス管理・EC2 インスタンス操作が行える。

OpsHub の主な機能

CLI と OpsHub の使い分け

Snow Family と AWS DataSync の連携戦略

Snow Family と DataSync を組み合わせる「ハイブリッド移行」は、移行期間中もネットワーク帯域を有効活用しながら物理輸送でデータを一括移行するベストプラクティスである。

段階移行パターン (Snowcone + DataSync)

• Phase 1: Snowcone で「過去データ (コールド) 」を物理輸送で AWS へ取込
• Phase 2: DataSync を Snowcone 内の組み込みエージェントで起動し、「現在データ (ホット) 」を差分転送
• Phase 3: Snowcone 返送後、DataSync エージェントをオンプレ Linux サーバに移行し継続同期

このパターンにより、初期移行のネットワーク帯域使用を最小限に抑えながら、運用中の継続的同期を DataSync が担う体制が完成する。

DataSync タスク設計のポイント

Snow Family 本番運用 キーポイント一覧

AWS Storage Gateway 本番運用 — File / Volume Cached・Stored / Tape 3種統合

Storage Gateway の位置づけと全体像

AWS Storage Gateway はオンプレミスアプリケーションをAWSストレージに透過的に接続するハイブリッドストレージサービスである。既存のファイルサーバ・ブロックデバイス・テープバックアップのプロトコルをそのまま維持しながら、バックエンドを段階的にAWSへ移行・拡張できる「移行の架け橋」として機能する。

3 種のゲートウェイ (File Gateway / Volume Gateway / Tape Gateway) は互いに独立して展開でき、オンプレ環境に VMware ESXi・Microsoft Hyper-V・Linux KVM 上の VM、または Storage Gateway Hardware Appliance として配置する。

File Gateway — SMB/NFS → S3 のオンプレファイル共有拡張

File Gateway はオンプレミスの SMB/NFS クライアントからマウントできるファイル共有を提供し、書き込まれたファイルをリアルタイムで S3 オブジェクトとして保存する。ファイル共有はそのまま利用しながら、バックエンドのストレージ容量が事実上無制限になる。

アーキテクチャ: オンプレ NFS/SMB クライアント → File Gateway VM (ローカルキャッシュ: SSD/HDD) → S3 バケット → S3 ライフサイクルルールで S3 Glacier へ自動移行

ローカルキャッシュの役割

File Gateway はアクセス頻度の高いファイルをローカルキャッシュ (SSD 推奨) に保持し、レイテンシを LAN 内相当に抑える。キャッシュから evict されたデータの読み取りは S3 から再フェッチするため、読み取りレイテンシが増大する。したがって、ホットデータ率を把握してキャッシュをオーバープロビジョニングすることが推奨される。

主な設定項目

ユースケース例:

• 社内ファイルサーバの S3 移行 (NFS/SMB インターフェイス維持)
• 動画素材の S3 保管 (NLE ソフトウェアからは NFS マウントとして見える)
• ホームディレクトリの S3 統合 (複数サイトからの同一 S3 バケット参照)
• DataSync との連携でコールドデータを自動アーカイブ

Volume Gateway Cached モード — ホットデータはローカル / コールドデータは S3

Volume Gateway Cached モード は iSCSI ブロックデバイスとしてオンプレサーバにマウントされる。ボリュームの実体は S3 に保存され、頻繁にアクセスされるデータのみがローカルキャッシュに保持される「S3 バックド iSCSI ボリューム」である。

動作原理

読み取りアクセス時: ローカルキャッシュにあれば LAN 速度で応答 → なければ S3 からフェッチしてキャッシュに入れてから応答 (キャッシュミス = レイテンシ増大)

書き込みアクセス時: まずローカルキャッシュに書き込み (高速) → バックグラウンドで S3 へ非同期アップロード

容量設計

EBS スナップショットと DR

Volume Gateway Cached のボリュームは定期的に EBS スナップショットとして保存される。スナップショットから Amazon EBS ボリュームを作成して EC2 にアタッチすることで、オンプレ停止時も数分以内に AWS 上で同一ボリュームを参照できる。「オンプレ主体 + AWS DR」の非対称 DR 構成を低コストで実現できる。

Volume Gateway Stored モード — オンプレ保持 + S3 スナップショット DR

Volume Gateway Stored モードは iSCSI ボリュームの実体がオンプレローカルストレージに残る構成である。S3 は「スナップショットバックアップ先」として機能し、定期的なスナップショットが EBS Snapshot として S3 にアップロードされる。

Cached vs Stored の使い分け

Stored モードのスナップショット設計

スナップショットは増分バックアップであるため、初回以降の転送量は差分のみである。スナップショット頻度の目安:

• 重要業務 (日次変更量 5 GB 超): 4 時間ごと
• 通常業務 (日次変更量 1〜5 GB): 12 時間ごと
• アーカイブ系 (日次変更量 1 GB 未満): 24 時間ごと

スナップショットは CloudWatch イベントまたは Data Lifecycle Manager (DLM) ポリシーで自動化する。

Tape Gateway — iSCSI VTL で既存バックアップソフトとの互換性

Tape Gateway は物理テープライブラリを仮想化し、既存のバックアップソフトウェア (Veeam / Veritas / CommVault 等) が物理テープと同様に扱える仮想テープライブラリ (VTL) を提供する。仮想テープのデータは S3 (アクティブ) および S3 Glacier / S3 Glacier Deep Archive (アーカイブ) に保存される。

仮想テープのライフサイクル

物理テープ廃止移行シナリオ

既存の物理テープライブラリを Tape Gateway に置き換える場合、バックアップソフトの「テープライブラリ接続先」を iSCSI VTL に変更するだけで移行が完了する。物理テープの輸送・管理・劣化リスクをゼロにしながら、バックアップの取得・復元フローをそのまま維持できる。

コスト設計のポイント

キャッシュサイジング設計

Storage Gateway の File Gateway および Volume Gateway Cached において、ローカルキャッシュのサイジングは性能を左右する最重要設計要素である。

計算式

キャッシュ容量 = 7日Working Set × 安全係数

実例: 製造業ファイルサーバのキャッシュ設計

キャッシュ不足時の影響:

File Gateway のキャッシュが枯渇すると、S3 からのオブジェクト再フェッチが頻発して読み取りレイテンシが大幅に悪化することがある。Volume Gateway Cached では、キャッシュヒット率が 70% を下回ると IOPS が急落し、業務アプリケーションのタイムアウトが発生する。

CloudWatch メトリクス CacheHitPercent および CacheUsed を監視し、CacheHitPercent が 80% を下回ったらキャッシュ拡張を検討する。

SMB/NFS 認証設計 (File Gateway)

File Gateway の SMB および NFS 共有はそれぞれ異なる認証機構を持ち、オンプレの Active Directory 環境と統合できる。

SMB 認証の選択肢

AD 統合の設定手順

1. File Gateway を AD ドメインに参加させる (コンソール or Gateway API で DN / パスワードを入力)
2. SMB 共有作成時に「AD 認証を有効化」を選択
3. S3 バケットポリシーで File Gateway の IAM ロールに PutObject / GetObject 権限を付与
4. AD 側で共有アクセスを許可するグループ/ユーザーを Gateway の ACL に追加

NFS 認証の設定 (RootSquash)

NFS v3/v4.1 対応の File Gateway では RootSquash を有効化することで、NFS クライアントの root ユーザーを nobody にマップしてファイル所有権の乱用を防ぐ。

NFS 共有の IP 制限 (クライアント IP 許可リスト)

File Gateway の NFS 共有はコンソールで「クライアント IP アドレス範囲」を指定できる。CIDR 形式で記入し、許可されたアドレス範囲のみが NFS マウントできる状態にすることで、不正マウントを防ぐ。

Storage Gateway 監視設計

Storage Gateway の本番運用では CloudWatch を活用したメトリクス監視が不可欠である。キャッシュ不足や帯域逼迫を事前に検知してスケールアウト対応するための監視設計を以下に整理する。

主要 CloudWatch メトリクス

アラーム設計の推奨構成

CloudWatch Alarm を SNS Topic と組み合わせて「警告 → メール / Slack 通知」「緊急 → PagerDuty / オンコール通知」の 2 段階エスカレーションを設定する。アラーム対応のランブックには「キャッシュ不足時はキャッシュディスクを追加してから Gateway を再起動する」手順を明記しておく。

ログ設計

File Gateway と Volume Gateway は CloudWatch Logs にエラーログを送信できる。ログレベルは本番では「WARN」以上を推奨する。DEBUG ログは API コール単位で出力されるため、大量転送時にログコストが急増する点に注意する。

Storage Gateway 本番運用 キーポイント一覧

AWS Mainframe Modernization 本番運用 — リファクタ vs リプラットフォーム / Micro Focus / AWS Blu Age

メインフレームをAWSへ移行する際、最大の決断は「どこまで近代化するか」だ。AWS Mainframe Modernization サービスは2大アプローチ——リファクタ（Re-factor）とリプラットフォーム（Re-platform）——を提供し、それぞれ対応するランタイムエンジンが異なる。

メインフレーム近代化 2大アプローチ比較

Micro Focus エンジン（Re-platform向け）

Micro Focus Enterprise Server は COBOL/JCL/CICS/VSAM を AWS 上でほぼそのままエミュレートするランタイムだ。AWS Mainframe Modernization の「Managed Micro Focus」環境として提供され、既存コードへの変更を最小化しながら AWS に移行できる。

主な特徴:
– COBOL互換実行: GnuCOBOL/Micro Focus COBOLのバイナリをそのまま動作
– JCL変換: AWS Batch へのジョブ変換を自動マッピング（EXEC PGM= → AWS Batch Job Definition）
– CICS互換: トランザクション処理ミドルウェア互換層を維持
– VSAM互換ストレージ: Amazon S3 + DynamoDB へのVSAMデータセットマッピング

移行フェーズの運用手順:
1. コードアセスメント（Micro Focus Enterprise Analyzer でCOBOLコールグラフを解析）
2. JCL → AWS Batch マッピング定義作成（STEP依存関係を有向グラフで整理）
3. VSAM データセット → S3/DynamoDB 移行（キーレイアウト定義を維持）
4. テスト実行（Micro Focus の単体テストフレームワーク活用）
5. パラレルラン → 本番切替

AWS Blu Age（Re-factor向け）

AWS Blu Age は COBOL/PL1 プログラムを Java（Spring Boot）+ Angular フロントエンドへ自動変換するツールだ。変換後は標準的なJavaアプリとして AWS 上で稼働するため、長期保守性が高まる。

変換プロセス:
1. アセスメント: Blu Age Analyzer で変換対象コードをスキャン・複雑度スコア算出
2. 自動変換: COBOL → Java クラス、JCL → AWS Batch Job、VSAM → RDS/DynamoDB
3. 検証: 変換後 Java コードの回帰テスト（出力データ一致確認）
4. 最適化: 変換後コードのリファクタ（不要ループ除去・ロジック整理）

Blu Age の制約と対処:
– 複雑な COMPUTE 文や REDEFINES 節は手動補完が必要
– CICS 依存トランザクションは Spring MVC への手動マッピングが発生するケースあり
– 変換品質は「変換率」だけでなく「出力値一致率」で評価すること（変換率100%でも出力差分が出ることがある）

アプローチ選定基準

選定は以下4軸で判断する:

3〜5年TCO比較の考え方:
– リプラットフォーム: Micro Focus ライセンス（年間数千万〜数億円規模）+ 移行工数（小）
– リファクタ: 自動変換ツール費 + 移行工数（大）+ Java保守費。ライセンスゼロが長期でペイする分岐点はおおよそ2〜3年
– TCO計算例（100万ステップCOBOL・Micro Focusライセンス年間5,000万円の場合）:
– リプラットフォーム 5年: ライセンス2.5億 + 移行費5,000万 = 3億円
– リファクタ 5年: 変換費2億 + 移行費2億 = 4億円（5年目以降は保守費が年500万程度に低下）
– 6年目以降はリファクタが有利になる計算

カットオーバー戦略

メインフレーム移行のカットオーバーは「パラレルラン」が業界標準だ。

パラレルラン戦略（3フェーズ構成）:

1. フェーズ1: シャドウモード（1〜3ヶ月）
2. 本番はメインフレームで稼働継続
3. AWS側も同じ入力を受け取り処理結果を記録（本番反映なし）

4. 出力差分を毎日比較し、乖離0件を目標とする

5. フェーズ2: 業務選択的切替（1〜2ヶ月）

6. 低リスク業務（バッチレポート出力等）からAWS側を本番採用

7. 旧メインフレームで同一業務を並走させ、バックアップとして維持

8. フェーズ3: 全面切替

9. オンライン系・帳票系を含む全業務をAWS側へ
10. 切替後30日間はメインフレームを「ウォームスタンバイ」として保持
11. 重大障害発生時は48時間以内に旧環境へ切り戻し可能な体制を維持

データ同期方式:
パラレルラン期間中のデータ同期は下記2方式を組み合わせる:
– リアルタイム同期: VSAM/DB2の更新イベントをCDC（Change Data Capture）で捕捉 → AWS DMS → RDS/DynamoDB へ同期
– バッチ同期: 日次EOD（End of Day）バッチ後の差分ファイルをS3へアップロード → AWS Glue でRDSへロード

切戻し可逆性の確保:
– 全面切替後も旧メインフレームのデータをAWS側から逆同期し「切戻し可能状態」を維持
– 切戻し手順書を整備し、少なくとも年1回のDR訓練で検証済みの状態を保つ
– 切戻し判断基準: エラー率が通常時の3倍超、または基幹業務停止が30分超の場合

Wave Group設計

メインフレームの移行を一括で行うのは高リスクだ。Wave Group に分割し、段階的に移行する。

標準的な3グループ分類:

Wave Group設計のポイント:
– 依存関係マップ: JCLのSTEP依存・プログラム間インターフェースをすべて洗い出す
– 1Wave = 1〜3業務サブシステムが適切な粒度（大きすぎると障害時の原因特定が困難）
– Wave完了基準: パラレルラン出力差分0件 × 3営業日連続 + 本番稼働72時間無障害

Wave Group の詳細設計例:

【受注管理システム Mainframe Modernization Wave計画例】

Wave1（バッチ系）:
  - 受注日次集計バッチ（ORDBATCH1〜ORDBATCH12）
  - 在庫更新バッチ（INVBATCH1〜INVBATCH8）
  - テスト期間: 2週間（日次バッチ × 14回）
  - 合格基準: 出力CSV差分0件 × 10営業日連続

Wave2（オンライン系）:
  - CICS受注入力端末（ORDTRANS1〜ORDTRANS5）
  - 受注照会Webサービス（ORDQUERY1〜ORDQUERY3）
  - テスト期間: 4週間（日中業務 + 夜間バッチ）
  - 合格基準: トランザクション処理時間 < 2秒 × 1週間連続

Wave3（帳票系）:
  - 月次請求書生成（BILLRPT1〜BILLRPT6）
  - 出荷伝票印刷（SHPRPT1〜SHPRPT4）
  - テスト期間: 1ヶ月（月末帳票を必ず含む）
  - 合格基準: 帳票ページ数・金額合計がMF出力と100%一致

アセスメントプロセスと移行計画策定

Mainframe Modernization プロジェクトの成否は「アセスメント精度」で決まる。アセスメント不足で後から問題が発覚するケースが最も多い。

アセスメント4フェーズ:

1. インベントリ収集（1〜2週間）
2. プログラム一覧（COBOL/JCL/CICS/PL1）を全棚卸し
3. データセット一覧（VSAM/GDG/テープ）の洗い出し

4. 外部連携インターフェース（FTP/MQ/RACF）の整理

5. 複雑度分析（2〜3週間）

6. Blu Age Analyzer / MF Enterprise Analyzer で全プログラムをスキャン
7. 複雑度スコア（Cyclomatic Complexity）を算出

8. 変換困難プログラムのリストアップ（REDEFINES多用・動的CALL等）

9. リスク評価（1〜2週間）

10. 変換困難プログラムの対処方針決定（手動変換 / 留置き / 新規開発）
11. 業務停止許容時間と移行スケジュールの整合性確認

12. パラレルラン環境の調達・構築コスト見積もり

13. 移行計画策定（1〜2週間）

14. Wave Group 分割設計と順序決定
15. テスト計画（パターン数・合格基準・期間）
16. コスト・スケジュール・リスクのトレードオフ調整

アセスメント完了の判断基準:
– 移行対象プログラムの100%棚卸し完了
– 変換困難プログラムの対処方針が全件確定
– Wave Group 間の依存関係グラフが完成
– パラレルラン合格基準が業務部門と合意済み

Micro Focus JCL → AWS Batch マッピング設計

Re-platform 選択時の主要な技術課題は JCL の AWS Batch へのマッピングだ。

JCL STEP と AWS Batch Job の対応関係:

【JCL 側】
//STEP010 EXEC PGM=ORDPROC,PARM='DATE=&DATE'
//INFILEDD DSN=PROD.ORD.INPUT,DISP=SHR
//OUTFILE  DD DSN=PROD.ORD.OUTPUT,DISP=(NEW,CATLG)
//SYSOUTDD SYSOUT=A

【AWS Batch 側】
Job Definition: ORDPROC-job
  Container: {
 image: "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/mf-ordproc:latest",
 environment: [{"name": "PARM_DATE", "value": "<DATE>"}],
 mountPoints: [
{"sourceVolume": "infile", "containerPath": "/vsam/ORD_INPUT"},
{"sourceVolume": "outfile", "containerPath": "/vsam/ORD_OUTPUT"}
 ]
  }
Job Queue: mainframe-migration-queue
  computeEnvironment: mainframe-compute-env (Fargate)

JCL フロー制御の変換:

JCL フロー全体を AWS Step Functions で管理する構成:

{
  "StartAt": "STEP010",
  "States": {
 "STEP010": {
"Type": "Task",
"Resource": "arn:aws:states:::batch:submitJob.sync",
"Parameters": {
  "JobName": "ORDPROC-step010",
  "JobDefinition": "ORDPROC-job",
  "JobQueue": "mainframe-migration-queue"
},
"Next": "CheckRC010"
 },
 "CheckRC010": {
"Type": "Choice",
"Choices": [
  {
 "Variable": "$.status",
 "StringEquals": "SUCCEEDED",
 "Next": "STEP020"
  }
],
"Default": "AbendHandler"
 }
  }
}

本番運用キーポイント

詰まりポイント7選 + アンチパターン → 正解パターン変換

実際の移行プロジェクトで繰り返し発生する詰まりポイントを7つに絞り込み、原因・影響・解決策をセットで整理する。

# MGN エンドポイント疎通確認
curl -s -o /dev/null -w "%{http_code}" \
  https://mgn.ap-northeast-1.amazonaws.com/HealthCheck
# 200 が返れば通信OK

# Snow Family ジョブ作成時の暗号化指定例
aws snowball create-job \
  --job-type IMPORT \
  --resources '{"S3Resources":[{"BucketArn":"arn:aws:s3:::my-bucket"}]}' \
  --kms-key-arn "arn:aws:kms:ap-northeast-1:123456789012:key/your-key-id" \
  --snowball-type EDGE_STORAGE_OPTIMIZED \
  --region ap-northeast-1

正しい順序:
  Wave1: DBサーバ群（依存されている側を先に移行）
  Wave2: APサーバ群（DB接続先をAWS側に更新してからカットオーバー）
  Wave3: Webサーバ群（AP接続先をAWS側に更新してからカットオーバー）

誤った順序（よくある失敗）:
  Wave1: Webサーバ群 → APへの接続は生きているが
  Wave2: APサーバ群 → DBはまだオンプレ → AP→DB接続切れ → 障害

# 静的 CALL の抽出（JCL STEP PGM= から）
grep -r "EXEC PGM=" ./jcl/ | awk '{print $3}' | sort -u > static_programs.txt

# 動的 CALL の抽出（COBOL ソース内の CALL 文）
grep -r "CALL " ./cobol/ | grep -v "CALL '" | awk '{print $2}' | \
  sed "s/['\"]//g" | sort -u > dynamic_calls.txt

# 差分確認（dynamic_callsにあってstatic_programsにないものが漏れ候補）
comm -23 <(sort dynamic_calls.txt) <(sort static_programs.txt)

Job作成 → PreparingAppliance → InProgress（デバイス使用中）
→ Complete（データ転送完了・返送待ち）※ここから返送期限カウント開始
→ InTransitToAWS（返送輸送中）
→ WithAWS（AWS受取・S3インポート処理中）
→ Completed（完全完了）

import boto3
from datetime import datetime, timezone

def check_snow_job_deadlines():
 client = boto3.client('snowball', region_name='ap-northeast-1')
 jobs = client.list_jobs()['JobListEntries']

 for job in jobs:
  if job['JobState'] == 'Complete':
created = job['CreationDate']
days_elapsed = (datetime.now(timezone.utc) - created).days
if days_elapsed >= 7:  # 10日期限の3日前にアラート
 print(f"ALERT: Job {job['JobId']} - {days_elapsed}日経過。返送期限まで{10 - days_elapsed}日")

check_snow_job_deadlines()

アンチパターン → 正解パターン変換

アンチパターン1: MGN launch template 未指定 → IAM Profile + Tag + SG + UserData テンプレ

アンチパターン: launch template を指定せずに Test Launch を実行。移行後インスタンスに正しい IAM Instance Profile・Security Group・Tags が付与されず、本番環境のポリシーと不整合が発生。

正解パターン: EC2 Launch Template を事前に作成し、MGN のレプリケーション設定に紐づける。

{
  "LaunchTemplateData": {
 "IamInstanceProfile": {
"Arn": "arn:aws:iam::123456789012:instance-profile/MigrationInstanceProfile"
 },
 "SecurityGroupIds": ["sg-0abc123def456789a"],
 "TagSpecifications": [
{
  "ResourceType": "instance",
  "Tags": [
 {"Key": "Project", "Value": "migration-2026"},
 {"Key": "Wave", "Value": "wave1"},
 {"Key": "Env", "Value": "production"}
  ]
}
 ],
 "UserData": "IyEvYmluL2Jhc2gKZWNobyAiTUdOIG1pZ3JhdGlvbiBpbnN0YW5jZSBpbml0aWFsaXplZCIK"
  }
}

アンチパターン2: Snow データ取込検証スキップ → Manifest検証 + チェックサム必須

アンチパターン: Snowball からS3へのインポート完了後、データ検証をスキップして移行完了と判断。後日、一部ファイルの破損・欠落が発覚。

正解パターン: インポート完了後に Manifest ファイルとチェックサムで整合性を検証する。

# Snow Family インポート後の検証手順
# 1. Job完了後に Manifest ファイルをダウンロード
aws snowball get-job-manifest \
  --job-id JID123e4567-e89b-12d3-a456-426614174000 \
  --output text > job_manifest.csv

# 2. S3 上のオブジェクトとManifestを比較
aws s3 ls s3://my-import-bucket --recursive | awk '{print $4}' | sort > s3_objects.txt
awk -F',' '{print $1}' job_manifest.csv | sort > manifest_objects.txt
diff manifest_objects.txt s3_objects.txt  # 差分0件であることを確認

# 3. チェックサム検証（sha256）
aws s3api head-object --bucket my-import-bucket --key path/to/file \
  --query 'ChecksumSHA256'

アンチパターン3: Storage Gateway VM CPU/RAM不足 → 推奨スペック採用

アンチパターン: コスト削減のため Storage Gateway VMを vCPU×2・RAM 4GB で構成。高負荷時にCPUが100%張り付き、ファイルアクセスが極端に遅くなった。

正解パターン: AWS 推奨の最小スペック以上で構成する。

高負荷環境（1日あたり書き込み1TB超）では vCPU×8・RAM 32GB 以上を推奨。Gateway VMのメトリクス（CPU・メモリ・キャッシュHit率）をCloudWatchで常時監視し、閾値超過時にインスタンスタイプを変更する。

アンチパターン4: Mainframe Wave単位粒度過大 → 業務サブシステム単位の細分化

アンチパターン: 「COBOL系バッチ全部を一括移行」というWave設計にしたため、1Waveに300本のJCLが含まれた。パラレルランで差分が出た際の原因特定に3週間かかった。

正解パターン: 1Wave = 1業務サブシステム（最大15〜20本のJCL）に細分化する。

悪い例:
  Wave1: バッチ系全体（JCL 300本）

良い例:
  Wave1-A: 売上日次集計バッチ（JCL 12本）
  Wave1-B: 在庫管理バッチ（JCL 18本）
  Wave1-C: 請求書生成バッチ（JCL 9本）
  ...

細分化のメリット:
– 差分発生時の原因特定が容易（影響範囲が小さい）
– Wave単位のロールバックが現実的な規模に収まる
– パラレルラン期間を短縮できる（検証対象が少ない）

アンチパターン5: MGN テストカットオーバー省略 → Test Launch必須

アンチパターン: スケジュールが厳しいため Test Launch をスキップし、直接 Production Launch を実行。本番環境でアプリが起動しないことが判明。深夜の緊急対応が発生。

正解パターン: 本番カットオーバー前に必ず Test Launch を実行し、全アプリの動作確認を完了させる。

# MGN Test Launch の実行と結果確認
aws mgn start-test \
  --source-server-ids '["s-0abc123def456789a"]' \
  --region ap-northeast-1

# Test Launch 完了後の確認項目
# 1. EC2インスタンスが「Running」状態になること
# 2. アプリケーションのヘルスチェックURL が200を返すこと
# 3. ログに起動エラーがないこと
# 4. DB接続が正常に確立されること

# Test 完了後は必ず削除（テストインスタンスの費用が継続発生するため）
aws mgn terminate-target-instances \
  --source-server-ids '["s-0abc123def456789a"]' \
  --region ap-northeast-1

Test Launch は本番環境とは独立した EC2 インスタンスで実行され、本番レプリケーションに影響を与えない。Test Launch 後もレプリケーションは継続されるため、本番カットオーバーへの影響はない。

Vol1 × Vol2 統合移行アーキテクチャ + 選定フローチャート

AWS Migration & Transfer サービス群は「データ移行・転送基盤（Vol1）」と「サーバ移行・物理輸送・ハイブリッドストレージ・MF近代化（Vol2）」の二軸で構成される。Vol1 では DMS・SCT・Migration Hub・Transfer Family・DataSync の5サービスが「データを移す・変換する・同期する」役割を担い、Vol2 では MGN・Snow Family・Storage Gateway・Mainframe Modernization の4サービスが「サーバを動かす・物理データを運ぶ・オンプレをAWSと橋渡しする・レガシーシステムを刷新する」役割を担う。

二部作を通じて学んだ各サービスの役割を統合的に理解することで、「データベース移行」から「大容量ファイル物理輸送」「サーバ丸ごと移行」「メインフレーム近代化」まで、オンプレミス環境に存在するあらゆる資産をAWSへ移行するための完全な設計フレームが完成する。本章では2つのVolを組み合わせた統合移行アーキテクチャと、移行対象の性質に応じた最適サービス選定フローチャートを提供する。

本章で提供する設計指針は以下の4点である。第一に「Migration & Transfer 全9サービス役割分担一覧」で各サービスの責務を明確化する。第二に「Mermaid02 統合選定フローチャート」で移行対象の性質に応じた最適サービス選定パスを示す。第三に「統合移行プロジェクトの典型6フェーズ」でサービスの時系列的な連携を示す。第四に「大規模・中規模の統合パターン」で実際のプロジェクト設計に使えるテンプレートを提供する。

→ Migration & Transfer本番運用 Vol1（データ移行・転送基盤 DMS × SCT × Hub × Transfer × DataSync 編）を読む

Migration & Transfer 全9サービス役割分担一覧

Vol1の5サービスとVol2の4サービスを合わせた全9サービスの役割分担を整理する。移行プロジェクト設計時には、この一覧を参照して必要なサービスを漏れなく選定すること。各サービスの「主な役割」欄に記載された用途が移行要件と一致するかどうかをチェックし、選定理由をアーキテクチャ設計書に明記することを推奨する。

Mermaid02: Vol1×Vol2 統合選定フローチャート

移行対象の性質と制約条件（ネットワーク帯域・データ容量・コード改修許容度・ダウンタイム許容時間）によって推奨サービスの組み合わせは大きく変わる。フローチャートはまず「何を移行するか」の大分類から始まり、各分岐で制約条件に応じた具体的な推奨サービスを導出する。複数の移行対象が存在する場合は、それぞれのパスを辿って必要なサービス群を列挙し、最終的に Migration Hub で一元管理する。

選定フローチャートの活用手順:

1. 移行対象の種別（DB / ファイル / サーバ / メインフレーム / テープ）を特定する
2. 各分岐の質問に回答し、推奨サービスのノードに到達する
3. 複数の移行対象がある場合は、それぞれのパスを辿り、必要なサービス群を列挙する
4. 全サービスを Migration Hub に集約し、プロジェクト全体の進捗を一元管理する
5. 選定したサービス群をもとに「フェーズ別サービス活用計画」を作成し、ステークホルダーと合意する

フローチャートの注意点として、移行対象が複数ある場合は各パスを独立して辿ること。例えば「サーバ500台 + Oracle DB 30本 + テープアーカイブ 100TB」という移行要件の場合、Q1 から3つのパス（MGN / DMS → SCT / Snow Family）をそれぞれ辿り、必要なサービス群を「MGN + DMS + SCT + Snowball Edge + Tape Gateway + Migration Hub」として確定する。

flowchart TD
 START([移行対象を特定]) --> Q1{何を移行するか?}

 Q1 -->|データベース| Q2{DB移行の種別?}
 Q1 -->|ファイル・オブジェクト| Q3{ネットワーク帯域は十分か?}
 Q1 -->|サーバ・VM| Q4{移行サーバの特性?}
 Q1 -->|メインフレーム| Q5{コード改修の許容度?}
 Q1 -->|テープバックアップ| TAPE[Tape Gateway<br>iSCSI VTL互換接続]

 Q2 -->|同種DB・継続同期必要| DMS[AWS DMS<br>継続レプリケーション + CDC]
 Q2 -->|異種DB・スキーマ変換必要| SCT[AWS SCT → DMS<br>スキーマ変換 + 移行]

 Q3 -->|帯域十分・オンライン転送可| DS[DataSync<br>エージェント配置・高速同期]
 Q3 -->|帯域不足・大容量TB級| Q3a{容量規模は?}
 Q3a -->|8TB以内・辺境環境| CONE[Snowcone<br>小型・軽量・IoT対応]
 Q3a -->|80TB以内・標準輸送| SBE[Snowball Edge<br>Storage Optimized]
 Q3a -->|クラスタ・Edge処理必要| SBE2[Snowball Edge<br>Compute Optimized × クラスタ]

 Q4 -->|Windows / Linux サーバ| MGN[MGN<br>エージェント + Wave設計 + カットオーバー]
 Q4 -->|SFTP / FTP サーバ| TF[Transfer Family<br>SFTP / FTPS マネージド移行]
 Q4 -->|オンプレ継続 + AWS接続| SGV[Storage Gateway<br>File / Volume Gateway]

 Q5 -->|コード改修OK・Java変換| BLUAGE[Mainframe Modernization<br>AWS Blu Age リファクタ]
 Q5 -->|コード改修最小・互換重視| MICROFOCUS[Mainframe Modernization<br>Micro Focus リプラットフォーム]

 DMS --> HUB[Migration Hub<br>全移行進捗一元管理]
 SCT --> HUB
 DS --> HUB
 SBE --> HUB
 SBE2 --> HUB
 CONE --> HUB
 MGN --> HUB
 BLUAGE --> HUB
 MICROFOCUS --> HUB
 TAPE --> HUB
 TF --> HUB
 SGV --> HUB

 HUB --> DONE([移行完了 — AWS環境への定着])

統合移行プロジェクトの典型フェーズ

大規模オンプレミス → AWS 移行プロジェクトは以下の6フェーズで進行する。各フェーズで活用するVol1 / Vol2サービスの組み合わせを正確に把握することが移行成功の鍵である。特に「Phase 3 事前データ転送」では Vol1・Vol2 の複数サービスが並走するため、スケジュール調整と進捗管理が最重要になる。

Vol1 × Vol2 統合設計のチェックポイント

統合移行アーキテクチャを設計する際に見落としやすいポイントを以下に示す。設計レビュー時のチェックリストとして活用すること。

• DB移行とサーバ移行のタイミング整合: DMS CDC によるDB継続レプリケーションとMGN Wave実行のカットオーバーを同じタイミングに揃えること。DBカットオーバーとサーバカットオーバーがずれると、アプリとDBが異なる環境を向く「スプリットブレイン」状態になる。
• Snow Family 物理輸送期間の事前計上: Snow Family の物理輸送には2〜4週間かかる。DataSync によるオンライン転送と並走して事前転送を実施し、カットオーバー直前のデータ差分をDataSyncのみで補完する計画を立てること。
• Storage Gateway キャッシュサイジングの事前設計: 移行後もオンプレ拠点が継続運用する場合は、Storage Gateway のキャッシュ容量をWave実行前に決定しておく。ホットデータ率 × 業務量 × 7日Working Set で算出し、余裕を持った容量にすること。
• Mainframe 移行はMGN Waveと分離して設計: Mainframe Modernization の移行タイムラインはMGN Waveとは別に設計する。MF移行はリファクタ/リプラットフォームの開発工程が伴うため、通常のサーバ移行より1〜2年長い期間が必要になる。
• Transfer Family の移行後役割の確認: Transfer Family は「移行ツール」ではなく「移行後も継続稼働するマネージドSFTPサーバ」である。移行後のファイル受信アーキテクチャとして継続運用するかどうかを事前に決定すること。
• Migration Hub への全サービス統合: DMS / MGN / Snow Job のすべてを Migration Hub でトラッキングする。各サービスが独立して進捗を管理すると、ステークホルダーへの報告コストが膨大になり、問題検知が遅れる。
• ロールバック可逆性の維持期間設定: MGN は本番カットオーバー後も継続レプリケーションを維持することで旧環境への切戻しが可能。旧環境保持期間（通常2〜4週間）を明示的に設定し、全関係者に周知してから旧環境を廃棄すること。
• DataSync とSnow Family の役割分担明確化: オンライン転送（DataSync）と物理輸送（Snow Family）は排他ではなく補完的に使う。大容量データはSnowで先行輸送し、輸送期間中の増分はDataSyncで継続同期するハイブリッド転送が最もコスト効率が高い。
• アセスメントフェーズでの Migration Hub 早期導入: Migration Hub はアセスメントフェーズから導入し、インベントリ収集・依存関係マッピング・Wave優先度付けを一元管理する。後続のDMS / MGN / DataSync 全サービスをHubに接続することで、プロジェクト全体の進捗をリアルタイムに可視化できる。
• SCT の事前変換レポート活用: DMS による異種DB移行の前に、SCT の変換レポートで「自動変換可能」と「手動変換が必要」な箇所を事前に分類すること。手動変換量がWave実行スケジュールに与える影響を過小評価すると、DBカットオーバーがサーバ移行のボトルネックになる。

Vol1 × Vol2 サービス間連携の典型データフロー

移行フェーズを通じて Vol1 / Vol2 のサービスは以下のように連携する。どのフェーズでどのサービスがデータを受け渡すかを把握することで、移行設計の全体像が明確になる。

この連携フローを設計に組み込むことで、Vol1 / Vol2 が独立した「点」ではなく、移行プロジェクト全体を流れる「線」として機能することが理解できる。各サービスの依存関係と連携タイミングを明示した移行設計書を作成することを推奨する。このデータフロー表をベースに、プロジェクト固有の制約（ダウンタイム許容時間・ネットワーク帯域・コンプライアンス要件）を重ね合わせてカスタマイズすること。

以上のサービス間連携パターンを踏まえた上で、次に実際の移行設計に即した「大規模エンタープライズ」と「中規模ハイブリッド」の2つの統合パターンを示す。

Vol1 × Vol2 移行規模別サービス選定マトリクス

移行規模と移行対象の組み合わせに応じた推奨サービス選定を以下に整理する。プロジェクト初期段階での概算コスト見積もりと選定根拠の説明資料として活用すること。

この選定マトリクスは概算の参考指針である。実際のプロジェクトでは、ネットワーク帯域・コンプライアンス要件・ダウンタイム許容時間・予算制約を踏まえた詳細設計が必要である。Migration Hub を早期に導入して移行対象のインベントリを収集し、データドリブンな意思決定を行うことを推奨する。

§7 まとめ: Vol1×Vol2 統合移行設計の本質

Migration & Transfer Vol1 と Vol2 の二部作を通じて理解できる最も重要な設計原則は、「データ移行とサーバ移行は並走するが、独立して管理する」という点である。

• 並走の必要性: DB継続同期（DMS）とサーバWave移行（MGN）は同じ移行期間に並走する。両者が切り離されると、サーバはAWSに移行済みなのにDBが旧環境に残るという「スプリットブレイン」が発生する。
• 独立した管理の必要性: 一方で、DB移行とサーバ移行はそれぞれ独自の依存関係・スケジュール・リスクを持つ。同一のWave設計書に両方を詰め込むと、どちらかのリスクが他方に波及する。DB移行計画とサーバ移行計画は別ドキュメントとして管理し、Migration Hubで統合的に進捗を可視化することが最善の設計パターンである。
• 物理輸送は事前完了が原則: Snow Familyによる物理輸送は、Wave実行開始の8週間前には着手する。物理輸送が遅延すると、Wave実行全体のタイムラインが後ろ倒しになる。
• Storage GatewayとMainframe近代化は長期運用前提: これら2サービスは「移行完了後も継続稼働するアーキテクチャコンポーネント」である。MGNやDMSが「移行完了後に役割を終える一時的ツール」であるのと対照的。Storage GatewayとMF Modernizationを移行後の恒久アーキテクチャとして設計することが重要である。

Vol1×Vol2の9サービスを統合した移行アーキテクチャは、単なる「サービス一覧」ではなく、移行フェーズを通じて連携する「動的なデータ・システム移行フロー」として設計すること。それが Migration & Transfer 二部作の最大の設計実践知識である。

選定フローチャートと統合設計のチェックポイントを活用し、プロジェクト初期段階でVol1 / Vol2 両軸のサービス選定を確定させること。移行設計の遅延は波及的にWave実行スケジュールを後ろ倒しにするため、アセスメントフェーズでの早期確定が最も費用対効果が高い投資となる。Migration & Transfer 二部作を読んだ読者は、本章で提示したフローチャートと統合パターンを、実際のプロジェクト設計書のたたき台として活用してほしい。

まとめ — Migration & Transfer 二部作完成 + 全軸クロスリンク + 65記事化告知

§8-1: Migration & Transfer 二部作完成宣言

AWS Migration & Transfer 本番運用シリーズは、本記事（Vol2）の完成をもって二部作が揃い、第26軸目が完結する。

Vol1（データ移行・転送基盤 編）では DMS による継続レプリケーション・SCT による異種DBスキーマ変換・Migration Hub による進捗一元管理・Transfer Family によるマネージドSFTP・DataSync による高速オンライン同期の5サービスを深堀りした。「データそのものをどう移行し、継続同期し、スキーマを変換するか」に焦点を当てた設計実践知識を体系化した。

→ Migration & Transfer本番運用 Vol1（データ移行・転送基盤 DMS × SCT × Hub × Transfer × DataSync 編）

Vol2（本記事：サーバ移行・物理輸送・ハイブリッドストレージ・MF近代化 編）では MGN によるエージェント配置・Wave設計・カットオーバー手順・ロールバック戦略、Snow Family による物理輸送ライフサイクル・クラスタ運用、Storage Gateway による File/Volume/Tape 3種運用・キャッシュサイジング、Mainframe Modernization によるリファクタ vs リプラットフォーム判断の4サービスを深堀りした。「サーバとストレージの物理・論理移行をどう設計するか」に焦点を当てた設計実践知識を体系化した。

二部作を合わせることで、「データを移す」×「サーバを動かす」×「物理データを運ぶ」×「オンプレをAWSと繋ぐ」×「レガシーを刷新する」の全5移行動詞をカバーする Migration & Transfer 完全体が完成する。

第26軸目完結・65記事化達成: 本記事の完成により、AWSサービス本番運用シリーズは第26軸目を二部作で完成させ、合計65記事を達成する。引き続き全軸シリーズとして AWS 本番運用の設計実践知識を体系化し続ける。

Vol1とVol2を統合して理解することで獲得できる設計力:
– (a) MGN でエージェント配置・Wave設計・launch template・カットオーバー手順・ロールバック戦略を確立できる
– (b) Snow Family で Snowball Edge/Snowcone 選定・物理輸送ライフサイクル・物理セキュリティ・クラスタ運用を構築できる
– (c) Storage Gateway で File/Volume Cached・Stored/Tape 3種運用・キャッシュサイジング・SMB/NFS認証を設計できる
– (d) Mainframe Modernization でリファクタ vs リプラットフォーム判断・Micro Focus/AWS Blu Age 活用・Wave Group設計を実装できる
– (e) Vol1×Vol2 統合移行アーキテクチャでデータ+サーバの両軸を一つの設計フレームで表現できる
– (f) 詰まり7選 + アンチパターン演習5問でサーバ移行・物理輸送設計力を実践レベルで習得できる

§8-2: Vol2 学習達成サマリ

§8-3: 4サービス 本番運用 重要設定一覧

4サービス 本番運用 要点まとめ（表）

MGN 本番運用 重要設定一覧

Snow Family 本番運用 重要設定一覧

Storage Gateway 本番運用 重要設定一覧

Mainframe Modernization 本番運用 重要設定一覧

§8-4: 全軸クロスリンク

本記事（Migration & Transfer Vol2）と関連度が高いシリーズを以下に整理する。移行プロジェクトの全体設計には、データ移行・ネットワーク・データベース・ストレージの各軸の知識が不可欠である。

関連性: 最高

• Migration & Transfer本番運用 Vol1（DMS × SCT × Migration Hub × Transfer Family × DataSync） — 本記事の二部作ペア。データ移行・転送基盤の深堀り。Vol2のMGN/Snowと組み合わせて移行全体設計が完成する

関連性: 高

• Database本番運用 Vol1（RDS × Aurora × DynamoDB） — MGN移行後のDB本番運用基盤。DMSのターゲットDB運用設計の基礎
• Storage本番運用 Vol1（S3 × EFS × FSx × Storage Gateway） — Storage GatewayのバックエンドS3/EFS運用設計。Snow Family移行後のS3ライフサイクル設計
• Network Hybrid専門編（Direct Connect × VPN × Transit Gateway） — MGNレプリケーション・Storage Gatewayのオンプレ接続に必須なハイブリッドネットワーク設計
• コスト最適化 Vol1 — 移行後のAWSコスト試算・TCO比較・6Rsのコスト評価に必須
• Migration本番運用 Vol1（DMS × MGN × Snow Family × AMS） — 旧シリーズ。サーバ/アプリケーション移行（Re-host/Re-platform）の概観。本記事は同テーマの深堀り編

移行プロジェクト全体設計のための推奨学習順序

移行プロジェクトに携わるCloud Architect / Migration Engineerには以下の学習順序を推奨する:

1. Migration & Transfer Vol1（データ転送軸の設計）
2. Migration & Transfer Vol2（本記事：サーバ移行軸の設計）
3. Network Hybrid編（オンプレ-AWS間接続基盤の設計）
4. Database本番運用 Vol1（移行先DBの設計）
5. Storage本番運用 Vol1（移行先ストレージの設計）

この順序で学習することで、「オンプレ → AWS」の全移行工程を設計できるCloud Architectとしての体系的な知識が身につく。

§8-5: 結び — Migration & Transfer 二部作完成と今後のシリーズ

AWS Migration & Transfer 本番運用シリーズ（Vol1 + Vol2）を通じて、「データを移す」「サーバを動かす」「物理データを運ぶ」「オンプレをAWSと繋ぐ」「レガシーを刷新する」という5つの移行動詞を体系的に学習した。9サービスの本番運用ノウハウを統合することで、大規模エンタープライズ移行から中規模ハイブリッド移行まで、あらゆる規模・形態のAWS移行を設計できる実践的な知識が身についた。

第26軸目の完成により、AWSサービス本番運用シリーズは65記事を達成した。各軸は独立して学習できるが、統合的に組み合わせることでAWS全体の設計力が飛躍的に向上する。シリーズ全体を通じてAWS本番運用の設計実践知識の体系化を継続する。