AWS DMSを使ってAurora MySQLのデータをS3に出力してみた
はじめに
データアナリティクス事業本部のkobayashiです。
Aurora MySQLクラスターのバイナリログを使ってレプリケートする必要があり、その手段としてをAWS DMS(Database Migration Service)を使う機会がありました。検証の途中で、RDS for MySQLとAurora MySQLとの設定の違う箇所があったりしてハマった箇所もあるためその内容をまとめます。
- AWS Database Migration Service とは - AWS Database Migration Service
- MySQL 互換データベースの AWS DMS のソースとしての使用 - AWS Database Migration Service
今回検証を行ったきっかけ
元々はAurora MySQLのデータをSnowflakeに連携したいがどのような方法があるかを調べているなかで以下のブログをたどり着き、参考にさせていただきました。
今回はこちらで紹介されている連携方法のうち「Aurora」から「S3」へ連携する箇所を実際に試してみたいと思います。
なお、「S3」から「Snowflake」へ連携する箇所は別エントリで検証を行っているのでこちらも併せて御覧ください。
AWS DMSとは
様々なデータベース(RDB,NoSQL,DWH)を他のデータベースへ移行する際に役立つサービスです。 移行にはワンタイムだけの移行だけでなく、レプリケーション機能を使い継続的に移行元と移行先のデータベースを同期することもできます。
今回は Aurora MySQLのCDC(Change Data Capture)としてAWS DMS使ってみます。なお移行先としてはデータベースでなくS3へCSV形式として出力します。
DMSを使ったAurora MySQLのデータ移行
MySQLデータベースでAWS DMSを使う際のドキュメントが「MySQL 互換データベースの AWS DMS のソースとしての使用 - AWS Database Migration Service 」にありますのでこのドキュメントを参考にしながら作業を進めると以下の通りになります。
- Aurora MySQLのパラメータグループの設定
- バイナリログの設定
- AWS DMSの構築
- エンドポイントの作成
- サブネットグループの作成
- レプリケーションインスタンスの作成
- データベース移行タスクの作成
なお、今回ソースとなるAuroraのエンジンは5.7.mysql_aurora.2.07.2
で、 すでにクラスターを作成して起動中の状態から進めていきます。
Aurora MySQLのパラメータグループの設定
AWS DMSではMySQLのバイナリログを使いますが、デフォルトのパラメータグループでは有効になっていないため、専用のパラメータグループを作成しそれをAuroa MySQLにアタッチします。Aurora MySQLでのバイナリログの設定は「Amazon Aurora MySQL クラスターのバイナリログを有効にする 」にも記載がありますのでここを参考にします。
手順1)マネージメントコンソールよりパラーメタグループ
を選択しパラメータグループの作成
ボタンを押下する。
手順2)パラメータグループの作成
の設定を行い作成
を押下する。
- パラメータグループファミリー :
aurora-mysql5.7
を選択 - タイプ :
DB Cluster Parameter Group
を選択 - グループ名 : 適切な値を入力
- 説明 : 適切な値を入力
手順3)作成したパラメータグループ名を選択してパラメータの設定を変更する。
binlog_format
:ROW
を選択binlog_row_image
:FULL
を選択binlog_checksum
:NONE
を選択
手順4)データベース > 対象のAuroraクラスタ > 変更
でバイナリログ出力の設定を行ったパラメータグループをAuroraクラスターにアタッチします。
手順5)Auroraクラスターを再起動する。
これでAurora MySQLからAWS DMSで取り込めるバイナリログが出力されるようになリます。
AWS DMSの構築
次に実際にレプリケーションを行うDMSの構築を行います。
エンドポイントの作成
はじめにソースとターゲットのエンドポイントを作成します。今回ソースは先に設定を行ったAurora MySQLなので改めてリソースを作成する必要はありませんが、ターゲットはS3としています。バケットとバケットへ書き込むことのできるロールが必要となりますので予め作成しておきます。
今回はS3のバケットをcm-kobayashi-dms-test
、読み書きできるロールをdmsAuroraToS3
として作成してある状態から進めます。
手順1)AWS DMS
からエンドポイントを選択し、エンドポイントの作成
を押下する。
手順2)エンドポイントの作成
の設定を行いエンドポイントの作成
を押下する。
- エンドポイントタイプ :
ソースエンドポイント
を選択- RDS DBインスタンスの選択 : チェック
- RDSインスタンスでAuroraを選択
- エンドポイント設定
- エンドポイント識別子 : RDSインスタンスを選択すると自動入力
- ソースエンジン : RDSインスタンスを選択すると自動入力
- エンドポイントデータベースへのアクセス :
アクセス情報を手動で提供する
を選択 - サーバー名 : RDSインスタンスを選択すると自動入力
- ポート :
3306
を入力 - ユーザー名 : ユーザー名を入力
- パスワード : パスワードを入力
Auroraへの接続情報をAWS Secrets Managerで管理していればエンドポイントデータベースへのアクセス
で[AWS Secrets Manager]を選択する
を選択すれば良いですが、今回は手動で提供
にしてあります。
次にターゲットエンドポイントの設定を行います。
手順3)エンドポイントの作成
の設定を行いエンドポイントの作成
を押下する。
- エンドポイントタイプ :
ターゲットエンドポイント
を選択 - エンドポイント設定
- エンドポイント識別子 : 適当な名前を入力
- ターゲットエンジン :
Amazon S3
を選択 - サービスへのアクセスロールのARN : ターゲットとなるバケットに書き込み権限のあるロールを入力
- バケット名 : ターゲットとなるバケット名を入力
- エンドポイント設定 :
{ "CsvRowDelimiter": "\\n", "CsvDelimiter": ",", "CompressionType": "NONE", "EnableStatistics": true, "DatePartitionEnabled": false, "IncludeOpForFullLoad": true }
を入力
ターゲットをS3とする場合の出力ファイルの設定はエンドポイント設定で設定を行います。 特に指定しないとCSVで出力される以下の設定値がデフォルト設定として登録されます。
{ "CsvRowDelimiter": "\\n", "CsvDelimiter": ",", "CompressionType": "NONE", "EnableStatistics": true, "DatePartitionEnabled": false }
今回はこの設定に加えて"IncludeOpForFullLoad": true
を加えています。これは移行タイプでFullロードを選んだ際にも最初の列にInsertを示すI
を付け加えることができます。
以上でエンドポイントの設定は終わりです。次にサブネットグループの作成をおこないます。
サブネットグループの作成
レプリケーションインスタンスを配置するサブネットグループを作成します。
手順1)AWS DMS
からサブネットグループを選択し、サブネットグループの作成
を押下する。
手順2)レプリケーションサブネットグループの作成
の設定を行いレプリケーションサブネットグループの作成
を押下する。
- サブネットグループの設定
- 名前 : 適当な名前を入力
- 説明 : 適当な説明を入力
- VPC : レプリケーションインスタンスを配置するVPCを選択
- サブネットの追加 : サブネットを2つ以上追加
レプリケーションインスタンスの作成
次にレプリケーションタスクを行うレプリケーションインスタンスの作成を行います。
手順1)AWS DMS
からレプリケーションインスタンスを選択し、レプリケーションインスタンスの作成
を押下する。
手順2)レプリケーションインスタンスの作成
の設定を行いレプリケーションインスタンスの作成
を押下する。
- レプリケーションインスタンスの設定
- 名前 : 適当な名前を入力
- 説明 : 適当な説明を入力
- インスタンスクラス : タスクを実行するのに十分なリソースを持ったインスタンスクラスを選択
- エンジンバーション : 特に制限がなければ最新バージョンを選択
- 割り当てられたストレージ : 特に制限がなければデフォルトの
50
を入力 - VPC : 先に作成したサブネットグループで設定したVPCを選択
- パブリック・アクセス可能 : チェックを外す
- セキュリティとネットワーク詳細設定
- レプリケーションサブネットグループ : 先に作成したサブネットグループを選択
インスタンスが作成できたらここまでの設定が問題ないかを確認します。
再びエンドポイントの画面に戻り、作成したエンドポイントを選択してアクション > 接続テスト
を押下すると設定に問題がなければステータスがsuccessful
になります。
今回は動作確認のための設定なので最低限の設定となっています。環境に応じて設定を変更してみてください。
データベース移行タスクの作成
最後にレプリケーションインスタンスで実行するでデータベース移行タスクを作成します。
手順1)AWS DMS
からデータベース移行タスクを選択し、データ移行タスクの作成
を押下する。
手順2)データ移行タスクの作成
の設定を行いデータ移行タスクの作成
を押下する。
- タスクの設定
- タスク識別子 : 適当な名前を入力
- レプリケーションインスタンス : 先に作成したものを選択
- ソースデータベースエンドポイント : 先に作成したものを選択
- ターゲットデータベースエンドポイント : 先に作成したものを選択
- 移行タイプ :
既存のデータを移行して、継続的な変更をレプリケートする
を選択
- タスク設定 :
ウィザード
を選択し、デフォルト値のまま - テーブルマッピング :
ウィザード
を選択し、対象のスキーマを絞る場合は設定
これで移行タスクが設定できたのでAurora MySQLからS3へのデータ移行の準備ができました。
タスクを実行してみる
では最後に作成したデータベース移行タスクを実行してみます。
データベース移行タスクを選択し、作成したタスクにチェックを入れ、アクション > 開始/再開
を押下してタスクを開始します。
しばらくすると実行中
になりロードが完了するとロード完了、レプリケーション実行中
とステータスが変わります。
タスク名からタスクの詳細を確認してみるとタスクの状況やデータ移行の統計情報が確認できます。
ターゲットの確認
ターゲットのS3を見てみるとファイルができています。また適当なクエリを実行すると新たにCSVファイルが出来上がります。
ファイルの中身を見ると以下のように行データがどのように変更されたかが記録されています。
$ head -n 5 LOAD00000001.csv I,1,Kabul,AFG,Kabol,1780000 I,2,Qandahar,AFG,Qandahar,237500 I,3,Herat,AFG,Herat,186800 I,4,Mazar-e-Sharif,AFG,Balkh,127800 I,5,Amsterdam,NLD,Noord-Holland,731200 $ head -n 5 20211116-030109755.csv D,1752,Sakata,JPN,Yamagata,101651 I,4080,u02naeNPL1hGghP1okO6Ca3St904Ez9cBFp,JPN,G5WISS6KAqkixVQWpkFO,16889 U,1309,A4vBcfzBUknhHPbMVgbZS5NyOiErCgKim34,IND,H1qlDm3K3O8rFTjt9Hld,35906
まとめ
Aurora MySQLのデータをAWS DMSを使い移行タイプとしてFullロードとCDCでS3へCSV出力してみました。 設定もマネージメントコンソールから簡単に行えるのでS3を起点としてその先にデータをレプリケーションしたい場合には有効に機能すると思われます。
また、S3からの連携先としてSnowflakeへの検証を別エントリで行っているのでこちらも併せてご覧ください。
最後まで読んで頂いてありがとうございました。