Migration Approachを決める判断軸

Migration Decisionで、移行対象、7Rs、Wave Planningへ渡す条件を整理しても、具体的な移行方式はまだ決まっていません。

次に必要なのは、

Data Volume
+
Bandwidth
+
Downtime
+
Migration Window
+
Security
+
Dependency
↓
Online / Offline
↓
Transfer Strategy

という判断です。

重要なのは、特定の移行サービスやツールを先に選ばないことです。

先に移行要件を明確にし、その要件を満たせるTransfer Strategyを選びます。

1. 移行アプローチは「移せるか」ではなく「どう移すか」を決める

Migration Decisionでは、このワークロードを移行するか、どの7Rsを適用するか、どのウェーブで扱うかを整理しました。

移行アプローチでは、その判断を前提として、

どれだけのデータを
どの時間内に
どの程度の停止で
どの通信条件を使って
どのSecurity要件を満たしながら
どの順序で移すか

を整理します。

Migration Decision
↓
移行アプローチ

という関係です。

ここでは、個別のAWS移行サービスの使い方を決めるのではなく、まず方式を選ぶための制約条件を明確にします。

2. Data Volumeは転送方式の基本入力になる

Data Volume は、移行するデータの量です。

例えば500 GB、5 TB、80 TB、500 TBでは、同じBandwidthを利用しても必要な転送時間が大きく異なります。

しかし、確認するのは単純な現在容量だけではありません。

初期データ
+
移行準備中に増加するデータ
+
必要に応じて同期する変更分

まで考慮する必要があります。

現在10 TBある
=
10 TBだけ送れば必ず終了

とは限りません。移行期間中もソースが更新される場合は、初期転送後に追加の変更データを反映する必要があります。

3. Bandwidthは公称値ではなく実効値で考える

Bandwidth は、データを転送できる速度へ直接影響します。

転送時間
≈
Data Volume
÷
実効Bandwidth

が基本的な考え方です。

大容量データに対してBandwidthが小さければ、ネットワーク経由の転送だけではMigration Windowに収まらない可能性があります。

ただし、回線の公称Bandwidthをそのまま利用できるとは限りません。

通常業務の通信
他の移行通信
プロトコルのオーバーヘッド
ネットワーク混雑
送信元 / 送信先の処理性能

などによって実効スループットが低下する可能性があります。

回線は1 Gbps
↓
常に移行で1 Gbps利用可能

とは考えません。

4. Data Volume × Bandwidth × Migration Windowで実現性を確認する

例えば、Data Volumeが80 TB、実効Bandwidthが1 Gbps、Migration Windowが48時間という条件を考えます。

80 TBは単純計算でも約640 Tbです。

640,000 Gb
÷
1 Gb/s
≈
640,000秒
≈
178時間

となるため、理論上の転送時間だけでも48時間を大きく超えます。

現在のネットワーク転送方式のまま
↓
Migration Window内に完了

という前提は成立しません。

利用可能なBandwidthを増やす、初期データの運搬方法を変える、転送対象を見直す、事前転送できる期間を確保する、などを検討します。

Data Volume・Bandwidth・Migration Windowを別々に見るのではなく、組み合わせて実現性を確認します。

5. Downtimeは転送時間と同じではない

Downtime は、業務やアプリケーションを利用できないことが許容される時間です。

全データの初期転送
→ 3日

業務停止
→ 15分

という移行もあり得ます。

3日間かけて事前転送
↓
ソースの変更を同期
↓
最終切り替え時だけ15分停止

のような方式を採用できるためです。

転送に3日必要
=
3日間Downtimeが必要

ではありません。逆に、ソースを停止してから全データを転送する方式なら、転送時間がDowntimeへ直接影響する可能性があります。

6. Migration WindowとDowntimeを分けて考える

Migration Window は移行作業を実施できる時間枠、Downtime はその中で業務停止が許容される時間です。

Migration Window
土曜22:00 ～ 日曜06:00
= 8時間

Downtime
最大30分

という要件では、作業時間が8時間あるから8時間停止してよいわけではありません。

8時間のMigration Windowには、最終同期、検証、切り替え、動作確認、必要に応じた切り戻し判断などを含められますが、業務停止自体は30分以内に収める必要があります。

この2つを混同すると、要件を満たさないTransfer Strategyを選ぶ可能性があります。

7. Onlineはソースを利用しながら移行する方向性

Online の方向性では、ソースを利用可能な状態に保ちながらデータ転送を進めます。

初期データを転送
↓
ソースで発生した変更を継続反映
↓
ソースとターゲットの差を小さくする
↓
短い切り替え

という考え方です。

Downtimeを短くしたい、移行中もソースが更新される、継続的な同期が必要、十分なネットワーク接続を確保できる場合に候補になりやすくなります。

Online
=
常に最適

ではありません。大量データに対してBandwidthが不足していれば、初期転送に非常に長い時間がかかる可能性があります。

8. Offlineは継続的なネットワーク転送への依存を減らす

Offline の方向性は、大量データの移行を継続的なネットワーク接続だけに依存させない方式です。

Data Volumeが大きい、利用可能なBandwidthが小さい、一回性の大量移行、データを一定期間静的にできる、一定のDowntimeを許容できる場合に候補になりやすくなります。

Offline
=
ネットワークが不要

という意味ではありません。

移行前後にはデータの準備、最終的な差分の処理、検証、切り替えなどが必要になる場合があります。

また、物理的なデータ運搬を伴う方式では、データ保護や取り扱い手順もSecurity要件になります。

9. Online / OfflineはData Volumeだけで決めない

100 TBという大容量データでも、十分なBandwidth、長い事前移行期間、短いDowntime要件、継続的な更新があるなら、ネットワークを使った事前転送と同期を検討できる場合があります。

反対に10 TBでも、利用可能なBandwidthが極端に小さくMigration Windowが短いなら、ネットワークだけに依存するTransfer Strategyが適さない可能性があります。

したがって、Data Volumeだけ、Bandwidthだけ、Downtimeだけの1項目でOnline / Offlineを決めません。

10. 初期転送と最終切り替えを分けて考える

大容量データと短いDowntimeを両立させる場合、初期データの移行と最終的な切り替えを分けて考えることが重要です。

大量の初期データ
↓
事前に移行

その後の変更
↓
継続的に同期

最終差分
↓
Migration Windowで反映

切り替え
↓
短いDowntime

という構造です。

Transfer Strategyは、全データを切り替え当日に一度で転送することだけを意味しません。

11. SecurityはTransfer Strategyの選定条件

Security は、方式を選んだ後に追加するものではありません。

規制対象データでは、転送中の暗号化、一時保存中の暗号化、アクセス主体の制限、認証・認可、操作記録、データ所在地、一時データの削除などの要件があります。

候補のTransfer Strategyが高速・低コストであっても、必要なSecurity要件を満たせなければ採用できません。

性能
+
時間
+
Security

を同時に評価します。

12. OnlineでもOfflineでもSecurityは必要

Online
→ ネットワークを使うのでSecurityが必要

Offline
→ ネットワークを使わないのでSecurity不要

という判断は誤りです。

Offline方式でも、保存データの暗号化、デバイスや媒体へのアクセス制御、取り扱い記録、受け渡し手順、移行後のデータ削除などが必要になる場合があります。

重要なのは、方式に応じてSecurityの実装方法が変わるだけで、Security要件自体がなくなるわけではないことです。

13. Dependencyは切り替え成立条件へ影響する

Dependency はWave Planningだけでなく、移行アプローチにも影響します。

アプリケーションA
↓
データベースB
↓
共有ファイルC

という依存関係がある場合を考えます。

BとCがAWS側で起動していたとしても、データベースBに最新変更の同期が残り、共有ファイルCも最終差分の反映が未完了なら、依存先が起動しているだけでアプリケーションAを安全に切り替えられるとは限りません。

移行アプローチでは、依存先が利用可能か、必要な同期が完了しているか、整合性を確認できているか、切り替え後に依存関係が成立するかまで確認します。

14. 同じMigration Waveでも同時切り替えとは限らない

同じMigration Waveに含まれていても、すべて同じ時刻に切り替える必要があるとは限りません。

例えば、共有データ基盤を先に移行・検証し、アプリケーションを後から切り替えるように、同じウェーブ内でもDependencyに合わせた順序を持たせる場合があります。

逆に、一方だけ切り替えると業務が成立しない強いDependencyなら、切り替えを協調させる必要があります。

Wave Planning
=
どの期間・グループで移行するか

移行アプローチ
=
その中でどう転送・同期・切り替えるか

15. Transfer Strategyは制約の組み合わせから作る

Transfer Strategy は、単一条件ではなく複数条件の組み合わせです。

Data Volumeが大、Bandwidthが小、Downtimeは数時間許容、Migration Windowは週末、Securityは強い暗号化要件、Dependencyが少ないなら、ネットワークだけで全量転送する方式がMigration Windowへ収まるかを確認し、収まらなければ別の大量データ移行方法を比較します。

一方、Data Volumeが中、Bandwidthが十分、Downtimeは数分、データ更新が継続、Dependencyが多いなら、事前転送、変更同期、Dependencyを考慮した短時間切り替えという方向性が重要になります。

16. 「速い方式」ではなく「要件を満たす方式」を選ぶ

Transfer Strategyでありがちな誤りは、最速 = 最適と考えることです。

最も高速でも、Security要件を満たさない、Downtimeが長すぎる、Dependencyを維持できない、Migration Windowへ収まらないなら不適切です。

逆に多少時間がかかっても、事前移行できる、業務影響を抑えられる、Security要件を満たす、確実に検証できるのであれば、その方が適切な場合があります。

17. 判断軸を比較する

18. この段階では特定サービスを先に決めない

大容量だからサービスA、Downtimeが短いからサービスBのように、1つの条件だけでAWSサービスを選ぶのは早すぎます。

まずData Volume、Bandwidth、Downtime、Migration Window、Security、Dependency、Online / Offlineを整理します。

その後、このTransfer StrategyをどのAWSサービスや移行ツールで実現するかを選びます。

要件
↓
Transfer Strategy
↓
サービス / ツール

の順番です。

19. 全体の判断フロー

Migration Decision
↓
Data Volume
↓
実効Bandwidth
↓
転送時間を概算
↓
Migration Windowへ収まるか
↓
Downtimeを満たせるか
↓
Online / Offlineの方向性
↓
Security要件
↓
Dependency / 切り替え条件
↓
Transfer Strategy
↓
具体的なAWSサービス / ツールを選択

SAP-C02では、サービス名から考えるのではなく、移行要件から逆算することが重要です。