目次
AWS DMS とは
DMS は AWS Database Migration Service の略で、簡単に言うと、あるデータベースのデータを、別のデータベースや S3 などの保存先へ移行・同期するための AWS サービスです。リレーショナルDB、データウェアハウス、NoSQL DB、その他データストアの移行に使えるサービスと説明されています。
DMS は、元DBを読み取り、DMSが中継し、先DBへデータを流す仕組みです。
以下のイメージです。
SQL Server / MySQL / PostgreSQL / Oracle など
↓
AWS DMS
↓
Redshift / RDS / Aurora / S3 など
このように、DBのデータを分析基盤・データマート・別DBへ連携するために使われています。
データマートとは
データマートとは、特定の業務・部門・用途で使いやすいように整えた分析用データ置き場です。
たとえば、会社全体の生データや巨大な分析基盤があるとして、その中から
「営業が見たいデータ」
「マーケティングが見たいデータ」
「経営レポートで使うデータ」
「求人応募分析で使うデータ」
のように、目的別に切り出して、集計・加工・整理したデータセットがデータマートです。
データマートと DB との違い
DBは、アプリケーションを動かすためのデータです。
たとえば、
応募する
企業情報を更新する
ログインする
請求情報を登録する
など、サービスの動作に使われます。
一方、データマートは、
今月の応募数は?
企業ごとの応募率は?
掲載プランごとの売上は?
前月比でどれくらい増えた?
どのカテゴリが伸びている?
のような 分析・レポート・BI・機械学習・業務判断 のために使われます。
DWHとの違い
よく似た言葉に DWH、データウェアハウス があります。
違いは以下のようになります。
DWH = 全社的・大規模な分析用データ基盤
データマート = 特定用途向けに整えた小さめの分析用データ
イメージとしてはこうです。
本番DB
↓
DMS / ETL / CDC などで連携
↓
DWH / データレイク / Redshift / Databricks など
↓
用途別に加工
↓
データマート
↓
BIツール / Redash / Tableau / Looker / ダッシュボード / SQL分析
つまり、データマートは DWH の中に作られることもありますし、DWH から派生して作られることもあります。
DMSでできること
DMSの主な用途は大きく3つです。
1. 既存データをまるごと移行する
たとえば、SQL Serverの既存テーブルをRedshiftへコピーするような使い方です。
既存の user テーブル 2,000万件
↓
DMSが読み取る
↓
ターゲット側にロードする
これは DMS では Full Load(フルロード、再ロード)と呼ばれます。DMS タスクには「既存データの移行」「キャッシュされた変更の適用」「継続的なレプリケーション」のフェーズがあります。
2. 変更分だけを継続連携する
既存データを一度コピーした後、アプリケーションが DB を更新し続けると、移行先へも追従(ついじゅう)させる必要があります。
アプリが SQL Server の user テーブルを INSERT / UPDATE / DELETE
↓
DMS が変更を検知
↓
ターゲット側にも反映
これが CDC、つまり Change Data Capture(変更データキャプチャ)です。
CDC は「変更データキャプチャ」という意味で、DB に発生した INSERT / UPDATE / DELETE などの変更を拾って、ターゲットへ反映する仕組みです。DMS では「Full load plus CDC」や「CDC only」というタスク方式があります。
ALTER について
一般的な CDC の中心は、INSERT / UPDATE / DELETE などの「データ変更」です。ALTER TABLE は通常、CDC の主役ではありません。
ただし、AWS DMS では、CDC 実行中に発生した一部の DDL 変更、つまり ALTER TABLE などのテーブル定義変更をターゲットへ反映する機能があります。 DMSの ChangeProcessingDdlHandlingPolicy は「CDC中のDDL変更をターゲットテーブルでどう扱うか」を決める設定で、HandleSourceTableAltered を true にすると、ソーステーブルが ALTER されたときにターゲットテーブルも ALTER します。
3. 異なるDB間の移行にも使える
DMS は、同じ DB エンジン間だけでなく、異なる DB エンジン間でも使えます。
例:
Oracle → PostgreSQL
SQL Server → Aurora PostgreSQL
MySQL → Redshift
RDS → S3
同じ DB エンジン間、たとえば Oracle から Oracle、または異なる DB エンジン間、たとえば Oracle から PostgreSQL への移行に利用できます。ただし、DMSを使うには少なくとも一方のエンドポイントが AWS サービスである必要があります。
DMSの基本構成
DMS を理解するうえで重要なのは、以下の4つです。
① ソースエンドポイント
② ターゲットエンドポイント
③ レプリケーションインスタンス
④ レプリケーションタスク
DMS 移行は主に、データベース検出、スキーマ変換、レプリケーションインスタンス、ソース/ターゲットエンドポイント、レプリケーションタスクなどのコンポーネントで構成されます。
① ソースエンドポイント
データの取得元DBです。
例:
RDS SQL Server
Aurora MySQL
Oracle
PostgreSQL
オンプレDB
DMSから見ると、どこからデータを読むのか を定義する接続情報です。
中身としては、だいたい以下のような情報を持ちます。
DBホスト名
ポート
DBユーザー
パスワード
DBエンジン種別
SSL設定
追加接続属性
② ターゲットエンドポイント
データの書き込み先です。
例:
Redshift
Aurora
RDS
S3
DynamoDB
OpenSearch
DMSから見ると、読み取ったデータをどこへ書き込むのか を定義する接続情報です。
③ レプリケーションインスタンス
これが DMS の実体に近いです。
レプリケーションインスタンス = DMS の処理を実行するサーバーです。
DMS のレプリケーションインスタンスは、1つ以上のレプリケーションタスクをホストする管理された EC2 インスタンスのようなものです。
つまり、ざっくり言うとこうです。
ソース DB から読む
変更データを一時的に保持する
必要に応じて変換する
ターゲット DB へ書く
エラーや遅延を管理する
この処理をしているのが、レプリケーションインスタンスです。
そのため、DMS で遅延が出るときは、このレプリケーションインスタンスの以下が問題になります。
CPU
メモリ
ストレージ
ネットワーク
ターゲットへの書き込み速度
一時ファイル / swap files
④ レプリケーションタスク
DMS で実際に何を連携するかを定義する設定です。
DMSタスクでは、たとえば以下を指定します。
どのソースエンドポイントから読むか
どのターゲットエンドポイントへ書くか
どのテーブルを対象にするか
Full Load だけか
CDC だけか
Full Load + CDC か
エラー時にどうするか
DDL 変更をどう扱うか
ログをどこまで出すか
DMS タスクは「どのテーブルやスキーマを使うか」「ログ、制御テーブル、エラー処理などの特別な処理」を指定する、DMS で実際の作業が行われる場所です。
DMSの処理の流れ
一番基本的な流れはこうです。
1. DMS用のレプリケーションインスタンスを作る
2. ソースエンドポイントを作る
例: RDS SQL Server
3. ターゲットエンドポイントを作る
例: Redshift / S3
4. レプリケーションタスクを作る
例: dbo.user, dbo.id を連携対象にする
5. タスクを開始する
6. 既存データをロードする
7. 以降の変更をCDCで継続連携する
Full Load と CDC の違い
DMSでよく出る重要用語です。
| 用語 | 意味 | 例 |
|---|---|---|
| Full Load | 既存データをまとめてコピーする | companyテーブル2,000万件を一括コピー |
| CDC | 変更分を継続的に反映する | INSERT / UPDATE / DELETE を追従 |
| Full Load + CDC | 既存データをコピーした後、変更分も追従 | 初回移行+継続同期 |
| CDC only | 既存データはすでにあり、変更分だけ流す | 途中から差分連携だけ行う |
業務運用で一番よく使うのは、
Full Load + CDC
または、すでにターゲット側に初期データがある場合の、
CDC only
です。
DMSは便利だが扱いづらい
DMS は非常に便利です。DB を他の DB へマイグレーションしてくれます。Oracle から MySQL へのマイグレーションもできます。
今まで Oracle や SQL Server を利用していてライセンス料金の負担が気になっている場合は、DMS を利用して MySQL や PostgreSQL へのマイグレーションもしてくれます。非常に便利ですよね。
しかし便利で痒い所に手が届くだけあってクセがあります。例えば便利すぎて日々の運用に取り入れると結構な運用工数が取られることになります。例えば DMS で常時 RDS SQL Server から RDS SQL Server へレプリケーションをする場合などです。
「え!?RDS SQL ServerからRDS SQL Serverへレプリケーションですか!?それってRDS SQL Serverでリードレプリカを構築すればいいだけなのでは?」
と思うかもしれません。正解ですが、企業によっては様々な事情がありリードレプリカではなく全然別のAWSアカウントに配置する必要があるかもしれません。
またはセキュリティ上の理由で特定のテーブルのみ見せたいとか。自社だけで完結していればいいですが外部ベンダーも参画していたり、外部ベンダーの AWS アカウントと連携していたりとか、いろいろ複雑な事情があり DMS を使わざるを得ない状況もあります。