クラウド移行Waveプランニング入門｜アプリケーション依存関係の分析から移行順序の設計・カットオーバー計画まで実践ガイド

オンプレミスで稼働するシステムをクラウドへ移行するとき、真っ先にぶつかる問いがあります。「どのアプリケーションから、どの順番で移すか」です。

システム数が数十～数百規模になると、全システムを同時にクラウドへ移すのはリスクが大きすぎます。かといって順番を誤ると、依存関係の切れたシステムが宙ぶらりんになり、本番障害につながります。一部のシステムだけクラウドに移したところ、オンプレ側に残った業務DBへの接続が断たれて一時的にサービス停止した、というよくある事例が物語るように、移行順序の設計は移行作業そのものと同じくらい重要です。

この問題を解決するのがWaveプランニングです。移行対象を複数のWave（波）に分割し、低リスクなものから段階的にクラウドへ移行していく設計手法で、大規模な移行プロジェクトでは事実上の標準アプローチとなっています。

この記事では、Waveプランニングの考え方から、依存関係の洗い出し手順、Wave分割の優先順位付け、カットオーバー計画の組み立て方まで、現場で実際に使える判断基準を解説します。

Waveプランニングとは？移行を「波」に分ける理由

Waveプランニングとは、移行対象のアプリケーションやシステムを複数のグループ（Wave）に分け、段階的に移行を進める計画手法です。一般的には以下のように構成します。

・Wave 0: クラウド基盤の整備（VPC、IAM、DNS、ランディングゾーン構築）
・Wave 1: 依存関係が少なく、リスクの低いワークロード
・Wave 2: 中程度の依存関係を持つワークロード
・Wave 3以降: コアシステム・複雑な依存関係を持つワークロード

オンプレ時代の計画停止型メンテナンス（一括停止→移行→再起動）と違い、Waveアプローチは「移行したシステムが動いている状態で次のWaveを移行する」という継続運用が前提です。このため、移行期間中はオンプレとクラウドが並行稼働する期間が生まれます。

なぜこのアプローチが有効かというと、理由は3つあります。

・リスクの局所化: 1つのWaveで問題が起きてもロールバックできる範囲が限定される
・チームの学習: 初期WaveでAWS/Azureの運用ノウハウを習得してから難易度の高いシステムに臨める
・ビジネス影響の最小化: 重要度の低いシステムから移行し、コアシステムは準備が整ってから移せる

ステップ1 依存関係を洗い出す3つのアプローチ

Waveを設計するには、まずどのシステムがどのシステムに依存しているかを可視化する必要があります。代表的な3つのアプローチを紹介します。

1. 自動検出ツールで通信ログを収集する

AWSの場合、AWS Application Discovery Serviceのエージェントをオンプレサーバーにインストールすると、実際のTCP接続ログを収集してシステム間の通信依存関係を可視化できます。AzureでもAzure Migrateの依存関係マッピング機能（Service Mapエージェント）が同様の機能を提供しています。

ツールによる自動収集の利点は、設計書に記載されていない「暗黙の依存関係」（例: 深夜バッチが別のサーバーのAPIを直接呼び出している）を発見できることです。収集期間は最低でも2週間、月次バッチがある場合は1か月分のデータを取得することを推奨します。

2. 設計書・CMDBと突合してホワイトリストを作る

自動検出ツールが取得したデータを、既存の設計書やCMDB（構成管理DB）と突合します。設計書に記載のある通信と、ログで実際に観測された通信を照合することで、

・設計書にあるが実際には使われていない通信（廃止候補）
・設計書にないが実際には使われている通信（未文書化依存関係）

の2種類を洗い出せます。未文書化依存関係は移行計画から漏れるリスクが最も高いため、アプリケーションオーナーへのヒアリングで確認します。

3. ネットワークキャプチャ・フローログによる補完

エージェントをインストールできないシステム（レガシーOSや組み込み系）については、ネットワークスイッチのフローログやファイアウォールのACLログを使って通信ペアを抽出します。VPCへの移行後はVPC Flow Logsが同じ役割を担います。

ステップ2 Wave分割の優先順位マトリクス

依存関係が可視化できたら、次はどのシステムをどのWaveに割り当てるかを決めます。よく使われる判断軸が「移行複雑度」と「ビジネスインパクト」の2軸マトリクスです。

このマトリクスに加えて、以下の要素も各Waveへの割り当てに影響します。

・ライセンス制約: Windowsのライセンスやソフトウェアベンダーのクラウド対応状況
・コンプライアンス要件: 個人情報を扱うシステムは規制対応が完了してから移行
・ハードウェア保守期限: 保守切れのサーバーは別の優先順位で前倒しを検討
・チームのクラウドスキル: 初期Waveは学習コストを見込んだスケジュールにする

ステップ3 Wave 0～Wave 3の設計パターン（想定例）

実際のWave設計がどのようなものか、オンプレから50システムをAWSへ移行するプロジェクトを想定例として示します。

Wave 0 — クラウド基盤整備（移行前の準備、システム移行はゼロ）

Wave 0はアプリケーションを1つも移行しないフェーズです。移行を受け入れるクラウド側の基盤を整備します。

・AWSのランディングゾーン構築（AWS Control Tower + Organizations）
・VPCとサブネット設計、Transit Gateway設定
・DirectConnect / Site-to-Site VPNによるオンプレとの閉域接続
・IAMポリシー・SCPの基盤設計
・ログ集約基盤（S3 + CloudWatch Logs）の構築
・移行ツールのインストールと動作確認

Wave 0が完了していないうちに移行を始めると、後から基盤を変更するたびに移行済みシステムに影響が出ます。焦らずここで土台を固めるのが鉄則です。

Wave 1 — 低リスクワークロード（想定: 10システム、期間: 2か月）

Wave 1の対象は「壊れても影響が限定的で、外部依存が少ないシステム」です。

・社内向け開発・テスト環境
・アーカイブ用の静的コンテンツサーバー
・社内ツール（Wiki、ドキュメント管理）
・外部との接続がなく、データ量の少ないバッチ処理

Wave 1の目的は移行自体の成功だけでなく、チームがクラウドの運用に慣れることです。ここでAWS Application Migration Service（MGN）を使ったリホストの手順を確立しておくと、以降のWaveでの作業効率が上がります。

Wave 2 — 中程度のワークロード（想定: 20システム、期間: 3か月）

Wave 2では、複数のシステムが依存し合っているアプリケーション群を移行します。ポイントはグループ単位で同時に移行することです。依存しているシステムを別々のWaveに分けると、オンプレとクラウド間のクロス通信が発生し、DirectConnect/VPNの帯域や遅延が問題になります。

DBレイヤーの移行が必要なシステムにはAWS DMSを使った継続レプリケーションを設定し、カットオーバー直前まで同期を保ちます。

Wave 3 — コアシステム（想定: 20システム、期間: 4か月）

受発注、在庫管理、基幹DBなど、停止が許されないシステムを対象にします。Wave 3では移行作業に加えて、以下の準備が必要になります。

・カットオーバーリハーサル（本番と同等のデータ量でテスト）
・監視・アラート体制のクラウド側への移行
・顧客やパートナーへのメンテナンス告知
・ロールバック手順の文書化とチームへの教育

ステップ4 カットオーバー計画の3要素

各Waveのカットオーバーを設計するときに必ず検討すべき3つの要素があります。

1. カットオーバーウィンドウの設定

カットオーバーウィンドウとは、旧環境（オンプレ）から新環境（クラウド）へ切り替える作業時間枠です。設定の基準は以下の通りです。

・ビジネス影響が最小になる時間帯を選ぶ（深夜・週末・月初直後を避けるなど）
・ウィンドウ時間内に完了できないと判断したらロールバックを判断するタイムボックスを設ける
・「戻す場合はT+2時間以内に決断する」など、明確なロールバック判断基準を事前合意しておく

2. ロールバック計画

カットオーバーが失敗したときに、元のオンプレ環境へ戻せる状態を常に維持します。

・DBの場合はDMS継続レプリケーションを使ってクラウド→オンプレの逆レプリケーションも有効にしておく
・DNSのTTLを事前に短縮（例: 300秒→60秒）しておき、切り戻し時のDNS浸透時間を短くする
・ロールバックの手順書はカットオーバー手順書と別に作成し、担当者を分けて訓練しておく

3. 並行稼働期間の設計

多くのプロジェクトで、カットオーバー直後に「様子見期間」として両環境を稼働させます。この期間中はオンプレへのトラフィックを段階的にゼロにしていきます。

・初日: クラウドへ10%のトラフィックを流す（カナリアリリース的に）
・3日後: 問題がなければ50%
・1週間後: 100%クラウドへ切り替え、オンプレを停止待機に
・1か月後: オンプレリソースを廃止

ただし並行稼働を長引かせると、2つの環境を維持するコストが増大します。コスト試算を行い、並行稼働の上限期間をプロジェクト開始前に決めておくことが重要です。

Waveプランニングでよく起きる失敗パターン

Waveプランニングを進める中でよく見られるつまずきを整理します。

・依存関係調査が不十分なままWaveを確定する: 後から隠れた依存関係が発覚してWave計画を大幅に組み替えることになります。エージェントを少なくとも2週間稼働させてからWaveを設計してください
・Wave 1に難易度が高いシステムを混ぜる: 「早く移行して成果を示したい」という意識から、本来Wave 3に入るべきシステムをWave 1に入れてしまいます。最初のWaveで移行失敗が起きると、プロジェクト全体の士気とスケジュールに大きな影響を与えます
・Wave 0を省略する: 基盤整備を後回しにして移行を始めると、VPC設計の変更やIAMポリシーの修正が移行済みシステムに波及します。Wave 0は省略不可です
・1つのWaveに詰め込みすぎる: 1Wave 20システム以上を短期間で移行しようとすると、カットオーバー集中日に問題が重複して対応が追いつかなくなります。1Waveのシステム数は移行チームの体制に合わせて上限を設けてください
・ロールバック手順を作らずに進める: 「戻すことはないだろう」という楽観的な前提でロールバック計画を省略するケースがありますが、実際に必要になったときに手順がないと混乱します

AWSとAzureのWave計画支援ツール

主要クラウドはWaveプランニングを支援するツールを提供しています。

AWS Migration Hubは複数の移行ツール（MGN、DMS、CloudEndure）の進捗を一元管理できるダッシュボードを提供しており、Wave単位でのステータス管理に有効です。AWSコンソールからMigration Hubにアクセスすると、各Wave内の移行進捗をアプリケーション単位で追跡できます。

移行計画の見直しタイミング

Waveプランニングは一度作成したら固定するものではありません。以下のタイミングで定期的に見直すことが重要です。

・Wave 1完了後: 実績ベースの所要時間・コストデータをもとに以降のWaveのスケジュールを修正する
・隠れた依存関係が発覚したとき: Wave計画の再編が必要かどうかを即座に判断し、プロジェクトオーナーに報告する
・ビジネス要件が変わったとき: 新システムの追加や既存システムの廃止が決まったら、対象システムリストを更新する
・クラウド基盤の設計変更があったとき: Wave 0で構築した基盤に変更が入る場合は、以降のWaveへの影響範囲を確認する

本記事のまとめ

クラウド移行のWaveプランニングは、移行の成否を左右する重要な設計工程です。要点を整理します。

オンプレからクラウドへの移行は、ツールの使い方よりも「何を、どの順番で、どうやって切り替えるか」の計画精度が最終的な品質を決めます。Waveプランニングを丁寧に設計することで、移行期間中の本番障害リスクを大幅に下げることができます。