Windows Virtual Desktop #52 Windows Virtual Desktop エクスペリエンス見積もりツール 後編

この記事のWVDは”Windows Virtual Desktop Spring 2020 Release”が対象です。

前回の記事に続いてWindows Virtual Desktop エクスペリエンス見積もりツール を試していきます。 今回は自宅のクライアント以外からラウンドトリップ時間を確認していきます。 具体的には中国本土から確認します。

中国本土からのテストですが、Alibaba Cloud の ECS を利用します。 中国本土のリージョンに Windows Server 2019 を起動し、Web ブラウザ ( Internet Explorer ) からWindows Virtual Desktop エクスペリエンス見積もりツール にアクセスし、ラウンドトリップ時間をリージョンごとに確認します。 中国本土以外外にも香港、シンガポールリージョンと東京リージョンも参考として確認します。

Alibaba Cloud の中国リージョンは Document Center で確認可能です。 いつの間にか 10 リージョンまで増えていました。

RegionCityRegion IDNumber of zones
China (Qingdao)Qingdaocn-qingdao2
China (Beijing)Beijingcn-beijing8
China (Zhangjiakou)Zhangjiakoucn-zhangjiakou3
China (Hohhot)Hohhotcn-huhehaote2
China (Ulanqab)Ulanqabcn-wulanchabu2
China (Hangzhou)Hangzhoucn-hangzhou8
China (Shanghai)Shanghaicn-shanghai7
China (Shenzhen)Shenzhencn-shenzhen5
China (Heyuan)Heyuancn-heyuan2
China (Chengdu)Chengducn-chengdu2

しかし、コンソール上で確認すると 11 リージョンあることがわかります。”Guangzhou” がドキュメントに記載の無いリージョンです。

以下、中国本土11リージョンと香港、シンガポール、東京の14地点からWindows Virtual Desktop エクスペリエンス見積もりツール を利用した結果となります。

Hangzhou

Azure の East Asia までのラウンドトリップ時間は 5 ms です。 

Shanghai

Azure の East Asia までのラウンドトリップ時間は 8 ms です。 

Qingdao

Azure の East Asia までのラウンドトリップ時間は 2 ms です。

Beijing

Azure の East Asia までのラウンドトリップ時間は 2 ms です。

Zhangjiakou

Azure の East Asia までのラウンドトリップ時間は 90 ms です。

Hohhot

Azure の East Asia までのラウンドトリップ時間は 3 ms です。

Ulanqab

Azure の East Asia までのラウンドトリップ時間は 105 ms です。

Shenzhen

Azure の East Asia までのラウンドトリップ時間は 4 ms です。

Heyuan

Azure の East Asia までのラウンドトリップ時間は 3 ms です。

guangzhou

Azure の East Asia までのラウンドトリップ時間は 260 ms です。

Chengdu

Azure の East Asia までのラウンドトリップ時間は 5 ms です。

Hongkong

Azure の East Asia までのラウンドトリップ時間は 3 ms です。

Singapore

Azure の Southeast Asia までのラウンドトリップ時間は 4 ms です。

Tokyo

Azure の Japan East までのラウンドトリップ時間は 4 ms です。

ラウンドトリップ時間の結果を表にまとめました。  

Alibaba Cloud RegionAzure RegionRound Trip (ms)
China (Qingdao)East Asia2
China (Beijing)East Asia2
China (Zhangjiakou)East Asia90
China (Hohhot)East Asia3
China (Ulanqab)East Asia105
China (Hangzhou)East Asia5
China (Shanghai)East Asia8
China (Shenzhen)East Asia4
China (Heyuan)East Asia3
China (Chengdu)East Asia5
China (guangzhou)East Asia260
HongkongEast Asia3
Singapore (Singapore)Southeast Asia4
Japan (Tokyo)Japan East4

気になったの点は2つあります。 Zhangjiakou , Ulanqab , guangzhou の遅延が大きいことが1点目。2点目はそれ以外のリージョンから Azure East Asia (Hongkong) への Round Trip が小さすぎる点です。 Alibaba Cloud の Hongkong リージョンから Azure の East Asia に対しての 3ms はわかります。それ以外の例えば Beijing や Qingdao は 2 ms 、他も1桁台のラウンドトリップ時間です。 物理的な距離を考えても遅延が小さすぎます。

Windows Virtual Desktop エクスペリエンス見積もりツール はどうやって遅延を測定しているのでしょうか。 CDN の近いノードにキャッシュした内容を応答しているのではないか?と推測されますが実際のところはわかりません。。。

せっかく中国にインスタンスを立ち上げたので Windows Virtual Desktop の仮想マシンに接続出来ることも確認してみます。 以前の記事でも Alibaba Cloud の上海リージョンと北京リージョンから利用出来ることは確認していました。 今回も接続を確認するとともに Windows Desktop Client の接続情報の確認機能からラウンドトリップ時間を確認し、Windows Virtual Desktop エクスペリエンス見積もりツールで確認できるラウンドトリップ時間と差異があるかを見ていきます。

Alibaba Cloud の北京リージョンの Windows Server 2019 にWindows Desktop Client をインストールし、フィードを取得します。

以下はフィード取得後の画面なのですが、ここに至るまで何度も認証を求められました。 以前のテストではそのようなことはなかったのですが何かおかしな感じです。

次に、実際のリソースにアクセスすると失敗しました。

エラーメッセージは以下の通りです。 Error code は “0x300000d” です。 メッセージ”The remote resource can’t be reached.” からクライアントから Azure East Asia にある Windows Virtual Desktop の管理コントロールプレーンにネットワーク的に接続出来ていないようです。

[Window Title]
Remote Desktop

[Content]
The remote resource can’t be reached. Check your connection and try again or ask your network administrator for help.

[Expanded Information]
Error code: 0x300000d
Extended error code: 0x0
Timestamp (UTC): 2020-10-16T17:11:56.902Z
Activity ID: e8a979f0-9f23-4239-8402-586260d30000

前回の記事でテストしたのは2020年7月です。 今日はたまたま接続出来ないだけなのか、出来なくなってしまったのかは不明です。 経路上どこに問題があったのか、北京以外のリージョンではどうなのか、切り分けできるところはあるのですが時間切れで今回は調査を断念します。 今回の記事を書くにあたり Alibaba Cloud の従量課金のインスタンスの自動リリースを1時間で設定しており、上記のエラーのあとほどなくして中国本土の11台の仮想マシンは自動リリースされてしまったということがありました。

なお、中国本土の11台の稼働マシンとは若干をおいて作成した東京リージョンの仮想マシンが残っていたのでこちらでも接続を確認します。

Windows Server 2019 上に Windows Desktop Client をインストールし、フィードを取得します。 こちらは問題なく実施出来ました。 北京リージョンであったAzure AD 認証の繰り返しのような挙動もありませんでした。

Windows Virtual Desktop の仮想マシンにも問題なく接続出来ました。

今回のテストでわかったことは、Windows Virtual Desktop エクスペリエンス見積もりツール で確認できるラウンドトリップ時間は正確ではない可能性があることです。  先に書いた通り、Azure の East Asia (Hong Kong)へのラウンドトリップ時間が 北京も青島も上海も 数ms であるはずがないからです。 仮説として考えた CDN の介在ですが、ツールの性質上、Azure 側で CDN を経由するように構成することもあまり考えられません。 

あとは、Alibaba Cloud の北京リージョンから Windows Virtual Desktop を利用出来なかったことも気になります。 一時的なものなのかそうではないかは今日の結果だけではわからないので別日に再度確認する、他のリージョンでも確認するなど別途確認することになりそうです。

最後に。今回のテストは1時間もかからないものでしたが、そのわずか1時間で中国の11地点でサーバ立ち上げが出来ること、その料金も合計で数百円もかからないこと、それを日本にいる日本人の私が簡単に実施できること、この点は Alibaba Cloud の最大の強みだなと再認識しました。

今回の記事は以上となります。