Application Migration Serviceを用いたクラウド化への第一歩

by jukiya330

Slide 1

Slide 1 text

Application Migration Serviceを用いたクラウド化への第一歩 2021/10/12 ネクストモードインテグレーション部島川寿希也

Slide 2

Slide 2 text

2 💡こんな方におすすめの動画です💡

Slide 3

Slide 3 text

3 こんな方におすすめのセッションです AWSにサーバ移行してみたいけど何からやっていいか分からない今動いているサーバがAWSでも動くかテストしてみたい自社データセンターから AWSへの移行が求められている

Slide 4

Slide 4 text

4 お話しすること ◆ AWS移行時の課題 ◆ 移行ツール、サービスの選定 ◆ Application Migration Service(MGN)の使い方 ◆ 実際の移行からの学んだこと、気を付けるべき点

Slide 5

Slide 5 text

5 自己紹介島川寿希也 (Shimakawa Jukiya) ネクストモード所属 AWS ソリューションアーキテクトとしてお仕事中好きなサービスは「Amazon ECS」

Slide 6

Slide 6 text

6 AWS移行時の課題

Slide 7

Slide 7 text

7 よくある移行理由 ⚫ データセンターからの退去 ⚫ サーバの保守切れ ⚫ もう資産管理したくない ⚫ スペック増強を素早く簡単に ⚫ DR対策(可用性をあげたい) ⚫ DX対応 ⚫ コスト削減

Slide 8

Slide 8 text

8 クラウドで全部解決できそう！

Slide 9

Slide 9 text

9 その前に・・・

Slide 10

Slide 10 text

10 7つのR Retire Retain Relocate Rehost Repurchase Replatform Refactor サーバをどうしたいか7つのRから選択する廃止する (難易度 : 低) そのままにする基盤をそのまま移行する (Vmware環境など) 中身はそのままサーバをクラウドへ移行するシステムを別の製品に置き換えるクラウドへの最適化を行いつつ移行するシステムを作り替える (難易度 : 高)

Slide 11

Slide 11 text

11 今回はRehostについてお話しします

Slide 12

Slide 12 text

12 Rehostしてクラウドで動かしたい！

Slide 13

Slide 13 text

13 だけど・・・難易度高そう失敗したくない何からやったらいいかわからない業務を止められないまずは試したい

Slide 14

Slide 14 text

14 その一歩を後押ししてくれるサービス「AWS Application Migration Service」

Slide 15

Slide 15 text

15 移行ツール、サービスの選定

Slide 16

Slide 16 text

16 色んなツール・方法がありますサーバをRehost(EC2化)する方法参考 : https://aws.amazon.com/jp/blogs/psa/migration_tools/ VM Import / Export CloudEndure Migration AWS Application Migration Service (MGN) AWS Server Migration Service CloudEndureの後継サービス。AWSマネジメントコンソールから使用することができる。仮想環境に並列で仮想マシンを作成、そのサーバ経由で仮想マシンを移行する。エージェントレス。増分反映。エージェントをインストールし、リアルタイムでデータを移行。ダウンタイムなし。物理サーバ、AWS外のクラウドのサーバにも対応。インターネット/専用線/VPN経由で移行ができる。 ※専用コンソールで操作 OVFでエクスポートをしてAWSへインポート。エクスポート時の情報が最新。おすすめ順・導入しやすさ

Slide 17

Slide 17 text

17 色んなツール・方法がありますサーバをRehost(EC2化)する方法参考 : https://aws.amazon.com/jp/blogs/psa/migration_tools/ VM Import / Export CloudEndure Migration AWS Application Migration Service (MGN) AWS Server Migration Service CloudEndureの後継サービス。AWSマネジメントコンソールから使用することができる。仮想環境に並列で仮想マシンを作成、そのサーバ経由で仮想マシンを移行する。エージェントレス。増分反映。エージェントをインストールし、リアルタイムでデータを移行。ダウンタイムなし。物理サーバ、AWS外のクラウドのサーバにも対応。インターネット/専用線/VPN経由で移行ができる。 ※専用コンソールで操作 OVFでエクスポートをしてAWSへインポート。エクスポート時の情報が最新。おすすめ順・導入しやすさ

Slide 18

Slide 18 text

18 CloudEndure MigrationとMGNの違い

Slide 19

Slide 19 text

19 CloudEndureとMGNの違いコンソール画面が異なる CloudEndure Migration AWS Application Migration Service (MGN) https://console.cloudendure.com/ ※CloudEndure専用アカウントの作成が必要 https://console.aws.amazon.com/mgn/home ※AWSマネジメントコンソールから操作が可能

Slide 20

Slide 20 text

20 CloudEndureとMGNの違いサポートOSが異なる • 32bit OS / Windows Server2003 / Windows クライアント OSはCloudEnudreを選択する必要がある。MGNはこれらをサポートしていない * 古めのOSだと注意が必要 • CloudendureのサポートOS情報 https://docs.cloudendure.com/Content/Getting_Started_with_CloudEndure/Supported_O perating_Systems/Supported_Operating_Systems.htm • MGNのサポートOS情報 https://docs.aws.amazon.com/mgn/latest/ug/Supported-Operating-Systems.html

Slide 21

Slide 21 text

21 CloudEndureとMGNの違いライセンス切れの際の動きが違う • CloudEndureは90日のライセンス期限が切れると自動的にレプリケーションが止まる。 • MGNは90日のライセンスが期限が切れてもレプリケーションは止まらずに課金が発生する。 https://aws.amazon.com/jp/application-migration-service/pricing/

Slide 22

Slide 22 text

22 CloudEndureとMGNの違い MGNでは一部のAWSリージョンが使用できない • 使いたいリージョンがサポートされていない場合はCloudEndure を選択する。 * 東京リージョンと大阪リージョンはサポートされている。 * リージョン情報はこちらでチェック→https://aws.amazon.com/jp/about-aws/global-infrastructure/regional-product-services/

Slide 23

Slide 23 text

23 CloudEndureとMGNの違い HTTPS(443)のアウトバウンドの通信先が異なる • サービスを利用するための通信先が異なる • 移行元とAWS側のレプリケーションサーバ両方から通信できないとダメ • CloudEndure → https://console.cloudendure.com • MGN → https://mgn..amazonaws.com * Regionは利用リージョンに合わせる

Slide 24

Slide 24 text

続き・・・移行元・レプリケーションサーバから通信ができないといけない。 MGNはAWS内のサービス →つまり、専用線またはVPNを用いていれば AWS側はプライベートサブネットで閉じることができる😎 24 CloudEndureとMGNの違い https://docs.aws.amazon.com/ja_jp/mgn/latest/ug/Network-Settings-Video.html https://docs.cloudendure.com/Content/Preparing_Your_Environments/Network_ Requirements/Network_Requirements.htm

Slide 25

Slide 25 text

続き・・・移行元・レプリケーションサーバから通信ができないといけない。 MGNはAWS内のサービス →つまり、専用線またはVPNを用いていれば AWS側はプライベートサブネットで閉じることができる😎 25 CloudEndureとMGNの違い https://docs.aws.amazon.com/ja_jp/mgn/latest/ug/Network-Settings-Video.html https://docs.cloudendure.com/Content/Preparing_Your_Environments/Network_ Requirements/Network_Requirements.htm

Slide 26

Slide 26 text

続き・・・移行元・レプリケーションサーバから通信ができないといけない。 MGNはAWS内のサービス →つまり、専用線またはVPNを用いていれば AWS側はプライベートサブネットで閉じることができる😎 26 CloudEndureとMGNの違い https://docs.aws.amazon.com/ja_jp/mgn/latest/ug/Network-Settings-Video.html https://docs.cloudendure.com/Content/Preparing_Your_Environments/Network_ Requirements/Network_Requirements.htm

Slide 27

Slide 27 text

27 余談：なぜ同じようなサービスが2つあるのか

Slide 28

Slide 28 text

28 余談：CloudEndureとMGNの歴史的背景 https://twitter.com/CloudEndure/status/1083258144283942912 Cloudendureはもともと AWS外の会社だった • 2019年の年明けにAWS がCloudEndureを買収 • それから約半年後に90 日間、無料で使えるという発表 • さらに約1年後、MGNが登場

Slide 29

Slide 29 text

29 余談：CloudEndureとMGNの歴史的背景 https://twitter.com/CloudEndure/status/1083258144283942912 Cloudendureはもともと AWS外の会社だった • 2019年の年明けにAWS がCloudEndureを買収 • それから約半年後に90 日間、無料で使えるという発表 • さらに約1年後、MGNが登場

Slide 30

Slide 30 text

30 余談：CloudEndureとMGNの歴史的背景 https://twitter.com/CloudEndure/status/1083258144283942912 Cloudendureはもともと AWS外の会社だった • 2019年の年明けにAWS がCloudEndureを買収 • それから約半年後に90 日間、無料で使えるという発表 • さらに約1年後、MGNが登場

Slide 31

Slide 31 text

31 まずはMGNを使ってダメなら CloudEndureを使う

Slide 32

Slide 32 text

32 MGNの使い方

Slide 33

Slide 33 text

33 説明用ざっくりアーキテクチャ

Slide 34

Slide 34 text

Slide 35

Slide 35 text

35 事前に準備しておくもの

Slide 36

Slide 36 text

36 VPC レプリケーション用とターゲット用の2つのVPCを用意する * レプリケーション用は必要に応じてインターネットゲートウェイのアタッチを

Slide 37

Slide 37 text

37 セキュリティグループレプリケーションサーバ用(TCP:1500のインバウンド) とターゲットインスタンス用(使用用途に合わせて) を用意する

Slide 38

Slide 38 text

38 IAMユーザアクセスキー/シークレットキーが必要なためプログラム実行用のIAMユーザを用意する権限は「AWSApplicationMigrationAgentPolicy」

Slide 39

Slide 39 text

39 MGNの初期設定

Slide 40

Slide 40 text

40 Replication Settings まずはレプリケーション環境の設定を行う。 * はじめてコンソールにログインするとこの設定を求められます。

Slide 41

Slide 41 text

41 Replication Settings まずはレプリケーション環境の設定を行う。 * はじめてコンソールにログインするとこの設定を求められます。

Slide 42

Slide 42 text

42 Replication Settings まずはレプリケーション環境の設定を行う。 * はじめてコンソールにログインするとこの設定を求められます。起動サブネットインスタンスタイプボリュームタイプボリュームの暗号化セキュリティグループ PrivateIPを使用するか帯域幅の指定(1Mbps単位) タグ付け

Slide 43

Slide 43 text

43 ローカル環境のサーバにエージェントをインストールする

Slide 44

Slide 44 text

44 エージェントのインストールコマンド Linuxの場合 ◆インストーラーをダウンロード wget -O ./aws-replication-installer-init.py https://aws-application-migration- service-.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py ◆実行 sudo python3 ./aws-replication-installer-init.py --region --aws-access- key-id --aws-secret-access-key 参考 : https://docs.aws.amazon.com/mgn/latest/ug/linux-agent.html

Slide 45

Slide 45 text

45 エージェントのインストールコマンド Windowsの場合 ◆インストーラーをダウンロード https://aws-application-migration-service- .s3.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe ◆実行(管理者で実行) AwsReplicationWindowsInstaller.exe --region --aws-access-key-id --aws-secret-access-key 参考 : https://docs.aws.amazon.com/mgn/latest/ug/windows-agent.html

Slide 46

Slide 46 text

46 実行時に聞かれることどのディスクを対象にするかを聞かれるそのままEnterで全てが対象になる

Slide 47

Slide 47 text

47 自動的にレプリケーションを開始させたくないデフォルトだとインストールと同時にレプリケーションが開始される。させたくない場合は --no-prompt オプションを付ける参考 : https://docs.aws.amazon.com/mgn/latest/ug/windows-agent.html

Slide 48

Slide 48 text

48 MGNの画面を確認

Slide 49

Slide 49 text

49 エージェントインストール後エージェントをインストールしたサーバの情報が表示される

Slide 50

Slide 50 text

50 エージェントインストール後レプリケーションの進捗情報を確認できたり (Migration dashboard)

Slide 51

Slide 51 text

51 エージェントインストール後サーバの情報が確認できたりする(Server info)

Slide 52

Slide 52 text

52 レプリケーションサーバも起動しているレプリケーションサーバも見えます

Slide 53

Slide 53 text

53 レプリケーションが完了すると・・・ Ready for testing状態になっていることを確認する

Slide 54

Slide 54 text

54 ラグがないことも確認しておくラグがなく同期できていることも確認する

Slide 55

Slide 55 text

55 これで初期同期が完了継続的なレプリケーションが維持されている状態

Slide 56

Slide 56 text

56 起動情報を確認する

Slide 57

Slide 57 text

57 起動情報を確認する EC2の起動情報を確認する(Launch settings)

Slide 58

Slide 58 text

58 起動情報を確認するインスタンスタイプが古かったりボリュームタイプがio1だったりすることがあるので出来る限り確認して変更したほうが良い

Slide 59

Slide 59 text

59 起動情報を変更したい場合作成されているEC2の起動テンプレートを変更する

Slide 60

Slide 60 text

60 テストモードで起動する

Slide 61

Slide 61 text

61 テストモードで起動するテストモードで起動する

Slide 62

Slide 62 text

62 テストモードで起動する Conversionサーバというデータ移行用サーバが一時的に作成される(作業が終わり次第削除される)

Slide 63

Slide 63 text

63 テストモードで起動する First boot : Succeededを確認実際にサーバにアクセスしてアプリのテスト等行ってみる

Slide 64

Slide 64 text

64 テストモードで起動するテストOKであればReady for cutoverのマークを付ける

Slide 65

Slide 65 text

65 テストモードで起動するテストに問題がある場合は再度テストモードを実行する再実行した際は既にあるテストモードのインスタンスは削除されて新しいインスタンスが作成される

Slide 66

Slide 66 text

66 カットオーバーでサーバを移行する

Slide 67

Slide 67 text

67 カットオーバーでサーバを移行する本番移行日を迎え、いよいよサーバを移行するタイミングとはいえ、レプリケーションが止まるだけで元のサーバが削除されるという訳ではない

Slide 68

Slide 68 text

68 カットオーバーでサーバを移行する Ready for cutoverであることを確認

Slide 69

Slide 69 text

69 カットオーバーでサーバを移行する Cutoverモードで起動するテストモードインスタンスが削除され、新しいインスタンスが作成される

Slide 70

Slide 70 text

70 カットオーバーでサーバを移行する起動後のテストが問題なければFinalize cutoverを実施

Slide 71

Slide 71 text

71 カットオーバーでサーバを移行するこれでサーバ移行が完了レプリケーションサーバも削除される

Slide 72

Slide 72 text

72 実際の移行からの学んだこと気を付けるべき点

Slide 73

Slide 73 text

73 学んだこと、気を付けるべき点 • エージェントインストール要件の確認 • OSはサポートされているか、必要なソフトウェアは揃っているか • 適切なドライバの用意、設定を行う必要がある • 移行ネットワークの確認 • 帯域確保、オンプレミス環境に動作影響を与えないか • ライセンスの有無 • Windows / SQL Server / RHELの場合は特に注意 • テストモード時のAWS利用費を気にする • レプリケーションのEBS代 / テストモードのインスタンス代、EBS代が常に発生するため、計画的に利用する

Slide 74

Slide 74 text

74 移行時に詰まったポイント • テストモードで起動はできたもののステータスチェックに失敗し接続ができない • EC2 RescueでOSログを調査→ドライバーインストール失敗を確認→ネットワーク機能が正常に動いていなかった。 • 根本原因はWindowsの修正パッチ適用不足 • Windows Updateは行った上で移行を実施する

Slide 75

Slide 75 text

75 ここからが本当のスタートライン

Slide 76

Slide 76 text

76 クラウドの最適化 • Rehostはクラウド最適化における第一歩でしかない • この土台を生かしてクラウドをガンガン活用していく

Slide 77

Slide 77 text

77 まとめ

Slide 78

Slide 78 text

78 まとめ • クラウド化の第一歩としてオススメなサービス「AWS Application Migration Service」 • まずは試す。ダメなら他の方法を考える。

Slide 79

Slide 79 text

No content