Amazon Web Services ブログ

AWS CloudFormationを使用してOracleからAmazon Aurora MySQLに移行する方法（パート1）

特に、OracleからAmazon Aurora PostgreSQL、OracleからAmazon Aurora MySQL、またはMicrosoft SQL サーバーからMySQLへの異種データベースの移行では、データベースの移行はかなり難しいです。ソース・データベースのスキーマ構造、データ・タイプ、およびデータベースのコードは、ターゲット・データベースのスキーマ構造、データ・タイプ、およびデータベース・コードとかなり異なる場合があり、データの移行が開始される前にスキーマおよびコードの変換ステップが必要です。これにより、異種データベースの移行が二段階のプロセスになります。

この2部構成の移行ブログシリーズの第1部では、AWS CloudFormationスタックを構築し、OracleデータベースからAmazon Aurora MySQLデータベースにデータを移行するプロセスを示すのに役立つリソースをデプロイします。パート2では、この記事で作成したリソースを基に、AWS Glueを使用してデータを抽出、変換、ロード（ETL）する方法を示します。

AWSには、異種の2段階移行のための AWS Schema Conversion Tool（AWS SCT）やAWSデータ移行サービス（AWS DMS）などの直感的なツールがあります。これらのツールは、移行オーバーヘッドと複雑さを軽減します。移行プロセスを最適化するためのこれらのツールおよび設定の詳細については、 「OracleデータベースをAmazon Auroraに移行する方法」をご参照ください。

図1：異種データベースの移行手順

この記事では、セルフサービスのデモンストレーションによる簡単な移行を紹介します。AWS SCTおよびAWS DMSコアの概念を理解し、なれるのに役立ちます。現在、Amazon Aurora、Amazon Redshift、または Amazon DynamoDB への移行の場合には、1 インスタンスごとに AWS DMS を 6 ヵ月無料で利用することができます。

移行プロセスを実証するため、AWS CloudFormationスクリプトを使用して、Oracleデータベース（HRDATA）が事前にインストールされたAmazon EC2インスタンス、Aurora MySQLクラスタ、およびAWS DMSレプリケーションインスタンスをデプロイします。移行プロセスに役立てるため、Amazon Virtual Private Cloud (Amazon VPC)、およびそのネットワーキング構成、Amazon S3バケット、そして AWS Identity and Access Management (IAM) のロールとポリシーなどのその他の必要なコンポーネントも使用します。AWS CloudFormationスタックのデプロイには、10〜12分かかります。この例の全体的なウォークスルーは1時間以内で完了できます。

注：このスクリプトは、他の地域でリソース制限が発生する可能性があるため、オレゴン州（米国西部-2）およびオハイオ州（米国東部-2）地域で機能するように設計されています。また、パート2では、AWS Glueを使用します。AWS Glueは、特定の地域でのみ使用できます。

前提条件

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

  1. ラップトップまたはインターネットにアクセスできるEC2インスタンスにAWS SCTをダウンロードしてインストールします。
  2. OracleとAmazon AuroraのMySQL互換ドライバーをダウンロードし、AWS SCTのインストール手順に従ってAWS SCTグローバル設定を構成します。
  3. 米国西部-2（オレゴン州）または米国東部-2（オハイオ州）地域で使用するAmazon EC2キーペアを探します。キーペアがない場合は、Amazon EC2 のキーペアを作成してください。
  4. AWS マネジメントコンソールにサインインし、IAM コンソールを開きます。ロールの下で、dms-vpc-roleがすでに存在するかどうかを確認します。これは、プログラムでAWS DMSタスクを起動するために必要なAPI / CLI固有の役割です。ロールが存在しない場合は、次のセクションのAWS CloudFormationスタックがロールを作成します。

スタックを起動する

注 : スタックによってデプロイされたリソースの一部では、使用を終了しない限り、料金が発生します。

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

  1. [Launch Stack] を選択します。このボタンは、お使いの AWS アカウントで、起動するテンプレートを使って自動的に AWS CloudFormation サービスを開始します。必要に応じて、サインインするプロンプトが表示されます。
  2. オハイオ州またはオレゴン州の地域を選択してスタックを作成してください。[次へ] を選択します。
  3. EC2インスタンスのキーペア、および必要に応じてその他のパラメータを指定します。すべてのパラメータが必要です。
  4. DMSVPCRoleExistsパラメーターの場合は、前提条件のステップ4に基づいて[はい]または[いいえ]を選択します。
  5. MyIPパラメータの場合、デフォルト0.0.0 / 0はオープンアクセス用にポート3306を作成します。パブリックIPを使用することをお勧めします。（whatsmyip.orgを使用してあなたのIPをチェックすることができます。）
  6. ほとんどのパラメータはデフォルト値をとります。[Next] (次へ) を選択します。
  7. レビューページで、スタックの起動時にAWS CloudFormationがIAMロールを作成することを確認します。[作成] を選択します。
  8. スタック作成の進捗状況を確認するには、[更新] を選択します。次に、スタックを選択して、下にある [イベント] セクションで起動イベントを表示します。スタック作成には、完了までに 7～10 分かかります。スタックが正常に起動されたら、[状況] がCREATE_IN_PROGRESS からCREATE_COMPLETE に変わります。出力セクションには、この手順の後半で必要となる、AWS CloudFormationによってデプロイされるリソースに関する情報が含まれています。これらの値をファイルにコピーして簡単に検索することができます。

セクション1：AWS SCTを使用して、既存のデータベーススキーマをソースからターゲットに変換する

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

  1. AWS SCTを起動します。
  2. [ファイル]、[新しいプロジェクトウィザード] と選択します。
  3. ウィザードで、プロジェクトの名前を入力します。ソースとして Oracleを選択し、[Next] を選択します。
  4. Oracle データベースの接続情報を入力します。このステップで必要なパラメーターはすべて、先ほどデプロイした AWS CloudFormation スタックの [出力] に記載されています。[Test Connection] を選択して、AWS SCT が Oracle ソースに正常に接続できることを確認します。[Next] (次へ) を選択します。
  5. 移行するスキーマとして [HRDATA] を選択して、[次へ] を選択します。
  6. 次に、さまざまなターゲットデータベースエンジンの移行の課題についての洞察を提供する、データベース移行評価レポートが表示されます。このレポートは、課題を理解し、移行に最適なターゲットデータベースを選択するのに役立ちます。この記事では、Amazon Aurora MySQLをターゲットエンジンとして使用しています。レポートは、必要に応じてダウンロードできます。[次へ] を選択します。
  7. ターゲットセクションで、サーバー名にAurora MySQLクラスターエンドポイントを指定し、3306をポートとして使用します。AWS CloudFormationスタックによってプロビジョニングされたAuroraクラスタのユーザー名とパスワードを入力します。[テスト接続] を選択して、AWS SCT が Auroraターゲットに正常に接続できることを確認します。[終了] を選択します。
  8. ウィザードが終了すると、2つのペインを持つメインビューが表示されます。左のペインはソースOracleデータベースで、右はターゲットAmazon Aurora MySQLデータベースです。より具体的で詳細な評価レポートを生成するには、ソースのHRDATAスキーマのコンテキスト（右クリック）メニューを開き、[レポートの作成]を選択します。このレポートには、データベース管理者（DBA）が移行を成功させるために、ターゲット内のスキーマの不一致を解決するのに役立つアクション項目が用意されています。例：ソースペインで、Viewsに移動して[EMP_DETAILS_VIEW]を選択します。ターゲットデータベース内のEMP_DETAILS_VIEWの自動作成中に問題を解決するには、2つのアクション項目があります。AWS SCTは、スキーマ、関数、およびストアドプロシージャを、アクションアイテムとともにソースデータベースからターゲットデータベースに変換する強力なツールです。このポストの範囲では、データベースは単純であり、大きなアクション項目は必要ありません。
  9. ソースOracleデータベースで、HRDATAスキーマのコンテキスト（右クリック）メニューを開き、[スキーマの変換]を選択します。HRDATAスキーマは、対象のAmazon Aurora MySQLデータベースで作成されます。 ターゲットにすでに存在するオブジェクトが置き換えられることを示す警告が表示されます。[はい] を選択して続行します。
  10. ターゲットの Amazon Aurora MySQL データベースのペインで、HRDATA スキーマのコンテキスト (右クリック) メニューを開き、[データベースへ適用] を選択します。

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

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

私たちの目的のために、ターゲットデータベースオブジェクトの最適化手順は探っていませんでした。AWS SCT でソースからターゲットへのシンプルな変換を行いました。

これで、移行を進めることができます。

セクション2：AWS DMSを使用してソースからターゲットにデータを移行する

このセクションでは、AWS DMSを使用して、OracleデータベースからAmazon Aurora MySQLデータベースへのバルクロードを行います。

  1. AWS マネジメントコンソールにサインインして AWS DMS コンソールを開きます。
  2. セクション1でAWS CloudFormationスタックをデプロイしたのと同じAWSリージョン（米国東部-2または米国西部-2）であることを確認してください。
  3. 左のナビゲーションペインで [レプリケーションインスタンス] を選択します。AWS CloudFormationスタックがすでに新しいレプリケーションインスタンスを作成したことに気付くかもしれません。レプリケーションインスタンスの Virtual Private Cloud (VPC) に注目してください。これは、CloudFormationスタックによって作成されたものと同じVPCです。
  4. 左のナビゲーションペインで、選択します。
  5. [エンドポイントの作成] を選択します。
  6. [エンドポイントの作成] ページで、[ソース] を選択し、Oracle ソースデータベースに関する必要な情報を入力します。AWS CloudFormation[出力]タブには、この手順を完了するために必要な情報が含まれています。 [エンドポイント接続のテスト]で、AWS CloudFormationスタックによって作成されたVPCレプリケーションインスタンスを選択します。テストが成功したことを確認し、ソースエンドポイントを作成します。
  7. 同様に、[エンドポイントの作成] ページで [ターゲット] を選択し、Aurora MySQL ターゲットデータベースに関する必要な情報を入力します。AWS CloudFormation 出力セクションには、この手順を完了するために必要な情報が含まれています。
  8. [詳細]セクションを開き、次の文字列をおまけの接続記号として入力します：
    initstmt=SET FOREIGN_KEY_CHECKS=0;parallelLoadThreads=5;maxFileSize=131072The initstmt=SET FOREIGN_KEY_CHECKS=0 この記号は、ターゲットAurora MySQLデータベースの外部キーチェックを無効にします。parallelLoadThreads = 5 この記号は、MySQLターゲットデータベースにデータをロードするために使用するスレッド数を指定します。maxFileSize = 131072 この記号は、MySQLにデータを転送するために使用される、ファイルの最大サイズ（128 MB）を指定します。
  9. [エンドポイント接続のテスト] セクションで、AWS CloudFormation スタックによって作成された VPC レプリケーションインスタンスを選択します。テストが成功したことを確認し、ターゲットエンドポイントを作成します。 注意：外部キーチェックが無効な場合（たとえば、AWS DMSの移行全体を通じて）、ターゲットデータベースに対してDDL文を実行しないでください。実行すると、データディクショナリーが破損する場合があります。
  10. 左のナビゲーションペインで [タスク] を選択します。次に、[タスクの作成]を選択します。
  11. [タスク設定] で以下を実行します：
    1. AWS CloudFormationスタックによってデプロイされたレプリケーションインスタンスを選択します。
    2. ソースとして Oracle エンドポイントを選択する。
    3. ターゲットとしてAmazon Aurora MySQLエンドポイントを選択します。
    4. [移行タイプ] に [既存のデータを移行する] を選択する。このオプションを選択すると、変更データキャプチャ (CDC) なしで一括ロードを実行することが可能になります。他のオプションを選択することもできますが、CDCを許可するには補助ログを有効にする必要があります。
    5. [作成時にタスクを開始] チェックボックスにチェックを入れて、タスクが作成されると同時にロードが開始されるようにします。
    6. ターゲットテーブルの準備モードでは、AWS SCTを使用してすでにスキーマを変換しているため、何もしないでください。
    7. [検証の有効化] オプションを選択し、ソースの各行を対応するターゲットの行と比較して、これらの行に同じデータが含まれていることを確認します。
    8. オプションとして、[ロギングの有効化] を選択して、必要に応じてトラブルシューティングやログの分析を行うためにタスクを CloudWatch にログします。
    9. 最後に、[テーブルマッピング] セクションで、移行するソースの HRDATA スキーマを選択します。[テーブル名] オプションでは、スキーマ内のすべてのテーブルに % ワイルドカードを指定します。
    10. [選択ルールの追加] を選択してテーブルマッピングルールを追加します。
    11. 続けるには、[タスクの作成]を選択します。
  12. タスクが作成されたら、ソースからターゲットデータベースへのデータのロードが自動的に開始されます。タスクを選択し、下のプロパティウィンドウで[テーブル統計]に移動して進捗状況を確認します。検証状態が 検証保留中 から 検証済み に変わるはずです。また、合計数と全ロード行の値が一致することも確認してください。

この時点で、OracleデータベースからAmazon Aurora MySQLデータベースにデータを正常に移行しました。必要に応じてMySQLクライアント経由でAurora MySQLに接続し、ロードされたデータを見ることができます。

クリーンアップリソース

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

注意：この移行シリーズのパート2では、この記事に掲載されているAmazon Aurora MySQLデータベースをデプロイして、AWS GlueをETL処理に使用する方法を説明します。パート2を完了するには、この投稿の移行手順を必ず完了してください。

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

  1. AWSマネジメントコンソールで、AWS DMSを開き、左側のナビゲーションペインで[タスク]を選択します。セクション2で作成したタスクを選択し、[削除]を選択します。
  2. タスクが削除されたら、左のペインで [エンドポイント] を選択します。セクション2の一部として作成したOracleソースおよびAurora MySQLターゲットエンドポイントを削除します。
  3. AWS CloudFormationコンソールを開きます。以前に作成したスタックを選択し、削除を選択します。スタックのすべてのリソースを削除する警告が表示されます。続行するには、[はい、削除します] を選択します。
  4. 削除処理には完了までに7-10分かかります。スタックが作成したすべてのリソースが削除されます。状況にはDELETE_IN_PROGRESSと表示されます。削除が正常に行われたら、スタックリストにそのスタックが表示されなくなります。

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

結論

この記事では、AWS Schema Conversion ToolとAWSデータ移行サービスを使用して、異種間で簡単に移行できることを確認しました。OracleからAmazon Aurora MySQLデータベースへの移行を理解してテストするための作業環境を構築する方法を紹介しました。また、AWS CloudFormation スクリプトをカスタマイズして、他のデータベースエンジンタイプを簡単にデプロイし、その他の移行をテストすることもできます。

著者について

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

 

 

 

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