MENU
AWS

AWS DMSだけ！お手軽スキーマ変換をやってみよう

migration
koma

こんにちは！久々に出張することになり、元出張族の血が騒いでいるこまっちゃんです。ただ、延期に次ぐ延期でまだ出張できておりません。

さて、今回はデータ移行のお話です。
異種データベース間でデータ移行をする場合、スキーマを変換する「AWS Schema Conversion Tool」（以降SCT）とデータを移行する「AWS Database Migration Service」（以降DMS）は外せません。しかし、実は条件を満たせばDMSのみ！インストール不要！でスキーマ変換もデータの移行も出来るってご存知ですか？

ということで、今回はDMSのスキーマ変換機能をお試ししてみました。

本記事はこんな方におすすめ
  • DMSのスキーマ変換機能を試してみたい方
  • オンプレミスにSCTをインストールできず、代わりの移行手段を探している方
  • 移行に必要なリソースをサクッと作り、短時間で使用感を確かめたい方
    • AWSワークショップ「AWS Database Migration Workshop」にて配布されているAWS CloudFormation Templateを使ってほとんどのリソースを構築します！
Contents
  1. DMSのスキーマ変換機能
  2. 前提条件・制限事項
    1. 使用できるデータベースの種類
    2. サポートされているAWSリージョン
    3. 制限事項
  3. DMSでスキーマ変換してみよう！
    1. 1. リソースの構築
    2. 2. インスタンスプロファイルの作成
    3. 3. データプロバイダーの作成
    4. 4. 移行プロジェクトの作成
    5. 5. 評価レポートの作成
    6. 6. ソースデータベースのソースコードを変換
    7. 7. ターゲットデータベースへ変換済みコードを適用
  4. まとめ

DMSのスキーマ変換機能

本来、AWSで異種データベース間移行をする場合、以下の流れがほとんどかと思います。

  1. SCTで、移行するデータベースのスキーマ・プロシージャー等を、移行先のデータベースに合わせて自動変換する。評価レポートに基づき、適宜手動でも変換する
  2. DMSでデータを移行する

この①のステップをDMSが担う！というのがDMSのスキーマ変換（Schema Conversion）機能です。端的にお伝えするならば、SCTのウェブ版が本機能となります。

DMS Schema Conversionは3つのコンポーネントで構成されています。

画像引用元）AWS Database Migration Service User Guide > Converting database schemas using DMS Schema Conversion

  • インスタンスプロファイル：ネットワークやセキュリティ設定を検出します。
  • データプロバイダー：データベースの接続情報を保存します。
  • 移行プロジェクト：インスタンスプロファイル、プロバイダー、移行ルールを元にスキーマやコードを変換します。

詳細は公式ドキュメントや、AWS公開のYoutube（以下）をご覧ください。

Q
Introduction to the DMS Schema Conversion

前提条件・制限事項

注意点

DMS Schema Conversion機能は、SCTと比較して一部機能が制限されています。
また、使用できるデータベースの種類も指定されているので、事前にスキーマ変換が可能か必ず確認するようにしましょう！

使用できるデータベースの種類

移行元（ソース）データベース

  • Microsoft SQL サーバーバージョン 2008 R2、2012、2014、2016、2017、2019
  • オラクルバージョン 10.2 以降、11g から 12.2、18c、19c まで

移行先（ターゲット）データベース

  • Amazon Aurora MySQL 8.0.23
  • Amazon Aurora PostgreSQL 14.5
  • Amazon RDS for MySQL 8.0.23
  • Amazon RDS for PostgreSQL 14.x

参考）AWS Database Migration Service User Guide > How AWS DMS works >
Sources > Sources for DMS Schema Conversion , Targets > Targets for DMS Schema Conversion

サポートされているAWSリージョン

リージョン名リージョン
米国東部（バージニア北部）us-east-1
米国東部（オハイオ）us-east-2
米国西部（オレゴン）us-west-2
アジアパシフィック（東京）ap-northeast-1
アジアパシフィック（シンガポール）ap-southeast-1
アジアパシフィック（シドニー）ap-southeast-2
欧州（フランクフルト）eu-central-1
欧州（ストックホルム）eu-north-1
欧州（アイルランド）eu-west-1
参考）AWS Database Migration Service User Guide > Converting database schemas using DMS Schema Conversion > Supported AWS Regions

制限事項

SCTはSQLを編集する際に、①データベースのSQLコードを直接編集するか、②SCTが生成するスクリプトを編集するかを選択できますが、DMS Schema Conversionは②のみであり、直接SQLコードを編集することはできません。

その他の制限事項はこちらからご確認ください。

DMSでスキーマ変換してみよう！

では、さっそくDMSでスキーマ変換をしてみましょう！
今回はワークショップ「Microsoft SQL Server to Amazon Aurora (PostgreSQL)」のPart 1: Schema Conversionを、SCTを使わずにDMS Schema Conversionで実行してみます。以下の流れで進めていきます。

  1. リソースの構築
  2. インスタンスプロファイルの作成
  3. データプロバイダーの作成
  4. 移行プロジェクトの作成
  5. 評価レポートの作成
  6. ソースデータベースのソースコードを変換
  7. ターゲットデータベースへ変換済みコードを適用

1. リソースの構築

Q
1-1. データベース等リソースの作成

ワークショップの手順を参考に、CloudFormationのテンプレートからリソースを立ち上げます。リージョンは任意ですが、今回はap-northeast-1（東京）で作成します。

LabTypeは「Microsoft SQL Server to Amazon Aurora (PostgreSQL)」を選択してください。

注意点

作成されるEC2やRDSはインスタンスサイズが大きいので、利用料金が高額になる可能性があります。使用しない場合はこまめに停止するのがお勧めです。

Q
1-2. S3バケットの作成

バージョニングをオンにして作成します。他はデフォルトで問題ありません。
評価レポートや変換したSQLコード、スキーマに関する情報等を保存するために使用します。

Q
1-3. AWS Secrets Managerにソースデータベースの認証情報を保存
  1. AWS Secrets Managerにアクセスし、「Store a new secret」を選択
  2. Select type：「Credentials for other database」を選択
  3. Credential：ソースデータベースのusername, passwordを登録
    <>で囲われているkeyのvalueについては、1-1で作成したCloudFormationスタックのOutputsを確認してください。また、こちらの入力値も参考になります。
    • username：<DMSDBSecretUSQLSERVER>
    • password：<DMSDBSecretPSQLSERVER>
  4. Database：以下を入力/選択
    • Database：SQL Server
    • Server address：<SourceEC2PrivateDns>
    • Database name：dms_sample
    • Port：1433
  5. Secret name and description：任意の名前を入力（例：sc-source-secret）
  6. 他はデフォルトで作成
Q
1-4. IAMロールを作成

AWS S3, AWS Secrets Managerに接続するために必要なIAMロールをそれぞれ作成します。

Amazon S3 バケットにアクセスするための IAM ロール

以下のとおりIAMロールを作成し、作成後に信頼ポリシーを編集します。

  • 信頼するエンティティ：DMS
  • 許可するポリシー：AmazonS3FullAccess
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "schema-conversion.dms.amazonaws.com",
                    "dms.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

AWS Secrets Managerへのアクセスを許可するIAM ロール

以下のとおりIAMロールを作成し、作成後に信頼ポリシーを編集します。

  • 信頼するエンティティ：DMS
  • 許可するポリシー：SecretsManagerReadWrite
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "dms.ap-northeast-1.amazonaws.com",
                    "schema-conversion.dms.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

2. インスタンスプロファイルの作成

  1. DMSコンソールへアクセスし、「Instance profiles」の作成ボタンを押下
  2. 以下のパラメータを入力し作成
    • Network type：IPv4
    • VPC for IPv4：<1-1で作成したVPC>
    • Subnet group：<1-1で作成したサブネットグループ>
    • VPC security groups：<1-1で作成したRDSのセキュリティグループ>
    • Assign public IP：No
Q
パラメータ参考画像

3. データプロバイダーの作成

3-1. ソースデータベースのデータプロバイダーを作成

  1. DMSコンソールへアクセスし、「Data providers」の作成ボタンを押下
  2. 以下のパラメータを手入力で入力し、作成（参考：こちら）
    • Engine type：Microsoft SQL Server
    • Server name：<SourceEC2PrivateDNS>
    • Port：1433
    • Database name：dms_sample
    • SSL mode：none
Q
パラメータ参考画像

3-2. ターゲットデータベースのターゲットプロバイダーを作成

  1. DMSコンソールへアクセスし、「Data providers」の作成ボタンを押下
  2. Engine type：Amazon Aurora PostgreSQL を選択
  3. 「RDS database Instance」を選択し、ターゲットのAuroraをプルダウンから選択
  4. その他、以下のパラメータで登録
    • Database name：AuroraDB
    • SSL mode：none
Q
パラメータ参考画像

4. 移行プロジェクトの作成

  1. DMSコンソールへアクセスし、「Migration projects」の作成ボタンを押下
  2. 以下のパラメータで作成
    • Source data provider
      • Source：<3-1で作成したプロバイダー>
      • Secret ID：<1-3で作成したSecrets>
      • IAM role：<1-4で作成したAWS Secrets Manager用IAMロール>
        Targetでも同じIAMロールを使用
    • Target data provider
      • Target：<3-2で作成したプロバイダー>
      • Secret ID：<1-1で作成したSecrets>
    • S3 Bucket
      • URL：<1-2で作成したS3バケットのURL>
      • IAM role：<1-4で作成したAmazon S3用IAMロール>
  3. （今回は実施しません）移行時にテーブル名を変換するといった、移行ルールについても「Transformation rules - optional」より設定可能です
Q
パラメータ参考画像

5. 評価レポートの作成

  1. 4で作成した移行プロジェクトを開き、「Overview」タブから「Schema conversion」タブに切り替える
  2. 「Launch schema conversion」を押下

で、スキーマ変換機能を起動できます。画面の見方は以下の通りです。

ソースデータベース側のデータベースから「dms_sample」を選択後、Actionsから「Assess」を選択し押下すると、評価レポートを生成できます。

サマリやアクションアイテムについて

評価レポートを生成すると、以下画像のようなサマリが表示されます。薄紫で表示されている項目数分は、DMS Schema Conversionが自動でスキーマを変換してくれます。一方、それ以外の色の場合は何らかのアクションが必要となるので、アクションアイテムタブから必要な作業を確認していきます。

ファイル名の左に マークが付いている場合、ターゲットデータベース用にソースコードの変換が必要です。 マークが付いている場合は変換不要となります。

評価レポートをS3へ出力（任意）

評価レポートは1-2で作成したS3へCSV形式で保存することも可能です。「Export results」プルダウンを押下し、「Export to CSV」ボタンを押下してください。

6. ソースデータベースのソースコードを変換

それでは、アクションアイテムを確認してみましょう。

今回はワークショップの手順（こちら）に則り、ソースデータベース（dms_sample）> dba > Procedures > generate_ticketsのアクションアイテムのみ確認していきます。

generate_ticketsは「Schema」に該当します。評価レポートの通り、Schemaは全て薄紫色で評価されている＝手動での変換は不要であるため、ここでは変換内容の確認のみ行います。

さて、generate_ticketsファイルを押下し、さらにアクションアイテムを選択すると、アクションが必要な箇所が黄色くハイライト表示されていますね。

次に、「dms_sample」を選択した状態で、Actionsから「Convert」を選択・押下します。

これで、ターゲットデータベース仕様に変換されたDDL（SQLスクリプト）が生成されました！
右側のターゲット側SQLを見ると、ハイライト箇所がPostgreSQL構文へ変換されています。

「Convert」はあくまでターゲットデータベース用のスキーマを生成しているのみであり、データベースへ適用するのは次のステップとなります。

DDLをS3へ出力（任意）

DDLも評価レポート同様、S3へ出力が可能です。
ターゲットデータベース側で「dms_sample_dbo」を選択し、Actionsから「Save as SQL」を選択・押下します。

7. ターゲットデータベースへ変換済みコードを適用

最後に、DDLをターゲットデータベースに適用し、スキーマ変換を完了させましょう。

ターゲットデータベース側で「dms_sample_dbo」を選択し、Actionsから「Apply changes」を選択・押下します。

Success表示が出れば、スキーマ変換は完了です！
お疲れ様でした！🎉

まとめ

いかがでしたでしょうか。
以前SCT, DMSを利用して移行した際、ただでさえスキーマの手動変換が大変なので、少しでも工数を減らせないかと感じていました。一部機能は制限されますが、オンプレミスへのインストールを始め手順が一部簡略化されるので、前提条件や制限事項さえ満たせば非常に便利な機能ではないかと思います。

ぜひみなさんも試してみてくださいね！

DMS スキーマ変換によるデータベーススキーマの変換
DMS スキーマ変換によるデータベーススキーマの変換
AUTHOR
koma
koma
エンジニア
元々製薬業界で働いており、スクールを経てDWSに入社。主にgolangを使用したバックエンド業務に携わっているが、触ったことのない技術にも楽しく挑戦していきたいと考えている。趣味はスキューバダイビング。
記事URLをコピーしました