Azure Virtual Desktop のリソース編成に関する考慮事項

リソース ストレージの構造によって、リソース管理とガバナンスを実装するためのオプションが直接決まります。 この記事では、組織の構造を設計するのに役立つ考慮事項と推奨事項について説明します。

このセクションのガイダンスを使用して、次のリソースの編成とセグメント化を確認します。

  • 管理グループ階層
  • サブスクリプション
  • リソース グループ
  • ランディング ゾーン

タグ付け戦略を使用してリソースを整理することを検討してください。

設計上の考慮事項

以降のセクションでは、組織の Azure Virtual Desktop 構造を計画する際に考慮すべき事項が示されています。

仮想マシンの数

組織で必要な Azure Virtual Desktop 仮想マシン (VM) の数

1 つのリージョンに 5,000 を超える VM をデプロイしないでください。 個々のセッション ホスト VM リソースを増やすことによって、追加のユーザー セッションに対応できます。

代わりに、サブスクリプションあたり 5,000 を超える VM を持つエンタープライズ環境を 1 つのリージョンで管理する場合は、複数の Azure サブスクリプションを作成する必要があります。 これらのサブスクリプションをハブスポーク アーキテクチャに配置し、仮想ネットワーク ピアリングを介して接続します。 VM の数を増やすには、同じサブスクリプションの別のリージョンに VM をデプロイします。

ホストのデプロイ用のリージョン

ホストをデプロイするときは、どのリージョンを選択する必要がありますか?

一般に、すべてのリソースを Azure Virtual Desktop のデプロイと同じ Azure リージョンに保存することをお勧めします。 関連する主なリソースは次のとおりです。

  • ホスト プール、アプリケーション グループ、ワークスペースなどのメタデータ (サービス オブジェクト)
  • 仮想マシン、ディスク、ネットワーク インターフェイスなどのセッション ホスト (Virtual Desktop) コンピューティング。
  • VNet (セッション ホストが直接接続されている VNet)
  • Storage (FSLogix ユーザー プロファイルの場合)
  • Azure Compute Galleries、Key Vault、イメージなどのその他のリソース。

その他の考慮事項

  • ユーザーに最も近い Azure リージョンにセッション ホストをデプロイすると、ネットワーク接続と待機時間の問題が軽減し、パフォーマンスが向上します。
  • 特定のリージョンを選択する前に、リージョンのコンプライアンスとデータ所在地の要件を常に考慮してください。
  • ある Azure リージョン (インド中部など) のセッション ホストでアプリケーションを実行し、別の Azure リージョン (米国中部など) のサービスに到達する必要がある場合、アプリケーションの待機時間が長くなることがよくあります。 代わりに、セッション ホストが必要なリソース (現在の例では米国中部) で Azure リージョンに近い場合、アプリケーションの待機時間が大幅に増加する可能性は低くなります。
  • 特定の Azure リージョンのセッション ホストにユーザーを割り当てることができないため、同じホスト プール内の異なる Azure リージョン (インド中部や米国中部など) にあるセッション ホストを混在させないでください。 代わりに、Azure リージョンごとに個別のセッション ホストを作成します。

設計の推奨事項

以降のセクションでは、Azure Virtual Desktop でのリソースのラベル付けと整理に関する推奨事項について説明します。

名前付けとタグ付け

リソースを整理し、リソース管理、コストの追跡、ガバナンスを簡素化するために、名前付けとタグ付けの標準を使用します。

リソース間で一貫性を維持し、合意されたポリシーからの逸脱を特定するのに役立ちます。 リソースのタグ付けに関する規範的なガイダンスでは、ガバナンス プラクティスをデプロイするときに以下のいずれかのパターンがどのように役立つかを示します。 タグを使用して規制コンプライアンスを評価するのに類似のパターンを利用できます。

標準化された名前付け規則は、クラウドでホストされるリソースを編成するための開始点です。 適切に構造化された名前付けシステムにより、管理と会計の両方の目的で迅速なリソース識別が可能になります。 組織の他の部分で既存の IT 名前付け規則に従う場合は、クラウドの名前付け規則をそれらに合わせるか、クラウドの名前付け規則を一意かつ個別にするかを検討してください。

管理グループとサブスクリプション

Azure Policy を使用してポリシーとイニシアティブの割り当てをターゲットにできるように、管理グループ内のリソースを論理的にグループ化します。

ルート レベルの管理グループの下に管理グループを作成して、ホストするワークロード (アーキタイプ) の種類と、セキュリティ、コンプライアンス、接続性、機能のニーズに基づく管理グループを表します。 このグループ化構造により、同じセキュリティ、コンプライアンス、接続性、機能設定を必要とするすべてのワークロードに対し、管理グループ レベルで一連の Azure ポリシーを適用できます。

サブスクリプションはスケール ユニットとして機能します。これにより、コンポーネントのワークロードをプラットフォームのサブスクリプション制限内でスケーリングできます。 ワークロードの設計セッションの間に、サブスクリプションのリソース制限を考慮してください。

サブスクリプションによって、ガバナンスと分離のための管理境界が提供され、問題が明確に分離されます。 次の図は、デプロイする各 Azure リージョンの管理ドメインとライフサイクルの目的として作成して使用することをお勧めする構造とリソース グループを示しています。

    - Azure Virtual Desktop Service Objects:  Create a Resource Group for Azure Virtual Desktop Service Objects from Host Pool VMs.  Service objects like Workspaces, Host Pools and Application Groups.  
    - Networking:  Generally created as part of the Cloud Adoption Framework Landing zone
    - Storage:  If not already created as part of Cloud Adoption Framework, create a resource group for storage accounts
    - Session hosts compute: Create a Resource Group for Virtual Machines, Disks and Network Interfaces. These have a different life cycle than the Azure Virtual Desktop Service Objects. 
    - Shared Resources:  Create a Resource Group for shared resources like custom VM images, this encourages self-service so you could have a subscription for each business line, for instance.
    
    - Basic Structure:
        - Subscription (AVD-Shared-Resources)
            - rg-<Azure-Region>-avd-shared-resources
        - Subscription (AVD)
            - rg-<Azure-Region>-avd-<Workload>-service-objects
            - rg-<Azure-Region>-avd-<Workload>-network
            - rg-<Azure-Region>-avd-<Workload>-pool-compute
            - rg-<Azure-Region>-avd-<Workload>-storage

既にデプロイされている Azure Virtual Desktop リソースについて、上記の推奨される構造の例を下に示します。

AVD 共有リソースのサブスクリプションを示すスクリーンショット。

AVD サービス オブジェクトとコンピューティングのサブスクリプションを示すスクリーンショット。

追加のガイダンスと例

次のステップ

Azure Virtual Desktop のエンタープライズ規模シナリオでの管理と監視について確認します。