仮想デスクトップ高速表示技術

連載 :

2011年8月2日(火)

エンジニアリングクラウドを支える技術

昨今、さまざまな分野でグローバル化が進む中で、日本が継続的に成長していくために欠かせないのが、日本のものづくり復興だと言われています。日本のものづくりを支えるのは日本のICTであるという信念のもと、富士通は次世代ものづくり環境「エンジニアリングクラウド」を発表しました。

「エンジニアリングクラウド」は、安全性・信頼性、既存システムや他クラウドとの連携、グローバルレベルでの標準化・共通化等、富士通のノウハウや技術をもとにサービスとして展開するものです。今回は、このエンジニアリングクラウドでコア技術として用いられている独自技術についてご説明します。

シンクライアントシステムの実現方法は

クラウドを利用して、デスクトップ環境を仮想的に配置し、ネットワーク経由でリモート操作する仮想デスクトップは、シンクライアントシステムの一つです。

富士通研究所は、仮想デスクトップにおいて、動画や高精細な画像等の多量な画面データ転送の課題に対応し、新しい高速表示技術を開発しました。この技術は、セキュリティやコストダウンといった側面だけでなく、私たちのワークスタイルに変化と多様性をもたらす技術としても期待されています。

そもそも、なぜ、シンクライアントシステムで画面データ転送量が多くなるのでしょうか。あらためて、シンクライアントシステムの動作原理を確認します。シンクライアントシステムでは、サーバー側で実行するアプリケーションの描画結果やデスクトップ画面をフレームバッファに出力し、そのフレームバッファの画面データをクライアント側にリアルタイムに送信することで、クライアント側でサーバー側のフレームバッファと同じ画面を即座に再現することができます。

よって、シンクライアントシステムでは、デスクトップ画面の変化を素早く検出し、その画面変化をできるだけ少ないデータ量でクライアントに届けることが重要になります。その実現方法として、２つのタイプに分類しました。一つは、画面変化を描画コマンドや静止画データでクライアントに送信する「（1）画面転送方式」です。もう一つは、デスクトップ全体をテレビのように動画でクライアントに送信する「（2）動画転送方式」です。

図1：シンクライアントの実現方式（クリックで拡大）

画面転送方式では、デスクトップでの画面変化を静止画やコマンドで送ります。よって、動画やアニメーション、グラフィックスなどの画面変化が多く発生するアプリケーションを利用すると、画面変化があるたびに静止画などでクライアントに送信する必要があるため、データ転送量が非常に多くなってしまいます。その結果、ネットワーク通信帯域が十分でなければ、ユーザーの操作応答性能が悪化します。

一方、動画転送方式では、デスクトップ全体を動画で送信します。よって、動画コンテンツなどのリッチコンテンツを閲覧する場合などにスムーズに表示されますが、サーバー側でのデスクトップ全体の動画化処理の負荷が大きく、一般的にはある程度以上の性能を引き出すためには専用ハードウエアが必要となります。

画面データ転送量をどうやって削減するか

そこで新たに開発したのが、仮想デスクトップ高速表示技術「RVEC（レベック）」です。今回、富士通研究所が開発したRVECは、画面の中で更新の多い領域を動画化し、それ以外の画面更新の差分を静止画で送信するというハイブリッド方式を採用しています（図2）。

デスクトップ画面を小さく分割したサブ領域ごとに画面更新量を測定し、数値の高いサブ領域を抽出します。そして、抽出したサブ領域を全て含む長方形（矩形）を生成して動画化領域とし、それ以外の領域は静止画領域として、それぞれに適した方式（RVEC独自のプロトコル）で転送します。図2において、サブ領域ごとの数値は一定時間の間に画面更新があった回数を意味します。数値が大きいほど、その領域の画面更新が多く、画面更新の差分をクライアントに送信するデータ量がより多くなります。

画面更新量は一定時間ごとに測定し、動画化領域と静止画領域を常に調整しているため、画面表示に応じて転送量を最適に抑えることができます。また、動画化領域をデスクトップ画面の一部分に絞り込み、処理を効率化したことでソフトウエアだけで動作可能となり、専用ハードウエアの導入を不要にしました。

図2：RVECでの画面更新領域抽出（クリックで拡大）

富士通研究所の試行環境において、HD（高精細度）動画（1280×720ドット）を再生した時のデータ転送量を、RVECと既存の画面転送方式のリモートデスクトップと比較したところ、約1／10（0.93Mbps）に抑えることができました。

スムーズな操作を実現するためには

RVECは、画面更新が多い領域を抽出して、画面更新の差分を一時的に動画化してクライアントに送信するため、従来よりもデータ転送量を削減できます。それだけでなく、画面更新間隔のフレームレートを維持できるため、操作応答性能も向上できます。

シンクライアントシステムにおいて、データ転送量を比較する場合に、画面更新間隔のフレームレートも同時に考慮する必要があります。画面更新間隔のフレームレートは、画面変化をどのぐらい素早くクライアントに送信するか、に影響します。

通常は、30回/秒程度のフレームレートであれば、シンクライアントシステムを利用しているユーザーが、PCでローカルにアプリケーションを実行させているときの応答性能と比べて、ほぼ遜色なくスムーズな操作が行えます。画面更新間隔のフレームレートを下げれば、それだけでもデータ転送量は少なくなります。しかし、その分、画面更新間隔が長くなりますので、ユーザーにとっては応答性能が悪化し、例えばマウス操作がカクカクした印象を強く感じることになるでしょう。画面更新間隔のフレームレートはできるだけ下げずに、いかにデータ転送量を削減するかが、シンクライアントシステムの重要な技術ポイントになります。

では、ネットワーク通信帯域が制限された環境で、画面更新量が多い動画やグラフィックスを多用するアプリケーションをシンクライアントシステムで利用する場合、データ転送量を削減しつつ、スムーズな応答性能を維持するためにはどうすればいいのでしょうか。確かに、非常に優れた圧縮技術があれば、限りなく少ないデータ量でシンクライアントシステムが利用できることになります。しかし、一般的に、データの圧縮率を高めるためにはその分だけ処理量が増加します。その結果、圧縮処理の時間が応答性能に影響する操作遅延に上乗せされて、データ転送量を削減してもスムーズな操作が実現できるとは限りません。データを圧縮するための一つのアプローチとして、画質を一時的に落とすという考え方があります。

例えば、ユーザーがマウス操作でウィンドウを移動したり、CADで３次元オブジェクトを回転させたりしている間、必ずしもオリジナルの画質でなく、若干画質を落としてもそれほどユーザーが違和感を抱かない、ということが多々あります。ユーザーが操作をしている間は、画質を落として、操作が止まったら画質をもとに戻すことで、実質的にユーザーの体感に影響を及ぼさずに効果的にデータ転送量を削減することができます。

RVECでも、このようなアプローチを採用し、ネットワーク通信帯域の状況に応じて動画および静止画について適切な画質でデータを圧縮する処理を行います。この場合に、動画で送信する領域が多くなるとデータ転送量を削減できますが、動画圧縮の処理時間は領域面積に応じて多くなりますので、操作遅延にも影響します。画面更新があった部分のうち、その画面更新の差分について、どの領域を動画で送信し、どの領域を静止画で送信するかは、データ転送量と画質、さらには処理時間も考慮して決定します。

適切な圧縮方式の選択も大きく影響

RVECでは、デスクトップの画面更新量に応じて、画面更新の差分を動画で送信する領域と静止画で送信する領域に分類します。動画は、例えばMPEGのような方式がありますが、いずれの方式も、前のフレームの画面データを利用して、圧縮処理を行います。よって、その画像一枚のデータのみを用いて圧縮処理をする静止画圧縮方式と比べて、通常は高い圧縮率を実現できます。

一方で、静止画で送信する領域についても、静止画圧縮方式での圧縮率が低ければ、結果的にデータ転送量の総量が多くなる原因となってしまいます。よって、静止画圧縮においても、その圧縮率を高める必要があります。そこで、RVECでは、画面の性質に応じて適切な圧縮方式の選択を行います。

図3：RVECアーキテクチャ（クリックで拡大）

RVECアーキテクチャの概要を図で示します（図3）。圧縮方式の選択は、画面更新領域を抽出し動画で送信すべき領域と静止画で送信すべき領域を分類した後に行います。静止画で送信すべき領域と分類された領域については、さらに画面の性質に応じて静止画圧縮方式を選択します。

特に、CADで用いる設計データを表示する場合に、ワイヤーフレームモデルのように線が非常に多く存在する画面については、富士通研究所が独自に開発したCAD画像圧縮方式を選択します。静止画圧縮方式の選択はデータ転送量の削減に大きく影響します。例えば、デスクトップ背景の草原の画像と、CADなどのワイヤーフレームモデルの画像では、それぞれ画像の性質が大きく異なります。その画像に適した静止画圧縮方式を選択することで、場合によっては静止画データの圧縮率が大きく向上します。

以上が、エンジニアリングクラウドで用いられている独自技術の概要です。なお、CAD画像圧縮技術の詳細については、次回ご説明します。また次々回では、ネットワーク遅延に対する対応などについて説明する予定です。