米Citrix SystemsのMetaFrameなどのWindows端末システムを利用する企業が増えてきた。既存のC/Sシステムから移行するケースが多い。その狙いは,アプリケーションの集中化やWAN環境でのレスポンス改善だ。事例を基に,費用対効果と導入時のチェック・ポイントを解説する。

 「Windows NT Server 4.0, Terminal Server Edition」(以下NT 4.0 TSE)や米Citrix Systemsの「MetaFrame」など,鳴り物入りで登場したWindows端末が国内で利用され始めてから2年半が経った。ここにきてようやく,約30台のPCサーバーを利用する大規模なシステムが稼働するなど,実運用に入った企業が増えてきた。その多くは既存C/Sシステムの移行である。WAN*環境でのレスポンスの改善や,集中化によるアプリケーション配布コストの削減などで効果を上げている。

複数ユーザー版リモコン・ソフト

図1●Windows端末の仕組み
クライアント上でキーボードやマウスを操作したイベントをサーバーに送信する。その内容からサーバー上でアプリケーションが動作して,その結果が表示される画面データだけをクライアントに返信する。Windows端末を実現するソフトには,Windows NT4.0 TSE,Windows 2000標準添付の機能,およびMetaFrameがある。ソフトの組み合わせによっては動的負荷分散が可能など,企業情報システムのプラットフォームとして利用できる機能と性能を備えている
 Windows端末を一言で言えば,「マルチユーザー版リモートコントロール(リモコン)・ソフト」である(図1[拡大表示])。クライアントは画面の表示と,キーボードやマウスの操作だけを担う。アプリケーションを実行するのはサーバーで,クライアントから受信した操作によって生じた画面の変更分だけをクライアントに返信する。

 リモコン・ソフトと同様の仕組みだが,違いは複数クライアントからの同時利用を前提にしていることだ。サーバーとして利用できるソフトは,米MicrosoftのNT 4.0 TSEとWindows 2000。Windows 2000では「ターミナル サービス」の名前でWindows端末機能を提供している。これらのOSにMetaFrameを組み合わせると,動的負荷分散や通信データの圧縮といった機能強化ができる(図1の右下)。

 これら製品の組み合わせ方による機能差は,主に3つある。(1)通信データの圧縮,(2)動的負荷分散,(3)クライアントに接続したデバイスの利用――である。NT 4.0 TSEは通信データを圧縮できない。また,サーバーの動的負荷分散機能も,NT 4.0 TSE単体では利用できない。さらにクライアントと接続したプリンタなどのデバイスをサーバー上で動作するプログラムから利用することも,NT 4.0 TSEではできない。Windows 2000はプリンタのみ利用でき,Meta Frameはほぼすべてを利用できる。

 このような機能差から,多くの業務アプリケーションではNT 4.0 TSE単体のWindows端末は利用されないと見られる。NTを使った既存C/Sシステムからの移行では,従来クライアントで稼働していたアプケーションをサーバーOSに対応させる必要があることから,NT 4.0 TSEとMetaFrameの組み合わせが有力視される。

1000台に展開,3年で元を取る

 次は費用対効果について見てみよう。効果は大きく2つある。アプリケーション集中化でソフト配布が不要になるなどによる管理コストの削減と,トラフィックを大量に流すC/Sシステムの性能向上である。

 住友商事は2000年10月,約1000台のクライアントが利用していた21種類のC/Sシステムを,約1億3000万円の費用をかけてWindows端末化した。内訳は,MetaFrame用PCサーバー29台とソフトが8500万円,システムのインテグレーション費用が2100万円,MetaFrameへの移行に必要なシステムの修正が2600万円である。

 移行のきっかけはサーバーの設置場所が変わり,クライアントとサーバー間の通信が1.5Mビット/秒(bps)のWANになったことだった。トラフィックが多いアプリケーションで性能低下の恐れがあったため,トラフィック量が少なくて済むWindows端末を採用した。また,運用コストの削減や,バージョン・アップの度に発生する対応作業の解消も,効果として狙った。MetaFrameに移行しないプランと比較し,クライアントの運用コストだけでも3年で今回の投資とほぼ同額の出費と見積もり,導入を決断した。

 アルプス技研は2000年7月,顧客データ分析ソフト「Broadbase」の導入に伴い,MetaFrameを採用した。クライアントは約40台で,投資金額はサーバー代を含めて約800万円である。22拠点を結ぶWANをまたぐC/Sアプリケーションの性能向上手段として利用する。Broadbaseはあらかじめデータをダウンロードする仕組みで,この分析対象となる約2Mバイトのデータを64KbpsのWANを介してダウンロードすると,15分ほどかかってしまった。

 そこでMetaFrameを試したところ,「10秒程度で実行できた」(アルプス技研 技術営業部 システム管理課 戸田正己氏)。コストは性能向上の手段として「妥当な金額」(同氏)という。同社では2000年11月にも,同じくWANがボトルネックで性能の問題を抱えていたC/Sの販売管理システムをMetaFrameに移行した。現在はさらに他のアプリケーションのMetaFrame化を進めようとしている。

サイジング,アプリ対応,印刷に注意

 このような成果を上げているWindows端末だが,導入時に注意すべき点が主に3つある。(1)サーバーのサイジング,(2)アプリケーションの対応,(3)ネットワークと印刷――である。

 サーバーのサイジングはアプリケーション1台のサーバーに収容する同時ユーザー数と動作させるアプリケーションの負荷がパラメータとなる。目安はPentium IIIを2つ搭載したPCサーバーで,同時20~40ユーザー程度。しかし,安易なサーバー選択は危険である。サーバーの性能が不足すると全ユーザーのレスポンスが低下する。事前の検証に加えて,運用中の負荷上昇に備えて余裕を持たせておくことも必要だろう。

 住友商事では,あえて小型のサーバーを多数用意した。これにより,性能の調整を容易にした(図2[拡大表示])。MetaFrameが備える動的負荷分散機能を利用して,複数台のNECの小型PCサーバー「Express5800/120」にアプリケーションを振り分けている。1台の大型サーバーにリソースを集中するよりも,性能の調整がしやすい。かつ,「性能が足りない場合でもサーバーを追加すればよい」(住商情報システム ネットワーク・ソリューション事業部 ネットワーク・マネジメント部 ITサポート第二課 岩野伸昭氏)との考えだ。同時ユーザー数が50を超えるなど,ある程度規模が大きいケースでは有用な手法と言える。

INIファイルはそのまま使えない

 NT/2000で動作するアプリケーションは,基本的にはWindows端末環境でそのまま動作するが,注意すべきポイントもある。複数のユーザーがサーバー上で同じアプリケーションを同時に動作させるため,例えばINIファイル*など,アプリケーションが上書きするファイルはそのまま使えない。例えばc:\Program Files\my_appli\my_appli.iniをすべてのプログラムが参照すると,予期せぬ書き換えや,排他処理により書き込めないエラーが発生し,対策が必要になる(図3[拡大表示])。住友商事でアプリケーションの修正作業が必要だった点は,INIファイルのほか,C/SアプリケーションをWindows95からNT 4.0へ移行する作業もあった*1

図2●「スケール・アウト」でサーバーの性能を調整する
住友商事では,同社の既存C/Sシステムのサーバー移設に伴い,MetaFrame化した。1つの大きなサーバーを導入する形(スケール・イン)ではなく,小型のサーバーを大量に導入する形(スケール・アウト)にすることで,アプリケーションの性能に対する柔軟性を持たせた
 
図3●複数起動するアプリが同一のファイルを参照させないようにする
MetaFrame環境下では,複数のユーザーのアプリケーションが1つのマシンで同時に動作することになる。例えばあるアプリケーション内でc:\Program Files\my_appli\my_appli.iniをINIファイルとして常に利用するようにしてある場合,複数起動したときに他のユーザーが書き込めないなどの問題が出る。Windows NT 4.0のユーザー・プロファイルなどを利用して,ユーザーごとに利用するディレクトリを分けるようにする必要がある

 INIファイル問題の対策方法の一つは,ユーザーごとにディレクトリを分けること。ただし動的負荷分散を利用する場合は,ユーザーがどのサーバーにログオンした場合でも同じディレクトリを参照できるように考慮する必要がある。アルプス技研では,NTの移動プロファイル*を利用することで,ユーザーごとにアクセスするディレクトリを分けた。

大トラフィックが発生する大量印刷

 必要なネットワークの帯域も,一般的な業務アプリケーションではMetaFrameの場合で8K~20Kbpsあれば軽快に動作するようだ*2。先のアルプス技研や,部品設計システムにMetaFrameを利用する昭和電線電纜では64Kbpsの回線で接続した拠点で,数人のユーザーが利用できている。

 ただし短時間に大量のトラフィックが発生する印刷だけは別である(図4[拡大表示])。MetaFrameとWindows 2000のターミナル サービスでは圧縮が効くものの,A4数十枚といった大量印刷では大量のトラフィックがバースト的に発生するため,ネットワークがボトルネックとなる。他のトラフィックに影響を与えるケースもあるだろう。

 対策は,(1)ネットワークを高速化する,(2)サーバー側で印刷用ファイルを生成し,クライアントで印刷する,(3)ツールを利用して帯域を稼ぐ――である。(1)は最も簡単だがコストが高い。(2)は印刷データをクライアントに直接送信せずに,pdfなどのドキュメント形式でいったん保存し,クライアントに転送して印刷する方法である。昭和電線電纜では,出力する仕様書などの書類をMicrosoft WordのDOC形式で保存し,クライアントからはファイル共有で取り出して印刷している。ファイル・サイズは数十Kバイトである。(3)のツールは,現在2つの製品がある(表1[拡大表示])。いずれも印刷データの圧縮に特化して,圧縮率を稼ぎ,印刷時間の短縮を実現している。ThinPrintは帯域制御の機能も備える。

(矢崎 茂明=yazaki@nikkeibp.co.jp)

図4●印刷で大量のトラフィックが発生する
通常アプリケーションを利用するときのトラフィックは1ユーザー当たり8K~20Kbps(ビット/秒)程度の帯域があればさばき切れるが,印刷時にはバースト的なトラフィックが大量に発生し,ネットワークがボトルネックになる。アプリケーションによってはネットワークの高速化などの対策が必要になる
 
表1●Windows端末環境での主なプリント・ツール