NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

注目のタグ
    トップ > クラウド > 高度に自動化された移行ツール AWS MGN　超便利なその裏側で何が行われているのか！

    高度に自動化された移行ツール AWS MGN　超便利なその裏側で何が行われているのか！

    クラウド MGN 基盤デザインウィーク

    本記事は  基盤デザインウィーク  3日目の記事です。
    🌈  2日目  ▶▶ 本記事 ▶▶  4日目  💻



    1. はじめに

    こんにちは。NRIネットコム2023年度新人社員の福川です。8月からインフラを扱う事業部に配属され、インフラの基礎やAWSについて学ぶ日々を送っています。
    NRIネットコムは、AWSより移行コンピテンシーの認定*1を受けました。そこで新人である私も、クラウドへの移行（マイグレーション）事業の推進に尽力することを目標に掲げ、より一層学習に注力しています！
    弊社のAWSマイグレーションサービスについては、 AWSマイグレーション（移行）サービス | NRIネットコムのクラウドソリューション をご覧ください。

    2. 今回のテーマ

    本ブログでは、AWS MGN（AWS Application Migration Service）とその移行プロセスについて紹介いたします。加えて、開発者側からは見えないAWS内部で自動化されている処理についても解説いたします。
    ブログ執筆に際して、AWSが公開しているハンズオン資料*2に基づいて、実際にサーバ移行を行いました。
    AWSのマイグレージョンについて学びたい方、MGNでの移行に詰まった方の手助けとなれば幸いです！！

    3. AWSにおけるマイグレージョンとAWS MGNの概要

    AWSにおいてマイグレーションとは、オンプレミスサーバ（他クラウドサービスの仮想サーバでも可）のネットワーク環境やサーバの設定をAWS上に移行してくることを指します。その移行パスは７つ存在します*3。そのうち、リホストと呼ばれる方式では、既存のオンプレもしくは仮想サーバの設定をほとんど変えずに、AWSへの移行を行います。
    AWS MGNは、まさにそのリホストマイグレーションを実現するためのサービスです。MGNの特徴には、

    • 移行工程が高度に自動化されているので、作業がとにかく楽になる
    • 移行の際に発生するダウンタイムが最小限で済む
    • 移行はEC2（Amazon Elastic Compute Cloud）へ行われ、オンプレミスサーバの構成をそのまま継承する

    などが挙げられます。また、MGNでのリホストマイグレージョンは、「自動化されたメリットを活かして手早く移行を行いたい」、「アプリケーションの改修やバージョンの更新を行わず移行したい」といった動機で使用が検討されます。
    SMS(Server Migration Service)との違いについては、先輩社員小西さんのブログ*4に記載されていますので、ぜひご一読ください。

    4. AWS MGNを利用した移行手順

    それでは本題の移行手順です。本ブログでは、移行プロセスを以下の５つのステップに分けて解説します。

    1. MGNのセットアップ
    2. 移行元サーバへの AWS Replication Agent（以降エージェントと記載）のインストール
    3. 移行元サーバデータの継続的なレプリケーション
    4. テスト移行
    5. カットオーバー

    「エージェント？レプリケーション？これ何？」って言いたくなりますよね。これらは後ほど解説します。
    また、移行手順の全体像を以下の図に示しました。大まかな順序は、凡例に示した通りです。

    4-1. MGNのセットアップ

    まずは、移行に必要な構築や通信の制御を担ってくれるMGNの設定を行います。MGNでもやはり事前準備が必要で、すぐに自動で動いてくれるという訳ではありません。その準備は、大きく分けて以下の二つです。

    1. レプリケーションテンプレートの作成
    レプリケーションとは、レプリケーションサーバを移行先に作成し、そこに移行元サーバの全データをコピーすることを指します。このテンプレートは、レプリケーションの際にどのようにデータを移してきて、保存するかを設定します。この設定には、レプリケーションサーバを構築するサブネット、レプリケーションサーバのインスタンスタイプなどがあります。

    2. 移行元サーバからMGNへ接続するためのIAMユーザーとそのアクセスキーの作成
    IAMユーザーには、既存の許可ポリシーを必要に応じてアタッチします。ハンズオンでは「AWS Application Migration Agent Policy」をアタッチしました。アクセスキーの作成は、作成したユーザーの[セキュリティ認証情報]タブから行います。アクセスキーIDとシークレットアクセスキーは、後の手順で必要になります。

    アクセスキーは漏洩の可能性があるため、使用を避け、IAMロール等を使用することを推奨します。一方、サーバ移行では、オンプレミスサーバといったAWS以外の移行元環境からのアクセスもあります。そのため、例外的にアクセスキーが必要となります。

    4-2. 移行元サーバへのエージェントインストール

    続いて、エージェントのインストールに移ります。エージェントのインストーラーをS3からダウンロード後、インストールコマンドを実行します。コマンドを実行する際、4-1.で作成したアクセスキーIDとシークレットアクセスキーが必要になります。
    インストール後、移行元サーバとMGNで制御通信が自動的に開始されます。

    4-3. 移行元サーバのデータの継続的なレプリケーション

    ここからは自動で開始されるプロセスについて紹介します。MGNとの制御通信が可能になると、レプリケーション通信も自動で開始されます。レプリケーションでは、 OS、アプリケーション、データ等の移行元サーバ全体のデータが、移行先に自動作成されたレプリケーションサーバに同期されます。
    移行したデータは、レプリケーションサーバにマウントされているEBSボリュームに書き込まれます。また、そのEBSスナップショットを取って、データが保管されます。さらに、移行元のデータが更新された際も心配はいりません。移行元のデータも、継続して反映してくれます。
    これらのレプリケーションサーバやEBSスナップショットなどは、MGNの機能と準備したレプリケーションテンプレートによって、すべて自動で作成してくれます。
    また、レプリケーションサーバは、移行元サーバよりも少ない台数で通信の仲介を行います。移行元サーバの規模によって、レプリケーションサーバが１つ以上のEC2インスタンスで構成される場合がありますが、EC2の利用料金を削減できます。なんと便利…

    4-4. テスト移行の実行

    移行先環境において、カットオーバーと同じプロセスで作業を行い、スナップショットのデータを基にテスト用のインスタンスをデプロイする、つまりインスタンスが正常に起動するかを確認するテストのことです。
    このデプロイの際、MGNにより自動で用意されたコンバーターインスタンスが、デプロイに必要な変換処理を行います。この処理が必要な理由は、レプリケーションされたデータのみのスナップショットに、EC2インスタンスとして起動するためのツールやドライバーが含まれていないためです。

    4-5. カットオーバーの実行

    テスト後はカットオーバーを実行します。ここでは、カットオーバーは本番移行のことを指します。テスト移行と同様に、コンバーターインスタンスがデータの変換処理を行います。

    カットオーバー実行後は、コンソールで [Finalize cutover] を選択します。これによりサーバ移行が完了し、レプリケーション通信が切断されます。また、レプリケーションに使用されていた各リソースが削除、停止します。

    移行プロセスの各状態は、MGNのコンソール画面で Source servers に遷移し、ライフサイクルで確認できます。ライフサイクルの各状態の詳細についても、小西さんのブログ AWS Application Migration Service(AWS MGN)のアーキテクチャとライフサイクルの関係、使い方の注意点まとめ − AWS Server Migration Service(AWS SMS)との違いも含めて - NRIネットコムBlog をご覧ください。
    以上で、AWS MGNを利用した移行手順は終了です。

    5. まとめ

    AWS MGNは、レプリケーションやコンバーターインスタンスによるデータの変換処理などを意識せずに、作業を行える大変便利な“サーバリホストマイグレージョン”ツールです。
    今回の学習で「MGNでサーバ移行ができるようになったぞ！」と言いたいところですが、私が実際に案件を行うにはまだまだ知識が必要です。実案件で考慮すべき事例としては、

    • オンプレミス環境がMGNでの移行やEC2への移行が可能なものであるかを精査する
    • 先行して移行されたシステムがあった場合、移行済みのサーバに影響を与えないようにターゲットVPCをテスト用と本番用で分ける
    • 大規模なシステムの移行であった場合、リソースサーバのグルーピングを行う

    などがあります。他にも多くの事例があるため、MGNについてさらに学んでいきたいと思います。
    最後まで読んでいただき、ありがとうございました！

    *1:移行コンピテンシーの認定取得に関する記事はこちら（ https://www.nri-net.com/news/2023/vmm35oo6rtdu/ ）

    *2: Application Migration Service(MGN) ハンズオン（ https://dcj71ciaiav4i.cloudfront.net/75BEDEA0-D70A-11EB-91FC-CFB7976F85AB/ ）

    *3:マイグレーションを実現するために - 第 2 回 : 移行戦略と移行パスとは ?（https://aws.amazon.com/jp/builders-flash/202011/migration-to-cloud-2/?awsf.filter-name=*all）

    *4: AWS Application Migration Service(AWS MGN)のアーキテクチャとライフサイクルの関係、使い方の注意点まとめ − AWS Server Migration Service(AWS SMS)との違いも含めて - NRIネットコムBlog（ https://tech.nri-net.com/entry/aws_mgn_architecture_lifecycle_usage_notes ）

    執筆者：福川正真 駆け出しインフラエンジニア