今回も前回に続き、「計画の落とし穴」の1つであるアプリケーションの検討について解説する。

デスクトップやアプリケーションの仮想化を導入する時、必ず検討する必要があるテーマの1つに「既存業務アプリケーションの移行」がある。

これまで、仮想デスクトップの導入に際してアプリケーションに対して影響のある変更として、「SBC or VDI」「プール型or専有型」「移動プロファイル or ローカルプロファイル」を紹介したが、このトピックでの最終回となる今回は「標準アプリ or 個別アプリ」と「専有型VDIでも動かないアプリケーション」について説明しよう。

標準アプリ or 個別アプリ

これまでの観点とは少し毛色が違うが、導入を行うソフトに関するガバナンスの変更に伴う検討も注目する必要がある。物理端末を使用して各ユーザーが自由にソフトのインストールなどを行える環境の場合、デスクトップ仮想化に伴って「標準アプリ」を定めてマスターを共通化した場合に、個別に入れているアプリケーションが問題になる。

インベントリ収集を行うためのツールなどを用いてアセスメントを行うと、相当量の個別アプリケーションが検出されることが多い。マスターに導入する「標準アプリ」を定めるためには何千というアプリの仕分け、ライセンスの考慮、持続可能な受け入れとリリースのプロセス設計など、困難なタスクが多く待ち構えている。

「個別アプリ」として分類されたアプリケーションは、導入や検証についてユーザーとの責任分解点を定める必要がある。アプリケーションを配信するためにApp-VやThinAppなどの技術を利用するとしても、パッケージ化や検証が必要になるためだ。IT部門が最低限必要な設定のみを投入した作り置きのマシンを用意してある程度自由に利用させたり、FATクライアントを残置してしまったりするのも1つの手だ。

専有型VDIでも動かないアプリケーション

プール型を選択することは諦め、ローカルプロファイルの専有型VDIとした場合も問題が発生する可能性はある。以下に、専有型VDIでもアプリの動作に困難が発生する代表例を挙げていく。

管理者権限が必要なもの

物理端末を前提としたアプリケーション、特に古き良き時代のレガシーアプリケーションの中には、利用者が管理者権限を持っていることを前提にしているものが意外に多い。特に、勝手のわかった自社環境を対象として作られる内製アプリケーションにこの傾向が強い。本質的に雑居方式であるSBC(サーバーベースコンピューティング)では当然だが、VDIでも、仮想化を機に管理者権限を渡さない運用に切り替えることは多く、こうした仕様のアプリケーションがあると難儀することになる。

高負荷を発生するもの

CPUやネットワークに強い負荷を与える、または、これらの変動に敏感なクライアント・アプリケーションがある。コンパイラーは代表的な例だが、ほかにも一括印刷を伴うアプリケーション、動画や音声を取り扱うアプリケーションなどが該当する。

SBCのほうが同一OSを共有している分、他のユーザーが(または、他のユーザーの)影響を受けやすいが、サーバーリソースやストレージ、ネットワークを共有している点ではSBCもVDIも変わりがないので、VDIだから大丈夫ということにはやはりならない。

ここでは代表的なものを挙げたが、実際の現場ではさらに多くの「例外的事項」が発生する。むしろ、すんなり動くアプリケーションのほうが少ないのではないかと思うくらいだ。

どのように対処すべきか

さて、3回にわたり、計画フェーズの落とし穴として、アプリケーションの検討について説明してきたが、これらの課題にどう対処すればよいのだろうか。まず考慮すべきは、VDIである場合でもスケジュール上で検証を行うための期間を含めることである。

幸いなことに、SBCと同様に、多くの課題に対しては取り得る対策がある。SBC上での回避方法とまったく同じ逃げ方が適用できる場合も少なくない。例えば、シンボリックリンクを用いる方法や、ログオンスクリプトを利用する方法などだ。プロジェクトメンバー内にこうした知見があれば、多くの課題はクリアできる。最後の手段として「物理端末残置」や「個人専有型VDI」などの手段を持っておくことも有効だ。

アプリケーションの互換性問題は、結局のところ、企画段階で、移行対象となるアプリケーションの特性をあらかじめ特定・分類・検証し、どのようなソリューションが適用できるかを把握しておくことに尽きる。手間はかかるが、プロジェクトが進み、納期が見えてきた段階で壁に突き当たるよりはずっとましである。

また、動かないアプリケーションがあることも想定して、回避方法を策定しておくことも重要だ。前述の通り、こうした場合の回避方法は、SBCのそれと重なることが多い。過去にSBCを実装しているなら、その時のプロジェクトメンバーに意見を聞いておくのもいいだろう。

また、こうした互換性検証を進めていく過程で、VDIが必ずしも万病に効く特効薬というわけではないことに気づくことができるのも重要なポイントだ。1OS・1ユーザーというアーキテクチャは、コストが高くつきがちだ。

エンドユーザーの業務形態やリテラシー、利用するアプリケーションセットの特徴などを勘案して、VDIとSBCを適材適所で使い分けていくことは費用圧縮の上で有効な手段であるし、そこに、さらに1つ2つのソリューション(例えば、アプリケーションのカプセル化)を用意しておけば、設計・構築過程で遭遇するアプリケーションの技術課題に対して、受けを広くとっておけるだろう。

プロジェクトに困難はつきものであるが、ことアプリケーションに関しては、(SBCだろうがVDIだろうが)「動かないかもしれない」ことを前提に、周到の上にも周到な準備をしておくことをお勧めしたい。冒頭に述べたように、端末ソリューションにおいて重要なのはつまるところ、アプリケーションなのだ。

次回は、仮想アプリケーションおよび仮想デスクトップ環境設計時に考慮すべきGPUの必要性について解説する。

峰田 健一(みねた けんいち)

シトリックス・システムズ・ジャパン(株)
コンサルティングサービス部 プリンシパルコンサルタント

サーバ仮想化分野のエンジニアを経て、シトリックス・システムズ・ジャパンに入社。
主に大規模顧客のデスクトップ・アプリケーション仮想化のコンサルティングに従事している。