Azure Virtual Desktop サービスのアーキテクチャと回復性 – Microsoft Learn 読解
とっつきにくい Microsoft Learn のページを、じっくり読み解いていきます。 今回のページは 「Azure Virtual Desktop サービスのアーキテクチャと回復性」 です。 AVD がどんなコンポーネントで構成され、どうやって「つながる」のか、そして障害が起きても倒れない仕組みを詳しく説明するページです。
はじめに
Azure Virtual Desktop のアーキテクチャは、ユーザーをデスクトップやアプリに接続するサービスを構成する多くのコンポーネントで構成されています。ほとんどのコンポーネントは Microsoft が管理しますが、一部はカスタマー マネージドまたはパートナー管理です。
AVD は「Microsoft が全部やってくれる部分」と「 customer が責任を持つ部分」が明確に分かれています。これは費用対効果とセキュリティ設計を考えるうえで非常に重要な視点です。
Microsoft 管理コンポーネント
Microsoft は、サービスとしてのコア機能用の仮想デスクトップ インフラストラクチャ (VDI) コンポーネントを提供します。これらのコンポーネントには、次のものが含まれます。
Microsoft が管理・運用する VDI コアコンポーネントは以下の 5 つです。
• Web サービス: ユーザー向けの Web サイトとエンドポイント。接続情報をユーザーのデバイスに返します。
エンドユーザーが AVD クライアントを開いたときに最初に通信するのがこの Web サービスです。「今あなたはどのリソースに接続できるか」という情報を返す役割を担います。
• ブローカー サービス: 受信接続を調整します。
ブローカー サービスは接続の「仲介役」です。ユーザーとセッションホストを結びつけたり、どの VM に接続させるかを決めたりします。RDS（Remote Desktop Services）でもブローカー（接続ブローカー）の概念はありましたが、AVD では Microsoft がクラウドで管理してくれます。
• ゲートウェイ サービス: デスクトップとアプリを提供するセッション ホストに接続しているユーザーのデバイスからリモート デスクトップ プロトコル (RDP) 接続を提供する Websocket サービス。
ゲートウェイ サービスは実際の RDP セッション通信を中継する WebSocket ベースのサービスです。「セッションホストへの穴あけ（ポート開放）が不要」なリバース接続の核となる部分です（詳しくは後述）。
• リソース ディレクトリ: 複数の地理的データベースのうち、各ユーザーに必要な接続情報をホストする Web サービスに指示する情報を提供します。
リソース ディレクトリは「どの地理的データベースを見ればよいか」を Web サービスに伝えるナビゲーター的役割です。ユーザーが別リージョンのホストプールを使う場合にも透過的に正しい場所へ誘導します。
• 地理的データベース: ユーザーがプロビジョニングされたすべてのリソースの接続ファイル (
.rdp) とアイコンが含まれます。
地理的データベースは実際の接続情報（.rdp ファイルやアプリアイコン）が格納された DB です。バックエンドは Azure SQL Database で、フェールオーバーとレプリケーション機能を備えています。
さらに、Azure Virtual Desktop では、Azure Traffic Manager や Azure Front Door などの他のグローバル Azure サービスを使用して、ユーザーを最も近い Azure Virtual Desktop エントリ ポイントに誘導します。
上記 5 コンポーネントに加え、グローバルなトラフィック制御として以下の 2 つのサービスも活用されています。
- Azure Traffic Manager: DNS ベースのグローバルトラフィック分散サービスです。AVD ではフィード検出時に使われ、ユーザーのデバイスの IP アドレスを元に地理的に最も近いリージョンの Web サービスへルーティングします。
- Azure Front Door: HTTP/HTTPS レベルのグローバルロードバランサーです。AVD では RDP 接続時に使われ、ユーザーの遅延が最も小さいゲートウェイサービスへ接続を誘導します。
以下は Microsoft Learn からの引用で、Microsoft 管理コンポーネントとカスタマー管理コンポーネントの区分をまとめた図です。
カスタマー管理コンポーネント
オペレーティング システム イメージのカスタマイズとアプリケーション、仮想ネットワーク接続、回復性、それらのセッション ホストのバックアップと回復など、セッション ホストの作成と管理を担当します。また、ユーザー ID を指定して管理し、サービスへのアクセスを制御します。
Microsoft がコアインフラを管理してくれる一方、セッションホスト VM の中身は customer の責任です。具体的には：
- OS イメージ（どのアプリを入れるか、どう設定するか）
- 仮想ネットワーク設計
- セッションホストのバックアップ・障害対策
- ユーザー ID（Azure AD / Entra ID）の管理
他の Azure サービスを使用して、次のような要件を満たすことができます。
• Azure 可用性ゾーンを使用して、Azure リージョン内の物理的に分離されたデータセンターの場所にセッション ホストを分散し、それぞれ独立した電源、冷却、ネットワークを使用します。
Azure 可用性ゾーンを使えば、同一リージョン内でも物理的に異なるデータセンターに VM を配置できます。1 つのデータセンターに障害が起きてもサービスを継続できる構成が取れます。
• セッション ホストのバックアップと復元を行う Azure Backup。
Azure Backup でセッションホスト VM のスナップショットを定期的に取得・保管します。
• Azure Site Recovery、セッション ホストを別の Azure リージョンにレプリケートします。
Azure Site Recovery を使えば、リージョン全体の障害に備えた DR 構成も取れます。
• Azure Advisor を使用すると、Azure リソースの最適化に役立ちます。
Azure Advisor はコスト・セキュリティ・可用性などの観点からリソースに対するアドバイスを自動的に出してくれるサービスです。
ユーザー接続
ユーザーが Azure Virtual Desktop のデスクトップとアプリにアクセスする場合、その接続を成功させるために複数のコンポーネントが関与します。次の 2 つのシーケンスがあります。
- フィード検出。フィードは、ユーザーが使用できるデスクトップとアプリの一覧です。
- セッション ホストへのリモート デスクトップ プロトコル経由の接続。
AVD への接続は「フィード検出」と「RDP 接続」の 2 段階で行われます。まず割り当てられているアプリとデスクトップの一覧を取得し（フィード検出）、その後に実際のセッションに接続（RDP 接続）します。
フィード検出
フィード検出中に、ユーザーが使用できるデスクトップとアプリがローカル デバイス上のアプリに設定されます。フィードには、接続に必要なすべての情報が含まれています。
フィードとは「AVD クライアントに表示されるアプリ・デスクトップの一覧データ」のことです。ここには .rdp ファイルやアイコンなど接続に必要な情報がすべて入っています。
フィード検出プロセスは次のとおりです。
- ユーザーは、世界中の任意の場所に配置される可能性があります。Azure Traffic Manager は、ユーザーのデバイスのソース IP アドレスを使用する地理的なトラフィック ルーティング方法に基づいて、ユーザーのデバイスを Azure Virtual Desktop Web サービスの最も近いインスタンスにルーティングします。
まず Azure Traffic Manager がユーザーの IP アドレスを見て、地理的に最も近い AVD Web サービスのインスタンスへ誘導します。世界中どこからアクセスしても、最も近いリージョンで処理されるため遅延が最小化されます。
- Web サービスは、同じ Azure リージョンの Azure Virtual Desktop ブローカー サービスに接続して、ユーザーのフィードの RDP ファイルとアプリケーション アイコンを取得します。ブローカー サービスは、同じリージョン内の Azure Virtual Desktop の地理的データベースとリソース ディレクトリに接続して情報を取得します。
Web サービスは同じリージョンのブローカーサービスへ問い合わせ、ブローカーがさらに同じリージョンの地理的データベースとリソースディレクトリを参照して必要な情報を集めます。
- ブローカー サービスは、RDP ファイルとアプリケーション アイコンを Web サービスに返し、ユーザーのデバイスに情報を返します。
集まった情報がブローカー → Web サービス → ユーザーデバイスの順で返ってきます。これでフィード（一覧）の取得完了です。
地理的データベースには、地域でカバーされているのと同じ Azure リージョン内のホスト プールからのデスクトップとアプリに必要な情報のみが含まれています。
地理的 DB は「そのリージョンでカバーするホストプールの情報だけ」を持っています。グローバルに 1 つの巨大 DB があるわけではなく、リージョンごとに分散して持っているイメージです。
ユーザーが別の地域でカバーされているホスト プールからデスクトップまたはアプリに割り当てられている場合、リソース ディレクトリは、正しい Azure リージョンのブローカー サービスと地理的データベースに接続するように Web サービスに指示します。
ユーザーが物理的に近いリージョンとは別のリージョンのホストプールに割り当てられている場合でも、リソースディレクトリが正しいリージョンを案内するため、ユーザーは意識することなく接続できます。
以下は Microsoft Learn からの引用図です。
同一リージョン内でフィードを取得するケース（シングルリージョン）:
Traffic Manager がユーザーを最寄りリージョンの Web サービスへ誘導し、同リージョンのブローカーを経由して地理的データベースからフィード情報を取得して返します。
ホストプールが別リージョンにあるケース（マルチリージョン）:
ユーザーは Region 1 の Web サービスに到達しますが、ホストプールが Region 2 にある場合、リソースディレクトリが「Region 2 のブローカーと地理的データベースを参照するよう」Web サービスに指示します。ユーザーはこの切り替えを意識することなく正しいフィード情報を受け取れます。
RDP 接続
ユーザーがフィードからデスクトップまたはアプリに接続すると、RDP 接続は次のように確立されます。
- すべてのリモート セッションは、Azure Front Door への接続から始まり、Azure Virtual Desktop へのグローバル エントリ ポイントを提供します。Azure Front Door は、ユーザーのデバイスの待機時間が最も短い Azure Virtual Desktop ゲートウェイ サービスを決定し、そのサービスへの接続を指示します。
Azure Front Door が RDP 接続のグローバルエントリーポイントとして機能します。グローバルエントリーポイントとは「世界中どこからアクセスしても最初に到達する単一の受付口」のことで、Azure Front Door 自体が世界中に分散配置されているため、ユーザーは最も近いエッジに接続してから最適なゲートウェイサービスへ誘導されます。
- ゲートウェイ サービスは、同じ Azure リージョンのブローカー サービスに接続します。ゲートウェイ サービスを使用すると、セッション ホストは任意のリージョンに存在し、ユーザーは引き続きアクセスできます。
ゲートウェイがブローカーに接続して接続先を確認します。ゲートウェイが仲介役に入ることで、セッションホストがどのリージョンにあっても接続できる柔軟な構成が実現されています。
- ブローカー サービスは、ユーザーのデバイスとセッション ホストの間の接続を引き継ぎ、調整します。ブローカー サービスは、セッション ホストで実行されている Azure Virtual Desktop エージェントに、ユーザーのデバイスが接続したのと同じゲートウェイ サービスに接続するように指示します。
ブローカーがセッションホスト上の AVD エージェントに「同じゲートウェイに来い」と指示します。これにより、ユーザー側・セッションホスト側の両方が同じゲートウェイに接続された状態になります。
- この時点で、構成と使用可能なネットワーク プロトコルに応じて、次の 2 つの接続の種類のいずれかが行われます。
ここから接続方式が 2 択に分かれます。
a. リバース接続トランスポート: クライアントとセッション ホストの両方がゲートウェイ サービスに接続されると、クライアントとセッション ホストの間で伝送制御プロトコル (TCP) を使用して RDP トラフィックの中継が開始されます。リバース接続トランスポートは、既定の接続の種類です。
リバース接続トランスポートが既定です。TCP ベースで、ゲートウェイが双方向の中継役を担います。「リバース」という名前の通り、セッションホスト側からゲートウェイへ接続しに行く方向になるため、セッションホスト側でポートを開放する必要がないというメリットがあります。
b. RDP Shortpath: ゲートウェイ サービスをバイパスして、ユーザーのデバイスとセッション ホストの間に直接ユーザー データグラム プロトコル (UDP) ベースのトランスポートが作成されます。
RDP Shortpath はゲートウェイをバイパスして UDP で直接つながる方式です。中継がない分レイテンシが低く、スループットも向上します。ただし、ネットワーク設定（UDP ポートの開放など）が別途必要です（またの機会に記事にします）。
以下は Microsoft Learn からの引用図です。
左側の TCP の矢印がリバース接続トランスポート（ゲートウェイ経由）、右側の 2 本の UDP の矢印が RDP Shortpath です。RDP Shortpath ではゲートウェイをバイパスしてセッションホストと直接 UDP 通信します。
サービスの回復性
Azure Virtual Desktop は、障害に対する回復性を備え、ユーザーに信頼性の高いサービスを提供するように設計されています。
このサービスは、個々のコンポーネントの障害に対する回復性を備え、障害から迅速に復旧できるように設計されています。
1 つのコンポーネントが壊れてもサービス全体は止まらない、というのが基本設計思想です。
Azure Virtual Desktop の Microsoft が管理するコンポーネントは、現在、ユーザーに近づき、回復性のあるサービスを提供するために、約 40 の Azure リージョンに配置されています。
約 40 リージョンという広範な分散配置により、どこから利用しても物理的に近い場所からサービスを提供できます。
回復性は、次の方法でグローバル、地理的、および Azure リージョン内に実装されています。
回復性は「グローバル」「地理的（リージョン間）」「リージョン内」の 3 階層で実装されています。
グローバルレベルの回復性
Azure Traffic Manager は Web サービスのトラフィックを転送し、Azure Front Door はゲートウェイ サービスのトラフィックを転送します。1 つの Azure リージョンから Web サービスまたはゲートウェイ サービスを利用できない障害が発生した場合、またはリージョン全体が停止している場合、トラフィックは、最も近いリージョンの次に最も近い使用可能なインスタンスにリダイレクトされます。トラフィックのリダイレクトにより、ユーザーは引き続き新しい接続を行うことができます。
あるリージョンの Web サービスやゲートウェイが落ちた場合、Traffic Manager / Front Door が自動的に次に近いリージョンへリダイレクトします。
地理的レベルの回復性
地理的データベースでは、各地域内 Azure SQL データベースのフェールオーバーとデータ レプリケーション機能が使用されます。データベースが停止した場合、データベースはセカンダリ レプリカにフェールオーバーされ、通常の操作が再開されます。
地理的データベースのバックエンドは Azure SQL Database で、セカンダリレプリカへの自動フェールオーバーが組み込まれています。
フェールオーバー中は、フェールオーバーが完了するまで新しい接続が失敗する時間が短くなりますが、このフェールオーバーは既存の接続には影響しません。
フェールオーバー中は一時的に新規接続が失敗することがある点は理解しておきたいところです。ただし既存セッションへの影響はないのが重要なポイントです。
リージョン内の回復性
リソース ディレクトリ、ブローカー サービス、Web サービス、ゲートウェイ サービスはすべて、Azure Virtual Desktop 用の Microsoft が管理するコンポーネントが配置されている各 Azure リージョンで使用できます。
各リージョンに全コンポーネントが揃っているため、1 つのリージョンで完結した接続が可能です。
各コンポーネントには複数のインスタンスがあるため、単一障害点はありません。各 Azure リージョン内には、インスタンスの障害に耐えるために個別に動作する各コンポーネントの個別のインスタンスまたはクラスターが少なくとも 6 つあります。
「単一障害点なし」は可用性設計の基本原則です。各コンポーネントは 1 リージョン内に 6 インスタンス以上存在し、1 つが落ちても残りが処理を引き受けます。
たとえば、リージョンには、要求を満たすのに十分なゲートウェイ サービスのインスタンスがあるだけでなく、それらのインスタンスの障害にも対応できる十分な容量があります。
「6 インスタンス存在する」だけでなく「うち数台が落ちても残りで捌ける容量を持っている」点がポイントです。
ゲートウェイ サービスのインスタンスが失敗した場合、ゲートウェイ サービスのその特定のインスタンスを介して中継されている TCP ベースの RDP 接続は削除されます。切断されたユーザーが再接続すると、残りのインスタンスは要求を処理し、各ユーザーを既存のセッションに再接続します。ゲートウェイ サービスの他のインスタンスによって処理されるその他のすべてのセッションは影響を受けません。
ゲートウェイインスタンス障害時の挙動を整理すると：
- そのゲートウェイを経由していた TCP RDP セッションは切断される（影響あり）
- 再接続すると残りのゲートウェイインスタンスが処理し、元のセッションに戻れる
- そのゲートウェイを使っていなかったユーザーは影響を受けない
Azure Virtual Desktop が依存している他の Azure サービスは、回復性と信頼性を備えて設計されています。詳細については、「Azure Traffic Manager と Azure Front Door」を参照してください。
Traffic Manager と Front Door 自体もそれぞれ高可用性設計なので、依存先も「倒れない前提」で設計されています。
グローバル展開
Azure Virtual Desktop は、組織がワーカーの要求に適応し、特にリモートで作業するのに役立つサービスです。 これは、デスクトップとアプリケーションを事実上どこでも提供する、安全で信頼性の高い柔軟な方法を提供します。
コロナ禍をきっかけにリモートワークの需要が急増しましたが、AVD はその要求に応えるために設計されています。
Azure Virtual Desktop は、ワークロードの高可用性サービスを確保するのに役立つ Azure の機能とサービスを使用して、回復性を持つように設計されています。
これまで見てきた Traffic Manager、Front Door、Azure SQL DB のレプリケーション、インスタンスの多重化など、Azure の豊富なサービスを組み合わせることで高い可用性を実現しています。
まとめ
- Microsoft が管理するコンポーネント（Web、ブローカー、ゲートウェイ、リソースディレクトリ、地理的DB）は約 40 リージョン × 6 インスタンス以上で稼働しており、単一障害点がない
- ユーザーの接続は「フィード検出（Traffic Manager → Web → ブローカー → 地理的DB）」と「RDP 接続（Front Door → ゲートウェイ → ブローカー → セッションホスト）」の 2 段階で行われる
- RDP 接続方式は**リバース接続（TCP・既定）とRDP Shortpath（UDP・低レイテンシ）**の 2 種類がある
- セッションホスト（VM）の可用性・バックアップは customer の責任。可用性ゾーン・Azure Backup・Site Recovery などで対策できる
- リージョン障害時も Traffic Manager / Front Door が自動リダイレクトするため新規接続への影響を最小化できる
('ω')ノ