Azure Virtual Desktop の評価

  • [アーティクル]

Azure Virtual Desktop の概念実証では、ベースラインの実装として初期のスコープを得ることができます。 しかし、その概念実証の出力は、そのままでは運用環境のニーズを満たさないでしょう。

Azure Virtual Desktop 評価演習は、データドリブンのプロセスによって仮定をテストすることに重点を置いています。 評価データは、チームが一連の重要な質問に答え、自分たちの仮定の正しさまたは誤りを実証し、必要に応じてスコープを改善すると、チームの Azure Virtual Desktop のシナリオをサポートするのに役立ちます。 この仮定検証のアプローチを使用すると、チームは、エンドユーザー デスクトップの Azure Virtual Desktop への移行またはデプロイを加速することができます。

Azure Virtual Desktop のデプロイを評価する

Azure Virtual Desktop 評価ごとに、ユーザーのペルソナ、仮想マシン (VM) の整合ホスト プール、エンドユーザーのアプリケーションとデータ、ユーザー プロファイル (データ) の組み合わせを評価します。 評価を行う場合には、データを使用してこのセクションの質問に答えることがチームの目的となります。 これらの答えによって、Azure Virtual Desktop 移行のデプロイとリリースの実際のスコープが決まります。

これらの質問への答えは、データから始まります。 計画の方法論、具体的にはベスト プラクティスとデジタル資産の評価では、移行計画を作成するために既にデータが収集および分析されている必要があります。 とはいえ、この特定のワークロードの評価における質問では、追加のデータが必要になります。 Azure Virtual Desktop のデプロイ計画を作成するために、デスクトップ、ユーザー、各ユーザーが使用するワークロードに関するデータが必要になります。

データ収集ツールとして Movere を使用する場合は、他の移行シナリオと同じように、Azure Migrate のデータを使用して、ペルソナの作成とこれらの質問に答えるのに必要なデータを入手することができるでしょう。

このセクションのすべての質問に答えるのに必要なデータがない場合は、お持ちのデータを補うための別の検出プロセスが、他のサードパーティ ソフトウェア ベンダーから提供されている可能性があります。 ISV パートナーも仮想デスク トップ インフラストラクチャ移行を目標とするセクション内で Azure Migrate と統合されています。 このベンダーは、ペルソナ、ホスト プール、アプリケーション、ユーザー プロファイルを含む Azure Virtual Desktop デプロイ計画を立てる場合に役立ちます。

ユーザーのペルソナ

この移行シナリオに含まれるすべてのユーザーをサポートするには、どれくらいの数の別個のペルソナが必要になるでしょうか? 以下の条件に基づいてユーザーをバケット化するとペルソナを定義することができます。

  • 個人用プール: 特定のユーザーのグループは、プールではなく専用のデスクトップを必要としますか? たとえば、セキュリティ、コンプライアンス、ハイ パフォーマンス、ノイジーネイバーといった要件が理由で、一部のユーザーはプール戦略に含まれていない専用のデスクトップで実行することになります。 この情報を入力するには、Azure Virtual Desktop のホスト プールのデプロイ中に、ホスト プールの種類として個人用を指定します。
  • 密度: 特定のユーザーのグループは、密度の低いデスクトップ エクスペリエンスを必要としますか? たとえば、密度が高くなると、仮想中央処理ユニット (vCPU) あたり 6 ユーザーというライト ユーザーの想定ではなく、vCPU あたり 2 ユーザーにすることが必要な場合があります。 密度情報は、 Azure Virtual Desktop ホスト プール デプロイのプール設定に入力します。
  • パフォーマンス: 特定のユーザーのグループは、ハイ パフォーマンスのデスクトップ エクスペリエンスを必要としますか? たとえば、一部のユーザーは、想定されている vCPU あたり 4 ギガバイト (GB) の RAM を超える vCPU あたりのメモリを必要としています。 VM のサイズは、Azure Virtual Desktop のホスト プールのデプロイでの仮想マシンの詳細で入力します。
  • グラフィック処理 (GPU): 特定のユーザーのグループには、より高いグラフィック性能の要件がありますか? たとえば、この GPU VM の構成ガイドで説明されているように、一部のユーザーは Azure で GPU ベースの VM を必要とします。
  • Azure リージョン: 特定のグループの OS ユーザーは、さまざまな地理的リージョンから操作しますか? たとえば、お客様がホスト プールを構成する前に、各リージョンのユーザーは見積りツールを使用して Azure までの待機時間をテストする必要があります。 テスト ユーザーは、待機時間が最小の Azure リージョンと、上位 3 つの Azure リージョンの待機時間 (ミリ秒) を共有する必要があります。
  • ビジネス機能: 特定のユーザーのグループ化で、部署、請求コード、ビジネス機能ごとにバケット化できますか? このようなグループ化は、運用の後の段階で会社のコストを調整するのに役立ちます。
  • ユーザー数: それぞれのペルソナには、どれくらいのユーザーがいますか?
  • 最大セッション数: 地域と運用の時間に基づいて、最大負荷時に想定される各ペルソナの同時ユーザー数はどれくらいですか?

前述の各質問に基づいて、ビジネス機能、コスト センター、地理的リージョン、技術要件ごとにユーザーのペルソナの描写を始めることができます。 次の表は、回答を記録して、評価を完成させたり設計ドキュメントを作成したりするのに役立ちます。

条件 ペルソナ グループ 1 ペルソナ グループ 2 ペルソナ グループ 3
プール プール プール 専用 (セキュリティ上の懸念)
密度 ライト (6 ユーザー/vCPU) ヘビー (2 ユーザー/vCPU) 専用 (1 ユーザー/vCPU)
パフォーマンス 低 高メモリ消費量 低
GPU 該当なし 必須 なし
Azure リージョン 北米 西ヨーロッパ 北米
ユーザー数 1,000 50 20
セッション数 200 50 10

各ペルソナ、またはビジネス機能と技術要件が異なる各ユーザー グループには、特定のホストプール構成が必要になります。

エンドユーザーの評価により、プールの種類、密度、サイズ、CPU/GPU、ランディング ゾーン リージョンなどの必要なデータを得ることができます。

ホスト プールの構成の評価によって、そのデータがデプロイ計画にマッピングされるようになりました。 技術要件、ビジネス要件、コストの調整は、ホスト プールの適切な数と構成を決定するのに役立ちます。

米国東部、西ヨーロッパ、東南アジアのリージョンでの価格の例をご覧ください。

アプリケーション グループ

Movere と ISV パートナーの両方による現在のオンプレミス環境のスキャンにより、エンドユーザーのデスクトップで実行されているアプリケーションに関するデータが提供されます。 そのデータを使用すると、各ペルソナで必要になるすべてのアプリケーションの一覧を作成できます。 必要なアプリケーションそれぞれについて、以下の質問の答えにより、デプロイの繰り返しを計画できます。

  • ペルソナがこのデスクトップを使用するために、インストールする必要のあるアプリケーションはありますか? ペルソナが、完全に Web ベースのソフトウェアをサービス アプリケーションとして使用するのでない限り、各ペルソナに対してカスタムのマスター VHD イメージを構成して、そのマスター イメージに必要なアプリケーションをインストールすることが必要になるでしょう。
  • このペルソナは、Microsoft 365 アプリケーションを必要としますか? そうであるなら、ギャラリーから Microsoft 365 アプリが含まれているイメージを選択するか、カスタマイズされたマスター VHD イメージに Microsoft 365 を追加する必要があります。
  • このアプリケーションは、Windows 10 Enterprise マルチセッションと互換性がありますか? アプリケーションに互換性が無い場合、カスタムの VHD イメージを実行するために個人用プールが必要になることがあります。 アプリケーションと Azure Virtual Desktop の互換性の問題については、Desktop Application Assure サービスを参照してください。
  • ミッションクリティカルなアプリケーションは、Azure Virtual Desktop インスタンスと任意のバックエンド システムとの間の待機時間から影響を受ける可能性がありますか? その場合、アプリケーションをサポートしているそのバックエンド システムを Azure に移行することの検討をお勧めします。

これらの質問の答えによっては、デスクトップの移行またはデプロイに先立って、デスクトップ イメージまたはサポートしているアプリケーション コンポーネントに対する修復を計画に含める必要があるかもしれません。

次のステップ

クラウド導入の取り組みの特定の要素に関するガイダンスについては、以下を参照してください。