前回までは、仮想デスクトップやアプリケーションの歴史を振り返り、できることの増加に伴ってユースケースが多様化してきたことを解説してきた。 仮想デスクトップやアプリケーションのユースケースが多様化することによって、これまで常識とされていたようなことがそうでなくなったり、検討が必要な内容が増えたり、などの変化が生じている。今回からの記事では、「計画の落とし穴」と「設計・構築の落とし穴」の2つに分けて解説してゆく。

ベンダーが提案した機器構成は必ず検討すべし

仮想デスクトップの環境を構築するためのRFPに対し、ベンダー各社は想定した集約率などに基づきハードウェアにより構成を組んで提案を行う。しかし、その構成を見直すことなく機器を買ってしまうと、落とし穴が待っている。

仮想デスクトップの案件においては、ユーザーのユースケースにより、想定されるリソースとそれに合わせて集約率が変わるため、提案時の想定の構成を検討せずにそのまま購入するべきではない。

初期の事例では、限られたユースケースに特化した実装が多かったが、昨今の全社導入などの事例ではユースケースがユーザーグループに応じて大きく異なることが想定される。

また、各デスクトップで使用される業務アプリケーションも顧客によりまちまちで、同じような業務を行っている競合であっても、利用するアプリケーションが異なれば負荷量も変わってくる。そのため、同業他社のデータは参考にはなるものの、確認を行うフェーズが必要になる。

しかし、集約率や構成の見直しは全体のコストに大きく影響するので機器発注前にもある程度検討を進めておきたい。それには、いくつかのポイントで構成を見直すことができるようにスケジュールを検討することが重要だ。

モデルとなるスケジュール

仮想デスクトップのプロジェクトでモデルとなるフェーズごとの工程を以下に示す。

提案前・アセスメントフェーズ

要件定義・設計フェーズ

構築・テストフェーズ

移行フェーズ

これらのうち、各フェーズの黄色のポイントで集約率や構成の見直しをかけることが考えられる。以下、各フェーズについて検討する。

[アセスメントフェーズ]RFP前の検討

RFPを出す前に、既存端末のアセスメントや事前検討のフェーズを設けることで、想定する集約率や構成を算出することができる。既存端末のアセスメントでは端末にツールを入れ、同時利用数や、負荷の高い業務アプリケーションがないか、負荷が高い場合にどのリソースにネックがあるかなどの検討を行う。

ツールを使うことで、IT部門が想定していないようなアプリケーションが検出されたり、特定アプリケーションの負荷が非常に高かったり、といったリスクを先に発見することができる。ただし、大量にツールを導入するとそれなりに準備期間が必要となるため、アプリケーションのインストールが比較的統制が取れているような組織は、ツールを入れずに個別にリソースを確認してもよい。

また、負荷の高いビデオ会議や動画再生などの要件が想定される場合はこのタイミングで含める。過去案件の実績をもとに提案するベンダーに対して、このような要件を示しておくことで事前に検討を促すことができるためだ。

計画段階である程度移行のロードマップを示しておくことも重要である。パイロット移行の期間を長めに取り、クリアした後に本格移行とすることでパイロット移行時に性能問題が出た際の対処が可能となるからだ。

これらの検討により、RFPの時点で、ある程度想定する同時利用数や集約率をベンダーに示すことで、その後の変動の影響を減らすことができる。

[設計フェーズ]機器発注前の検討

機器のリードタイムを考慮すると、構築時に機器をそろえるために、基本設計の完了前に発注が必要なことがよくある。

仮想デスクトップのプロジェクトは決定が必要な項目が多岐にわたるため、どうしても細かい内容に議論が進んでしまうことが多い。しかし、要件定義の中でユースケースを確認しながら進めることで、基本設計以降のフェーズでのぶれを防ぐことができる。

注意したいユースケースとしては、先に挙げたビデオ会議や動画再生に加えて、印刷がある。印刷において、FAT PCの場合はプリンタへのアクセスがオフィス内で完結するが、仮想デスクトップの場合は「仮想PC→WAN→アクセス元の端末→プリンタ」といった経路になり、WANを経由してしまう。そのため、回線増強やトラフィックの優先制御、帯域圧縮装置などの対策が必要になる可能性がある。

また、非機能要件の検討も重要となる。単一障害点を作らないことは前提だが、管理コンポーネントの中でログイン時に必要なコンポーネントで障害が起きた時は、配下にいる仮想デスクトップすべてにアクセスできないことになる。そのため、二重障害を許容する場合も、冗長性が損なわれている状態が業務上、どこまで許容可能かを意識する必要がある。

例えば、ある二重化されたコンポーネントに障害が生じ、単一の構成となった場合、再び冗長な構成に戻るまでに1週間かかることを許容するかどうかだ。

各社で呼び名は異なるが、モジュラー型ないしポッド型と呼ばれる構成を取り、影響範囲を管理コンポーネントの管理対象にとどめる構成をとることも重要だ。以下、モジュラー型の構成例を示す。

モジュラー型の構成は、拡張単位をあらかじめ定め、同じ構成と設定で順次拡張していく構成だ。上図では管理コンポーネントは4000台ごとに増設しているので、管理コンポーネントの全障害時も影響範囲は4000台にとどまることになる。

さて、テストフェーズと移行フェーズにおける、機器構成の検討については、次回に説明することにしたい。

峰田 健一（みねた けんいち）

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

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