Azure Virtual Desktop パフォーマンス監視ガイド

📋 このガイドについて

✅ このガイドで学べること

AVDが遅い原因を特定するための監視方法
各監視手法のパフォーマンスへの影響度
実際の設定手順とKQLクエリ
監視データの見方と対処方法

🎯 想定する読者

AVDが遅いという課題を抱えている方で、以下のような方を対象としています：

Azureの基本的な操作ができる方
PowerShellの基本コマンドを実行できる方
監視によるパフォーマンス影響を心配されている方

🔍 AVDが遅い原因の調査フロー

ユーザーから「遅い」報告

→

監視の実装

→

データ収集・分析

→

原因特定

→

対策実施

🔧 監視手法の比較

AVDの監視には複数の方法がありますが、パフォーマンスへの影響が全く異なります。以下で詳しく比較します。

監視方法	VM影響度	実装難易度	推奨度	コスト
診断設定 (Connection/Checkpoint)	影響なし 0%	⭐ 簡単	⭐⭐⭐⭐⭐	低
Azure Virtual Desktop Insights	影響なし 0%	⭐ 最も簡単	⭐⭐⭐⭐⭐	低
Azure Monitor Agent (標準構成)	0.1-0.3%	⭐⭐ やや簡単	⭐⭐⭐⭐	中
カスタムパフォーマンスカウンター	0.3-0.5%	⭐⭐⭐ 普通	⭐⭐⭐	中
ETWトレース (セッションホスト上)	1-3%	⭐⭐⭐⭐ 難しい	⭐	高

✅ 推奨される監視構成（影響度：ほぼゼロ）

以下の3つを組み合わせることで、セッションホストVMに一切負荷をかけずに包括的な監視が可能です：

診断設定：接続品質、ラウンドトリップ時間、帯域幅などを収集
Azure Virtual Desktop Insights：ダッシュボードで視覚的に確認
Log Analytics：KQLクエリで詳細分析

⚠️ 現在遅い場合は避けるべき監視

セッションホスト上でのETWトレース（CPU 1-3%消費）
高頻度（1分未満間隔）でのカスタムカウンター収集
リアルタイムでのクライアントログ転送

📊 パフォーマンス影響の詳細分析

なぜ推奨監視はVMに影響しないのか？

🏗️ アーキテクチャの理解

AVDの監視データは複数のレイヤーで収集されます：

クライアント

⬇️

RD Gateway / RD Broker
（ここで大部分を収集）

⬇️

セッションホストVM
（影響を受けない）

⬇️

Log Analytics

重要：診断設定で収集される接続情報、ラウンドトリップ時間、帯域幅などは、すべてAzureのコントロールプレーン（RD Gateway/Broker）で収集されます。セッションホストVMでは処理されません。

各監視方法のリソース使用量

診断設定

CPU使用率: 0%

メモリ: 0 MB

ネットワーク: 0 Mbps

✅ Azure側で処理、VM影響なし

Azure Monitor Agent

CPU使用率: 0.1-0.3%

メモリ: 50-100 MB

ネットワーク: 1-5 Mbps

✅ 非常に軽量、影響最小

ETWトレース

CPU使用率: 1-3%

メモリ: 200-500 MB

ディスクI/O: 数 MB/秒

⚠️ 現在遅い場合は非推奨

⚙️ 実装手順（ステップバイステップ）

所要時間：約10-15分
必要な権限：Azure サブスクリプションの共同作成者または所有者

1前提条件の確認

PowerShell - 環境確認

# Azure PowerShell モジュールがインストールされているか確認
Get-Module -ListAvailable -Name Az.* | Select-Object Name, Version

# インストールされていない場合
Install-Module -Name Az -AllowClobber -Scope CurrentUser

# Azureにログイン
Connect-AzAccount

# サブスクリプションの確認
Get-AzSubscription | Select-Object Name, Id, State

2Log Analytics ワークスペースの作成または確認

PowerShell - Log Analytics ワークスペース

# 既存のワークスペース確認
Get-AzOperationalInsightsWorkspace | 
    Select-Object Name, ResourceGroupName, Location

# 新規作成する場合
$resourceGroup = "rg-avd-monitoring"
$workspaceName = "law-avd-monitoring"
$location = "Japan East"

# リソースグループ作成（存在しない場合）
New-AzResourceGroup -Name $resourceGroup -Location $location -Force

# Log Analytics ワークスペース作成
New-AzOperationalInsightsWorkspace `
    -ResourceGroupName $resourceGroup `
    -Name $workspaceName `
    -Location $location `
    -Sku PerGB2018

Write-Host "✓ Log Analytics ワークスペースが作成されました" -ForegroundColor Green

3診断設定の有効化（最重要）

この設定だけで、以下の情報が収集されます（VM影響ゼロ）：

接続の開始・終了時刻
ラウンドトリップ時間（RTT）
利用可能な帯域幅
接続プロトコル
エラーや切断の情報

PowerShell - 診断設定の有効化

# 変数設定（環境に合わせて変更）
$subscriptionId = "your-subscription-id"
$avdResourceGroup = "rg-avd-production"
$hostPoolName = "hp-avd-production"
$workspaceResourceGroup = "rg-avd-monitoring"
$workspaceName = "law-avd-monitoring"

# サブスクリプション設定
Set-AzContext -SubscriptionId $subscriptionId

# Log Analytics ワークスペース取得
$workspace = Get-AzOperationalInsightsWorkspace `
    -ResourceGroupName $workspaceResourceGroup `
    -Name $workspaceName

# ホストプール取得
$hostPool = Get-AzWvdHostPool `
    -ResourceGroupName $avdResourceGroup `
    -Name $hostPoolName

# 診断設定作成（これが最も重要！）
$categories = @(
    "Connection",      # 接続情報
    "Checkpoint",      # 品質メトリクス（RTT、帯域幅など）
    "Error",          # エラーログ
    "Management",     # 管理操作
    "HostRegistration" # ホスト登録状態
)

$diagnosticSetting = @{
    ResourceId = $hostPool.Id
    WorkspaceId = $workspace.ResourceId
    Enabled = $true
    Name = "AVD-Diagnostics"
    Category = $categories
}

Set-AzDiagnosticSetting @diagnosticSetting

Write-Host "✓ 診断設定が完了しました（VM負荷：ゼロ）" -ForegroundColor Green
Write-Host "  データ収集開始まで約5-10分かかります" -ForegroundColor Yellow

🎉 設定完了！

これで以下が実現できました：

✅ セッションホストVMに負荷をかけずに監視開始
✅ 接続品質データの自動収集
✅ Azure Portal でのビジュアル監視
✅ 問題発生時の自動アラート

データ確認：設定後10-15分でLog Analyticsにデータが表示され始めます。

📝 KQLクエリ集（コピー&ペーストで使える）

Log Analytics ワークスペースで以下のクエリを実行してください。

基本的な接続品質の確認

1️⃣ 過去24時間のラウンドトリップ時間（RTT）トレンド

KQL Query

// 過去24時間のRTTトレンドを5分間隔で表示
WVDCheckpoints
| where TimeGenerated > ago(24h)
| where Name == "RoundTripTime"
| extend RTT = todouble(Parameters)
| summarize 
    AvgRTT = avg(RTT),
    MinRTT = min(RTT),
    MaxRTT = max(RTT),
    P95RTT = percentile(RTT, 95)
  by bin(TimeGenerated, 5m), SessionHostName
| render timechart

用途：時間帯による遅延の変化を把握し、ピーク時間を特定

見方：AvgRTTが100ms以上なら要注意、150ms以上なら深刻

2️⃣ 利用可能な帯域幅の推移

KQL Query

// 帯域幅の推移を確認（低帯域幅が遅延の原因かを判定）
WVDCheckpoints
| where TimeGenerated > ago(24h)
| where Name in ("AvailableBandwidth", "EstimatedAvailableBandwidth")
| extend Bandwidth = todouble(Parameters)
| summarize 
    AvgBandwidth = avg(Bandwidth),
    MinBandwidth = min(Bandwidth)
  by bin(TimeGenerated, 5m), UserName, Name
| render timechart

用途：ネットワーク帯域幅不足が原因かを確認

見方：10Mbps未満が続く場合はネットワーク問題の可能性

3️⃣ ユーザー別の接続品質ランキング（ワースト10）

KQL Query

// 最も遅延が大きいユーザー Top 10
WVDCheckpoints
| where TimeGenerated > ago(24h)
| where Name == "RoundTripTime"
| extend RTT = todouble(Parameters)
| summarize 
    AvgRTT = avg(RTT),
    MaxRTT = max(RTT),
    SessionCount = dcount(CorrelationId)
  by UserName
| top 10 by AvgRTT desc
| project UserName, 
    AvgRTT_ms = round(AvgRTT, 1), 
    MaxRTT_ms = round(MaxRTT, 1), 
    SessionCount

用途：特定ユーザーだけの問題か全体的な問題かを判断

見方：特定ユーザーのみ悪い→クライアント環境、全体的→サーバー側

4️⃣ セッションホスト別のパフォーマンス比較

KQL Query

// どのセッションホストが遅いかを特定
WVDCheckpoints
| where TimeGenerated > ago(6h)
| where Name == "RoundTripTime"
| extend RTT = todouble(Parameters)
| summarize 
    AvgRTT = avg(RTT),
    P95RTT = percentile(RTT, 95),
    UserCount = dcount(UserName),
    SampleCount = count()
  by SessionHostName
| project SessionHostName, 
    AvgRTT_ms = round(AvgRTT, 1),
    P95RTT_ms = round(P95RTT, 1),
    UserCount,
    SampleCount
| order by AvgRTT_ms desc

用途：特定のセッションホストに問題があるかを確認

対処：特定ホストのみ遅い場合、そのVMのリソースやネットワークを調査

5️⃣ 総合パフォーマンススコアカード

KQL Query

// 過去24時間の総合パフォーマンスサマリー
let timeRange = 24h;
let connections = WVDConnections
    | where TimeGenerated > ago(timeRange)
    | summarize 
        TotalConnections = count(),
        SuccessfulConnections = countif(State == "Connected"),
        FailedConnections = countif(State == "Failed")
    | extend SuccessRate = round(100.0 * SuccessfulConnections / TotalConnections, 1);
let rtt = WVDCheckpoints
    | where TimeGenerated > ago(timeRange)
    | where Name == "RoundTripTime"
    | extend RTT = todouble(Parameters)
    | summarize 
        AvgRTT = round(avg(RTT), 1),
        P95RTT = round(percentile(RTT, 95), 1),
        HighLatencyCount = countif(RTT > 100);
let bandwidth = WVDCheckpoints
    | where TimeGenerated > ago(timeRange)
    | where Name == "AvailableBandwidth"
    | extend BW = todouble(Parameters)
    | summarize 
        AvgBandwidth = round(avg(BW), 1),
        LowBandwidthCount = countif(BW < 10);
connections
| extend dummy = 1
| join kind=inner (rtt | extend dummy = 1) on dummy
| join kind=inner (bandwidth | extend dummy = 1) on dummy
| project 
    メトリクス = "過去24時間のサマリー",
    総接続数 = TotalConnections,
    接続成功率_パーセント = SuccessRate,
    平均RTT_ms = AvgRTT,
    P95_RTT_ms = P95RTT,
    高遅延セッション数_100ms以上 = HighLatencyCount,
    平均帯域幅_Mbps = AvgBandwidth,
    低帯域幅セッション数_10Mbps未満 = LowBandwidthCount

用途：全体的な健全性を一目で確認

見方：成功率95%以上、平均RTT50ms以下、P95RTT100ms以下が理想

📈 監視すべき重要メトリクスと推奨値

パフォーマンス評価基準

メトリクス	良好	警告	重大	説明
Round-trip Time (RTT)	< 50ms	50-100ms	> 100ms	クライアントとセッションホスト間の往復遅延時間
Available Bandwidth	> 20 Mbps	10-20 Mbps	< 10 Mbps	利用可能なネットワーク帯域幅
Frame Rate	> 25 FPS	15-25 FPS	< 15 FPS	画面の更新頻度
接続成功率	> 98%	95-98%	< 95%	接続試行に対する成功の割合
CPU使用率	< 70%	70-85%	> 85%	セッションホストのCPU使用率
メモリ使用率	< 80%	80-90%	> 90%	セッションホストのメモリ使用率

パフォーマンス低下の一般的な原因と対処法

🌐 ネットワーク遅延

症状：RTTが高い、帯域幅が低い

対処：

Azure Virtual WAN の使用
クライアントに近いリージョンへの移行
RDP Shortpath の有効化

💻 リソース不足

症状：CPU/メモリ使用率が高い

対処：

VMサイズのスケールアップ
セッションホスト数の増加
負荷分散の最適化

💾 ディスクI/O

症状：ディスクキュー長が高い

対処：

Premium SSD への移行
FSLogixの最適化
プロファイルのクリーンアップ

🔐 認証遅延

症状：接続確立時間が長い

対処：

ドメインコントローラーの配置最適化
GPOの簡素化
FSLogix Cloud Cache の使用

❓ よくある質問（FAQ）

Q1. 監視を有効にすると本当にパフォーマンスに影響しませんか？

A. はい、診断設定とAzure Virtual Desktop Insightsは、セッションホストVMのパフォーマンスに一切影響しません。

理由は以下の通りです：

データ収集はAzureのコントロールプレーン（RD Gateway/Broker）で実行される
セッションホストVM上では処理が行われない
メトリクスは接続のメタデータであり、VMリソースを消費しない

Q2. データ収集開始までどのくらい時間がかかりますか？

A. 診断設定を有効にしてから5-15分程度でLog Analyticsにデータが表示され始めます。

Q3. RTTが高い場合、具体的にどう対処すればいいですか？

A. RTT（Round-trip Time）が高い場合の対処法：

1. 原因の特定（KQLクエリで分析）

特定ユーザーのみ？→クライアント側の問題
特定時間帯のみ？→ネットワーク混雑
特定セッションホストのみ？→サーバー側の問題

2. ネットワーク最適化

RDP Shortpath: UDP経由の直接接続を有効化
リージョン最適化: ユーザーに近いリージョンを選択
Express Route: 専用線接続の検討

Q4. 既存のAVD環境に後から監視を追加できますか？

A. はい、いつでも追加可能で、既存環境への影響もありません。

手順：

本ガイドの「実装手順」に従って診断設定を有効化
既存のユーザーセッションは継続したまま設定変更可能
再起動や接続の切断は不要

Azure Virtual Desktop パフォーマンス監視ガイド

🚀 Azure Virtual Desktop パフォーマンス監視ガイド

📋 このガイドについて

✅ このガイドで学べること

🎯 想定する読者

🔍 AVDが遅い原因の調査フロー

🔧 監視手法の比較

✅ 推奨される監視構成（影響度：ほぼゼロ）

⚠️ 現在遅い場合は避けるべき監視

📊 パフォーマンス影響の詳細分析

なぜ推奨監視はVMに影響しないのか？

🏗️ アーキテクチャの理解

各監視方法のリソース使用量

⚙️ 実装手順（ステップバイステップ）

1前提条件の確認

2Log Analytics ワークスペースの作成または確認

3診断設定の有効化（最重要）

🎉 設定完了！

📝 KQLクエリ集（コピー&ペーストで使える）

基本的な接続品質の確認

📈 監視すべき重要メトリクスと推奨値

パフォーマンス評価基準

パフォーマンス低下の一般的な原因と対処法

❓ よくある質問（FAQ）

1. 原因の特定（KQLクエリで分析）

2. ネットワーク最適化

📥 このガイドを保存