AWS Database Migration Service：データ移行先にAmazon Redshiftが追加(されたので早速試してみた)

しんや

2016.05.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

5/4付けのリリースにて、AWS Database Migration Service(DMS)が移行先対象となるデータベースに『Amazon Redshift』も対象とする旨が発表されました。

AWS Database Migration Service Now Supports Migrations to Amazon Redshift

AWS DMSはこれまで移行先対象のDBとしてはRDSのみがその対象となっていましたが、この度Amazon Redshiftも移行先対象のDBとして選べる様になりました！これにより、Amazon Aurora,PostgreSQL,MySQL,MySQL,MariaDB,Oracle,SQL ServerといったデータベースからAmazon Redshiftへのデータ移行がより簡潔かつスムーズに行えるようになります。

当エントリでは、早速(と言いつつも既に5日も過ぎてますが)移行シナリオの1つであるOracle→Redshiftのデータ移行についてその手順を実践してみたいと思います。

移行元DB環境(RDS Oracle)の用意

RDS Oracleインスタンスの起動

今回は移行元にOracleを指定したという想定ですので、環境を用意したいと思います。管理コンソールのRDSメニューから『Oracle SE One』を選択。

検証用なので今回はDev/Testで作成する事にします。

環境も必要なものを設定して、

外部アクセス可能なRDS Oracleインスタンスを作成します。

15分程してインスタンスが立ち上がりました。

Oracle SQL Developerのインストール&データ投入

作成したDBにデータを投入し、確認する環境を整えたいと思います。今回はツール『Oracle SQL Developers』を使ってその辺りの作業を進めて見たいと思います。Oracle公式サイトから対応するOS版のインストーラを入手し、

Oracle SQL Developer Downloads

インストール実施。

新規接続の作成で必要な情報を設定し、接続。

aws-dms-to-redshift_01

下記エントリで利用した映画データを今回も活用してみる事にします。必要なデータをダウンロードし、投入用のテーブルを用意。

Amazon Redshift: unixtime形式のタイムスタンプをTIMESTAMP型に変換する方法x2 ｜ Developers.IO
- MovieLens | GroupLens

この中からファイル『movies』に対応するテーブルを以下SQL文で作成します。

CREATE TABLE mlmovies (
  movie_id INT NOT NULL,
  title VARCHAR(200) NOT NULL,
  genres VARCHAR(200) NOT NULL
);

作成後はテーブルに対してデータをインポートします。このツールの場合、テーブルを右クリックすると『データのインポート』が実行出来るのでこの機能を使う事にします。

aws-dms-to-redshift_03

対象のファイルを選択し、

必要な事項をそれぞれ確認して、

[終了]押下。すると、

aws-dms-to-redshift_04

データのインポートが始まります。

データインポート完了。

今回の場合、27000件をおよそ3分程度で投入出来ました。

aws-dms-to-redshift_05

上記のテーブルとは別に、日本語情報を含むテーブルも今回簡潔なものではありますが併せて作成しておきます。

CREATE TABLE cm_test (
  cm_id INT NOT NULL,
  cm_jpn_name VARCHAR(100) NOT NULL,
  cm_char CHAR(30) NOT NULL,
  cm_date DATE NOT NULL,
  cm_timestamp TIMESTAMP NOT NULL,
  cm_int INT NOT NULL,
  cm_bigint NUMBER(19,0) NOT NULL,
  cm_float FLOAT NOT NULL
);

INSERT INTO cm_test VALUES(1,'あああああ', 'AAAA', '2016/05/06', '2016/05/06 12:34:56', 100, 11111111111, 1.23);
INSERT INTO cm_test VALUES(2,'いいいいい', 'BBBB', '2016/05/06', '2016/05/06 12:34:56', 200, 22222222222, 1.23);
INSERT INTO cm_test VALUES(3,'ううううう', 'CCCC', '2016/05/06', '2016/05/06 12:34:56', 300, 33333333333, 1.23);
INSERT INTO cm_test VALUES(4,'えええええ', 'DDDD', '2016/05/06', '2016/05/06 12:34:56', 400, 44444444444, 1.23);
INSERT INTO cm_test VALUES(5,'おおおおお', 'EEEE', '2016/05/06', '2016/05/06 12:34:56', 500, 55555555555, 1.23);
INSERT INTO cm_test VALUES(6,'かかかかか', 'FFFF', '2016/05/06', '2016/05/06 12:34:56', 600, 66666666666, 1.23);
INSERT INTO cm_test VALUES(7,'ききききき', 'GGGG', '2016/05/06', '2016/05/06 12:34:56', 700, 77777777777, 1.23);
INSERT INTO cm_test VALUES(8,'くくくくく', 'HHHH', '2016/05/06', '2016/05/06 12:34:56', 800, 88888888888, 1.23);
INSERT INTO cm_test VALUES(9,'けけけけけ', 'IIII', '2016/05/06', '2016/05/06 12:34:56', 900, 99999999999, 1.23);
INSERT INTO cm_test VALUES(10,'こここここ', 'JJJJ', '2016/05/06', '2016/05/06 12:34:56', 1000, 123456789012, 1.23);

dms-oracle-to-redshift_012

移行先DWH環境(Amazon Redshift)の用意

環境確認

移行対象(target)となるRedshiftクラスタも併せて準備しておきます。こちらも移行元同様、外部からアクセス可能な形とします。

aws-dms-to-redshift_08

AWS Database Migration Service環境構築

いよいよ本丸の設定作業です。ここまで準備が色々と掛かりました...

レプリケーションインスタンスの作成

AWS管理コンソール、メニューからDMSを選び『Getting Started』を選択。[Next]を押下し、移行に必要な諸々のインスタンス等を作成します。

dms-oracle-to-redshift_001

レプリケーションインスタンスの作成。今回の移行対象データは小さいのでここで作成するインスタンスも控えめなものをチョイス。

dms-oracle-to-redshift_002

DBストレージサイズもデフォルト50GBのようですが今回は少なめ設定。[Next]押下。

dms-oracle-to-redshift_003

移行設定

裏でレプリケーションインスタンスの作成が始まりつつ、移行元と移行先のデータベース情報の設定を行います。左側は移行元となるデータベースの情報をそれぞれ設定します。

dms-oracle-to-redshift_004

次いで右側。以前は無かった選択肢『Redshift』がちゃんとありますね。

dms-oracle-to-redshift_005

右側の移行元DB同様、必要な情報をそれぞれ設定して行きます。レプリケーションインスタンスの作成が完了した時点で接続テストが実行出来るようになるので、暫し待機後、チェックしておきます。共に接続確認が取れたら[Next]押下。

dms-oracle-to-redshift_006

タスクの作成。今回は単純なデータ移行なのでデフォルト指定の『Migrating existing data』を選択。

dms-oracle-to-redshift_007

タスク設定のログ出力は行う設定にしてみます。(ログ出力を行わない場合、後述する実行タスクの『Table statistics』にテーブル単位での記録が表示されるようです。見栄え的にはログ出力無しの方が分かり易い様な気もしますので、この辺は状況に応じてお好みで。)

dms-oracle-to-redshift_008

テーブルマッピングの設定。こちらはデフォルト指定でスキーマ名が『ROOT』となっていますが、ユーザー名をrootとしていたのでそこに引き摺られてしまった(接続ユーザー名のスキーマを作成し、その配下にテーブルを移行する？)形なのでしょうか。ここでは設定値そのままで進めますが、移行先スキーマ名をカスタマイズする事も可能となっています。

dms-oracle-to-redshift_009

移行作業実施

タスク作成及び実行完了。

dms-oracle-to-redshift_010

[Logs]タブからCloudWatchログの内容を確認しています。確かに対象2テーブルへの処理を行っていた事が確認出来ました。

dms-oracle-to-redshift_011

実際のデータベースの中身を確認してみます。rootスキーマに対してテーブルが2つ、作成されています。

# SELECT * FROM pg_tables WHERE schemaname = 'root';
 schemaname | tablename | tableowner | tablespace | hasindexes | hasrules | hastriggers 
------------+-----------+------------+------------+------------+----------+-------------
 root       | cm_test   | root       |            | f          | f        | f
 root       | mlmovies  | root       |            | f          | f        | f
(2 rows)

データの中身についても問題無さそうです！

# SELECT COUNT(*) FROM root.mlmovies;
 count 
-------
 27278
(1 row)

# SELECT * FROM root.cm_test ORDER BY cm_id;
 cm_id | cm_jpn_name | cm_char |       cm_date       |    cm_timestamp     | cm_int |  cm_bigint   | cm_float 
-------+-------------+---------+---------------------+---------------------+--------+--------------+----------
     1 | あああああ  | AAAA    | 2016-05-06 00:00:00 | 2016-05-06 12:34:56 |    100 |  11111111111 |      1.23
     2 | いいいいい  | BBBB    | 2016-05-06 00:00:00 | 2016-05-06 12:34:56 |    200 |  22222222222 |      1.23
     3 | ううううう  | CCCC    | 2016-05-06 00:00:00 | 2016-05-06 12:34:56 |    300 |  33333333333 |      1.23
     4 | えええええ  | DDDD    | 2016-05-06 00:00:00 | 2016-05-06 12:34:56 |    400 |  44444444444 |      1.23
     5 | おおおおお  | EEEE    | 2016-05-06 00:00:00 | 2016-05-06 12:34:56 |    500 |  55555555555 |      1.23
     6 | かかかかか  | FFFF    | 2016-05-06 00:00:00 | 2016-05-06 12:34:56 |    600 |  66666666666 |      1.23
     7 | ききききき  | GGGG    | 2016-05-06 00:00:00 | 2016-05-06 12:34:56 |    700 |  77777777777 |      1.23
     8 | くくくくく  | HHHH    | 2016-05-06 00:00:00 | 2016-05-06 12:34:56 |    800 |  88888888888 |      1.23
     9 | けけけけけ  | IIII    | 2016-05-06 00:00:00 | 2016-05-06 12:34:56 |    900 |  99999999999 |      1.23
    10 | こここここ  | JJJJ    | 2016-05-06 00:00:00 | 2016-05-06 12:34:56 |   1000 | 123456789012 |      1.23
(10 rows)

まとめ

DMS(Database Migration Service)がRedshiftへデータ移行出来るようになったという事で、『どれ、DMSを使ってみようか...』と検討される方々は多いのではないでしょうか。今回はデータも非常に少なかったので処理時間もほんの数分と行ったところでしたが、実案件でのデータ移行となると件数もボリュームも桁違いのものとなるのでそうなった時にどの位の(レプリケーションインスタンスの)スペックやストレージサイズを擁するのか、といった部分についてはまだまだ未見の部分となるので深掘りを行っていく必要がありそうです。公式ドキュメントは以下のURLとなります。DBの種別、移行ケース等様々想定しうるものは出てくると思いますので、引き続きDMSについてはウォッチして行きたいと思います。こちらからは以上です。