PR

WAN高速化装置は,拠点間通信のレスポンスを改善する製品。ともすればブロードバンド回線があれば不要にも思えるが,むしろブロードバンドが普及した最近になって注目を集めるようになった。その理由は,WANのブロードバンド化ではレスポンス向上が解決できないアプリケーションの存在が認識され,その原因として「遅延」という問題が顕在化してきたからだ。

 ここ数年,拠点間通信のレスポンスを改善することをうたうWAN高速化装置という製品が市場で盛り上がりを見せている。

 例えば,米シスコ,米ジュニパーネットワークス,米リバーベッド・テクノロジーなどの通信機器メーカーが相次いで参入し,競って装置を販売している。日本のユーザー企業の注目度も相応に高い。製造業などで導入が進んでいる。

 ところで,WAN高速化装置に注目が集まり出した時期は,光ファイバに代表されるブロードバンド・インフラが企業に浸透した時期と一致する。通信回線がブロードバンド化したことで,十分にレスポンス向上効果を得られているようにも思える。にもかかわらず,なぜ装置が必要とされているのだろうか。

広帯域化で新しいWANの使い方が出現

 理由を探るために,まずWANがどのように進展してきたかを整理しておこう。

 近年,企業のWAN環境は目覚ましい勢いで進化した。現在ではブロードバンド回線を足回りに,IP-VPN(仮想閉域網),広域イーサネット,インターネットVPNなどを活用した高速の社内ネットワークを運用する企業が多数を占める。専用線時代であればkビット/秒単位が一般的だった拠点間の通信速度は,今や数十Mビット/秒ということさえ珍しくなくなった。

 ブロードバンド化の進展により,企業は従来のWANでは見られなかった使い方をするようになった。

 典型的な例は,全国各地の拠点に設置していたファイル・サーバーをデータ・センターに集約し,WAN経由でアクセスさせる取り組み。セキュリティの向上や,サーバー運用コストの削減が目的である。

 サーバー集約は今後も多くの企業に広がる可能性が高い。いわゆる「日本版SOX法」の規定により,企業はメールなどの情報を保管する措置が求められるようになった。このような作業の負荷を抑えるには,サーバーを集約・統合することが望ましいからだ。

立ちふさがる遅延の壁

 ところが,実際に各拠点からWAN経由でファイル・サーバーにアクセスする形態にした企業は,問題にぶつかることになる。各拠点にサーバーを置いていたときと比べて,レスポンスが悪化してしまうのである。たとえ帯域が十分にあっても,この現象に見舞われる。問題を理解するには,WANの「遅延」に注目する必要が出てくる。

 通信のレスポンスを決める要素は大きく三つある。具体的には,(1)遅延,(2)1回のやり取りで送信するデータ量である「ウインドウ・サイズ」,(3)アプリケーションのバースト転送性である。

 (1)の遅延は,ネットワークの品質で決まる。一方の(2)と(3)は,アプリケーションやプロトコルによって決まる。このため,遅延の影響を受けやすいアプリケーションが存在する。その代表格は,米マイクロソフトのファイル共有プロトコルのCIFS(common internet file system)や,データベースに使われるMicrosoft SQL(MS-SQL)などのアクセスである(図1-11-2)。ここでは,CIFSの通信形態をサンプルに解説する。

図1_1●CIFSの通信シーケンス
図1_1●CIFSの通信シーケンス

図1_2●ODBCの通信シーケンス
図1_2●ODBCの通信シーケンス

 理論上のスループット(ビット/秒)は,「ウインドウ・サイズ×8÷遅延値(秒)」という計算式で求められる。この計算式から,ウインドウ・サイズが大きく,遅延値が小さい環境ほど良好なスループットを得られることが分かる。

 WindowsXPであれば通常,ウインドウ・サイズは最大64Kバイトとなる。ところが,CIFSを使う場合には転送サイズの制限がある。一つのAckに対し,最大で1514バイト×2(=3Kバイト)のデータしか送信できない。WindowsXPからのウインドウ・サイズの要求は64Kバイトなのだが,CIFSの通信形態は1514バイトのパケットを二つ転送するにとどまる。これは,CIFSの仕様上の転送制限である。

 さらにCIFSの通信では,送信したデータに対するAckが返ってくるまで,送信側は次のデータを送信しない。データを連続して送信するバースト転送ができないわけだ。

 このようなメカニズムでは,遅延が大きくなるとレスポンスが悪化する。遅延によってAckが到達するまでの時間が増え,サーバー側が次のデータを送信する間隔が長くなるからだ。

 例として,700KバイトのファイルをCIFSで転送する場合を考えてみよう。遅延が1ミリ秒未満のLAN環境であれば1~2秒で完了する。ところが,遅延40ミリ秒の環境で同様の操作をすれば約60秒もかかる。

 というのも,700Kバイトのデータ量ではネットワーク上でのシーケンス数が1000強にのぼる。シーケンスごとに遅延の影響を受ける結果,何十倍もの時間がかかってしまう。

 このように数十ミリ秒程度の遅延でも,遅延の影響を受けやすいアプリケーションの通信ではレスポンスに大きな差をもたらすことになる。

WAN高速化装置は遅延を克服する

 レスポンスを高めたい場合,すぐに思いつくのは回線の帯域を増強すること。しかし,遅延の影響を受けやすいCIFSやMS-SQLの通信では,帯域を増強してもレスポンス向上は期待できない。

 CIFSやMS-SQLの通信はバースト転送ができず,遅延が大きいとデータを送信していない時間が長くなる。帯域を十分に使い切れていない状態である。このため,いくら帯域を増やしてもレスポンスの改善にはつながらない。ちなみにFTP(file transfer protocol)のようなバースト転送ができるアプリケーションなら,帯域増強でレスポンス向上が期待できる。

 このようにレスポンスを向上させるには,アプリケーションの特性に応じた対処法が必要となる。帯域増強は決して万能の解決策ではない。

 そこで,WAN高速化装置の出番となる。WAN高速化装置は,帯域増強では難しい「遅延を克服する」仕組みなどを備えているからだ。