間違いだらけのネットワーク作り(92) 99/09/04
「OLTP over FRの留意点」
 
 京都研究会の写真が出来あがり、よく遊んだもんだなあと思いつつ見ていると会に参加したNさんからメールが届きました。

以下、引用。
  ”受注したユーザを方式設計(インフラ)を行うため訪問すると、ネットワークのWANはFRが多くなってきています。 ISDNから昨年または今年FRに切り替えたユーザが多いです。定額制を売り物にキャリアが攻勢をかけているようです。 以前のC/SシステムはLANを基盤としており、WANを考慮していないのが多いです。”
  ”そのため、WAN接続をした場合、クライアントとサーバ間(WAN接続)でSQLが飛び交い、FR遅延のため、レスポンスが LANに比べ、非常に悪くなります。 改善案として、SQL通信回数を減らすため、サーバにアプリケーション処理をつくる方法があります。 新規に作成するプログラムでは,WANを考慮するため問題ないのですが、既存のプログラムをWAN接続するには 改造が必要となり大変です。 ユーザにお願いして、専用線にしてもらった例もあります。 FR時のレスポンス調査を事前に行い、ユーザに理解してもらうよう努力しています。"

以下、コメント。
 CSS(クライアント・サーバ・システム)のOLTP(Online Transaction Processing)をWAN上で構築するときにはレスポンスの考慮が不可欠です。Nさんが指摘しているデータベース操作のコマンドであるSQLの他にもアプリケーションには見えない制御データがサーバとクライアント間でやりとりされるからです。LAN上でCSSを使う場合はスピードが速いため制御データのやりとりが多くてもレスポンスへの影響は少ないのですが、WANでは大きな影響があります。

 CSSのOLTPではTPモニタとか、ミドルウェアと呼ばれるアプリケーションとOSの中間に位置するソフトがあり、データベースの操作やリカバリ処理制御・負荷制御等をしています。LAN上で使われることを前提にしたミドルウェアはいわば安普請なので、レスポンスを向上させるために制御データを減らす工夫をしていないのです。対してWAN上での利用に配慮したミドルウェア、たとえばTUXEDOはSQL等の制御データを最小限にする配慮がされているためWAN上で利用してもレスポンスの劣化が少ないのです。

 要はOLTPをフレームリレーのような遅延の大きいWANで行うときには単純に「流れるデータ量が32K程度だから、CIR32KでPVCを張りましょう」などというシステムに無知なネットワーク屋さんの言うとおりにしたのでは、後でレスポンスが出なくて大変なことになる、ということです。CSSをWAN上で使うにはNさんのようにシステムとネットワークの両方を分かった人に依頼するのがポイントです。システムのことも知らないで単純にISDNをフレームリレーにしましょう、などという提案には要注意です。
 
 

 
ホームページへ