AWS DMS

AWS DMS

(Database Migration Service) は、データベースのデータを別のデータベースやデータストアへ移すサービスです。一度だけ全データを移す移行にも、変更を取り出して続けて反映する継続的な複製 () にも使えます。DEA では、からやへデータを取り込む手段として、また異なるエンジン間でスキーマを変換する手段として出題されます。

Point

DMS = Database Migration Service の略です。
SCT = Schema Conversion Tool の略で、スキーマ (テーブル定義、ビュー、ストアドプロシージャなど) を別のエンジン向けに書き換える道具です。
同種移行 (homogeneous) は同じエンジン同士 (MySQL → Aurora MySQL)、異種移行 (heterogeneous) は違うエンジン同士 (Oracle → Aurora PostgreSQL) です。
和訳
- Heterogeneous: 異種の
- Weblio英和辞書「heterogeneous」

概要

は、 (接続先の定義)、の実行環境、タスク (何をどう移すか) の3つで構成します。データを移すのは DMS、異種移行でスキーマを書き換えるのは DMS Schema Conversion または、と役割が分かれます。

主要技術

①構成要素

要素	内容
ソース	読み取り元のデータベースの接続情報
ターゲットエンドポイント	書き込み先の接続情報と、出力の設定 ( なら形式やパーティション)
インスタンス	タスクを実行するマネージドのインスタンス。サイズとマルチを選ぶ
Serverless	容量をサービスが見積もり、自動で拡張・縮小する。インスタンスの選定やパッチ適用が不要
タスク / レプリケーション設定	テーブルの選択、変換ルール、全ロードとの種類

実行環境	向くケース
レプリケーションインスタンス	負荷が安定、細かい設定と予測可能な費用
DMS Serverless	負荷が変わる、容量の見積もりをしたくない、運用を減らしたい

レプリケーションインスタンスをマルチ AZ にすると、AZ の障害時にスタンバイへし、継続的な複製が止まりにくくなります。

②タスクの種類: 全ロードと CDC ⚠️ 頻出

種類	内容	使いどころ
全ロード	既存のデータを一度に移す	一回限りの移行、初期データの作成
全ロード +	全部移した後、進行中の変更を続けて反映	ダウンタイムを最小にした移行、継続的な取り込み
CDC のみ	変更だけを流す	初期データを別の方法 (ネイティブのダンプなど) で用意した場合

CDC は、ソースのトランザクションログ (MySQL のバイナリログ、PostgreSQL の論理、Oracle の REDO ログなど) を読みます。そのため、ソース側でログの保持や論理レプリケーションの設定が必要です。

ソース	CDC の前提となる設定
for MySQL	自動バックアップを有効にする (バイナリログが有効になる)。パラメータグループで binlog_format を ROW、binlog_row_image を FULL にする。RDS はバイナリログをすぐ消すため、`mysql.rds_set_configuration` で binlog retention hours を延ばす
MySQL	クラスターのパラメータグループで binlog_format を ROW にする
PostgreSQL	論理レプリケーション (rds.logical_replication) を有効にする

⚠️ 頻出: 「本番 DB を止めずに移行し、切り替えの直前まで変更を反映し続けたい」は全ロード + CDC です。

③ターゲットごとの使い方

ターゲット	使い方	ポイント
	への取り込み	出力形式に CSV かを選ぶ。Parquet にするとで効率よく読める。日付でフォルダを分ける設定や、の操作列 (I/U/D) を付けられる
	変更をストリームとして配る	変更を、、など複数の処理系で使う
	DWH へのロード	は内部で S3 に書いてからする
、、他の	移行・同期	—

S3 へ CDC を書き出すと、変更はファイルとして追記されていきます。分析用のテーブルにするには、やでなどへします (「変更データキャプチャ (CDC) と」の章)。

④テーブルマッピングとデータの検証

機能	内容
選択ルール	移すスキーマやテーブルを含める・除く (ワイルドカード可)
変換ルール	スキーマ名やテーブル名、列名の変更、列の追加・削除、小文字化
データ検証	ソースとターゲットの行を比較し、不一致を報告する
移行前評価 (premigration assessment)	データ型の非互換や設定の不足を移行前に見つける
LOB の設定	大きなオブジェクト (LOB) の扱い。制限付き LOB モードは速いが、上限を超える部分は切り捨てられる

の変換ルールは名前の変更や列の追加など軽いものに限られます。複雑な変換や結合は、移した後でやので行います。

⑤スキーマ変換: AWS SCT と DMS Schema Conversion ⚠️ 頻出

異種移行では、テーブル定義だけでなく、ビュー、ストアドプロシージャ、関数、トリガーもターゲットのエンジンの文法へ書き換える必要があります。自体はスキーマのコード (プロシージャなど) を変換しません。

道具	形態	特徴
DMS Schema Conversion	DMS のコンソールで使うマネージドの機能	評価レポートで手作業が必要な箇所を示し、スキーマを変換してターゲットへ適用する。生成 AI による変換の補助もある
	自分の PC やサーバーにインストールするデスクトップアプリ	対応するソースとターゲットの組み合わせが多い。 (Oracle、Teradata、Netezza など) からへの変換にも使う

同種移行 (例: MySQL → MySQL) ではスキーマ変換はほぼ不要で、ネイティブのツール (ダンプや) や DMS の同種データ移行も選べます。

⚠️ 頻出: 「Oracle から Aurora PostgreSQL へ移行。ストアドプロシージャも変換したい」は、DMS Schema Conversion (または AWS SCT) でスキーマを変換し、DMS でデータを移す組み合わせです。DMS だけではプロシージャは変換されません。

⑥ネットワークとセキュリティ

項目	内容
配置	インスタンスは内。のソースへはかで到達させる
接続許可	ソース DB のファイアウォールやで、レプリケーションインスタンスからの接続を許可する
認証情報	のパスワードをで管理できる
暗号化	保管時は、転送中は /

試験対策

①判断マトリクス

問題文のキーワード	選ぶ機能
DB を止めずに移行、変更も反映し続ける	全ロード +
のデータをのへ、で分析	→ S3 ()
DB の変更を複数の処理系へストリームで配る	DMS →
移行の容量を見積もりたくない、運用を減らす	DMS Serverless
複製をの障害で止めない	マルチ AZ のインスタンス
異種移行でプロシージャも変換	DMS Schema Conversion /
DWH (Teradata など) からへスキーマ変換	AWS SCT
移したデータが正しいか確認	DMS のデータ検証
移行前に非互換を見つける	移行前評価
→ Redshift を運用最小で継続同期	DMS ではなく統合を検討

②よくある誤答

がストアドプロシージャも変換すると考えること。スキーマのコードは DMS Schema Conversion かです。
DMS の変換ルールで複雑な結合や集計を行おうとすること。移した後でやで行います。
に必要なソース側の設定 (バイナリログの保持など) を忘れること。
/ からへの継続的な同期に、自分で DMS のパイプラインを組むことを最初に選ぶこと。運用最小なら統合です。

概要