【レポート】AWS のサービスを使ったオンプレミスからのデータベース移行 #AWSSummit

オンプレミスにあるデータベースをAWSに移行する際のポイントを紹介します。
2020.09.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、崔です。

AWS Summit Online のセッション「AWS のサービスを使ったオンプレミスからのデータベース移行」を視聴しましたので、レポートをお届けします。
このセッションは、オンプレミスにあるデータベースをAWSへ移行する際に、どのような移行パターンがあるのか、また、AWSが提供するDMSやSCTをどのように利用すればいいのか、について語られています。

セッション情報

スピーカー

アマゾン ウェブ サービス ジャパン株式会社
技術統括本部
ソリューションアーキテクト 新久保 浩二 様

概要

オンプレミスのデータベースを AWS に移行する際の様々なパターンとその移行方法について説明します。 データベース移行の各フェーズで DMS/SCT がどのように活用できるのか、データベース移行を効率化する DMS/SCT の機能の特徴など基礎的なことを理解して頂きます。

資料

Agenda

  • AWSにデータベースを移行する際のパターンと移行方法
    • 今回のセッションでは、例としてオンプレミスのOracleを移行対象とする
  • Schema ConversionTool(SCT)/ Database Migration Service(DMS)の概要
  • SCT/DMSを活用したデータベース移行の具体例
  • まとめ

AWSにデータベースを移行する際のパターンと移行方法

考えられる移行パターン1 : Re-Host

  • 既存のデータベース環境はできるだけ変更せず、そのままクラウド化する
  • データベースのバージョンや運用方法もできるだけ変更しないことで、データベース移行に対するリスクを最小限に抑える

データベースエンジンを変更せず移行する場合

  • Re-HostとRe-Platform
    • Re-Host:EC2にデータベースをインストール
    • Re-Platform:マネージドサービスであるRDSの利用

考えられる移行パターン2 : Re-Architecture

  • 既存データベース環境のクラウド化と合わせて、アーキテクチャー変更も行う
    • 例えば、OracleからAmazon Aurora PostgreSQL に移行する
      • 商用DBエンジンからOSS系DBエンジンへの変更により、ライセンス問題を解決
      • Auroraを利用することで、AWSの他のサービスとも連携
      • ただし、DBエンジンを変えることで、周りのアプリケーションや関連するシステムにも影響あるので、充分に検証が必要
    • 難易度は高くなる

考えられる移行パターン3 : (Re-Host or Re-Platform)& Re-Architecture

  • まずは、DBエンジンを変えずに、オンプレミスからAWSへ移行
  • その後に、AWS上でDBエンジンを変えながら、Re-Architectureをしていく
  • 二段階移行
    • 意外にこのパターンが多い
    • データセンターの契約切れなど、期間の短い中での対応が求められるケースなど

移行パターンと移行方針の整理

  • カットオーバー時に十分な停止時間を取れる場合
    • ソースとターゲットが同一DBエンジンの場合
      • ダンプツールで移行
    • ソースとターゲットが異なるDBエンジンの場合
      • CSVアンロードで移行
  • カットオーバー時に十分な停止時間が取れない場合
    • ソースDBとターゲットDBが同一DBエンジンの場合
      • DB純正のレプリケーションが組める場合
        • レプリケーションで移行
    • ソースDBとターゲットDBが異なるDBエンジンの場合
      • Database Migration Service で移行

移行の流れとAWSで提供するDB移行サービス

  • OracleからPostgreSQLに移行する場合
    • SCT(Schema Conversion Tool)
      • アセスメント、評価の実施
      • スキーマ変換
      • コード変換(プロシージャ、アプリケーション)
    • DMS(Database Migration Service)
      • データ移行
      • テスト

SCT/DMSの概要

SCT

  • データベースのスキーマを変換するツール

DMS

  • データベース上のデータをマイグレーションするサービス
  • ダウンタイムを最小化したデータ移行の実現

SCT/DMSを活用したデータベース移行の具体例

  • オンプレミスのOracleからAurora PostgreSQLへの移行シナリオ
    • 最初の3つのステップをSCTで実施
      • オンプレミス側にSCTをインストールし、DBに接続
    • 後半の2つのステップをDMSで実施
      • VPNやDirect Connectなどのセキュアで安定したネットワークが必要

SCTによるデータベースの移行評価

  • アセスメントレポートが作成される
  • 自動変換できる割合
  • 手動変換が必要な割合
    • 必要なアクションがランク分けされる
  • 自動変換出来ない場合は指摘ポイントが出る

よく指摘されるポイント

  • 主に次の3つ
    • オブジェクトの互換性
    • SQL、ビルトイン関数、データ型の互換性
    • ストアドプロシジャー、ビュー、トリガーなどの互換性

Database Migration Playbook

  • AWSが提供しているDB移行のベストプラクティスのまとめ
  • 手動変換が必要な場合は、参照すること

SCTによるスキーマ、コード変換

  • 左側がソースDBのオブジェクト
  • 右側がターゲットDBのオブジェクト
    • プロシージャのソースコードが表示されている
  • 結果の整合性やパフォーマンスは担保できないので、テストの実施が重要

DMSを使ったデータ移行手順のイメージ

  • DMSインスタンス(レプリケーションインスタンス)を作成
  • ソース、ターゲットのエンドポイントを作成
  • 移行タスクを作成(以下3つから選択)
    • フルロード
    • フルロード + CDC
    • CDCのみ
    • 必要なオブジェクトだけを選択可能

DMSを使った最小限のダウンタイムのデータ移行

  • 初期データ移行(フルロード)の実行
  • トランザクションをチェックし、データ更新(CDC)
  • カットオーバー時にアプリケーションを停止
  • 差分データが適用されたことを確認
  • アプリケーションを再開

DMSのデータ検証機能

  • データ移行とは非同期で実行可能
  • 主キー/ユニークキーが存在するテーブルのみ設定可能
  • ソースDBとターゲットDBのデータの各行が一致しているか確認する

まとめ

  • どの方法がベストか考える
  • アセスメントにSCTが有効
  • SCTでコードオブジェクトを移行
  • DMSでデータ移行
  • データ整合性の検証には時間がかかる

感想

異なるDBエンジンへの移行時には、SCTが非常に便利です。
ある程度、自動変換してくれますし、また、手動変換が必要な場合も、Playbookを確認することで対応方法が分かる場合があります。
DB移行時に重要なのは、パフォーマンステストやアプリケーションが正常に動くかどうかのテストフェーズです。
SCTやDMSを利用することで、このテストフェーズに工数を割くことが可能になるかと思います!