最新S3ストレージクラス比較表〜新サービス・S3 Glacier Instant Retrievalとは？〜
enamin
デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
AWS Application Migration Serviceについてまとめてみた
yuhan
こんにちは！推しと同じ髪色、同じ位置にピアスを開けて、もうすぐ1年になるyuhanです。
前回のブログでは、AWSにおけるクラウド移行についてまとめた記事を書かせていただきました。
あわせて読みたい
AWSにおけるクラウド移行についてまとめてみた
今回は、AWSが提供するマイグレーション関連のサービスの中でも、AWS Application Migration Service（以下、MGN）に焦点を当てて、概要や各機能などをまとめていきます。
少しボリュームの多い記事になるかと思いますが、是非、最後までお付き合いいただけると幸いです。
AWS Application Migration Service（MGN）の概要
AWS Application Migration Serviceは、とても簡単に言うとAWSへの移行をサポートしてくれるサービスです。
MGNを利用することで、AWS環境への移行を簡単かつ迅速に行うことができます。
オンプレミス環境にあるサーバーをEC2にリホストしたい！という場合に、とても有効的に利用できます。
MGNのユースケース
MGNは、様々な環境からAWS環境への移行をサポートしています。
そのため、以下のようなユースケースで利用することが可能です。
- オンプレミス環境で稼働する仮想マシンや物理サーバーをAWS環境へ移行したい。
- AWS以外のパブリッククラウドや自社のプライベートクラウドなど他のクラウド環境で稼働するワークロードをAWS環境へ移行したい。
- 異なるAWSアカウントやリージョンにあるワークロードを移行したい。
MGNを利用するメリット
MGNの利用を検討されている方であれば、MGNを使うとどんなことが嬉しいの？というところが気になるかと思います。
MGNを利用して移行を行うことで、以下のようなメリットがあります。
- テスト含む一連の移行の流れを自動化されたプロセスで行うことができ、手で行う作業を最小限に抑えることができる。
- 複数台のサーバーをグループ化して移行の管理をすることができ、大規模移行でも効率的に対応できる。
- CloudWatch AgentのインストールやOSアップデート、ライセンス変換などを自動化することができ、移行後に行うタスクの負担を軽減できる。
- 上記の利点により、移行にかかる作業コストや人件費等のコストを削減できる。
移行には複雑なプロセスや対応コストが発生しますが、MGNを使うことでそこにかかる負担やコストを軽減できるのが、嬉しいポイントかと思います。
MGNの料金体系
MGNでは、サービス自体の利用料金とテストインスタンスなど移行の各プロセスの中で起動されたAWSリソースの利用料金がかかります。
MGNのサービス利用料金は、下記の通りです。
| MGNの使用 | 料金 |
|---|---|
| 1時間あたりのコスト | 0.042 USD/サーバー |
| 1ヶ月あたりのコスト | ～30 USD/サーバー |
MGNには無料利用期間があり、ソースサーバー1台につき、2,160時間（90日相当）は無料で利用することができます。
移行規模にもよりますが、この期間内に移行を完了させることができれば、MGNを無料で利用することができます。
MGNで移行を行うと、テスト用のEC2インスタンスやカットオーバーインスタンスが起動されます。これらのリソースについても、各サービスに応じた利用料金が発生するため、不要なインスタンスを起動したまま放置して無駄な費用が発生しないように注意をする必要があります。
MGNの各用語
MGNで登場する各用語について、簡単に解説します。（記載を統一してわかりやすくするため、カタカナ表記にしております。）
本項以降では、この用語を用いて説明を行うので、それぞれがどんな役割のものなのかイメージしながら読んでいただければと思います。
| レプリケーション エージェント | エージェントを用いて移行を行うために移行元のサーバーにインストールするエージェント。 |
| ソースサーバー | エージェントをインストールもしくはエージェントレスでMGNに追加した移行元のサーバー。 |
| レプリケーション サーバー | ソースサーバーのデータを同期するためのサーバー。 |
| ステージングエリア サブネット | レプリケーションサーバーが構築されるサブネット。 初期設定ではデフォルトVPCのパブリックサブネットが使用される。 |
| コンバージョン サーバー | EBSにレプリケートしたデータからAMIを作成するためのサーバー。 自動的に作成され、処理が終わったら自動的に削除されるので、利用者側であまり意識することはない。 |
| テストインスタンス | テスト用に起動するEC2インスタンス。 |
| カットオーバー インスタンス | 移行先のサーバーとして起動するEC2インスタンス。 |
2種類の移行方法
MGNでは、レプリケーションエージェントを使用した移行と、エージェントレスでの移行の2種類の移行方法があります。
これらの違いは下記の表の通りですが、セキュリティ要件などの特別な理由がない限りは、レプリケーションエージェントを使用することが推奨されています。
| レプリケーションエージェント | エージェントレス | |
| レプリケーション手法 | ディスクのブロック単位での レプリケート | スナップショット単位での レプリケート |
| 導入作業 | 移行元サーバーに エージェントをインストール | vCenter Client用の 仮想マシンの構築 |
| 要件 | Windows、Linuxで 利用可能 | VMware環境のみ broadcomアカウントが必要 |
次項で、レプリケーションエージェントを使用した移行とエージェントレスの移行について、それぞれ解説していきます。
レプリケーションエージェント
移行元のサーバーにレプリケーションエージェントをインストールして移行を行う場合、以下のような構成でMGNは移行を行ないます。
レプリケーションエージェントには以下のネットワーク要件があります。
- ソースサーバーは443番ポート経由でMGNと通信ができる。
- ソースサーバーとレプリケーションサーバーが1500番ポートで通信できる。
- レプリケーションサーバーからMGNへ通信ができる。（※）
※レプリケーションサーバーをプライベートサブネットに配置する場合はVPCエンドポイント等が必要。
レプリケーションエージェントは広いOSバージョンに対応していますが、古いOSなどは対応していない場合もあります。また、ディスクやメモリに十分な空き容量が必要です。利用する前には公式ドキュメントを確認しましょう。
大規模移行を検討されている場合は、それぞれの移行元のサーバーでエージェントをインストールする作業を行うのは負担になると思うかもしれません。
MGNコネクタという機能を利用すると、エージェントのインストールを自動化することができ、複数台のサーバーへの一括インストールを行うことが可能です。
MGNコネクタについては、後述の「MGNの各機能」で詳しく説明するので、ここでは割愛します。
先述の通り、MGNではレプリケーションエージェントの使用が推奨されており、エージェントレスと比べてカットオーバーウィンドウが最短になるなどのメリットがあります。
エージェントレス
エージェントレスで移行を行う場合の構成は以下の図の通りです。
エージェントレスで移行を行う際には、Application Migration Service vCenter Client用の仮想マシンを構築して、MGNとやり取りを行います。
セキュリティ要件などにより、レプリケーションエージェントのインストールができない場合に利用します。
エージェントレスの利用には、以下のネットワーク要件があります。
- vCenter Client をインストールする仮想マシンで、以下のアウトバウンド通信ができる。
- vCenter API が実行されているポート
- MGNのAPIと通信するための443ポート
- レプリケーションサーバーと通信するための1500ポート
また、vCenter Client用の仮想マシンには、以下のリソース要件があります。
| 要件 | メモリ | CPU | ディスクの空き容量 |
|---|---|---|---|
| 最小要件 （最大5台を並行でレプリケート） | 2 GiB | 1 コア | 10 GiB |
| オプションのパフォーマンス要件 （最大50台を並行でレプリケート） | 16 GiB | 8 コア | 10 GiB |
上記の他に、OS要件やvCenter のバージョンなどの制約もあるため、こちらも詳しくは公式ドキュメントをご確認ください。
MGNによる移行の仕組みと流れ
移行の仕組み
簡易的にですが、MGNがどのように移行を行うのか仕組みの部分を説明します。
MGNを使用するためには、まず移行元のサーバーをMGNにソースサーバーとして追加する必要があります。エージェントもしくはエージェントレスで追加を行います。
追加されたソースサーバーは、ステージングエリアサブネットに構築されたレプリケーションサーバーにより、データをレプリケートされます。
MGNは、レプリケーションデータと起動テンプレートなどで設定された起動設定を用いてAMIを作成します。この時、コンバージョンサーバーが使用されます。
コンバージョンサーバーにより作成されたAMIを元に、MGNはテストインスタンスやカットオーバーインスタンスを起動します。
移行の流れ
レプリケーションエージェントを使用する場合の大まかな移行の流れは、以下の通りです。
- Application Migration Service の初期セットアップを行う。（初回のみ）
- 移行先EC2を配置するVPCやステージングエリアサブネットなどを必要に応じて準備する。
- 移行元サーバーにレプリケーションエージェントをインストールして初回同期を実施する。
- 起動設定、起動後設定などを行う。
- テストインスタンスを起動して、テストインスタンスでテストを行う。
- テストで問題がないことが確認できたらカットオーバーを実行する。
- 起動したカットオーバーインスタンスで動作確認を行う。
- ソースサーバーをアーカイブして、移行を完了する。
MGNの初期セットアップを行うと、必要なIAMロール/ポリシー、MGNで使うテンプレートが自動的に作成されます。AWSコンソールもしくはAPIを利用して初期セットアップを行うことができます。
エージェントレスの場合は、③の手順がvCenter Clientのセットアップに変わりますが、その他の流れは大きく変わりません。
MGNでは移行における各ステップをライフサイクルとして管理しています。ソースサーバーを追加すると、コンソール上で以下のようにライフサイクルが確認できるようになります。
各ライフサイクルとその意味については以下の表をご参考にしていただければと思います。
| ライフサイクル ※()は日本語でのコンソール表記 | 概要 |
|---|---|
| Not ready （準備ができていません） | 初回のデータ同期を実行中で、まだテストができない状態。 |
| Ready for testing （テストの準備完了） | ソースサーバーがApplication Migration Service に正常に追加された状態。 テストインスタンスまたはカットオーバーインスタンスを起動できる。 |
| Test in progress （テストが進行中） | テストインスタンスが起動され、テストが実行されている状態。 インスタンスの起動ステータスが起動済みになったら、テストインスタンスでアプリケーションのテスト等を行う。 |
| Ready for cutover （カットオーバーの準備完了） | テストが完了し、カットオーバーインスタンスを起動できる状態。 |
| Cutover in progress （カットオーバーが進行中） | カットオーバーインスタンスを起動している状態。 インスタンスの起動ステータスが起動済みになったら、カットオーバーインスタンスで動作確認を行う。 |
| Cutover complete （カットオーバー完了） | カットオーバーが完了して、ソースサーバー上のすべてのデータがカットオーバーインスタンスに移行された状態。 |
| Disconnected （切断済み） | ソースサーバーがApplication Migration Service から切断された状態。 |
MGNの各機能
MGNには、移行を効率的に進めるための機能が備わっています。
それぞれについて、簡単に説明をしていきます。
Application
Application は、複数のソースサーバーをグループ化して移行の管理を行うことができる機能です。
ソースサーバーをグループ化することで、Application単位で移行タスクを実行することができます。1つのApplicationに、最大200台のサーバーを追加することができます。
例えば、Webサーバー単位、アプリケーションサーバー単位、という風に、サーバーの役割に応じたグループ分けをして移行管理をする場合などに有効です。
Wave
Waveは、Applicationをさらにグループ化して管理する機能です。
大規模なワークロードを移行する際には、Applicationによるソースサーバーのグループ化だけでなく、WaveによるApplicationのグループ化を行うことで、効率的に移行の対応を進めることができます。
例えば、役割ごとに行いたい処理はApplication単位で実行して、ワークロードに一括で行いたい処理はWave単位で実行するというような使い方ができます。
検証環境、本番環境でWaveを分けるなどの使い方も考えられると思います。
インポート/エクスポート
インポート/エクスポートは、ソースサーバーを一括でMGNに設定、あるいはソースサーバーの設定を出力する機能です。
ここで注意が必要なのが、この機能は仮想マシンファイルをインポート/エクスポートする機能ではないということです。
あくまで、MGNでの設定を一括で入出力するための機能であることは留意してください。
インポート
CSV形式のファイルを用いて、ソースサーバー、Application、WaveのインベントリをMGNにインポートします。
AWSコンソール画面から、インポート用のテンプレートファイルがダウンロードできるため、こちらを参考にインポートファイルを作成することができます。
※私が検証した際、ダウンロードしたテンプレートにおいて、一部のパラメータに誤り（誤： mgn:launch:tag:[KEY] 正： mgn:launch:tag:instance:[KEY]）がありました。使用する際は正しいパラメータであることを公式ドキュメントと合わせて確認することをお勧めします。
インポートの際は、ローカルディスクにあるファイルを使用するか、S3にあるファイルを使用するかを選択できます。
インポートを実行すると、ソースサーバーの一覧に「インポートされたサーバー」が追加されます。この状態では、まだエージェントのインストールなどがされていないため、別途対応が必要になります。
インポートの際、未作成のApplicationやWaveの名前を指定すると、新しくリソースが作成されますが、IDを指定すると、既存のリソースを参照しようとするため、この違いには注意が必要です。
エクスポート
ソースサーバー、Application、WaveのインベントリをCSV形式のファイルに出力します。
エクスポートするソースサーバーの選択はできません。
ローカルディスク、またはS3に出力することができます。ローカルディスクへの出力を選択した場合も、MGNによって自動的にS3が作成され、そこにファイルが格納されます。
MGNコネクタ
MGNコネクタは、複数のソースサーバーへのコマンドの実行を自動化できる機能です。先述のインポート機能と合わせて使用します。
MGNコネクタを使用したアーキテクチャ図は以下の通りです。
MGNコネクタはLinuxサーバーにインストールして使用します。OS要件や実行ユーザーの権限などの制約があるため、詳細は公式ドキュメントのこちらのページをご確認ください。
対象サーバーにSSHもしくはWinRMで接続して、レプリケーションエージェントのインストールを実行するため、ネットワークの許可設定やMGNコネクタが各サーバーへの接続で使用する認証情報が必要になります。
MGNコネクタを利用したレプリケーションエージェントインストールは、下記のような流れで行います。
- インポート機能でソースサーバーのインベントリをMGNに追加。
- MGNコネクタ用のLinuxサーバーを構築。
- MGNコネクタにソースサーバーを登録。
- 登録したサーバーの認証情報を設定。
- エージェントインストールのための前提条件の確認。
- レプリケーションエージェントのインストール実行。
1つのMGNコネクタにつき、最大500台のソースサーバーを処理することができます。AWSアカウントごとには、最大50台のMGNコネクタを利用することができます。
エージェントレスの場合は、vCeneter Client用の仮想マシンにMGNコネクタを共存させることが可能です。
Global View
Global Viewは、AWS Organizations を利用した、複数のAWSアカウントをまたがってソースサーバーを管理する機能です。
管理アカウントから設定を行います。
複数のAWSアカウントのソースサーバー、Application、Waveを横断的に参照・設定することができ、より柔軟に移行の対応を行うことができます。
Global Viewでできることの詳細については、こちらをご参照ください。
まとめ
AWS Application Migration Service（MGN）について、詳しくまとめてみましたが、いかがだったでしょうか。
実際に使ってみたなどの検証した内容も載せたかったのですが、文量が多くなってしまうので、今回は基本的な概要や機能についてのまとめに留めました。
AWSへの移行を検討されている方や、MGNを使ってみたいと考えている方に、少しでも参考になれば幸いです。
AUTHOR
