計算リソースやデータスペースはサーバー側に持たせ、端末は入出力処理に徹する、いわゆる「シンクライアントシステム」はセキュリティや運用管理の問題を改善できるソリューションである。しかし、処理性能やネットワーク帯域の確保に課題が残っている。


 前回記事(「シンクライアントはPCを代替できるか?」)において、シンクライアントの仕組みやその方式について解説した。シンクライアントシステムは、従来のクライアントPCに代わるユーザー向けの端末を提供する。シンクライアントシステムと呼ぶのは、端末とサーバーを組み合わせているからで、計算リソースやデータスペースはサーバーが提供し、端末は入出力機能に徹する。前回同様、以下ではシンクライアントと略記し、通常のPCはリッチクライアントと表記する。

 前回説明した通り、シンクライアントにはさまざまな種類があり、それぞれ長短がある。このため、複数の方式を効果的に組み合わせるハイブリッドタイプが多くのメーカーから推奨されている。シンクライアントを上手に導入することで、セキュリティや運用管理面の問題を大幅に改善できる可能性が高い。しかし、完璧なソリューションは存在しない。シンクライアントにも当然いくつかの課題がある。

リッチクライアント並みの処理性能確保は容易ではない

 シンクライアントの課題の第一は、パフォーマンスである。シンクライアントでリッチクライアント並の処理性能を確保することは非常に困難と言ってよい。

 サーバー上で多数のクライアント環境が動作することから、リッチクライアントに搭載されているCPUと同等の処理性能をサーバー側で確保することはコストの兼ね合いから非常に難しい。このため、CAD/CAMや高度な計算など、処理負荷の高いアプリケーションをシンクライアントで使用するとレスポンスが落ちやすい。

 例えば、シンクライアントの一つである「画面転送方式」はサーバー上のリソースをフルに使って各種のクライアント処理を実行する。画面転送方式は、サーバーでほとんどの処理を済まし、端末に画面情報だけを転送する。画面転送方式の中でも特に「サーバーベース型」や「仮想PC型」は、サーバーが持つ計算リソースを多数のクライアント環境で完全に共有する。サーバーベース型は、Windows Serverのターミナルサービスのような仕組みであり、仮想PC型は、仮想化技術によってサーバー上に端末ごとに独立したPC環境を用意するものだ。

 こうした方式の場合、シンクライアント用サーバーのリソースが、リッチクライアントを使った場合の総リソース(リッチクライアントの処理性能×同時に動かす台数)を上回るくらい十分に確保できるなら、シンクライアントでもリッチクライアントとほぼ同等の処理性能を発揮できる計算になる。だが、実際のシステムでそれだけのサーバーリソースを確保することは容易ではない。

 シンクライアント用サーバーは、サン・マイクロシステムズが提供するソリューション(Sun Ray)の一部を除けば、そのほとんどがx86系サーバーを採用しており、搭載されるCPUはインテルXeonプロセサやAMD Opteronプロセサである。これらのCPUはサーバー向けとはいっても、設計思想としてリッチクライアント向けCPUの延長線上にあるマイクロアーキテクチャーを採用している。したがって純粋な計算処理能力は、リッチクライアント向けCPUの最上位製品と大きく変わらない。

 サーバーは、おおむねデュアルプロセサ(2P)またはクアッドプロセサ(4P)のマルチプロセサシステムを採用しているものの、インテルやAMDの最新4Pをフル活用したとしても、ごく一般的なリッチクライアント相当で20~30台分の計算リソースを確保するのがせいぜいだろう。

 しかも、これは現在考えられる最良のケースであり、多くのサーバーがこれほど高性能なCPU構成をとっているとは限らない。実際にはサーバー自身を動作させるためのリソースが必要であり、さらにはサーバー仮想化ソフトウエアなどによるオーバーヘッドも発生する。このため、シンクライアントの端末あたりの計算リソースは、リッチクライアントよりどうしても少なくなってしまう。

 厳密に言えば、すべてのシンクライアント端末が同時に高負荷な状態になることはまずありえない。仮にあったとしても、大抵の使い方では高負荷な状態は一時的なもので、しかもそれぞれのシンクライアント端末でばらばらに高負荷状態が発生するであろうから、各端末にはそれなりの計算リソースが割り振られることになる。ただし、すでに触れたように、CAD/CAMや計算中心の用途を多くの端末で同時に実行する場合は、サーバー内でリソースの取り合いが発生し、確実にレスポンスの低下が起こる。これに対し、ある程度高速なリッチクライアントのそれぞれに計算させれば、クライアントは自分自身が持つ計算リソースを確実に占有でき、シンクライアントのようなレスポンス低下は発生しない。

 一方、同じ画面転送方式でもブレードPC型なら、クライアント環境それぞれに独立した物理ブレードを割り当てるため、処理性能はそれなりに確保しやすいはずである。ブレードPC型は、シンクライアント1台ごとに1枚のブレード型PCを用意し、それらをブレードサーバーに収容しておくものだ。

 ところが、実際には、ブレードPC型とはいえども、リッチクライアントほどには計算リソースを確保できない。主要なブレードPCベンダーが発売しているブレードPCの仕様をチェックしてみると、その多くは安価なリッチクライアントより低速なCPUを搭載している。これは、適切なコストでブレードPCを提供するために、オフィス業務で必要最低限の計算リソースを確保できる仕様にしたからだ。

 その上、ブレードという限られたスペースの中に、多数のCPUを搭載するため、発熱や消費電力などを最小限に抑えたシステム設計を余儀なくされている。このため、消費電力や発熱の大きな高性能CPUをブレード上に搭載することは技術的に難しい。
 

ネットワークの状況に影響を受けやすい

 シンクライアントの課題の第二は、ネットワークのレスポンスだ。シンクライアントでは、サーバーと端末間の通信が基本にあることから、リッチクライアントと比べるとネットワークを原因としたレスポンス低下が大なり小なり発生してしまう。特にサーバーとシンクライアント端末間で十分なネットワーク帯域幅を確保できない場合や、両者の距離が物理的に離れていて遅延が起こりやすい環境下では、操作時のレスポンスが低下しやすい。

 サーバーから画面イメージを常に転送する画面転送方式においては、慢性的にトラフィックが発生する。オフィス・アプリケーションをメインに使う多くのオフィス関連業務では、それほど大きなトラフィックは発生しないが、画面の書き換えが頻繁に発生するケースではトラフィックが増える傾向にある。動画の再生やCAD/CAMで高精細の図面や3Dグラフィックスを頻繁に動かすような操作が該当する。

 一方、ネットワークブート方式のシンクライアントは、サーバー上にOSイメージを持ち、ネットワーク経由でそのOSイメージを端末にロードするため、膨大なトラフィックが発生する。ネットワークの帯域幅がかなり要求されるので、拠点に置く端末やモバイル端末には向かない。ただし、OSをいったん起動してしまえば、それ以降のトラフィックはリッチクライアントと同程度になる。