顧客フロントSEのIT勉強ブログ

2022 Japan AWS Top Engineer / 2022-23 Japan AWS Certifications Engineer。AWS認定12冠、情報処理試験全冠。顧客フロントSEがなるべく手を動かしながらIT技術を学んでいくブログです。

トップ > AWS勉強-ハンズオン > AWSデータベース移行（SCT＋DMS）ハンズオンを試してみた

AWSデータベース移行（SCT＋DMS）ハンズオンを試してみた

AWS勉強-ハンズオン AWS勉強

f:id:se_o_chan:20220214003139p:plain

以前AWS MGNによるサーバ移行ハンズオンを試しましたが、今回はデータベース移行ハンズオンです。

サーバとデータベースを押さえておけば、オンプレミスサーバ群の大半をAWSへ移行できるのではないでしょうか！？

データベース移行には対象のDBMSによっていくつか方式がありますが、今回はSCT＋DMSを取り上げます。これらを使ったことがない人が大まかな設定・作業の流れを理解できるよう噛み砕いて説明します。

AWS SCT、DMSとは

AWS SCTとはSchema Conversion Toolの略称で、異なるDBMS間でデータベーススキーマやコード（ビュー、ストアドプロシージャ、ファンクションなど）の大部分を自動的に変換し移行してくれるツールです。ローカルPCにインストールして使用します。

AWS DMSとはDatabase Migration Toolの略称で、異なるDBMS間（同種でもOK）でデータそのものを移行できるサービスです。こちらはAWSマネジメントコンソールから使用するWebサービスです。
Migrationと名前はついていますが、検証目的でのデータレプリケーションや遠隔地バックアップなどにも活用できるサービスです。

異なるDBMS間で移行を行う際、まずSCTでテーブル定義などのメタデータやストアドプロシージャなどのコードを移行し、その後にDMSでデータ移行を行うというステップが定石です。

ちなみに、以前サーバ移行ハンズオンでAWS MGNを試してみたときの記事は下記です。
ご興味あればこちらもご参照ください。

データベース移行ハンズオンの構成

データベース移行ハンズオンは下記で提供されています。

MGN同様、日本語で提供されていますがこちらも「DMS ハンズオン」などでググってもヒットしないので、URL自体を知っていないとたどり着けないかもしれません。

大きく３つのシナリオが用意されています。

  1. OracleからAmazon RDS for Oracleへの移行
  2. SQL ServerからAmazon RDS for SQL Serverへの移行
  3. OracleからAmazon RDS for PostgreSQLへの移行

今回はこのうち「3. OracleからAmazon RDS for PostgreSQLへの移行」を取り上げます。
ちなみに1、2はData PumpやDBネイティブの方法での移行方式が紹介されています。

ステップ１．ハンズオン環境を準備する

本来はオンプレOracleをAWS RDS for PostgreSQLに移行するところですが、ハンズオンでは下記図のようにRDS for Oracleからの移行で代替します。

01

（出典）データベース移行ハンズオン

あらかじめEC2コンソールからキーペアを作成し、pemファイルをダウンロードしておきます。ここでは「DMSHandson58」というキーペアを作りました。

f:id:se_o_chan:20220207232022p:plain

つぎにCloudFormationから必要リソースを作成します。
テンプレートはこちらからダウンロードできます。

テンプレートで指定しているWindows ServerのAMIが存在しなくなっていたので、良きAMIに変更してください。私はami-03d018a89c276f9f7を利用しました。

f:id:se_o_chan:20220207234110p:plain

スタックの名前は「DMSHandson58」としました。
Keynameには作成したキーペアを選択してください（これを使ってEC2インスタンスが作成されます）。
PrimaryAZは「ap-northeast-1a」、SecondaryAZは「ap-northeast-1c」とし、
UniqueNoには「58」を入れました。

このUniqueNoはVPCの第二オクテッドになるため、もし既存で10.58.0.0/16のIPレンジを使用している場合は別の数字を指定してください。

f:id:se_o_chan:20220207232356p:plain

CloudFormationのスタック作成が成功したら、DMSHandson58という名前のEC2インスタンスが1台起動されているので、キーペアのpemファイルを使ってAdministratorのパスワードを復号化し、リモートデスクトップ接続でログインしてください。

ステップ２．SCTを体験する

RDS for Oracleにログイン

このハンズオンではDBeaverというクライアントツールがEC2にプレインストールされているはずなのですが、CloudFormationのテンプレートで指定されているAMIが使えなかったので、仕方なく手動でDBeaverをインストールします。

「Windows 64 bit (installer)」からインストーラをダウンロードし、EC2インスタンスにリモートデスクトップ接続経由でコピペするなどしてインストーラを配置し、インストールしてください。

インストールできたらDBeaverを起動してください。今回はRDS for Oracleに接続したいので「Oracle」を選択します。

f:id:se_o_chan:20220208000239p:plain

面倒なことにOracleドライバの設定が必要です。
Mavenリポジトリからドライバをダウンロードし、EC2インスタンスに配置します。

https://maven.xwiki.org/externals/com/oracle/jdbc/ojdbc8/12.2.0.1/ojdbc8-12.2.0.1.jar

下記DBeaver画面の右下「ドライバの設定を編集」から「ライブラリ」タブを選択し、元々のライブラリパスをすべて削除し、上で配置したOracleドライバのパスを追加します。

f:id:se_o_chan:20220208001007p:plain

f:id:se_o_chan:20220208001402p:plain

この状態でRDS for Oracleの接続情報を入力すると繋がるようになります。

  • Host：RDSエンドポイント
  • Port：1521
  • Database：handson
  • User Name：scott
  • Password：tigertiger

サプリメンタルログの設定

DMSでOracleデータを継続的レプリケーション（差分データもほぼリアルタイムに同期）する場合、Oracleにサプリメンタルログを有効化する必要があります。

サプリメンタルログとは、OracleのREDOログに追加の情報を記録する機能です。これにより異種DBMS間でも、更新された行を一意に特定できるようになります。

DBeaverからSQLエディタを開き、下記コマンドを実行します。
これにより最小サプリメンタル・ロギングが使用可能になり、主キーを持つ表が更新されるたびにREDOログに主キー列が書き込まれます。

call rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');
call rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','PRIMARY KEY');

※このコマンドはRDSのユーティリティです。オンプレOracleに対しては下記サイトを参考になると思うので、こちらを参照しつつ有効化してください。

次のクエリを実行し両カラムともYESと表示されたらサプリメンタルロギングは有効になっています。

select supplemental_log_data_min, supplemental_log_data_pk from v$database;

f:id:se_o_chan:20220208002332p:plain

移行対象のテーブルの内、MLB_DATA 、NFL_DATA、NFL_STADIUM_DATAはプライマリーキーが指定されていないため、以下のSQLで全列をREDOログに書き込むよう設定します。

alter table dms_sample.mlb_data add supplemental log data (ALL) columns;
alter table dms_sample.nfl_data add supplemental log data (ALL) columns;
alter table dms_sample.nfl_stadium_data add supplemental log data (ALL) columns;

DMSの継続的レプリケーションには、アーカイブログモードも有効になっていることが必要です。
下記コマンドで有効になっていることを確認します。「ARCHIVELOG」と表示されたら有効になっています。

select log_mode from v$database;

RDS for PostgreSQLにログイン

Oracle接続の時と同様、Postgreドライバをダウンロードし、EC2インスタンスに配置します。

https://repo1.maven.org/maven2/org/postgresql/postgresql/42.2.22/postgresql-42.2.22.jar
https://repo1.maven.org/maven2/net/postgis/postgis-jdbc/2.5.0/postgis-jdbc-2.5.0.jar
https://repo1.maven.org/maven2/net/postgis/postgis-jdbc-jtsparser/2.5.0/postgis-jdbc-jtsparser-2.5.0.jar

「新しい接続」からPostgreSQLを選択し、Oracleの時と同じように「ドライバの設定を編集」から「ライブラリ」タブに切替えます。元々のライブラリパスをすべて削除し、上で配置したPostgreSQLドライバのパスを追加します。

f:id:se_o_chan:20220208004334p:plain

この状態でRDS for PostreSQLの接続情報を入力すると繋がるようになります。

  • Host：RDSエンドポイント
  • Port：5432
  • Database：handson
  • User Name：scott
  • Password：tigertiger

SCTをインストール

こちらのSCTユーザーガイドからSCTのインストーラをダウンロードします。
zipファイル内にmsiファイルが入っているので、そちらを実行するとインストールが開始されます。特に設定項目はありません。

インストールが完了すると、Windowsスタートメニューの中にあるはずです。

f:id:se_o_chan:20220213221857p:plain

SCTでProject Wizerdを実行

SCTを開くと「Create a new database migration project」ダイアログが表示されます。

「Step1. Choose a source」では下記を入力・選択してNextボタンをクリックします。

  • Project Name：DMSHandson
  • Location：C:\Users\Administrator\AWS Schema Conversion Tool\Projects
  • SQL Database
  • Source database engine：Oracle
  • I want to switch engines and optimize for the cloudにチェック

f:id:se_o_chan:20220213223055p:plain

「Step2. Connect to the source database」では下記を入力・選択してTest Conectionボタンをクリックします。
SSL接続していないことでalermが出ますが、無視して「Accept the risk and continue」を押します。

  • Connection name：Source Oracle
  • Type：SID
  • Server name：RDSのエンドポイント
  • Server port：1521
  • Oracle SID：handson
  • User name：scott
  • Password：tigertiger
  • User SSL：off
  • Store Password：off
  • Oracle driver path：DBeaverログイン時にインストールしたJDBCを指定

f:id:se_o_chan:20220213223350p:plain

正常に接続できると「Next」ボタンが押せるようになります。

「Step3. Choose a schema」ではDMS_SAMPLEスキーマを選択してNextボタンをクリックします。

f:id:se_o_chan:20220213223731p:plain

「Step4. Run the database migration assement」で移行アセスメントレポートが表示されます。レポートはPDFやCSVに出力でき、DBエンジンを変更する際にSCTでは自動変換できないオブジェクトと対応方法を明示してくれています。
このハンズオンではレポート内容を詳細に確認していませんが、ここではPDFの内容を少し触れておきます。

f:id:se_o_chan:20220213224257p:plain

まずExcecutive summaryではTaget Platform毎に、自動・軽微な作業でスキーマ変更可能なオブジェクトと複雑な作業が必要なオブジェクトに仕分けてくれます。
大体Code object（ProcedureやPackege、Viewなど）が引っかかっていますね。

f:id:se_o_chan:20220213224745p:plain

f:id:se_o_chan:20220213224829p:plain

具体的に何のオブジェクトにどのような作業が必要なのか、明細情報も提示してくれ得ちます。上記例では「HINTS句が自動変換できないよ！」と指摘されているようですね。

最後に「Step5. Choose a target」で下記を入力・選択してTest Conectionボタンをクリックします。正常に接続できればFinishボタンが押せるようになります。

  • Target Database Engine：Amazon RDS for PostgreSQL
  • Connection name：Target PostgeSQL
  • Server name：RDSのエンドポイント
  • Server port：5432
  • Database：handson
  • User name：scott
  • Password：tigertiger
  • Use SSL：off
  • Store password：off
  • PostgreSQL driver path：DBeaverログイン時にインストールしたJDBCを指定

f:id:se_o_chan:20220213225521p:plain

SCTのメイン画面が表示されます。

SCTでスキーマ変換

「Source Oracle > Schema > DMS_SAMPLE > Table >MLB_DATA」を右クリックして「Convert schema」を選択します。

f:id:se_o_chan:20220213230357p:plain

右ペインのTarger PostgerSQL内にmlb_dataテーブルが増えています。
また、下ペインには移行元・先の各DBにおけるテーブルDDLが表示されています。
オブジェクト名が小文字になっていたり、NUMBER型がDOUBLE PRECISION型に変換されていますね。

f:id:se_o_chan:20220213230704p:plain

動きが確認出来たら「Source Oracle > Schema > DMS_SAMPLE」を右クリックして、スキーマ全体を変換します。同じく「Convert schema」を選択すると右ペインに各種テーブル名やProcedure名が増えています。

が、この時点ではまだTargetに各オブジェクトは登録されていません。DBeaverで見てみると下記のようにまだdms_sampleスキーマもテーブルもないはずです。

f:id:se_o_chan:20220213231323p:plain

ここまではまだ変換内容の確認中ステータスなんですね。変換内容を手動変更することもできます（アラームが出ているオブジェクトもありますが、今回はなにも手動変更することなく先に進みます）。
SCTに戻って、右ペインのTarget側でdms_sampleスキーマを右クリックして「Apply to database」を選択して初めてオブジェクトが登録されます。

f:id:se_o_chan:20220213232016p:plain

DBeaverを更新するとdms_sampleスキーマ内に各種テーブル定義ができています。これでSCTによるスキーマ変換は完了です。

f:id:se_o_chan:20220213232403p:plain

この後のDMSによるデータ移行時に性能悪化するため、一旦外部キーの定義を外しておきます。※実際の移行時も可能なら一度外部キーは外しておきたいですね。

alter table dms_sample.player drop constraint sport_team_fk;
alter table dms_sample.sport_league drop constraint sl_sport_type_fk;
alter table dms_sample.sport_team drop constraint home_field_fk;
alter table dms_sample.sport_team drop constraint st_sport_type_fk;
alter table dms_sample.seat drop constraint seat_type_fk;
alter table dms_sample.sporting_event drop constraint se_away_team_id_fk;
alter table dms_sample.sporting_event drop constraint se_home_team_id_fk;
alter table dms_sample.sporting_event drop constraint se_sport_type_fk;
alter table dms_sample.sporting_event_ticket drop constraint set_seat_fk;
alter table dms_sample.sporting_event_ticket drop constraint set_sporting_event_fk;
alter table dms_sample.sporting_event_ticket drop constraint set_person_id;
alter table dms_sample.sport_division drop constraint sd_sport_league_fk;
alter table dms_sample.sport_division drop constraint sd_sport_type_fk;
alter table dms_sample.ticket_purchase_hist drop constraint tph_sport_event_tic_id;
alter table dms_sample.ticket_purchase_hist drop constraint tph_ticketholder_id;
alter table dms_sample.ticket_purchase_hist drop constraint tph_transfer_from_id;

ステップ３．DMSを体験する

DMSレプリケーションインスタンスのセットアップ

ここからはDMSによるデータ移行を進めていきます。
まずはDMSのレプリケーションインスタンスをセットアップします。

AWSマネジメントコンソールから東京リージョンのDMSを開き、「レプリケーションインスタンスの作成」ボタンをクリックします。

f:id:se_o_chan:20220213233530p:plain

次のように入力・選択し、レプリケーションインスタンスを作成します。

  • 名前：dmshandson58
  • 説明：Instance for DMS hands-on
  • インスタンスクラス：dms.r5.large
  • レプリケーションエンジンのバージョン：3.4.6
  • VPC：DMSHandson58
  • マルチAZ：開発またはテストワークロード（シングルAZ）
  • パブリックアクセス可能：off
  • アベイラビリティーゾーン：ap-northeast-1a
  • VPCセキュリティグループ：default

f:id:se_o_chan:20220213234042p:plain

DMSエンドポイントのセットアップ

DMS画面の左ペインから「エンドポイント」を選択して「エンドポイントの作成」ボタンをクリックします。

次のように入力・選択し、まずはソースエンドポイントを作成します。

  • エンドポイントタイプ：ソースエンドポイント
  • RDS DBインスタンスの選択：on
  • RDSインスタンス：dmshandson58oracle
  • エンドポイントデータベースへのアクセス：アクセス情報を手動で提供する
  • パスワード：tigertiger

もう一度「エンドポイントの作成」から、次はターゲットエンドポイントを作成します。

  • エンドポイントタイプ：ターゲットエンドポイント
  • RDS DBインスタンスの選択：on
  • RDSインスタンス：dmshandson58postgres
  • エンドポイントデータベースへのアクセス：アクセス情報を手動で提供する
  • パスワード：tigertiger

f:id:se_o_chan:20220213234745p:plain

DMSタスクのセットアップとフルロード

DMS画面の左ペインから「データベース移行タスク」を選択して「タスクの作成」ボタンをクリックします。

次のように入力・選択し、移行タスクを作成します。

  • タスク識別子：oracle58-postgres58
  • レプリケーションインスタンス：dmshandson58
  • ソースデータベースエンドポイント：dmshanson58oracle
  • ターゲットデータベースエンドポイント：dmshandson58postgres
  • 移行タイプ：既存のデータを移行して、継続的な変更をレプリケート
  • 作成時にタスクを開始：on
  • CDC停止モード：カスタムCDC停止モードを無効にする
  • ターゲットDBで復旧テーブルを作成：off
  • ターゲットテーブル作成モード：何もしない
  • フルロードの完了後にタスクを停止する：停止しない
  • レプリケーションにLOB列を含める：制限付きLOBモード
  • 最大LOBサイズ(KB)：32
  • 検証の有効化：on
  • CloudWatchログを有効化：on

途中、テーブルマッピングで選択ルールから「新しい選択ルールの追加」から以下のように入力します。

f:id:se_o_chan:20220213235552p:plain


次に変換ルールとして次の3つを追加します。これはPostgreSQLではスキーマ、オブジェクト名等のデフォルトが小文字であることへの対応です。

「タスクの作成」ボタンを押すとフルロードが開始されます。

oracle58-portgres58タスクの「テーブル統計」タブを表示し、ロード状態：Table completed、検証状態：Validatedになればフルロード完了です。

f:id:se_o_chan:20220214000624p:plain

DMSでの継続的レプリケーション

DMSの移行タスクで継続的レプリケーションを有効にしたため、移行元のOracleで更新したデータが自動的にPostgreSQLに反映されることを確認します。

DBeaverでOracleおよびPostgreSQLに接続し、下記SQLを実行してみます（どちらも0件が返るはず）。

select count(*) from dms_sample.ticket_purchase_hist;

ソースのOracle側で次のSQLを実行します。
これはOracleのTICKET_PURCHASE_HISTテーブルにレコードをInsertし続けるプロシージャです。

call dms_sample.ticketmanagement.generateticketactivity(1, 1000);

もう一度PostgreSQLのほうでselect count(*)をしてみるとレコード件数が増えているはずです。これはOracleでInsertし続けると同時にDMSが変更差分をキャッチしてPostgreSQLに同期し続けているためです。

f:id:se_o_chan:20220214001248p:plain

これでDMSの継続的レプリケーションも確認できました。
Oracle側のプロシージャはキャンセルしておきます。
この後はハンズオンで作成した各種リソースを削除する必要がありますが、ハンズオン資料本紙に任せることとし、ここでは割愛します。

まとめ

MGNに引き続き、SCT＋DMSによるデータベース移行も試してみました。

実際はSCTで移行アセスメントレポートを表示した後の手動変換や、DMSにおける選択・変換ルールの定義に試行錯誤がありそうですが、その辺の勘所をつかめたことが子のハンズオンの収穫だったと思います。

これでオンプレからAWSの移行で使うサービスの大半を理解することができました！

PVアクセスランキング にほんブログ村ブログランキング・にほんブログ村へにほんブログ村

#AWS #DMS #SCT #ハンズオン

se_o_chan 読者になる

広告を非表示にする
読者になる
コメントを書く