LAC WATCH

セキュリティとITの最新情報

RSS

株式会社ラック

メールマガジン

サイバーセキュリティや
ラックに関する情報をお届けします。

サービス・製品 | 

運用コストを削減する、VMWareからAWSへの移行~AWS Application Migration Serviceの概要と注意点

2023年にBroadcom社がVMWare社を買収したことで、VMWare製品のライセンス体系が変更されました。従来の買い切りモデルからサブスクリプションモデルへ変更された結果、多くのユーザにとってライセンスコストが増加したのではないでしょうか。この状況を受け、今後もVMWareを使い続けるのか、あるいは他のプラットフォームに移行するのか、戦略的な判断を迫られるタイミングと言えるでしょう。

そこで今回は、VMWareからクラウドへのスムーズな移行を可能にするAWSサービス、「AWS Application Migration Service(以下、AWS MGN)」をご紹介します。クラウド移行を検討する際のヒントになれば幸いです。

AWS MGNとは

AWS MGNとは、オンプレミス環境や他のクラウド上で稼働しているWindows、およびLinuxマシンで稼働しているアプリケーションやデータベースを、AWSに移行するサービスです。ダウンタイムを最小限に抑えながら、安全かつ効率的にリフト&シフトである「リホスト」を実現します。

AWS MGNを使用した移行方法は、以下の2種類があります。

  • AWS Replication Agentを移行元サーバにインストールする方法
  • Application Migration Service vCenter ClientをvCenter環境にインストールする方法(移行元サーバにAWS Replication Agentをインストールしないため、エージェントレスレプリケーションとも呼ばれる)

AWS Replication Agentをインストールする方が移行を迅速に行えるため、AWSはこちらの方法を推奨しています。会社のセキュリティポリシーなどにより、移行元サーバにAWS Replication Agentをインストールできない場合は、エージェントレスレプリケーションを活用することで対応可能です。

本記事ではAWS Replication Agentを使用した移行方法についてご紹介します。

AWS MGNのアーキテクチャと処理の流れ

AWS MGNのアーキテクチャを簡単にまとめると、以下のようになります。詳細なアーキテクチャ図については下記のドキュメントをご参照ください。

Network requirements for Application Migration Service - Application Migration Service

AWS MGNのアーキテクチャ

VMWare(移行元サーバ)にAWS Replication Agentをインストールすると、AWS上にReplication Server(図中①)と呼ばれるEC2が自動で作成されます。このReplication Serverを通じて、移行元サーバのデータは非同期で転送され、EBSへレプリケートされます。その後、AWS MGNサービス画面で「テストインスタンスの起動」を実行すると、レプリケートされたEBSを使用してConversion Server(図中➁)が自動で起動し、ブートローダーの変更やクラウドツールなどのインストールを行います。

さらに、Test Instance(図中③)も自動で起動します。このEC2はAWSへ移行した後、テストをするためのインスタンスです。その後、AWS MGNサービス画面で、「カットオーバーの準備完了としてマーク」、「カットオーバーインスタンスを起動」を実行すると、Cutover Instance(図中④)が自動で起動します。これで、VMWare上のアプリケーションをEC2上に移行できます。

実際に以下の構成で検証してみましたが、オンプレミスにあるVMwareからAWS上のEC2にアプリケーションを移行できました。

  • VMWareのOSはRocky Linux 9.4
  • オンプレとAWS間はインターネット接続
  • VMWareにApacheをインストールしてテストページが表示されることを確認し、AWSへ移行後も同じテストページが見られることを検証のゴールとする

AWS MGNの詳細な設定手順については以下をご参照ください。

Quick start guide for AWS Application Migration Service - Application Migration Service

注意点

検証するにあたり、注意したいポイントをまとめました。AWS MGNを検証する方の参考になれば幸いです。

AWS MGNで発生する通信

1. 必要な通信ポートを開放する

移行元サーバとAWS MGN間でTCPポート443、および移行元サーバとStaging Area Subnet間でTCPポート1500を介した通信が発生します。

ラックの社内ネットワークではTCPポート1500の通信がブロックされているため、移行がうまくいきませんでした。そこで、社内ネットワーク管理部門に相談し、TCPポート1500の通信を許可してもらうことで検証を再開できました。そのため、AWS MGNを使用する際は、通信が社内で許可されているか事前に確認するとよいでしょう。

2. SSLインターセプトに注意

Replication ServerとApplication Migration Service API エンドポイント間の通信、移行元サーバとAWS MGN間の通信に、SSLインターセプトを適用しないというネットワーク要件があります。

しかし、ラックの社内ネットワークでは、SSLインターセプトが適用される製品を使用しているためか、「AWS Replication AgentをReplication Serverに接続」でエラーが発生し、レプリケーションがうまくいきませんでした。こちらも社内ネットワーク管理部門に相談し、SSLインターセプトを通らないようにしてもらうことで検証を進めました。その他にもネットワーク要件がありますので、以下をご参照ください。

Network requirements for Application Migration Service - Application Migration Service

セキュアブートが有効になっているとエラーが発生する

移行元のサーバでセキュアブートが有効になっていると、エラーが発生することがあります。AWS MGNではサポートされていないため、セキュアブートはオフにしましょう。

EC2 Linux インスタンスでの AWS レプリケーションエージェントのインストール失敗を修正 | AWS re:Post

kernel-devel/linux-headersは必ず事前に手動インストールする

AWS Replication Agentインストール要件として、移行元サーバ(Linuxマシンの場合)には実行中のカーネルと同じバージョン番号(uname -rの出力と同じ)のkernel-develとlinux-headers(もしくはkernel-headersなど)が必要です。

例えばRocky Linux 9.4で検証した場合、インストール直後のカーネルバージョンは「5.14.0-427.13.1.el9_4.x86_64」でした。しかし、「aws-replication-installer-init」コマンドを実行すると、「kernel-headers-5.14.0-503.15.1.el9_5.x86_64」が自動的にインストールされており、実行中のカーネルと同じバージョンにする要件を満たせなかったため、「aws-replication-installer-init」コマンドがエラーになりました。

不足するパッケージがある場合、「aws-replication-installer-init」コマンドによって自動でインストールされるものの、必ずしも実行中のカーネルのバージョンと一致するわけではないので、事前に手動でインストールしておくのが安全です。さらに、古いカーネルを使い続けているシステムは、すでにリポジトリ上に古いカーネルに対応するパッケージが存在しない場合も考えられるため、実際の稼働中のシステムを移行する際はこのあたりのパッケージのインストールが懸念点になると感じました。

「aws-replication-installer-init」コマンドを実行する前
「aws-replication-installer-init」コマンドを実行する前
「aws-replication-installer-init」コマンドを実行した後
「aws-replication-installer-init」コマンドを実行した後

Installation requirements - Application Migration Service

おわりに

VMWare上のアプリケーションをAWSに移行するのは敷居が高いと感じる方も多いかもしれませんが、AWS MGNを利用すれば大部分が自動化されており、移行自体は簡単にできました。

ただし、ネットワーク構成やIPアドレスについては、移行する前に考慮する必要があります。例えば、外部に公開しているWebサーバを移行する際は、オンプレミスで使用していたグローバルIPアドレスをAWSでも使用できるのか検討する必要があります(AWS BYOIPの利用など)。さらにDNSにて名前解決をしていて、AWSに移行後にグローバルIPアドレスが変わる場合は、DNSサーバに登録するIPアドレスも変えることになるため、移行計画をしっかり考える必要があります。

なお、AWS MGNには、移行元サーバ1台につき2,160時間(90日)の無料期間があります。特に、VMware環境のライセンス費用や運用コストに課題を感じている方にとって、AWSへの移行はコスト削減や運用負荷を軽減する有効な手段です。「クラウド移行に興味はあるけれど、何から始めれば良いかわからない」「計画や技術面で不安がある」という方は、ぜひラックまでご相談ください

プロフィール

CCoE部AWS推進チーム

CCoE部AWS推進チーム
CCoE部AWS推進チームではAWSの各サービスを最大限活用するために日々技術検証や教育プログラムの検討を行っております。その活動のなかで得られた有益な情報を外部へ発信していきます。

関連サービス
AWSインテグレーション
「クラウドインテグレーション」に関するお問い合わせ

この記事は役に立ちましたか?

はい いいえ

関連記事

LAC WATCH

関連記事をご紹介します

  • VMware HCXを使ってオンプレミスからOCVSへの移行とL2延伸を試す(前編)

  • VMware社最大のイベント「VMware Explore 2023」へ出展、OCVSを活用した新サービスを展示

  • AWS利用を検討中の方必見!「セキュアなAWSアカウントにするために」を公開

関連サービス
AWSインテグレーション