こんにちは。utsugiです。今回は、オンプレミスのOracleのデータを、Database Migration Service(DMS)を利用してRDS for Oracleに移行する方法について考えていきたいと思います。
Oracle自体のユーティリティではないため、馴染みのない方もいらっしゃるかもしれませんが、とても簡単にデータの移行を行うことができるツールです。
目次
∗ Database Migration Service(DMS)について ∗ OracleからRDSへのDMSを利用したデータ移行の流れ ∗ OracleからRDSへのDMSを利用したデータ移行方法のメリット ∗∗ とにかく簡単にデータの移行ができる ** ダウンタイムを短くできる ∗ OracleからRDSへのDMSを利用したデータ移行方法のデメリット ∗∗ オンプレミス環境の設定変更が必要になる場合 ∗∗ オンプレミス環境と直接繋ぐ必要がある ∗∗ DMSの利用料金がかかる ∗∗ DBのユーティリティより移行が遅い場合がある ∗∗ 移行に制限がある ∗ まとめ
Database Migration Service(DMS)について
Database Migration Service(DMS)はAWSが提供しているデータベースの移行サービスです。個人的に気になった点の抜粋ですが、おおよそ、下記のような特徴があります。 記載させていただいた特徴も含めた詳細はAWS Database Migration Serviceをご参照いただければと存じます。
【Database Migration Service(DMS)の特徴】 ・AWS上に移行用インスタンスを生成して利用する ・移行元/先のどちらかがAWS上に存在している必要がある ・様々な種類のデータベースに対応している ・異種間のデータベースの移行に対応している ・対象データの一括移行に対応している ・更新差分のレプリケーションに対応している ・定義情報の移行に一部対応している
これだけ見ると夢のようなサービスですね。単純な構造なら、DMSを単純に実行するだけで移行が完了してしまうような印象すら受けます。
ただし、あくまで個人的な意見という前置きをした上で、DMSはデータ移行に特化させた方が良いと考えています。つまり、テーブル等のオブジェクトは事前に作成しておいて、データの移行にDMSを利用するというイメージです。
下記ページにも記載がありますが、現時点では、完全に定義等を移行するわけではないためです。しかし、データの移行は得意なので、役割分担させるのが、ベターなアプローチかもしれません。 よくある質問 - AWS Database Migration Service（データベース移行）｜AWS
Q: AWS Database Migration Service でデータベーススキーマを移行できますか? すばやくデータベーススキーマをターゲットインスタンスに移行するために、信頼性のある AWS Database Migration Service のベーシックスキーマコピー機能を利用できます。ターゲットに同じ名前のテーブルが含まれていない場合、ベーシックスキーマコピーはターゲットインスタンスに、自動的にテーブルとプライマリーキーを作成します。ベーシックスキーマコピーは、移行テストや、Oracle から MySQL への移行、または SQL Server から Oracle への移行などの、異なる種類のデータベースへの移行に最適です。ベーシックスキーマコピーでは、セカンダリインデックス、外部キー、またはストアドプロシージャは移行されません。よりカスタマイズ可能なスキーマの移行プロセスを使用する必要がある場合 (プロダクションデータベースを移行しており、ストアドプロシージャとセカンダリデータベースオブジェクトを移動させる必要がある場合など)、同種間の移行や異種間の移行に AWS Schema Conversion Tool を使用できます。 (1) SQL Server Management Studio のインポートおよびエクスポートウィザード、(2) Oracle の SQL Developer Database Export ツールまたは dbms_metadata パッケージを使用するエクスポートのスクリプト、(3) MySQL の Workbench Migration Wizard といった同種間の移行を行う場合は、ソースエンジンにネイティブで実行されるスキーマエクスポートツールを使用できます。
OracleからRDSへのDMSを利用したデータ移行の流れ
今回は、「データを一括で移行した後、更新差分も移行する」というケースで考えられる、おおよその流れについて記載します。
図: 移行タイプ「既存のデータを移行して、継続的な変更をレプリケートする」
①②エンドポイント作成 DMSを利用するためには、接続情報を保持したエンドポイントと呼ばれるものが必要になります。 エンドポイントにはソースとターゲットの2種類があり、複数のエンドポイントを指定することもできます(複数サーバを1つのサーバに集約する等のケースで利用)。
③移行タスク作成 実際に移行を行うタスクを作成します。特に重要なのは、ここで「移行タイプ」を選択することです。現時点では、移行タイプは3種類用意されており、それぞれ、下記のような特徴を持っています。 今回は「既存のデータを移行して、継続的な変更をレプリケートする」を選択している想定ですが、他の2つについても、要件次第で使い分けることができます。
| 移行タイプ | 概要 |
|---|---|
| 既存のデータを移行する | 移行元のデータを全て移行します。 |
| 既存のデータを移行して、継続的な変更をレプリケートする | 移行元のデータを全て移行し終えた後、移行中に発生した変更を移行先に適用します。 |
| データ変更のみをレプリケートする | 移行元に対して行われた変更だけを移行先に適用します。 |
④既存データ移行 まずは、既存のデータを移行します。同種間の移行ならば純正ツールを利用することもできますが、今回はそれもDMSに任せてしまう想定です。速度は遅いですが、手間は減りますので、要件次第だと思われます。
⑤継続的なレプリケーション 既存のデータが移行し終わったら、継続的なレプリケーションの段階に入ります。移行元に対する更新も移行先に反映されますので、慌てて即座にアプリの更新を停止する必要はありません。
⑥更新停止 アプリケーションの向き先を移行先に付け替えるため、継続的なレプリケーションの段階に入ったら、更新を停止します。
⑦終了目印投入 ここでは、DBのデータ更新はアプリケーションのみで、アプリケーションによる更新が停止されたら、DBのデータは未更新になるという想定です。 ただし、レプリケーションにも反映にタイムラグが存在しますので、完全に反映がされたことを表す終了の目印を移行元に投入します。
⑧終了目印確認
⑨移行タスク終了 移行先に終了目印が到達したことが確認できたということは、全てのレプリケーションが終了したということを意味しますので、移行タスクを終了します。
⑩整合性確認 ここまでで完全にデータとしては移行元と移行先で同期がとれた状態になりますが、データの欠落等がないか、データの整合性を確認します。
⑪更新再開 データの整合性まで確認出来たら、アプリケーションの更新先を移行先に変更します。
DMSを利用した移行のメリット
とにかく簡単にデータの移行ができる
実際にDMSのコンソールを触っていただければお分かりになるかと存じますが、これだけのことを実現できるにも関わらず、わずらわしい設定項目はありません。また、移行方式も明快で分かりやすいです。 データベースの移行は複雑になりがちなものですが、GUIで簡単に設定できるため、そこまで特別な知識を持ち合わせていなくても、移行に取り組むことができるようになっています。
図: DMSの設定画面例
移行タイプ次第でダウンタイムを短くできる
前述しました通り、DMSには複数の移行タイプが存在しますが、OracleからRDSへのDMSを利用したデータ移行の流れで例に挙げさせていただいたような流れで移行を行うことができれば、ダウンタイムは極めて短くなります。 最短のケースだと、アプリケーションの向き先を変更する時間だけがダウンタイムとなります。極力ダウンタイムを短くしなければならないという要件がある場合、これは極めて大きなメリットとなります。
DMSを利用した移行のデメリット
オンプレミス環境の設定変更が必要になる場合
DMSを利用するには、ARCHIVELOGモードとサプリメンタル・ロギングを有効化する必要があります。 基幹システムの場合、ARCHIVELOGモードは有効化しているケースが多いと思われますが、サプリメンタル・ロギングまで有効化しているケースは、ARCHIVELOGモードよりも少ないのではないでしょうか。
サプリメンタルロギングについての詳細はREDOログ・ファイル分析のためのLogMinerの使用をご参照いただければと存じますが、REDOログの生成時にオーバーヘッドが発生するため、負荷も若干高まる可能性があります。 本番環境へ負荷が高まる可能性のある設定を適用する必要があるため、この点が大きなハードルになると推測されます。
オンプレミス環境と直接繋ぐ必要がある
DMSは移行元DBのデータを参照する必要があるため、必然的に、クラウド環境に存在するDMSからオンプレミス環境に存在するOracleにアクセスできるようにしないといけません。 Direct ConnectやVPNを利用することで安全性は高まりますが、現状、完全に閉じたネットワーク上に存在しているDBの場合、セキュリティ要件を満たすのが難しくなるかもしれません。
DMSの利用料金がかかる
DMSはAWSのサービスであるため、別途、利用料金がかかります。実際に使用したコンピューティングリソース、および、ストレージに対して課金がされます。 料金 - AWS Database Migration Service（データベース移行）｜AWS Oracleのユーティリティを利用する場合はツール自体の利用に追加料金がかかることはないため、コスト的には若干、見劣りしてしまう部分も出てきてしまうかもしれません。
DBのユーティリティより移行が遅い場合がある
DMSはデータを移行する流れの中で、内部的に一度データを変換しています。この分のオーバーヘッドがあるため、移行データ量が多くなればなるほど、Oracle純正ツールの利用と比べて、移行時間の差が顕著になります。 今回は同じ製品間のデータ移行ですが、DMS自体は異なる製品間のデータ移行にも対応しているため、このオーバーヘッドは仕方がないところではあります。
移行に制限がある
詳細は下記ページをご覧いただければと存じますが、サービス特有の制限事項があります。ただし、個人的には、そこまで致命的なものはないと思われるため、移行計画の際に留意していれば問題ないレベルだと感じます。 AWS DMS のソースとして Oracle データベースを使用する - AWS Database Migration Service
まとめ
今回は、少し例を挙げつつDMSについて見てきました。 クローズドな環境で塩漬けしているデータベースの場合、若干、利用ハードルが高くなってしまう部分もありますが、非常に便利で強力なツールであることには変わりありません AWSへのデータの移行方法は他にもありますが、有力候補と言えるのではないでしょうか。
