リモート デスクトップ サービス (RDS) は、クラウドまたはオンプレミスで Windows アプリケーションとデスクトップをホストするための柔軟なプラットフォームを提供します。 この記事では、一般的な RDS デプロイ アーキテクチャについて説明し、組織のニーズに合わせて RDS と Azure サービスを統合する方法について説明します。
次のアーキテクチャ図を使用して、次の内容を理解します。
- さまざまな展開シナリオで RDS ロールがどのように連携するか。
- 基本的な RDS 構成と高可用性 RDS 構成のオプション。
- Azure Platform as a Service (PaaS) オファリングとの統合パターン。
新しい RDS 展開を計画する場合でも、既存の RDS 展開を最新化する場合でも、これらのアーキテクチャは、パフォーマンス、可用性、およびセキュリティの要件を満たすソリューションを設計するのに役立つ実証済みのパターンを提供します。
この記事のアーキテクチャ図は、Azure での RDS の使用を示しています。 ただし、リモート デスクトップ サービスは Windows Server の役割であるため、オンプレミスやその他のクラウドに展開できます。 これらの図は、主に、RDS のロールがどのように共存し、他のサービスを使用するかを示すことを目的としています。
標準の RDS 展開アーキテクチャ
リモート デスクトップ サービスには、次の 2 つの標準的アーキテクチャがあります。
基本的な展開: 完全に効果的な RDS 環境を作成するためのサーバーの最小数が含まれていますが、冗長性はありません。
高可用性の展開: RDS 環境で最も高い稼働時間を保証するために必要なすべてのコンポーネントが含まれています。
次のセクションでは、各アーキテクチャのコンポーネントとその連携方法を示します。 また、この図では、RDS ロールがサーバーにどのように併置されているかも示しています。これは、コストと複雑さを軽減するための一般的な方法です。
基本的な展開
このアーキテクチャは、単一の Azure リージョンを介してデスクトップとアプリケーションへのリモート アクセスを提供する、Azure での基本的なリモート デスクトップ サービスのデプロイを示しています。 展開では、外部ロード バランサーを使用して、RDS インフラストラクチャ全体にパブリック インターネットからの受信接続を分散します。
コア RDS ロールは、1 つのリソース グループ内の複数の仮想マシンに分散されます。 RD 接続ブローカー (RDCB) と RD ライセンス サーバー (RDLS) は 1 つの仮想マシンを共有しますが、RD ゲートウェイ (RDGW) コンポーネントと RD Web アクセス (RDWeb) コンポーネントは別の VM にデプロイされます。 サポート インフラストラクチャには、Active Directory ドメイン コントローラーと、ユーザー プロファイル ディスクと共有ストレージ用のファイル サーバーが含まれます。 独自の仮想マシンにデプロイされた RD セッション ホスト (RDSH) サーバーは、実際のデスクトップ セッションとホストされたアプリケーションをエンド ユーザーに提供します。
すべての仮想マシンは Azure Virtual Network を介して通信します。これにより、他の Azure リソースからデプロイを分離しながら、RDS コンポーネント間のセキュリティで保護されたネットワーク接続が提供されます。 このアーキテクチャは、デスクトップ ホスティングを Azure に移行しようとしている組織にとって、コスト効率の高い開始点を提供し、使用量の増加に合わせて個々のコンポーネントを柔軟にスケーリングできます。
高可用性の展開
このアーキテクチャでは、Azure Platform as a Service (PaaS) オファリングを統合してスケーラビリティを向上させ、管理オーバーヘッドを削減するリモート デスクトップ サービスのデプロイを示します。 基本的な RDS デプロイとの主な違いは、RDS 構成とユーザー セッション データを格納するための従来の SQL Server 仮想マシンを Azure SQL Database に置き換える点です。
RDS ロールは同じ分散パターンを維持しますが、各ロールの複数のインスタンスを保持します。RD ゲートウェイ (RDGW) コンポーネントと RD Web アクセス (RDWeb) コンポーネントは別の VM セットにデプロイされている間、RD 接続ブローカー (RDCB) と RD ライセンス サーバー (RDLS) が 1 つの仮想マシンのセットを共有します。 RD セッション ホスト (RDSH) は、専用の仮想マシンからデスクトップ セッションとアプリケーションを引き続き提供します。 サポート インフラストラクチャには、Active Directory ドメイン コントローラーと、ユーザー プロファイルと共有ストレージ用のファイル サーバーが含まれます。
このアーキテクチャでは、セルフマネージド SQL Server インスタンスではなく Azure SQL Database を使用することで、組み込みの高可用性、自動バックアップ、および簡略化されたデータベース管理が提供されます。 Azure SQL Database は RDS 接続ブローカー データベースの要件を処理しますが、別のデータベース サーバーの保守、修正プログラムの適用、監視を行う必要はありません。 このハイブリッド アプローチでは、RDS ロールのサービスとしてのインフラストラクチャ (IaaS) の柔軟性と、データベース層の PaaS のマネージド特典が組み合わせられ、運用の複雑さが軽減され、信頼性が向上します。
固有の Azure PaaS ロールを持つ RDS アーキテクチャ
標準的な RDS 展開アーキテクチャはほとんどのシナリオに適合しますが、Azure では、顧客価値を高めるファースト パーティ PaaS ソリューションに引き続き投資します。 次のアーキテクチャは、RDS に組み込む方法を示しています。
Microsoft Entra Domain Services を使用した RDS の展開
2 つの標準的なアーキテクチャ図は、Windows Server VM にデプロイされた従来の Active Directory (AD) に基づいています。 ただし、従来の AD がなく、たとえば Microsoft 365 などのサービスを通じて Microsoft Entra テナントのみを持っていても RDS を使用する場合は、 Microsoft Entra Domain Services を使用して、Microsoft Entra テナントに存在するのと同じユーザーを使用するフル マネージド ドメインを Azure IaaS 環境に作成できます。 このオプションにより、ユーザーを手動で同期し、より多くの仮想マシンを管理する複雑さが排除されます。 Microsoft Entra Domain Services は、基本展開または高可用性展開のどちらでも機能します。
Microsoft Entra アプリケーション プロキシを使った RDS 展開
2 つの標準的なアーキテクチャ図では、RDS システムへのインターネットに接続するエントリ ポイントとして RD Web/ゲートウェイ サーバーを使用します。 一部の環境では、管理者は境界から独自のサーバーを削除し、代わりにリバース プロキシ テクノロジを使用してセキュリティを強化するテクノロジを使用することを好みます。 Microsoft Entra アプリケーション プロキシ PaaS ロールは、このシナリオにうまく適合します。
サポートされている構成とこのセットアップの作成方法については、「 Microsoft Entra アプリケーション プロキシを使用したリモート デスクトップの発行」を参照してください。
