間違いだらけのネットワーク作り(102) 99/11/13
「WAN上のC/Sシステム」

 CWCのサービスについては皆さんの関心が高かったようです。そこで12月4日(土)の情報化研究会はCWCの方から「CWCサービスの技術的特徴と用途」、NTTの方から「NTTの次世代IPネットワーク・サービス」について講演していただくことにしました。「次世代IPネットワーク特集」といった研究会になりました。これで日本テレコムの人でも参加してくれれば言うことはないのですが。PRISM実験に参加している企業の方は常連なので出席されることを期待しています。講師・時間・場所等は会員ページにありますので見てください。出席者名簿も掲載します。

 さて、今回の話題は先週とはまるで趣が変わってWAN上のC/S(クライアント・サーバ)システムに必要な帯域計算をどうするか、です。私が仕事として行っているネットワーク設計でもC/Sシステムのレスポンス目標をエンドユーザの方と決め、トラヒックを予測し、目標を満たす帯域設計をするのは様々な困難があって大変さを痛感しています。ところが私のひいきにしている米のホームページでえらく単純な帯域見積もり方法を示した記事を見つけました。面白いのでポイントを紹介します。*に続くのは私のコメントです。

○C/Sでネットワーク設計に失敗しないヒケツ
@先ず、WAN上でC/Sがどんな振る舞いをするか=どんなパケットを飛ばすか把握すること。
 *これが意外とC/Sを開発しているSEさえ分かってないことが多いのです。いわんやネットワーク技術者をや。アプリケーションからは見えない制御用のデータをミドルウェアやOSが飛ばしていることがあります。 
A性能を最適化するために選択可能な方式を検討すること。
B開発・プロトタイプ・移行でWAN ART(Application Readines Testing)をきちんとすること。

○C/Sのアーキテクチャ
@2層C/S  サーバはデータベース、クライアントにアプリとプレゼンテーションを持つ。サーバとクライアント間で多数のパケットが飛ぶためWANには不適。
A3層C/S  現在の主流。SAP R3、PeopleSoft等多くのERPが採用。セントラルサイトにはLAN上にデータベース・サーバとアプリケーション・サーバがあり、WANを介してプレゼンテーションに特化したクライアントがリモートにある。スケーラブルであること、クライアントとサーバ間のパケットを大幅に減らせるのが特徴。ほとんどレガシーなIBM3270システムと同様、クライアントからはトランザクションの入力パケットが飛び、サーバからは処理結果が送信されるシンプルなシーケンスになる。
Bthin-client  3層C/Sから発展。クライアントにはOSとブラウザしかのせない。クライアントのコストが80%節減できるという試算がある。CitrixSystemsのWinnFrame/MetaFrameのようなリモート・プレゼンテーション、HTML、オラクルのNetworkComputingArchtecture(NCA)、の3つのアプローチがある。

○帯域の算出方法
 多くのパケットがサーバ・クライアント間でやりとりされるping-pongトランザクションでの見積もり方法は次のとおり。
N=対象ロケーションでの同時利用ユーザ数
T=userーthink−time(考えている時間)
K=トランザクションあたりのパケット数(上り、下り)
M=パケットあたりのバイト数(上り、下り)
P=片方向のネットワーク遅延時間
 これらのパラメータが確定すると片方向の帯域は次式で求められる。
帯域=8×N×K×M/(K×P+T)
 上り下りについて算出し、大きい方がこのロケーションの帯域となる。

 *分子はトランザクションで伝送すべきデータ量。分母はユーザがトランザクションとトランザクションの間で何もせず考えている時間。Tは1〜2分とのこと。考えている時間やネットワーク内の遅延(P)が大きいいほど帯域は少なくて済むことになります。単純で平和な方法ですね。トランザクションを入力してから、出力がユーザに届くまでのレスポンスタイムを基準に考えるのではなく、「考えている間に結果がとどけばいいよ。ネットワーク内の遅延はしようがないね。」という感じ。

 *こんな方法で設計が出来るとは思いませんが、何も考えずにネットワークを構築しC/SをWANにのせた後でレスポンスの悪さにビックリするよりは数段ましです。
C/Sでのレスポンス向上のためにはネットワークの帯域を大きくするより、余分な制御パケットが飛ばないよう適切なC/Sのアーキテクチャやミドルウェアを選択することの方が重要です。つまり、上記ヒケツの第一、C/Sの振る舞いをちゃんとすること、です。
 
 

ホームページへ