このページの本文へ

前へ 1 2 次へ

デスクトップ仮想化のすべて 第10回

VDIをはじめとする実現方式を基礎から解説!

デスクトップ仮想化を支える技術

2010年09月30日 06時00分更新

文● 渡邉利和

  • この記事をはてなブックマークに追加
  • 本文印刷

画面転送のさらなる工夫

 VDIで使われる画面転送技術では、一般的なアプリケーションの画面書き換えの状況に合わせた最適化を行なうことで転送量を削減できる。自然画像の動画配信であればともかく、一般的なPCアプリケーションの実行では、画面全体が常時書き換えられるといった事態は起こりにくい。むしろ、基本的にはほぼ全体が静止画像であり、ごく一部分だけが変更される、という方が実態に近い。そのため、画面転送の際には画面上のどこがどう変更されたかを正確に判断し、変更箇所だけを通知すれば最小限の通信量で済ませることが可能だ。

図5 変更部分だけを通知することで通信量を削減できる

 また、変更箇所を転送する際にも、基本的にはグラフィックスイメージデータであるため、データ圧縮を併用することで転送データ量を削減する手法も有効だ。WindowsのようなGUI環境を前提にするなら、アイコンやメニュー、ボタンなどのグラフィックオブジェクトが繰り返し表示されることになるので、こうしたデータに関してはキャッシュを併用することが有効となる。

 画面転送技術を利用してアプリケーションを実行する場合、たとえばユーザーがマウスを動かしても、いつものように直接マウスカーソルが動くわけではない。ユーザーがどの方向にどの程度の量マウスを移動したのかを読み取り、そのデータをアプリケーショが実行されているサーバー側に転送し、まずサーバー側でユーザーの指示通りにマウスカーソルを移動する。そして、マウスカーソルが移動した結果生じた画面表示の変化をサーバー側で読み取り、その情報をクライアント側に送り、クライアントの画面を書き換える、というのが基本的な処理となる。

 つまり、ユーザーがどのような操作を行なったとしても、その結果がユーザーの目の前の画面に反映されるためには必ずクライアントとサーバーの間で往復する通信が発生することになる。このため、通信量を削減することで遅延を減少させ、ユーザーに自然な操作感を提供することがVDIの技術では重要となる。

より一層の高速化

 画面転送技術を活用したVDIシステムでは、一般的なオフィスアプリケーションなどではおおむね充分なパフォーマンスを達成できるが、不向きとされる用途も存在している。

 基本的にはビジネス用途のシステムなので、動きの激しいゲームソフトウェアなどはそもそも対象外だ。加えて、基本的にはグラフィックスを多用するアプリケーションではデータ転送量が増大してしまうため、レスポンスが低下する可能性がある。業務用途としては、CADやCAMなどのソフトウェアが該当する。

 同様に、ビデオストリーミングなどは画面サイズによっては苦しくなってくることもあるだろう。また、ハードウェアアクセラレーションを前提としている3Dグラフィックス処理なども、画面転送技術とはあまり相性がよくないアプリケーションだといえる。

 こうした、グラフィックス処理中心のアプリケーションのパフォーマンスの改善策もいくつか工夫されていている。

 代表的な例としては、サーバー側のアプリケーションが発行した描画命令を横取りし、それを転送するというものだ。アプリケーション自体の実装にも依存するが、高度なグラフィックスを活用するアプリケーションでは、OSやプラットフォーム側で用意したグラフィックス描画のための高レベルなAPIを利用していることが多い。こうしたAPIコールをトラップしてそのままクライアントに転送し、クライアント側でこのAPIコールを実行することで、負荷の重いグラフィック命令の処理をクライアント側にオフロードすることが可能になる。

 また、描画結果の画面イメージと、その結果を得るための描画命令とでは、転送されるデータ量には大幅な差があり、転送するデータ量の削減にも貢献する。こうした手法を活用すれば、クライアント側に実装されたハードウェアによるグラフィックスアクセラレータの機能を活用できるなど、高速化手法としてメリットは多い。ただし、環境依存性が高いという問題もある。

 少なくとも、アプリケーションが利用するグラフィックスAPIがサーバー/クライアント双方に実装されている必要があるだろう。APIのバージョンの差異なども問題になるだろうし、場合によってはサーバー側/クライアント側双方のOSのバージョンも特定の組み合わせに制約される可能性も考えられる。

 サーバーやクライアントの環境に依存せずにアプリケーションを利用できる、という点はVDIシステムの大きなメリットとなっている。たとえば、最新バージョンのクライアントOSでは利用できない古いアプリケーションをサーバー側で実行し、その画面だけを最新バージョンのクライアントOS上で表示する、といった利用が可能になる。

 こうした環境非依存性が実現できるのは、物理環境を仮想化しているからに他ならない。こうした仮想化のアプローチと、ハードウェアの機能を活用するという方向性とは矛盾していることになる。画面転送技術の高速化にはこの矛盾がつきまとうことになるが、プロトコルの高効率化やデータ圧縮率の向上など、プラットフォーム非依存性を損なわない範囲での高速化の努力も続けられているのも確かである。

前へ 1 2 次へ

カテゴリートップへ

この連載の記事