AWS DMS を使ってみた(1) ～手軽にMy SQLからRDS(Postgre SQL)にDB移行する～｜AWSを使い倒せ

AWS DMS を使えばテーブル作成なしで異なるDB種類へのクラウド移行が行える

近年、AWS(Amazon Web Services)やMicrosoft Azureなどのクラウドサービスが進歩してきたことで、新規システムの導入先としてクラウドが選ばれることが多くなってきました。また、既存システムでも、運用コスト削減やハードウェア障害のリスク回避の手段としてクラウドへの移行を行う事が多くなってきました。しかし、既存システムのクラウドへの切り替え作業には非常に多くのハードルがあり、特に常にデータが蓄積されているDB(データベース)のクラウド移行には、多くのテーブルデータをミスなく短期間に移動する必要があり、非常にリスクが高い作業になっていました。

これらのDB移行の問題を解決するためのサービスが、AWS DMS(Database Migration Service)です。今回は、今月(3月)、正式リリースされたばかりのAWS DMSについて、簡単なDB移行タスクの作成を通してご説明したいと思います。

異なるDB種類への移行リスク

AWS DMSの内容に入る前に、異なるDB種類への移行リスクについて、簡単に説明したいと思います。

ご存知の通りDBは、大量データが蓄積され、それらは複数のテーブル等によって分散して登録されているため、これらの大量データの移動に時間が掛かります。また、移行先のDBには、あらかじめデータ受口としてのテーブルを用意する必要があり、これらの移行元と移行先のDB種類が異なる場合には、移行先用にテーブル作成命文を再作成する必要があります。

そして、一番、問題になるのがDB切替のタイミングです。ほぼ、24時間稼働しているシステムの場合、常にDBにデータが書き込まれているため、一度、システムを止める必要があります。当然、システムを止めている時間は短ければ短いほど業務への影響は少ないです。そのため、DB切替作業の事前に過去のデータを移行して、DB切替時のデータ移行を最小限にしたり、これらの作業をスムーズに行えるように何度も移行シミュレーションを行ったりします。

そして、これらのDB移行には、専門のエンジニアとシステム開発が必要になり、DB移行プロジェクトだけでも非常に多くのコストが掛かっていました。

AWS DMSのココが凄い

上記の通り、DB移行には非常に多くのハードルがあり、手軽にできる作業ではありませんでした。これらの問題を解決したのがAWS DMSです。

AWS DMSは、AWSコンソール画面からプログラム、SQL文を全く書かずにDB移行を行うことができます。DBがAWSクラウドの外でも、移行元と移行先のDB種類が異なっていても関係ありません。AWS DMSが対応しているDB(Postgre SQL、My SQL、Oracle、SQL Server、Aurora、Maria DB)であれば、移行元のDB内のテーブル情報を取得し、移行先のDBに最適なテーブルを自動的に作成し、データを移行します。そして、AWS DMSが、1時間当たり$0.028(t2.microで移行先のDBが同じアベイラビリティーゾーン内の場合)という低価格で利用できます。

そして、最大の特徴は、AWS DMSの稼働中はDBのデータ同期を行ってくれる事です。これは、非常に凄い機能です。なぜなら、移行元、移行先のDBの同期が取れていることで、僅かな時間にシステムを停止して、DBの接続先を移行先のDBに切替えるだけでDB移行作業が完了するのです。移行スケジュールをタイトに詰めて、胃に穴が開くような緊張感の中、DB移行作業を行う必要がなくなるのです。

AWS DMSを使ってみよう

システム構成

今回、検証でDB移行したシステム構成は以下です。AWS VPCの外の移行元DB(My SQL)からAWS VPC内の移行先DB(Postgre SQL)にデータをコピーします。

AWS DMSは、ウィザード方式で一気にDB移行のタスクを作成できますが、今回は、移行先DBがAWS VPCの外にあるため、一度、移行先DBの接続可能なIPアドレスにAWS DMSのインスタンスのIPアドレスを追加する必要があります。そのため、AWS DMSのインスタンス、エンドポイント、タスクを別々に設定していきます。

インスタンスの設定

AWS DMSのインスタンスの作成は、DMSのAWSコンソールの「Replication instances」の「Create replication instances」ボタンから行えます。

AWS DMSのインスタンスの設定は、インスタンの名前、説明、性能(instances class)、VPC、パブリックアクセス(Publicly accessible)を入力します。今回、インスタンスの性能は移行元DBのデータ量が40GBと比較的小規模ですので「dms.t2.small」にしました。また、AWS VPCの外のDBからアクセスするため、パブリックアクセスにチェックをしています。

AWS DMSのインスタンスが作成されると、グローバルIPアドレスが割り振られます。このIPアドレスから移行元DBに接続できるように移行元DBの設定を行います。

エンドポイントの設定

AWS DMSのエンドポイントの作成は、DMSのAWSコンソールの「Endpoints」の「Create endpoint」ボタンから行えます。

AWS DMSのエンドポイントの設定は、接続元DB(Endpoint type:Source)と接続先DB(Endpoint type:Target)の2つを別々に設定する必要があります。設定するDB接続情報は、一般的な情報のため迷うことは無いと思います。また、上記で登録したインスタンス情報を入力して、DBの接続確認が行えます。

タスクの設定

AWS DMSのタスクの作成は、DMSのAWSコンソールの「Tasks」の「Create task」ボタンから行えます。

AWS DMSのタスクの設定は、タスク名、上記で作成したインスタンス名、エンドポイント名、マイグレーションタイプ(Migration type)などを入力します。マイグレーションタイプとして「Migrate existing data and replicate ongoing changes」を選択することで、テーブル作成とデータ同期を自動的に行ってくれます。

マイグレーションタイプとして「Migrate existing data and replicate ongoing changes」や「Replicate data changes only」を選んだ場合、下記のようにメッセージが表示される場合があります。これは、データ同期を行うために移行元DBで必須の設定をアナウンスしており、下記の場合は「call mysql.rds_set_configuration(‘binlog retention hours’, 24);」コマンドを実行することで設定が完了します。

タスクの標準設定では、実行ログが出力されません。障害対応のヒント等になりますので、ログを出力することをお勧めします。ログを出力する場合は、「Task Settings」の「Enable logging」にチェックを入れてください。

標準設定では、移行元DBの1つのスキーマから全てのテーブルをデータ移行しますが、一部分のテーブルに限定したい場合は、Table mappingの「Mapping method」で「Custom」を選択することで、テーブル名をXML形式でフィルタリングすることができます。

最後に「Start task on create」にチェックを入れて「Create task」ボタンをクリックすると移行タスクが実行されます。

DB移行完了の確認

AWS DMSのタスクが実行されるとAWSコンソールから各テーブルの移行進捗を確認できるようになります。今回、使用したインスタンス性能の「dms.t2.small」では、並列処理で同時に6つのテーブルの移行処理を行っているようでした。

タスクの「Complete」列が100%になると移行完了です。今回、移行元DB(DB容量40GB／23テーブル／最大1.6億行)の移行処理に約2時間40分掛かりました。

AWS DMSの設定は非常に簡単

この様に非常に簡単なAWS DMSの設定だけで、複数のテーブルを漏れなく移行をすることができます。また、テーブル以外のビューなどのDB資産は「AWS Schema Conversion Tool」を使う事で、移行先DBに合わせてビュー作成命令(create view)を作ることが可能です。これらを使う事でDB移行に掛かる多くの作業を省くことが可能です。

そして、移行元と移行先のDBは、AWS DMSが実行している間は自動的にデータ同期を取ってくれます。このデータ同期機能の検証については、次回の記事でご紹介したいと思います。

【関連記事】

• AWS Database Migration Service によってDBの乗り換えが加速する｜ AWS re:Invent 2015 新サービス
• AWS DMS を使ってみた(1) ～手軽にMy SQLからRDS(Postgre SQL)にDB移行する～ (本稿)
• AWS DMS を使ってみた(2) ～データ同期を徹底検証～