Amazon Web Services ブログ

Amazon Q Developer transformation capabilities for VMware を使ってみる

本稿は、2024 年 12 月 3 日に Migration & Modernization AWS Blog で公開された “Getting started with Amazon Q Developer transformation capabilities for VMware” を翻訳したものです。

本ブログでは、Amazon Q Developer transformation capabilities for VMware の利用開始方法をご紹介します。Amazon Q Developer は、ソフトウェア開発ライフサイクルのエクスペリエンスを再構築し、AWS 上でのアプリケーションの構築、セキュリティ、管理、最適化をより簡単かつ迅速に行う、ソフトウェア開発のための AI アシスタントです。18 年にわたる AWS の専門知識に基づき、Amazon Q Developer transformation capabilities for VMware エージェントは、自然言語を使用して VMware ワークロードを移行し、最新化するための、よりシンプルで迅速なアプローチを組織に提供します。

本稿では、開始にあたって必要な全てをカバーし、新しい Q Developer ウェブエクスペリエンスを使用した移行について説明します。最後に、Amazon Q Developer によって一連の移行が我々のリホストソリューション、すなわち AWS Application Migration Service (MGN) にどのように統合されるかを紹介します。

前提

  1. Amazon Q Developer 利用のための Amazon Q Developer Pro Tier Subscription
  2. 新しいウェブエクスペリエンスへのフェデレーションのための AWS Identity and Access Management (IAM) Identity Center のセットアップ
  3. 全てのディスカバリデータを格納する AWS アカウントである VMware discovery アカウント
  4. 変換されたリソースのデプロイ先となる VMware infrastructure provisioning アカウント。これは discovery アカウントと分ける必要はありませんが、本番環境として移行することを推奨します。
  5. vCenter Server からの csv 形式の RVTools 出力ファイル (xlsx 形式はサポートされておらず、csv 形式のみ)
  6. VMware NSX を利用されている場合は、ネットワーク設定とルールを変換することができます。そのためには新しい Import/Export for NSX ツールで NSX の設定情報を出力する必要があります。詳細はブログ記事 “Exporting network configuration data with Import/Export for NSX” をご確認ください。

Amazon Q Developer で VMware 変換ジョブを実行する

  1. ワークスペースの作成

    Amazon Q Developer ウェブエクスペリエンスにログインすると、ワークスペース名を指定してワークスペースを作成するよう指示されます。任意の名前を付けることができますが、移行プロジェクトに関連する意味のある名前を付けることを推奨します。ワークスペースを作成すると、右上に自分のイニシャルとプラス(+)のアイコンが表示されます。同じ Identity Center アカウント内の共同作業者を追加するには、プラスアイコンを選択してください。

    null
    図 1: Amazon Q Developer for VMware ワークスペース

    以下のいずれかのロールを共同作業者に割り当てることができます。まずロールを選択し、Invite をクリックしてください。

    • administrator – ワークスペースへのフルコントロールアクセス
    • approver – pending 中のアクションを承認できます
    • contributor – Q Developer と会話し、承認不要のクリティカルではないタスクを実行できます
    • view only – ワークスペースの閲覧ができますが、一切の変更はできません

    null
    図 2: 共同作業者をワークスペースに追加する

  2. ジョブの作成

    共有ワークスペース内で、あなたと共同作業者は変換ジョブを開始することができます。Ask Q to create a job を選択し、進んでください。

    null
    図 3: Q Developer に依頼して新しい変換ジョブを作成する

    VMware 仮想マシンを Amazon EC2 に変換するには、自然言語を使用して Q Developer で利用可能なさまざまな生成 AI エージェントのジョブを作成するか、利用可能な変換ジョブの 1 つをチャットで選択します。

    VMware と入力して次へ進みます。

    null
    図 4: 変換の選択

    この時点で、自動生成されたジョブ名を受け入れるか、あなたが指定した名前を使うように Q に依頼することができます。この例では、Name it “VMW-to-EC2 Job #1” と入力し、Q にジョブ名の変更を依頼しています。

    null
    図 5: 新しい VMware 変換ジョブの名前変更を Q に依頼

    名前を変更してもよいことを yes と入力して確認し、Create job を選択することで Q Developer が新しいジョブプランを作成します。ジョブプランは、移行を順を追って説明するガイド付きのステップバイステップの手順です。Q Developer はジョブの進行中に必要に応じてプランを更新します。

    null
    図 6: 新しいジョブを作成

    Q Developer が新しいジョブプランを提示します。

    null
    図 7: Q Developer によるジョブプラン提示

    Q のアクション監視

    ジョブを作成した後、どのセクションの Worklog タブに行っても、エージェントやユーザーが実施した全てのアクションを確認することができます。

    null
    図 8: Worklog で Q Developer のアクションを監視

  3. discovery アカウントと接続

    ここで、エージェントが移行の推奨を生成できるように、ディスカバリデータが保存され、後で取得される AWS アカウントへのアクセス権を Q Developer に付与する必要があります。このアカウントは、VMware discovery connector AWS アカウントと呼ばれます。ワークフローの後半では、VMware infrastructure provisioning connector (ターゲットアカウントとも呼ばれ、デプロイされたインフラストラクチャを含む AWS アカウント) を提供するよう求められます。ワークスペースは、最大 10 個の VMware connector (5 個の VMware discovery connector と 5 個の VMware infrastructure provisioning connector) を持つことができます。

    Connect AWS account for on-premises discovery data タスクでは、タスクに既存のコネクタを使用するか、新しいコネクタを作成することができます。ここでは、VMware discovery connector AWS アカウントのアカウント番号を入力し、Create Connector を選択し、Send to Q を選択して、新しいコネクタの作成を進めます。

    null
    図 9: 新規コネクタの作成

    コネクタの設定が完了したので、ジョブプランを進め、Perform discovery を選択します。

    null
    図 10: Next Step – Perform discovery

    Choose ZIP file を選択し、RVTools でエクスポートした ZIP ファイルをアップロードします。.xlsx ファイルはサポートされていませんので、.csv ファイルを含む RVTools ZIP ファイルをアップロードする必要があります。アップロードに成功したら、Send to Q を選択します。

    null
    図 11: RVTools ファイルのアップロード

    ZIP ファイルをインポートした後、Amazon Q Developer transformation capabilities for VMware エージェントは、検出された全サーバーのクイックサマリーを提供します。このデータは、VMware discovery connector AWS アカウントに保存されます。検出されたサーバーを元の RVTools ファイルと比較したい場合は、検出されたデータを確認し、サーバーリストをエクスポートすることができます。

    先へ進むには、Continue with existing data を選択し、Send to Q を選びます。Q Developer が全てのサーバーのアプリケーショングルーピングを生成できない場合は、その旨が通知され、再評価のためにさらにデータを収集するためのオプションが提供されます。

    null
    図 12: 検知データのサマリ

  4. 検知データの確認

    オプションの AWS Application Discovery Service (ADS) Agentless Collector を使用すると、Q Developer はアプリケーションを自動的にグループ化できます。Amazon Q Developer transformation capabilities for VMware は、アプリケーションのグルーピングとウェーブで対応する移行プランを作成します。この機能を使用するには、VMware discovery connector AWS アカウントに ADS Agentless Collector をインストールして設定する必要があります。そうすることで、Q Developer は ADS によって提供される検知データを自動的に認識します。

    null
    図 13: Q による ADS Agentless Collector と AWS Discovery Agents の統合

    ADS Agentless Collector を使用しない場合でも、手動インポート機能を使用して VM をグループ化し、アプリケーションをマッピングできます。ただし、アプリケーションのコンポーネント間の相互依存関係をマッピングするには TCP ネットワークデータが必要なため、複雑な依存関係のマッピングはできません。

    Q Developer では、RVTools インベントリファイルをインポートして、オンプレミスのサーバーデータを検出することもできます。この場合、サービスによって提供される事前設定済みファイルを修正してインポートすることによって、Q Developer にアプリケーションのグループ化と移行ウェーブを提供する必要があります。このプロセスの動作については、この記事の後半で説明します。

  5. 移行ウェーブの計画

    次にアプリケーションを特定し、それらを移行ウェーブにグループ化します。このプロセスでは、検出されたサーバーをアプリケーションと移行ウェーブに関連付けます。Amazon Q Developer transformation capabilities for VMware では、アプリケーションの名前とそれに応じた移行ウェーブを追加することが可能な、移行計画テンプレートファイルを提供しています。ADS Agentless Collector を使用した場合、ファイルにはアプリケーション名と推奨されるウェーブが事前に入力されています。そうでない場合は、各 VM のアプリケーション名とウェーブを手動で入力する必要があります。移行計画立案の一環として、移行スコープからサーバーを削除する必要があるかもしれません。これらはファイルから手動で削除できます。変更するつもりがなくても、Q Developer はアップロードしたファイルに対してのみ動作するため、ファイルのアップロードは必須です。

    Download file を選択し、ウェーブ計画ファイルをダウンロードします。

    null
    図 14: ウェーブ計画テンプレートのダウンロード

    ウェーブ計画ファイルが更新されたら、Choose file を選択して Q Developer にアップロードすることができます。アップロードが完了したら、Send to Q を選択します。これで、アプリケーションのグループ化とウェーブタスクの確認が完了します。

    null
    図 15: ウェーブ計画テンプレートのアップロード

  6. ターゲットアカウントへの接続

    これで移行ウェーブが設定されたので、次に進み、Q Developer エージェントに移行のターゲットとなる AWS アカウントへのアクセスを許可することができます。ターゲット AWS アカウント、もしくは VMware infrastructure provisioning connector にてリソースを保持します。

    新しく provisioning connector を作成するには、AWS アカウント ID を入力し、Create connector、そして Send to Q を選択します。

    null
    図 16: VMware infrastructure provisioning アカウントの設定

  7. NSX もしくは RVTools のネットワークデータを取り込み、ネットワークを移行

    Q Developer は、VMware NSX や RVTools から収集したデータを分析し、現在の仮想ネットワーク構成を理解します。その後に、Large Language Models (LLM) を使用して、これらのオブジェクトを AWS VPC、サブネット、セキュリティグループ、NAT ゲートウェイ、トランジットゲートウェイ、インターネットゲートウェイ、Elastic IP、ルート、ルートテーブルなどの対応する AWS 構成に変換します。VMware NSX を実行している場合は、Import/Export for NSX を使用してネットワーク構成のコピーをエクスポートし、Q Developer にインポートすることができます。詳細については、AWS ブログ Exporting network configuration data with Import/Export for NSX をご参照ください。エクスポートツールは ZIP ファイルを出力しますので、この段階でアップロードしてください。VMware NSX を使用している場合、Q Developer は NSX エクスポートを行わないとサブネットとセキュリティグループを作成できません。VMware NSX を使用していない場合は、検出フェーズでアップロードした RVTools ファイルを使用できます。

    プロビジョニング用のAWSアカウントを接続すると、Q Developer は既存の VPC を検出します。検出された場合、既存の VPC を利用するか、新しい VPC を作成、デプロイするかを選択することができます。

    オンプレミスのネットワークが同等の AWS ネットワーク構成に変換されると、Q Developer は適切な AWS ネットワーク構成を持つ Infrastructure-as-Code ファイル (CloudFormation および CDK) を生成します。ネットワークコンポーネントがデプロイされると、エージェントはインフラストラクチャが適切にデプロイされていることを検証します。また、生成されたネットワーク設定をダウンロードして確認、編集し、更新されたバージョンをプロビジョニング AWS アカウントに直接デプロイすることもできます。エージェントは、AWS 上のネットワークリソース間の接続性を検証する AWS VPC の機能である AWS Reachability Analyzer を使用して、ネットワークのデプロイを検証します。

    アップロードを開始するには、Upload ZIP file を選択します。ネットワークデータをアップロードすると、それが Import/Export for NSX からであっても RVTools からのものであっても、新規にアップロードされた ZIP file を選択できるようになります。最後に Send to Q を選択します。

    null
    図 17: ネットワーク設定のインポート

  8. VPC のデプロイ

    ネットワーク分析が完了したら、エージェントを使用してプロビジョニング AWS アカウントに VPC を自動的にデプロイできます。そのためには Use Q to deploy the VPCs を選択します。手動でデプロイする場合は、生成されたネットワークを確認することもできます。Generated CDK のリンクをクリックすると、プロビジョニング AWS アカウントの S3 バケットに移動します。このバケットには、VPC 構成を生成するための AWS CDK と AWS CloudFormation コードが含まれています。

    null
    図 18: Q Developer により生成された VPC の確認

    Q Developer は、target provisioning AWS アカウントの追加の VPC 構成オプションを提供します。高度なセキュリティ監視のために AWS Marketplace からサードパーティのファイアウォールを統合したり、IP アドレス空間を効率的に管理するためにサードパーティの IPAM アプライアンスを統合したりすることができます。また、ルートテーブルやセキュリティグループを変更することで、インバウンドとアウトバウンドのトラフィックを設定することができます。

    null
    図 19: ターゲット AWS アカウントでの追加の VPC 構成

    Q Developer は CloudFormation スタックを使用して AWS ネットワーク構成をデプロイします。進捗を見るには、プロビジョニング AWS アカウントの CloudFormation コンソールにログインし、CloudFormation スタックの進捗から確認できます。このステップは完了までに時間がかかります。

    null
    図 20: Q Developer によりデプロイされた AWS ネットワーク構成

  9. target provisioning AWS アカウントにプロビジョニングされたインフラストラクチャのテスト

    AWS CloudFormation スタックをデプロイすると、オンプレミスから Amazon EC2 への移行の一部である AWS ネットワーク構成を作成するための全てのコードが含まれています。これらには以下が含まれます。

    • VMware のサブネットはスーパーネットとして構成され、VPC CIDR ブロックとして割り当てられます。全てのスーパーネットをカバーするために必要な数の VPC を持つことになります。
    • VPC CIDR ブロックは VPC サブネットに切り分けられます。
    • リソースの送受信トラフィックをコントロールする VPC セキュリティグループ
    • 全ての VPC は AWS Transit Gateway でピアリングされ、VM 間の通信を可能にします。
  10. ワークロードの移行

    AWS ネットワークコンポーネントのプロビジョニングが完了したら、最終段階であるワークロードの移行に移ります。この段階になると、AWS Application Migration Service (MGN) を初期化するように促されます。MGN を初期化するには、完全な管理者権限を持つアカウントが必要です。Go to AWS Application Migration Service console を選択すると、AWS コンソールが表示されます。

    null
    図 21: Go to MGN Service console

    AWS コンソールにログインしたら、Get started を選択します。

    null
    図 22: AWS Application Migration Service (MGN) の開始

    次に Set up service を選択します。このステップは、AWS Application Migration Service (MGN) がお客様に代わって AWS リソースを作成するために必要な IAM ロールを作成するために必要です。

    null
    図 23: AWS Application Migration Service (MGN) のセットアップ

    最後に Q Developer に戻り、Send to Q を選択します。

  11. ワークロードウェーブ

    次に、オンプレミスのワークロードの移行を開始します。ウェーブごとに、ターゲットとなる Amazon EC2 インスタンスのサイジングに使用するサイジング方法を選択します。

    • Maximum utilization – 過去最大のソース VM の使用量
    • Current server specs – vCenter Server にてソース VM に設定されているのと同等の RAM と vCPU を保持します
    • Average utilization – 過去のソース VM の使用量の平均
    • Percentile of utilization – 現在のサーバーのスペックより 20% 低いなど、パーセンテージを指定します

    共有 ( デフォルト ) もしくは専有テナンシーを選択できます。またオプションとして、特定の EC2 インスタンスタイプを推奨から除外することができます。

後片付け

プロビジョニングアカウントについて:もし本番環境を移行した場合は、プロビジョニングアカウントは、ワークロードの実行に必要な全てのオブジェクトを含んでいるため、削除することはないでしょう。しかし単なるテストである場合は、以下を実行してください。

  • Q Developer ウェブエクスペリエンスの移行ジョブを停止する
  • プロビジョニングアカウント内の CloudFormation スタックを削除する

まとめ

本稿では、VMware ワークロードを AWS に移行するための、Amazon Q Developer transformation capabilities for VMware の利用手順を解説しました。ご自身の環境にて、新しい移行機能をテストする一助となれば幸いです。Amazon ではお客様を起点に仕事をしているため、この新しいサービスをテストされた際には是非我々にフィードバックをお寄せください。お客様のご意見は、私たちが反復と改善を続け、常にお客様に可能な限り最高のエクスペリエンスを提供することを保証するのに役立ちます。

パトリック・カルマ

Patrick Kremer

Patrick Kremer は、VMware ワークロード移行に特化したシニアスペシャリストソリューションアーキテクトです。Patrick は 2022 年に AWS に入社し、15 年以上にわたる VMware の経験を活かして顧客の移行とモダナイズを支援しています。AWS Certified Solutions Architect – Professional の資格保有者であり、指導とブログ執筆に情熱を注いでいます。

アトゥル・モディ

Atul Modi

Atul Modi は AWS Migrations and Modernizations グループのプロダクトリーダーで、ユーティリティコンピューティング、エッジコンピューティング、ワークロード移行において 12 年以上の経験を持ちます。AWS では、生成 AI を活用したコンピュートワークロードの移行や、ソフトウェアライセンスの管理の簡素化に注力しています。

ペドロ・カリクスト

Pedro Calixto

Pedro Calixto は AWS のシニアソリューションアーキテクトで、ワークロードの移行とモダナイゼーションを専門としています。AWS サービスによるアプリケーションのモダナイゼーションを加速させるだけでなく、AWS 内でオンプレミス環境の拡張、移行、保護をサポートすることに注力しています。

翻訳は SA 太田が担当しました。原文はこちらです。