[計画フェーズの落とし穴]VDIならアプリのことは気にしなくてよい!?(1)

第3回・第4回で「計画の落とし穴」の1つであるサイジングに関する落とし穴について解説した。そこで、今回から3回にわたり、同じく「計画の落とし穴」の1つであるアプリケーションの検討について解説する。

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

設計・構築の局面においては、サーバやストレージ、ネットワークなどのインフラに比べてやや軽視されがちな傾向があるが、実際に端末を利用して業務を行うエンドユーザーにとっては、むしろこちらのほうが本題である。業務アプリケーションのために端末やOS、各種インフラが存在するのであって、逆ではないからだ。

このため、少なくとも企画段階においては、既存(または近々に移行が予定されている)業務アプリケーションが問題なく動作するかどうかが、デスクトップ仮想化の中心的な検討事項となる。

この時しばしば交わされる議論に、「SBC(Server Based Computing)はアプリの互換性に課題があり、VDI(Virtual Desktop Infrastructure)ではそれがない。したがって、VDIのほうが、ことアプリに関して言えばスムーズな移行が期待できる」というものがある。

これは一面では正しい。OS部分を共有し、セッション共有という特殊な形でデスクトップやアプリケーションの仮想化を提供するSBCと異なり、VDIは1OSにつき1ユーザーが割り当てられるという点で、既存の物理端末と本質的には同じアプローチである。OSも、サーバOSを用いるSBCに対して、大半の業務アプリが想定しているデスクトップOSであり、その点でも連続性を保ちやすい(OSのバージョンアップを伴う場合は別であるが)。

だが、問題はそう単純ではない。アプリケーションを動作させる上ではさまざまな技術条件が関与しており、実装に伴うわずかなディテールの違いで、今まで動作していたアプリケーションがそれまでとは同じように動作しなくなる。SBCとVDIの違いは、これらの複数の条件の1つでしかない。

企画やセールストークの段階であればともかく、実証検証、設計、構築とプロジェクトが深まっていくにつれて、このディテールが大きな壁となって立ちはだかってくる。そこで、本稿ではアプリケーションの検討に際して、陥りがちな落とし穴について説明しよう。

何を変えて、何を変えないのか

物理PC端末から仮想デスクトップの環境に移行する場合、何も変えずにそのまま移行するという考え方もある。しかし、ITガバナンスの強化や運用の効率化､コストの削減を図るため、仮想デスクトップの導入を機に、アプリケーションに対して影響のある以下の変更が加えられることがほとんどだ。ここでは、それぞれについて検討したい。

1. SBC or VDI
2. プール型or専有型
3. 移動プロファイル or ローカルプロファイル
4. 標準アプリ or 個別アプリ

(1)SBC or VDI

SBCを採用する場合、VDIと比較してライセンスなどのコスト上のメリットが大きい。しかし、最初に述べた通り、SBCでは以下に挙げるようなタイプのアプリが課題となる。

サーバOSにインストールできないもの

まず、インストーラーがそもそもサーバOSを識別して除外しているアプリケーションがある。入れることができない以上、動作検証も何もなく、ある意味最もわかりやすいNGパターンである。

サーバOSまたはRDSで動作保証がされていないもの

技術的には動作するが、メーカーが動作保証やサポートを提供していないパターンである。内製のアプリケーションでそもそも外部のサポートが必要ない場合や、交渉次第で個別対応してもらえる場合もある(VDIや物理端末で再現する場合はサポートする、など)ので、必ずしも深刻な問題とはならないこともある。

サーバOSのインストールできない、ないし動作保証もされていない場合は、サーバOSをVDIとして単一ユーザーで利用する「サーバVDI」の構成でも利用ができない。サーバVDIはSPLAライセンスの制限により、クライアントOSの利用が認められていないパブリッククラウドでよく利用されるので注意が必要だ。

RDS上での動作に問題を抱えているもの

いわゆるマルチユーザーを想定していない作りのアプリケーションがこれに当たる。一般に、「SBCはVDIよりアプリを動かすのが困難」という場合、このパターンを指す。これにより、1人目のユーザーが使っている分には何ら問題ないが、2人目が入った途端にクラッシュしたり、データが上書きされたりといったことが起こる。

これらは一例ではあるが、確かにVDIでは遭遇しないタイプの「ディテール」である。SBCを採用した場合、適切な回避方法や代替手段を持っていない場合、こうした局面で困難を抱えることになるのは事実であり、過去にRDSなどのSBCを実装、運用していた企業がVDIに乗り換える時は、大なり小なりこうした過去の失敗体験が関係している。

次回は、VDIであってもアプリケーションの動作について確認が必要になる残りの項目について検討する。

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

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

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