今回は、既存データベース（Oracle、PostgreSQLなど）から Amazon RDS へのデータベース移行手順について解説します。
企業のシステムはデータベースを中心に回っています。
「Webサーバー」や「APIサーバー」など多種のサーバーが企業内で稼働していますが、結局のところ「データをどう見せるか？」という表現の部分で、企業の中心は「データ」になります。（顧客情報、過去の営業情報、日常的に発生する種々のデータ類など）
今まではオンプレでデータベースサーバーを構築するのが主流でしたが、AWS が登場してからデータベースもクラウドに持っていくことが当たり前になってきました。
また、データベースの運用管理など非常に高度なスキルを求められるので、運用管理を一挙に丸投げできるクラウドは各企業にとってもコストダウンにつながると思います。
データベースの移行方法
大きく分けると以下のように2つあります。
- コマンドで移行する ← AWS のサービスを利用せずにコマンドでデータベースを移行する
- AWS DMS で移行する ← AWS DMS（Database Migration Service）というデータベースを移行するツールを利用してデータベースを移行する
Oracle Data Pump（Expdp,Impdp）コマンドでデータベースを移行する
コマンドでのデータベース移行図
※直接既存 DB から Amazon RDS へ Database Link（データベースリンク） を張ってもいいですが、既存 DB への負荷を考えて作業用 EC2 インスタンスを作成しています。（どちらがいいか悪いかは状況により判断されます）
小規模なデータベースや、休日や夜間などある程度システムを停止できるデータベースの場合は、AWS DMS などのサービスを利用せずにコマンドからデータの「エクスポート」「インポート」コマンドや、rsync や scp でのデータ転送でデータベースの移行が可能です。
コマンドでデータベースを移行するメリット
- シンプル
- 全体を移行するので環境が変わらない
- 移行漏れがない
- ある程度作業時間が読める
- トラブルに強い
コマンドでデータベースを移行するデメリット
- サービス（業務）を停止する必要がある
- 一発勝負（移行後に発生する更新データは別途手動でデータベースに反映する）
Oracle から RDS へコマンドでデータを移行する場合
Oracle の場合は「Oracle Data Pump」を利用します。具体的には以下の2つのコマンドです。
- expdpコマンド
- impdpコマンド
ディレクトリオブジェクトと権限が必要
- create directory コマンド
- grant コマンド
expdp/impdp でデータベースを移動する場合の手順
- DB：Oracle
- 作業用ディレクトリ：/home/test/work
- OS アカウント：oracle
サーバーにログインしたら oracle アカウントにスイッチします。
|
$ sudo su – oracle |
SYS ユーザーを使用して SYSDBA 権限で SQL*Plus を起動します。
|
$ sqlplus / as sysdba |
ディレクトリオブジェクト（/home/test/work）を作成します。
|
SQL> create directory EXP_DIRECTORY as ‘/home/test/work’ |
※ディレクトリに権限を割り当てることも出来ます。（読み書き可、読み取りのみ可など）
一旦 exit します。
|
SQL> exit |
データベースをファイル名「test.dmp」、ディレクトリを「/home/test/work」としてエクスポートします。
|
$ expdp test/test_password DIRECTORY=EXP_DIRECTORY DUMPFILE=test.dmp |
dumpデータ（test.dmp）を圧縮します。
|
$ gzip test.dmp |
※gzip はリソースを全て消費してしまうので、nice コマンドと一緒に使用するとシステムへの負荷が掛かりません
nice コマンドで リソース負荷を抑えながら dumpデータ（test.dmp）を圧縮する例です。
|
$ nice -n 19 gzip test.dmp |
rsync コマンドで dump ファイルを「作業用の EC2 インスタンス」に転送します。
転送後に「作業用の EC2 インスタンス」上で、gunzip コマンドで dump ファイルを展開します。
「作業用の EC2 インスタンス」と「移行先の DB インスタンス（RDS）」の間に Database Link（データベースリンク）を作成します。
DBMS_FILE_TRANSFER を使用して、移行元で（expdpコマンドで）エクスポートされたダンプファイルを「移行先の DB インスタンス（RDS）」にコピーします。
DBMS_FILE_TRANSFER .PUT_FILEメソッドを利用します。
impdp コマンドを使用して「移行先の DB インスタンス（RDS）」にデータファイルをインポートします。
DBMS_FILE_TRANSFER を使用して転送されたダンプファイルは削除されずに残るので、最後にクリーンアップしてダンプファイルを削除します。
Database Link（データベースリンク）とは？
データベースリンクとは、複数のデータベースが存在する分散データベース環境で用いられるデータ統合のための仕組みです。
データベースリンクを使用すると、複数のデータベースに分散して存在するデータを1つのデータベース上に存在するかのように扱うことができます。
データベースリンクを利用するためには、データベース間のリモート接続用の Oracle Net Services の構成が完了している必要があります。
Oracle から RDS へデータベースを移行する際は、このデータベースリンクを利用し、「別サーバーの別データベースの別インスタンス」から「Amazon RDS」へリンクを張ります。
その結果、完全に別の DB にも関わらずデータを移行することができるようになります。
【DB】【SQL Server】リンクサーバー（Linked Server）とは
不要なデータは移行しない
不要なデータは移行対象から外すことで移行時間を短縮することができます。
truncate コマンドは、テーブルの中身（データ）を高速に削除することができます。
|
truncate table <テーブル名> |
delete コマンドでもデータを削除することができますが、REDO ログに削除内容が記載されるため、大量のデータを削除する際は時間が掛かることに注意です。
commitを実行する前ならロールバックで元に戻すことができます。
|
delete from <テーブル名> |
AWS DMS（Database Migration Service）を利用してデータベースを移行する
AWS DMS はデータベースを AWS へ移行するためのツールです。
同一のデータベース間（Oracle → Oracle、PostgreSQL → PostgreSQL など）での移行は当たり前のこととして、異種のデータベース間（Oracle → PostgreSQL、PostgreSQL → Aurora など）も可能です。
AWS DMS を利用するメリット
- AWS SCT と組み合わせると異種データベースでも移行ができる（今までは難易度が高かった、もしくは諦めていた）
- サービス停止時間を短縮できる
AWS DMS を利用するデメリット
- トラブルが発生した際の対応ノウハウが少ない（ツールに対する経験が少ない）
- 移行後のチェックに時間が掛かる（結局全部チェックになる？）
異なるデータベース間の場合は AWS SCT（Schema Conversion Tool）を利用する
異なるデータベース間の場合は DMS を利用する前に AWS SCT（Schema Conversion Tool）を利用してストアドプロシージャやシーケンスなどスキーマオブジェクトを移行する必要があります。
当初は SCT を利用するケースとして「異種データベース間」のみでしたが、現在では SCT は同一データベース間でも利用することができるようになっています。
AWS SCT で何ができるのか？
AWS DMS だけでは異なるデータベース間の移行はできません。
AWS DMS はあくまでも「データのみ」移行するツールです。
しかし、Oracle と PostgreSQL などは、データベースで扱う「データ型」などが異なるためそのまま移行しても使えません。
そのため、データ以外の情報（ストアドプロシージャ、シーケンス、トリガー、シノニムなどのスキーマオブジェクト）は、SCT を利用して移行します。
※ただし SCT は異なるデータベース間のスキーマオブジェクトを100％完璧に変換して移行してくれるツールではなく、あくまでも補助的なツールなので別途調査しては手動で変換していくなどの作業が必要になる場合があります。
→あくまでもサポートツールとして考えた方がいいです。
AWS SCT で以下が可能になります。
- スキーマの変換
- アプリケーション SQL の変換（ソース内の SQL 文を解析）
- 各種スキーマオブジェクトの変換（ビュー、ストアドプロシージャ、トリガー、インデックス、シーケンスなど）
- DMS への接続
トリガーとは？
トリガーとは、指定のイベントが発生した際に実行されるプログラム（プロシージャ）のことを言います。
イベントの対象は、「データベース」や「スキーマ」などで、イベントとは、表の変更やビューの変更などのアクションです。
シーケンスとは？
シーケンスとは一意の連続した数値を生成するオブジェクトです。
例えば取引データに付与する「発注番号」や「受注番号」など重複がない一意の連続した番号を生成する場合に「シーケンス」を利用します。
IT用語での「一意」とは、「大量にあるデータから確実に1つの情報が特定できる状態」を言います。
例えば社員番号は必ず「一意」である必要があります。
仮に社員番号「0015」の社員が二人いたら管理できなくなります。
ストアドプロシージャとは？
以下のようなデータベースに格納できるプログラムを総称して「ストアド・プロシージャ」と言います。
- プロシージャ
- ファンクション
- パッケージ
DMS を利用するために準備するもの
- 移行元データベース
- 移行先データベース
- レプリケーションインスタンス
DMS を利用するための要件
DMS を利用するための要件です。
どちらかが AWS 上に存在していること
DMS を利用するためには、「移行元データベース」か「移行先データベース」のどちらかが AWS 上に存在している必要があります。
両方がオンプレミス上に存在している、いずれも AWS 上に存在していない場合は DMS を利用してデータベースの移行はできません。
ネットワークで接続されている
通常 DMS を利用して既存のデータベースを Amazon RDS へ移行しようとする場合は、データーセンターから AWS へ移行するパターンが多いです。
その場合、ネットワークの経路として以下の3種類が挙げられます。
- ダイレクトコネクト（Direct Connect）
- VPN 接続
- インターネット経由
移行元と移行先がファイアウォールでポートが閉じられていないことを確認します。
AWS DMS でどのようにデータを移行出来るのか
AWS DMS は初回に対象のデータベースを移行し、移行後に発生した更新データの差分を継続的に同期する機能があります。
トラブルシューティング
移行時間が以上に遅い場合以下の点を確認します。
- ネットワーク帯域幅 ← 環境によっては、数百GBクラス（数TBクラス）のダンプデータを転送するのに何時間もかかることがあります。
- DB サーバーのスペック ← DB サーバーのスペックが低いとエクスポートに時間が掛かります。
- RDS のインスタンスクラス ← インスタンスクラスが低すぎるとインポート時に時間が掛かります。
- ストレージタイプ ← RDS のストレージタイプが「汎用（SSD）」のままだとインポート時にパフォーマンスが発揮できなくて時間が掛かります。
→ 汎用（SSD） 3,000 IOPS までバースト可能
→ プロビジョンド IOPS（SSD） 30,000 IOPS まで可能
データ移行における一番重要な点
Expdp、Impdp コマンドを使用しても、DMS を利用しても、最終的に一番重要な点は、やり方ではなく「移行後にいかに正確に移行出来ているのかチェックすること」であると思いました。
ここに時間を掛けなければ「データベースを移行できたと思っていたが、実は漏れがあり、デグレーションが発生してしまった」ということになりかねません。
参考図書
Amazon Web Services 業務システム設計・移行ガイドですが、企業のシステムを AWS へ移行する上で何ができるのか？何をどのように AWS へ移行することができるのか？という知識が身に付きました。
内容としては具体的な手順は出てきませんが、設計や要件のまとめ方などが記載されています。具体的な手順は AWS の公式サイトやインターネットに出ているので補完することができます。
Amazon Web Services 業務システム設計・移行ガイド 一番大切な知識と技術が身につく
コメント