re:Invent 2024: AWSがAmazon Q Developerで VMwareワークロードの近代化を加速
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Accelerate modernization of VMware workloads using Amazon Q Developer (DOP224-NEW)
この動画では、VMwareからAWSへのマイグレーションを加速するAmazon Q Developerについて解説しています。従来2年以上かかっていたVMwareワークロードの移行作業を、AIエージェントによる自動化で大幅に効率化できることが示されています。例えば、熟練者が2週間かけていたWave計画の作成を15分で完了できるなど、具体的な効果が紹介されています。Amazon Q Developerは、インベントリ収集、Wave計画、ネットワーク変換、サーバー移行までの一連の作業をウェブベースで統合的に管理し、TCSやCognizantなどの大手パートナーからも高い評価を得ています。また、自動化と人による監視のバランスを重視し、重要な意思決定には承認プロセスを設けている点も特徴的です。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon Q Developerによる変革：VMwareからAWSへの移行加速
皆様、本日はAmazon Q DeveloperによるVMwareからAWSへのマイグレーション加速についてのセッションにご参加いただき、ありがとうございます。マイグレーションとモダナイゼーションプロジェクトに対する考え方を大きく変える、エキサイティングな変革についてお話しできることを嬉しく思います。私たちの最高のマイグレーションとモダナイゼーションツールを、プロジェクトの始めから終わりまで、時間のかかる手作業の多くを自動化するコラボレーティブなプラットフォームに深く統合しました。このセッションの終わりには、皆様も私と同じように興奮していただけることと思います。
私はPeter Ramenskyと申します。AWSのMigration and Modernization Servicesのディレクターの一人です。本日はRajesh RathodとAtul Modiも登壇いたします。まず私からAmazon Q Developerプラットフォームについて、高レベルな概念とデザインアプローチについてお話しします。その後、Rajeshがアプリケーションの詳細について説明し、Atulが実際の製品デモンストレーションをエンドツーエンドでご紹介します。このセッションを通じて、Q Developerプラットフォームがマイグレーションとモダナイゼーションの未来をどのように形作るのか、私たちがその未来を形作るために用いている考え方のモデル、そしてVMwareからAWSへのマイグレーションをどのように加速できるのかについて理解を深めていただければと思います。
マイグレーションとモダナイゼーションの新たな考え方
まず、マイグレーションとモダナイゼーションに関する問題をどのように考え、枠組みを作ったのか、その考え方のモデルについてお話ししたいと思います。通常、このようなプロジェクトは、一度きりの大規模なプロジェクトとして捉えられがちです。プロジェクトチームを編成し、そのチームが完了すると、それは独立したプロジェクトとして終わり、メンバーは別の仕事に移っていきます。しかし、これは本来あるべき考え方ではありません。なぜなら、マイグレーションを実行すること自体が、モダナイゼーションのための多くの機会を生み出すからです。
従来、これらのプロジェクトは何らかの切迫した事象に基づいて考えられてきました。例えば、撤退が必要なData Center、12〜18ヶ月後に迫った大規模なライセンス更新、寿命を迎えた古い機器からワークロードを移行する必要性、需要に応じてスケールアップ・ダウンできるより良いインフラが必要な重要なワークロードなどです。このようなプロジェクトに直面すると、プロジェクトチームを立ち上げ、機会とリスクを検討し、数ヶ月から1〜2年にわたる計画を立てます。そして実行し、完了すると成功を宣言して解散し、ビジネス全体の他の重要なプロジェクトに取り組むことになります。
しかし、本来はそうあるべきではありません。なぜなら、マイグレーションを実行すること自体が、さらなる発展への旅の始まりに過ぎないからです。例えば、プロジェクトを完了したばかりだとして、この会話の目的上、そのプロジェクトがVMwareベースのData CenterからAWSクラウドへのワークロード移行だったとしましょう。ここから私の旅が始まります。AWSで実行しているデータベースをEC2インスタンスからAurora PostgreSQLのような自己管理型データベースに移行することを検討できます。.NETアプリケーションのカタログを見直し、それらをWindowsからLinux上のクロスプラットフォーム.NETに移行するモダナイゼーションを考えることもできます。さらに、Linux上のクロスプラットフォーム.NETからLambda、EKS、その他のServerlessインフラストラクチャへの移行を検討することもできます。
これらのワークロードは、データセンターで実行されているか、AWSで実行されているかに関係なく、最適化やモダナイゼーションの機会があります。その実施の判断は通常、優先順位と労力、そして実際にそれらのプロジェクトを実行するためのリソースが現時点であるかどうかにかかってきます。私が考えるに、私たちが構築しているプラットフォームであるQ Developerは、リソースの有無についての質問に対する答えが、ますます「イエス」になっていくことを意味します。なぜなら、より少ない労力で、より少ないリスクで、そしてチーム間のより良いコラボレーションで実行できるからです。
Re:Inventで本日発表するのは、トランスフォーメーションの旅の3つの特定の部分のプレビューです。1つ目は、.NET Frameworkのモダナイゼーションで、.NET Frameworkから.NET CoreのLinux環境への移行です。2つ目は、Mainframeのモダナイゼーションで、COBOLコードをAmazon EC2上で動作するJavaに変換します。そして3つ目が、本日お話しする内容で、VMwareからの移行、つまりVMwareで動作しているデータセンターからVPC上のEC2への移行です。これらの機能は全て、1つのWebアプリケーション内で利用可能になり、Q Developerフレームワークがそのモダナイゼーションプロセスを推進し、チームが1つの空間で協力して作業できるようになります。
移行プロジェクトの複雑さと課題
ここまで、組織がこれらの移行とモダナイゼーションプロジェクトを検討する際に直面する課題について触れてきました。私たちが解決しようとしている問題の種類を理解していただくために、これらの課題について詳しく説明したいと思います。1つ目は複雑さです。複雑さには実際に3つの側面があります。1つ目の側面はインベントリ、つまりデータセンターに何があるのかということです。どのようなサービスがあり、どのようなワークロードが動いているのか、それらのワークロード間にはどのような依存関係があるのか、どのようなデータベースがあり、どのようなファイルストレージがあるのか。そこにある全てのインベントリを理解することです。
複雑さの2つ目の部分は、移行プロセス自体に関するものです。実際にその移行をどのように実行するのか、それはどのように見えるのか、良い移行とはどのようなものか、どのようなツールが関係するのか、サーバーがAWSに移行された時に適切なVPCやサブネットで動作するように、どのようにLanding Zoneをセットアップするのか、といったことです。私たちが解決しようとしている3つ目の複雑さのタイプ、そして企業が課題として感じているのは、組織的なプロジェクトの複雑さです。これらのプロジェクトには多くのステークホルダーが関わっており、重要なインベントリは何か、優先順位は何か、考慮すべき隠れた技術的負債は何か、そして承認が必要な時に承認者をどのように関与させ、チーム間でどのように協力するかについて、それらのステークホルダー間で合意を得る必要があります。
企業がこのような種類のプロジェクトを検討する際に直面する2つ目の課題は、スキルの専門化です。成功するために必要なスキルは何か？移行プロセスを実際に推進する人材が必要です。AWSで実際に運用するにはどのようなスキルが必要か？データセンターと同じセキュリティ、可用性、ガバナンスの体制をどのように実現するか？そしてそこでサービスを運用する方法は？企業がこの作業を行う際の3つ目の課題は、イノベーションの停滞です。これらのプロジェクトは時として大規模で、組織全体から多くの人々の協力が必要であり、一般的に長期間にわたって実行されます - 数ヶ月、時には数年かかることもあります。
これらのプロジェクトに人員を配置することで、ビジネス全体の他の戦略的イニシアチブとの間でトレードオフが生じているのは明らかです。これがイノベーションの停滞です。このイノベーションの停滞について、どのように考えればよいのでしょうか？これらのプロジェクトに対する投資収益率をどのように改善できるでしょうか？このような考えが製品開発の思考に直接反映されました。つまり、これらのリスクや課題を最小限に抑え、プロジェクトを成功に導き、エラーや手戻りによる停滞を防ぐために、どのようなユーザー体験を作り出せるかということです。
Amazon Q Developerプラットフォームの設計原則と機能
ここからプラットフォームの概念レベルの説明に入っていきましょう。Rajeshが後ほど実際の画面とユーザーインタラクションの詳細をご紹介します。私たちはこの製品の開発において、4つの重要な原則を考えました。1つ目は「Goal-driven（目標駆動型）」で、これについては後のスライドで詳しく説明します。2つ目は「より多くの自動化」を実現することでした。
3つ目の要件は「シームレスな統合」で、4つ目は「Human in the loop（人間の関与）」を維持することでした。これら4つの重要なポイントについて詳しく見ていきましょう。
Amazon Qプラットフォームは、生成系AIエージェントによる協調的な移行自動化プラットフォームです。この文章には多くの要素が含まれています。具体的には、Generative AIプラットフォームは、言語モデル自体だけでなく、実際の作業が必要な場合にエージェントに作業を割り当てます。Amazon Qプラットフォームは、Generative AIエンジンによって駆動され、エージェントに作業を割り当てます。この場合、エージェントはVMware Migration Agentで、移行プロセスを実行するという目標が与えられます。この目標は、インベントリの状況やプロセス中の選択に応じて変化する可能性があります。目標は上部の赤い矢印で「移行プロセスを完了してください」として表現されています。エージェント自体はサブエージェントで構成されており、これらも目標駆動型で、大きなエージェントから与えられた目標を実行する2層構造の目標駆動型アプローチとなっています。
これらのサブエージェントは実際の移行ツールとして機能します。ネットワーク内のリソースを発見するInventory Discoveryツール、それらの関連性を把握するWave Planningツール、新しく追加されたNetwork Conversionツール、そしてオンプレミスからEC2インスタンスへの実際のリフト＆シフトを実行する移行ツールがあります。これらのツールの自動化レベルを高めることを目指し、改善の余地があるというフィードバックに基づいて、各ツールの手動ステップの自動化向上に取り組みました。
インベントリ検出に関して、私たちはオンプレミスのデータセンターにおけるワークロードの検出能力を向上させるため、Application Discovery Serviceを見直しました。完全なインベントリを確保するため、追加のネットワークプロトコルの対応と、サーバー検出の精度向上を検討しました。また、インベントリ収集プロセスとしてRVToolsの使用をサポートし、処理できるRVToolsファイルのサイズと複雑さも拡張しました。Wave計画については、アプリケーション間の通信に基づいて、どのサーバーを一緒に移行すべきかを判断するため、数千台のサーバーと複数のワークロードを分析する能力を向上させました。これは、Graph Neural Networkを再トレーニングすることで、より高い精度を実現しました。
ネットワーク変換ツールは、Landing Zoneの設計という時間のかかるプロセスに対応します。お客様とパートナーからのフィードバックに基づき、現在ではサーバー、アプリケーション、ネットワークのインベントリを取得し、VLAN、ルーター、ルーティングルールを検証します。これにより、オンプレミスネットワークからVPCへの直接的なマッピングとなるネットワーク計画を作成できます。これによって、アプリケーションの適切なLanding Zoneを確保するため、VPC、サブネット、ルートテーブル、Transit Gateway、ACL、セキュリティルール、Internet Gatewayなどのコンポーネントを適切に設定できます。移行に関しては、Waveの処理能力も向上させ、1回のWaveで処理できるサーバー数を、初期の40～50台からはるかに大きな数へと大幅に増やすことができました。
これらの優れたツールが素晴らしい機能を持っているなら、次はツール間の連携が必要です。移行プロジェクトでよくあった「ファイルをダウンロードして、加工し、次のツールに合わせて修正してから再度アップロード」といった作業を避けたいものです。私たちは、これらのツールを統合する方法について多くの検討を重ねました。そのアプローチの1つは、データを常に再フォーマットしたり、あるデータストアから別のデータストアに移動したりする必要がないよう、共通のデータストアを作成することです。また、データを受け渡しできるよう、交換フォーマットの標準化にも取り組みました。
現在、インベントリ検出で情報を収集する際、RVToolsからのデータであるかどうかは問題ありません。来年のGA（一般提供）までには、RVTools以外のツールもサポートする予定です。RVToolsやApplication Discovery Serviceから収集したデータは、Wave計画ツールが処理できる共通フォーマットに変換され、Waveを作成します。インベントリをNetwork Conversion Toolに渡してネットワークを作成し、それらすべてをAWS Application Migration Service（MGN）に渡します。MGNは、特定のWaveに含まれるアプリケーションが、どのサブネットにマッピングされるかを判断し、どこにLift & Shiftすべきかを把握できます。このプロセスを端から端まで自動化することで、移行をよりシームレスに実行できるようになりました。
最後にお話しするのは、最後の原則である「Human in the loop（人間の介在）」についてです。Human in the loopとは、プラットフォームがプロジェクトチームのメンバーとコミュニケーションを取ることを指します。これが必要な理由はいくつかあります。まず1つ目は選択です。移行対象の大量の情報をWaveとして収集すると、30～40のWaveになることもあれば、20のWaveになることもあります。現時点では、その20のWaveすべてを移行したいわけではなく、ビジネスにとって今重要なものとして2～3のWaveだけを移行したいかもしれません。
この選択の考え方により、作業可能な項目の全体の中から、現在のプロジェクトで取り組むべきものを決定することができます。これによって、プラットフォーム上でプロジェクトを小さな単位に分割し、複数のプロジェクトを同時に進め、複数のチームに分散させることができます。検証に関しては、私たちが持っているデータの中には非常に正確で確定的なものもありますが、一部は推測的で不完全なものもあります。そのデータから推論を導き出す必要があるため、データの正確性を確保し、チームの専門家にデータを確認してもらい、正しいことを確認するか、場合によってはアプリケーションを別のWaveに移動することを提案してもらうこともあります。
承認も非常に重要な側面です。コストが発生する行動や、取り消すことが難しい行動を取る前には、必ず権限を持つ人からの承認を得る必要があります。VPCのWaveをクラウドに移行したり、数十のVPCやサブネットを含むLanding Zoneを作成したりする前に、それらをすべて元に戻すのは大変です。そのため、まず誰かに確認してもらい、正しいスタートを切れるようにしましょう。後で修正することは常に可能ですが、手戻りを避けるために基本的な部分を正しく押さえておきたいのです。
ダッシュボードは、チームがプロジェクトの状況、進捗状況、停滞している部分を確認できる重要な中心的な場所です。どのVMが移行されたか、どのWaveが移行されたか、どのアプリケーションが移行されたかを確認することができます。チームがプロジェクトの現在の真の状況を確認できる場所なのです。ここで、これらのコンセプトが実際の製品にどのように反映されているかを、より詳しく説明してもらうためにRajeshに引き継ぎたいと思います。
VMware環境からAWSへの移行ニーズと課題
皆さん、こんにちは。Peterが変革プロジェクトにとって重要ないくつかの原則について説明しました。製品の説明に入り、それらの原則が製品にどのように反映され実装されているかをお見せする前に、まず皆さんにお聞きしたいと思います。現在、オンプレミスでVMwareのワークロードを実行している方は何人いらっしゃいますか？手を挙げてください。なるほど、大多数の方ですね。VMwareワークロードをお持ちの方のうち、現在クラウドへの移行プロジェクトを進めている方は何人いらっしゃいますか？
まだプロジェクトを開始されていない方々にお聞きしたいのですが、クラウドへWorkloadを移行する計画をお持ちの方はどのくらいいらっしゃいますか？かなりの数の方がいらっしゃいますね。では、これからご紹介する内容は皆様にとって有益なものになると思います。
この移行の journey において、皆様は決して孤独ではありません。私たちの観察では、何千もの顧客が VMware 上にアプリケーションを構築していますが、現在は代替手段を探しています。Gartner の調査によると、VMware ユーザーの73%が、Cloud Native 環境でアプリケーションを実行できる代替手段を探しているとのことです。また、かなりの数の顧客が、新しいWorkloadや新しいアプリケーションをCloud Native環境で構築しています。
組織内にVMwareの経験者はいるものの、AWSのクラウドスキルが不足している場合、これはインフラストラクチャの変革プロジェクトであり、多くのスキル構築が必要になると感じられることでしょう。VMwareの各テクニカルコンポーネントがAWS環境とどのように接続されるのかを考え始め、さらにすべてのWorkloadの移行の技術的実現可能性を検討し、移行パスを特定する必要があります。これこそが、Peterが言及した複雑さとスキルに関連する課題が浮き彫りになるところです。
これまで私たちは、Workloadをクラウドに移行する方法として、アセスメント計画、移行、モダナイゼーションという従来の手法を使用してきました。これには人が手作業で行わなければならない多くの反復作業が含まれています。 それは労働集約的で、エラーが発生しやすく、コストがかかります。この作業は一人で行うものではありません。多くの人々がプロジェクトに関わっており、お互いに依存関係があり、そのボトルネックが実際に移行を停滞させたり、時には遅らせたりしています。
現在、私たちは多くのツールを使用しています。皆様も、AWSが提供するツールやパートナーが作成した、これらの手作業を自動化するためのツールをいくつか使用されているのではないでしょうか。しかし、まだ実現されていないのは、すべてのツールで共有されるコンテキストを提供し、単一の情報源を持ち、すべての協力者が一つのプロジェクトで一緒に作業できる統一された体験を実現することです。そして、プロジェクトの移行にかかる時間を短縮するための大規模な自動化も必要です。これらのプロジェクトの中には、大規模なVMwareアプリケーション群をクラウドに移行するのに2～3年かかるものもあります。この期間をどうすれば大幅に短縮できるでしょうか？
Generative AIと、主にAgent AIやAmazon Qにおけるイノベーションにより、まさにそれを実現する機会が得られました。 これは、re:inventで発表した製品で、Amazon Q Developerのウェブベースのエクスペリエンスです。これにより、様々な組織や役割のユーザーが一堂に会し、移行プロジェクトに取り組み、クラウドへの移行を超えた変革の旅を継続することができます。
Amazon Q Developerの具体的な機能と利点
この製品には、いくつかの機能があり、それらについて手短にご説明させていただきます。これらの機能の一部は、Peterが説明した原則がどのように製品に実装されているかを明確に示すものです。まず、Amazon Q Developerはウェブベースのエクスペリエンスを提供します。このエクスペリエンスにより、組織内の全てのユーザーと移行プロジェクトを開始することができます。これは単に移行を開始するだけでなく、移行プロセス全体をカバーするものです。このウェブエクスペリエンス上で、プラットフォームの発見、計画立案、移行の実施、依存関係やエラーの特定、承認の取得、進捗の追跡など、全ての作業を行うことができます。
私たちは、数千のお客様のワークロード移行を支援してきた18年間の経験に基づき、AIエージェントを構築しました。これらのエージェントがこのプロセスの大部分の自動化を担っています。変革プロジェクトにおける一部の意思決定には適切なレビューが必要なため、自動化と人による監視のバランスを取ることを重視しています。そのため、これらのタスクには常に人による監視が伴います。Qはスマートにタスクを識別し、ユーザーの入力を促します。特定の自動化タスクに承認が必要な場合、それを識別します。
承認権限を持つ担当者に、そのタスクを承認するための通知が送られます。これが、ここで実装されている人による監視のレベルです。チームコラボレーション機能により、コンサルティングパートナー、AWS Professional Services、VMwareエキスパート、AWSエキスパート、ネットワークエキスパートなど、異なる組織の人々が一堂に会してこの変革プロジェクトに取り組むことができます。この自動化では、チャットによる会話体験と、私たちが構築した全てのエージェントの両方に、Foundational LLMsを活用しています。
では、これはどのように機能するのでしょうか？ このウェブエクスペリエンスは、プロジェクトの目標を定義することから始まります。ここでAmazon Qは、VMwareの変革、.NETの変革、Mainframeの変革、その他のワークロードのいずれを実施したいのかを理解します。目標を設定すると、Amazon Qが計画を生成します。この計画は、私たちがQに既に提供した経験とトレーニングに基づいて作成されます。変革プロジェクトを実行するための計画を提供し、その時点で必要な追加情報の入力を求めていきます。
これから詳しく見ていく一連のエージェントについて、それぞれがどのように実装されているかを説明していきます。移行において重要なのは、すべてのインベントリ設定や変換したい情報リソースのための共通のデータストアを持つことです。Amazon Qを使用すると、そのデータを統合し、お客様のアカウントに安全に保存することができます。このデータは、プロジェクトの計画と変換のためだけに使用され、他の目的には使用されません。Qを使用すると、データを取り込み、解析し、後続のエージェントがその情報を重複作業なく利用できるように標準化することができます。
また、柔軟性も提供します。すでにRToolsを通じてエクスポートされたVMwareのデータをお持ちの場合は、そのファイルを直接アップロードすることができます。リアルタイムのデータが必要な場合は、AWSが提供するデータコレクターをインストールすることができます。これにはエージェントベースとエージェントレスの2つのバリアントがあります。ニーズとユースケースに応じてデータの収集を開始すると、Qは検出したアプリケーション、サーバー、ネットワークの数を特定して要約します。それがソース環境を正確に表していると確信できれば、次のステップに進むか、さらにデータを収集し続けることができます。
移行の第二段階は計画です。ここでアプリケーションの整合性が重要になってきます。移行したい何千ものVirtual Machineが複数のネットワークに分散している場合、依存関係のあるコンポーネントをすべて一緒に移行して、移行完了後にアプリケーションが機能的でパフォーマンスが出るようにしたいものです。このエージェントはまさにそれを行います - すべてのデータとネットワーク接続を分析して論理的な移行グループを特定し、それらのリソースをグループ化します。Qがその計画を生成し、レビューのために提供します。
計画をレビューして問題なければ、移行を開始できます。気に入らない場合は、編集する機会が与えられます。時には、依存関係があっても、ビジネス上の理由で特定のアプリケーションの移行を遅らせたいと考える、ドメイン知識を持つ人がいるかもしれません。そのような編集を行い、計画を再度アップロードすることができます。Qは人間が承認し、入力として提供された内容を理解し、それを使用して次のステップの自動化を開始します。
そして、アプリケーションをAmazon EC2でネイティブに実行したい場合のVMware変換で最も重要で複雑な部分は、ネットワークの変換です。ネットワークスタック、ネットワーク設定、ファイアウォールルールやVLANを含むNSX環境での使用方法は、EC2での運用方法とは大きく異なります。Qができることは、現在のネットワーク設定を提供できるようにし、それをAWS相当のネットワークコンポーネントにスマートに変換し始め、それらの各コンポーネントをInfrastructure-as-Codeとして利用可能にすることです。
Infrastructure-as-Codeでは、Amazon Qが生成したアーティファクトを確認できるリソースが用意されています。Qに自動デプロイを任せることも、アーティファクトを自分でデプロイすることも可能です。また、Qはターゲットアカウントの既存のVPCに接続し、既存のVPCでセキュリティルールやサブネットを設定するか、新規に作成するかを選択できます。選択に応じて、ターゲット環境でこれらのリソースのプロビジョニングが開始されます。これにより、手作業が大幅に削減され、さらに重要なことに、このプロセスで発生する可能性のあるエラーを減らすことができます。
移行作業を開始した同じWebアプリケーションで作業を継続できます。この段階に到達すると、NSXデータを提供するか、RVToolsファイルを使用するかを選択するよう求められます。選択に基づいて変換されたネットワークアーティファクトの作成が開始され、これらのアーティファクトを確認することができます。また、ターゲット環境へのデプロイ方法に関する推奨事項も提供されます。最後に、ネットワーク設定に問題がないことを確認したら、移行オーケストレーションに進むことができます。
移行オーケストレーターは、これらすべてを統合する1つのエージェントです。特定されたインベントリ、Wave単位での選択、移行順序などを理解し、ネットワーク設定や人間が提供したすべての入力、手動での解決が必要なエラーの有無などを確認します。これらすべてが統合されて移行計画が作成されます。この移行計画はAWS Application Migration Serviceのようなリホスト移行サービスで直接利用できるアーティファクトとなり、これらすべての作業を手動で行う必要がなくなります。
この計画はApplication Migration Service（MGN）が利用可能で、クラウドでのリソースのデプロイを開始できます。デプロイされたリソースと進捗状況の更新は、同じWebコンソールで確認できます。このダッシュボードで進捗状況を視覚的に確認できます。ダッシュボードには、移行されたサーバー、Wave、アプリケーション、ネットワークに関する情報と、その進捗状況が表示されます。この視覚的なダッシュボードに加えて、エージェントが実行したすべてのアクションと、人間が実行したすべてのアクションを時系列で確認することもできます。
私たちの重要な原則は、これを監査可能な責任あるAIにすることでした。エージェントが実行したアクション、人間が実行したアクション、そしてどこで人間がエージェントに異なる入力を提供したのかを把握できます。これらの情報はすべてアカウントで確認でき、エージェントの動作が正しいか、あるいはエージェントに異なる指示を提供する必要があるかを判断する際の確信を得ることができます。
私たちは、既存のツールやソリューションを使用してこのような移行やモダナイゼーションプロジェクトを実施してきたパートナーが多数いることを認識しています。AWS Professional Servicesや大手コンサルティングパートナーと協力して、この機能の構築に関する私たちの考え方を共有してきました。彼らからのインプットを参考に、機能の優先順位付けや、同様のモダナイゼーションプロジェクトで何十年もの経験を持つ方々がすぐに使えるような設計方法を検討しました。この機能は、パートナー、お客様、そしてAWS Professional Servicesがご利用いただけます。皆様のアカウントや環境で協力して移行作業を実施することができます。
これらの企業とのパートナーシップに、私たちは大変感謝しています。Suranjan Chatterjeeからは、Generative AIの活用により、VMwareワークロードの移行が新しい時代に入り、複雑さが軽減され、プロセスが簡素化されたというフィードバックをいただきました。そして今では、これらすべてを実現できるようになっています。
TCSが経験した移行の容易さで、前例のないペースで移行プロセスが簡素化されることが実証されています。TCSが特に評価したのは、自動化とResponsible AIのバランスを取りながら、人間による監視を提供している点でした。Cognizantからは、非常に複雑な移行においても、プロセス全体が簡素化され、より迅速に完了できるようになったというフィードバックを得ました。Cognizantはこれを継続的な取り組みと捉えており、移行だけでなく、エンドツーエンドのモダナイゼーションの旅全体でも同じツールを活用できると考えています。
また、具体的なイメージを掴んでいただくためにベンチマークも実施しました。約500台の仮想マシン環境における初期のWave計画作成や依存関係の確認といった、非常に複雑なタスクをいくつか選びました。10年以上の経験を持つ専門家に、手作業と現行ツールを使用して作業を行ってもらい、所要時間を計測しました。Wave計画の作成には、熟練者でも2週間かかっていましたが、このエージェントを使用することで、同じ精度と同じデータを15分で得ることができました。このような効率化により、計画が迅速に利用可能になることで、次のアクティビティへの取り組みがスムーズになります。
ネットワーク変換でも同様の改善が見られました。オンプレミスのルールをすべて確認し、AWS相当のものに変換する作業は、通常なら2週間かかっていたものが、1時間以内で完了し、しかもその時点でレビュー後のリソースもプロビジョニングされていました。これが、私たちが実現している自動化のレベルです。この機能をお客様の環境でどのように活用されるか、そしてご経験やフィードバックをお聞かせいただきたいと思います。なぜなら、これはまだ始まりに過ぎないからです。現在はプレビュー版として提供されており、皆様のフィードバックに基づいてさらに機能を拡充していきたいと考えています。
最後に、デモをご覧いただく前に、この製品がもたらす主要なメリットについてお話しします。それは、より迅速な価値実現です。2年以上かかっているプロジェクトを、はるかに短い期間で完了できるようになります。また、トランスフォーメーションチームの生産性を向上させ、最終的にVMwareから脱却してEC2上でネイティブに実行することで、AWSのライセンスとインフラ支出の両面でコスト削減が実現できます。皆様からのフィードバックをお待ちしております。それでは、Atulをお招きして、実際の製品デモをご覧いただきたいと思います。
Amazon Q Developerのデモンストレーションと今後の展望
Q Developer Webアプリケーションを使用するには、Q Developer Proのサブスクリプションが必要です。AWS Identity Centerのシングルサインオン認証情報を使用してWebアプリケーションにログインできます。アプリケーションにログインすると、Qは自動的にワークスペースを作成し、すぐにトランスフォーメーションジョブの作成に取り掛かることができます。 Qはさまざまなオプションを提示し、移行目標を設定することができます。私はVMwareの移行を目標として選択します。目標を設定すると、Q はVMをEC2に移行するという私の移行目標を要約し、ジョブ名を提供します。自然言語でチャットを行い、ジョブ名を変更してすぐにジョブを開始することができます。
Qが最初に行うことの1つは、ジョブプランの作成です。このジョブプランは、Qがトランスフォーメーションジョブを実行するための詳細なステップのセットです。VMwareジョブの場合、オンプレミスのデータサーバーの検出、移行ウェーブの計画、ネットワークの変換、そして最後にサーバーの移行が含まれます。エージェントがジョブを進めていく中で、学習内容に基づいてこのプランを動的に更新していきます。人間の入力が必要な場合は、いつでもヒューマンインザループの協業ステップが作成されます。例えば、ここではコネクタの作成と選択を求められています。コネクタは、Qが外部リソースに接続するためのメカニズムです。VMwareジョブの場合、これはAWSアカウントとなります。サーバーインベントリやネットワーク構成データを収集するためのソースAWSアカウントの場合もあれば、AWS VPCやネットワークを構成し、EC2インスタンスを起動するターゲットアカウントの場合もあります。ここで新しいアカウントで新規コネクタを作成するか、以前のジョブで作成した既存のコネクタを使用することができます。私は以前設定したコネクタの1つを選択します。コネクタはクラウド管理者がワンクリックで承認でき、すぐに使用を開始できます。
Qで作成したワークスペースで可能なことの1つは、コラボレーターを追加することです。Rajeshが説明したように、これらのコラボレーターには4つの細かなアクセス制御ルールのいずれかを設定できます。閲覧のみの権限、重要なアーティファクトを選択する権限なしでジョブを進める権限、重要なアーティファクトの承認権限、そしてこれらすべてに加えてワークスペースにコラボレーターを追加できる管理者権限です。私は自分のワークスペースにRajeshをコラボレーターとして追加しようと思います。
次に、オンプレミスデータの収集という重要なステップに進みます。RVToolsからのエクスポートデータをアップロードするか、オンプレミスでNSXソフトウェア定義ネットワークを使用している場合は、AWSが提供するオープンソースツールのImport Export for NSXを使用してZIPファイルをアップロードできます。AWSの独自のエージェントを使用してデータを収集したい場合は、AWS Application Discovery Serviceを使用できます。これにより、サーバーインベントリとウェーブプランニングやアプリケーショングループ化に必要なネットワークトラフィックデータが収集されます。ファイルをアップロードしてコレクターをセットアップしたら、移行の計画を開始するためにQにデータを送信できます。
Qはデータを収集し、分析、分類して、その結果をまとめてくれます。特定されたサーバーの総数を表示し、データの品質と完全性も示してくれます。また、接続データがないためアプリケーションウェーブでグループ化されないサーバーの数も示してくれます。これにより、私の移行作業を続行できる状態かどうか、そしてQがウェーブプランニングを進める準備ができているかどうかを理解することができます。準備が整ったら、Qにウェーブの計画を依頼します。Qはグラフニューラルネットワークを使用してウェーブを計画します。これらのウェーブは、アプリケーションの整合性を考慮して計画されます。ネットワークトラフィックデータとサーバーインベントリを使用して、これらのアプリケーションサーバーをグループ化し、推奨事項を提供します。
推奨事項をダウンロードし、グループ分けを変更したり、スコープ外のサーバーを削除したりして編集し、Qに再度アップロードすることができます。ウェーブの準備が整ったら、それをQに送信し、Qはそれを使用してウェーブを計画します。Rajeshが監査証跡の確認について言及しましたが、いつでもWorkタブに移動して、あなた自身、共同作業者、またはQによって実行されたステップの完全な監査証跡を1か所で確認できます。この監査証跡を特定のステップでフィルタリングしたり、詳細な分析のためにダウンロードしたりすることができます。
次に、最も重要なタスクであるネットワーク変換に進みます。ネットワーク変換では、ネットワークがプロビジョニングされる対象のAWSアカウントに接続します。対象のAWSアカウントに接続すると、QはRVToolsまたは以前にアップロードしたネットワーク設定データを使用して、AWS VPC、サブネット、セキュリティグループ、Transit Gateway、Internet Gateway、アカウントへのデプロイメントに必要なすべてのコンポーネントを生成します。QはまたCDKとCloudFormationテンプレートを生成し、それらをダウンロード、レビュー、編集して再アップロードすることができます。Qは生成されたVPCを直接アカウントにデプロイすることも、そのデプロイメントを自分で制御することもできます。ここでQにデプロイを依頼してみましょう。
ご覧の通り、Qは既に移行ウェーブを追加してプランを更新しています。興味のあるウェーブを選択し、各ウェーブに対してEC2の設定を行うことができます。QではEC2インスタンスのサイジングの基準となるパフォーマンスメトリクスを定義し、指定した設定と共にウェーブに関連付けることができます。使用するメトリクスに加えて、インスタンスのテナンシーも指定できます。ライセンスのニーズに応じて、Dedicated TenanacyまたはShared Tenancyのいずれかを選択できます。最後に、Qは生成したすべてのアーティファクト（サーバーとウェーブ、ターゲットネットワーク構成、セキュリティグループを含む）を使用します。
EC2に加えて、ネットワークのターゲット設定、Security Group、そしてインスタンスのサイジング推奨事項を使用して、包括的な移行計画が生成されます。この計画をダウンロードして最終的な編集を行い、Qに再度アップロードすることで、 AWS Application Migration Serviceを使用してバックグラウンドで最終的な移行を実行できます。Qにはダッシュボードタブがあり、ジョブの進捗状況を詳細に確認することができます。各移行Waveのステータス、アプリケーションのステータス、そして各アプリケーションに含まれるサーバーの状態を確認できます。移行実務者やプロジェクトマネージャーは、このダッシュボードを使用して遅延や停滞している移行を特定し、それらを軌道に戻すための対策を講じることができます。
では、スライドに戻りましょう。左側のQRコードからQ Developerの使い方について詳しく学ぶことができ、右側のQRコードからプロダクトプレビューを試すことができます。スナップショットを撮りたい方のために、これを数秒間表示させておきます。
これで私たちのプレゼンテーションは終わりです。皆様がQ Developerを使用してVMwareの移行をスピードアップさせる様子を見るのが本当に楽しみです。Rajesh Rathod、Peter Ramensky、そして私が質問にお答えできますので、ぜひお気軽にお声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion