地方ならではのクラウドVDIの落とし穴

かなり久しぶりの技術ネタ投稿かもしれません

こんばんわ。九州支社で働く二等兵こととみーです。
技術探索に注力し始めてはや1年を越え、実案件の技術支援もしつつ今日も「言葉しか知らないこと」の中身を知るべく取り組んでいる日々を過ごしています。技術に近いネタをこのブログに書くのは実に2年ぶりぐらいですかね？珍しくそれっぽいことを書いてみることにしました。

私はちょうど10年前、家庭の事情により関東のIT企業を離れて九州のこの地にUターンしました。それからずーっとそこでの仕事を続けてきたのですが、九州でのインフラ構築やクラウド利用に関わるお仕事も中々規模が大きく、当初は「あれ、こんなすごいの作るの？」とか全身震えながら仕事をした時期もあったなぁと時々述懐することがあります。

話がそれました、すみません。
地方でお仕事していて、「ああ、やっぱり東京とは違うなー」と感じるポイントとしていくつか挙げられる中で、今回とりあげるものは、利用する場所と実際に動くシステムの設備間の距離に関する話です。関東在住を続けていたらなかなか気づかなかったんじゃないかというポイントでもある話ですので、何かの参考になれば幸いです。

3DCGツールがVDI経由だとまともに動かない

丁度昨年8月ごろ、ディスプレイカードを新調した時に「ちょっと背伸びをして3DCGを作るツールに触れてみよう」と思ったのがきっかけで、今日に至るまでDAZ Studioという3DCG作成ツールを使ったCG作成が趣味として増えました。このツール、初期のモデリングなどが出来ずとも既に完成されたアセットと呼ばれる部品を使って人や動物、風景を描くことができるという特色を持っており、私のように絵心のない人間でもそれなりの3DCG画像を描くことが可能だったりします。

現在メーカーサイトにて無償で作れるギャラリーを活用し、細々と作品をアップロードしていたりすることもあります。

ここで困ったのがこの3Dツール、ものすごく応答性に敏感であり、なぜかリモートデスクトップなどでつないだ環境ではまともに操作できなくなったりするのです。カーソルを途中で方向転換させたいのに方向転換せずにいつまでもどこまでも先に進んでしまったりとか、目の前でいきなりくるくる（フィギュア：いわゆる人形）がプレビュー画面で回転しちゃったりで全く使い物にならない状況も発生したりしました。

例えば以下のように編集画面の視点を90度切り替えるような操作をします。端末上で操作する分には問題ないんですが、リモート操作だとこれが思うようにできないんです。余計に回転したり、あるいはまったく動かなかったり。気づけばローカル端末を直接操作すれば30分でできるようなことに2時間を費やすことも多くありました。結構描くことをするのってストレス発散になるんですけど、これじゃぁストレスが溜まるだけやん・・

さらに困ったのが、例えばAzure VMなどを使ってGPUインスタンスを使う場合でもこの現象が起きたことです。あれ、GPUの性能じゃないの？でも、ネットワーク帯域はそんなに使用されていないよ、どうしてこんなに動きが悪いんだろう？と悩んでいたら、弊社堂前の登場しておりますこの動画をたまたま見ていてハッと気づきまして。

インターネット・ミニ解説: 通信速度と遅延 なぜ「エッジ」が必要なのか

その後調べてみた結果、まさかのRound Trip Time(RTT)による影響を受けていたことが分かりました。

物理的な距離の影響

2022年現在、日本国内は基本的に光ファイバーを用いた信号の送受信によってコンピュータのネットワーク通信を可能にしています。利用者が使う端末とネットワーク間の接続は無線通信を行うことによって担保されているケースもありますが、中核的なところでは光ファイバーを伝って通信設備を潜り抜けつつ通信してるケースの方が多いかと思います。

光は1秒間に地球を7周半すると言われてますが、光信号は屈折しながら光ファイバー内を飛んでいくことから、その速度は1Km進むのに5μ秒かかると言われています。さらに、光ファイバーは共同地下坑とか電柱を伝って張られていることもあり、直線距離で目的地へビューンと飛んでいってるわけではありませんで、実は想像以上に長い距離を伝って通信は行われています。

pingコマンドをインターネット上のアドレスに向けて実行した時、応答時間が表示されると思うのですが、これはICMPと呼ばれるプロトコルに従って発射されたパケットが目的について戻るまでの時間を示しており、これをRound Trip Time(RTT)と呼んでいます。ゲーム界隈などではpingを実行して確認できる値であることから「ping値」と呼んでる人もいらっしゃるようです。

このRTTですが、例えば実際に私が在住している福岡県から東京都までは、凡そ30ms(ミリ秒)かかると言われています。

実はこの30msという時間は1000分の30秒ということで、非常に短い時間ではあるのですが、実はリアルタイム操作をする際にはなかなかの遅延なのです。

リアルタイム操作の落とし穴

リアルタイム操作をするというのはどういうケースかと言いますと、

• 3DCADや3DCGに代表されるような、細やかなマウス操作を必要とし、即時応答を求められるアプリケーション
• eスポーツに代表されるような、反射神経・感覚的な高い能力を要求するようなアクション系ゲーム

が該当します。これらのケースでは、如何に入力に対して応答が迅速に返ってくるかが要求され、それが一般的に言われる速度＝帯域よりも重要なファクターになってきます。

動画に関しては送信する方が片方によるため、送信側が時系列に正しくデータが送れれば多少RTTが大きくとも特に問題になりません。しかし、リアルタイムアプリケーションを使用する場合、特にドラッグ操作が行われた時は大量のマウス位置情報のデータがクライアントからアプリケーションへ送信され、アプリケーションはその送信されたデータを解釈し、動画再生とそれほど変わらないレベルでのビュー画面応答を返す必要が出てきます。

以下は、DAZ StudioをRDP接続した状態で操作したときの送受信帯域、送受信パケット数をグラフにしたものです。画面更新を頻繁かつ高速に行わせたところ、送受信帯域の使用量もさることながら、送受信パケット数の青いグラフが気になりました。画面転送するパケット量に対しておよそ半分の量で「クライアントからサーバに対しての通信」が発生していました。これはクライアントからサーバに対して送られた「マウスの移動情報」を示しています。

送受信が頻度としていずれも高いこと、ユーザの反応性がそのままアプリケーション側の応答にも反映されなければならない、それがリアルタイム操作というものの難しいところかなと思います。RTTの大きさによる影響はまさにこの部分を直撃するものです。

都市圏向けソリューションが地方に通用しないケース

こういう影響が分かると頭を抱えてしまうのが「首都圏の企業向けにうまく言ったソリューションパターンが地方ではうまくいかない」という点です。ユーザも設備も近場に集約されている場合、その応答時間は非常に短く、実はクラウドVDIの応答遅延時間などは非常に小さい値に収まります。こうした場合、実はリアルタイム操作の影響はあまり発生しません。

私の3DCG環境では、だいたい20ms以内であれば何とか使用に耐えうるレベルでツールが使えるようになることを確認しています。
この問題が生じるケースはまさに、私がここ九州にいる場合です。

九州から見て、例えばMicrosoft Azureのリージョンは西日本・東日本の2つが存在しますが、20ms以内で収まる環境は基本的に西日本リージョンとなります。しかしながら、私が使いたいGPUインスタンスは2022年4月現在西日本にはなく、東日本リージョンにしかありません。東日本リージョンでは、凡そ30ms-40msの遅延がかかり、この時画面の応答性は「一線を越えた」と言わんばかりに大幅に劣化します。

このように、ひとが近距離に集ってる場合には顕在化しない問題が、ユーザと設備の距離が離れたことで顕在化するケースが出てくるのです。基本的にインターネット自体が「離れていてもコミュニケーションできる」というコンセプトで考えられているものであるが故、このように物理的な距離が障害要因になりうるというのはなかなかの驚きを伴うものであったりします。

こういうケースもあります。物理的には福岡⇔大阪間で離れている操作対象サーバをリモート操作するわけですが、踏み台サーバが東京都にある場合、まず踏み台サーバに向けてアクセスし、続いてもう一段階踏み台サーバから操作対象サーバへリモート接続することによって、結果的に最初の接続で30ms、次の接続で15msかかった結果、45msもの遅延が生じたケースになります。この場合、通常のサーバ操作を行うにも違和感を感じるレベルまで遅延時間は長くなっています。保守オペレーションを行う際はより慎重さが必要となります。

私が実体験した3DCGツールがまともに動かなかったケースではこれに近い状況が発生しており、自身のリモート操作対象マシンに接続するために福岡から東京、東京から福岡という非常に遠回りな2段階の通信を行っていました。実質60msの遅延を発生させている環境で操作を試みようとしたということになりました。それ故、マウス位置情報と見た目の更新連携がうまくいかず、画面の視点を操作できなくなったようです。

リアルタイム応答性向上の施策

こうした部分への対処はメーカーあるいはクラウドベンダーなどいろいろなところで取り組まれています。

• ツール側・あるいはアプリケーションプロトコル側でリアルタイム応答性を向上させる施策を講じる（リモート操作された場合のパターンに対する応答方法の改善など）
• より高速に応答できるトランスポートプロトコルを使用する（例えばTCP通信でなく、UDP通信をする。あるいはQUIC対応するなど。）

ツール・アプリケーションプロトコル側での改善策

前者の場合、特に影響の大きい動きとして「連続的にマウスカーソルを同じ方向に動かし続けると加速する」という部分でした。マウスカーソルを動かす範囲が小さければ「緻密な作業が必要」と判断して細かく動き、大きければ「オブジェクトなどをより遠くへ移動させる必要がある」と判断してそのような動作をするよう設計されているのだと思われますが、応答遅延によりこの信号送受信にずれが生じたのだと考えられます。結果、ツールがマウス移動情報を誤認して今回の問題を発生させた可能性があります。
昨今、このような挙動は多くの人が確認された可能性もあることから、ユーザからのフィードバックにより改善が為されることもあり得ます。
また、同様にリモート操作プロトコルに対して似たような改善が為される可能性もあるのかなと思われます。

先日私が検証用途に使っているGPUインスタンスのOSを先日Windows11へ変更したところ、劇的に応答性が上がる現象を目の当たりにしました。時間帯などの要因もある(いつも30ms強ぐらい発生していた遅延が24msぐらいに下がっているなど）のだと思いますが、リモート操作でも3DCGツールがギリギリ使えるレベルになってきました。RDP仕様の変化についてまだ情報は得られていませんが、何かしらの改善をMicrosoft社が導入したのかもしれないですね。

トランスポート・プロトコル側での改善

後者の場合、例えばTCP通信の場合は3ウェイハンドシェイクを行うという仕様により、実はRTTが大きいとそのネゴシエーションに時間がかかって正味のデータ送信量が少なくなるという特性があります。そこで、そのネゴシエーションの必要がないUDP通信を使用することで、こうしたオーバーヘッドを軽減させて通信効率を上げるというアプローチも考えられ、Microsoft Azureの場合は後述するRDP Shortpathという技術が挙げられます。

QUICはそんなUDPをさらに強化したトランスポートプロトコルです。詳しくは　QUICをゆっくり解説 – 新しいインターネット通信規格　を参照いただければと思います。

RDP Shortpathという機能

Microsoft Azureでは仮想デスクトップサービスとして提供されているAzure Virtual Desktopに対しては、RDP Shortpathという機能が実装されています。UDPを主体にした通信に切り替えることで応答性を引き上げることが可能であると共に、閉域網を構成している環境では、RDP通信する際に使用するネットワークを閉域網に優先させることでセキュリティレベルの引き上げを可能にしながらより通信効率の高いネットワークを行うことで、よりリアルタイム性を高めることを可能としています。

 

ネットワークレンダリング

3Dの世界で言えば、さらにクラウドサービス側でレンダリングと呼ばれる重要な処理を肩代わりしようというものも登場してきています。ネットワークレンダリングと呼ばれる手法では、3D開発などにおける「本番化」ともいえる最終レンダリング処理をまるっと外部サービスに行わせる「ネットワークレンダリング」という手法が存在します。以下は、NVIDIA Irayと呼ばれるレンダリングエンジンを遠隔で受け付け実行するIray ServerをDAZ Studioから使用した場合の大まかな動きを図示したものになります。

他にも、サービス提供側をネットワークレンダリングファームとも呼び、高価なGPUを搭載したレンダリングファームにデータを引渡してバッチ処理をさせ、その結果を後で受領するというものがあります。手元の開発環境ではあくまでプレビュー表示の精度に特化させてワークステーションを構成し、最終的な品質の高いデータ作りは外部サービスを利用することで、手元環境のコスト圧縮を図るというものです。

非常に優秀なオンプレミスVDI系ソフトウェアが使うプロトコル

また、VDIに関してもオンプレミス環境に対するパッケージ（VMware Horizon や Citrix Virtual Desktop等）はまだまだ元気です。
VMware HorizonはBlastという機能を使用しており、Citrix Virtual DesktopはICA(Independent Computing Architecture)という機能が用いられています。これらの機能はRDP/AVDが使用する機能と比べるとさらにインテリジェンス化されており、通信状況によってフレキシブルにTCP/UDPを切り替えます。また、導入環境にオンプレミス・クラウドを問わず一元管理できる仕組みを設けることで、未だVDI領域におけるリーダー的な地位を確保していると言えるでしょう。

どんなに抽象化しても残る物理的な制約はある

私たちのインターネット周辺環境はクラウド化なども相まってかなり抽象的な概念の下で利用するケースが増えましたけれど、このように未だ物理環境の要因によって制限を受けている側面もあること、そしてそうしたパッと見どうにもならなさそうなところにおいても何とかして応答性を確保してよりよい環境にしようと努力している人たちがいるということをほんのちょっぴり知っていただければ幸いです。