AWS の技術ブログ

全3642件

2026/08/21

AWS Transform の SQL Server から PostgreSQL へのスキーマ検証

本記事は 2026 年 6 月 4 日に .NET on AWS Blog で公開された「 AWS Transform SQL Server to PostgreSQL Schema Validation in .NET Application Modernization 」を翻訳したものです。本記事の執筆には Sayan Ghosh、Yuhao Zhang、Uday Kiran Erukulla、Srinivasa Varadan Saragur Madabhushi、Koushik Rajagopal、Khurram Khawaja、Vikas Babu Gali、Luke Huan が協力しました。 Microsoft SQL Server から Amazon Aurora PostgreSQL – Compatible Edition へのデータベース移行は、ライセンスコストの削減、スケーラビリティの向上、オープンソースデータベース技術の活用を目指す組織にとって一般的なモダナイゼーション戦略です。ただし、SQL Server データベースを Aurora PostgreSQL に移行する際、スキーマ変換はあくまで出発点に過ぎません。真の課題は、すべてのテーブル、制約、ストアドプロシージャ、トリガーが正しく移行され、移行先の PostgreSQL 環境でも同一の動作をすることを検証する点にあります。小数精度の変更をひとつ見落としたり、ストアドプロシージャの変換に誤りがあったりするだけで、本番環境でデータ破損やアプリケーション障害、ビジネスロジックの誤動作を招くおそれがあります。手動でのスポットチェック、スモークテスト、単純な行数比較に頼る従来の移行テストでは、こうした微妙な意味の違いを捉えられません。オブジェクトが存在するかどうかだけでなく、機能的に等価であるかまで検証する体系的なアプローチが必要です。この記事では、 AWS Transform が構造分析、意味検証、動作テストを組み合わせた 3 層の検証モデルによって、SQL Server から PostgreSQL への移行に対する包括的なスキーマ検証を実現する仕組みを紹介します。あわせて、 Amazon Bedrock を活用した AI エージェントが検証結果を分析し、根本原因ごとに問題をまとめ、重大度を判定して修正の優先順位付けを支援する流れも解説します。ソリューション概要 AWS Transform のスキーマ検証は、移行元と移行先の両方を稼働中のデータベースエンジンにデプロイし、そこに対して直接チェックを実行することで、移行済みデータベーススキーマの検証をエンドツーエンドで自動化します。この検証は移行先スキーマの作り方に依存しません。ルールベースのツール、エージェンティックなソリューション、独自に構築した生成 AI (GenAI) 変換パイプラインのいずれで生成したスキーマにも適用できます。図 1 は、移行元と移行先のスキーマが検証ワークフローをどのように流れるかを示しています。図 1. エンドツーエンドのスキーマ検証ワークフロー図 1 のとおり、検証は以下の流れで進みます。移行元の SQL Server スキーマと移行先の PostgreSQL スキーマを、それぞれ専用の Amazon Elastic Container Service (Amazon ECS) コンテナに読み込む両方のスキーマが Tier 1 (構造的検証) に入り、検証ワークフローが各オブジェクトが移行先に存在するかをプログラムでチェックする構造チェックを通過したオブジェクトが Tier 2 に進み、意味的な等価性を比較する意味チェックを通過したストアドプロシージャが Tier 3 (動作検証) に進み、ランタイムでテストする各 Tier がオブジェクトごとの判定 (PASS、FAIL、または WARNING) を出力し、スコアリング層に集約されるエキスパートアセスメントエージェントがすべての判定を確認し、両方の稼働中データベースにクエリを発行してフラグの立った問題を裏付ける。その後、検出内容を根本原因ごとにまとめ、重大度を判定し、最終的な本番移行準備レポートを生成するウォークスルーこのワークフローは、内部的には以下の 5 つのステップとして実行されます。移行元 SQL Server と PostgreSQL の検証コンテナを Amazon ECS 上で起動する移行元と移行先のスキーマを、対応する検証用データベースに読み込む両方のデータベースにクエリを発行してルールベースのチェックを実行する Amazon Strands Agents を使って AI エキスパートによる分析を実行する最終的な検証レポートを生成するこの検証は 2 つの原則に基づいています。正規表現による解析ではなく、稼働中のデータベースを使う。バリデーターは稼働中の各データベースに直接クエリを発行します。生の SQL ファイルの記述内容ではなく、エンジンが実際に解釈した内容を報告します。決定論的な処理を先に、LLM は後に。ルールベースのチェックを大規模言語モデル (LLM) 層より前に実行し、LLM にはフィルタリング済みの入力を渡します。これにより LLM は決定論的なシグナルを置き換えるのではなく、補強する役割を担います。これらの原則のもと、ルールベースのチェックと AI 分析は以下のように動作します。 1. 構造的検証 (Tier-1) 目的 : 移行元スキーマのすべてのデータベースオブジェクトが移行先スキーマに存在することを検証するこの Tier では、移行元と移行先の両方のデータベースに直接クエリを発行し、すべてのスキーマオブジェクトに対してルールベースの存在チェックを並行して実行します。以下の表に例を示します。オブジェクトタイプチェック内容テーブル各テーブルが移行先に存在し、列と NULL 許可のルールが一致することを確認する制約主キー、外部キー (カスケードルールを含む)、一意制約、CHECK 制約を検証する構造の照合で見落としやすい課題が、名前の正規化です。SQL Server は既定で大文字小文字を区別しませんが、PostgreSQL は引用符で囲まない識別子を小文字に折りたたみ、大文字小文字を区別して扱います。さらに PostgreSQL は識別子を 63 バイトで切り詰めます。そのため、SQL Server 上では別名だった 2 つのプロシージャが PostgreSQL 上では同じ名前に統合されることがあり、正しく移行できたテーブルが単純なバイト単位の比較では不一致と判定されてしまいます。これを避けるため、構造の照合では大文字小文字の折りたたみ、切り詰め、引用符の除去という段階を踏んで名前を正規化し、各段階でレコードの正規化を適用します。 2. 意味的検証 (Tier-2) 目的 : 移行したオブジェクトが構造として存在するだけでなく、意味的に等価であることを検証する Tier 1 がオブジェクトの存在を確認するのに対し、Tier 2 はその定義が意味的に等価かどうかをチェックします。チェックはルールベースで、SQL Server と PostgreSQL の型システム間の型マッピングと精度のルールを組み込んでいます。以下に例を示します。チェック例型マッピング nvarchar(100) から character varying(100) への変換は有効。integer への変換は無効数値精度 decimal(18,2) は numeric(18,2) のままである必要があり、numeric(10,0) では不可意味チェックが等価性を捏造することはありません。正規化できない場合 (既定値に互換性がないなど) は、黙って修正を適用するのではなく WARNING を出します。これにより、不要なアラートを増やさずに本番環境での問題を防げます。 3. 動作検証 (Tier-3) 目的 : ランタイムの動作が期待どおりであることを確認する Tier 2 で定義を検証したうえで、Tier 3 では実際のランタイム動作をテストします。2 つのルーチンが構造チェックと意味チェックの両方を通過しても、スタブ、分岐処理のバグ、変換で失われる方言固有の機能などが原因で、異なる結果を返すことがあります。こうした問題を洗い出すため、動作検証は次の 3 ステップで段階的に踏み込みます。ステップ 1: スタブの検出バリデーターは、PostgreSQL 側のルーチン本体が意味のある実装になっているか、それとも BEGIN RETURN 0; END のようなプレースホルダーのロジックだけかを調べます。スタブの生成は自動変換で最も起こりやすい失敗パターンのひとつなので、最初に検出しておくことで後続ステップの無駄な作業を防げます。以下は、変換時に AI エージェントが SQL Server プロシージャから生成した PostgreSQL のスタブの例です。 SQL Server プロシージャ : --SQL Server procedure CREATE PROCEDURE BabelFish.bf_collationproperty @collation_name SYSNAME = 'Traditional_Spanish_CS_AS_KS_WS', @prop_name VARCHAR(255) = 'CodePage' AS BEGIN SELECT COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'CodePage') AS 'CodePage' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'LCID') AS 'LCID' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'ComparisonStyle') AS 'ComparisonStyle' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'Version') AS 'Version'; END; PostgreSQL のスタブプロシージャ : --PostgreSQL stub procedure CREATE OR REPLACE PROCEDURE babelfish.bf_collationproperty(IN collation_name varchar(128) DEFAULT 'Traditional_Spanish_CS_AS_KS_WS', IN prop_name varchar(255) DEFAULT 'CodePage') LANGUAGE plpgsql AS $body$ BEGIN RAISE NOTICE 'Stub: babelfish.bf_collationproperty - needs manual T-SQL to PL/pgSQL conversion'; END; $body$; ステップ 2: 構造の検証バリデーターは両側のルーチンのシグネチャ、入出力パラメータ、戻り値の型を検査し、移行後のアプリケーションで呼び出しエラーを引き起こす構造の不一致を特定します。ステップ 3: ミューテーションテストと LLM による評価バリデーターはテスト入力を生成し、両方のデータベースに対して実行して結果を比較します。行レベルで 1 件でも差異があれば、それが 2 つのルーチンが等価でないことを示す具体的な反例になります。ミューテーションテストで判断がつかない場合は、Amazon Bedrock を通じた LLM による評価で機能的な等価性を判定し、最終的な結論を出します。 4. スコアリング各チェックは、オブジェクトごとに PASS/FAIL または WARNING を出力します。レポートには決定論的な 2 つの主要スコアが示され、同じ入力であれば実行ごとに同じ値になります。 Storage Score – データを保持するオブジェクト (テーブル、インデックス) 全体でのスキーマの一貫性を測る Code Score – 実行可能なオブジェクト (ビュー、ストアドプロシージャ、関数、トリガー) 全体での機能カバレッジを測るこの 2 つの数値で移行のカバレッジを素早く把握できますが、最終的な評価を決めるのはこれらではありません。それを担うのが AI ジャッジ ( LLM-as-a-Judge )です。これは、エキスパートレビュワーとして振る舞う Amazon Strands Agents です。ルールベースのチェックが答えるのは「何が違うのか」です。これに対して AI ジャッジが答えるのは「それは重要なのか、どう直すべきか」です。この AI ジャッジは両方の稼働中データベースに読み取り専用でアクセスでき、フラグの立った問題を裏付けたり否定したりするために自ら検証クエリを発行できます。そのうえで、この Strands Agents が検出内容を根本原因ごとのクラスターにまとめます。たとえば、スキーマがひとつ欠けていることが原因で 29 個のトリガーが欠落している場合、29 件ではなく 1 件のクラスターとして扱われます。各クラスターには次の重大度が割り当てられます。重大度基準 CRITICAL ユーザーデータの損失または破損 HIGH 将来的に気づきにくい障害が起きる、またはアプリケーションからの呼び出しが失敗する MEDIUM アプリケーションが意図どおりに動作しない可能性がある LOW 表示上の問題で、動作を妨げない根本原因ごとにまとめるこのアプローチでは、影響を受けたオブジェクトを個別に列挙するのではなく、大元の問題に対処するためノイズが減ります。共通の原因を修正すれば、そこから派生したすべての症状が一度に解消します。本番移行準備の判定ルール Critical の検出があれば、他のスコアに関わらず本番デプロイをブロックする High のクラスターがあれば条件付きの準備完了となる (追加の検証が必要) Medium と Low の問題は、Critical や High のブロッカーを上書きしないまとめ SQL Server から PostgreSQL への移行は影響範囲の大きい変更であり、テストに合格したというだけでは正しさの証明にはなりません。AWS Transform の 3 層検証ワークフローは、その主張を監査可能な成果物に変えます。Tier 1 ですべてのオブジェクトが移行できたことを確認し、Tier 2 で個々のオブジェクトが意味的に等価であることを確認し、Tier 3 でルーチンが同じ結果を返すことを実際に検証します。さらに AI ジャッジである Amazon Strands エージェントが検出内容を根本原因ごとにまとめ、重大度にもとづいた評価を出すため、主要スコアが高いだけで重大なデータ損失の問題が見過ごされることはありません。まずは最初のスキーマ移行の検証を AWS Transform で試してみてください。詳細は以下のリソースをご覧ください。 AWS Transform Amazon Aurora PostgreSQL Amazon Bedrock Amazon Strands Agents 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文はこちらです。著者について Amit Kachroo Dr. Amit は、Amazon Agentic AI Science チームのシニアアプライドサイエンティストとして、コード変換のための生成 AI および LLM システムを構築しています。さまざまなプログラミング言語やデータベースに対応した変換機能を開発するサイエンスチームを率いています。詳しくは https://amitkac.github.io/ をご覧ください。 Vijay Mandadi Vijay は、AWS Migrations and Modernizations グループのエンジニアリングリーダーです。分散システム、クラウドコンピューティング、仮想化、ワークロード変換、ヘルスケアの分野で 16 年以上の経験を持ちます。AWS では、生成 AI とエージェンティック AI を活用して、お客様のアプリケーションワークロードのモダナイゼーションとクラウドネイティブ化を加速することに取り組んでいます。 Nits Jeganathan Nits は、AWS Transform のプロダクトリーダーです。IT 業界で 15 年の経験を持ち、エッジコンピューティング、システム開発、アプリケーションモダナイゼーションの分野で 12 件の特許と 2 件の論文があります。複雑な課題の解決とカスタマーエクスペリエンスの向上に情熱を注いでおり、現在は生成 AI を使ったレガシーアプリケーションのモダナイゼーション加速に注力しています。

AWS, PostgreSQL, SQL, .NET, SQLServer, 人工知能, テスト, HealthTech, OSS, 大規模言語モデル（LLM）

AWS の技術ブログ

コンテンツ