AWS移行 - CloudEndure MigrationでのEC2移行検証

　本資料は、初めてCloudEndureを使ってオンプレミスまたはAWS以外のクラウドサービスからAWSへサーバを移行する人が、移行時間が実際に何分くらいかかるのかを検討する際の参考資料として作成しました。

　この検証はAWS内で実際にCloudEndure Migrationを使って、仮想マシンを移行し、その際の時間を測定しています。最大1TBのデータを移行していますので、移行時間の見積もりの参考になれば幸いです。
　また、この資料では移行を検討する際のポイントに絞って紹介しています。具体的な移行手順、前提条件、制限事項等についてはAWS社が公開しているドキュメントを参照下さい。　→　https://docs.cloudendure.com/

　（参考情報）
　2021年5月から東京リージョンにて「AWS Application Migration Service」が利用可能です。このサービスはCloudEndure Migration と同様の機能を提供しますが、違いはAWS マネジメントコンソールで利用できます。さらに、AWS CloudTrail、Amazon CloudWatch、AWS Identity and Access Management (IAM) などの他の AWS のサービスとのシームレスな統合が可能になっているそうです。
　また、実際に「AWS Application Migration Service」を使って検証していないためあくまで推測になりますが、移行時間についてはCloudEndureと同等になると想定されます。

### 1.CloudEndureの特徴
　主な特徴をあげます。

- 切替直前までデータ同期を行うため、切り替え時のダウンタイムを短く出来る（最小数分）
- 元々は有償ツールだったが、AWSが買収し2019年１月から無償(※1)利用が可能。
- 従来AWSのサーバ移行ツールとして提供されていた「VM Import」「Server Migration Service(SMS)」による移行と比較し、少ない手順にて簡単に移行が可能。
- 日本国内（他社事例）において「CloudEndure」を使って数百台の移行事例あり。（海外では数万台の実績があるそうです）

(※1)CloudEndure Migration自体は無償にて利用可能ですが、移行の為に利用するAWSリソース (例：後述のReplicationサーバ)や、移行後の仮想マシン(EC2)につきましては、従来通り課金されます。


### 2.対象者

- 対象読者：　AWSへのサーバ移行にかかわるエンジニア
- 前提知識：　オンプレミスでの物理サーバ移行、仮想サーバ移行の経験またはAWS認定クラウドプラクティショナー(初級レベル) 程度の知識を有していること


### 3.CloudEndure概要
　CloudEndureとは、AWSが提供するエージェント導入型の移行 / DR支援ソリューションです。

- **ソリューション概要**
  - 2018年末にAWS社がCloudEndure社を買収
  - エージェント導入型の移行、DRを実現(※1)
  - 高速な切り替えを実現
  - 移行ソリューション自体は無償利用が可能
  - インターネット接続が必須（可否判断要(※2)）
 
   ​	(※1) DRは別途有償ライセンスが必要となります
    ​	(※2) 認証付きプロキシが未サポート。ホワイトリスト登録にて対応必要。

　詳しくは次のドキュメントに詳しく解説されています。ご参照下さい。
　　Amazon Web Services ブログ
　　[AWS Black Belt Online Seminar] CloudEndure 資料及び QA 公開
　　https://aws.amazon.com/jp/blogs/news/webinar-bb-cloudendure-2020/

　また、具体的な操作手順はAWS社のハンズオンが参考になります。
　https://application-migration-with-aws.workshop.aws/ja/server-migration.html


- **CloudEndure Migrationの処理の特徴**
  - 仮想**マシン全体**を移行します。
  - CloudEndure **エージェントが常駐**し、データをReplicationサーバへ**随時転送**します。
  - 移行先サーバは、仮想マシン全体の同期後、**任意のタイミングで作成**します。	
![image-20210728160037980.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/c08beb60-83eb-bda5-541f-7954c915e25f.png)


### 4.検証概要
　CloudEndureを使って移行するための手順をまとめると次のようになります。詳細は公式ドキュメントを参照下さい。
![image-20210714162428654.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/ee1ff1c9-cb47-afbe-f563-7a7c55b7d5e3.png)


　また、CloudEndureを使って移行する際には、次の点にご注意下さい。詳細は公式ドキュメントを参照下さい。

- 1．移行元サーバからAWSへのアウトバウンド通信必須（httpsと**1500番ポート**）
  　（1500番ポートはDirect Connect またはVPN経由に変更は可能）
 　補足：実際の環境では、1500番ポートを既存FireWallにて通すことは困難と想定。
  　 詳しいネットワーク要件は、”付録．CloudEndureに関するFAQ”のQ:6を参照。

- ２．**認証付きのプロキシが現段階 (2021年3月)では使えません**
  （インターネット直接続、認証無しプロキシまたはプロキシへホワイトリスト登録が必須条件）
  補足：今回の検証ではプロキシを使用していないため問題になりませんでした。
   しかし、実際のオンプレミス環境ではプロキシを経由することが一般的です。

- ３．移行元サーバへエージェントインストールが必須
  （CPU負荷や業務影響を心配しインストールが許可されないケースが想定されます）



　次に、今回の検証における構成の概要図を以下にしまします。
![image-20210728160112320.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/fc56bde0-364b-69a3-354d-ad8c00e2346a.png)


　今回の検証では、処理時間の傾向を把握するために３パターンのDISKサイズのVMを移行しました。
![image-20210721175617842.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/c1e9df9f-c703-d8c5-4341-3911ec2d2959.png)


**検証環境の構成**

- 検証環境は、AWS 東京リージョン
- 移行元サーバは、ap-northeast-1aに配置
- Replicationサーバ、移行先サーバは、ap-northeast-1cに配置
- 移行元サーバのインスタンスタイプは、
　**t3.large**(2コア、メモリ8GB)、  OSは**Windows** Server 2019
- Replicationサーバのインスタンスタイプは、t3.small（デフォルト値）
- 各サーバのEBSは、**汎用SSD（gp2）**を使用
- 検証パターン別のEBSの割当とDISKの使用量は以下を参照。

| 検証パターン | DISK1(使用/割当) | DISK2(使用/割当) | DISK3(使用/割当) |
| ------------ | ---------------- | ---------------- | ---------------- |
| 30GB         | 15GB/30GB        | なし             | なし             |
| 580GB        | 15GB/30GB        | 500GB/550GB      | なし             |
| 1130GB       | 15GB/30GB        | 500GB/550GB      | 500GB/550GB      |


- テストデータは、次のPowerShellスクリプトにて1GBのランダムテキストのファイルを作成し、このファイルを必要な容量分だけコピーしました。


```powershell
$random_bin = new-object byte[] (1024*1024*1024); 
(new-object Random).NextBytes($random_bin); 
[IO.File]::WriteAllBytes("c:\temp\test.txt", $random_bin)
```


- テストデータ内容
![image-20210714161840484.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/77ea89f7-5166-bcfd-fbd2-ed82569e79f6.png)



### 5.検証結果
　CloudEndureを使って移行した場合の処理時間の測定結果は以下のようになりました。

- 起動時間は、１０分以内（DISKサイズが増えても変わらなかった）
- 初期同期時間は、DISK容量に比例
- 転送性能は、1.0GB/分以上
![image-20210714162505519.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/1fcd013f-3c4d-deeb-5d92-478477a537d3.png)



### 6.注意事項
　検証結果を参照する際には、次の点にご注意下さい。

- 1.初期同期の速度は、進捗率が進むほど悪化していました。今回の環境では16MB/秒～43MB/秒と差がありました。ただし43MB/秒のパターンは、途中までの初期同期時間しか測定出来なかったため、例外と判断下さい。傾向として同期開始から約150GBの転送までは、約50MB/秒の性能が出ていましたが、それ以降は徐々に性能劣化の傾向が見られました。

- 2.今回使用したEBSは、移行元、移行先ともに汎用SSD（gp2）です。
  　　（550GBのEBSをDISK Read性能を測定した結果、200MB/秒以上出ていました）

- 3.移行元と移行先間のAZ間の通信性能は、実測60MB/秒以上出ていたため、 ネットワークがボトルネックではないと考えられます。

- 4.これとは別に２パターンテストを実施した結果では、**約16MB/秒の初期同期**の処理性能でした。

- 5.起動時間はインスタンス起動までの時間です。**アプリ起動は別途必要**です。



### 7.付録　CloudEndureに関するFAQ

Q1: CloudEndureの実績はどれくらいありますか？メーカーはどこか？サポート体制は大丈夫か？
A: 2020年1月時点で、**数万**以上のサーバの移行実績があるときいています。メーカーのCloudEndure は、2018年末に**AWS****に買収**され現在は AWS グループ企業。サポート体制は、EC2などと同様にAWSコンソールから**AWS Support**へ問い合わせ可能です。問い合わせ時に**日本語**または英語かを選べます。

Q2: なぜCloudEndureを選択するのか？他の移行ツールは何があり、違いはなにか？
A: １番の理由は切替時の**ダウンタイムを短く**することができるためです。（目安は５分～１０数分）90日間は**無償**にて利用可能です。他のツールに対する優位性は、移行が高速（S3へのコピーが不要。データ転送時の圧縮。ブロックレベル複製）仮想サーバと**物理サーバ**の両方に**対応**。操作がシンプルかつ少ない手順。他のツールとしては、Server Migration Service(SMS)、VM ImportがAWS社としてあります。また、AWS社以外からも移行ツールやサービスが出ています。

Q3: 価格は？前提条件や制限は？ 
A: CloudEndure Migration の各**無料**ライセンスは、エージェントのインストール後 **90** **日間**使用できます。  CloudEndure Migration の使用は無料ですが、移行中と移行期間後にプロビジョニングされる、 コンピューティング(EC2)やストレージ(EBS)のリソースなどの AWS インフラストラクチャに対して料金が発生します。前提としては、対象サーバにエージェントがインストールされます。そのため、対象サーバに負荷が生じます。また、CloudEndure **DRは有償**です。

Q4: サポートOSは？ 
A:サポート対象の **Windows** **と** **Linux** OS のバージョンで実行されているすべてのアプリケーションとデータベースを移行できます。これには、Windows Server **2003/2008/2012/2016/2019** バージョン、および **CentOS**、**RHEL**、**OEL**、**SUSE**、**Ubuntu**、**Debian** といった Linux ディストリビューションが含まれます。

Q5: どのような移行方式なのか？ 
A: **エージェント導入型**の移行サービス。制御はCloudEndure **専用ポータル**から行います。AWS側に**ReplicationServer**が少なくとも1台構成されます。ここに移行元のデータが複製されます。データの複製後もリアルタイムで非同期で、データの同期を継続します。テストや本番時に、**EC2**を展開します。展開の際にAWS用に変換処理が実行されます。

Q6: インターネット接続は必須か？ 必要な場合の具体的な要件は？
A: **必須**です。**CloudEndureポータル**はインターネット上にあり、そこへの**OutBound通信が必要**です。また、移行元からReplicationサーバーへのデータ伝送にインターネットを選択した場合には、ReplicationサーバーへのInbound通信も発生します。VPNやDirect ConnectでAWSへ接続する場合には、データ伝送時にインターネット接続は不要ですが、制御のためにCloudEndureポータルとの通信は必須です。具体的には、下図の破線円で示した①②③④がインターネット接続部分になります。
![image-20210715113752435.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/9ad762ab-c19d-de92-0c7e-ba5b6b008d5c.png)

インターネットと接続する３か所（①②③）については次の通信要件があります。④についてはAWSのAPIを呼ぶためのユーザと権限等の設定が必要です。
![image-20210715120440304.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/0a6143a7-261d-94f9-3773-aba40ac54d1d.png)

ネットワーク要件の詳細は次の“CloudEndure Documentation”の“Network Requirements”を参照下さい。

https://docs.cloudendure.com/#Preparing_Your_Environments/Network_Requirements/Network_Requirements.htm#Network_Requirements_..85%3FTocPath%3DNavigation%7CPreparing%2520Your%2520Environments%7CNetwork%2520Requirements%2520%7C_____0

Q7: エージェントの負荷による業務影響はどの程度か？ 
A: システムのパフォーマンスに目立った影響を与えることもありません（以前存在していたAWS社のHPより抜粋）

Q8: エージェントのインストール後に**OS再起動**が必要か？
A: **不要**です。

Q9: 切り替え時の**ダウンタイム**はどの程度の時間が必要か？ 
A: Q2にも記載したが、**5~10** **数分**が目安です。

Q10: **移行が出来ない**ような事例はありましたか？ 
A: 今回の検証ではありませんでした。ただ、EC2の制限により1台のインスタンスに20個程度までしかEBSを接続出来ません。そのため**EC2の制限以上のDISKを1サーバに接続している場合**は移行できません。移行元でDISK数を集約出来ればCloudEndureでの移行が可能になります。

　　参照　https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/volume_limits.html

Q11: ユーザ側でする作業は何がありますか？
A: 主に以下の作業があります。

- 環境準備：インターネット接続のための**ネットワーク変更**、無償ライセンスの取得、AWSアクセスキー準備
- 移行対象の準備：移行対象の決定、エージェントのインストール、**移行後の各種ライセンス準備**
- データ同期中：　進捗の確認
- 切り替え時：　**移行対象の停止**、移行に伴う各種設定変更、動作確認

Q12: どれくらいの移行期間が必要でしょうか？ 
A:　1台のサーバを移行するための時間は、主に次の要素で決まります。

- 移行元のDISK読み取り性能
- 移行元からReplicationサーバまでのネットワーク転送性能
- ReplicationサーバのDISK書き込み性能
- 移行準備、テスト、本番までの待機時間

　CloudeEndureは、300台程度(※1)までは同時移行が管理可能なツールです。
　ネットワーク帯域の確保のうえ、**複数サーバを並行移行する**ことで、短期間で移行が可能です。
(※1)300台程度：CloudEndure内のプロジェクトを分けることでそれ以上の管理は可能

Q13: CloudEndureの利用期間（エージェントのインストール後90日間）は、サーバ単位か？ また、90日が過ぎた場合、移行は可能か？ 
A: 90 日の無料期間後、ユーザーのマシンではレプリケートが停止し、新しいターゲットマシンは起動できなくなります。90 日の無料期間内に移行を完了させることができなかった場合でも、**新しい** CloudEndure Migration **アカウント**を使用して該当するマシンに CloudEndure **エージェントを再インストール**することにより、**引き続き無料で移行できます**。そうすることで追加の 90 日の無料期間中、レプリケーション、テスト、移行を実行できるようになります。


Q14: データの転送性能は？帯域制御等の機能がありますか？ 
A: データの転送性能は、16MB/秒～43MB/秒と検証結果はばらつきがありました。（例：1.1TBが19時間）また、ネットワーク**帯域幅調整オプションを使用**すると、ネットワークトラフィックを調整し、帯域幅の輻輳を最小限に抑えることができます。ソースマシンから TCP ポート1500のステージング領域に送信されるデータの転送速度を制御する場合は、このオプションを有効にします。データ転送速度は Mbps 単位で設定できます。設定は、 Setup & Info > REPLICATION SETTINGS. ページにて行います。詳しくは、次を参照下さい。
　 https://docs.cloudendure.com/#Defining_Your_Replication_Settings/Defining_Replication_Settings_for_AWS/Defining_Replication_Settings_for_AWS.htm
![image-20210712151853675.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/c6a99019-d4c0-00b2-8f96-b9f107612a3e.png)

Q15: データ転送が途中で中断した場合、途中から再開可能か？ 
A: ソースマシンのコンテンツのブロックレプリケーションが開始され、コンテンツがステージング領域にコピーされます。レプリケーション中は復旧ポイントが作成されるため、切断時に**最後のポイントからレプリケーションを続行**できます。
　　　　参照資料：https://docs.cloudendure.com/#FAQ/FAQ/Replication_Related.htm

Q16: 物理サーバからAWSへ移行する場合、デバイスドライバーなどは自動調整されますか？ 
A:　本番用マシンの起動準備ができると、マシンは CloudEndure Migration によって**自動的**にソースインフラストラクチャから AWS インフラストラクチャへと**変換**され、AWS でネイティブに起動し、実行できるようになります。

Q17: 複数サーバの同時移行が監視可能とのことだが、どのような監視項目がありますか？   
A:複製対象マシン名毎のDISK容量、DISK**複製**の**進捗率**、DISK**複製**完了までの**残り時間**、STATUS（(!)エラー有無、🏴注意必要/否、🚀データ複製完/未、🏢ターゲットコンピュータの起動完/未）と、Test mode／Cutover modeの状況が一覧で確認可能です。また、詳細画面ではターゲットコンピュータ作成後のインスタンスID、IPアドレス等が確認可能です。
![image-20210712152113238.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/a6e43501-65cd-cf50-fb35-49afe4e11ef0.png)

![image-20210712152122220.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/19de7f4a-8ab4-317c-9cc3-a0c89eb5d808.png)

![image-20210712152132907.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/fc918bbb-8793-88d9-06d2-06941e5a267f.png)

Q18: CloudEndure MigrationとDisaster Recoveryとの違いは？
A: Migrationは90日の期間内でAWSへ移行するための一時的なツールです。一方のDisaster Recoveryでは、対象マシンをAWSにあるステージング領域に**レプリケートし続けます**。**災害発生時**には、数十分のうちに、完全に**プロビジョニング**された状態の、数百台のマシンを自動で起動するように、CloudEndure Disaster Recovery を設定できます。また、DRサイトからメインサイトへの**FailBack****にも対応**。

Q19: 移行がサポートされないアプリケーションやファイルシステム等、既知の制限がありますか？
A: CloudEndure Migration は、ERPパッケージや、一般的なデータベースもサポートしています。 既知の制限については、例えば次のような条件があります。

- WindowsのGPT パーティションとDynamic ディスクをサポートしていません。
- XFS5 ルートまたはブートファイルシステムを使用する Linux マシンはサポートされていません。
- EC2の制限以上のDISKを接続している（通常は20個程度が上限）場合はサポートされません。

　サポートOSの詳細については、次を参照下さい。
　　　https://docs.cloudendure.com/#Getting_Started_with_CloudEndure/Supported_Operating_Systems/Supported_Operating_Systems.htm

Q20: ツールの利用手順書やマニュアルが日本語でありますか？また、どこにありますか？
A: マニュアルは**英語のみ**が現在提供されています（2021年2月時点）。
　　マニュアルは次のURLを参照下さい。
　　　　 [https://docs.cloudendure.com/ ](https://docs.cloudendure.com/)

　　2021年7月現在、CloudEndureを使う前に、AWS Application Migration Service (AWS MGN) の利用が推奨されています。詳しくは次のURLを参照下さい。
　　　　 https://aws.amazon.com/jp/application-migration-service/

Q21: ツールの使い方やエラー時の問い合わせ先はAWS Supportか？それとも他にありますか？無償か？
A:　AWS Supportへ問い合わせ可能です。AWS Supportのプランに応じて費用が変わります（有償）。（CloudEndureのための**追加費用はかかりません**）

以上です。移行の参考になれば幸いです。