« 【AWS DevOps Blog】AWS CloudFormationテンプレートを最適化する | メイン | 9月のAWS Black Belt オンラインセミナーのご案内 »

AWS Black Belt Online Seminar「AWS Database Migration Service」の資料およびQA公開

こんにちは、ソリューションアーキテクト小川です。

8/17 に開催したBlackBeltオンラインセミナー「AWS Database Migration Service」の資料が公開されております。当日ご参加頂いた皆様より頂戴したQ&Aの回答とあわせて掲載させて頂きます。

【Q&A】

Q1:旧サーバ(移行元)の負荷についてどこまで考慮が必要ですか?

A1:サーバの負荷は設定するタスクの量や転送するデータ量、並列度によって大きく異なりますので一概には言えませんが、初期ロード時には大きい負荷が掛かるため、本番業務で使っているRDBであればピークの時間を避ける等の工夫が必要です。CDCは負荷が低いのが特徴ですが、こちらもタスクを並列で動かした場合には注意が必要です。

Q2:国内でどのくらいの実績があるのでしょうか?

A2:まだ公開可能な事例はありませんが、日本のお客様でもCDCを利用してAmazon Aurora等AWS上のデータベースに移行される事例が複数あります。

Q3:初期データは手でロードして、あとからレプリケーションだけ使うことはできますか?

A3:可能です。その場合は初期データがソースとターゲット双方で同じであることを確認してからレプリケーション(CDC)を実行する必要があります。

Q4:レプリケーションのレイテンシについての知見は御座いますでしょうか?

A4:レイテンシを決める要素としては、ソースRDBの負荷、ターゲットRDBの負荷、DMSインスタンスの性能やネットワーク性能等がありますが、一番大きい要素はネットワーク自体の遅延です。

Q5:DMS で使うディスクの容量は、どの程度(例えば、読み込み元と同程度?)必要なんでしょうか。

A5:タスク設定によるため一概には言えませんが、一般的には余裕をもったディスクサイズの用意を推奨しています。読み込みと同じサイズまでは必要無いケースがほとんどですが、最低でもソース上に存在する一番大きい表と同じサイズは用意するようにしてください。

Q6:DX接続でも使用できますか?

A6:利用可能です。DMSインスタンスはVPC内に存在し、プライベートIPが付与されています。

Q7:特に継続的レプリケーション機能(CDC)利用時のレイテンシが気になっています。
Q8:同期はどの程度の速度が保証されていますでしょうか。MySQLのレプリケーションと同等、それ以上など。(ネットワーク遅延は考慮しないものとして) # DMSインスタンスタイプにどの程度左右されるのかも気になります。

(Q7/Q8に対するご回答)
継続的レプリケーション(CDC)での同期については、ネットワーク帯域だけでなく対象のRDBの性能や表の数、サイズ等の環境に大きく影響されますし、DMSとして保証した数値はありません。
必要なだけの速度や遅延で稼動するかどうかのPoC(事前検証)を行っていただいた上で本番稼動で御利用いただく事を推奨しております。

Q9:ソースDB側にレプリケーション設定は必要ないものでしょうか?

A9:ソース側には、トランザクションログ(REDOログやBINログ等)にアクセスできるような設定が必要になります。その他の制約を含めて以下のURLに記載されています。
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.html
同様にターゲット側の設定や制約については以下のURLに記載されています。
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Target.Oracle.html

Q10:MySQLをソースにした場合、row/mix/statementに関係なく利用可能でしょうか。その他、なにか制限事項などありますか?

A10:CDCを利用する場合は、BIN LogのフォーマットはROWである必要があります。
その他にも必須の設定項目があります。MySQLをソースにした場合の設定項目や制約については以下のURLに記載されています。
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.MySQL.html

Q11:CDC利用時には、内部的にはいわゆるログシッピングを実施している感じでしょうか?

A11:ログシッピングのようにターゲットで直接ログをアプライしているわけではありませんが、ログを読み取りそれを転送し、ターゲットに更新データを適用するという意味ではログシッピングに近い形で動いていると言えます。

Q12:CDC を Multi-AZ 構成で組んだ場合に、ユーザー側でフェールオーバーを発生させることってできますか?また障害時の挙動やダウンタイムについても教えて欲しいです。

A12:DMSインスタンスのマルチAZをユーザの操作でフェイルオーバーさせる事は、現時点ではできません。AZ全体の障害が発生した場合は、他AZ上のDMSインスタンスに引き継ぎ、引き継がれたインスタンスがプライマリに昇格します。昇格するまではタスクは一時停止状態になり、新しいプライマリが稼動開始した後にタスクが再開されます。

Q13:STCツールはoracle to oracle みたいな同じDB間の移行でも利用できるのでしょうか?

A13:利用は可能と考えられますが、SCTは異機種RDB間でのSQL変換を補助するツールですので、同一RDBで利用しても有意なアウトプットは得られないと考えられます。

Q14:オンプレで使っているOracle Enterpraiseのライセンスはそのまま使えますか?

A14:DMSはデータベース間でデータを移行するためのサービスであり、データベースそのものではありません。AWSには、EC2上にOracleを構築する場合や、RDSを使ってOracleを利用する場合でもライセンスも持ち込み(BYOL)には対応しております。詳細は以下のURLに記載されています。

https://aws.amazon.com/jp/oracle/

またOracle社から発行されている以下のレターもご確認ください。
http://www.oracle.com/jp/store/cloud-lic-170290-ja.pdf

Q15:移行期間中、オンプレとAWS両方稼働させている発生があります。この期間の考え方についても知りたいです

A15:DMSが稼働中に2台データベースを利用する際のRDBライセンスについてのご質問かと思いますが、そのライセンスがどれだけ必要かはRDBのライセンス形態によります。詳細は御利用されたいRDBのライセンスベンダーにご確認ください。なおAmazon RDSでは商用データベース(Oracle, SQL Server)を1時間単位で利用できるライセンスもご提供可能です。

Q16:AWS環境(RDS)からオンプレRDBMSへのマイグレーションは不可能でしょうか?

A16:可能です。DMSはソースもしくはターゲットのどちらかのRDBがAWS上にあれば利用可能です。

Q17:利用するポートは各RDBMSでDBを起動しているポートになりますか?それともバイナリログの転送なので別ポートでしょうか。

A17:DBがODBC等の接続を受け付けるポート番号です。

Q18:ソースDB側に与える影響(スキーマの作成等)は何があるでしょうか?

A18:ソースとして利用する際に設定の変更が必要な場合がありますが、ソースDBのデータやスキーマには影響を与えません。ソース側の設定は以下に記載があります。
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.html

Q19:DMSでCDCを使用する場合、EBSのサイズはどのように見積もったらよろしいでしょうか。指標はありますでしょうか。

A19:CDCだけの利用については具体的な指標はありませんが、CDCでの転送はトランザクションの変更サイズごとなので、必須サイズは小さいと考えられます。
ただし、EBSのサイズはDMS全体の費用の中で占める割合は小さいため、できるだけ余裕をもったディスクサイズで御利用いただく事を推奨しております。

Q20:例えば、Oracleは表定義に表領域などの設定がありますが、Mysqlへ移行する場合、これらはどのような扱いになるのでしょうか?

A20:表領域の指定は反映されないとお考えください。
表領域等のOracle独自の部分は、DDLをSCTで変換した時点で削除されます。DMSによって表定義が変換された場合も同様にMySQLに適用できない設定は削除された形で変換されます。
基本的な使い方としてはDMLの変換をSCTで行った場合でも、ターゲットDBに必要な設定の付与等最終的な調整は開発者の手で行うことが推奨されます。

Q21:mysql5.5 でbinログの保存期間を24Hに設定しないとCDCは利用できないのでしょうか?

A21:MySQLをソースDBとして使い、CDCを利用する場合はexpire_logs_daysを1以上に設定する必要があります。詳しくは以下のURLに記載があります。
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.MySQL.html

Q22:スキーマという表現はOracleなどのDBに関する概念だと思いますが、Mysqlの場合はスキーマとはDBのことを意味するものと理解してよいでしょうか?

A22:MySQLの場合は他のRDBで言うスキーマという概念はDBに近いものです。
DMSはMySQLのDBもしくは表単位で対象を選択してのレプリケーションに対応しています。

Q23:DMS利用時にマイグレートされるデータは必ず移行元から移行先に転送されることが保証されているのでしょうか。(欠落の可能性はないのでしょうか)

A23:全データをコピーするように動きますが、保証があるわけではありません。
ターゲットDB側のデータに利用上の問題がないかを確認するのはお客様の対応になります。

Q24:ターゲット先DBに障害が発生した場合 復旧後から自動で同期処理を再開できるのでしょうか?

A24:DMSはターゲットDBに対して接続のリトライを繰り返し行い、接続が出来た場合は自動的に同期(CDC)を再開します。
これにより、一時的なDB障害やネットワーク障害発生時でも自動的に復旧します。
ただし長時間接続が出来なかった場合はタスク自体が一旦停止の状態になります。この場合はDBが復旧したのを確認したうえでユーザがタスクを再開させる必要があります。タスクを再開すると、前回同期した時点の状況を確認し、その時点からCDCの同期処理を再開します。

 

以上です。今後のBlackBeltオンラインセミナーの予定はこちらにございます。気になるトピックがありましたら気軽にご参加下さい。引き続き皆様のご参加お待ちしております。

コメント

Twitter, Facebook

このブログの最新情報はTwitterFacebookでもお知らせしています。お気軽にフォローください。

2018年4 月

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30