オンプレミスからクラウド移行！AWS MGNによるリフト＆シフトでシンプルに始めよう

本記事では、オンプレミスからクラウドへ移行する際にリホストするためのツールAWS MGN (AWS Application Migration Service)を利用したリフト&シフトについてご紹介します。まず、リホストについて簡単な解説と、続けてAWS MGN の詳しい仕様や利用方法、実際に利用するにあたっての注意事項についても掘り下げて紹介していきたいと思います。

リホストとは

クラウドへの移行戦略としてAWSが提唱する”7R” がありますが、その中の一つ”リホスト”が今回の主題となります。

Rehost	リホスト
Replatform	リプラットフォーム
Refactor	リファクタリング
Relocate	リロケート
Repurchase	リパーチェス
Retain	リテイン
Retire	リタイア

リホストの特徴

特徴は“そのまま”クラウド移行することです。以下はオンプレミス環境からAWSへリホストにより移行した場合の図になります。ここでのポイントはAPサーバーはそのままAPサーバーへ、WEBサーバーもそのままWEBサーバーへとサーバーの役割・構成の変更はせずそのまま移行している点になります。

リホストのメリット

メリットは他の移行戦略と比べて素早く移行できる点となります。回線環境やストレージ容量にもよりますが数時間レベルで手早く移行できます。現状のOSをそのまま持ち込むため、アプリケーションの改修コストが低くく抑えられる、もしくは改修すらも不要で済む場合も多くあります。移行が完了すると、ハードウェアの所有も必要なくなり、Amazon EC2のスペック変更や同一イメージによる複数台起動などリソースの柔軟な伸縮が可能なクラウドとしてのメリットが享受できます。

リホストのデメリット

デメリットは現状の問題点も引き継いでしまう点となります。サポート切れの古い OS や既知の不具合、脆弱性なども全てそのままとなります。また、Amazon EC2での運用となるため、今まで通りOSやミドルウェアの管理、DBのバックアップなど、OSレベル以上の管理運用は必要となります。

その他、AWSが提供している移行ツールにおいてサポート対象外のOSをAWSに持ち込むことを検討する場合、難易度が上がります。その場合、Amazon EC2で動作させることが難しいことも考えられるので、他の”7R”、リプラットフォームのような、新しい環境として作り直すなど、他の移行戦略を検討する必要も出てきます。
AWS移行支援サービス

AWS MGN (AWS Application Migration Service)とは

AWS MGN (AWS Application Migration Service)は、オンプレミスの物理環境・仮想環境やパブリッククラウドのサーバーを無停止でAWS上にレプリケーション（複製）し、AWSへの移行を迅速におこなうことができるリホストの中核となるサービスになります。

特徴

主な特徴は下記になります。

– 断続的なレプリケーションにより、移行に伴うダウンタイムを最小化
– Agent版とVmware vCenterを対象とするAgentLess版の二種類が提供されている
– 幅広い対象OS
– 1台あたり90日間無料で利用可能

Agent版とAgentless版の比較

Agent版

– 物理・仮想サーバー両方の環境に対応
– 移行元のサーバーにAgentをインストールする必要がある
– ブロック単位での継続レプリケーション

Agentless版

– Vmware vCenterに AWS MGN vCenter Clientをインストール
　※対応バージョン 6.7 or 7.0
– スナップショット単位の継続差分レプリケーション

AWS MGN対象OS

– Microsoft Windows Server 2003/2008/2012/2016/2019/2022
– Microsoft Windows 10
– CentOS 6.0以上 (Agentless版のみCentOS5.0以上の対応)
– RHEL 6.0以上
– SUSE Linux 12以上
– Debian Linux 8以上
– Ubuntu 12.04以上
– Oracle Linux 6.0以上

AWS MGN対象OSであってもカーネルのバージョンなどに制約がある場合もあり、事前に確認が必要です。
Supported operating systems

素早い移行にはAWS MGNがオススメ

AWS MGN対象OSを利用していて、クラウド移行を検討している場合は、AWS MGNによるリホストからはじめてみませんか？AWS MGNはAgentをインストール後、数時間単位での迅速な移行が可能となります。また、先にあげた制約や懸念点はありますが、リホスト後に他の移行戦略”7R”、リプラットフォームやリファクタリングを進めるにもかなりのメリットがあります。

AWS MGNを利用した移行の流れ

実際にAWS MGNを動作させると以下のような流れになります。まず、AWS MGNの設定および移行元サーバーへのAgentのインストールを実施すると、Agentをインストールした時点で自動的にReplication Serverへデータの複製が開始されます。

レプリケーションが完了した後、AWS MGNのコンソール上よりインスタンス起動を実行します。インスタンスが起動するフェーズには、動作確認用のテストインスタンスと、本番稼働用のCutoverインスタンスの二種類があり、テストインスタンスで内容を確認した後、本番稼働用のインスタンスを起動する形になります。

今回はこちらの図に沿って、実際にAWS MGNを利用したクラウド移行の流れを解説していきます。

（１）AWS MGNの初期設定

まず、AWS MGNの初期設定からおこないます。

AWS MGNのサービスページ右上、 Get startedをクリックしAWS MGNのページへ移動します。

初回は Set up Application Migration Service というページに遷移します。ここでは、AWS MGNが立ち上げる Replication Serverの実行環境の設定変更をおこないます。移行サーバーの台数などにもよって必要な性能は変わってきますが、ネットワークは外部疎通の可能なsubnet上に構築すれば問題ありません。

今回はAmazon EC2インスタンスサイズは初期設定のままt3.small、subnetとセキュリティグループを変更しています。変更が完了しましたら、下部の Create Template をクリックします。

左メニューの Settingsから Replication templateを確認して、先程設定した内容であれば変更は完了です。

（２）移行元サーバーへのAgentのインストール

次に移行元のサーバーにAgentのインストールを実施します。

AWS MGNの左メニューから、 Source Serversを選択します。
※こちら画面は移行元サーバーの状況や移行の状況が確認できるページです。

右側中段の Actionsの中または中央に表示されている Add Serversを選択し、詳細設定をしていきます。

Agentインストールに関する設定

ここでは、Agentインストールに関する設定を入力していきます。

レプリケーションするディスクについての設定とレプリケーションするために必要な権限を持ったIAMアクセスキー、 IAM シークレットキーの入力をおこないます。adminの権限を持った一時的な認証情報を利用していますが、最小権限に絞ったものを利用することが推奨されます。

なお、このフォームの実態としては上に入力したIAMアクセスキーを下のインストールコマンドの引数へ自動入力し、コピーペーストでの実行を可能とする支援ツールです。引数などが正しければ特にここに入力せずともAgentのインストール自体は可能です。

次に、ここで発行されたwgetコマンドでインストールスクリプトの取得とPythonコマンドでのAgentインストールを実行していきます。

wgetコマンドでインストールスクリプトの取得とPythonコマンドでのAgentインストール

対象サーバーにコマンドが実行できる形でログインします。今回は検証用の物理サーバー（FUJITSUのRX100S7、CentOS7）を対象としています。先ほどの設定画面で出力されていた wgetコマンドでインストールスクリプトを取得した後、Pythonのコマンドでインストールを実施します。今回は一時認証キーを利用していますのでトークンを要求されていますが、IAMユーザの認証キーを利用する場合は要求されません。

出力されている、Agentのダウンロードとインストール、AWS MGNとの通信チェックなどが走ったあと、The AWS replication agent was successfully installed. と表示されればインストールは完了です。
※上記コンソール画面はカットされています。

（３）レプリケーション（複製）

移行元のサーバーへのAgentのインストール完了後は、AWS MGNのページに戻ります。AWS MGNのインストールが完了すると AWS MGNを通じて Replication Server が起動しレプリケーションが自動的に開始されます。

AWS MGN上ではSource ServersにはAgentをインストールしたサーバーが自動的に追加され、Data Replication 上には進捗表示され、レプリケーションが開始されています。以下の状態だと、全体の8%が完了し、残り3時間ほどかかるという表示になっています。

移行対象のサーバーを選択すると、詳細情報や次にすべきことを確認できます。以下は、レプリケーションが完了していないので、レプリケーションが完了するのを待つように記載されており、また、画面中央にはLifecycleが表示されており、移行フェーズが視覚的にわかりやすく表示されています。

Amazon EC2のダッシュボードの確認

この段階でAmazon EC2のダッシュボードを確認すると、先程 settings で設定した Replication Server が起動していることが確認できます。本作業はAWS MGNが起動や停止を制御しており、ダッシュボードで停止してしまうとAWS MGNのレプリケーション動作に影響が出ますので手動での操作はなるべくおこなわないようにしましょう。

（４）移行先サーバーの設定

レプリケーションの待ち時間に移行先サーバーの設定をおこなっていきます。

移行先サーバーの設定は、AWS MGN設定の詳細画面の上部のタブ「Launch settings」内でおこないます。初期設定では Instance type right sizing が Basicとなっており、下部のインスタンスサイズも C4.2xlargeと自動的にサイジングされていることがわかります。今回はここまでスペックは必要ありませんので、設定を変更していきたいと思います。General launch settingsの右上、Editを開きます。

以下画面で Instance type right sizingを offへ変更します。

以下設定ページで反映されていることを確認後、modifyを選択して Amazon EC2 Launch Template を変更していきます。

以下画面は縦に長いので二分割していますが、通常のAmazon EC2起動テンプレートはAWS MGNに紐づいたものが作成されており、こちらを修正して移行後のサーバー設定を作成していきます。以下では起動subnet、キーペア、インスタンスタイプ、ストレージタイプを変更してテンプレートのバージョンを作成しています。

起動テンプレートのデフォルトバージョン修正

テンプレートのバージョンを作成した後、起動テンプレートのデフォルトバージョンを修正します。現在は1がデフォルトとなっており、インスタンスタイプがc4となっていますが、こちらを設定したものに差し替えます。右上アクションからデフォルトバージョンを選択します。

表示されたGUI上で設定したバージョンを選択し、デフォルトバージョンとして設定を選択します。

起動テンプレートの修正後、AWS MGNのLaunch Settingsに戻り、 EC2 Launch Template が変更されていれば完了です。

（５）サーバーの起動テスト

数時間経過してレプリケーションが終わったと仮定して先に進みます。

AWS MGNの画面を確認すると、 Ready for testing と表示されていることがわかります。この状態になると、レプリケーションが追いついた状態となり、サーバーの起動テストが可能となります。

テストインスタンスの起動

右上の Test and cutover から Launch test instanceを選択します。

サーバーを1台起動しますが良いですか？と確認画面が挟まりますので、 Launchで先に進みます。

AWS MGNのLifecycleが Test in progressとなりました。

Amazon EC2のダッシュボードでのConversion Serverの起動確認

このタイミングでAmazon EC2を確認すると、 AWS Application Migration Conversion Server が起動していることがわかります。こちらのサーバーはConversion、つまり起動イメージの変換をおこなっているサーバーになります。

しばらくするとテストサーバーの起動が完了し、AWS MGN上の表記が変わります。Lifecycleの左下にView in EC2 consoleと表示されていますので、こちらをクリックしますと、対象のAmazon EC2に絞られたコンソールが表示されます。

（６）移行先テストインスタンスの動作確認

Amazon EC2インスタンスの情報を確認し、移行後のサーバーへログインします。

このフェーズでは、対象のインスタンスへの接続ができるか、OS自体の動作確認やアプリケーションの動作、データの複製状況などに問題がないかなどを確認します。

テストサーバーで確認すること
✔ OS自体の動作
✔ アプリケーションの動作
✔ データの複製状況

テスト/カットオーバインスタンスの違いについて

ここで一度、テストとカットオーバのフェーズの違いについて表しておきます。

確認することの一例として上げた、OSの稼働状況やアプリケーションの稼働状況、更にはデータの複製状況などをテストフェーズで確認する必要があります。

ここで、OSやアプリケーションの動作に問題がある場合は、移行元サーバーでそれぞれの設定を見直す必要があるかもしれません。また、移行対象サーバーからレプリケーションが正常におこなわれている間は自動的に同期されており、フェーズを巻き戻すことで何度でもその時の最新状態で テストインスタンスおよびカットオーバインスタンスの再作成が可能となります。

問題がなければ サービス切り替えの直前に、データ同期がされた状態の本番稼働サーバーを起動する流れとなります。

（７）カットオーバインスタンス(本番環境)の起動

ここではテストに問題がなかったと想定して進めます。テストサーバーの確認が完了後、以下図のとおり、Mask as “Ready for cutover” を選択します。

Continueを選択すると、テストインスタンスは自動的に停止されますので注意してください。これはあくまでテスト済みというフラグを立てて次のフェーズへ向かうだけの操作となります。

先程説明したとおりですが、Mask as “Ready for cutover” の下にある Revert to “Ready for testing” を選択することでテストフェーズをやり直すことが可能です。

Mask as “Ready for cutover” の選択を完了すると、Lifecycleの表示が Ready for cutoverまで進みます。次に、テストフェーズと同様に Launch cutover instancesを選択し、カットオーバーインスタンスを作成します。この操作は、システムの運用開始、つまり最終的に本番のインスタンスを起動するフェーズとなります。

Launchを選択するとカットオーバサーバーの起動がはじまります。

テストフェーズと同様に少し待つと Next actionsに Finalize cutoverの表示と、lifecycleに View in EC2 console　が出力されます。Amazon EC2の起動が完了していますので、テスト時と同様にAmazon EC2の情報を確認し、接続確認などを動作チェックを実施します。

疎通などに問題がなければ、移行対象のサーバーのAWSマイグレーションが完了です。

（８）AWS MGN上に完了したフラグを立てる（後処理）

最後に後処理的なものですが、 AWS MGN上に完了したフラグを立てましょう。先程と同様にTest and cutoverから Finalize cutoverを選択します。

Finalize を選択すると、AWS MGN上移行が完了した扱いとなり、自動的に移行元サーバーとのレプリケーションが停止され、移行元サーバーにインストールしていたAgentが自動的に停止・アンインストールされます。

Lifecycle上でも Cutover complete となればAWS MGN上でも処理が完了です。

こちらを実施しないとAWS MGNのレプリケーションが継続するため、レプリケーションインスタンスは起動したままとなり、また90日を超えるとAWS MGN自体にも課金が発生してしまうため、特に理由がない場合は移行終了のタイミングで停止しましょう。

逆に、サービス切り替えなどのタイミングの関係でcutoverを後日にしたい場合はFinalizeはせずにテストインスタンスのときと同様にRevert、つまりフェーズを戻すことが可能ですので、完全に移行が終わったタイミングで完了しましょう。

NHNテコラスでは、AWS移行をオールインワンで請け負う「AWS移行支援サービス」を提供しています。マンガでわかる「AWS移行支援サービス」の資料では、サービスを利用した移行事例や実際の移行の流れをわかりやすく解説しています！

AWS MGNの動作環境や通信要件の構成図

最後に、AWS MGNの動作環境や通信要件の構成図がこちらとなります。

基本的には、移行元環境からの外向き443番ポートおよび1500番ポートの通信が可能であることが要件となります。今まで紹介してきた流れの通りですが、レプリケーションサーバーやカットオーバサーバー、移行後サーバーについてはAWS MGNが自動で生成や破棄をおこなってくれますので、ユーザーがそのあたりを意識することなくスムーズな移行が可能となります。

「AWSクラウドエコノミクス」評価サービス
→移行時のTCO（総保有コスト）の削減効果をレポートで可視化し、コストへの不安を解消します！

AWS MGNの注意点

実際にサービス切り替えをおこなうのであればそのタイミングでアウトバンド回線の帯域やDB/その他データの同期の調整、各サーバーの特性を把握した事前準備など注意すべき点があります。

DBサーバーの整合性

DBサーバーをAWS MGNによるレプリケーションで完全な同期を取るのであれば、本番切り替えの際に一時的にサービスを停止し、AWS MGNの同期を待って整合性が取れているか確認してから切り替えるなど配慮する必要があります。しかし、テスト時はある程度の欠損を許容して確認すればクラッシュリカバリなどで基本的には問題なく動作確認は取れると思います。

Push型の処理サーバー

移行対象サーバーがPush型の処理をおこなうようなサーバーであれば、テストサーバーを起動したタイミングでPush型の処理がおこなわれてしまうと本番環境に影響が出てしまう可能性があります。その場合はあらかじめ自動起動を止めておくことや、外部疎通ができないVPCを予め作成して起動するなどを検討する必要があります。

AWS MGNでの移行を試してみよう（まとめ）

AWSへの移行を検討していて、対象システムのOSがAWS MGNに対応している場合、AWS MGNによるリホストはオススメです。

AWS MGNで移行をテストして検討する

注意点もありますが、特に懸念点が無くAWS MGNが利用可能なOSの場合は、AWS上での動作を確認するために、AWS MGNでテストインスタンスを起動し、動作確認した上で、改めて移行戦略を考えるのも一つの手かとも思います。

まずはクラウドへ「リフト」してみる

また、移行はリホストしたら終わりではありません。AWSを適切に利用することで、さらなる最適化やクラウドの拡張性・可用性を享受することが可能となりますので、リホストした後、どのようにクラウドを活用していくかを考えていく必要もあります。しかし最初から理想の環境へ近づけることは難しいため、まずクラウドへリフトしてから、改めてクラウドシフトを検討しするのも遅くはないので、クラウドリフトはクラウド活用の第一歩になるかと思います。

リフト（まず “ここだけ” を考える） 今のサーバーをクラウドに移す	シフト クラウドに最適化する
■主な考慮項目 -対象OS -サービスの切り替えタイミング -Outboundの回線帯域 -DB・頻繁に書き換わるデータの整合性 -各サーバの特性に合わせた事前準備 etc…	■リプラットフォーム -リホストでそのまま持ってきたレガシーOSの最新化 -DBをAmazon RDSへの移行 ■リファクタリング -Auto Scalingの利用 -LambdaやAmazon ECSなどサーバーレスやコンテナの活用

移行支援サービスの利用を検討する

実際にサービス移行してみるには考慮点多くてすこし大変だな…なんて思われた方や台数が多くて手が足りないと思われた方、AWS MGNの対象OSに無いレガシーなOSがまた現役…なんて思われた方もいるかもしれません。その場合は、NHNテコラスのC-Chorusから提供しているAWS移行支援サービスをご検討いただければと思います。

NHNテコラスは、AWS移行コンピテンシーの認定を受けた、AWSプレミアティアサービスパートナーであり、今回ご紹介した各フェーズの評価から実際の移行、移行後の運用・監視代行まで一元した支援が可能です。本記事で上げたような考慮点を含め、さまざまな検討事項を当社でご支援いたします。非常に強力な支援内容となりますので、お気軽にご相談ください。

おすすめのサービス

• AWS移行支援
• AWS運用・監視代行