2026年9月30日、AVDの「リージョンホストプール(Regional host pools)」がGAになりました。まずはEast US 2とCentral USの2リージョンからです。
ホストプールの作成画面に[デプロイ スコープ]という項目が増えていて、[地域]と[リージョン]を選べます。
公式ブログには「リージョン間の依存関係を取り除く」とありますが、これまでもホストプールの場所は選べましたし、メタデータも複製されていました。
では、何が変わったのか。メタデータのデータベース(DB)はどこにあって、障害のときにどこが止まるのか。
ドキュメントだけでは見えなかったので、検証環境で確認してみました！
さっそく、構成を見てみましょう！
【デプロイ スコープの表示名】
最初に戸惑ったのが、日本語ポータルの表示名です。[地域]がリージョンの意味に見えますが、逆です。
| ポータル表示 | API の値 | メタデータの置き場所 |
|---|---|---|
| 地域(既定) | Geographical | Geo(米国、日本など)ごとに1つのDB |
| リージョン | Regional | 選んだAzureリージョンのDB |
※Azure の用語では geography＝地域、region＝リージョンです。[デプロイ スコープ]は、場所に East US 2 か Central US を選んだときだけ表示されます。
【構成図】
場所をCentral USを指定したとしても、Primary DBはEast US 2となり、セッションホストがCentral USに存在していても、メタデータはEast US 2に取りに行きます。
場所をEast US 2を指定した場合、Primary DBはEast US 2、Secondary DBはCentral USとなる。※本来想定していた構成
場所をEast US 2を指定した場合、Primary DBはEast US 2、Secondary DBはCentral USとなる。Primary DBはゾーン冗長構成。
[地域][リージョン]どちらの場合でも、MetaDataはペアリージョンに複製されていて、障害のときはそちらに切り替わります。
【PrimaryとSecondary】
米国の2リージョンで整理すると、こうなりました。
| 指定した場所 | 地域(Geographical) | リージョン(Regional) |
|---|---|---|
| 結論 | どこを選んでもPrimaryはEast US 2 | 選んだ場所がPrimary |
| Central US | Primary：East US 2 Secondary：Central US |
Primary：Central US Secondary：East US 2 ※ |
| East US 2 | Primary：East US 2 Secondary：Central US |
Primary：East US 2 Secondary：Central US ※ |
※リージョンのSecondaryは、ドキュメントの「ペアリージョンに複製する」という記述からの推定です。
それでは、確認してみましょう！
【確認方法】
DBの場所はどこにも公開されていません。そこで、2つの方法で外から確かめました。
①空のホストプールを作り、登録トークンの中身を見る
登録トークンはJWT形式なので、デコードすると接続先のブローカー(BrokerUri)が書かれています。
②ブローカーのヘルスチェック(/api/health)を見る
ブローカーのヘルスチェックは認証なしで応答し、リージョン名とDBへの接続確認にかかった時間を返します。DBが遠いほど時間がかかるので、DBのある場所が推定できます。
【登録トークンの接続先】
地域(Geographical)とリージョン(Regional)で、ホストプールを6つ作って比べました。
| スコープ | 選んだ場所 | BrokerUri |
|---|---|---|
| 地域 | Japan East / Japan West | rdbroker-g-jp-r1(同じ) |
| 地域 | East US 2 / Central US | rdbroker-g-us-r1(同じ) |
| リージョン | East US 2 | r1.eus2.avdbroker |
| リージョン | Central US | r1.cus.avdbroker |
地域では、Japan EastとJapan Westのどちらを選んでも接続先は同じでした。場所の選択で決まるのは「どのGeoか」だけです。
リージョンでは、接続先がリージョンごとに分かれています。※現時点では、日本は未対応
【地域(Geographical)のDBの場所】
各リージョンのブローカーで、読み取り用DBへの接続確認にかかった時間を12回ずつ測りました(中央値)。
| Geo | ブローカーのリージョン | 接続確認の時間 |
|---|---|---|
| 米国 | East US 2 | 3.9ms(最短) |
| 米国 | East US | 9.2ms |
| 米国 | Central US | 35ms |
| 米国 | West US 2 | 70ms |
| 日本 | Japan East | 4.7ms(最短) |
| 日本 | Japan West | 11.4ms |
East US 2(日本ならJapan East)から離れるほど、時間が長くなっています。
Central USのブローカーも、読み取りをEast US 2のDBに対して行っているということです。Secondaryは障害に備えて待機しているだけで、普段の読み取りには使われていません。
【リージョン(Regional)のDBの場所】
リージョンのブローカーも同じように測りました。
| 接続先 | ブローカーが動くリージョン | 接続確認の時間 |
|---|---|---|
| cus 用 | Central US | 約5ms |
| cus 用 | East US 2(ペア) | 約35ms |
| eus2 用 | East US 2 | 約5ms |
| eus2 用 | Central US(ペア) | 約35ms |
Central US用のDBはCentral USに、East US 2用のDBはEast US 2にありました。
ペアリージョン側にも、そのリージョン用のブローカーが待機しています。
障害のときに止まる範囲
Primaryに障害が起きると、地域でもリージョンでもSecondaryへの切り替えが発生します。
切り替えている間は、新しい接続ができません。すでに接続しているセッションは影響なし。
Central USにホストプールを作った場合で比べてみます。
| 障害 | 地域(Geographical) | リージョン(Regional) |
|---|---|---|
| East US 2 | 影響あり DBがCentral USに切り替わるまで新規接続ができない |
影響なし |
| Central US | DBは無事 (セッションホストのVMは止まる) |
DBがEast US 2に切り替わるまで新規接続ができない (セッションホストのVMも止まる) |
地域(Geographical)だと、使っていないEast US 2の障害でもCentral USのホストプールが止まります。これが「リージョン間の依存」の原因です。
リージョン(Regional)にすると、DBの障害とセッションホストの障害が同じリージョンになるので、対応がしやすいです。止まる理由が1つ減る、というのが一番の効果だと思います。
リージョンにするメリットと注意点
【効果が大きい構成】
・GeoのPrimary以外のリージョンにホストプールを置く場合(米国ならCentral US、日本ならJapan West)
・2つのリージョンにホストプールを置いてDRを組む場合。地域(Geographical)では、リージョンを分けてもDBは1つです
・メタデータを1つのリージョンの中に置きたい場合
反対に、East US 2にホストプールを置く場合は、地域でもリージョンでもPrimaryとSecondaryの組み合わせが変わりません。違いは、ほかのリージョンのホストプールとDBを共有するかどうかだけです。
【注意点】
・地域(Geographical)とリージョン(Regional)のオブジェクトは混在できません。ワークスペースもアプリケーション グループも、リージョンでそろえます。
・デプロイ スコープは作成後に変更できません。既存のホストプールの移行は、段階的に提供される予定です。
・セッションホストのVMは、メタデータと同じリージョンに置くことが推奨されています。
・診断データの送信先は、リージョンにしてもGeo単位(rddiagnostics-g-us-r1)のままでした。
・リージョンのセッションホストのエラーとチェックポイントがLog Analyticsに送られない。
まとめ
地域(Geographical)は、どこを選んでもGeoで1つのDBを使います。米国ならEast US 2、日本ならJapan Eastです。
リージョン(Regional)は、選んだリージョンのDBを使います。
対応リージョンで新しくホストプールを作るなら、リージョンを選ばない理由はほぼありません。日本で選べるようになったら、Japan Westに置いている環境や、東西でDRを組んでいる環境から切り替えを検討するのがよさそうです。
※本記事のDBの場所は、ヘルスチェックの応答時間から推定したものです(2026年10月7日時点)。Microsoftが公開している情報ではありません。DBの複製方式(フェールオーバー グループかアクティブ geo レプリケーションか)は、外からは判別できませんでした。
