AWS Database Migration Serviceを使用したデータ移行

 オンプレミスからAWSへ移行をする流れが、エンタープライズシステムにおいて急速に進んでおり、今後、不可逆な流れとなりそうです。システムをAWSに移行しようとする動機には、パブリッククラウドを利用するように会社方針で指示があった、TCO(total cost of ownership)を削減したいというお話をよく聞きます。

 自身が移行のプロジェクトを経験した中では「DBをどう移行しよう」といった質問をよくいただきます。DBエンジンはどうするのか、そもそもデータをどうやって移行するのか、Amazon RDSにするか、Amazon EC2にRDBMSを構築する方がいいのかといったものです。

 そこで、今回は下記目次にそって「AWS Database Migration Service」を使用した移行について説明します。

▼目次
1.AWSで利用するデータベースを決める
2.データ移行の手法を決める
3.データ移行の一例 DMS+SCTでの移行方法を解説







1.AWSで利用するデータベースを決める

 一般的に、Amazon EC2上にDB製品をインストールする場合は、オンプレミスと比較してもコストメリットは出にくいと言われてます。
 (※構築後の運用を変更したくない場合や、OS設定だったりパッチ適用だったりといった柔軟性を取りたい場合は DB on EC2 を選択することになります。)

 一方、Amazon RDSは、バックアップやソフトウェアパッチ適用など、AWSがDBの運用管理タスクを 実行してくれるといった特徴があります。 また、「ライセンス込み」というのを選択できたり、「インスタンス停止」 ができるようになったりと機能改善もつぎつぎと行われています。注意点として、RDSはOSレイヤーの操作が出来なかったり、容量制限があったりと制約がいくつかあります。

(※制限や前提条件の詳細はRDSのユーザーガイドをご確認下さい。)

 そして、DBエンジンが変わると、アプリケーションの改修が必要になります。その場合、工数が大きく変わる要素となるので、慎重に計画が必要です。







2.データ移行の手法を決める

 同一DBエンジンであれば、DB製品標準のエクスポート/インポートツール等で移行が出来ます。ただし移行中はDBを停止しておく必要があるため、サービス停止時間が長くなります。

 そこでサービス停止時間を最小限にし、既存のデータを簡単にAWS上に移行出来る、下記を使ったデータ移行の例を説明します。

  • AWS Database Migration Service
  • AWS Schema Conversion Tool



図1:DMSを利用したデータ移行イメージ

図 1. DMSを利用したデータ移行イメージ 
※オンプレ→オンプレはサポート外



2-1. AWS Database Migration Service(以下DMS) とは

 同一DBエンジン間も異なるDBエンジン間も、既存DBを停止することなく継続的なデータレプリケーションが可能です。停止時間はアプリケーションを切り替えるタイミングのみとなります。


2-2. AWS Schema Conversion Tool(以下SCT) とは

 異なるDBエンジン間(同一DBエンジンでも利用可能)の移行の際、ソースDBのスキーマ、ビュー、ストアドプロシージャ、関数といったデータベースオブジェクトの大部分を自動的にターゲットDB用に変換するツールです。


 ただし、変換するDBエンジンにより、100%変換されるわけではありません。自動変換できないものについてはガイダンスが表示されるので変換時の参考にして下さい。







3.データ移行の一例 DMS + SCTでの移行方法を解説

 それでは、上記で紹介した「 DMS + SCT 」での移行の流れと方法を解説します。

3-1. SCT事前準備

  • SCTインストール(ソース/ターゲットDBに対してネットワーク接続可能なサーバに)。
  • スキーマ変換においてソースDBとターゲットDBに特定の権限が必要となるため、それぞれのDBに権限設定。


3-2. スキーマ変換

  • SCTにてスキーマ変換評価レポート作成。
    ※DMSレプリケーション時のパフォーマンス観点で、この時点ではテーブルとPK程度オブジェクトのみとしておく。
    同種DBの場合は、SCTではなくDB標準のツールでオブジェクト移行でも可。


3-3. ソースDBとターゲットDBへ事前設定(DMS)

  • ユーザアカウント権限やロール設定。
  • CDC(Change Data Capture ※変更があったデータを識別する)用のトランザクションログ設定。


3-4. DMS設定

  • レプリケーションインスタンスを作成。

図2:DMS作成

図 2. DMS作成



  • エンドポイントを作成(ソースDB/ターゲットDBの接続)。
図3:エンドポイント作成

図 3. エンドポイント作成


  • DMSタスク作成(移行対象スキーマ・テーブル等の選択)。



<DMSタスクとして以下の移行タイプを選択可能>

  • 既存のデータを移行する(FullLoad)
    →実行した時点のデータが全て移行される。

  • 既存のデータを移行して、継続的な変更をレプリケートする(FullLoad+CDC)
    →既存のデータ移行と並行して変更が発生したデータをターゲットDBに同期する。

  • データ変更のみをレプリケートする(CDC)
    →変更が発生したデータをターゲットDBに同期する。
     ※事前にFullLoadしておく


図4:タスク作成

図4:タスク作成

3-5. タスクの開始

  • 上記で作成したタスクを開始させる。
    ステータス列がFullLoadの場合「ロード完了」、CDCの場合「レプリケーション進行中」となれば、タスクの実行は正常完了。


3-6. アプリケーション切り替え

  • CDCの場合、移行完了判断用のマーカートランザクションをソースDBで実行。
  • ターゲットDBにマーカートランザクションが反映されたことを確認。
  • アプリケーションをソース→ターゲットDBへ切り替える。
    ※サービス停止を伴うのはここだけ。


3-7. サービス再開

  • DMSタスクの停止。
  • ターゲットDBへの更新開始。



 DMS、SCTとも操作自体は簡単です。ただし、利用においては制限や前提条件を事前に確認しておくことが重要です。制限や前提条件の詳細はDMS、SCTのユーザーガイドをご確認下さい。







さいごに

 RDSへDBを移行し、「RDSはマネージドだから、後の運用はAWSにお任せ!」っというように運用がなくなると勘違いしがちですが、RDSであってもDBA運用業務がなくなるわけではありません。弊社では、データ移行や構築・運用支援の各種サービスを提供しています。

  • RDS for Oracle
    • ORA-XXXX アラート対応
    • Statspack を基に性能分析
  • RDS for MySQL
    • スロークエリログ の解析
  • RDS for PostgreSQL
    • VACUUM処理
  • 共通
    • セッションの切断
    • SQLチューニング

etc...



 下記は、弊社運用支援によるDBアラート対応のイメージ図となります。


図5:アラート対応イメージ

図 5. アラート対応イメージ

著者プロフィール

著者アイコン
元田浩二
CTCテクノロジー株式会社在職中| 1. データベースを中心としたシステムの構築~運用保守までを担当。 昨年度よりAWSにも携わるようになり日々精進中!