拠点間のデータ遅延を解消する「WAN高速化」最新事情

アクセスを高速化し、遠隔業務でも高い生産性を実現

（2007年11月02日）

WAN回線増速とはどこが違うのか

　米国のIT情報誌「Business Communications Review」の2006年4月号に掲載された、企業における通信トラフィック量の調査結果によると、通信トラフィックに占めるプロトコルの割合で一番多いものが、CIFSの約17％であった。次いで多いのがSMTPの16％、HTTPの15％となっている。これら3つのプロトコルにFTP（ファイル転送プロトコル）を加えた4つが、WAN経由で頻繁に利用されるプロトコルである。WAN回線増速とWAN高速化装置のアプローチの違いを理解するうえでも、プロトコルの特性を知ることは重要である。以下では、4つの中から、FTPとCIFSを取り上げて解説する。

■ FTP

　FTPでは、クライアントから送信された1つのデータ要求に対して、サーバは複数のデータ・ブロックをひとまとめにして応答している（図1左側）。FTPにバースト性があると言われるのは、クライアント／サーバ間の要求／応答というやり取りで、応答をまとめて行えるからである。TCP/IPレイヤで考えると、応答をまとめて行えるFTPは、TCPウィンドウ・サイズの最大値（注1）でデータ転送が可能である。例えば、TCPウィンドウ・サイズ64KB、遅延30ミリ秒の環境では、「64KB×8÷30ミリ秒＝約17Mbps」のスループットが出ることになる。ちなみに、最大スループットは、「（TCPウィンドウ・サイズ×8）÷往復応答時間（RTT）」の計算式で算出することが可能だ。

注1：TCPウィンドウ・サイズは、OSの種類やバージョン／リリースによって異なる。Windows XP SP2やWindows Server 2003では最大64KB、Windows XP SP1では最大16KBとなる

■ CIFS

図1：FTPとCIFSのクライアント／サーバ間通信

　CIFSは、クライアント／サーバ間の要求／応答のやり取りが非常に細かい（図1右側）。これは、CIFSがSMBブロック・サイズを基に通信しているからだ。SMBブロック・サイズは、4KBから16KBで使用されることが一般的（Rawモードは64KB）であり、TCPウィンドウ・サイズが64KBであっても、上位プロトコルのSMBブロック・サイズで4KBから16KBに制約されていれば、スループットは上がらない。

　FTPで用いた最大スループットの計算式に当てはめ、CIFSのスループットをSMBブロック・サイズから算出すると、遅延30ミリ秒、SMBブロック・サイズ16KBの環境では、「16KB×8÷30ミリ秒＝約4.2Mbps」となる。ここでは、TCPウィンドウ・サイズをSMBブロック・サイズに置き換えて計算しているので、あくまでも参考程度の数値ではあるが、過去のデータからすると比較的近い数値であると言える。

　FTPとCIFSを比べてみると、上位プロトコルの制限により同じ遅延30ミリ秒の環境でも最大スループットに大きな差が出ていた。これに帯域が100Mbpsである場合を加味すると、30ミリ秒の遅延環境下ではFTPの最大スループットが17Mbps、CIFSは4.2Mbpsであるため、100Mbpsの帯域をまったく使い切れていないということになる。

WAN高速化では効果が得られず
WAN回線増速が必要なケース

　それでは、どのような環境であればWAN回線高速化が有効で、どのような環境だとWAN回線増速が必要になるのか。回線増速が必要となる環境は、共通性の低いデータ転送がメインで、WAN高速化装置によるデータ量の削減効果が期待できず、回線の輻輳が発生するようなケースに限られる。例えば、帯域1.5Mbps、遅延30ミリ秒の環境で、FTPを使って共通性の低いデータを転送する場合には、WAN高速化装置を使ってもデータ・キャッシュによる高速化効果が得られず、WANに流れるデータ量が減少しない。さらに、FTPの最大スループットである17Mbpsよりも実回線（1.5Mbps）が細いため、回線の輻輳が解消されず高速化効果が出ない。

　こういった環境であれば、回線を増速することで性能を簡単に上げることができる。つまり、回線帯域を現行の1.5Mbpsから3Mbpsにすれば性能が約2倍になり、FTPの最大スループット値までは回線増速の効果が得られる。ただし、実際のユーザー環境を見ているかぎりでは、常にWAN高速化装置に共通性の低いデータばかりが流れているわけではない。そのため、回線増速とWAN高速化装置を組み合わせることで、より効果が得られるケースもある。

主要ベンダーのWAN高速化装置と技術トレンド

　ここでは主要ベンダーのWAN高速化装置に関して、特にCIFSに限定した比較を行う。CIFSに限定するわけは、各ベンダーにより高速化対象とするプロトコルにバラつきがあり、主要製品に共通した機能がCIFS高速化であったためだ。

　図2にCIFSにおける3種類の通信パターンを示した。各社若干の違いはあるが、大きく分けて3つのパターンに大別することができる。

図2：CIFS高速化の通信パターン

パターン1：WAFS

　パターン1は、WAFSと呼ばれる製品に位置づけられ、シスコ、パケッティア、ブルーコートの製品が該当する。これらの製品は、WAFS装置間では独自の高速化プロトコルを用い、バイト単位でデータをやり取りしているが、クライアント側WAFS装置にはファイル単位でデータをキャッシュしている。クライアントは、WAFS装置上のキャッシュ・ファイルにアクセスするため、大幅に高速化が図れるが、コンプライアンス対策という意味では、WAFS装置にファイルが丸ごと残ってしまうことになり、安全性に欠ける。

　また、クライアント側WAFS装置は、WAFS装置同士がやり取りする際に必要なバイト単位のキャッシュ領域と、クライアントがアクセスするファイル単位のキャッシュ領域の両方をハードディスク上に確保しなければならない。このことは、WAFS装置内でのデータ重複につながり、ディスク利用効率が悪くなる。

パターン2：WAN高速化装置

　パターン2は、WAN高速化装置に位置づけられ、リバーベッドとシトリックス・システムズが主要ベンダーである。

　両社のWAN高速化装置は、WAFS装置とは異なり、クライアント側の装置にバイト単位でデータをキャッシュしている。クライアント側装置には、ファイルを数バイト単位に細分化してIDを付加したデータ・セグメントだけが保存されるため、装置へ直接アクセスしてもデータ・セグメントからファイルを構成することはできない。これにより、情報漏洩を防止している。

　クライアント側装置には完全な形のファイルが存在しないため、クライアントは実際のサーバへアクセスすることになり、WAFS装置と比べればスループットが若干遅い。しかし、過去の検証データを見ても今やその差はほとんどなく、キャッシュ機能が高度化していることがうかがえる。

　また、バイト単位でのキャッシュは、ハードディスクの利用効率も高い。ファイルには共通なビット列が多数存在しており、たとえファイル1個分をバイト単位でキャッシュしたとしても、ファイル1個分のハードディスク領域が必要になるわけではない。特にオフィス系データであれば、ファイル1個のうち約50％が共通なビット列であり、共通なビット列を排除することで、ハードディスク領域は事実上半分で済む。

パターン3：WAN高速化装置（トンネリング）

　パターン3も、WAN高速化装置に位置づけられ、WAN間でトンネリング技術を使っている点が特徴となる。該当するのは、ジュニパーとF5ネットワークスである。

　2社共に、UDPによるトンネリング技術を採用しており、バイト単位でキャッシュを行うため、パターン・のWAN高速化装置と同様に、クライアント側装置にファイルを残さない。また、両社の最近の動向としては、データをキャッシュする記録媒体を従来利用してきたフラッシュ・メモリから、徐々にハードディスクに切り替えてきている。

前のページへ < ｜1｜2｜3｜ > 次のページへ