AWS SCTをまとめながらAWS Database Migration Workshopをやってみた

もきゅりん

2021.01.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

おはようございます、もきゅりんです。

皆さん、AWS Schema Conversion Tool (以下 SCT) 使ってますか？

AWS Database Migration Service (以下 DMS) を触り始めると顔を出してくる SCT です。

ご存知な方も多いと思いますが、SCT とは、あるデータベースエンジンにおける既存のデータベーススキーマを、別のデータベースエンジンのスキーマに変換するツールです。

DMS の前処理として認知されている方が多いかと思います。

でも SCT を具体的にどうやって使うのか、どんなことができるのかは、あまり利用する機会もなく、環境を用意するのにもそれなりに時間がかかるため不鮮明ではないでしょうか。(自分はそうです)

上記課題感から本稿では、環境を用意してくれる AWS Database Migration Workshop で SCTを対応してみて以下まとめました。

  • SCTでできること
  • 基本的な使い方の流れ
  • 所感
  • やってみた

対象とする読者は下記です。

  • AWS Schema Conversion Tool に関心はあるけど実際に使ったことない方
  • AWS Schema Conversion Tool がどんなか雰囲気だけでも知りたい方
  • データベースのスキーマとは何か、なんとなく理解できている方

なお、これまで SCT に関係する弊社ブログは以下のようなものがあります。

SCT でできること

思っていたよりいろいろとできます。

  • ソースデータベースのデータベーススキーマをターゲットのデータベーススキーマと互換性のある形式に自動的に変換する
  • ターゲットのデータベーススキーマを作成する方法に関するガイダンスを提供する評価レポート を作成する
  • DMS と連携して大規模データを Amazon S3 または Amazon SnowballEdge デバイスにデータをコピーすることができる
  • ソースデータベースとターゲットデータベースとで互いに大きく異なっている場合などで利用できるデータ抽出エージェントを提供する
  • ソースDBにあってターゲットDBにない機能をターゲットDBで実現するための拡張パックを提供する
  • 既存の AmazonRedshift データベースを最適化できる
  • 同じDBエンジンを実行している場合、既存のオンプレミスデータベーススキーマをAmazon RDS インスタンスにコピーできる
  • C ++、C＃、Java、またはその他のアプリケーションコードのSQLコードを変換して表示、分析、編集、および保存できる
  • 既存のETLプロセスを AWS Glueに移行することができる

今直面している課題が、実は SCT で対応できるかもって気になった方は、ドキュメントで詳細を確認してみると良いかと思います。

本稿で利用するものとしては、上2つになります。

基本的なSCTの使い方

既存のリレーショナル OLTP スキーマをターゲットとなる OLTP データベースのスキーマに変換する基本的な使い方は以下になるかと考えます。

  1. 利用するデスクトップ環境にSCTをインストールする
  2. SCTのユーザーインターフェースでプロジェクトを作成する
  3. データベース移行評価(コンバージョン)レポートを作成して対応事項を確認する
  4. 変換できないアイテムの処理について検討・対応する
  5. 必要であれば、AWS SCTを使用して、SQLストアドプロシージャやその他アプリケーションコードを変換する
  6. データベーススキーマを変換する
  7. スキーマ変換をターゲットに適用する

SCTを利用できるデスクトップ環境についてはInstalling, verifying, and updating the AWS SCT - AWS Schema Conversion Tool をご確認下さい。

Database Migration Workshop で学べること

AWS Database Migration Workshop では、以下さまざまなケースでの SCT, DMS の使い方を体験することができます。

  • Microsoft SQL Server to Amazon Aurora (MySQL)
  • Microsoft SQL Server to Amazon Aurora (PostgreSQL)
  • Microsoft SQL Server to Amazon RDS for SQL Server
  • Microsfoft SQL Server to Amazon S3
  • Oracle to Amazon Aurora (PostgreSQL)
  • Oracle to Amazon RDS for Oracle

他 Workshop と同様、環境を CloudFormation で構築できます。

本稿では、 Microsoft SQL Server to Amazon Aurora (PostgreSQL) のケースにおける SCT のみに焦点を当てます。Data Migration のパートについてはスコープ外として触れません。

ms_sql_to_postgres

※ 図はワークショップからの引用

所感

この Workshop では都合上、変換に対する評価レポートで提供された手動変更箇所をほぼスルーしますが、実際にはどれくらい出てくるのかが気になるところでした。

レポートでは、これらのスキーマ項目を変換するための推定時間を次のように分類しています。

  • Simple: 1時間以内に完了することができるアクション。
  • Medium: より複雑で、1〜4時間で完了することができるアクション。
  • Complex (Significant?) : 非常に複雑で、完了するまでに4時間以上かかるアクション。

分別の色(緑、濃い緑、水色、青色)やレポートの形式は、サンプルやドキュメントとでもそれぞれ異なっています。ちょこちょこ更新されていそうです。

青色の Complex は4時間以上かかる作業と記載されていますが、このサンプルケースでは8つ出てきています。対応が必要な場合、単純計算で、最低でも32時間以上はかかりますね。(さらに、 simple な作業で16つ, Medium が1つなので、仮に1人で対応していたら1週間くらいかかりそう。)

report_result

評価レポート内容を確認して、対応するのかしないのか含めてるレビューの上、手動変換するには、前もって時間をしっかり取る必要がありそうだな、と感じました。

やってみた

以下は Workshop での SCT を使った作業になります。

Workshop 内にも画像がありますし、ご自分でやってみることを推奨しますが、(自分の備忘録として)作業フローだけまとめています。

1 利用するデスクトップ環境にSCTをインストールする

SQL Server on EC2 に SCT をインストールします。

sct_install

sct_installed

2 SCTのユーザーインターフェースを使用してプロジェクトを作成する

1 SCTのプロジェクトを作成

setup_sct_project

2 テスト接続 / 対象スキーマを選択

choose_schema

データベースに接続して対象のスキーマを読み込ませるとレポートを表示します。

3 データベース移行評価(コンバージョン)レポートを作成して必要事項を確認する

下記のように、自動的に RDS MySQL, PostgreSQL, MariaDB および Aurora MySQL, PostgreSQL のそれぞれに対する自動変換できる箇所、自動変換できない箇所についての詳細情報を記載しています。

report_summary

今回は、 Aurora PostgreSQL が対象です。

下図のように、自動変換できる箇所、自動変換ができない箇所、そして自動変換できない箇所のうち、Simple, Medium, Complex (Significant?) という区分でレポートされます。

要チェックです。

postgresql_report

レポートは、これらのスキーマ項目を変換するための推定時間を次のように分類します。 Assessment report summary - AWS Schema Conversion Tool

  • Simple: 1時間以内に完了することができるアクション。
  • Medium: より複雑で、1〜4時間で完了することができるアクション。
  • Complex (Significant?) : 非常に複雑で、完了するまでに4時間以上かかるアクション。

以下(機械翻訳)引用。

パッケージ、プロシージャ、および関数には、最もカスタムまたは独自のSQLコードが含まれているため、解決すべき問題が発生する可能性が高くなります。AWS SCTは、各オブジェクトタイプを変換するために必要な手動変更の量を指定します。また、これらのオブジェクトをターゲットスキーマに正常に適合させる方法についてのヒントも提供します。

4 ターゲットデータベースに接続する

connect_target_db

レポートのアクションアイテムを確認します。

Workshop の説明では、「図に横に赤い感嘆符が付いているアイテムは、ソースからターゲットに変換する前にレビューする必要があります。」と記載されています。

red_exclamentions

結構表示されてますね。。

5 変換できないアイテムの処理について検討・対応する

今回のケースでは、ストアドプロシージャが含まれていますが、次のいずれかのアクションで対応するようです。

  1. AWS SCTがオブジェクトをターゲットのAuroraPostgreSQLデータベースに変換できるように、ソースのSQLServerデータベースのオブジェクトを変更する。
  2. ソーススキーマを変更する代わりに、AWSSCTが生成するスクリプトがターゲットのAuroraPostgreSQLデータベースにスクリプトを適用できるように変更する。

この Workshop では、自動的に変換できなかったすべてのオブジェクトの変更を無視して、SCT内からストアドプロシージャの1つを手動で変更して、ターゲットデータベースとの互換性を持たせまることとしました。

6 SQLストアドプロシージャやその他のアプリケーションコードを変換する

赤いびっくりマークの箇所を開くと、イメージのように問題のある箇所を表示してくれているので、確認の上、変更していきます。

sct_error

確認、レビュー、必要な変更が完了したらスキーマ変換を実行します。

7 スキーマ変換をターゲットに適用する

ソースデータベースを選択してスキーマ変換を実行すると、オブジェクトがデータベースにすでに存在する可能性があるという警告が表示されますが、進めます。

convert_db

最後に、ターゲットのデータベースで対象のスキーマを選択して、データベースに適用を実行します。

img_apply

これで、データベーススキーマとオブジェクトを Microsoft SQL Server か Amazon Aurora (PostgreSQL) との互換性のある形式に変換しました。

これで DMS を実行する準備が整いました。

進め方、使い方自体は簡単ですね！

最後に

個々の環境によって設定や要件も異なってくるため、一概に同じやり方によって、うまくいく保証がないマイグレーションには不安が付きまといますが、各種マイグレーションツールの適切な使い方を知り、しっかりと前もって時間を取って、計画を準備してテストすることで不安を軽減していくことができると思いました。

あまり馴染みのない SCT を触ってどんなものか体験できて良かったです。

引き続き、実際の現場で知見を蓄積していきたいと考えています。

以上です。

どなたかのお役に立てば幸いです。

AWS