まる見え!パブリッククラウド移行(3):知らないと損?AWS移行を助けてくれる便利ツール【前編】

2024.11.25
マルチクラウド 基礎 AWS クラウド活用
まる見え!パブリッククラウド移行(3):知らないと損?AWS移行を助けてくれる便利ツール【前編】

はじめに

皆さん、こんにちは。五味 なぎさです。パブクラ移行をテーマにしている本シリーズ、前回はAWS移行のステップの全体像と、各ステップで役立つサービスをまとめてご紹介しました。まだ前回のブログを読まれていない方はぜひ、こちらをご覧ください。

さて前回のブログでは、AWS移行における“Migrate&Modernize(移行&モダナイズ)”ステップで役立つサービス全5種類について触れていますが、今回はその中から下記(1)と(2)について、利用シーンやコストなどを解説していきたいと思います。

“Migrate&Modernize(移行&モダナイズ)”ステップで役立つサービス一覧

「サービス名は知っているけど実際に使用したことは無い」という方もいらっしゃると思うので、ぜひ利用イメージを具体化するご参考になればと思います。

AWS Application Migration Service(MGN*)

  • *AWS Application Migration Serviceの省略されたサービス名はAWS MGNです。「MGN」は「migration」(移行)という単語の略称です。

利用シーン

オンプレミスや他クラウドにある物理サーバ、仮想マシンをできるだけそのままAWS環境に移行したいケースに向いています。AWS内で他環境に移行するケース(AWSアカウントやVPCの統廃合など)にも適します。

利用の流れ

  • 事前に以下のネットワーク要件を確認し、必要な環境を構築します。 インターネット経由の構成が一般的ですが、以下の参考リンクにあるようにVPNやDirectConnectを用いた閉域経由の移行も可能です。
  • 利用するリージョンでMGNを初期化します。初期化により、必要なIAMロール(MGNが動作するために必要な操作権限のセット)とデフォルトのテンプレートが作成されます。
    テンプレートは以下3種類です(編集可能)。

    レプリケーションテンプレート

    移行制御のために一時的に作成されるレプリケーションサーバの設定を定義する。

    起動テンプレート

    移行後に起動するEC2のデフォルト設定(インスタンスタイプやEBS(EC2で利用するブロックストレージ)ボリュームタイプ、起動するサブネットなど)を定義する。

    起動後テンプレート

    主に移行後のサーバにSystems Managerエージェントを導入するかどうかを定義する。
  • 移行元となるソースサーバにMGNのエージェントをインストールします。
    移行元がVMware仮想環境の場合、バージョンによってはエージェントレス版が利用できますが、エージェントを導入できない特別な理由がない場合、エージェントベースのレプリケーションが推奨されています。
  • ソースサーバへのエージェントインストールが完了するとレプリケーションテンプレートの設定内容に基づきレプリケーションサーバが作成され、AWS側への移行が進行します(=EBSのスナップショットがAWS側に作成される)。
  • 4の移行完了後、起動テンプレートの内容に従い、テストインスタンスを起動します。また、起動後テンプレートでSystems Managerエージェントの導入設定を有効化している場合、Systems Managerが導入されます。
    テストインスタンスの起動後、動作検証を実施します。
  • 5で動作に問題がなければ、いよいよカットオーバーです。カットオーバーインスタンス(確定後AWS上で実際に運用するインスタンス)を起動し、カットオーバーを確定させます。
    また、確定により「カットオーバー完了」となるタイミングでレプリケーションサーバも停止されます(=データレプリケーション処理も停止する)。

環境構成

「利用の流れ」の1~6と環境のマッピングは以下の通りです。

参考:AWS_MGN_Network_Architecture.pdf

コスト

移行対象のソースサーバ1台につき2,160時間(連続して利用した場合は90日間)まで無料で利用できるため、無料の範囲内で対応が完了するケースが多いです。無料範囲を超えた場合、1時間当たり0.042USD/サーバの課金が発生します。

利用時の注意事項

  • 移行対象としてサポートされているOSは以下に記載の通りです。バージョンの適合以外にも空きストレージ容量や機能の有効化/無効化など利用条件が書かれているため、事前に必ず確認しましょう。
  • レプリケーションするネットワーク経路の帯域や、レプリケーション実施中のソースサーバのリソース状況は必要に応じて監視しておきましょう。

AWS Database Migration Service(DMS)

利用シーン

DBデータ連携を支援するツールで、オンプレミスからのデータ移行にも利用可能です。異種データベース間での移行にも対応しています。
仕組みとしては論理レプリケーションとなり、ソースデータベースで作成されたトランザクションログファイルからDMLを作成し、ターゲットとなるデータベースに適用する形になります。

利用の流れ

DMSは移行だけでなくデータ連携全般に利用されるツールですが、今回はオンプレミスからのデータ移行を想定した場合の利用の流れをご説明します。

  • 移行先となるデータベースを構築します。
  • 通信要件を反映させたネットワーク設定を行います。また、オンプレミス側も必要な通信許可設定を行います。DMSもインターネット経由の接続だけでなく、以下のようにVPNやDirectConnectを利用した閉域接続の利用が可能です。
  • レプリケーションインスタンスを構築します。インターネット経由で移行する場合はパブリックアクセスを有効化します(閉域接続の場合は不要)。
  • ソースエンドポイントとターゲットエンドポイントを作成します。
    それぞれレプリケーションインスタンスからソースデータベース、ターゲットデータベースに接続するためのエンドポイントです。
    接続情報(IPアドレス)や認証情報を設定します。認証情報をAWS Secrets Managerに保存して利用することも可能です。
  • 移行タスクを作成します。
    利用するレプリケーションインスタンスやソースエンドポイント、ターゲットエンドポイントを指定します。また、テーブルマッピングの設定や移行前のタスク評価、データ検証、フィルター設定などもタスクの中で定義できます。
  • 移行タスクを開始し、データを移行します。移行前のタスク評価を有効にしている場合は、移行開始前に潜在的な移行の問題について警告を作成します。
  • 移行完了後、データ検証を有効にしている場合は、ターゲット上のデータとソース上のデータの比較が行われます。

環境構成

「利用の流れ」の1~7と環境のマッピングは以下の通りです。

コスト

Replication InstanceとしてSingle-AZ dms.t2.microインスタンス(50GB)を利用する場合は750時間まで無料で利用できます。
それ以外のケースではReplication Instanceのタイプと稼働時間により料金が決まります。また、ターゲットがReplication Instanceとは別のAZやリージョン、AWS以外のデータベースとなるケースでは別途データ転送料金がかかります。

参考:料金 - AWS Database Migration Service |AWS

利用時の注意事項

おわりに

いかがでしたでしょうか?今回は「Migrate&Modernize(移行&モダナイズ)ステップ」で活用できるツールのうち、AWS Application Migration Service(MGN)およびAWS Database Migration Service(DMS)について解説してきました。次回は、後編としてAWS Storage Gateway、AWS DataSync、AWS Snow Familyについて解説予定です。

いずれも、ツールの使い方自体は直感的で分かりやすく、実際やってみると必要な環境構成自体もそこまで複雑なものではありませんでした。ただ、実際本番稼働中の環境で利用する際には上述の注意事項を中心に考慮するポイントが多々ありますので、事前に検証を十分に行った上で利用されることをお勧めします。

なお、当社ではAWS包括的技術支援サービスを提供しています。AWSへの移行でお悩み等ございましたら、ぜひ本サービスもご活用ください。その他、AWSをはじめマルチクラウド化に関するご相談全般はこちらからお気軽にお声がけください!それでは、また次回もお楽しみにお待ちください!

関連ページ

おすすめブログ

まる見え!パブリッククラウド移行(2):AWS移行ステップと役立つサービス
まる見え!パブリッククラウド移行(2):AWS移行ステップと役立つサービス
AWS移行に関して、AWSから様々な役立つ移行サービス・ツールが提供されていることをご存じでしょうか?本ブログでは、AWSへの移行ステップをまとめた上で、各移行ステップで活躍する8つの代表的なサービス・ツールを一挙に紹介します。AWS移行の基礎をおさらいしていきましょう!
まる見え!クラウドネイティブ(2):クラウドネイティブ実現の難しさ
まる見え!クラウドネイティブ(2):クラウドネイティブ実現の難しさ
近年日本においても注目度があがっているクラウドネイティブですが、実現はまだ道半ばという情報システム部門の方々も多くいらっしゃるのではないでしょうか?今回はクラウドネイティブの実現が難しい理由を考えながら、実現のヒントとなる視点を一緒に学んでいきましょう!