Microsoft AZ-140: Azure Virtual Desktop のアーキテクチャとサービス設計 — 学習ガイド

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Virtual Desktop Specialty AZ-140 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Azure Virtual Desktop (AVD) は、Microsoft が管理するデスクトップおよびアプリ仮想化サービスであり、サービスのコントロールプレーンをテナント固有のデータプレーンから分離します。このサービスは安全な接続を仲介し、セッションホストの仮想マシン、ID、ストレージ、ネットワークはお客様が所有・運用します。効果的なアーキテクチャを設計するということは、ユーザーエクスペリエンス、ID、アプリケーション配信、キャパシティ、回復力、コスト管理を、ユーザーの中断なしに段階的に検証・展開できる一貫したデプロイモデルにマッピングすることを意味します。

サービスアーキテクチャ：コントロールプレーン vs データプレーン

• コントロールプレーン（Microsoft が管理）:

  • Web Access、Gateway、Broker サービスは、ユーザーを認証し、リソースを列挙し、TLS 443 経由のリバースコネクトセッションを調整します。これらはグローバルに分散され、Microsoft によって更新されます。
  • Diagnostics および Insights サービスは、接続のテレメトリ、正常性、エージェントのステータスを収集します。
  • ARM ベースの管理 API は、ホストプール、アプリケーショングループ、ワークスペースを定義し、スケーリングプランや「Start VM on Connect」も含まれます。

• データプレーン（お客様が管理）:

  • お客様のサブスクリプションと VNet 内のセッションホスト（Windows 10/11 Enterprise multi-session または single-session）。
  • AD DS、Azure AD DS、または Entra ID を介した ID と名前解決、および適切な参加モード。セッションホストはドメインサービスを解決できる必要があります。VNet DNS は、パブリック DNS ではなく、ドメインコントローラーまたは Azure AD DS の IP に設定します。
  • Azure Files Premium または Azure NetApp Files (ANF) 上のユーザー状態とキャッシュ（FSLogix プロファイルおよび Office コンテナー）。あまり一般的ではありませんが、IaaS ファイルサーバーや Storage Spaces Direct (S2D) も使用可能です。
  • ネットワーク（VNet、ピアリング、VPN/ExpressRoute、NSG、UDR、エグレス）。UDP/TCP 443 の遅延とジッターを最小限に抑えるための QoS とパスステアリングを含みます。
  • Azure Compute Gallery と Azure Image Builder によるイメージ管理、および自動スケーリングやメンテナンスウィンドウなどの運用管理。

コントロールプレーンのトラフィックはセッションホストからのアウトバウンドです。ホスト VM にインバウンドのパブリックエンドポイントは不要です。これにより、公開される領域が減り、ファイアウォールルールが簡素化されます。

主要な構成要素とアプリケーション配信

• ホストプール: 定義されたリソースの場所（メタデータリージョン）、負荷分散ポリシー、割り当てモード（プール型または個人用）を持つセッションホストの論理的なセットです。ホストプールにはデフォルトで1つの Desktop アプリケーショングループが含まれ、複数の RemoteApp グループを持つことができます。

• アプリケーショングループ（app group）:

  • Desktop: プールから完全な Windows デスクトップを提供します。ホストプールごとに許可される Desktop アプリケーショングループは1つだけです。
  • RemoteApp: 個別のアプリを公開します。プールごとに複数の RemoteApp グループを作成できます。
  • ユーザーには、同じホストプールから Desktop と RemoteApp の両方のグループを割り当ててはいけません。アプリとデスクトップのエクスペリエンスの競合を避けるために、別々のプールを使用してください。
  • アプリケーショングループは、厳密に1つのワークスペースに関連付けられます。ワークスペースとアプリケーショングループは、同じ AVD リソースの場所を共有する必要があります。

• ワークスペース: 複数のプールにまたがるアプリケーショングループを、AVD クライアント向けのリソースフィードに集約する、ユーザー向けのコンテナです。アプリケーショングループに対する RBAC で、どのユーザーがどのアプリ/デスクトップを閲覧できるかを制御します。アプリケーショングループをワークスペースに登録する際は、メタデータの場所を一致させてください。

• イメージ戦略: プール型のマルチセッションでは、Windows 10/11 Enterprise multi-session のマーケットプレイスイメージ、または Azure Compute Gallery 内の一般化されたカスタムイメージを使用します。個人用プールでは、Windows 10/11 Enterprise single-session のイメージを使用します。イメージをキャプチャする前に、必ずソース VM を一般化して、ユーザーおよびマシン固有の状態を削除してください。

ホストプールの種類、割り当て、更新、電源管理

• プール型 vs 個人用ホストプール:

  • プール型: VM あたり複数の同時ユーザー。幅優先（Breadth-first）または深さ優先（Depth-first）の負荷分散で、密度とコストを最適化します。プロファイルには FSLogix を使用します。
  • 個人用: 専用の状態を持つ VM あたり1人のユーザー。割り当て方法:
    • 自動: 最初の接続で、ユーザーが未割り当ての VM に永続的に紐付けられます。
    • 直接: 管理者がユーザーを特定のセッションホストにマッピングします。

• 検証プール vs 運用プール:

  • 検証プールフラグは、プールをプレリリースの AVD エージェントリングに参加させます。パイロットユーザーと共に AVD エージェント、OS、アプリの更新をテストするために、イメージ/リージョンごとに小規模な検証プールを使用します。
  • 段階的なロールアウトモデル:
    1. 開発/テストプールでイメージとエージェントを検証します。
    2. 一部のユーザーを含む検証プールでパイロット運用を行います。
    3. リージョンごとに段階的に運用プールに展開します。
    4. ダウンタイムを避けるため、ホストを段階的にドレインし、パッチを適用します。

• Autoscale と Start VM on Connect:

  • Autoscale（スケーリングプラン）は、容量をスケジュールし、セッションのしきい値を適用し、アイドル状態のホストをドレインし、VM の割り当てを解除して、ユーザーエクスペリエンスを維持しつつコストを最小限に抑えます。
  • Start VM on Connect は、ユーザーが接続を試みたときに、割り当て解除済みの VM の電源をオンにします。運用上の要件:
    • ホストプールでシステム割り当てマネージド ID を有効にし、セッションホストのリソースグループまたは VM に対して Desktop Virtualization Power On Off Contributor ロールを付与します。
    • コンピューティングコストを節約するには、VM の割り当てを解除する必要があります。「停止済み」でも割り当てられている状態では料金が発生し、コールドスタートのメリットもありません。
    • プール型および個人用プールで機能します。コールドスタートにより、接続に数分の遅延が加わります。
    • AVD を介したクライアント起点の接続のみが適用されます。直接の RDP はサポートされていません。
    • 自動スケールと連携して、ピーク時に最小限のホストが事前にウォームアップされるようにします。

負荷分散、容量計画、登録、正常性

• 負荷分散アルゴリズム:

  • 幅優先 (Breadth-first): 利用可能なホスト全体にセッションを均等に分散します。一貫したパフォーマンスとメモリのヘッドルームを確保するのに最適です。
  • 深さ優先 (Depth-first): 次のホストを使用する前に、1つのホストを最大セッション制限まで満たします。割り当て解除を最大化してコストを削減しますが、制限が高すぎるとノイジーネイバー効果 (noisy-neighbor effects) のリスクがあります。

• 最大セッション制限とユーザー密度:

  • VMごとの最大セッション制限を設定して同時セッション数を制限し、特に深さ優先の場合にUXを保護します。
  • 対象ワークロードのベンチマークを行って密度を推定します。多くの場合、CPUがマルチセッションの密度を制限します。経験則として:
    • 軽めの生産性向上タスク: 適切にチューニングされた最新のマルチセッションSKUで6–10セッション/vCPU。
    • 中程度の生産性向上タスク: 4–6セッション/vCPU。
    • グラフィックスまたはデータ量の多いタスク: 1–3セッション/vCPU。
  • 容量計画:
    • 必要なホスト数 = ceil((ユーザー数 × 同時接続率) ÷ ホストあたりのセッション数)。
    • フェイルオーバーやパッチ適用ウィンドウのために、N+1の予備またはパーセンテージでのヘッドルームを追加します。
    • ネットワーク: 軽めのセッションあたり300–500 Kbps、中程度で1–2 Mbps、高負荷で3–5+ Mbpsと見積もります。オフィスベースのユーザーのみが企業のインターネット接続を経由してヘアピン接続します。リモートユーザーはAVDに直接接続します。
    • QoS: AVDゲートウェイへのUDP/TCP 443を優先します。割り当てが不十分だと、応答の遅延や接続エラーが発生します。

• FSLogixストレージの選択:

  • Azure NetApp Filesは、エンタープライズ規模（数万ユーザー向け）で最高のIOPSと最小のレイテンシーを、最小限の管理オーバーヘッドで提供します。
  • Azure Files Premiumは、ADベースの認証またはEntra Kerberosを備えたSSDバックのSMB共有を提供し、ほとんどのデプロイでパフォーマンスとコストのバランスを取ります。
  • IaaSの代替案（S2D SOFS）は、Cloud Witnessなしで少なくとも3台のVMを必要とし、運用オーバーヘッドがかかります。PaaSオプションが利用できない場合にのみ使用します。

• 登録トークン、セッションホストの登録、エージェントの正常性:

  • 既存のVMをホストプールに追加する前に、登録トークンを生成します。AVDエージェントとブートローダーはこのトークンを使用してVMを登録します。その後、ホストはプールにバインドされ、トークンは期限切れになってもかまいません。
  • AVD InsightsとLog Analyticsを介してサービスステータス、SxSスタックのバージョン、ハートビートを監視し、エージェントの正常性を緑色に保ちます。パッチ適用中は、新しいセッションを防ぐためにホストをドレインモードにします。
  • 簡単なトラブルシューティングのヒント: ユーザーセッション内で、パフォーマンスモニターのRemoteFX Graphicsカウンター（Frames Skipped/Second）を使用して、サーバー、ネットワーク、クライアントのレンダリング問題を切り分けます。

登録と正常性に関するPowerShellの例:

# Generate a time-limited registration token
New-AzWvdRegistrationInfo `
  -ResourceGroupName 'rg-avd' `
  -HostPoolName 'hp-pooled' `
  -ExpirationTime (Get-Date).AddHours(8)

# Review host state, drain mode, and session counts
Get-AzWvdSessionHost `
  -ResourceGroupName 'rg-avd' `
  -HostPoolName 'hp-pooled' |
  Select-Object Name, Status, AllowNewSession, Sessions

• DNSとドメイン参加に関する考慮事項:

  • Azure AD DSを使用する場合、VNetのDNSサーバーをマネージドドメインのIPに設定し、セッションホストがWindows登録やKerberos/NTLMのためにドメインコントローラーを見つけられるようにします。
  • ハイブリッド経由でAD DSを使用する場合、セッションホストをホストする各VNetを、オンプレミスのDCのIP（回復性のために少なくとも2つ）を使用するように構成します。Azureプライベートエンドポイントを使用する場合は、条件付きフォワーダーまたはリゾルバーがそれをサポートしていることを確認します。

• リージョン設計とExperience Estimator:

  • Azure Virtual Desktop Experience Estimatorで測定したユーザーロケーションからのラウンドトリップレイテンシーが最も低い場所に基づいて、ホストプールのリージョンを選択します。ピーク時とオフピーク時に、実際のユーザーサブネットからテストを実行します。
  • FSLogixストレージとドメインサービスをセッションホストと同じ場所に配置（コロケーション）して、SMBのラウンドトリップを最小限に抑えます。リージョンをまたいだプロファイルのマウントは避けてください。
  • マルチリージョン展開の場合、ホストプール、アプリグループ、ワークスペース間でメタデータの場所を一致させます。自律性と段階的なフェイルオーバーのために、リージョンごとに個別のプールを使用します。

実践的な問題シナリオ

Siemens AGは、ミュンヘン、シカゴ、シンガポールのエンジニアにCADおよび生産性向上ワークロードを、コストを最小限に抑えつつ高いパフォーマンスを確保して提供する必要があります。

1. ユーザーコホート、ワークロード、リージョンのマッピング

• 3つのコホートを特定します: CADを多用するユーザー（GPUが必要）、標準的な生産性向上タスクのユーザー、アプリのみを必要とする契約社員。各拠点からのレイテンシーをAVD Experience Estimatorで測定します。
• 理由: コホートベースのプールは、ノイジーネイバー効果を防ぎ、ワークロードごとに最適なサイズのVMファミリーとスケーリング動作を可能にします。レイテンシー測定は、リージョンの配置を決定する情報となります。

2. リージョンごとのホストプールとアプリケーション配信の設計

• 西ヨーロッパ、米国東部、東南アジアに、コホートごとに3つのリージョナルホストプールを作成します。以下を使用します:
  • CAD向けにGPU NVadsA10 v5（プール型、幅優先、低めの最大セッション制限）。
  • 生産性向上タスク向けにD/Eシリーズ（プール型、深さ優先でオフピーク時の割り当て解除を最大化）。
  • 特定のアプリを公開する契約社員向けにRemoteApp専用プール。
• 各プールのリソースの場所に合わせて、RemoteAppおよびデスクトップアプリグループをリージョナルワークスペースに登録します。
• 理由: ワークロードとリージョンごとにプールを分離することで、パフォーマンスとコストを最適化し、クリーンなアプリケーション権限を維持できます。

3. IDとDNSの実装

• EUと米国では、Entra IDに同期されたオンプレミスのAD DSにドメイン参加させます。回復性のために、各VNetのカスタムDNSを2つのリージョナルDCに構成します。シンガポールでは、Azure AD DSを展開し、WANへの依存を避けるためにVNetのDNSをマネージドドメインのIPに設定します。
• 理由: ローカルのドメインコントローラーと正しいVNet DNSは、信頼性の高いKerberos解決と高速なログオンを保証します。Azure AD DSは、オンプレミスADが存在しない場所での運用オーバーヘッドを削減します。

4. ユーザー状態とストレージの最適化

• CADおよび高同時接続の生産性向上コホートにはAzure NetApp Filesを使用し、契約社員にはAzure Files Premiumを使用します。ストレージをホストプールと同じリージョンに配置し、近隣の2つのオフィス間を移動するCADユーザーのために、FSLogixプロファイルコンテナーでCloud Cacheを有効にします。
• 理由: ANFは高負荷ワークロードに対して最小のレイテンシーと最高のIOPSを提供します。Azure Files Premiumは、軽めのユーザーのコストを削減します。同じ場所への配置（コロケーション）は、リージョンをまたぐSMBのレイテンシーを防ぎます。

5. 容量、自動スケール、Start VM on Connect

• パイロットテストから密度目標を設定します（例: CAD 1–2セッション/vCPU、生産性向上タスク 4–6セッション/vCPU）。勤務時間中のランプアップと、時間外のドレインおよび割り当て解除を含む自動スケールプランを構成します。各ホストプールでシステム割り当てIDを使用してStart VM on Connectを有効にし、セッションホストのリソースグループに対してDesktop Virtualization Power On Off Contributorロールを付与します。
• 理由: 自動スケールとStart VM on Connectは、ユーザーエクスペリエンスを維持しながらコンピューティング費用を最小限に抑えます。IDとロールの割り当てにより、サービスがVMの電源を確実に操作できるようになります。

6. 段階的なロールアウトと検証

• リージョンごとに小規模な検証用ホストプールを指定し、エージェントの更新を早期に受け取れるようにします。パッチ適用のケイデンス: 検証 → パイロット → 本番。パッチ適用中はドレインモードを使用し、各ワークロードとアルゴリズムに適した最大セッション制限を適用します。
• 理由: 制御されたリング（検証リング）により、サービス全体のリグレッション（機能低下）を回避できます。ドレインモードは、ホストのメンテナンス中にセッションを維持します。

7. ネットワークとQoSのチューニング

• ブランチルーターが、十分な帯域幅を割り当ててAVDエンドポイントへのUDP/TCP 443を優先するようにします。リモートユーザー向けのVPNヘアピン接続を削除し、在宅ユーザーがAVDに直接接続できるようにします。
• 理由: AVDのメディアフローは443に依存しており、不十分にプロビジョニングされたQoSは、応答の遅延や接続切断を引き起こします。

Siemensのコホートと地理的条件に合わせて、プールの種類、アプリグループ、ID、ストレージ、スケーリング、リージョン配置を調整することで、この設計は予測可能なパフォーマンス、検証リングによる運用の安全性、そしてインテリジェントな電源管理と密度制御によるコスト効率を実現します。

すべてのドメイン · ID、アクセス、ガバナンス →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Microsoftを閲覧 →