Migration要件から最適なApproachを選択する

これまで、アプリケーション、データ、データベース、ネットワーク、ID、ガバナンス、セキュリティについて、それぞれの移行判断を確認してきました。

実際のワークロード移行では、これらを個別に選んだだけでは移行アーキテクチャは完成しません。

最終的には、すべての移行要件を同時に満たす組み合わせになっているかを確認します。

1. 移行アーキテクチャはサービスを1つ選ぶ問題ではない

1つの業務システムでも、移行対象は複数の要素に分かれます。

例えば、

アプリケーションサーバー

共有ファイル

データベース

ネットワーク

DNS

ID基盤

移行先アカウント

セキュリティ統制

などです。

これらすべてを1つのAWSサービスで移行する必要はありません。

例えば、

アプリケーション転送
→ AWS Transform MGN

データベース転送
→ AWS DMS

データ転送
→ AWS DataSync

ネットワーク
→ AWS Direct Connect

ID
→ 既存Active Directoryとの統合

ガバナンス / セキュリティ
→ 既存ランディングゾーンの統制

のように、役割ごとに異なる方式を組み合わせることができます。

重要なのはサービス数を減らすことではなく、各要件を満たす方式を組み合わせた結果、システム全体として移行可能になっていることです。

2. 最初にワークロードを移行対象の単位へ分解する

移行アーキテクチャを選ぶときは、まずワークロードを構成する要素を整理します。

アプリケーション転送方式だけを決めても、データベース、共有ファイル、認証、ネットワークが利用できなければ、アプリケーションは本番稼働できません。

したがって、各要素の方式を選んだ後に、相互依存関係を含めて1つの移行アーキテクチャとして成立するかを確認します。

3. 異なる移行方式の準備状態を共通基準へ変換する

AWS Transform MGN、AWS DMS、AWS DataSyncなどを組み合わせると、それぞれで確認する状態が異なります。

例えば、

AWS Transform MGN
→ テスト起動やカットオーバー準備

AWS DMS
→ タスク状態やレプリケーション遅延

AWS DataSync
→ タスク実行結果や最終同期

といった違いがあります。

このとき、「各担当チームが正常と言っている」だけでは、システム全体として切り替え可能かを判断しにくくなります。

そこで、各コンポーネントについて、

対象

使用する移行方式

担当者

準備完了と判断する条件

確認証跡

未解決の阻害要因

依存する他コンポーネント

を共通の移行準備表へまとめます。

重要なのは、異なるサービス固有の状態をそのまま比較するのではなく、「このコンポーネントは切り替え可能か」という共通の判断へ変換することです。

4. データ転送はアプリケーション転送とは独立して選ぶ

アプリケーションサーバーをリホストする場合でも、大容量の共有ファイルまで同じ方式で扱うとは限りません。

例えば、

サーバーOS / アプリケーション
→ AWS Transform MGN

NFS共有データ
→ AWS DataSync

のように分離できます。

取引先がSFTPで継続的にファイルを送信する要件なら、移行後のファイル受付方法としてAWS Transfer Familyが関係する場合もあります。

したがって、

アプリケーション転送
=
データ転送

とは考えません。

各要素に適した方式を選び、その後に切り替え条件を統合します。

5. ネットワーク・ID・ガバナンス・セキュリティを成立条件へ含める

アプリケーション、データ、データベースの転送方式が決まっても、それだけでは移行アーキテクチャは完成しません。

これまで確認した、

ネットワーク経路

ID基盤

移行先アカウントとOU

組織統制

移行ツールのセキュリティ

なども成立している必要があります。

ここではこれらを個別に再設計するのではなく、選択済みの方式が、統合された移行アーキテクチャの前提条件として成立しているかを確認します。

例えば、AWS側サーバーは起動できるが必要なID基盤へ接続できないという状態なら、利用者はアプリケーションを利用できません。

同様に、移行ツールは動作しても移行先アカウントに必要な統制が適用されていないなら、移行開始条件を満たしていない可能性があります。

6. 複数方式が共有する前提条件を確認する

各移行方式は単独で動作するのではなく、共通の基盤を利用することがあります。

例えば、

同じネットワーク接続

同じDNS

同じActive Directory

同じAWSアカウント

同じAWS KMSキー

同じセキュリティ承認

などです。

したがって、

方式A = 成立
方式B = 成立
方式C = 成立

だけを個別確認するのではなく、それらが共通利用する前提条件も成立しているかを確認します。

ここではネットワーク帯域などの個別設計を再度行うのではなく、すでに確定した要件を移行アーキテクチャ全体の依存条件として扱います。

7. 切り替え時には書き込み主体を明確にする

複数のデータ転送方式を組み合わせる場合は、切り替えの各段階で、どちらの環境が正しい更新元なのかを明確にします。

例えば、

オンプレミスアプリケーション

AWS側アプリケーション

オンプレミスデータベース

AWS側データベース

オンプレミス共有ファイル

AWS側共有ファイル

が一時的に並存することがあります。

このとき、同じ業務データに対して旧環境と新環境の両方から自由に書き込みを続けると、どちらの更新を正とするか、どちらのデータを同期するか、どの時点を正式な切り替えとするかが不明確になります。

そのため、移行アーキテクチャでは、例えば、

切り替え前
→ オンプレミス側を更新元とする

最終同期中
→ 必要に応じて更新を制御する

切り替え成立
→ AWS側を更新元とする

のように、書き込み主体が切り替わる時点を定義します。

これは単にデータ転送が成功したかを見るのではなく、複数の移行方式を1つの業務システムとして切り替えるための所有権移行を明確にするための判断です。

8. 共通のカットオーバー条件を定義する

各コンポーネントには、それぞれ切り替え可能になる条件があります。

例えば、

アプリケーション
→ テスト完了、最新状態で起動可能

データベース
→ 必要な同期状態へ到達

ファイルデータ
→ 必要な最終同期が完了

ネットワーク
→ AWS側への必要な通信経路が利用可能

ID
→ AWS側アプリケーションから認証可能

ガバナンス / セキュリティ
→ 必要な統制と承認が完了

という状態です。

これらのうち1つだけが準備できていても、依存するシステム全体を切り替えることはできません。

最終的には、必要なコンポーネントがすべてカットオーバー可能になったことを共通の移行準備表で確認してから切り替えます。

9. 移行アーキテクチャを対応表として整理する

複数の移行方式を組み合わせる場合は、単にAWSサービス名を並べるだけでは不十分です。

例えば次のように整理します。

この表の目的は、製品一覧を作ることではありません。

各方式と、その方式が成立するための横断依存関係を関連付けることです。

10. 異なる移行方式の間に引き継ぎ点を定義する

複数の移行方式を組み合わせると、ある作業の完了が、次の作業を開始する条件になることがあります。

例えば、

AWS DMSによるデータベース同期が切り替え可能な状態になる
↓
AWS DataSyncによる最終ファイル同期を完了する
↓
AWS Transform MGNでアプリケーションを切り替える
↓
DNSをAWS側へ切り替える

というように、複数の作業が順序関係を持つ場合があります。

このとき各担当者が「自分の作業は完了した」と判断できても、次の担当へいつ処理を引き渡してよいかが決まっていなければ、移行全体の実行手順は完成していません。

そこで、方式同士の境界ごとに、

前の作業が完了したと判断する条件

次の作業を開始する条件

引き継ぎを確認する担当者

確認に使用する証跡

開始できない場合の停止条件

を明確にします。

例えば、

AWS DMS
必要な同期状態を確認
↓
確認結果を記録
↓
データ移行担当から切り替え担当へ引き継ぐ
↓
AWS Transform MGNのカットオーバー開始

のように扱います。

この引き継ぎ点を明確にすると、前工程が未完了なのに次工程を開始する、複数チームが互いに相手の完了を待ち続ける、確認証跡がないまま次工程へ進む、といった問題を防ぎやすくなります。

重要なのは、各AWSサービスの操作手順を細かく再説明することではありません。

異なる移行方式を、明確な開始条件と引き継ぎ点で1つの実行可能な移行アーキテクチャへ接続することです。

11. 統合された移行アーキテクチャの例

次の要件があるとします。

アプリケーションサーバーは大きく変更せずAmazon EC2へ移す

PostgreSQLデータベースは更新を継続し、停止時間を短くする

NFS共有ファイルは切り替え直前まで更新される

AWS Direct Connectには必要な通信条件がある

既存Active Directoryを継続利用する

移行先アカウントには既存ガバナンスを適用する

この場合の候補は、

アプリケーション
→ AWS Transform MGN

データベース
→ AWS DMS Full Load + CDC

ファイルデータ
→ AWS DataSync

ネットワーク
→ AWS Direct Connect

ID
→ 既存Active Directoryとの統合

ガバナンス / セキュリティ
→ 既存ランディングゾーンの統制下で実施

となります。

ただし、サービスを選んだだけでは完了ではありません。

最後に、

各コンポーネントの準備完了条件

共有する前提条件

書き込み主体を切り替える時点

方式間の引き継ぎ点

ネットワーク

認証

ガバナンス

セキュリティ

を合わせて確認します。

このすべてが成立して初めて、移行アーキテクチャ全体が成立したと判断します。

12. 最終判断フロー

移行アーキテクチャを選択するときは、次の順序で考えます。

移行要件を整理
↓
アプリケーション / データ / データベースへ分解
↓
各転送方式を選択
↓
ネットワーク要件を統合
↓
ID要件を統合
↓
ガバナンス / セキュリティ要件を統合
↓
各コンポーネントの準備完了条件を共通化
↓
共有前提条件を確認
↓
書き込み主体の切り替えを定義
↓
方式間の引き継ぎ点を定義
↓
共通のカットオーバー条件を確認
↓
移行アーキテクチャを確定

SAP-C02では、個別の移行サービスを知っているだけではなく、複数の移行方式とネットワーク、ID、ガバナンス、セキュリティを組み合わせ、既存ワークロードの要件をすべて満たす移行アーキテクチャを選択できることが重要です。