re:Invent 2025: AWS TransformのAIで.NETとSQL Serverを同時モダナイゼーション
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Modernize SQL Server & .NET Together with AWS Transform's New AI Agent (MAM340)
この動画では、AWS Transformを使用したWindowsベースアプリケーションの最新化について解説しています。Khurram Khawaja、Nits Jeganathan、Vijay Mandadiが、.NET FrameworkからCore 8/10への変換、SQL ServerからPostgreSQLへの移行、EC2 Linuxインスタンスへのデプロイまでを単一プラットフォームで実現する方法を紹介します。Agentic AIを活用したマルチエージェントフレームワークにより、Assessment and Planning Agent、Schema Conversion Agent、Code Transformation Agent、Deployment Agentが連携し、従来5倍の時間を要していたモダナイゼーションプロセスを加速します。Veriskは40%のコスト最適化と4倍の加速を実現し、TeamfrontやCommonwealth Bank of Australiaも採用を進めています。サービスは無料で利用可能で、使用したAWSリソースのみ課金されます。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
AWS Transform による Windows ベースアプリケーションの最新化 - セッション概要と顧客の課題
SQL Server と .NET を AWS Transform で一緒に最新化する。私は Khurram Khawaja です。AWS Transform のプロダクト マネジメントを統括しています。私と一緒に、プロダクト リード の Nits Jeganathan と、シニア マネージャー ソフトウェア開発の Vijay Mandadi がいます。今日は、ほぼすべてのエンタープライズが直面する問題の 1 つについて議論します。それは Windows ベースのアプリケーションをどのように最新化するかということです。このセッションでは、AWS Transform を使用したエージェンティック AI を通じて、UI フレームワークだけでなく .NET コードも最新化し、さらに SQL Server を PostgreSQL に最新化して Linux インスタンスにデプロイする方法についてお話しします。お客様からよく聞く内容をいくつかご紹介し、実際にどのように機能するかのデモをお見せして、その後、内部でどのように機能するのか、そしてエージェンティック AI がどのような役割を果たすのかについて深く掘り下げます。また、お客様の事例もいくつかご紹介し、最後に Q&A で皆様からのフィードバックをいただき、ご質問にお答えします。
お客様とお話しするときに、最新化の取り組みを妨げているものは何かとお聞きします。お客様全体での回答はかなり一貫しています。それはテクノロジーやビジネスの問題ではなく、SQL Server と Windows Server のサポート終了に伴う継続的なアップグレードと更新が必要であり、開発者とリソースが照明を付けたままにするために継続的にアップグレード、更新、パッチを適用し続ける必要があるということです。次に、.NET Framework で実行されているモノリシック アプリケーションが、DevOps、AI、分析統合などのクラウド ネイティブ方法論の採用を妨げています。さらに、アプリケーションがモノリシックであるため、わずかなピーク トラフィックにも対応するために過剰にプロビジョニングする必要があります。コードが非常に古いため、それを継続的に運用するだけでも、トラブルシューティングはより複雑になり、パッチの適用はより困難になります。最後に、コストは確実に要因です。ライセンス コストはほとんどの IT 予算の最大の項目の 1 つです。これらすべての要因が組み合わさって、エンタープライズがイノベーションに焦点を当てることを妨げ、これらのさまざまな要因の負担の下で運用を続けることを強いています。
SQL プロジェクト変換における複雑性 - 複数ペルソナの調整という課題
SQL プロジェクトを変換した場合、最大のブロッカーは一つの部分だけではなく、SQL とデータベースの最新化でもあります。SQL プロジェクトのマイグレーションをアプリケーションと一緒に経験したことがあれば、それは個別のタスクではなく、複数のペルソナと複数の異なる要素が一緒に来なければならない調整されたタスクです。SQL Server の最新化では、まずデータベースが何であるか、異なるクエリが何であるか、それらがどのように異なるアプリケーションに関連しているか、そしてスキーマを変更した場合にどのような影響があるかを理解することから始めます。その後、スキーマ変換に進み、それらの変換の有効性と、自動的に変換できないものに必要な手動作業の量を決定する必要があります。次に、アプリケーションを修正して新しいデータベースまたは新しい PostgreSQL インスタンスに接続します。デプロイして検証し、すべてを 1 つのデータベースずつ実行する必要があります。多数のデータベースとアプリケーションがある場合、このイテレーティブ プロセスを複数のアプリケーション全体で、1 つのアプリケーションずつ続けます。しかし、ここで複雑さが生じます。これは 1 人または限定された数の人が行うのではなく、SQL Server は DBA によって処理され、.NET コードは開発者によって処理されます。
そして、他のチームへのデプロイと検証があります。つまり、これらのすべての異なるペルソナ、異なるチームを一堂に集めて、それが最初から正しく実行され、残りのアプリケーション ポートフォリオ全体で一貫して繰り返されることを確認する必要があります。これは難しいんです。断片化されているんですよ。すべてのチームが異なるルールを使用しています。異なるスクリプトを持っています。異なるメソドロジーを持っているので、すべてを一堂に集めるのは労働集約的です。全体的なプロセスがエンタープライズ全体のモダナイゼーションの障害になってしまいます。
AWS Transform のフルスタック最新化ソリューション - 4 ステップのプロセス
ここで AWS Transform が活躍します。これは、Windows 全体のフルスタックをモダナイズする最初の生成 AI ベースのプラットフォームで、UI レイヤー、.NET コード、データベース モダナイゼーション、そして EC2 Linux インスタンスへのデプロイを含んでいます。これらすべてのペルソナを単一のプラットフォーム上に集めることで、彼らが一緒に働いてモダナイゼーションを最初に完了し、このコーディネーションを加速させ、ペルソナ間の一貫性という退屈なタスクを 5 倍高速化することができます。
アプリケーションを構成するさまざまな要素、バックエンドとフロントエンドの両方の変換全体で一貫性を達成することで、その単一のプラットフォームを通じて数百のアプリケーション全体で繰り返し可能になります。クラウドネイティブまたはモダンなテクノロジーとオープンソース テクノロジーを採用することで、ライセンス コストを削減でき、その結果、運用コストとライセンス コストで 70% の削減が実現します。
歴史的な状態と正確なターゲットがどこにあるかを見ると、左側では .NET Framework というアセットから始まっていることがわかります。本当に古いコード、モノリシック、ほとんどの場合、古いテクノロジーを使用しています。UI レイヤーにはビジネス ロジックとデータ アクセス レイヤーが含まれています。その後、SQL Server があり、すべてが Windows マシンの上で実行されています。AWS Transform を通じたこれのターゲット状態は、クロスプラットフォーム .NET Core 8 または 10 です。UI レイヤーを Razor や MVC Core のようなモダンなコンポーネント駆動型テクノロジーにモダナイズし、データベースを SQL Server からオープンソースの PostgreSQL または Aurora PostgreSQL に変換し、Amazon EC2 Linux インスタンスまたは ECS にデプロイするのをサポートします。
AWS Transform はどのようにしてそれを実現するのか？これは 4 ステップのプロセスです。データベースと .NET アプリケーション間の関係を分析することから始まります。クエリの依存関係を理解し、どのような SQL クエリがあり、それらがアプリケーションにどのような影響を与えるかを正確に理解します。その分析を構築し、SQL から PostgreSQL へのスキーマ変換に続く評価を実行し、セマンティック分析を行って、SQL で持っていたものに適合していることを確認します。また、Amazon DMS（Data Migration Service）を使用してデータを移行することもできます。
第2部、このプロセスの第3ステップは、依存するアプリケーションコードが接続文字列、ORM、その他のSQL依存アプリケーションコードで修正される場所です。これにより、アプリケーションとして PostgreSQL と通信を開始したり、一緒に動作を開始したりできるようになります。最終的には EC2 Linux または ECS インスタンス上にデプロイされ、検証されます。これが正確に何をどのように行うのかについて、より詳しく説明するために、Nits にここに来てこれらのことがどのように機能するかを示してもらうようにお願いしたいと思います。
.NET と SQL Server の統合最新化デモ - ワークフロー全体の実演
皆さん、こんにちは。私の名前は Nits で、AWS Transform for Windows のプロダクトリードです。デモに入る前に、AWS Transform を使ったことがある人、または何らかの知識がある人がどのくらいいるか、手を挙げてもらいたいのです。何人か手が挙がっているのが見えます。良いですね。それでは、AWS Transform を使ったことがない人のために、簡単にコンテキストを説明させてください。
これは録画されたビデオなので、各ステージで何が起こっているかを説明するために、クリックして特定のポイントで停止します。私の仕事の楽しい部分は、デモを進めることです。皆さんの中には、スタック全体にわたる完全なエンドツーエンドの体験を見るのは初めての人もいるでしょう。.NET Framework アプリケーションを .NET 8 または .NET 10 に最新化し、その後、SQL Server から Aurora PostgreSQL への移行方法の体験も示します。
ここで最初に見えるのは AWS コンソールです。これにログインするには、複数のオプションがあります。独自のアイデンティティセンターを作成するか、独自の IDP プロバイダーを使用して認証情報でログインするかのいずれかです。最初に直面するのはワークスペースで、ワークスペースはすべての .NET および SQL 最新化ジョブのコンテナです。 最初のステップはジョブを作成することです。ジョブを作成するときは、異なる機能を持つ複数の異なるエージェントがあります。例えば、メインフレーム最新化エージェントが見えますが、この特定のオーディエンスにとっては、これは Windows 最新化です。ここに来て Windows 最新化を選択すると、2つのオプションに直面します。1つは .NET 最新化で、もう1つは SQL Server です。
レガシーアプリケーションを移行するために、顧客が最初にしなければならないことは、.NET Framework から .NET 8 または .NET 10 への最新化です。したがって、ワークフローの最初の部分で見るのは、.NET Framework アプリケーションを .NET 8 に変換することで、その後、同じアプリケーションを取得して、アプリケーションと SQL Server を一緒に変換するプロセスを実行し、完全に最新化されたスタックを取得します。最新化の部分を選択すると、ここで直面するのは本質的には変換計画です。 これは、AWS Transform が .NET アプリケーションを変換するために実行しようとしているすべてのステップとして考える高レベルの計画です。
まず、ソースコードリポジトリに接続して、リポジトリ全体の依存関係を評価・特定します。リポジトリ内のプロジェクトが他のリポジトリに依存している場合は、その依存関係マッピングを作成して、すべての変換を行います。プライベート NuGet パッケージがある場合も、それらを変換します。ターゲットを .NET 8 にするか .NET 10 にするか、あるいは一部のクラスライブラリは .NET Standard のままにしておくか、そういったオプションをすべて選択できます。
最初のステップは、ソースコードコネクタへのアクセスをセットアップすることです。2つのメカニズムをサポートしています。GitHub、GitLab、Bitbucket、または Azure Repos とのコード接続を使用するか、S3 バケットを使用してソースコードを直接アップロードするかです。 その後、アカウント内のリポジトリを確認します。ここでリポジトリを選択し、どのブランチを使用するか、ターゲットは何かを選択できます。これにより評価を実行できます。数百のリポジトリがあり、例えば 10 個を変換したい場合は、それらを選択してプロセスを進めます。
必要な特定のリポジトリを選択して、変換のために送信します。ここで表示しているのはプライベート NuGet パッケージです。 プライベート NuGet パッケージがある場合、2つのメカニズムをサポートしています。1つは、すべてのプライベート NuGet フィードが Azure Artifacts にある場合、それと直接インターフェースできます。もう1つは、当社からスクリプトをダウンロードして、Visual Studio と同じマシン上で実行し、依存するすべてのパッケージを 1 つの zip ファイルとして収集して、そこにアップロードする方法です。パッケージファイルをアップロードすることで、すべてのパッケージ依存関係を解決できます。
最後に、レビューを行います。ここはあなたの作業セットです。これは変換の入力です。変換したいリポジトリ、依存するリポジトリ、依存するパッケージです。 レビューして承認し、AWS Transform に送信して最新化します。変換が開始されると、本質的には agentic workflow となり、変換したい順序を特定し始め、それらのリポジトリ内の各プロジェクトを 1 つずつ処理していきます。ダッシュボードを使用して、現在何が起こっているかのステータスを確認できます。失敗したリポジトリがある場合は、変換できない理由と、それを修正するための対応する次のステップについての変換サマリーが表示されます。 その後、Amazon Q のようなコーディングアシスタントにそれらを入力して、それらのジョブを完了させることができます。その後、さらに変換を実行して戻ってくることもできます。
つまり、これが基本的に .NET Framework 部分の変換です。これが意味するのは、開始時点では .NET Framework があり、このプロセスを経て、最終的には .NET 8 または .NET 10 アプリケーションが得られるということです。
次のパイプラインのステージは SQL Server の変換になります。これも同じ方法で始まります。 前と同じようにジョブを作成して、いつものように Windows modernization を選択します。ただし、この場合は .NET modernization ではなく、SQL Server の変換では、ジョブを作成して Windows modernization に戻ってきて、.NET ではなく SQL Server を オプションとして選択することになります。変換プランの同じような手順に慣れることになりますが、ここで .NET の場合と比べて 大きな違いに気づくでしょう。ジョブプランには、権限の検証とデータベースへの適切なアクセス権があることを確認することが含まれています。データベースとリポジトリを一緒に確認するオプションがあります。これらすべての評価とウェーブプランを行う前に、評価のシーケンスがあり、これにはすべてのレポートとすべてのデータベースを特定し、それらの間の依存関係を特定し、ウェーブプランを作成し、その後変換を実行することが含まれます。最初のステップは、データベースを扱っているため、必要な前提条件です。適切なロール、権限、および正しいアカウントへのアクセス権があることを確認したいのです。
すべてを検証したら、開始して、コネクタを承認します。 まず、AWS アカウントにすべてのデータベースがインストールされているデータベースコネクタが来て、次の部分はインストールするソースコードリポジトリになります。 すべてを行った後、本質的には、戻らせてください。 はい、そこの領域を選択しています。申し訳ありません。ビデオの制御は難しいので、最初からもう一度やります。ただし、かなり短いビデオなので、速く進めます。では、ジョブを選択して、それを通して進めます。 ソースコードコネクタを通して進み、評価に入ると、少し詳しく話すために停止します。前提条件に到達します。 その後、データベースに進みます。ここは AWS アカウントがある場所で、その後、AWS アカウントの IT 管理者に承認を送る必要があります。その後、ソースコード接続が来ます。ここは以前に変換したソースコードリポジトリがある場所で、両方を 一緒に使用できます。これが完全なスタック modernization の真の力です。アプリケーションとデータベースの両方を変更できます。 その後、オプションのデプロイメントがあります。変換されたアプリケーションをデプロイしたい場合は、それも行うことができます。
すべてのコネクタセットアップ が完了したら、すべての権限の検証を実行したいのです。適切なレベルの権限、ロール、およびすべてのものがあることを確認します。権限がチェックされ、すべてが良好になったら、まず discovery を行いたいのです。AWS アカウント内で、サーバーと対応するデータベース、およびリポジトリも特定できることを確認します。 ここで、変換したいリポジトリと選択したいデータベースを選択するオプションがあります。 その後、評価のために承認します。評価の一部として、 アプリケーションとデータベース間の依存関係を特定し、話したウェーブプランを作成します。この場合、2 つのウェーブがあるのを見ることができます。これらの各ウェーブには、1 つのデータベースと 1 つのリポジトリがあります。これは依存関係があり、独立しているため、2 つのウェーブを作成し、独立して変換されます。これにより、どのチームが協力する必要があり、どのチームが一緒に働いて依存関係を解決する必要があるかの間の分離も保たれます。ウェーブをダウンロードして編集することもできます。依存関係をさらに調整する必要があると思う場合は、編集できます。その後、変換の最初の部分はスキーマ変換です。SQL Server から PostgreSQL への移行の場合、サーバーを確認してすべてのデータベーススキーマを特定し、それらを PostgreSQL 互換スキーマに変換できることを確認したいのです。スキーマ変換は、既存の AWS サービス、特に AWS DMS スキーマ変換サービスを活用して、スキーマを PostgreSQL 互換形式に変換することで進みます。
作成したターゲットクラスタを使用し、スキーマ変換を適用します。
スキーマ変換ステップが完了したら、残りのコア変換と移行が進みます。使用するターゲットクラスタを選択し、スキーマ変換部分の後に変更を加えたい場合は、変換されたスキーマをダウンロードできます。
スキーマ変換は生成 AI メカニズムを使用して実行します。SQL のスキーマを識別して PostgreSQL に変換し、自己デバッグループを実行します。問題が見つかった場合は、それらを自動的に修正します。プロセスの最後に、すべての変換の概要を受け取ります。スキーマが完全に変換された場合は、そのステータスを示します。完全に変換されていない場合は、変換できなかった機能を確認して、変換レポートを活用して自分で修正することができます。
次はデータ移行です。データベースのスナップショットをターゲットクラスタに移行することで、これを検証するオプションがあります。これはオプションのステップです。既存の AWS サービスである AWS DMS を活用し、コンソールへのディープリンクを提供しているので、何が起こっているかのステータスを確認したい場合は確認できます。この場合、データ移行は完了しています。
次はコード変換ステップです。アプリケーションが Entity Framework または ADO.NET コードを使用して ORM でデータベースと相互作用している場合、新しいデータベースを指すようにアプリケーション内で対応する変更を加えます。埋め込み SQL、更新が必要な接続文字列、またはその他の ORM 要素がある場合、これらすべてのものは AWS Transform によって変換されます。これにより、アプリケーション開発者は複数のデータベースチームと協力してスキーマの更新内容を把握する必要がなくなるため、大幅な時間短縮になります。これにより、多くのやり取りが削減されます。
アプリケーションのコード変更をコミットするためのフィーチャーブランチを要求するので、元のソースコードは更新されません。すべての変換レポートはレビュー用に利用可能です。
最後に、ステージをデプロイします。デプロイメントコネクタを使用して、正しい AWS アカウントにデプロイしていることを確認します。ターゲットを設定できます。ECS インスタンスまたは EC2 インスタンスをターゲットとするかどうかを選択し、それらのパラメータを選択します。それが送信されると、これらのアプリケーションをそれらのアカウントにデプロイします。
このプロセスの終わりには、完全に検証されたメカニズムが完成します。アプリケーションが PostgreSQL に変換され、変換されたスキーマを持つ PostgreSQL データベースがあり、それらを組み合わせて検証を実行することができます。これが、単一のワークフロー内で実現できる強力な機能です。
舞台裏のアーキテクチャ - マルチエージェント AI フレームワークの仕組み
デモはここまでです。高いレベルでどのように機能するかをお見せすることができました。そして今から、サービスとしてどのようなことを行っているかについて、舞台裏をお見せします。そうすることで、私たちがサービスとして何をしているのかについて、より安心していただけると思います。そのために、Vijay をお招きします。
製品がどのように機能するかをご覧いただいたので、この機会に、私たちのサービスが舞台裏でどのように機能しているかについてお話ししたいと思います。始める前に、簡単な質問です。Agent、Agentic システム、MCP ツールの経験がある方は、手を挙げていただけますか？かなり多くの方がいますね。では、これはかなり分かりやすいと思います。
舞台裏では、これは動的でゴール指向の Agent で構成される、完全な Agentic AI ソリューションです。このマルチエージェントフレームワークの中心には、Windows Modernization Orchestration Agent があり、これがエンドツーエンドのワークフロー全体を調整する脳として機能します。これは Connector を使用しており、これらの Connector は顧客リソース、AWS アカウント、および Agent 間のブリッジとして機能します。
Agent が主に使用する 3 つの異なる Connector があります。最初のものは Source Code Connector で、ソースコードリポジトリと Agent 間のブリッジとして機能します。Source Code Connector は舞台裏では AWS の CodeConnections というサービスに依存しており、これは Agent がソースコードリポジトリと相互作用し、コードをダウンロードするための安全で確実な方法を提供します。
次に、データベースコネクタがあります。このデータベースコネクタは、顧客のアカウント内のデータベースにアクセスし、それらを検出、評価、変換、移行するために必要なすべてのルールと権限で構成されています。
Orchestration Agent はすべてのシークレットにアクセスでき、これにより、エージェントはソースデータベースと宛先の PostgreSQL データベースの両方に接続できます。また、エージェントがインスタンスをスピンアップし、EC2 クラスタをスピンアップし、アプリケーションをビルドし、変換されたすべてのバイナリをこれらの ECS クラスタに移動して、実際に実行するために必要なすべてのルールと権限を含むデプロイメントコネクタもあります。
Orchestration Agent はまた、複数の特化したエージェントにアクセスできます。Assessment and Planning Agent は、顧客のポートフォリオを評価して、どのアプリケーションが実行されており、どのデータベースと通信しているかを判断する責任があります。これは、エージェントが顧客の環境で検出した内容、アプリケーションのバージョン、および通信しているデータベースの数に基づいてカスタマイズされた動的なプランを生成します。
プランが構築されたら、Schema Conversion Agent は主に、SQL Server のテーブル、ストアドプロシージャ、ビューなどのデータベースオブジェクトを PostgreSQL の同等のバージョンに変換して、すべてのデータベースオブジェクトを移行する責任があります。Orchestration Agent はまた、データ移行ツールにアクセスでき、これはすべてのデータ移行を実行します。スキーマが変換されたら、ソースから宛先へデータを移行できます。
Code Transformation Agent は、アプリケーションの性質に基づいてクエリに使用されている基盤となるフレームワークを特定し、オブジェクトがどのように変換されたかに基づいて SQL クエリを変換し、コードを変換してから、特定のブランチにコミットします。Deployment Agent は、このコードを取得し、ビルドし、顧客の好みに基づいて必要な EC2 インスタンスまたは ECS クラスタを起動し、バイナリをコピーして、アプリケーションをビルドして実行することができます。
このシステムは完全にエージェンティックです。これらすべてのエージェントとツールが連携して、ワークフローを動的にしています。アプリケーションの性質、アプリケーションのバージョン、そして通信しているデータベースの数に基づいて、プランはカスタマイズされ、顧客の好みに基づいて生成されます。 顧客がシステムと行うすべてのインタラクションはチャットを通じて実施されます。Orchestration Agent はチャットエージェントにアクセスでき、これにより顧客は自然言語クエリを提供し、必要な回答を受け取ることができます。
チャットエージェントは基盤となるナレッジベースにアクセスでき、これには AWS に関するすべての知識とジョブの進行状況が含まれています。プロセスを通じて生成されたすべてのレポートとシステムが遭遇したエラーはナレッジベースにコミットされるため、チャットは顧客に次のステップが何かについてのガイダンスを提供できます。チャットエージェントは顧客が遭遇する一般的なエラーにアクセスでき、問題やエラーが発生するたびに、ブロック解除する方法についてのガイダンスを提供して、前に進むことができるようにします。チャットはインタラクティブで、システム内のどこにいるのか、次に何をする必要があるのかを認識しており、必要なガイダンスを提供します。
ワークフローは顧客の好みに基づいて完全にコンポーザブルです。データマイグレーションを選択したり、そのステップをスキップしたり、デプロイメントを実行したり、デプロイメントプロセスを制御したりできます。モダナイゼーション全体のジャーニーはカスタマイズ可能です。これらのエージェントは意思決定を行うことができますが、彼らは何をしているかの可視性も提供し、顧客が必要に応じて検査と介入を行う能力を提供し、生成されるヒントを通じてモダナイゼーションプロセス全体を制御します。
各フェーズの詳細 - アセスメント、変換、デプロイメントの技術的深堀り
全体的なシステムを見てきたので、各フェーズについて詳しく掘り下げてみましょう。最初はアセスメントです。 Assessment and Planning Agent はソースコードリポジトリとデータベースにアクセスできます。彼らはソースコードコネクタとデータベースコネクタを使用して、まずすべての前提条件が適切に設定されていることを検証します。前提条件が不足している場合、チャットを通じて、不足している部分が何であり、ジョブが成功するためにそれらを修正する方法をユーザーに伝えます。
前提条件の検証が完了すると、ディスカバリーを実行します。ソースコードリポジトリに設定されているすべてのアプリケーションを特定し、実行中のすべてのデータベースを検出し、どのアプリケーションがどのデータベースと通信しているかのマッピングを作成しようとします。これを行うにはいくつかの方法があります。エージェントはソースコードを解析して、接続文字列が設定されているかどうか、またはパイプラインで設定されている環境変数があるかどうかを確認し、どのアプリケーションがどのデータベースに依存しているかを特定するのに役立つかどうかを確認しようとします。
また、フォールバックロジックも備えており、ストアドプロシージャ名、ビュー名、テーブル名など、コード内で参照されているデータベースオブジェクトを識別しようとします。ソースコード内でそれを検出し、データベース内でも検出してから、この2つの間でクロスマッピングを作成します。その後、これらのロジカルユニットを形成し、SQL から PostgreSQL へ一緒に変換する必要がある依存アプリケーションとデータベースのロジカルユニットを作成します。
ロジカルユニットが形成されると、エージェントはこのロジカルエンティティを SQL から PostgreSQL に変換する全体的な複雑さを判定しようとします。ソースコードのサイズ、コード行数、データベース内に存在するオブジェクトの数、および SQL と PostgreSQL 間の互換性など、さまざまな要因を使用します。これに基づいて、スコアを計算し、各ロジカルユニットのスコアを計算すると、各ウェーブが SQL から PostgreSQL へ一緒に変換する必要がある依存アプリケーションとデータベースのロジカルユニットで構成される、モダナイゼーションウェーブを作成します。
システムが完全にエージェンティックであるため、顧客は変換方法と実行順序について独自の好みを表現する機会も得られます。自然言語を通じてそれを表現でき、エージェントはユーザーのニーズに基づいてウェーブプランを調整するループに入ります。プロセス全体を通じて、多くのアセスメントレポートが生成され、エージェントがエラーに遭遇した場合、すべてのデータはナレッジベースに一貫して保存されるため、チャットエージェントはユーザーに次に何をすべきか、または自分たちをどのようにブロック解除するかを伝え続けることができます。
アセスメントが完了すると、変換プロセスが開始されます。SQL データベースを PostgreSQL の対応物に変換するには、3つのステップがあります。まず、エージェントはソースデータベースに接続し、すべてのネットワーク情報を取得し、ターゲットデータベースを起動するために必要なロールを判定します。ソースから収集したネットワーク情報に基づいて、デスティネーションクラスタを作成し、PostgreSQL クラスタを設定して、エージェントが通信でき、すべてのデータベースオブジェクトを作成できるようにします。
それが完了すると、オーケストレーターはスキーマ変換エージェントを使用して変換プロセスを開始し、テーブル、ビュー、ストアドプロシージャを PostgreSQL の対応物に変換します。エージェントには、この変換の複雑さと顧客が一般的に遭遇する一般的なエラーに関する知識、およびそれらを修正する方法の例が装備されています。これらの例を使用して、必要なオブジェクトを生成し、検証し、検証が失敗した場合は LLM を使用して再生成し、検証が成功するまで自己デバッグループに入ります。
検証は、対応する PostgreSQL オブジェクトが生成されたら、構文検証を実行することで機能します。これにより、作成されたオブジェクトが PostgreSQL が期待するものと互換性があることを確認します。このプロセス中に、ソースデータベースオブジェクトが何であったか、そして変換されたデータベースオブジェクトが何であるかを示すマッピングファイルも生成されます。このマッピングは、エージェントがソースコード内の対応するクエリを更新するために重要です。
スキーマが正常に変換されたら、オーケストレーションされたエージェントが MCP ツールにアクセスできるオプションのステップがあります。このツールは、内部で database migration service を使用して、SQL から PostgreSQL にデータを移動します。データベース変換が成功したら、オーケストレーターはコード変換プロセスを開始します。コード変換エージェントの場合、アプリケーションのソースコードと、ソースデータベースと宛先データベース間で生成されたマッピングを主な入力として使用します。
アプリケーションが基盤となるデータベースと相互作用する方法には、さまざまなパターンがあります。最も一般的なパターンは、Entity Framework を使用するか、古いプロジェクトの場合は ADO.NET を使用するかのいずれかです。それが何を使用しているかを判断した結果に基づいて、アプリケーションが Entity Framework を使用している場合、エージェントはアプリケーションがどのように構築されているかを理解し、対応するエンティティバインディングを更新して、宛先データベースで機能するようにすることができます。これは、LLM を使用して実行する必要がある変更を判断する反復的なプロセスでもあります。
Entity Framework を設定する方法はさまざまです。一般的なパターンの中には、アノテーションまたは API 呼び出しを使用する方法があります。また、これらのバインディングがソースコードとデータベース間でどのように維持されるかについての情報を持つ XML バインディングファイルと XML 設定ファイルもあります。エージェントはこれらのパターンを判断し、PostgreSQL と互換性を持つようにコードを自動的に更新できます。検証が完了したら、ADO.NET に依存しているアプリケーションの場合、エージェントはコードを解析し、対応する SQL クエリを特定し、それらを抽出し、まずルールベースのエンジンを使用してこれらの抽出されたクエリを PostgreSQL に変換します。
その後、LLM ベースのモデルにフォールバックして、PostgreSQL クエリを生成し、クエリが正確であり、元の SQL クエリと同じ方法で機能していることを検証します。検証は 2 段階です。まず構文検証を実行して、クエリが構文的に正しいことを確認し、その後、生成された PostgreSQL クエリが機能的に同等であり、元の SQL クエリと同じ出力を生成することを確認するために、形式検証メカニズムに依存する機能的等価性検証を実行します。
変換が完了すると、エージェントは変換されたクエリを検証します。また、対応する周辺の .NET コードが期待通りに動作していることを確認する必要があります。 そのために、クエリを置き換えた後、アプリケーションの .NET ビルドを実行します。ビルドが失敗した場合、ビルドエラーを修正し、新しいコードを生成して、ビルドが成功するまでプロセスを再試行するデバッグループに入ります。
このプロセスの中で、エージェントがソースコードに関連するユニットテストを見つけた場合、アプリケーションをビルドしてからそれらのユニットテストを実行します。テストが成功したら、変換されたコードを新しいブランチにコミットします。コード変換が完了すると、デプロイメントプロセスが開始されます。デプロイメントエージェントは、主にターゲットブランチから 変換されたソースコードを取得し、EC2 インスタンスを起動して、アプリケーションをビルドします。アプリケーションがビルドされたら、顧客の 設定に基づいて、EC2 Linux インスタンスを起動するか、ECS クラスタを起動し、ビルドされたバイナリをこれらにコピーして、アプリケーションを起動します。
デプロイメントエージェントは、アプリケーションが起動して実行されていることを確認するために、いくつかの検証ステップを実行します。まず、ヘルスチェックを実行して、アプリケーションに到達可能かどうかを確認します。次に、アプリケーションと基盤となるデータベース間の接続チェックを実行して、顧客が自動テストスイートまたは手動テストを使用してテストを続行できるようにします。これは反復的なプロセスであり、顧客はコードをチェックアウトして、対応する変更を加えて、ブランチにコミットし直すことができます。エージェントは常に最新のコードを取得し、バイナリをビルドして、起動された EC2 Linux インスタンスまたは ECS コンテナにコピーし直すため、顧客はテストを続行できます。
顧客事例とパートナーシップ - 実績と今後の活用方法
これが、フルスタック Windows モダナイゼーションがどのように機能するかについての高レベルの概要です。顧客がシステムをどのように使用してきたか、そして彼らが提供したフィードバックに基づいて、これからそれらの詳細について議論するために Khuram に引き継ぎます。ありがとうございました BJ。2つの重要なことを強調したいと思います。まず、このフルスタック Windows モダナイゼーションは、今日、EC2 Linux でホストされている SQL Server と RDS で利用可能です。次に、さらに重要なことに、このサービスはあなたにとって無料で利用可能です。これらのエージェントを使用するために料金を支払う必要はありません。EC2 インスタンスや PostgreSQL クラスタなど、使用するリソースに対してのみ料金を支払いますが、エージェンティックワークフロー全体と AWS Transform を通じたアクセスは追加費用なしです。これがあなたを試してみるのに興奮させることを願っています。
顧客フィードバック と私たちが取り組んできたことに基づいて、Verisk はそのうちの1つです。Verisk は保険業界にいて、顧客にテクノロジーソリューションを提供しています。彼らは、このフルスタック Windows モダナイゼーションの組み合わせにより、モダナイゼーションのタイムラインを4倍加速させながら、約40%のコスト最適化を実現できると期待しています。Teamfront は AWS Transform for .NET の早期採用者である別の顧客です。彼らは Framework からCore へのモノリシックアプリケーションの変換に成功しました。UI ベースの変換のベータ版にも参加し、Web Forms を Blazor に変換することができ、現在は SQL から PostgreSQL への変換を検討しており、複数のステップの代わりに、フルスタック モダナイゼーションを組み合わせたステップとして実行できるようになります。Commonwealth Bank of Australia も、モダナイゼーションを加速させる方法全体の変換を検討しており、AWS Transform により、その道筋が見えています。
AWS Transform は、組織がモダナイゼーションの目標を数年ではなく数ヶ月で達成するのに役立つパスを提供しています。私たちは、Kalin Technologies、Presidio、Evolved Tech Systems などの主要なローンチパートナーと協力してきました 。彼らはデータベースマイグレーションに関して私たちと一緒に取り組むのを支援してくれています。彼らから聞く重要な洞察は、コードモダナイゼーションとデータベースモダナイゼーションを一緒に行うことで、異なるペルソナが関わる複数のトランスフォーメーションステップを経るのではなく、より効果的で最適化された方法で顧客との作業を加速させることができるということです。
私たちの観点からは、QR コードをスキャンして AWS Transform にアクセスし、ソリューションがどのように機能するかについてさらに詳しく理解することをお勧めします。インタラクティブなデモを見て、ソリューションがどのように動作するかを正確に確認することができます。 このトピックに関するより具体的なセッションに参加することもできます。.NET コードトランスフォーメーションと SQL Server から PostgreSQL への変換の方法を含む、フルスタックモダナイゼーションプロセスの各ステップについて説明するワークショップを開催する予定です。
より詳細な情報が必要な場合は、QR コードをスキャンして SkillBuilder にアクセスし、AWS Transform のトレーニングを受けることができます。 最終的に、私たちはあなたと一緒に仕事をするためにここにいます。フィードバック、コメント、または私たちがより良くすべき領域、あるいは課題の解決をお手伝いできる領域があれば、ぜひお気軽にお問い合わせください。私たちはいつでも対応可能で、あなたのリクエストから逆算して対応します。 ありがとうございました。これからご質問をお受けします。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion