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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

6. 6
   AWS移行時の課題
   

   View Slide

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

   View Slide

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

   View Slide

9. 9
   その前に・・・
   

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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へインポート。エクスポ
    ート時の情報が最新。
    お
    す
    す
    め
    順
    ・
    導
    入
    し
    や
    す
    さ
    

    View Slide

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へインポート。エクスポ
    ート時の情報が最新。
    お
    す
    す
    め
    順
    ・
    導
    入
    し
    や
    す
    さ
    

    View Slide

18. 18
    CloudEndure MigrationとMGNの違い
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

32. 32
    MGNの使い方
    

    View Slide

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

    View Slide

34. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

39. 39
    MGNの初期設定
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

44. 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
    

    View Slide

45. 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
    

    View Slide

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

    View Slide

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

    View Slide

48. 48
    MGNの画面を確認
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

56. 56
    起動情報を確認する
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

77. 77
    まとめ
    

    View Slide

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

    View Slide

79. View Slide