こんにちは。ネットワンパートナーズでRiverbed 社製品を担当している中島です。

今日はWAN最適化製品の魅力と、SteelHeadの優位性についてお話しできればと思います。以前に弊社の池田がIOTについて記事を書くときに、「SteelFusionについても触れて！」とお願いしながら、今回はSteelHeadの紹介をさせていただきます。SteelFusionは、SteelHeadと連携して動作することもあり、私の初めての記事はSteelHeadについて書かせていただきます。SteelFusionは別途紹介記事を書かせていただければなと思っています。

ブロードバンド環境と日本

日本のブロードバンド回線は他国に比べて品質が良いといわれています。2009年とちょっと古い情報ですが、左の図にあるとおり日本は世界で一番速いブロードバンドサービスを展開しています。さらにその回線の1Mbpsに対するコストは$0.27となり、安価な形で提供されています。

日ごろから恵まれたブロードバンド環境にアクセスしているからこそ気が付かないのがアプリケーションパフォーマンスについての視点です。私たちが利用している回線は”高品質”で”速い”という共通認識がアプリケーションパフォーマンスに視点を向ける意識を阻んでいるのではと考えます。

アプリケーションパフォーマンスと遅延の関係

普段、みなさまが提案・構築・運用・利用されているデータセンターからオフィス向けに用意している回線の契約帯域はどれくらいでしょうか？ 100Mbps? 1Gbps? 中には10Gbpsなんていうリッチなお客さまもいるかもしれませんね。その回線を有効利用できていますか？ MRTGや通信キャリア様が提供するレポートツールで利用状況を確認すると、それなりの帯域の使用率が表示されるのではないでしょうか？ それでは、ホスト対ホストというもう少し小さい視点ではいかがでしょうか？ 更にもう少し小さな視点について考えましょう。

ホストが利用しているWAN越えのアプリケーションのスループットはどうでしょうか？　WAN越えの通信で特定のアプリケーショントラフィックが最大限通信可能なスループットを使い切っている状況は非常にまれだと思われます。この原因となるのが距離遅延とTCPスループットの関係となります。机上でのWAN越えの通信で期待されるTCPスループットは以下の数式で算出することが可能になります。

あまりにも古いシステムでない限り、各ホストのTCP Windowサイズは64kByteもしくは64KByte以上(Windows Vista以降)になります。今回の記事では想定するケースが複雑になりますので、Windows Vistaから搭載されたTCPのウィンドウサイズの自動調整機能については考慮から除外させていただきました。その上で遅延とTCPスループットのグラフを以下に記載します。

左図のTCPスループットと遅延の関係を見てい頂くと、遅延が20msecを超えると著しくスループットが低下します。20msecの遅延というと回線にもよりますが、東京-札幌、東京-大阪間の通信が該当します(*1)。
机上での計算になりますが、事業拠点を全国展開されているエンドユーザー様だと地方オフィスからデータセンターへのトラフィックはLAN内の通信に対して、半分以下のスループットになっている場合が多々あると考えられるということです。
さらにTCPの上位レイヤーでもアプリケーション独自のメッセージのやり取りがありますので実際にはさらにスループットが減少することになります(*2)。

参考:
*1 通信距離とTCP帯域その２：実際の往復遅延時間
*2 教科書には載っていない ネットワークエンジニアの実践技術（第2回　ネットワーク遅延と高速化）

これは物理的な距離によって起こる地理的な制約になりますので、いくら通信事業者様が用意する回線の契約帯域をアップグレードしても改善できない事象となります。この事象をカバーするのがWAN最適化装置の役割です(余談ですがSteelHeadをご提案させていただく際に、回線の増速とSteelHeadの導入時のコストの差を算出されるお客様がいらっしゃいます。

WAN高速化装置が解決する問題とWANの増速が解決する問題はそれぞれ異なりますのでできれば両方あわせて実施いただくのが良いと考えています。WANの増速はWANルーターのキュー詰まりを解決しスムーズにWANへパケットを流すためのアプローチであり、SteelHeadの様に物理的な遅延を解決するための仕組みではありません。
したがって競合するソリューションではありません)。

SteelHeadがどのように物理的な遅延を解決するかについては、次回のblogで解説させていただきます。