Oracle データベースから Amazon Aurora PostgreSQL データベースへの移行の概要

この記事では、Oracle データベースから Amazon Aurora PostgreSQL データベースへの移行プロセスのデモを行うために、リソースをデプロイする AWS CloudFormation スタックを構築します。これは異種間移行であるため、How to Migrate Your Oracle Database to PostgreSQL で詳しく説明されているものと同様の 2 フェーズのアプローチに従います。

この記事は、AWS Schema Conversion Tool (AWS SCT) と AWS Data Migration Service (AWS DMS) の中核的な概念をより良く理解するために役立つ移行スタックの構築に焦点を当てます。また、データベースパラメータグループを使用して、移行のためにターゲットの Amazon Aurora PostgreSQL データベースでトリガーを無効化する方法についても説明します。

今回は、AWS DMS で Oracle データベース (HRDATA) が事前にインストールされた Amazon EC2 インスタンス、Amazon Aurora PostgreSQL クラスター、およびレプリケーションインスタンスをデプロイするために AWS CloudFormation を使用します。移行プロセスに役立てるため、Amazon Virtual Private Cloud (Amazon VPC)、Amazon Simple Storage Service (Amazon S3)、および AWS Identity and Access Management (IAM) のロールとポリシーなどのその他の必要なコンポーネントも使用します。

考慮事項

移行用のコンポーネントの構築を開始する前に、以下の要点に注意してください。

変換中、AWS SCT はターゲットの Aurora PostgreSQL データベースでスキーマを大文字に変換します。Aurora PostgreSQL エンジンは大文字と小文字を区別するので、移行ステップでは変換ルールを使用します。
一括ロードのために、ターゲットの Aurora PostgreSQL データベースですべてのトリガーを無効化する必要があります。無効化しなければ、外部キー違反のために一括ロードが失敗します。この記事では、データベースパラメーターグループを使用して、replica に session_replication_role パラメーターを設定することによって無効化する方法を説明します。このアクションは、すべてのトリガーを無効化します。Aurora クラスターの作成中、AWS CloudFormation スタックが必要に応じて DBParameterGroup リソースを設定します。一括ロードの完了後に session_replication_role パラメーターを元の値に変更して、ターゲットデータベースでトリガーを再度有効化することが理想的です。

注意: 外部キーチェックが無効化されている間 (例えば、AWS DMS 移行全体) にターゲットデータベースで DDL 文を実行しないでください。実行すると、データディクショナリーが破損する場合があります。

以下のコードスニペットは、データベースパラメーターグループ用の AWS CloudFormation スクリプトからのものです。

"RDSDBParameterGroup": {
            "Type": "AWS::RDS::DBParameterGroup",
            "Properties": {
                "Description": "CloudFormation Sample Aurora Postgresql Instance Parameter Group",
                "Family": "aurora-postgresql9.6",
                "Parameters": {
                    "session_replication_role": "replica"
                }
            }

セクション 1: AWS CloudFormation を使用して移行に必要なリソースをデプロイする

注意: スクリプトは、オレゴン (us-west-2) およびオハイオ (us-east-2) の各リージョンのみで機能します。

前提条件

移行を開始するために、以下を実行してください。

AWS SCT をダウンロードしてインストールする。
Oracle および Aurora PostgreSQL のデータベースドライバをダウンロードする。
AWS Schema Conversion Tool のインストール、検証、および更新についての手順に従って AWS SCT グローバル設定を設定する。
US West-2 (オレゴン) または US East-2 (オハイオ) リージョンで使用する Amazon EC2 のキーペアを確認する。キーはリージョン固有です。キーペアがない場合は、Amazon EC2 のキーペアを作成してください。
コンソールで Identity and Access Management (IAM) に移動します。[ロール] で、dms-vpc-role という名前のロールがあるかどうかをチェックします。これは、AWS DMS のタスクをプログラム的に起動するために必要な API/AWS CLI 固有のロールです。このロールがない場合は、AWS CloudFormation がこのロールを作成できるように、この記事の AWS CloudFormation の起動セクションで DMSVPCRoleExists の exists パラメーターに no を選択してください。

スタックを起動する

注意: ストックによってデプロイされるリソースには、使用中に料金が発生するものがあります。

AWS CloudFormation テンプレートのデプロイを開始するには、以下の手順を実行します。

[Launch Stack] を選択します。このボタンは、お使いの AWS アカウントで、起動するテンプレートを使って自動的に AWS CloudFormation サービスを開始します。必要に応じて、サインインするプロンプトが表示されます。
スタックの作成には、オハイオ (us-east-2) またはオレゴン (us-west-2) リージョンを選択するようにしてください。その後、[次へ] を選択します。
DMSVPCRoleExists パラメーターには、前提条件のステップ 5 に基づいて yes または no を選択してください。注意: 以前アカウントで AWS DMS を使用したことがある場合は、dms-vpc-role はすでに IAM で作成されています。ロールがすでに存在することによって AWS CloudFormation スタックが失敗することを避けるため、DMSVPCRoleExists の入力パラメーターには yes を選択してください。それ以外の場合は、デフォルトの no のままにしておきます。
MyIP パラメーターについては、デフォルトの 0.0.0.0/0 がポート 1521 (Oracle 用)、およびオープンアクセスのためのポート 5432 を許可します。このため、スタックの起動元となるマシンのパブリック IP の使用が強く推奨されます。(IP は org を使ってチェックできます。)
EC2 インスタンスのキーペアを指定し、必要の応じて他のパラメーターも指定します。すべてのパラメーターが必須ですが、ほとんどのパラメータにデフォルト値が設定されています。その後、[次へ] を選択します。
[確認] ページで、スタックを起動する結果として AWS CloudFormation が IAM ロールを作成することを承認します。[作成] を選択します。
スタック作成の進捗状況を確認するには、[更新] を選択します。次に、スタックを選択して、下にある [イベント] セクションで起動イベントを表示します。スタック作成には、完了までに 7～10 分かかります。スタックが正常に起動されたら、[状況] が CREATE_IN_PROGRESS から CREATE_COMPLETE に変わります。[出力] タブには、AWS CloudFormation によってデプロイされたリソースに関する情報が記載されています。これらのリソースは、この記事で後ほど必要になります。参照しやすくするために、これらの値をファイルにコピーできます。この時点で、Aurora PostgreSQL データベースのパラメーターグループの設定をオプションでチェックすることができます。
AWS マネジメントコンソールにサインインして、Amazon Relational Database Service (Amazon RDS) を開きます。左にあるナビゲーションペインで、[パラメータグループ] を選択します。次に、以下にあるように、AWS CloudFormation スタックによって作成されたインスタンスのパラメーターグループ (DB クラスターのパラメーターグループではありません) を選択します。
検索ボックスに、session_replication_role と入力します。そのパラメーターの値には、replica が表示されます。

セクション 2: AWS SCT を使用してソースデータベースのスキーマを変換する

このセクションを実行するには、前提条件 セクションにあるように、AWS Schema Conversion Tool (AWS SCT) をインストールする必要があります。AWS SCT には、AWS CloudFormation によってデプロイされたリソースに接続するためのインターネットへのアクセスが必要です。

AWS SCT を起動します。
[File]、[New Project Wizard] と選択します。
ウィザードで、プロジェクトの名前を入力します。ソースとして [Oracle] を選択し、[Next] を選択します。
Oracle データベースの接続情報を入力します。このステップで必要なパラメーターはすべて、先ほどデプロイした AWS CloudFormation スタックの [出力] に記載されています。[Test Connection] を選択して、AWS SCT が Oracle ソースに正常に接続できることを確認します。その後、[次へ] を選択します。
移行するスキーマとして [HRDATA] を選択して、[Next] を選択します。
次に、データベース移行アセスメントレポートが表示されます。このレポートは、異なるターゲットデータベースエンジンに関する移行の課題に対する洞察を提供します。これは、課題を理解して、この移行に最適なターゲットデータベースを選択するために役立ちます。この記事では、ターゲットエンジンとして Aurora PostgreSQL を使用しています。レポートは、必要に応じてダウンロードできます。[Next] を選択します。
[Target] セクションで、サーバー名に Aurora PostgreSQL クラスターエンドポイントを入力します。ポートとして 5432 を指定し、AWS CloudFormation スタックによってプロビジョニングされた Aurora クラスターのユーザー名とパスワードを入力します。
[Test Connection] を選択して、AWS SCT が Aurora PostgreSQL ターゲットに正常に接続できることを確認します。[Finish] を選択します。ウィザードが終了すると、2 つのペインがあるメインビューが表示されます。左のペインはソースの Oracle DB で、右のペインはターゲットの Aurora PostgreSQL DB です。より具体的で詳細なアセスメントレポートを生成するには、ソースで [HRDATA] スキーマのコンテキスト (右クリック) メニューを開き、[Create Report] を選択します。このレポートは、データベース管理者 (DBA) が、正常な移行のためにターゲットでスキーマの不一致を解決するために役立つ Action Items (アクションアイテム) を提供します。例えば、ソースパネルで [Views] を選択してから、[EMP_DETAILS_VIEW] を選択します。ターゲットデータベースでの EMP_DETAILS_VIEW の自動作成中における問題を解決するためのアクションアイテムが 2　つあります。AWS SCT は、ソースデータベースからのスキーマ、関数、およびストアドプロシージャをターゲット用に変換することによって支援し、アクションアイテムを提供する強力なツールです。この記事の対象範囲では、データベースがシンプルで、実施する必要がある重要なアクションはありません。
ソースの Oracle データベースで [HRDATA] スキーマのコンテキスト (右クリック) メニューを開き、[Convert Schema] を選択します。HRDATA スキーマが、ターゲットの Aurora MySQL データベースで作成されます。ターゲットにそれらのオブジェクトがすでに存在しており、置き換えられる場合があるという警告が表示されます。[Yes] を選択して続行します。
ターゲットの Aurora PostgreSQL データベースのペインで、HRDATA のコンテキスト (右クリック) メニューを開き、[Apply to database] を選択します。

これで、AWS SCT をうまく利用してデータベース移行アセスメントレポートを生成し、ターゲットの Aurora PostgreSQL データベースに HRDATA スキーマを記述することができました。

AWS SCT は、ソースデータベーススキーマとカスタムコードの大半を、ターゲットデータベースとの互換性があるフォーマットに自動的に変換します。このツールが自動で変換できないコードは、独自に変更できるように明確に表示されています。最良の結果を得るために、変換されたスキーマを SQL スクリプトとしてファイルに保存して、ターゲットデータベースの専門家と共に変換されたスキーマを見直してください。スキーマは、データ移行を続行する前に見直して、ターゲットデータベース向けに最適化する必要があります。

この記事では、ターゲットデータベースオブジェクトの最適化ステップは説明しておらず、AWS SCT でソースからターゲットへのシンプルな変換を行いました。

これで、データ移行を続行することができるようになりました。

セクション 3: AWS DMS を使用してデータをターゲットデータベースに移行する

このセクションでは、AWS DMS を使用して Oracle から Amazon Aurora PostgreSQL への一括ロードを行います。現在、Amazon Aurora、Amazon Redshift、または Amazon DynamoDB への移行の場合には、1 インスタンスごとに AWS DMS を 6 ヵ月無料で利用することができます。

AWS マネジメントコンソールにサインインして AWS DMS コンソールを開きます。
リージョンが、セクション 2 の AWS CloudFormation スタックのデプロイ先と同じリージョン (us-east-2 または us-west-2) であることを確認してください。
左のナビゲーションペインで [レプリケーションインスタンス] を選択します。AWS CloudFormation スタックによって新しいレプリケーションインスタンスがすでに作成されていることがわかります。レプリケーションインスタンスの Virtual Private Cloud (VPC) に注目してください。これは、AWS CloudFormation スタックがこの記事のために作成した VPC と同じものです。
左のナビゲーションパネルで [エンドポイント] を選択します。
[エンドポイントの作成] を選択します。
[エンドポイントの作成] ページで、[ソース] を選択し、Oracle ソースデータベースに関する必要な情報を入力します。このステップを完了するために必要な情報は、AWS CloudFormation の [出力] セクションにあります。[エンドポイント接続のテスト] セクションで、AWS CloudFormation スタックによって作成された VPC レプリケーションインスタンスを選択します。テストが正常に完了することを確認してから、[エンドポイントの作成] を選択してエンドポイントの詳細を保存します。注意: エンドポイントのテストステップは省略しないでください。これは、AWS DMS にスキーマを更新するために必要なエンドポイントへの接続があることを確認するために役立ちます。
同様に、[エンドポイントの作成] ページで [ターゲット] を選択し、Aurora PostgreSQL ターゲットデータベースに関する必要な情報を入力します。Aurora PostgreSQL のクラスターエンドポイント、ポート、ユーザー名、パスワード、およびデータベース名を入力します。
[エンドポイント接続のテスト] セクションで、AWS CloudFormation スタックによって作成された AWS DMS レプリケーションインスタンスを選択します。テストが正常に完了することを確認してから、[エンドポイントの作成] を選択してエンドポイントの詳細を保存します。注意: エンドポイントのテストステップは省略しないでください。これは、AWS DMS にエンドポイントへの必要な接続があることを確認するために役立ちます。このステップを完了するために必要な情報は、AWS CloudFormation の [出力] セクションにあります。
左のナビゲーションペインで [タスク] を選択してから、[タスクの作成] を選択します。
[タスク設定] で以下を実行します。
1. AWS CloudFormation スタックによって作成されたレプリケーションインスタンスを選択する。
2. ソースとして Oracle エンドポイントを選択する。
3. ターゲットとして Aurora PostgreSQL エンドポイントを選択する。
4. [移行タイプ] に [既存のデータを移行する] を選択する。このオプションを選択すると、変更データキャプチャ (CDC) なしで一括ロードを実行することが可能になります。他のオプションを選択することもできますが、CDC を許可するためにサプリメンタルロギングを有効にする必要があります。詳細については、「AWS DMS のソースとしての Oracle データベースの使用」を参照してください。
5. [作成時にタスクを開始] チェックボックスにチェックを入れて、タスクが作成されると同時にロードが開始されるようにします。
6. [ターゲットテーブル作成モード] には、[何もしない] を選択します。すでに AWS SCT を使用してスキーマを変換しているからです。
7. [検証の有効化] を選択し、ソースの各行を対応するターゲットの行と比較して、これらの行に同じデータが含まれていることを確認します。
8. オプションとして、[ロギングの有効化] を選択して、必要に応じて分析を行うためにタスクを CloudWatch にログします。
9. [テーブルマッピング] セクションで、移行するソースの HRDATA スキーマを選択します。[テーブル名] オプションでは、スキーマ内のすべてのテーブルに % ワイルドカードを使用します。[選択ルールの追加] を選択してテーブルマッピングルールを追加します。
10. 選択ルールを追加したら、2 つの変換ルールを追加します。
  1. 最初のルールは、スキーマ名「HRDATA」を大文字から小文字に変えるルールです。このステップは、Aurora PostgreSQL エンジンが大文字と小文字を区別する、および AWS SCT がスキーマ変換中にスキーマとテーブルを大文字で作成するために必要となるステップです。[変換ルールの追加] を選択して、タスクにルールを追加します。
  2. 2 番目のルールは、HRDATA スキーマのテーブル名を大文字から小文字に変更するルールです。[変換ルールの追加] を選択してタスクにルールを追加します。選択ルールと変換ルールを追加したら、[テーブルマッピング] セクションは以下のようになります。
11. [タスクの作成] を選択して続行します。タスクが作成されたら、ソースからターゲットデータベースへのデータのロードが自動的に開始されます。
タスクを選択し、下にあるプロパティペインで [テーブル統計] タブを選択して、進捗状況を表示します。検証状態が検証保留中から検証済みに変わるはずです。また、[合計] 数と [行の全ロード] が一致することも確認してください。

オプションとして、pgAdmin などの PostgreSQL クライアントを使用して Aurora PostgreSQL で移行の結果をチェックすることもできます。

AWS CloudFormation スタックの出力で提供された Aurora PostgreSQL 接続情報を使って、SQL クライアントで接続を確立します。

この時点で、Oracle から Amazon Aurora PostgreSQL データベースにデータが正常に移行されています。

クリーンアップ手順

このセクションでは、この記事の一環としてデプロイされた AWS リソースを削除するクリーンアップタスクを実行します。リソースを引き続き実行することもできますが、リソースが実行されている間は料金が発生し続けることに注意してください。

以下の手順に従って、作成されたリソースを削除します。

コンソールで AWS DMS を開きます。左のナビゲーションペインで [タスク] を選択します。先ほどセクション 3 で作成したタスクを選択して、[削除] を選択します。
タスクが削除されたら、左のナビゲーションペインで [エンドポイント] を選択します。先ほどセクション 2 で作成した Oracle のソースエンドポイントと Aurora PostgreSQL のターゲットエンドポイントを削除します。
コンソールで AWS CloudFormation を開きます。セクション 1 で作成したスタックを選択して、[スタックの削除] を選択します。

削除プロセスは、完了まで 5～10 分かかります。スタックが作成したすべてのリソースが削除されます。状況には [DELETE_IN_PROGRESS] が表示されます。削除が正常に行われたら、スタックリストにそのスタックが表示されなくなります。

この時点で、この記事の一環としてデプロイされたすべてのリソースが正常に削除されています。

結論

この記事では、AWS での異種間データベース移行の主な手順を詳しく説明しました。今回は、AWS Schema Conversion Tool と AWS Database Migration Service を使用した Oracle から Amazon Aurora PostgreSQL への移行に焦点を当てました。AWS CloudFormation スクリプトをカスタマイズして、他のデータベースエンジンタイプを簡単にデプロイし、その他の移行をテストすることもできます。

今回のブログ投稿者について

Sona Rajamani は AWS のソリューションアーキテクトです。 サンフランシスコのベイエリアに暮らしながら、AWS 上でアプリケーションを設計し最適化できるようお客様をサポートしています。仕事以外では、ハイキングや旅行が趣味です。

Ballu Singh は AWS のソリューションアーキテクトです。サンフランシスコのベイエリアに住んでおり、お客様が AWS でアプリケーションを設計し最適化するサポートを行っています。余暇には、彼は読書、家族との時間を楽しんでいます。

Amazon Web Services ブログ