はじめに
しばらく前にTwitterで見かけたWAN高速化装置に関する疑問について、ネスペなんかではまだ出ますし、後輩のためにも記事にまとめておこうと思います。
WAN高速化装置は導入の目的が2つあるってのが理解の助けになるかもですね。
— カスキー@技術書典8Day1く03 (@skksky_tech) 2019年12月17日
①レイテンシの向上
→代理応答によってレイテンシ（RTT）が向上。
②利用帯域の圧縮
→キャッシュ、データ圧縮などによって細い回線でも多くのデータを送れる。回線費用が高い地域に入れると効果的。 https://t.co/3MXN7cXAy7
WAN高速化装置とは
WAN高速化装置とは、2000年代後半～2010年代前半ごろに広く使われ始めた技術で、①レスポンスの向上や②利用帯域の圧縮を可能とする機器として使用されました。現在でも使用している企業はもちろんあります。
簡潔に言うと、拠点とデータセンターに設置して、設置した機器間の通信を「高速化」する仕組みです。
WAN高速化装置は略してWAS（WAN Acceleration System）と呼ばれたりもしますので、ここからはWASで統一表記します。
なぜ、WASが必要とされたのか
当時のエンタープライズネットワークは、いわゆるデータセンター集約型の構造にシフトしていた時代です。（下図参照）
それ以前もデータセンターと拠点をWANでつなぐ構造になっていましたが、ファイルサーバのようなデータ転送量の多いアプリケーションをデータセンターに設置したり、クラウド利用が進んだりしたことによって、WANを流れるデータ量が急激に増大しはじめました。
もともとは、データセンターにある自社システムを使用するために引いた回線ですから、必要最低限（数百K～数十Mbps）の回線しか用意しておらず、しだいにWAN帯域が逼迫していくことになりました。
データセンターと拠点間のWAN回線は専用線であったり、IP-VPN網であったり、MPLSであったりと、今とあまり変わりません。
「逼迫したのなら増速すれば良い」というのはもっともですが、いずれの回線も維持コストが馬鹿にならない（とくに海外との接続）ものだったため、情報システム部門は、一朝一夕に増速することはできませんでした。
さらに問題がありました。
回線増速対応を行ったにもかかわらず、効果のでない拠点があったのです。帯域に余裕があるのにユーザーからは通信遅延のクレームが上がってくるのですから、これには情シスも頭を悩ませました。
こんな情シスの悩みを解決すべく登場したのが、WASというソリューションです。
WASを導入する目的は何か
ここまで書いてきた内容から、当時の情シスが抱えていた課題は以下の2つとなります。
- WAN帯域が逼迫しているが、増速するとコスト高であり、費用を捻出できない
- WAN帯域は逼迫していないのにもかかわらず、拠点からデータセンターの特定のアプリケーションを使うと「遅い」事象が発生している
ここからは、WASを導入するモチベーションついて見ていきます。
データ量を削減する「圧縮/キャッシュ機能」を使いたい
前者の課題の原因は、「WANを通るデータ量が増えたこと」なので、データ量に対して適切なWAN回線の帯域を用意できれば解決すると考えられます。
アプローチとしては、「データ量を減らす」もしくは「帯域を増やす」です。
普通に考えれば、純粋にデータ量が増えている背景がありますから「データ量を減らす」ことはできず、コストをかけてでも「帯域を増やす」選択を取らざるを得ません。
しかし、WASを導入すれば「圧縮機能やキャッシュ機能によってWANを流れるデータ量を削減する」ことが可能になります。
これが、WASを導入する目的のひとつです。
WAS導入・運用コストと回線増速・ランニングコストをしっかりと比較する必要はありますが、高い回線にお金を追加で払う必要がなくなることで、コスト削減につながる可能性もあります。
レイテンシを向上させる「代理応答機能」を使いたい
もうひとつの目的は、「代理応答によってレイテンシを向上させることで通信遅延を軽減する」ことです。
これは、後者の課題に対するソリューションとなります。
帯域が逼迫していないのに通信遅延が発生する例としてよく挙がるのが、ファイルサーバとの通信プロトコルとして使用されるCIFS通信です。
CIFSには、送信したデータに対するレスポンスが返ってくるまで次のデータを送らない、また、1回に送信可能なメッセージサイズが小さいという仕様があります。
送信したデータに対するレスポンス（TCP ACK）が返ってくるまでデータを送らないということは、物理的な距離が遠くなればなるほどRTTは大きくなっていくため、遠くの拠点とファイルのやりとりをする場合は近い拠点よりも大きく時間がかかることになります。
また、送信可能なメッセージサイズが小さいということは、ファイルの転送を終えるまでに行う通信の回数が多いことになります。
ただでさえ、レスポンスを待たないと次のデータを送らない仕様に加えて、一度に送信可能なデータ量が小さいために非常に多くのやりとりをしなければなりません。結果として大きな遅延となってしまうのです。
これを解決するのがWASの「代理応答機能」です。遠くの拠点のクライアントとやりとりするとレスポンス待ちの時間が長くなってしまいますが、WASが遠くの拠点のクライアントに代わってファイルサーバにレスポンスを返すことによって、通信遅延を軽減することが可能になります。
「通信最適化機能」を使いたい
WAS間の通信はTCPの拡張（MX-TCPなど）やウィンドウサイズの拡張のようなプロトコルの改良によって、通信が最適化されます。これにより、TCPとしての手続きの簡略化や一度に送付可能なデータ量の増大が期待できます。
WASを導入する目的
改めてWASを導入する目的と期待効果を整理すると大きく分類すると以下のようになります。
①利用帯域の圧縮 → キャッシュ、データ圧縮などによって細い回線でも多くのデータを送ることができる。回線費用が高い地域に入れるとコスト削減効果を得られる可能性がある。
②レイテンシの向上 → 代理応答機能によってレイテンシ（RTT）が向上し、WAN越しの通信遅延を軽減できる可能性がある。
③通信最適化 → プロトコル拡張によって、手続きの簡略化等が期待できる。
詳細に図示するとこんなイメージです。
WASは情シスの悩みを解消するソリューションとなれたか
個人的な見解ですが、半分YESであり、半分NOだと考えています。
WASがデータを圧縮することで、細い回線のままでも回線逼迫しなくなる可能性があります。日本であればMPLS等の値段が高いといってもしれていますが、海外では回線コストが異常に高い地域もあります。そういった意味では、WASを導入し運用するコストを受け入れてでも、回線コストを下げることに成功した企業が一定数あるのではないかと推測しています。
一方で、レイテンシの向上によるWAN越しの通信遅延軽減は、難しかったのではないかと推測しています。どれほど代理応答を早くしたとしても、その後WAS間は別の通信方式で遠くの拠点までデータを運ばなければなりません。この距離だけはどれだけ頑張っても縮めることができないので、WAS導入による遅延軽減効果はいまひとつだったのではと考える次第です。
WASの今後
WASは今後消えゆく運命でしょう。
WAN高速化をSaaSにも適用するソリューションがいくらか出てはいますが、残念ながら売れているようにはみえません。
個人的にはネーミングにも問題があったと思いますが、WANを高速化（accelerate）する装置といっているのに、遅延に対する効果はいまひとつであったのが致命傷かなと思います。きちんと仕組みを理解していなければ、「高速化」という言葉に過剰な期待を込めてしますものです。
WAN高速化の今後
今後ですが、やはり市場の主力はSD-WAN製品です。WASのキャッシュ機能はSD-WAN製品に巻き取られていますので、ある意味後継といえるかもしれませんね。
ただし、代理応答を実装したSD-WAN製品は、もしかしたらあるのかもしれませんが、私は見たことがありません。
そもそも、代理応答の恩恵を受ける最たる例として挙げられていたCIFSを、WAN越しで使う時代が終わりかけているのもひとつの要因かもしれません。クラウドシフトがしっかり進んでいますから、ファイルサーバも、OneDriveやBoxに代表されるストレージサービスへ置き換わっています。これらは基本的にHTTP(S)の世界です。HTTPは、1回1回レスポンスを待ったりしませんので、代理応答機能の有効性は低いでしょう。
しかしながら、SD-WAN製品に対しても「高速化」を期待するのは難しいでしょう。たしかに、VeloCloudのようなサービスであれば、彼らのバックボーンを使うことで高速化が可能と謳っていますが、物理的な距離にはどう頑張っても勝てません。地球の裏側のブラジルから東京にアクセスしようとすれば、数百ミリ秒かかるのは事実です。光の速さは決して超えられません。
高速化する手段はないのか
じゃあ高速化する手段はないのかというとHTTP(S)に関しては手段があると思います。
それはCDNです。
CDN（Content Delivery Network）は、Akamaiに代表されるように古くからある技術ですが、CDNはコンテンツサーバがユーザの拠点まで「近づいて」来ていますから、物理的な距離を大幅に短縮できます。
最近のCDNは、ある程度のスクリプトはCDNのエッジサーバで処理することもできますから、静的コンテンツ以外も多少は恩恵を受けられる時代になってきているようです。
昨今は、SaaS利用の高まりからインターネット・ローカル・ブレークアウトが推奨される時代であることも後押しとなり、ありとあらゆるものがHTTPというプロトコル上で動くようになった時代でもあります。
今後、WANの遅延に悩む情シスが向かうべき方向性は、古き良き(?)クラサバシステムをHTTP上で動くように改修し、CDNをつかった構成にシフトする、もしくはIaaS/FaaSを活用して遅延に悩む拠点の近くにシステムを配置する構成を検討することが良いのではないでしょうか。
（蛇足）WASの運用について
WASの運用で留意したほうが良い点を参考までに記載しておきます。
バイパス機能
WASはその特性上、インライン構成で置く必要があります。
「ハードウェア障害時には通信できなくなるの！？」と思う方もいらっしゃるようですが、バイパス機能がありますので、壊れた時にはWASはただのケーブルのように振る舞います。
WASが提供する機能（代理応答、キャッシュ、最適化）は利用できなくなりますが、通信が止まることはありません。
ただし、WASの提供する機能が使えなくなるということは、故障時にはWAN回線が逼迫したり、通信遅延が大きくなる可能性はあります。迅速に交換できる体制を作っておくべきでしょう。
ディスクが飛ぶ
WASはキャッシュのためにデータを蓄積するため、ディスクはキャッシュ機能の要となります。
物理サーバの運用をした経験のある方はわかると思いますが、ディスクはしょっちゅう壊れます。
ネットワークエンジニアは案外サーバ運用経験がないので気が付きにくいところです。
ディスク交換についても、保守体制をよく考えておきましょう。
ソフトウェアの検討
WASには物理的に設置するアプライアンスタイプもありますが、ソフトウェアタイプの製品もあります。ソフトウェアのバージョンアップ方法については考慮する必要がありますが、比較的簡単に導入できるので、検討の余地はあるでしょう。
おわりに
長文になってしまいましたが、2020年1月時点での私の考えはこんな感じです。
長文読んでくださった方、ありがとうございました。
以上
