catch-img

そのアプリケーションパフォーマンスに満足していますか?(2)

こんにちは。ネットワンパートナーズでRiverbed 社製品を担当している中島です。
前回のblogの続きで、WAN最適化製品の魅力と、SteelHeadの優位性についてご紹介してまいります。

目次[非表示]

  1. 1.WAN高速化装置が解決するアプリケーションの遅延
  2. 2.機能その1 データストリームライニング
  3. 3.機能その2 トランスポートストリームライニング
  4. 4.機能その3 アプリケーションストリームライニング
  5. 5.SteelHeadを導入するとどれくらいパフォーマンスアップする?
  6. 6.WAN高速化装置で広がる更なるアプリケーションの利活用


WAN高速化装置が解決するアプリケーションの遅延

まず、WAN最適化装置が伝送距離遅延を解決するために何をするかについてですが、一般的には3つの仕組みを利用します。

一部の国産メーカーの製品や海外でも市場に参入してまだ日が浅いベンダーの製品はこの3つの機能をすべてではなく、一部使うことにより機器の低価格化を実現しているものもあります。どの製品も以下に示す3つの機能の一部もしくはすべて利用している形になります。カッコでくくられた中に記載された単語はSteelHeadでの機能名になります。

  • データーの重複排除/キャッシュ化による帯域削減(データストリームライニング)
  • TCP通信の効率化(トランスポートストリームライニング)
  • アプリケーションのやりとりの最適化(アプリケーションストリームライニング

次のテーマから、各機能の簡単な紹介をさせていただきます。


機能その1 データストリームライニング

SteelHeadを含め、一般的なWAN高速化装置は自身を通過するアプリケーショントラフィックをキャッシュする機能があります。

新規のデータが来た場合にWAN高速化装置はデータを自身の内部ストレージにキャッシュした後、WANに送信する際に圧縮して送信します。ストレージに保存されたデータのキャッシュにはIDが振られ、対向のSteelHeadとの間で同じIDで共有します。以後、同じデータがWAN高速化装置に着信した場合、生のデータを送信するのではなくこのキャッシュに紐づいたIDを送付することで、WANへ送信されるデータ量を削減することが可能になります。


機能その2 トランスポートストリームライニング

TCPはスロースタートなプロトコルであり、通信の信頼性を重視するために転送効率を犠牲にします。トランスポートストリームライニングはオーバーヘッドの高いTCPのやりとりをSteelHead間で効率化します。

具体的にはTCPウィンドウサイズの向上や、輻輳制御アルゴリズムの変更などを実施します。SteelHeadではTCPウィンドウサイズを仮想的に1MB+まで広げることにより、一度に送信できるアプリケーショントラフィックを向上させるとともに、HSTCP、New-Reno、MX-TCPなどの輻輳制御アルゴリズムから環境にあったものを選択することが可能です。


機能その3 アプリケーションストリームライニング

アプリケーション層で通信をWAN高速化装置で効率化するための機能になります。SMBではアプリケーションプロキシとして動作し、ファイルのやり取りに必要なメッセージの代理応答などを実施します。Citrix ICAの最適化の場合、L7でQoS(キューイング)を行うことをメインとし、SteelHeadに搭載されたRAMにキャッシュ領域を作り、キャッシュへのアクセススピードの向上を図りながらトラフィックの重複排除をおこないます。
アプリケーションレベルでWANを超えるやり取りに対して様々な視点で弱点を補うのがこの機能になります。SteelHeadの特徴としてアプリケーションレベルでの最適化が可能なプロトコルの種類の豊富さがあげられます。 エンタープライズ環境では時代とともに求められるアプリケーションが様変わりします。ここ数年はクラウド環境に業務アプリケーションが移行していることもあり、SteelHead for IaaS(ESXi / Hyper-V/ Amazon AWS)への対応やSteelHead SaaS(Office 365, Saleforce.com)のトラフィックの最適化もSteelHeadを導入することで可能となります。


常にエンタープライズ環境が求めるアプリケーションのニーズを把握し、そのアプリケーションに対する最適化機能を提供しているWAN高速化装置。それがSteelHeadになります。


SteelHeadを導入するとどれくらいパフォーマンスアップする?

上記の通り、SteelHeadは重複排除によってWANに流れるデータ量を削減することによって、またTCPウィンドウサイズの拡大による一度に送れるデータ量の増加によって、アプリケーション制御プロトコルのやり取りをLAN内で完結しデータのみをWANに送信するなどWANを超えるアプリケーションプロトコルの弱点を補うことによってTCP通信の伝送距離遅延を克服します。

では実際、どれくらいパフォーマンスが向上するのでしょうか? まずはWAN高速化装置が得意とするWindowsファイル共有でのパフォーマンス改善の例です。

パフォーマンス改善例

SteelHeadでWindows 2012 Server – Windows 8.1環境でファイル共有を行った際のデータです。この結果ではSteelHeadを導入することで最大60倍パフォーマンスを向上した形になります。WAN高速化装置について知識がある方なら当然の結果と思われるかもしれませんね。そのため別のプロトコルとしてSnapMirrorのパフォーマンス向上の例を以下に記載します。

SnapMirrorのパフォーマンス向上例

SnapMirror自体で重複排除しているところから、更に10倍以上のパフォーマンスアップが測れた例になります。

最後に、最近問い合わせ量が急上昇しているOffice365のパフォーマンスについてです。

Office365のパフォーマンス

上記例では20MbyteのファイルをSharePoint Onlineからダウンロードしたときの結果です。最大33倍のパフォーマンスを得られる結果になっております。 インターネットというベストエフォートでパフォーマンスをコミットできない環境に対して最適化を実施します。Office365を導入する際のアプリケーションパフォーマンスが心配。ユーザーから遅いという苦情が来ている。このようなお悩みをお持ちの方がいらっしゃれば是非ご相談いただければと思います。



WAN高速化装置で広がる更なるアプリケーションの利活用

この記事を読まれている読者の皆様は、常日頃からユーザーの方が使いやすいシステムにするために頭を悩まされていると思われます。 みなさまが接するインフラで、ここ3年間のIT投資がどのように実施されたか思い出してみてください。以下のどれかを実施しているのではないでしょうか?

  • データセンター内のネットワーク機器をデータセンター向けアーキテクチャ搭載機器に入れ替えた。
  • サーバーの性能増強するため機器を入れ替えた。
  • ユーザーが使いやすいようにオンプレミスのアプリケーションのフロントエンドをjavascriptで実装し、より一層ユーザーが対話しやすいアプリケーションの操作環境を実現した。

4人乗り自転車

これらすべて、ユーザーの方々がシステムを使いやすくするための投資です。ここにWANを超えるという視点はありますでしょうか?
ITシステムは個々のコンポーネントがそれぞれ独立した方向性で進化したとしても良い結果は生まれません。すべてのコンポーネントが協調して動作することによりユーザーが使いやすいアプリケーション環境が提供できるのではないでしょうか? 全員が一生懸命ペダルをこがないといけないという点では、複数人で乗車する自転車とちょっと似ている部分があると思います。
WANはキャリア様が品質を担保するものという視点ではなく、自社内で品質をコントロールすることが可能であるという視点でもう一度システムを見直してみるのもよいかもしれません。

最後にもう一度問いかけをさせてください。

そのアプリケーションパフォーマンスにユーザーは満足されていますか?