マイグレーションを実現するために - 第 3 回 : 具体的な移行方法とは ?

前回の移行パスでお話した、リプラットフォームやリアーキテクチャの場合は、クラウド上でシステムを作り、既存システム上のデータを移行することになります。その際にツールを利用するケースが多いと思いますが、既存システムの構成のままクラウドに移行するリホストの場合でも、ツールを利用して移行することで一から OS やミドルウェアを構築するよりも早く環境を構築することができます。

AWS ではお客様のクラウド移行に役立つ移行ツールを提供していますが、その中でも今回は、VMの移行を対象とする AWS Server Migration Service (以下 SMS)、VM に加え物理サーバーの移行も対象とした CloudEndure Migration (以下 CloudEndure) や、データベースのデータやスキーマの移行を対象とした AWS Data Migration Service (以下 DMS) について概要をご説明させていただきます。

さて、VM や物理サーバーの移行について、AWS では CloudEndure と SMS の 2 つを用意しています。サーバー移行という同じ目的のツールですが、いろいろ異なる点がありますので以下の表でまとめます。

SMS が Amazon Machine Image (AMI) を作成することでサーバーの移行を実現することに対し、CloudEndure は継続的に移行元の更新をストレージのブロック単位でレプリーケーションを行うことで AWS 上に環境を移行します。よって、更新があまりに多い場合はレプリーケーションが更新に追いつかないことも考えられます。SMS でも同様で、移行時にはある断面での AMI を作成することになるので、移行対象のサーバーがどのくらい記憶領域に対して更新をかけているのかを事前に見積もっておくことはとても重要です。

注意点として、CloudEndure は移行元や移行先の情報の紐付けやレプリーケーションの状態を管理するサーバーがインターネット上にあります。そのため、セキュリティルール等でインターネット上にあらゆるトラフィックを流すことが出来ない場合は、現状 CloudEndure は利用できない事になります。ただし、エージェントをインストールしレプリケーションが始まってしまえばバックグラウンドで AWS 上に環境をコピーし、移行時も移行元に静止点を設けレプリケーションの完了を待てば移行完了後のテストが出来ることなど、移行工数を削減できることから、インターネットへの通信がクリアできれば CloudEndure をおすすめしたいところです。

なお、CloudEndure はブロック単位でレプリケーションを行い、更新量を見積もることが重要とご説明をさせていただきました。言い換えれば、データ更新が少なければデータベースサーバーの移行にも利用できることになります。基本、データベースの移行は後述の DMS を推奨いたしますが、CloudEndure でもデータベースサーバーの移行ができる条件は下記のとおりです。

OS やミドルウェア、データベースをバージョンアップする必要がなく、1 台の中に Web / AP / DB がオールインワンで構築されており、メンテナンスで停止することが調整できるような、きっちり静止点を設けることが出来るサーバーが該当するかと思います。OLTP で高負荷なアクセスが発生している場合や、大量のバッチで更新中のものは、CloudEndure での移行を避けるか、更新の終了を待ち静止点を設けてレプリーケーションの時間が確保できることが前提となります。これらがクリアできれば事前テストの実施を前提として、データベースサーバーの移行にもご利用いただけます。

次にデータベースの移行です。データベースの移行には、ツールのセットアップが大変だったり、スキーマやプロシージャの変換の手間やレプリケーションによるダウンタイムが発生しているかと思います。

AWS では、DMS というデータベース移行ツールを提供しており、その特徴として下記が上げられます。

マネージド型のデータベース移行サービスのため、インスタンスやストレージ、データ転送量など使った分だけ課金される仕組みとなっており使いいやすいシンプルな価格体系です。

この DMS はオンプレミスから AWS への移行に利用できるだけではなく、AWS 上の VPC の異なるデータベース間のレプリケーションにも利用できます。言い換えれば、VPC をまたがり継続的にレプリケーションができるため、クラウド移行時のみならず、データ連携基盤の一部として使用したり、リージョンをまたぐデータ連携や、DWH などへの継続的なデータ反映にも使うことが出来ます。

一方で、DMS が移行対象としているのは、

• 表定義
• プライマリーキー
• データ

なので、ビュー、プロシージャや制約等は移行できません。

そこで、AWS では、AWS Schema Conversion Tool (SCT) というソースデータベースのスキーマなどを自動的にターゲットデータベース互換フォーマットに変換するデスクトップツールを用意しています。特徴は下記のとおりです。

利用料も無料となっています。

DMS と SCT と組み合わせることで、データベースの移行について、何がツールで移行でき、何がツールで移行できないかを事前に把握しておくことで、移行に関するリソース計画やスケジュールの作成に生きた情報を含めることが出来ます。

一方で、データベース移行について、AWS では、DMS と SCT というツールを用意しています。しかしながら必ずしもこれら 2 つのツールを使う必要はなく、データベースメーカーが提供する純正の移行ツールや、ダンプなど様々な方式選択することが可能です。下記の通り条件によって取りうる方式をご参考ながらまとめました。

データベース移行はどのようなクラウド移行のケースでも深い検討が必要なポイントです。システムやデータベースの特徴を把握した上で正しく取りうる選択肢を選択することが重要です。

なお、どのツールにも共通する注意点としては、オンプレミスからクラウドに移行する際には、オンプレミス〜 AWS 間の WAN だけではなく、LAN についても検討が必要なことです。移行に利用できる時間や帯域、それらから導かれる移行可能なデータ量、等制約が発生します。ツールを使ってクラウド移行をする際に見落とされがちなポイントですが、WAN や LAN についても考慮が必要です。クラウド移行の際にはネットワークご担当者様への相談もお忘れなく。

なお、上述のサービス詳細はドキュメントや AWS Black Belt Seminar の資料をご参照ください。特に、Black Belt は重要なエッセンスが凝縮されているのでとても参考になります。

前々回にお話しさせていただいた、「なぜマイグレーションが必要なのか」、前回のトピックの「移行戦略と移行パス」は、どちらかというと机上やディイスカッションで今後のことを考えていく重要なタスクでした。

今回の移行方法については、机上での検討はもちろんのこと、実際に手を動かして見ると顕著に効果がわかるものになります。クラウドは環境を簡単に作ることも出来ますし、簡単に破棄することも出来ます。迷ったらまずは開発環境やテスト環境で試して見る、というスタンスで移行方法も検討してみることをおすすめします。

3 回にわたり、クラウドのマイグレーションに関する重要なトピックをお話させていただきました。既存システムをマイグレーションするにあたって考慮するポイントは多岐にわたります。その中でも検討の初期段階で行う必要のある重要な事項を中心にトピックとさせていただきました。これらの記事が皆様のお役にたてば幸いです。