AWS Database Migration Serviceについて整理してみた

背景・目的

AWS Database Migration Service（以降、DMSと呼びます）について、触れる機会がありましたので知識を整理します。

まとめ

下記に特徴を記載します

特徴	説明
DMSとは	簡単、小さなダウンタイムでAWSへデータベースやDWHを確実に移行する
特徴	・マネージド ・幅広いオプション ・高い可用性 ・低コスト
ユースケース	・Migrate ・Replicate ・Modernize
一般的なレプリケーション方式	物理レプリケーションと論理レプリケーションがある
DMSのレプリケーション方式	論理レプリケーション

概要

下記のAWS Black Beltとドキュメントの記事を参考に整理します。

DMSとは

• 簡単、小さなダウンタイムでAWSへデータベースやDWHを確実に移行する
• 特徴
  • マネージド
    • 自動化された移行サービスで、DBとDWHのワークロードを検出、評価、変換しAWSに移行
  • 幅広いオプション
    • 広く使用されているほとんどの商用データベース、OSSデータベースとの間でデータ移行
    • SQL、NoSQL、テキストベース、DWHをサポート
  • 高い可用性
    • マルチAZオプション
    • 最小限のダウンタイムに向けた継続的レプリケーション、モニタリングの仕組み
    • 高い回復力と自己修復を実現
  • 低コスト
    • コンピューティングリソースと追加のログストレージの使用分のみ

対応データーベース

ソース

下記に記載があります。詳細はドキュメントをご覧ください。

ターゲット

下記に記載があります。詳細はドキュメントをご覧ください。

一般的なDMSユースケース

• Migrate
  • ビジネスクリティカルなアプリケーションとデータウェアハウスを移⾏
  • NoSQL から SQL、SQL から NoSQL
  • NoSQL から NoSQL
  • NoSQL からNoSQL へのマイグレーション
  • マイナー/メジャーバージョンのアップグレード
  • データを統合してアーカイブ
• Replicate
  • クロスリージョンリードレプリカの作成
  • データレイク/データウェアハウスへのデータ連携
  • ストリーミングプラットフォームへのレプリケート
• Modernize
  • イノベーションを加速させるための、Amazon Aurora、Amazon、DynamoDB、Amazon Redshift などの AWS モダンマネージドデータベースへの移⾏
  • レガシーデータベースからの脱却により、データの保存、拡張、イノベーションを実現

DMSアーキテクチャ

一般的なレプリケーション方式

一般的なレプリケーションとしては、下記の2つがある

• 物理レプリケーション
  • ソースDBで作成されたトランザクションログファイルを、ターゲットに転送しターゲットに適用する
  • データベースのリカバリと同じ
• 論理レプリケーション
  • ソースデータベースで作成されたトランザクションログファイルからDMLを作成し、ターゲットに適用する

論理レプリケーションの連携対象

• DMSで作成されるオブジェクトは、テーブルと主キーなどの一部の制約のみ
• インデックス、プロシージャー、ビューはターゲットに手動で反映する必要あり
• DRのように同一構成を作る必要がある場合、ソース、ターゲット両方のDBにオブジェクトを作成する必要がある

レプリケーション方式の違い

物理と論理レプリケーションの方式の違いを載せます。

	物理	論理
レプリケーション方式	トランザクションログをターゲットに適用	トランザクションログからDMLを作成しターゲットに適用
連携単位	データベース単位	テーブル単位
データの整合性	差分が発生する可能性は低い	差分が発生する可能性あり 例） ・ターゲット側への更新エラー ・文字化け ・ユーザによるターゲット側更新
主な制約	ソース、ターゲットでバージョンが同様であること 単位はDB単位、特定のテーブルを指定できない	テーブルデータとテーブル定義、一部制約のみ連携される（製品により異なる）
ターゲット側への処理	参照のみ	参照・更新可能
主な製品・サービス	DBエンジンの機能 ・Oracle DataGuard ・PostgreSQLストリーミングレプリケーション	AWS Database Migration Service Oracle GoldenGate Qlik Replicate

DMSによるデータ連携方式

下記の3つがある

• Full load
  • フルロード開始時点のデータを連携
• CDC
  • CDC開始以降に発生した更新差分データを連携
• Full Load + CDC
  • フルロード＋CDC開始以前の既存データを連携
  • それ以降に発生した更新差分はCDCでデータ連携

Full アーキテクチャ

• ソースに対して、10000件ごとにFetchし、データを抽出する
• ターゲットに対してロードする
• ロード方法は、エンジンによって異なる

CDC アーキテクチャ

• ソースで発生したデータ変更は受信バッファにキャプチャする
• CDCで、ソースからターゲットへキャプチャされたデータ変更を仲介するバッファ、Commitの順番にソートし、Commit済みのデータのみ送信バッファに移動する
• 送信バッファにキャプチャされたデータ変更をターゲットへ適用する

OracleのCDCアーキテクチャ

2つの方式がある

• Oracle Logminer
  • ソースのOracle のREDO/アーカイブログをキャプチャして、DMLをフィルターし転送する
• Oracle Binary Reader
  • ソースのOracle のREDO/アーカイブログをDMSに転送し、DMS上でDMLをフィルターする

SQL Server/MySQL/PostgreSQLのCDCアーキテクチャ

• OracleのLogminerと近い方式。ソースのデータベースでキャプチャDMLをフィルターしてから転送する

トランザクションログのキャプチャに必要な条件

データベース	条件
Oracle	ARCHIVELOGモードと、FORCE LOGGING サプリメンタルロギング
SQL Server	MS-Replication or MS-CDC
MySQL	binlog_format=ROWのバイナリログ
PostgreSQL	論理レプリケーション

Oracleのアーカイブログモード

• REDOログファイルは3つ目のREDOログファイルがいっぱいになると、以前のファイルを上書きする
  • 障害が発生してREDOログファイルを使用して復旧した場合に、上書きされた以前の情報は復旧されない
  • 上記の自体に備えてOracleではREDOログ・ファイルのコピーができるように設定できる
• 仮にアーカイブモードではない場合、変更する必要がある
  • REDOログファイルをアーカイブログファイルとしてコピーされるため、ファイルコピー時のCPUとIOが増加する
  • ログスイッチ時に、対象のREDOログファイルの情報でチェックポイントが完了してないと待機が発生する

Oracleのサプリメンタルロギング

• 一般的に、REDOログ・ファイルは、インスタンス・リカバリおよびメディア・リカバリに使用される
  • これらの操作に必要なデータは、REDOログ・ファイルに自動的に記録される
  • ただし、REDOログ・ファイルには、Oracle内部で管理するRowIDが記録される
  • そのままでは、DMSでは利用できないため、サプリメンタルロギングを設定し、主キーをREDOログに埋め込む必要がある

LOBデータの移行

下記の３つがある

• Full LOB mode
  • DMSはサイズに関係なく、すべてのLOBをソースからターゲットに移行する
  • この設定ではLOBデータの最大サイズに関する情報がない
  • LOBは1つずつ移行され、かなり遅くなる可能性がある
• Limited LOB mode
  • DMSが受け付ける最大LOBサイズを設定する
  • これにより、一括してロードできる
  • しかし最大LOBを超えるサイズは切り捨てられる
  • パフォーマンスは、Full LOB modeより向上する
• Inline LOB mode
  • DMSがインラインで転送する最大LOBサイズを設定する
  • 指定されたLOBより大きいサイズは、フルLOBモードを使用しレプリケーションされる
  • 大部分のLOBが小さい場合、小規模LOBと大規模LOBの両方を複製できる
  • S3やRedshiftなどFull LOB modeをサポートしてないエンドポイントのインラインLOB modeをサポートしてない

データ検証

• フルロード時
  • ソースからターゲットに連携した後に、正しく移行されたか検証する
  • 論理的なパーティションに分割し、パーティションごとに、デフォルト5つのスレッドで比較する
  • 失敗した場合、制御テーブルに書き込まれる
• CDC時
  • 変更された行のみ検証
  • 変更が多い場合、フルロードと同じようなパーティション単位で検証する

データ検証の制限事項

• テーブルにPK、ユニークキーが必要
• データ検証用のクエリが実行されるため、ソースとターゲットに負荷がかかる可能性あり
• 複数のDBを1つに統合する場合、データ検証ができない
• ターゲットデータベースがDMS以外で変更された場合、不一致が正確に報告されない可能性がある

AWS DMS Serverless

• 自動プロビジョニングとスケーリング
  • 移行リソースのプロビジョニング、監視、スケーリングといった時間のかかるタスクを排除することで運用の負担を削減
• 高い費用対効果
  • 必要に応じて最適なサイズに変更されるため、推測に頼る必要がなくなり、使用した分だけ課金
• 幅広いサービス
  • ソースとターゲットのエンドポイントとして一般的なDBエンジンや分析エンジンをサポート
• 高い安定性
  • データ損失とダウンタイムを最小限に抑えてデータを保護

DMSのライフサイクルポリシー

各DMSバージョンリリースのサポート終了日は、最初のリリースから18ヶ月後に開始される

考察

今回、DMSの基本的な内容を整理しました。次回以降実際に利用して試してみます。

参考