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

Transcript

1. Application Migration Serviceを用いた クラウド化への第一歩 2021/10/12 ネクストモード インテグレーション部 島川 寿希也
2. 2 💡こんな方におすすめの動画です💡
3. 3 こんな方におすすめのセッションです AWSにサーバ移行してみたいけど 何からやっていいか分からない 今動いているサーバがAWSでも 動くかテストしてみたい 自社データセンターから AWSへの移行が求められている
4. 4 お話しすること ◆ AWS移行時の課題 ◆ 移行ツール、サービスの選定 ◆ Application Migration Service(MGN)の使い方 ◆ 実際の移行からの学んだこと、気を付けるべき点
5. 5 自己紹介 島川 寿希也 (Shimakawa Jukiya) ネクストモード所属 AWS ソリューションアーキテクトとして お仕事中 好きなサービスは「Amazon ECS」
6. 6 AWS移行時の課題
7. 7 よくある移行理由 ⚫ データセンターからの退去 ⚫ サーバの保守切れ ⚫ もう資産管理したくない ⚫ スペック増強を素早く簡単に ⚫ DR対策(可用性をあげたい) ⚫ DX対応 ⚫ コスト削減
8. 8 クラウドで全部解決できそう！
9. 9 その前に・・・
10. 10 7つのR Retire Retain Relocate Rehost Repurchase Replatform Refactor サーバをどうしたいか7つのRから選択する 廃止する (難易度 : 低) そのままにする 基盤をそのまま 移行する (Vmware環境など) 中身はそのまま サーバをクラウドへ 移行する システムを別の製品に 置き換える クラウドへの最適化を 行いつつ移行する システムを作り替える (難易度 : 高)
11. 11 今回はRehostについてお話しします
12. 12 Rehostしてクラウドで動かしたい！
13. 13 だけど・・・ 難易度高そう 失敗したくない 何からやったらいいかわからない 業務を止められない まずは試したい
14. 14 その一歩を後押ししてくれるサービス 「AWS Application Migration Service」
15. 15 移行ツール、サービスの選定
16. 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へインポート。エクスポ ート時の情報が最新。 お す す め 順 ・ 導 入 し や す さ
17. 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へインポート。エクスポ ート時の情報が最新。 お す す め 順 ・ 導 入 し や す さ
18. 18 CloudEndure MigrationとMGNの違い
19. 19 CloudEndureとMGNの違い コンソール画面が異なる CloudEndure Migration AWS Application Migration Service (MGN) https://console.cloudendure.com/ ※CloudEndure専用アカウントの作成が必要 https://console.aws.amazon.com/mgn/home ※AWSマネジメントコンソールから操作が可能
20. 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
21. 21 CloudEndureとMGNの違い ライセンス切れの際の動きが違う • CloudEndureは90日のライセンス期限が切れると自動的にレプリ ケーションが止まる。 • MGNは90日のライセンスが期限が切れてもレプリケーションは止 まらずに課金が発生する。 https://aws.amazon.com/jp/application-migration-service/pricing/
22. 22 CloudEndureとMGNの違い MGNでは一部のAWSリージョンが使用できない • 使いたいリージョンがサポートされていない場合はCloudEndure を選択する。 * 東京リージョンと大阪リージョンはサポートされている。 * リージョン情報はこちらでチェック→https://aws.amazon.com/jp/about-aws/global-infrastructure/regional-product-services/
23. 23 CloudEndureとMGNの違い HTTPS(443)のアウトバウンドの通信先が異なる • サービスを利用するための通信先が異なる • 移行元とAWS側のレプリケーションサーバ両方から通信できない とダメ • CloudEndure → https://console.cloudendure.com • MGN → https://mgn.<region>.amazonaws.com * Regionは利用リージョンに合わせる
24. 続き・・・ 移行元・レプリケーションサーバから通信ができないといけない。 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
25. 続き・・・ 移行元・レプリケーションサーバから通信ができないといけない。 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
26. 続き・・・ 移行元・レプリケーションサーバから通信ができないといけない。 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
27. 27 余談： なぜ同じようなサービスが2つあるのか
28. 28 余談：CloudEndureとMGNの歴史的背景 https://twitter.com/CloudEndure/status/1083258144283942912 Cloudendureはもともと AWS外の会社だった • 2019年の年明けにAWS がCloudEndureを買収 • それから約半年後に90 日間、無料で使えるとい う発表 • さらに約1年後、MGNが 登場
29. 29 余談：CloudEndureとMGNの歴史的背景 https://twitter.com/CloudEndure/status/1083258144283942912 Cloudendureはもともと AWS外の会社だった • 2019年の年明けにAWS がCloudEndureを買収 • それから約半年後に90 日間、無料で使えるとい う発表 • さらに約1年後、MGNが 登場
30. 30 余談：CloudEndureとMGNの歴史的背景 https://twitter.com/CloudEndure/status/1083258144283942912 Cloudendureはもともと AWS外の会社だった • 2019年の年明けにAWS がCloudEndureを買収 • それから約半年後に90 日間、無料で使えるとい う発表 • さらに約1年後、MGNが 登場
31. 31 まずはMGNを使ってダメなら CloudEndureを使う
32. 32 MGNの使い方
33. 33 説明用ざっくりアーキテクチャ
35. 35 事前に準備しておくもの
36. 36 VPC レプリケーション用とターゲット用の2つのVPCを用意する * レプリケーション用は必要に応じてインターネットゲートウェイのアタッチを
37. 37 セキュリティグループ レプリケーションサーバ用(TCP:1500のインバウンド) と ターゲットインスタンス用(使用用途に合わせて) を用意する
38. 38 IAMユーザ アクセスキー/シークレットキーが必要なためプログラム実行 用のIAMユーザを用意する 権限は「AWSApplicationMigrationAgentPolicy」
39. 39 MGNの初期設定
40. 40 Replication Settings まずはレプリケーション環境の設定を行う。 * はじめてコンソールにログインするとこの設定を求められます。
41. 41 Replication Settings まずはレプリケーション環境の設定を行う。 * はじめてコンソールにログインするとこの設定を求められます。
42. 42 Replication Settings まずはレプリケーション環境の設定を行う。 * はじめてコンソールにログインするとこの設定を求められます。 起動サブネット インスタンスタイプ ボリュームタイプ ボリュームの暗号化 セキュリティグループ PrivateIPを使用するか 帯域幅の指定(1Mbps単位) タグ付け
43. 43 ローカル環境のサーバに エージェントをインストールする
44. 44 エージェントのインストールコマンド Linuxの場合 ◆インストーラーをダウンロード wget -O ./aws-replication-installer-init.py https://aws-application-migration- service-<region>.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py ◆実行 sudo python3 ./aws-replication-installer-init.py --region <region> --aws-access- key-id <access_key> --aws-secret-access-key <secret_key> 参考 : https://docs.aws.amazon.com/mgn/latest/ug/linux-agent.html
45. 45 エージェントのインストールコマンド Windowsの場合 ◆インストーラーをダウンロード https://aws-application-migration-service- <region>.s3.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe ◆実行(管理者で実行) AwsReplicationWindowsInstaller.exe --region <region> --aws-access-key-id <access_key> --aws-secret-access-key <secret_key> 参考 : https://docs.aws.amazon.com/mgn/latest/ug/windows-agent.html
46. 46 実行時に聞かれること どのディスクを対象にするかを聞かれる そのままEnterで全てが対象になる
47. 47 自動的にレプリケーションを開始させたくない デフォルトだとインストールと同時にレプリケーションが開始 される。 させたくない場合は --no-prompt オプションを付ける 参考 : https://docs.aws.amazon.com/mgn/latest/ug/windows-agent.html
48. 48 MGNの画面を確認
49. 49 エージェントインストール後 エージェントをインストールしたサーバの情報が表示される
50. 50 エージェントインストール後 レプリケーションの進捗情報を確認できたり (Migration dashboard)
51. 51 エージェントインストール後 サーバの情報が確認できたりする(Server info)
52. 52 レプリケーションサーバも起動している レプリケーションサーバも見えます
53. 53 レプリケーションが完了すると・・・ Ready for testing状態になっていることを確認する
54. 54 ラグがないことも確認しておく ラグがなく同期できていることも確認する
55. 55 これで初期同期が完了 継続的なレプリケーションが 維持されている状態
56. 56 起動情報を確認する
57. 57 起動情報を確認する EC2の起動情報を確認する(Launch settings)
58. 58 起動情報を確認する インスタンスタイプが古かったり ボリュームタイプがio1だったりすることがあるので 出来る限り確認して変更したほうが良い
59. 59 起動情報を変更したい場合 作成されているEC2の起動テンプレートを変更する
60. 60 テストモードで起動する
61. 61 テストモードで起動する テストモードで起動する
62. 62 テストモードで起動する Conversionサーバというデータ移行用サーバが一時的に作成 される(作業が終わり次第削除される)
63. 63 テストモードで起動する First boot : Succeededを確認 実際にサーバにアクセスしてアプリのテスト等行ってみる
64. 64 テストモードで起動する テストOKであればReady for cutoverのマークを付ける
65. 65 テストモードで起動する テストに問題がある場合は再度テストモードを実行する 再実行した際は既にあるテストモードのインスタンスは削除さ れて新しいインスタンスが作成される
66. 66 カットオーバーでサーバを移行する
67. 67 カットオーバーでサーバを移行する 本番移行日を迎え、いよいよサーバを移行するタイミング とはいえ、レプリケーションが止まるだけで元のサーバが削除 されるという訳ではない
68. 68 カットオーバーでサーバを移行する Ready for cutoverであることを確認
69. 69 カットオーバーでサーバを移行する Cutoverモードで起動する テストモードインスタンスが削除され、新しいインスタンスが作成される
70. 70 カットオーバーでサーバを移行する 起動後のテストが問題なければFinalize cutoverを実施
71. 71 カットオーバーでサーバを移行する これでサーバ移行が完了 レプリケーションサーバも削除される
72. 72 実際の移行からの学んだこと 気を付けるべき点
73. 73 学んだこと、気を付けるべき点 • エージェントインストール要件の確認 • OSはサポートされているか、必要なソフトウェアは揃っているか • 適切なドライバの用意、設定を行う必要がある • 移行ネットワークの確認 • 帯域確保、オンプレミス環境に動作影響を与えないか • ライセンスの有無 • Windows / SQL Server / RHELの場合は特に注意 • テストモード時のAWS利用費を気にする • レプリケーションのEBS代 / テストモードのインスタンス代、EBS代が常 に発生するため、計画的に利用する
74. 74 移行時に詰まったポイント • テストモードで起動はできたもののステータスチェックに 失敗し接続ができない • EC2 RescueでOSログを調査→ドライバーインストール失敗を 確認→ネットワーク機能が正常に動いていなかった。 • 根本原因はWindowsの修正パッチ適用不足 • Windows Updateは行った上で移行を実施する
75. 75 ここからが本当のスタートライン
76. 76 クラウドの最適化 • Rehostはクラウド最適化における第一歩でしかない • この土台を生かしてクラウドをガンガン活用していく
77. 77 まとめ
78. 78 まとめ • クラウド化の第一歩としてオススメなサービス 「AWS Application Migration Service」 • まずは試す。ダメなら他の方法を考える。