Zenn
Google Cloud JapanPublicationへの投稿
🐘

Google Cloud DMS を利用した、Oracle から PostgreSQL へのモダナイズ

ryutaza
2023/12/26に公開
Google Cloud
PostgreSQL
Database
migration
Oracle
tech

DMS Oracle to PostgreSQL
この記事は Google Cloud Japan Advent Calendar 2023 (通常版) の 22 日目の記事です。

TL;DR

  • パブリック・クラウドを利用する際には、PostgreSQL を選択することが、選択肢を広げる重要な要素
  • Google Cloud の データベース移行サービス (DMS) が Oracle から PostgreSQL への移行を 正式サポート
  • コンバージョン ワークスペース機能が追加され、スキーマやストアードプロシージャなどの変換もツール内で一括して実施可能に
  • 生成 AI を利用した変換サポートや、AlloyDB への移行も preview へ

パブリック・クラウドにおける PostgreSQL 選択の重要性

近年パブリック クラウド利用の増加と併せて、OSS データベースを利用するシステムが飛躍的に増加しているように思います。特に複数のクラウドベンダーを使い分けるマルチクラウド戦略を考えると、一部クラウドベンダーへ依存してしまう可能性のある Oracle や SQL Server などの商用 DB エンジンの利用はリスクと捉えられてしまう側面もあるのかもしれません。
OSS DB の中でも、リレーショナル DB では特に PostgreSQL が年々人気を拡大しており、DB-Engines Ranking を見ると主要な DB エンジンの中では近年唯一利用が拡大している DB エンジンとなっています。
DB-Engines
PostgreSQL の魅力について、私が思いつくものを幾つか挙げてみます。

  • オープンなコミュニティによる開発やサポート
    PostgreSQL は主要なリレーショナルデータベースの中で、唯一オープンなコミュニティにより開発されている DB エンジンである点は、一つの魅力です。
    またコミュニティも活発であり、日本だと 日本PostgreSQLユーザ会 の他、業務システム利用に特化した企業団代である PostgreSQL エンタープライズ・コンソーシアム などが有名です。
  • 拡張機能の充実
    PostgreSQL の機能が充実している一因として、拡張機能の開発のしやすさがあります。
    よく利用されているものでいえば、地理情報処理を拡張する PostGIS や 全文検索拡張のpg_bigm、ベクトル検索拡張の pgvector などが PostgreSQL とは独立したオープンソースとして開発されています。
  • 実績
    PostgreSQL を利用した業務システムの実績が多いのも魅力の一つです。
    参考：PGECons / PostgreSQL 導入事例サイト
  • コスト
    もちろんライセンスのコストやオプション選択の手間が不要となる点も、大きなメリットとなります。

この様な状況を反映してか、パブリック・クラウドにおいては PostgreSQL 互換のデータベースサービスに対して、多くの選択肢が提供されています。
標準的なマネージド データベース サービスである RDS や Azure Database、Cloud SQL でサポートされているのはもちろんとして、次世代データベース サービスである Aurora、 水平スケール可能なリレーショナル・データベースである Azure Cosmos DB for PostgreSQL や先日発表された Aurora Limitless Database は、PostgreSQL と MySQL 若しくは PostgreSQL のみの互換性サポートを提供しています。
Google Cloud においても PostgreSQL 互換サービスとして下記のような充実したサービスが展開されています。

  • Cloud SQL for PostgreSQL
    • 多くのデータベース運用を自動化し、アプリケーション開発への集中を可能とする、マネージド・サービス
    • メンテナンスの柔軟なスケジューリングと、短縮されたダウンタイムにより、アプリケーションの可能性向上をサポート
  • Cloud SQL Enterprise Plus for PostgreSQL
    • 標準エディション (Enterprise) と比較して、書き込みスループットが最大 2 倍向上、読み取りスループットが最大 3 倍向上
    • メンテナンスを含む 99.99% の可用性 SLA、2 秒未満へのメンテナンスダウンタイムの短縮
    • 35 日間のログ保持によるより高いレベルのデータ保護
  • AlloyDB for PostgreSQL
    • 標準 PostgreSQL と比較して、4 倍高速なトランザクション スループット、最大 100 倍高速な分析クエリ
    • メンテナンスを含む 99.99% の可用性 SLA、1 秒未満へのメンテナンスダウンタイムの短縮
    • ML 対応の適応型自動パイロット システム
    • 標準 PostgreSQL と比較して最大 10 倍高速にベクトルクエリを実行できる、pgvector 互換検索 (AlloyDB AI)
    • オンプレや他パブリッククラウドでの利用オプションの提供 (AlloyDB Omni, Blog)
  • Spanner (PostgreSQL Interface)
    • 無制限の水平スケーラビリティと強整合性を両立したリレーショナル・データベース
    • 可用性 SLA 99.999 % のクロスリージョンでの DR 構成を実現
    • メンテナンスやスケール、スキーマ変更を ゼロ ダウンタイム、100 % オンラインで実現

上記の状況から、現在パブリック・クラウドを利用する際には DB エンジンとして PostgreSQL を選択することが、選択肢を広げる重要な要素と言えるかと思います。

Oracle から PostgreSQL への DB 移行

既存システムをパブリック・クラウドへ移行する際には、ご利用の既存 DB をパブリック・クラウド上の DB へ移行する作業が含まれます。
パブリック・クラウドにおいて PostgreSQL を利用すると決定されたとして、現在ご利用されている DB が商用 DB である場合には、 PostgreSQL へ移行する異種データベース間の移行をする必要があり、SQL 方言やデータタイプの違いなどへの対応が含まれます。
そのため移行作業では、ソースとターゲットの DB 種別に応じた下記の変換作業が必要となります。

  • データ
  • スキーマ (テーブル, インデックス、ビュー etc.)
  • コードオブジェクト (ストアードプロシージャ, パッケージ etc.)

幸い商用 DB から OSS DB への移行については、特に事例の多い Oracle から PostgreSQL への移行というパターンに対する知見やツールも充実しています。ツールとしては
OSS として提供されている ora2pg や oracle_fdwの他、有償ツールの Striim や Ispirer、Qlik Replicate などを利用することにより、これらの作業の自動化のための支援が受けられます。
この様な中、Google Cloud で提供されている データベース移行サービス (DMS) においても、 Oracle から PostgreSQL への移行が サポート されました。DMS の機能拡張により、下記のような支援が提供されるようになります。

  • Google Cloud に統合されたサーバレスなマネージド サービスであり、容易な設定で DB 移行を実現
  • データ移行を継続的レプリケーション (CDC) 機能により最小限のダウンタイムで実現
  • スキーマ、コードオブジェクトの変換機能を統合。2021 年に Google が買収した CompilerWorks が持つ SQL 変換技術をバックグラウンドとした、強力な自動変換を提供。（生成 AI 技術を組み込んだ変換支援も提供予定）

データベース移行サービス (DMS) による移行の流れ

DMS を用いた DB 移行の全体の流れについて、概要を紹介します。

  1. ソース (Oracle) 構成
    • 継続的レプリケーション (CDC) のため、ソースデータベース上でレプリケーション機能 (LogMinor) の有効化が必要です。
  2. ターゲット (Cloud SQL for PostgreSQL) 構成
  3. 接続プロファイル (ソース/ターゲット DB 接続情報) 作成
  4. コンバージョン ワークスペースによるスキーマ、コードオブジェクト変換とターゲットへの適用
  5. 移行ジョブによるデータ移行
    • CDC 機能により、ソース DB を利用しながら移行が可能
  6. ターゲット (Cloud SQL for PostgreSQL) への DB 切り替え

本ブログでは、新たに DMS へ統合されたコンバージョン ワークスペースについて、より詳細を確認して見たいと思います。

コンバージョン ワークスペースを試してみる

準備

コンバージョン ワークスペースを試すだけであれば、ソース DB (Oracle) とその接続プロファイルがあれば利用が可能です。
ここでは、大まかな準備手法をご案内します。

ソース DB (Oracle) の準備

本ブログでは、Google Cloud の Compute Engine へ Oracle Database XE をインストールした環境を、ソースデータベースとして利用します。
Compute Engine 上へ Oracle Database を導入する場合には、クラウドエース 古田さんのブログ が参考になります。

また移行対象のスキーマとして、サンプル・スキーマ から HR スキーマをインストールして、移行を試してみます。

ソース DB への接続プロファイル作成

ソース DB への接続情報を格納する、接続プロファイルを作成 します。

  1. Google Cloud コンソールのナビゲーションメニューより、[データベース] > [データベースの移行] > [接続プロファイル] を選択
  2. [プロファイルを作成] を選択
  3. データベースエンジンに "Oracle" を選択し、接続プロファイル名、リージョン、DB への接続情報を入力
    プライベート IP アドレスを利用した VPC 経由での接続を行う場合には、事前に DMS の プライベート接続構成 が必要です。
    また画像では system ユーザーを接続に利用していますが、セキュリティ上の懸念がある場合には、権限を絞ったユーザを 準備 して利用することも可能です。
    接続プロファイル入力画面
  4. [続行] を選択
  5. サーバ証明書を利用した SSL/TLS 暗号化通信を利用する場合には、情報を入力
  6. [続行] を選択
  7. DMS と ソースデータベース間の 接続方法 を選択します。今回は VPC 経由でのプライベート IP 通信を想定しているため、[プライベート接続（VPCピアリング）] を選択し、利用するプライベート接続構成を選択
  8. [テストを実行] を選択して、通信テストが無事に完了することを確認
    接続テスト成功
  9. [保存] を選択

コンバージョン ワークスペース作成

準備が整ったら、コンバージョン ワークスペースを作成 します。

  1. Google Cloud コンソールのナビゲーションメニューより、[データベース] > [データベースの移行] > [コンバージョン ワークスペース] を選択
  2. [ワークスペースをセットアップ] > [新しいワークスペースを設定] を選択
  3. ワークスペースの名前と、構成するリージョンを入力し、[ワークスペースを作成して続行] を選択
  4. 先に作成した ソース DB の接続プロファイルを入力し、[スキーマのスナップショットを PULL して続行] を選択
  5. 今回移行対象となるスキーマ HR を選択して、[変換と続行] を選択
    オブジェクトを選択

スキーマ・コードオブジェクト変換

コンバージョン ワークスペースの作成が完了すると、作業画面を確認出来ます。
コンバージョン ワークスペース
左ペインにスキーマのリストと、変換のステータスが確認できます。コンバージョン ワークスペースの変換は全て自動で行われますが、変換の結果として人手による確認や介入を推奨される項目が出る場合があります。
右ペインを見ると、対象のオブジェクトと確認すべき理由の詳細なメッセージが確認できます。
対象のオブジェクトを詳細に見てみます。

  • HR.EMP_DETAILS_VIEW / PostgreSQL does not support CREATE VIEW ... WITH READ ONLY
    ビューについて Oracle でサポートされている CREATE VIEW ... WITH READ ONLY が、PostgreSQLではサポートされていないというメッセージです。ではどの様な自動変換されているのでしょうか？左ペインで対象のオブジェクトを選択し、右ペインで [SQL] を選択すると、2 つの画面でソース側と DMS により自動変換された DDL を並べて比較することができます。
    WITH READ ONLY 句を用いない VIEW の作成が提案されていました。これは妥当な変換結果かと思うので、そのままにしておきます。
    Read only ビューの確認
  • HR.SECURE_DML / Translated Oracle error_code -20205 to CW205
    こちらはストアードプロシージャのエラーコードについてです。こちらも実際のコードを見てみましょう。対象行の前に Warning マークが表示されているのが確認できます。
    ストアードプロシージャのエラーコード
    Oracle と PostgreSQL ではエラーコードの形式が異なるので、PostgreSQL の形式に一致するように変換されていました。こちらも妥当な変換と思われますが、エラーコードを参照しているアプリケーションがあれば調整を行う必要がありますね。
  • HR.SECURE_DML / Conversion between vendor date formats may be imprecise.
    こちらはストアードプロシージャの日付フォーマットについてです。こちらも実際のコードを見てみましょう。
    ストアードプロシージャの SYSDATE
    Oracle の SYSDATE を localtimestamp(0) へ変換しているようです。
    SYSDATE の適切な変換については、様々な場所で議論されているので詳細はそちらにゆずるとして、ここでは localtimestamp() 関数を clock_timestamp() 関数へ書き換える手順を確認したいと思います。
    [Cloud SQL for PostgreSQL の下書き] の SQL を修正し、[SQLを保存] を選択することで、ターゲットへ適用する SQL を修正することが出来ました。
    SQL書き換え

スキーマ、コードオブジェクト適用

ターゲットインスタンスと接続プロファイルの準備ができていれば、変換したスキーマとコードオブジェクトを、コンバージョン ワークスペースを用いてターゲットインスタンスへ適用することが可能です。

  1. コンバージョン ワークスペース にて [対象に適用] > [適用] を選択
  2. [移行先の接続プロファイル] にて、ターゲットインスタンスの接続プロファイルを選択し、[定義して続行] を選択
  3. 適用したいオブジェクトを選択し、[移行先に適用] を選択
    適用オブジェクト選択
    （適用オブジェクトはオブジェクトタイプなどによってフィルタできるので、DMS ジョブ実行によるデータ移行前はテーブルと PK 制約のみを適用するのがおすすめです）
  4. スキーマの適用結果を確認します。
    （画像では事前に一部オブジェクトの適用を完了していたので、重複エラーが発生しています。）
    スキーマの適用結果

まとめ

本ブログでは、Google Cloud データベース移行サービスにて新たにサポートされた Oracle から PostgreSQL への DB 移行機能についてご紹介し、スキーマ、コードオブジェクトの作業スペースとなるコンバージョン ワークスペースについて、詳細な手順まで深掘りをしてみました。

コンバージョン ワークスペースを利用することで、異種データベース間移行におけるスキーマとコードオブジェクトの変換が自動で行え、また確認が必要な項目をフィルタしてリストしてくれることで、作業負担を大きく減らすことが可能となります。
DMS は移行するデータ量に応じた 課金体系 となっています。そのため通常高額なライセンス費用がかかるスキーマ、コードオブジェクト変換ツールが実質無料で利用できるという点も嬉しいポイントです。

DMS は引き続き機能拡充が予定されており、例えばコンバージョン ワークスペースにおける手動での SQL 書き換えに対して生成 AI による支援を提供する Duet AI in DMS for Code Conversion や Oracle から AlloyDB への移行のサポートが予定されています。
これらの機能にご興味がある方は、preview の申し込み をご検討ください。

それでは、よいマイグレーションライフを！

Google Cloud Japan
Google Cloud JapanPublication

Google Cloud Japan のエンジニアを中心に情報発信をしている Publication です。Google Cloud サービスの技術情報を中心に公開しています。各記事の内容は個人の意見であり、企業を代表するものではございません。

Discussion