さくらのクラウドからAWS Application Migration Serviceを使用して移行作業をしてみた感想

こんにちは、Maromaroの松橋です。

さくらのクラウドからAWSへ移行する機会があり、AWS Application Migration Service(MGN)を使用してみました。
その時に、まとめた内容や感想などをご紹介していきたいと思います！

AWS Application Migration Serviceとは、

AWS Application Migration Serviceの公式サイトから引用すると、

変更を加えることなく、最小限のダウンタイムで、アプリケーションをクラウドに移行するメリットをすばやく実現できます。

AWS Application Migration Service は、ソースサーバーを物理インフラストラクチャ、仮想インフラストラクチャ、およびクラウドインフラストラクチャから AWS でネイティブに実行するように自動的に変換することにより、時間のかかる、エラーが発生しやすい手動プロセスを最小限に抑えます。同じ自動化されたプロセスを広範なアプリケーションに使用できるようにすることで、移行をさらに簡素化します。

また、移行前に中断なしのテストを実行することで、SAP、Oracle、SQL Server などの最も重要なアプリケーションが AWS でシームレスに動作することを確信できます。

ということで、最小限のダウンタイムで、AWSへ移行でき、本番サーバーを中断することなく、テストを実行できるAWSの移行サービスとのことでした。すごいです。

似たようなサービスに、CloudEndureというサービスがあるのですが、こちらはAWSが2019年に買収し、その後にAWS Application Migration Serviceが出来た、という背景があったようです。

ちなみに短縮すると、AMSではなく、MGNだそうです(以下MGN)。

CloudEndureというサービス自体は残っているのですが、AWSマネジメントコンソールから操作が出来ない、2022 年 12 月 30 日に、ほとんどの AWS リージョンで使用できなくなるとのことでした。使用にあたっての要件は、大体一緒なので、MGNで移行できないようであれば、CloudEndureというサービスという選択肢もある作戦を考えてました。(※結局使用しませんでしたが)

AWS Application Migration Service(MGN)を選んだ理由

今回の予定は、AWSに環境を移行させ、WAFやAWS Backupなどのサービスを入れていくというものです。

MGNを選択した背景としては、「第一ステップとして一旦環境そのまま移行し動作させるようにしたい」＆「ダウンタイムを最小限にしたい」という要件があり、それが実現できそうなのがMGNとCloudEndureでした。

先述した通り、AWSマネジメントコンソールが使用でき、作業プロセスを両方比較するとシンプルそうだなという理由でMGNを選択しました。

不安材料としては、去年(2021年5月)にサービスがスタートしたばかりということで、WEBに参考記事や知見が少ないのではというところぐらいでした。

移行してみた感想・注意点

実際にMGNを使用し、データのレプリケート(複製)をさせ、DNS切替をし、移行が完了しました！

さくらのクラウドサーバーからのレプリケートも数十分置きにしてくれて、差分を除去してくれてたので、ここはすごいなと感じました。

それでも、躓いた点・注意点はあったので、列挙していきたい思います。

移行元サーバーのtmpディレクトリの空きディスク容量を500 MBにすること。

移行元サーバーで、MGN指定のPythonファイルを走らせて、AWSへデータをレプリケートさせるのですが、その要件として、tmpディレクトリの空きディスク容量を500 MBにする必要があります。

参考：https://docs.aws.amazon.com/ja_jp/mgn/latest/ug/installation-requiremets.html

しかし、今回の移行元サーバーはこの容量が少なく、こちらの要件を満たせませんでした。

要件を満たすためにはサーバーのスペックを上げる必要がありました。

そのため、exportコマンドなどでパスに別のディレクトリを追加することで、擬似的にプログラムが走るのでは。。。？ということで試したのですが、上手くできずでした。。。。

素直に移行元サーバーのスペックを上げて対応となりました。

この点は、移行元の起動中サーバーに、ある程度手を加えることがあるということを念頭に入れておく必要があります。

おすすめインスタンス・EBSボリュームタイプのままEC2インスタンスを起動させてしまった。

AWS Application Migration Serviceで起動したテストサーバーや本番サーバーのインスタンスタイプが金額が高めのもの(c4.large)でした。

スペック的にも過剰ということで、グレードを下げたのですが、インスタンスタイプなどのサーバー起動情報は立ち上げ前に一度確認したほうが良さそうです。

また、EBSボリュームタイプも同様に、金額が高めのio1に設定されたまま起動してしまいました。

io1のボリュームタイプはIOPS（Input/Output Per Second）がかなり早いタイプなのですが、金額が高いので、インスタンスタイプと同様に、本番サーバーを起動する前に、EBSボリュームタイプが何に設定されているのか、こちらも確認したほうが良です。

さいごに

今回の経験によって、AWSについての知見が増えたので、今後さらに様々な移行作業に挑戦していきたと思いました！

以上、Maromaroの松橋でした。