アプリケーショントラフィック管理入門 第5回

WAN高速化の基礎技術　第1弾

WANの遅延を抑えて、レスポンスアップする

WAN経由でのアプリケーションレスポンスの向上を実現するのがWAN高速化の技術だ。今まで紹介してきた圧縮、キャッシング、オフロードなどのほか、プロトコル最適化などの処理も行なう。

本記事は「アプリケーショントラフィック管理入門」の第5回です。過去の記事も合わせてご覧ください。

WAN高速化装置の登場

　ロードバランサーは、クライアントのリクエストを複数のサーバーに振り分けることで、サイト全体のパフォーマンスや可用性を高める仕組みを提供する。こうした装置は、1990年代後半のドットコムビジネスには必須とされ、多くの企業で導入されることになった。また、専用のWeb高速化装置も登場した。そして、2003年頃に登場したのが、WANでのパフォーマンスを向上させる「WAN高速化装置」だ。

　WAN高速化装置は、これまで紹介してきたキャッシング、圧縮、QoS（Quality of Service）、プロトコル最適化などの技術を駆使して、WANに流れるデータを削減したり、通信品質をコントロールする。この結果、遅延を削減することが可能になり、アプリケーションのスループットが劇的に改善される。「WANをまるでLANのように利用できる」というわけだ。

　両者の最大の違いは、利用環境のネットワーク構成にある（図1）。ロードバランサーやWeb高速化装置は、サーバーとクライアントの間で通信を仲介するように設置し、複数のサーバーに処理を振り分けたり、サーバーの処理を肩代わりする。こうした「非対称型」の設置形態では、クライアントやサーバーと直接通信するため、自ずと独自の技術は利用できない。WebブラウザやWebサーバーがサポートする汎用的な規格をベースに通信の最適化を行なうことになる。

図1　非対称型のロードバランサーと、対称型のWAN高速化装置

　一方のWAN高速化装置は、同じ装置を拠点ごとに設置して、対向で利用する。こうした「対称型」において高速化を実現する通信相手はWebブラウザ等ではなく、あくまで同じベンダーのWAN高速化装置だ。そのため、汎用のWebブラウザが相手の場合と異なり、独自技術を用いることが可能になるわけだ。

ブロードバンドでもレスポンスは悪い

WAN高速化装置が登場した背景には、既存の高速化手法が限界に至ってしまったことが挙げられる。

　第1回で述べたとおり、1990年代において、アプリケーションのパフォーマンスを上げる方法としては、帯域の拡張とサーバーの増設がメインであった。帯域は拡大すればするほど、伝送能力は高まり、サーバーを増設すれば、その分処理能力が向上する。こうしたなかで、サーバーへのリクエストの振り分けを自動化できるロードバランサーが持てはやされたというのは、すでに説明したとおりだ。

　その後、2000年以降、韓国や日本を筆頭に、インターネット接続の広帯域化と常時接続が一気に進んだ。また、複数のサーバーに並列処理させることで処理能力を上げる「スケールアウト」という手法も一般化し、薄型で低価格なラックマウントサーバーが登場しました。その結果、アプリケーションのパフォーマンスは、従来に比べ飛躍的に向上した。特にISDNからADSLへの移行によるレスポンス向上は、充分に実感できるものといえる。

　しかし、向上するにはしたものの、その効果は限定的といわざるをえない（図2）。

既存の高速化テクニックの限界

　たとえば、1.5MbpsのADSLが100MbpsのFTTHになった場合、ファイル共有で66倍にも及ぶ帯域の差を感じることができるだろうか？　1時間かかっていたファイルの転送時間が、1分で済むようになるわけではない。実際のところ、転送速度はあるところで頭打ちになるのだ。特に後述するとおり、TCPでは用意された帯域をフル活用することは難しい。こうした意味で、既存の対策だけでは「効果は限定的」という表現をしたわけだ。では、ブロードバンドであってもレスポンスが上がらないのは、どのような理由からなのだろうか？

（次ページ、サービスの可用性を確保）