Migration Network Architecture

Migration Network Architectureでは、

オンプレミス
↓
AWS

へ接続できるだけでは不十分です。

移行期間中には、

移行データのレプリケーション

通常の業務トラフィック

オンプレミスに残る依存サービスとの通信

テスト通信

本番切り替え時の利用者トラフィック

問題発生時のロールバック通信

が同じ時期に存在する可能性があります。

そのため、

どのネットワークを使うか

だけではなく、

十分なBandwidthがあるか

障害時も移行を継続できるか

切り替え後の業務通信が成立するか

旧環境へ戻せるか

まで設計します。

1. Migration Networkは「データ転送経路」だけではない

Migration Networkを、

データをAWSへコピーするための回線

だけだと考えてはいけません。

移行期間には、

レプリケーション通信

既存業務通信

ハイブリッド通信

切り替え時の通信

などが共存します。

つまりMigration Network Architectureでは、

移行トラフィック

ハイブリッドアプリケーション通信

切り替えトラフィック

を分けて確認します。

2. Bandwidthは通常業務とMigrationを合算して考える

移行専用に見えるネットワークでも、実際には既存業務と共有されている場合があります。

例えば、

AWS Direct Connect
10 Gbps

通常業務ピーク
7 Gbps

移行レプリケーション
4 Gbps必要

なら、

7 + 4
=
11 Gbps

となります。

10 Gbps回線だから
4 Gbpsの移行通信も追加できる

とは判断できません。

確認するのは、

通常業務のピーク

レプリケーションの変更量

移行ウェーブの大きさ

追加データ同期

切り替え前後のトラフィック

です。

必要に応じて、

移行トラフィックを制限する

移行ウェーブを小さくする

業務ピークと時間帯を分ける

ネットワーク容量を増やす

といった対応を行います。

3. AWS Direct ConnectはMigrationの安定した基盤として利用できる

既にAWS Direct Connectを利用できる環境では、

大量レプリケーション

長期間のハイブリッド通信

切り替え後も残る
オンプレミス依存通信

のネットワーク基盤として利用できます。

ただし、

AWS Direct Connectがある
=
Migration Network完成

ではありません。

確認する必要があるのは、

Migrationに必要なBandwidthが残っているか

移行先VPCへのルーティングが成立しているか

切り替え後に必要な
オンプレミス通信を通せるか

単一障害点になっていないか

です。

移行トラフィックと本番トラフィックが同じAWS Direct Connectを共有するなら、容量設計が特に重要です。

4. Site-to-Site VPNをMigration用の別経路として使える

Site-to-Site VPNは、MigrationでAWS Direct Connectと役割を分けて利用できます。

例えば、

大量のレプリケーション
↓
AWS Direct Connect

小規模な別Migration Wave
↓
Site-to-Site VPN

のように、すべての移行通信を1つの接続へ集中させない構成も可能です。

Site-to-Site VPNが、

必要なプライベート接続を提供できる

対象通信量を処理できる

移行元と移行先へ必要なRouteがある

のであれば、小規模な移行通信や一時的な別経路として利用できます。

また要件に応じて、

AWS Direct Connect
+
Site-to-Site VPN

を異なるネットワーク経路として持つこともできます。

重要なのは、

Migrationでは
すべてAWS Direct Connect

または、

Migrationでは
すべてSite-to-Site VPN

と固定しないことです。

通信量と接続要件に応じて役割を分けます。

5. InternetをMigrationから完全に排除する必要はない

移行関連通信のすべてが必ず、

AWS Direct Connect
または
Site-to-Site VPN

を通る必要があるとは限りません。

例えば、

大量のレプリケーション
→ プライベート接続が必要

管理用API
→ パブリックAWSエンドポイントへのHTTPS
→ Internet利用可能

という要件なら、通信目的ごとに経路を分けることができます。

つまり、

MigrationにAWS Direct Connectを使う
=
移行関連通信を
すべてAWS Direct Connectへ固定

ではありません。

確認するのは、

通信先

通信量

プライベート接続要件

セキュリティポリシー

可用性要件

です。

Internet利用が許可され、パブリックエンドポイントで要件を満たせる通信まで、必ず専用のハイブリッドネットワークへ載せる必要はありません。

6. 移行トラフィックを通信目的ごとに分ける

Migration Networkを設計するときは、1本の線として考えるより、

データ通信

管理・制御通信

ハイブリッドアプリケーション通信

切り替えトラフィック

のように通信目的を整理します。

例えば、

大量レプリケーション
↓
AWS Direct Connect

小規模な移行通信
↓
Site-to-Site VPN

管理用HTTPS
↓
Internet

のように、それぞれ異なる経路を使用する場合があります。

重要なのは、

すべて同じ経路に統一する

ことではなく、

各通信が
要件を満たす経路を持つ

ことです。

7. RedundancyはMigration完了まで必要

Migration中にネットワークが停止すると、

レプリケーション停止

同期遅延増大

Migration Window超過

再同期や再レプリケーション

につながる可能性があります。

特に大規模Migrationでは、

数時間のネットワーク停止

が移行ウェーブ全体へ影響する場合があります。

そのため重要なMigrationでは、

複数のネットワーク経路

異なる障害ドメイン

バックアップ接続

を検討します。

例として、

複数のAWS Direct Connect接続

または

AWS Direct Connect
+
独立したSite-to-Site VPN

などがあります。

ただし、

同じ障害で
複数経路が同時停止する

構成では十分なRedundancyになりません。

8. Cutover Networkは事前に統合確認する

本番切り替えでは、Migration中に利用した接続だけではなく、

利用者からAWSへの通信

残存オンプレミスサービスとの通信

DNS

ロードバランサー

Firewall

Security Group

Network ACL

Bandwidth

Redundancy

などをまとめて確認します。

重要なのは、

レプリケーション完了
=
Cutover Network完成

ではありません。

Cutover Networkは、切り替え後の業務に必要な通信を成立させるためのネットワーク全体として確認します。

9. Amazon Route 53はCutover先を変えられるがNetworkを作るわけではない

Amazon Route 53を利用して、

旧環境
↓
AWS新環境

へ名前解決先を切り替えることができます。

しかし、

Amazon Route 53のDNSを変更
=
必要なVPC Routeや
Firewall設定も自動作成

ではありません。

Cutover Networkそのものは事前に完成させておく必要があります。

10. DNS TTLはCutover当日ではなく事前に考える

DNSによる切り替えでは、

Amazon Route 53側のレコードを変更した

瞬間に、すべてのクライアントが新しい接続先を見るとは限りません。

DNS Resolverやクライアントには、

TTLに基づくキャッシュ

があります。

例えば現在、

TTL
24時間

のレコードを使用している場合、

切り替え開始時に
TTLを60秒へ変更

しても、すでに24時間TTLでキャッシュされている回答は直ちには消えません。

TTLを変更できるレコードで短いTTLを使う場合は、

切り替えより十分前にTTLを短縮

↓

以前の長いTTLが失効する時間を確保

↓

切り替え

と計画します。

11. ロールバック期間中は旧環境への経路を維持する

本番切り替えが成功した直後でも、

問題が起きれば
旧環境へ戻す

というロールバック計画が残っている場合があります。

この期間に、

旧環境へのRoute

VPN

旧環境へ戻すDNS設定

必要なFirewall設定

を廃止すると、ロールバック計画が成立しなくなる可能性があります。

したがって、

Cutover成功
↓
ロールバック期間
↓
旧環境への経路を維持
↓
ロールバック不要を判断
↓
旧環境関連Networkを廃止

と考えます。

Migration完了と移行元環境の廃止は、同じタイミングとは限りません。

12. Cutover直前に確認する

Cutover Networkでは最低限、

1. 移行先へのRoute
2. Firewall / Security Group
3. ハイブリッド依存通信
4. Bandwidth
5. DNS / TTL
6. Redundancy
7. ロールバック経路と維持期間

を確認します。

13. 全体判断フロー

Migration対象と通信を整理
↓
Migrationに必要なBandwidthを計算
↓
通常業務トラフィックも合算
↓
必要なMigration Network容量を確保
↓

通信ごとの接続要件を確認
├─ 大量プライベート通信
│  → AWS Direct Connectを利用可能か確認
│
├─ 小規模なプライベート移行通信
│  → Site-to-Site VPNを利用可能か確認
│
└─ パブリックエンドポイント通信
   → Internet利用要件を確認

↓

Redundancyを確認
↓
移行 / レプリケーションを実行
↓
Cutover Networkを事前確認
↓
DNS / Route / 依存通信を確認
↓
トラフィックを切り替え
↓
ロールバック期間中は旧環境への経路を維持
↓
旧環境を廃止

SAP-C02では、Migration Networkを単なる「オンプレミスとAWSの接続方式」としてではなく、Bandwidth・Redundancy・ハイブリッド依存通信・DNS・Cutover・Rollbackまで含む移行期間全体のNetwork Architectureとして判断することが重要です。