Azure Virtual Desktop とリモート デスクトップ サービスのセッション ホストのサイズ設定には、ワークロードの種類とハードウェア構成を慎重に考慮する必要があります。 ワークロードの種類が異なると、最適なパフォーマンスを確保するために異なるハードウェア構成が必要になります。
ユーザーに適したサイズ設定を行う場合は、次の 2 種類のセッション ホストを考慮する必要があります。
単一セッション: 一度に 1 人のユーザー専用。
マルチセッション: 複数のユーザー間で同時に共有されます。
デスクトップとアプリがリモートでアクセスされる環境では、アプリがローカル オフロードをサポートしていない限り、セッション ホストで実行とデータ処理が行われます。 各セッションホストのサイズとホストの数を正しく設定することが重要です。リソースがピーク時に不足しないようにするためです。そうでないと、ユーザーに対するサービスが中断される可能性があります。
セッション ホストは、仮想マシンまたはリモート デスクトップ サービスの物理ハードウェア上で実行できます。 仮想マシンにはオーバーヘッドがあるため、この記事で説明するセッション ホストのサイズを変更するときは、そのことを考慮する必要があります。
この記事の例は一般的なガイドラインです。初期段階のパフォーマンスの見積もりにのみ使用してください。 最適なエクスペリエンスを実現するには、ユーザーのニーズに応じてデプロイをスケーリングします。
能力計画
提供する必要がある容量とリソースは、多くの要因に依存するため、すべてのユーザーによって異なります。 容量計画は、予想されるワークロードの需要を満たすために必要なセッション ホストとそのリソースを決定するプロセスです。 現在および将来のリソースニーズの分析、セッション ホストあたりのユーザー数の見積もり、最適なパフォーマンスを確保するための適切なサイズの決定が含まれます。
セッション ホストの容量を計画する場合は、次の領域を考慮してください。
| Area | Description |
|---|---|
| ユーザー ワークロード | ユーザーが実行するアプリとタスクの種類について理解します。 ワークロードによって、CPU、メモリ、ストレージなど、さまざまなリソース要件があります。 |
| ユーザー数 | セッション ホストにアクセスする同時ユーザーの数を見積もります。 これにより、予想されるユーザー負荷をサポートするために必要なリソースを特定できます。 |
| リソースの要件 | ユーザーが実行するアプリとタスクのリソース要件を分析します。 これには、CPU、メモリ、ストレージ、ネットワーク帯域幅が含まれます。 |
| パフォーマンスの期待値 | 応答時間、ログオン時間、アプリケーションの起動時間、全体的なユーザー エクスペリエンスなど、セッション ホストのパフォーマンスに対する期待値を定義します。 稼働日の開始やシフトなどの重要な時間のログオン パフォーマンスは、安定した状態と比較してパフォーマンスに影響を与える可能性があります。 |
| スケーラビリティ | ユーザーの要求が増加するにつれてセッション ホストをスケーリングする機能を検討してください。 これには、追加のユーザーやワークロードに対応するために、セッション ホストの追加や既存のホストのサイズ変更が含まれる場合があります。 |
| 回復性と冗長性 | 高可用性を確保し、ハードウェアまたはソフトウェアの障害が発生した場合のダウンタイムを最小限に抑えるために、冗長性とフェールオーバーのメカニズムを実装することを検討してください。 |
| 監視と最適化 | 監視ツールを実装して、リソース使用率とパフォーマンス メトリックを追跡します。 このデータを使用して、セッション ホストを最適化し、必要に応じて継続的な調整を行います。 |
セッション ホストの容量を判断するには、次の 2 つの方法が一般的に使用されます。
パイロット アプローチ: 1 つのテスト サーバーをデプロイし、負荷を徐々に増やしながら、CPU、ページング、ディスク、ネットワークなどのユーザー フィードバックとシステム パフォーマンス インジケーターを監視します。 この方法は、小規模な展開では信頼性が高くなりますが、最終的な展開目標を満たさない可能性のある初期ハードウェア投資が必要になる場合があります。
シミュレーション アプローチ: オートメーション ツールを使用して、実際のユーザーの動作を模倣するシミュレートされたユーザー ワークロードを生成します。 通常、シミュレーションでは、時間の経過と同時にシミュレートされたユーザーの数が徐々に増え、パフォーマンス メトリックがテスト全体で収集されます。 分析は、許容されるしきい値を超えてパフォーマンスが低下するポイントを特定するのに役立ちます。 このアプローチは、正確な容量決定が購入の決定に大きく影響する大規模なデプロイに適しています。
パイロットは、小規模なデプロイでは時間とコスト効率が高くなる傾向があります。一方、セッション ホスト容量を正確に決定すると購入の決定に大きな影響を与える可能性がある大規模なデプロイには、シミュレーション アプローチの方が適している可能性があります。
どちらの方法を使用する場合でも、稼働日やシフトの開始など、ユーザーログオンの重要な時間を考慮する必要があります。これは、安定した状態と比較してパフォーマンスに影響を与え、ログオン時間が長くなることがあります。 セッション ホストは、特定のシナリオで十分なユーザーをサポートできる可能性がありますが、すべてのユーザーに同時にログオンする機能がない可能性があります。 予期しないユーザー活動やリソース需要の急増に対応するために、余裕を計画しておきます。
想定、計算、行われた決定など、キャパシティ プランニング プロセスを文書化することをお勧めします。 計画を関係者に伝え、連携と理解を確保します。
容量とパフォーマンスに影響を与える主な要因
セッション ホストの容量に影響を与える重要な要因がいくつかあります。 これらの要因を理解することは、セッション ホストのサイズ設定とスケーリングに関する情報に基づいた意思決定を行うのに役立ちます。
CPU スケーリング
- CPU コアの数は、セッション ホスト VM でサポートできるユーザーの数に直接影響します。
- CPU コアの数を 2 倍にしても、リターンと同期のオーバーヘッドが減少するため、必ずしもユーザーの容量が 2 倍であるとは限りません。 CPU の初期数が少ない場合はスケーリング 係数が高くなり、コアの数が増えると減少します。 たとえば、4 コアから 8 コアへのスケール ファクターは、8 コアから 16 コアまでのスケーリング 係数よりも大きくなります。
- 通常、スケーリング 係数の範囲は 1.5 から 1.9 です。つまり、余分なコアごとに、ユーザー容量の比例的な増加を期待できますが、線形の増加は期待できません。
メモリへの影響:
- セッション ホスト VM に割り当てられるメモリの量は、サポートできるユーザーの数に直接影響します。
- メモリが制限要因の場合、容量を小さくすると、パフォーマンスが大幅に向上する可能性があります。 たとえば、メモリを 8 GB から 16 GB に増やすと、サポートできるユーザーの数が 2 倍以上になります。
ユーザー ログオンへの影響:
- ユーザー ログオンは CPU を集中的に使用する操作であり、同時ログオン率が高い場合は、システムのパフォーマンスに大きな影響を与える可能性があります。
- 多くのユーザーが同時にログオンする、稼働日の午前 9 時の開始など、予想されるログオン パターンを計画します。 それ以外の場合、ユーザーはログオン時間が長くなります。
仮想化のオーバーヘッド
- 仮想マシンで実行すると、内部テストに基づいて、ベア メタルと比較して 15 から 20% の容量コストが発生する可能性があります。
- ハイパーバイザーでは、待機時間と CPU オーバーヘッドが増えるため、ユーザーの応答時間がベア メタルよりも 10% 20% 高くなる可能性があります。
ハイパースレッディングの利点
- ハイパースレッディングでは、各コアで同時に実行するスレッドを増やし、プロセッサのリソースをより効率的に使用できるようにすることで、ユーザーの容量を向上させることができます。
- ハイパースレッディングの利点は、ワークロードとコアの数によって異なります。 CPU 負荷が低いワークロードは、追加の並列処理機能の恩恵を受け、ハイパースレッディングによってパフォーマンスを向上させることができます。
ネットワーク パフォーマンス
- ネットワーク待機時間、パケット損失、ジッターは、特にリモート サーバーまたはデータベースとの頻繁な通信を必要とするアプリケーションの場合、ユーザー エクスペリエンスに影響を与える可能性があります。 待機時間、パケット損失、ジッターを組み合わせて使用すると、応答時間が遅くなり、パフォーマンスが低下する可能性があります。
- ネットワーク RTT、パケット損失、ジッターが低いと、応答時間が短縮され、全体的なパフォーマンスが向上します。 ネットワーク パフォーマンスがユーザー エクスペリエンスに与える影響を最小限に抑えるには、待ち時間の短いネットワーク接続を使用することを検討してください。
ストレージのパフォーマンス
- ストレージのパフォーマンスは、ユーザー エクスペリエンスに影響を与える可能性があります。特に、ディスク アクセスが頻繁に必要なアプリケーションの場合です。
- SSD や NVMe ドライブなどの高性能ストレージ ソリューションを使用して、高速なデータ アクセスを確保し、待機時間を最小限に抑えます。
グラフィックス処理装置 (GPU) の要件
- 一部のワークロード (ビデオ レンダリング、3D デザイン、シミュレーション用のグラフィックス集中型アプリケーション、高解像度ディスプレイを備えた仮想デスクトップなど) では、最適なパフォーマンスを確保するために専用の GPU が必要になる場合があります。
- ユーザーがグラフィックスを集中的に使用するアプリケーションを実行する場合、または高解像度ディスプレイが必要な場合は、GPU 機能を備えたセッション ホストの使用を検討してください。
これらすべての要因は、セッション ホストの全体的なパフォーマンスと容量に影響を与える可能性があります。 ユーザー入力の遅延 (エンド ツー エンドのセッション応答時間) の測定は、ユーザーのパフォーマンスを評価する際に考慮すべき重要なメトリックです。 このメトリックは、ユーザーの入力が処理されてセッションに反映されるまでの時間を測定し、ユーザー エクスペリエンスをより正確に表現します。 ユーザーは通常、アクションの応答時間が 200 ミリ秒未満で、それ以上の遅延が発生すると、ユーザー エクスペリエンスが低下する可能性があります。 ユーザー エクスペリエンスの測定の詳細については、「 リモート デスクトップ セッション ホストでパフォーマンス カウンターを使用してアプリのパフォーマンスの問題を診断する」を参照してください。
Workloads
セッション ホストのサイズを設定するときは、ユーザーが実行するワークロードの種類が大きく異なる可能性があるため、考慮することが重要です。 たとえば、軽いデータ 入力ワーカーのリソース使用率が低いため、ユーザー密度が高くなります。 ただし、高負荷の 3D アプリを使用する専門家は、より高いリソースを消費するため、同じハードウェアでユーザー密度が低くなります。
ワークロードを ライト、 ミディアム、 ヘビー、 パワーの 4 種類に分類する例を次に示します。 ワークロードの種類ごとに、リソース要件とユーザーの期待が異なります。
次の表では、各ワークロードについて説明します。 ユーザーの例 は、各ワークロードが最も役に立つ可能性があるユーザーの種類です。 アプリの例 は、ワークロードごとに最適に動作するアプリの種類です。
| ワークロードの種類 | ユーザーの例 | アプリの例 |
|---|---|---|
| 光 | 基本的なデータ入力タスクを実行するユーザー | データベース エントリ アプリ、コマンド ライン インターフェイス |
| ミディアム | コンサルタントと市場研究者 | データベース エントリ アプリ、コマンド ライン インターフェイス、Microsoft Word、静的 Web ページ |
| Heavy | ソフトウェア エンジニア、コンテンツ作成者 | データベース エントリ アプリ, コマンドライン インターフェイス, Microsoft Word, 静的 Web ページ, Microsoft Outlook, Microsoft PowerPoint, 動的 Web ページ, ソフトウェア開発 |
| パワー | グラフィックデザイナー、3Dモデルメーカー、機械学習研究者 | データベース 入力アプリ、コマンド ライン インターフェイス、Microsoft Word、静的 Web ページ、Microsoft Outlook、Microsoft PowerPoint、動的 Web ページ、写真とビデオ編集、コンピューター支援設計 (CAD)、コンピューター支援製造 (CAM) |
単一セッション セッション ホストのサイズ設定に関する推奨事項
単一セッションシナリオでは、一度に 1 人のユーザーのみがセッション ホストにサインインします。 たとえば、Azure Virtual Desktop でパーソナル ホスト プールを使用する場合は、シングルセッション シナリオを使用しています。
単一セッション シナリオでのこれらのサイズ設定の推奨事項は、Azure VM に基づいています。 これらの数値を物理セッション ホストのベースラインとして使用することもできます。ワークロードに対してこれらの推奨事項を調整するための容量計画アプローチを検討してください。
VM ごとに少なくとも 2 つの物理 CPU コアを使用することをお勧めします。通常は、ハイパースレッディングを備えた 4 つの vCPU を使用します。 単一セッション シナリオに対してより具体的な VM サイズ設定の推奨事項が必要な場合は、ワークロードに固有のソフトウェア ベンダーに問い合わせてください。 通常、単一セッション セッション ホストの VM のサイズ設定は、物理デバイスのガイドラインに従います。
次の表は、一般的なワークロードの例を示しています。
| ワークロードの種類 | vCPU/RAM/OS ストレージの最小値 | Azure インスタンスの例 | コンテナー ストレージの最小値をプロファイルする |
|---|---|---|---|
| 光 | 2 vCPU、8 GB RAM、32 GB ストレージ | D2s_v5、D2s_v4 | 30 GB |
| ミディアム | 4 vCPU、16 GB RAM、32 GB ストレージ | D4s_v5、D4s_v4 | 30 GB |
| Heavy | 8 vCPU、32 GB RAM、32 GB ストレージ | D8s_v5、D8s_v4 | 30 GB |
マルチセッション セッション ホストのサイズ設定に関する推奨事項
マルチセッション シナリオでは、複数のユーザーが任意の時点でセッション ホスト仮想マシンにサインインします。 たとえば、Azure Virtual DesktopでプールされたホストプールをWindows 11 Enterprise マルチセッションオペレーティングシステム（OS）を用いて使用する場合、それはマルチセッションデプロイです。
マルチセッション コンピューティング環境では、単一セッション環境に比べてピーク負荷が大幅に高くなります。 特定のハードウェア容量を持つセッション ホストには、リソースが使い果たされる前にサポートできる最大ワークロード制限があります。
マルチセッション シナリオでのこれらのサイズ設定の推奨事項は、Azure VM に基づいています。 これらの数値を物理セッション ホストのベースラインとして使用することもできます。ワークロードに対してこれらの推奨事項を調整するための容量計画アプローチを検討してください。
次の表に、仮想中央処理装置 (vCPU) あたりの推奨ユーザー数の最大数と、標準以上のユーザー ワークロードの最小 VM 構成を示します。 単一セッション シナリオに対してより具体的な VM サイズ設定の推奨事項が必要な場合は、ワークロードに固有のソフトウェア ベンダーに問い合わせてください。
| ワークロードの種類 | vCPU あたりの最大ユーザー数 | 最小 vCPU/RAM/OS ストレージ | Azure インスタンスの例 | 最小プロフィールストレージ |
|---|---|---|---|---|
| 光 | 6 | 8 vCPU、16 GB RAM、32 GB ストレージ | D8s_v5、D8s_v4、F8s_v2、D8as_v4、D16s_v5、D16s_v4、F16s_v2、D16as_v4 | 30 GB |
| ミディアム | 4 | 8 vCPU、16 GB RAM、32 GB ストレージ | D8s_v5、D8s_v4、F8s_v2、D8as_v4、D16s_v5、D16s_v4、F16s_v2、D16as_v4 | 30 GB |
| Heavy | 2 | 8 vCPU、16 GB RAM、32 GB ストレージ | D8s_v5、D8s_v4、F8s_v2、D8as_v4、D16s_v5、D16s_v4、F16s_v2、D16as_v4 | 30 GB |
| パワー | 1 | 6 vCPU、56 GB RAM、340 GB ストレージ | D16ds_v5、D16s_v4、D16as_v4、NV6、NV16as_v4 | 30 GB |
マルチセッション ワークロードの場合は、次の理由により、VM サイズを 4 vCPU から 24 vCPU に制限する必要があります。
すべての VM には、2 つ以上のコアが必要です。 Windows の UI コンポーネントは、重いレンダリング操作の一部に少なくとも 2 つの並列スレッドを使用します。 マルチセッション シナリオでは、2 コア VM に複数のユーザーを配置すると、UI とアプリが不安定になり、ユーザー エクスペリエンスの品質が低下します。 4 つのコアは、安定したマルチセッション VM に必要な最小の推奨コア数です。
VM には 32 個を超えるコアを含めるべきではありません。 コアの数が増えると、システムの同期オーバーヘッドも増加します。 ほとんどのワークロードでは、約 16 コアで投資収益率が低くなり、ほとんどの場合、同期オーバーヘッドによる余分な容量のオフセットが発生します。 1 つの 32 コア VM ではなく、2 つの 16 コア VM を使用すると、ユーザー エクスペリエンスが向上します。
推奨される 4 ~ 24 コアの範囲では、通常、コアの数を増やすと、ユーザーに対してより優れた容量が返されます。 たとえば、4 つのコアを持つ VM に同時に 12 人のユーザーがサインインしている場合、その比率はコアあたり 3 人のユーザーです。 8 コアと 14 ユーザーの VM の比率は、コアあたり 1.75 ユーザーです。 このシナリオでは、比率が 1.75 の後者の構成では、短期的な CPU 需要があるアプリケーションのバースト容量が大きくなります。
この推奨事項は、より大規模な場合に当てはまります。 20 人以上のユーザーが 1 つの VM に接続されているシナリオでは、1 つまたは 2 つの大きな VM よりも複数の小規模な VM の方がパフォーマンスが向上します。 たとえば、16 コアの同じセッション ホストで 10 分以内に 30 人以上のユーザーがサインインすることが予想される場合、2 つの 8 コア VM がワークロードをより適切に処理できます。 また、幅優先の負荷分散を使用して、深さ優先の負荷分散ではなく、異なる VM 間でユーザーを均等に分散することもできます。この場合、既存のセッション ホストがユーザーでいっぱいになった後にのみ新しいセッション ホストを使用できます。
また、少数の大規模な VM ではなく、多数の小さな VM を使用することをお勧めします。 更新が必要な VM や現在使用されていない VM をシャットダウンする方が簡単です。 VM が大きくなると、少なくとも 1 人のユーザーがいつでもサインインする可能性が高くなり、VM をシャットダウンできなくなります。 小さい VM が多数ある場合は、アクティブなユーザーがいない VM がある可能性が高くなります。 これらの未使用の VM を安全にシャットダウンして、Azure Virtual Desktop で自動スケーリングを使用して、手動または自動でリソースを節約できます。 リソースを節約することで、デプロイの回復性が向上し、保守が容易になり、コストが削減されます。
関連するコンテンツ
- リモート デスクトップ セッション ホストでアプリのパフォーマンスの問題を診断するには、パフォーマンス カウンターを使用します。
- Windows Server 2025 リモート デスクトップ サービスの展開に関するより詳細な計画ガイダンスについては、Windows Server 2025 容量計画に関するホワイトペーパー (PDF) を参照してください。