Category: AWS Schema Conversion Tool


オンプレミスや Amazon EC2 上の Oracle Database を Amazon Redshift に移行

AWS Database Migration Service (AWS DMS) は、簡単かつ安全なAWSへのデータベース移行の手助けをします。AWS Database Migration Service は広く使われている商用データベースとオープンソースデータベースに対応しています。このサービスはOracleからOracleのような同一プラットフォームでの移行に対応していますし、Oracleから Amazon Aurora や、Microsoft SQL Server からMySQLのような異なるプラットフォーム間での移行にも対応しています。移行元のデータベースは移行中も完全に動作しつづけたままであり、データベースに依存するアプリケーションのダウンタイムを最小限に抑えます。

AWS Database Migration Service を使用したデータレプリケーションは、AWS Schema Conversion Tool (AWS SCT) と緊密に統合されており、異なるプラットフォーム間でのデータベース移行プロジェクトを簡略化します。異なるプラットフォーム間での移行には AWS SCT を使用できますし、同一プラットフォームであれば移行元エンジンの純正スキーマ出力ツールが使えます。

この投稿では、Oracle Database のデータウェアハウスから Amazon Redshift へのデータ移行にフォーカスします。

以前の AWS SCT では、Oracle Database のビューやファンクションなどのカスタムコードを Amazon Redshift と互換性のあるフォーマットに変換できませんでした。ビューとファンクションを変換するには、最初に Oracle Database スキーマをPostgreSQLに変換し、それから Amazon Redshift と互換性のあるビューとファンクションを抽出するスクリプトを実行する必要がありました。

お客様のフィードバックに基づいたアップデートの後、AWS SCT と AWS DMS を使用して Oracle Database のビューとファンクションを Amazon Redshift に移行できるようになりました。

次の図は移行手順を示しています。

準備

この移行を開始するには次の手順を実行します。

  • AWS SCT をダウンロード
  • AWS SCT グローバル設定 からデータベースドライバーをダウンロードし、そのパスを設定。
  • 米国西部(オレゴン)リージョンで使用できる Amazon EC2 キーペアを用意。持っていない場合は新しい Amazon EC2 キーペアを作成。

スタックの作成

この投稿では、AWS CloudFormation スタックを起動するために、以下の Launch Stack を使います。起動プロセス中に前述のアーキテクチャも作成されます。結果は AWS DMS コンソールで確認できます。移行が終わると、CloudFormationスタックは破棄できます。

このリンクは米国西部(オレゴン)リージョン (us-west-2) でスタックを開始します。

一部のリソースを使用されている間は料金が発生します。

Launch Stack

スタックを起動して名前を付けるには、次のようにします。

  1. AWSアカウントにまだログインしていない場合はログイン。
  2. Launch Stack を選んで、あらかじめ用意されたCloudFormationテンプレートでCloudFormationコンソールを起動。「次へ」を選択。
  3. スタック名には入力済みのorclrsmigrationを使用するかカスタム名を入力。KeyNameを選択し、Redshiftクラスター用のMasterUserPasswordを入力し、「次へ」を選択。
    Specify Details
  4. 確認ページにて、スタックの起動結果としてCloudFormationが AWS Identity and Access Management (IAM) ロールを作成することを確認。「作成」を選択。
    I acknowledge that AWS CloudFormation might create IAM resources with custom names.
  5. スタック作成の進行状況を確認するには更新ボタンを押し、起動イベントを表示するスタックを選択。
    Eventsタブ
  6. スタックが正常に起動すると、状況はCREATE_IN_PROGRESSからCREATE_COMPLETEに変わります。次のセクションで使用する値を表示するには「出力」を選択。
    Outputsタブ

このCloudFormationテンプレートによって作成されたインフラは、次のセクションで使用されます。以下のテーブルでリストされている値が表示されています。

Schema Conversion Tool での設定

Schema Conversion Tool での設定のために、以下を実行します。

  1. AWS Schema Conversion Tool を開始。
  2. Fileから New Project を選択。New Project ダイアログが表示される。
    New Project dialog
    次のプロジェクト情報を追加。

    Project Name プロジェクト名を入力。コンピュータにローカル保存される
    Location ローカルプロジェクトファイルの保存先を入力
    Data Warehouse (OLAP)
    Source DB Engine Oracle DW
    Target DB Engine Amazon Redshift
  3. AWS Schema Conversion Tool プロジェクトを作成するためOKを選択。
  4. Oracle Database に接続するため、Connect to Oracle DW を選択。

    Connect to Oracle DW ダイアログが表示される。移行元の Oracle Database 接続情報を入力。

    以下の値をフォームに入力。

    Server name <移行元EC2エンドポイントのDNS名>
    Server port 1521
    Oracle SID XE
    User name dms_sample
    Password dms_sample
    Use SSL チェックしない
  5. 移行元のデータベースに正しく接続できるかを確認するため、Test Connection を選択。
  6. 移行元データベースに接続するため、OKを選択。
  7. DMS_SAMPLEデータベースを選び、Nextを選択。
  8. Database Migration Assessment Report を読み、Nextを選択。

  9. Amazon Redshift に接続するため、Connect to Amazon Redshift を選択。

    Connect to Amazon Redshift ダイアログが表示される。移行先のデータベース接続情報を入力。

    以下の値をフォームに入力。

    Server name 移行先RedshiftエンドポイントのDNS名
    Server port 5439
    Database dev
    User name admin
    Password CloudFormationで選ばれたパスワード
    Use SSL チェックしない
  10. 移行先のデータベースにただしく接続できるかを確認するため、Test Connection を選択。
  11. 移行先データベースに接続するため、OKを選択。

スキーマを変換

次にスキーマを変換します。

  1. Viewを選び、Main View を選択。
  2. 移行元のデータベースのスキーマを表示している左側のパネルから変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト(右クリック)メニューを開き、Convert schema を選択。
  3. AWS Schema Conversion Tool でのスキーマ変換が完了すると、選択されたスキーマがビューやファンクションを含めて移行先の Amazon Redshift クラスター上で表示されます。この時点では、移行先の Amazon Redshift クラスターにスキーマは適用されていません。このウィンドウでスキーマを編集できます。編集したスキーマはプロジェクトの一部として保存されます。変換されたスキーマをデータベースに適用することを選択すると、編集されたスキーマが移行先DBインスタンスに書き込まれます。
  4. 移行先データベースのスキーマを表示する右側のパネルで、変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト(右クリック)メニューを開き、Applyを選択。

この時点で、データが空の状態のデータベーススキーマが Amazon Redshift クラスター上にできあがります。

データベース移行のために AWS DMS を構成

次にDMSに移ります。

  1. AWSマネジメントコンソールでDMSを選び、「移行の作成」を選択。
  2. 「AWS Database Migration Service へようこそ」ページで「次へ」を選択。
  3. 「レプリケーションインスタンスの作成」ページが表示される。

    このページで以下の値を入力し、「次へ」を選択。

    名前 8から16文字のASCII文字によるレプリケーションインスタンスの名前(/、”、@を除く)
    説明 レプリケーションインスタンスの説明を入力
    インスタンスクラス dms.t2.medium
    VPC 使いたい Amazon Virtual Private Cloud (Amazon VPC) を選択。移行元または移行先または両方があるVPCを使う
    Multi-AZ いいえ
    パブリックアクセス可能 チェック
  4. 「アドバンスト」タブはデフォルトのままで、「次へ」を選択。

データベースエンドポイントの設定

  1. ソースエンドポイントに以下の値を設定。
    エンドポイント識別子 エンドポイントを識別するために使いたい名前を入力
    ソースエンジン oracle
    サーバー名 <移行元EC2エンドポイントのDNS名>
    ポート 1521
    SSLモード none
    ユーザー名 dms_sample
    パスワード dms_sample
  2. ターゲットエンドポイントに以下の値を設定。
    エンドポイント識別子 エンドポイントを識別するために使いたい名前を入力
    ソースエンジン redshift
    サーバー名 <RedshiftエンドポイントのDNS名>
    ポート 5439
    SSLモード none
    ユーザー名 admin
    パスワード CloudFormationで選ばれたパスワード

レプリケーションインスタンスが正しく作成された後に「テストの実行」を選ぶことで、エンドポイントへの接続をテストできます。

タスクの作成

「タスクの作成」ページでタスクのオプションを設定します。

以下のテーブルはタスクの設定について説明しています。

タスク名 タスク名を入力
ソースエンドポイント 使用する移行元エンドポイントを選択
ターゲットエンドポイント 使用する移行先エンドポイントを選択
レプリケーションインスタンス 使用するレプリケーションインスタンスを選択
移行タイプ Migrate existing data
作成時にタスクを開始 チェックする

「ターゲットテーブル作成モード」は「何もしない」を選択。

「テーブルマッピング」ではdms_sampleを選び、Add selection rule を押して、「タスクの作成」を選択。

タスクの監視

タスクの作成で「作成時にタスクを開始」を選んだ場合、「タスクの作成」を選択するとすぐにデータ移行が開始されます。AWSマネジメントコンソールから実行中のタスクを選ぶことで、タスクの統計と監視の情報を表示できます。次のスクリーンショットはデータベース移行のテーブル統計を表しています。

まとめ

この投稿では Oracle Database の商用環境をビューやファンクションとともに Amazon Redshift に移行することがいかに簡単であるかをご紹介しました。


翻訳はソリューションアーキテクト柴田(シバタツ)が担当しました。原文は Migrating Oracle Database from On-Premises or Amazon EC2 Instances to Amazon Redshift です。

Oracle Database を Amazon Aurora に移行する方法

この投稿では、商用データベースから Amazon Aurora への移行を容易にするために AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Service (AWS DMS) をどのように使えるかの概要をお伝えします。今回は、Oracleから Amazon Aurora with MySQL Compatibility への移行にフォーカスします。

データベースエンジンの変更は不安を伴うかもしれません。しかし、Amazon Aurora のようなスケーラビリティやコスト効果の高いフルマネージドサービスのバリュープロポジションは、それに挑戦する価値を生み出します。その手順を簡単にするツールがある場合は特にです。データベースをあるエンジンからほかのものに移行するとき、主に2つのことを考慮する必要があります。スキーマとコードオブジェクトの変換と、データ自身の移行と変換です。幸いにも、データベースの変換と移行の両方を容易にするツールをAWSは用意しています。

AWS Schema Conversion Tool は移行元データベースのスキーマとカスタムコードの大部分を新しい移行先データベースと互換性のあるフォーマットに自動的に変換することで、異なるプラットフォーム間でのデータベース移行をシンプルにします。このツールが変換するカスタムコードには、ビューやストアドプロシージャ、ファンクションを含みます。このツールで自動変換できない一部のコードは明確に示されるので、ユーザー自身でそれを変換することができます。AWS Database Migration Service は最小限のダウンタイムでデータを簡単かつ安全に移行することを手助けします。

すばらしい! では、どこから始まれば良いのでしょう?

AWS SCT での移行手順

通常、移行の最初のステップは実現可能性と作業量のアセスメントです。現行のOracleからAuroraにデータベースを移行するために要する作業量の大枠な概要を AWS SCT は生成することができます。SCTはいくつかのOS上で動作しますが、このブログではWindows上で動かします。SCTをダウンロードするためには、マニュアルの AWS Schema Conversion Tool のインストールと更新 をご覧ください。SCTのマニュアル全体を見たい場合は AWS Schema Conversion Tool とは からご覧ください。

この投稿ではSCTのイストールや構成については触れませんが、注意点は移行元と移行先のデータベースにSCTを接続するために、OracleとMySQLのドライバーをインストールする必要があることです。移行元のOracleに接続した後、スキーマのいずれかを右クリックしてアセスメントレポートを作成できます。アセスメントレポートはこのスキーマがどれくらいOracleからAuroraに自動変換されるのかと、自動変換後に残された作業量がどれくらいなのかの概要を教えてくれます。以下がレポートの例です。

Database Objects with Conversion Actions for Amazon Aurora

アセスメントレポートに加えて、SCTは各オブジェクトがどれくらい正確に変換されるかも教えてくれます。もしあるオブジェクトが変換できない場合、SCTはその理由と、状況を改善するためのヒントを教えてくれます。

Database Objects with Conversion Actions for Amazon Aurora

スキーマの100%がOracleからAuroraに変換されない場合、いくつかの方法で状況を改善できます。

  • 移行元のOracleのデータベース上のオブジェクトを変更して、SCTでAuroraに変換できるようにする
  • スキーマをひとまず変換し、SCTによって生成されたスクリプトを変更してからAuroraデータベースに適用する
  • 変換できないオブジェクトを無視し、移行先でそれらを置き換えるか無視する。たとえば、Oracleのsys.dbms_randomパッケージを呼び出すファンクションがあるとします。このパッケージはAuroraには存在しません。この問題を解決するには以下のことができます。
    • ランダム値の生成をアプリケーションコードに移し、それをパラメーターとしてファンクションに渡します。この変更は、変換前の移行元データベースまたは変換後の移行先データベースで行うことができます。
    • SCTで生成されたコードを、MySQLに存在するRAND()ファンクションを使うように変更し、新しいコードをAuroraデータベースに適用します。

その他の例として、一意の識別子を生成するためにOracleのシーケンスを使っているとします。Auroraはシーケンスをサポートしていないので、修正するために以下を実行してください。

  • 自動的に一意の識別子を生成するAuroraのauto-increment機能を使う。この方法で行く場合は、Auroraデータベースにスキーマを作成した後で、移行先のテーブルを変更するためのスクリプトを作成することをお勧めします。
  • 一意の識別を生成する何か別の方法(ファンクションや類似のもの)を作成し、シーケンスを参照している部分を新しいファンクションで置き換える。これは変換前に移行元のOracle上で実施することも、移行先のAuroraで実施することもできます。
  • 両方の手法を使う必要があるかもしれません。

一般的に、移行の一環としてSCTを使うための良い取り組み方には以下を含みます。

  • SCTアセスメントレポートを作成し、移行のギャップを埋める計画を立てる。もし移行候補となる複数のシステムがある場合は、どのシステムから最初に取り組むべきかの決定に役立ちます。
  • Action Items を確認し、変換に失敗した各項目の適切な処理を決定する。
  • 新しいAuroraデータベースに対してアプリケーションをテストしながら、AWS Database Migration Service と連携して新しいスキーマにデータをロードし、この処理を繰り返す

AWS DMS での移行手順

AWS DMS は移行元のOracleデータベースから移行先の新しいAuroraデータベースにデータをロードするときに使えます。DMSの素晴らしい点は、データを丸ごとロードすることに加えて、実行中のトランザクションをキャプチャして適用することです。カットオーバーの準備が整うまで、Oracleの移行元データベースとAuroraの移行先データベースを同期させつづけます。このアプローチによって、移行を完了させるために必要な停止時間を大幅に短縮することができます。DMSマイグレーションには、移行元エンドポイントであるOracle、移行先エンドポイントであるAurora、レプリケーションサーバー、タスクを含みます。

OracleからAuroraに移行するとき、既存データを移行し、進行中の更新をレプリケーションするタスクを構成したいでしょう。これにより、データ全体の移行中に実行されたトランザクションをキャプチャするようにDMSに指示します。データ全体がロードされると、DMSはキャプチャされたトランザクションの適用を開始し、OracleとAuroraのデーベースの同期を開始します。Auroraをカットオーバーする準備ができたら、アプリケーションを停止し、残ったトランザクションをDMSに適用させ、新しいAuroraデータベースに接続するアプリケーションを開始するだけです。

DMSを使用してOracleからAuroraに移行する場合、考慮すべき点がいくつかあります。

サプリメンタルロギング。 DMSが移行元のOracleから更新をキャプチャするにはサプリメンタルロギングを有効にする必要があります。詳細な手順については、DMSのマニュアルを参照してください。

DMSの3つのフェーズ。 データを移行し、進行中の更新をキャプチャするとき、DMSは3つのフェーズを経ています。

  • バルクロード: バルクロードフェーズで、DMSはn個のテーブルを一度にまとめてロードします。デフォルトでは n = 8 です。この値はDMSマネジメントコンソールまたは AWS CLI を利用して変更できます。
  • キャッシュされたトランザクションの適用: バルクロードフェーズにDMSは移行元データベースへの更新をキャプチャします。あるテーブルのバルクロードが完了すると、DMSはバルクロードの一部であるかのようにキャッシュされた更新をできるだけ速くそのテーブルに適用します。
  • トランザクションとしての適用: すべてのテーブルのバルクロードが完了すると、DMSはキャプチャされた更新を単一のテーブルの更新ではなく、トランザクションとして適用し始めます。

セカンダリインデックス。 状況によっては、性能上の理由からDMSのバルクロードフェーズにセカンダリインデックスを削除したくなるかもしれません。バルクフェーズ中にセカンダリインデックスの一部またはすべてを削除することを選ぶ場合は、移行を一時停止して、トランザクションとしての適用フェーズでそれらを追加しなおす必要があります。すべてのテーブルのフルロードが完了した後であれば、移行を安全に一時停止することができます。

外部キー、トリガーなど。 バルクロードはテーブル単位で行われるため、バルクロードやキャッシュされたトランザクションの適用フェーズでは移行先のAurora内の外部キーに違反する可能性があります。initstmt=SET FOREIGN_KEY_CHECKS=0 をAuroraエンドポイントの追加接続属性として加えることで、外部キー検査を無効にすることができます。一般的に、データのバルクロードを中断したり悪影響を与える可能性のあるものにどう対処するかの戦略を策定する必要があります。たとえば、問題を回避するために、移行のカットオーバーフェーズになるまでトリガーの実装を延期することができます。

データ型。 新しいデータベースエンジンに移行するときには、どのようなデータ型がサポートされているかと、移行元のデータ型を移行先の新しいデータ型にどう変更するかを理解することが重要です。これについては、移行元のOracleのデータ型移行先のAuroraのデータ型をマニュアルで確認すべきです。

性能。 移行の全体的な性能は、移行元のOracle内のデータ量、種類、分散に依存しています。 AWS Database Migration Service Best Practices ホワイトペーパーに移行性能を最適化するためのいくつかの推奨事項が載っています。

手順をおさらいすると、

  1. SCTアセスメントレポートを使用して課題の概要を知ることができます。Auroraへの移行候補が複数ある場合は、どれから最初に取り組むべきかの決定に役立ちます。
  2. 処理の前後に必要となるかもしれない移行手順を洗い出すために、DMSを使用して移行先スキーマの作成とロードを実践します。
  3. 移行先のシステムでアプリケーションをテストして、新しい環境で期待通りに動作することを確認します。負荷やネットワーク環境を含む本番環境と同等の構成でテストしてみてください。
  4. スキーマの生成、データのロード、後処理の手順の適用、移行元と移行先システムの同期、カットオーバーに必要な手順などの実際の移行を実践します。
  5. SCTもDMSをシステム全体を一度に移行することを求めません。システムを短期間で効率的に移行するため、また必要であれば再構築するために、これらのツールを使用することができます。

実際の移行を開始する前に、SCTとDMSの両方のドキュメントを通して読むことをお勧めします。また、Step-by-Step ウォークスルーAWS Database Migration Service Best Practices ホワイトペーパー を読むこともお勧めします。

ツールの使い方を知るためにサンプルデータベースを使用したいのであれば、AWS GitHub リポジトリ で見つけることができます。

この投稿は特定の状況に必要な可能性のあるすべての手順や考慮事項を解説するものではありませんが、SCTとDMSを使用してプロプライエタリなOracleデータベースの足かせをどう緩められるかについての良いアイデアを提供しました。それでは幸せな移行を!


翻訳はソリューションアーキテクト柴田(シバタツ)が担当しました。原文は How to Migrate Your Oracle Database to Amazon Aurora です。