AWS re:Invent 2024参加レポート#4 AWS re:Invent 2024で発表されたデータベースサービスの細やかなアップデート

本記事は、AWS re:Invent 2024で発表された注目アップデートを解説する連載の第4弾です。今回はデータベース分野について、細やかなアップデートをご紹介します。

前回のブログ記事はこちらです。

今回取り上げるアップデートは、以下のいずれかの軸に当てはまるものとして選定しました。

また、初めてAWS re:Inventについて知る方は、以下の記事も参考になりますのでぜひご覧ください。

DMSにおけるスキーマ変換機能に関するアップデートです。まず、スキーマ変換機能の概要をおさらいし、その後、具体的な利用方法を解説します。

AWSでは以前からデータベース移行を支援するツールとしてDMSとAWS Schema Conversion Tool(SCT)の2つが提供されており、前者はデータの移行を、後者はスキーマやオブジェクトの移行を対象にしていました。その後 DMSにスキーマ変換機能が取り込まれた、という経緯があります。

スキーマ変換機能はその名のとおり、異なるデータベース間の移行においてスキーマを評価し、またスキーマを移行先のデータベースサービスと互換性のある形式へ変換することを支援します。

re:Invent2024で発表された生成AIによるスキーマ変換機能はDMSでのみ利用可能なため、本記事ではDMSを対象とします。またDMSとSCTの混同を避けるため、DMSにおけるスキーマ変換機能をDMS SCと表現します。

前述したように、DMS SCでは移行元のデータベーススキーマ、ビュー、ストアドプロシージャ、ファンクションを移行先のデータベースサービスと互換性のある形に変換できます。また、スキーマ変換の複雑さに関する評価レポートを生成することも可能です。

図1.DMS SCの全体像

出典:AWS Black Belt Online Seminar　AWS Database Migration Service 概要
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2025_Amazon_DatabaseMigrationService_0219_v1.pdf
引用日付:2025/04/14

異なるデータベース間の移行において、特にストアドプロシージャやファンクションなどデータベース独自の手続き型言語(OracleDatabaseであればPL/SQL、PostgreSQLであればPL/pgSQLなど)で作成されたオブジェクトの変換は難易度が高く、移行の大きなハードルになっていました。
今回のアップデートにより、複雑なデータベースオブジェクトの変換において生成AIを利用した推奨事項が提供されるようになりました。これにより異なるデータベース間の移行作業の軽減が見込まれます。

なお本アップデートは記事の掲載時点でOracle DatabaseからPostgreSQL/Aurora PostgreSQL、およびSQL ServerからPostgreSQL/Aurora PostgreSQLへの変換で利用可能です。またリージョンは米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、および欧州 (フランクフルト)に限定されます。

今回はバージニア北部リージョンを利用します。また移行元のデータベースをOracle Database19c、移行先のデータベースをAmazon Aurora PostgreSQL16.6として同リージョンに用意しました。さらに生成AIによる変換を確認するため、弊社のOracle研修コースで利用するデータベースオブジェクトを移行元データベース側に事前に作成しております。弊社のOracle研修コースではPL/SQLの独自構文やOracle PL/SQLパッケージを多く紹介しているため、それらのオブジェクトがどのように変換されるかを確認します。

なおDMS SCのセットアップ手順については以下の公式ブログを参考にしております。ブログは生成AI機能が利用可能になる前のものですが、セットアップ方法には特に影響がないものと考えます。

上記セットアップ手順で"移行プロジェクトの作成”まで行えていることを前提に、DMSスキーマ変換を実行する場面から記載します。

作成した移行プロジェクトを選択し、スキーマ変換のタブから"Launch schema conversion”を選択すると変換ツールが起動します。

図2.スキーマ変換の起動操作

起動すると、このように左側に移行元のOracle Databaseが、右側に移行先にAurora PostgreSQLが表示されます。

図3.スキーマ変換の起動後

最後に生成AI機能を有効化します。※デフォルトでは無効化

図4.生成AI機能の有効化

まずは移行の難易度を図るため、データベース全体を対象にした評価を行います。データベースオブジェクトはPL2スキーマに作成しているため、左フレーム：ソースデータベースプロバイダーのSchemasの中からPL2を選択し、アクションメニューから[評価]を実行します。

図5.DMS SCによる評価実行イメージ

評価が終わると、画面上に変換可能な[データベースストレージオブジェクト] と [データベースコードオブジェクト] の割合が表示されます。[データベースコードオブジェクト] については41%が変換可能、となっています。

図6.DMS SCによる評価結果イメージ

さらに[結果をエクスポート] から[PDF] を選択することで、S3 バケットに評価レポートが出力されます。

評価レポートには、『データベースコードオブジェクトのうち11%は生成AIを使用した変換の候補となる可能性がある』と記載されています。

図7.評価レポートイメージ

次に生成AIによる変換の精度を確認するため、PL2スキーマが持つUPDATE_SALプロシージャを変換します。こちらは評価レポートにおいて生成AIによる変換の可能性が示されたものです。
左フレーム：ソースデータベースプロバイダーのSchemasの中からUPDATE_SALプロシージャを選択し、アクションメニューから[変換]を実行します。実行の際は生成AIによる変換を有効にしておきます。

図8.DMS SCによるオブジェクト変換イメージ

実行後、データベースコードオブジェクトが100%自動変換されましたこと、またアクション項目タブには生成AIが利用された旨が表示されています。

図9.DMS SCによるオブジェクト変換後イメージ1

図10.DMS SCによるオブジェクト変換後イメージ2

実はUPDATE_SALプロシージャにはOracle PL/SQLの独自構文であるFORALLが含まれています。FORALLはPL/pgSQLでは実装されていない構文のため、FORALLを他のコードに変換する例を生成AIが提示したというわけです。

生成AI機能の有無により、提示されるコードの違いを以下に記します。

※FORALL部分に限定

図11.生成AIを無効にした場合のオブジェクト変換例

図12.生成AIを有効にした場合のオブジェクト変換例

生成AIを無効にした場合は"FORALLは未サポート”とだけコメントされていますが、有効にした場合はFORループによるコードを示してくれました。

なお、残念ながら生成AIから提示された変換をそのまま適用しただけではUPDATE_SALプロシージャは実行できませんでした。自動変換された場合でもその後の動作確認が必須であることには変わりありませんが、生成AIからの変換例をベースにすることでオブジェクト変換作業の軽減に繋がる可能性を感じました。

この記事では、AWS re:Invent 2024で発表されたデータベース分野の細かなアップデートに注目してご紹介しました。

AWSのあらゆるサービスに生成AIが組み込まれていくことで、利用者の負担は益々軽くなっていくものと思われます。また同時に、推奨事項を鵜呑みにしてしまわずに、大胆かつ慎重に使いこなしていく必要があると考えます。

アシストでは、データベース移行に関する技術的なご相談をはじめ、AWSサービスの導入支援にも対応しています。データベースに関する課題やAWS導入に関するお悩みがございましたら、ぜひお気軽にご相談ください。