この記事は約10分で読めます。
こんにちは。テクニカルサポート課の森本です。 以前のエントリでは、AWS DMS の同種データ移行(RDS MySQL -> Aurora MySQL)を検証してみました。
今回のエントリでは、PostgreSQL on EC2 -> Aurora PostgreSQL の 同種データ移行を検証していきます。 基本的な設定は前回のエントリと同じですが、今回はただ動かすだけでなく必要なネットワーク設定について少しだけ深掘りしてみました。
同種移行の使用
事前準備
こちらのドキュメントの内容に従い進めていきます。
Migrating databases to their Amazon RDS equivalents with AWS DMS - AWS Database Migration Service
環境
今回の環境はソースに PostgreSQL 15 on EC2 (Amazon Linux 2023), ターゲットにAurora PostgreSQL を使用します。 ソース/ターゲット共、同一 VPC 内のプライベートサブネットに構築しています。
IAM リソースの作成
前回作成済みのものを使用します。
ネットワーク設定
今回も同一 VPC 内での移行を前提として設定を行います。
AWS DMSでの同種データ移行用のネットワークのセットアップ - AWS データベース移行サービス
データベース側の設定
ソースデータベースの設定
テスト用のデータベースオブジェクト、およびフルロード用のデータを作成します。
| オブジェクト | 設定値 |
|---|---|
| データベース | repldb |
| スキーマ | replschema |
| テーブル | test |
| ユーザ | repluser |
postgres=# create database repldb; CREATE DATABASE postgres=# \c repldb; You are now connected to database "repldb" as user "postgres". repldb=# create schema replschema; CREATE SCHEMA repldb=# create table replschema.test (id CHAR(4) NOT NULL, note TEXT NOT NULL,PRIMARY KEY (id)); CREATE TABLE repldb=# insert into replschema.test values (1, 'for full load'); INSERT 0 1 repldb=# insert into replschema.test values (2, 'for full load'); INSERT 0 1 repldb=# insert into replschema.test values (3, 'for full load'); INSERT 0 1
また、レプリケーション用のユーザ作成と権限付与を行います。
repldb=# CREATE USER repluser WITH LOGIN PASSWORD '***'; CREATE ROLE repldb=# ALTER USER repluser WITH SUPERUSER; ALTER ROLE repldb=# GRANT SELECT ON ALL TABLES IN SCHEMA replschema TO repluser; GRANT
また、pg_hba.conf に以下追記します。
# TYPE DATABASE USER ADDRESS METHOD # for DMS host all repluser 192.168.0.0/24 md5 host all repluser 172.16.0.0/24 md5 host all repluser 10.0.0.0/24 md5 # for target database host all repluser 10.0.0.5/24 md5 host replication repluser 10.0.5.0/24 md5
for DMS の部分は DMS がデフォルトで使用する可能性のある CIDR、for target database の部分は ターゲットである Aurora PostgreSQL のライターインスタンスが存在するサブネットの CIDR を指定しています。
また、postgresql.conf のパラメータを適宜修正します。
wal_level = logical max_replication_slots = 10 max_wal_senders = 10 wal_sender_timeout = 60s
ここまで設定し、パラメータ反映のため忘れずにPostgreSQL の再起動を実施します。
ターゲットデータベースの設定
移行先のデータベースはあらかじめ作成しておく必要があるので作成します。
postgres=> create database repldb; CREATE DATABASE
また、ユーザを作成し権限付与を行います。 フルロード + CDC には rds_superuser 権限が必要なようなので付与します。
postgres=> CREATE USER repluser WITH LOGIN PASSWORD '***'; CREATE ROLE postgres=> GRANT rds_superuser TO repluser; GRANT ROLE
また、ターゲット側のパラメータグループにて、rds.logical_replicationを1に設定します。 設定後に DB インスタンスの再起動を行います。
移行プロジェクトの作成
サブネットグループやインスタンスプロファイルは前回作成済みのものを流用します。 Secret Manager や データプロバイダーの作成手順にも大きな相違はないので割愛します。
一点、PostgreSQL を対象とする場合は接続時に接続先のデータベース名を指定する必要があるため、データプロバイダーの作成時に忘れずに指定(前述の例だと repldb を指定)します。
データ移行
データ移行の作成
移行プロジェクトの詳細からデータ移行タブに進み、データ移行を作成します。 MySQLと異なり、PostgreSQL をソースとする場合には選択ルールが記述できるため記載しておきます。 ワイルドカードで全てを選択することも可能です。今回は、前述の作業で作成したスキーマ、テーブルに限定して移行を行いました。
{
"rules": [
{
"rule-type": "selection",
"rule-action": "include",
"object-locator": {
"schema-name": "replschema",
"table-name": "test"
},
"filters": [],
"rule-id": "269537808",
"rule-name": "269537808"
}
]
}
データ移行の開始
データ移行を作成しただけでは自動で開始されないので、手動で開始する必要があります。 開始した時点からリソースのプロビジョニングや接続テスト等が行われるため、初回は少し時間がかかります。
After AWS DMS creates your data migration, the status of this data migration is set to Ready. To migrate your data, you must start the data migration manually. To do so, choose your data migration from the list. Next, for Actions, choose Start. For more information, see Managing data migrations.
The first launch of a homogeneous data migration requires some setup. AWS DMS creates a serverless environment for your data migration. This process takes up to 15 minutes. After you stop and restart your data migration, AWS DMS doesn't create the environment again, and you can access your data migration faster.
Creating a data migration in AWS DMS - AWS Database Migration Service
移行結果確認
フルロードの確認
データ移行のステータスが Load complete, replication ongoing になった時点から確認を進めていきます。 ターゲット側で確認します。フルロードが完了しています。
repldb=> select * from replschema.test; id | note ------+--------------- 1 | for full load 2 | for full load 3 | for full load (3 rows)
CDC の確認
ソース側で以下実行します。
repldb=# insert into replschema.test values (4,'for CDC'); INSERT 0 1
ターゲット側で確認します。 CDC でデータ移行されています。
repldb=> select * from replschema.test; id | note ------+--------------- 1 | for full load 2 | for full load 3 | for full load 4 | for CDC (4 rows)
プロセスの確認
ソース側
レプリケーション用のユーザにて、 DMS (172.16.0.199)からの接続と、ターゲット(10.0.5.141)からの接続があることがわかります。 インスタンスプロファイル側からの接続はフルロード用のダンプ取得のため、ターゲット側からの接続はレプリケーション用のためと考えられます。
repldb=# select usename,application_name,client_addr,backend_type from pg_stat_activity where usename = 'repluser'; usename | application_name | client_addr | backend_type ----------+------------------------------------------------------+--------------+---------------- repluser | PostgreSQL JDBC Driver | 172.16.0.199 | client backend repluser | PostgreSQL JDBC Driver | 172.16.0.199 | client backend repluser | migration_subscriber_ejsqcaczmfhzfnrjomiwyqhaxjtxhfz | 10.0.5.141 | walsender (3 rows)
ターゲット側
こちらは DMS 側からの接続のみでした。 ダンプファイルを適用するための接続と考えられます。
repldb=> select usename,application_name,client_addr,backend_type from pg_stat_activity where usename = 'repluser'; usename | application_name | client_addr | backend_type ----------+------------------------+--------------+---------------------------- repluser | PostgreSQL JDBC Driver | 172.16.0.199 | client backend repluser | PostgreSQL JDBC Driver | 172.16.0.199 | client backend repluser | | | logical replication worker (3 rows) 2 rows in set (0.00 sec)
セキュリティグループの設定について
インスタンスプロファイルにセキュリティグループを設定すると、データ移行開始時にAWS により強制的にインバウンドルールが追加されます。
色々と検証した結果、リソース毎に設定が必要そうな内容は以下のとおりでした。
インスタンスプロファイル用
インバウンドルール
| タイプ | プロトコル | ポート | ソース |
|---|---|---|---|
| すべてのトラフィック | すべて | すべて | 172.16.0.0/24 |
このルールはデータ移行の開始時、HomogeneousDataMigrationsRole により自動設定されていました。
Description にも "Security group rule required for AWS DMS Data Migration. Do not delete or modify!" の記載があるので、特に触る必要はなさそうです。
アウトバウンドルール
試しにアウトバウンドルールをすべて削除してみましたが、特に問題なく動作しました。 どうしてこれで動作するのかは残念ながらよく理解できていません。
ソースデータベース用
インバウンドルール
| タイプ | プロトコル | ポート | ソース |
|---|---|---|---|
| PostgreSQL | TCP | 5432 | 10.0.0.0/24 |
| PostgreSQL | TCP | 5432 | 172.16.0.0/24 |
| PostgreSQL | TCP | 5432 | 192.168.0.0/24 |
| PostgreSQL | TCP | 5432 | ターゲットDBのIPアドレスもしくはCIDR |
ターゲット DB から直接接続を受け入れる設定が必要となります。
インスタンスプロファイルに設定しているパラメータグループをソースに指定してもなぜかうまく動作しないため、ドキュメントに記載のある範囲の CIDR を手動で追加する必要がありました。
To avoid CIDR block overlapping with the VPC of your instance profile VPC, AWS DMS uses the /24 prefix from one of the following CIDR blocks: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
Setting up a network for homogeneous data migrations in AWS DMS - AWS Database Migration Service
アウトバウンドルール
同種データ移行によりソース側を起点としたアウトバウンド通信は発生しないので、同種データ移行に関して特定の設定は不要です。
ターゲットデータベース用
インバウンドルール
| タイプ | プロトコル | ポート | ソース |
|---|---|---|---|
| PostgreSQL | TCP | 5432 | 10.0.0.0/24 |
| PostgreSQL | TCP | 5432 | 172.16.0.0/24 |
| PostgreSQL | TCP | 5432 | 192.168.0.0/24 |
インスタンスプロファイルに設定しているパラメータグループをソースに指定してもなぜかうまく動作しないため、ドキュメントに記載のある範囲の CIDR を手動で追加する必要がありました。
アウトバウンドルール
| タイプ | プロトコル | ポート | ターゲット |
|---|---|---|---|
| すべてのトラフィック | すべて | すべて | ソースDBのIPアドレスもしくはCIDR |
ソース DB インスタンスに直接接続するための設定が必要となります。
まとめ
今回は PostgreSQL の同種移行の検証をやってみました。前回(MySQL)よりもネットワークの設定に重点を置いて検証してみました。 ソース、 ターゲットで許可すべきインバウンドルールなどわかりづらい部分がありましたが、検証を通じて(自分としては)少し見通しが良くなったと感じています。
公式ドキュメントにはオンプレミス環境のデータ移行を行うのであれば基本的に パブリック IP アドレスをもとにパブリックインターネット経由の通信が必要となる旨の記載がありますが、Direct Connect 等を使用しているのであれば NLB を使用してこの制限を回避した公式ブログも存在するので、時間があれば試してみたいなと思っています。
For homogeneous data migrations, AWS DMS connects to your source database within the public network. For more details, see Using an On-Premises Source Data Provider. However, connectivity to a source database within a public network is not always possible. In this blog we will explain how to overcome this limitation by utilization network load balancer in AWS.
手動で論理レプリケーションを設定するのは面倒だけど、DMS を使用して レプリケーションインスタンスに余計な費用を払いたくない、少しでもマネージドサービスを活用したい、等の要望に刺さるサービスとして積極的にご案内できるよう、今後も色々と検証して行きたいと思います。
この記事がどなたかのお役に立てば幸いです。
