アプリケーション・プロキシについて
アプリケーション・プロキシは、アプリケーション・データ・ストリーム（一般にOSIモデルのレイヤー4～7の間で動作）の途中に挿入され、WAN接続上でパフォーマンスが低下するアプリケーションの特性を「修正」するためのシムとして機能するソフトウェアです。 これらの “修正 “には2つの種類があります：
- アプリケーションデータのデータ重複排除を可能にするのに役立ったもの。
- WAN接続を介して2つのアプリケーション・エンドポイントが必要とする通信（「チャット性」）の総量を削減するのに役立つもの。
アプリケーション・プロキシ（リバーベッドのような従来のWAN最適化ベンダーが使用）は古い技術であり、今日のWAN最適化の分野ではあまり使用されなくなってきています。
そして、この移行の理由のトップ5をご紹介します：
1) アプリケーションプロキシは、それが支援すると称するアプリケーションの多くを「壊す」傾向が高い。
これが、WAN最適化技術が「レイヤー7プロキシ」モデルから大きく移行した最大の理由です。
アプリケーション・プロキシは、アプリケーション・プロトコルの仕様に忠実に記述する必要があります。 SSLのような安定した低レベルのプロトコルでは一般的に問題ありませんが、MS-SQLやCitrix ICAのような高レベルの独自プロトコルでは問題になります。 これらのプロトコルは頻繁に変更され、その変更は公表されていません。
ネットワーク管理者の世界ではよくあることですが、どこかのサーバーがアップグレードされ、アプリケーションのプロトコルが変更されたことを知る最初の手がかりは、アプリケーションが正しく機能しなくなったというユーザーからの苦情が殺到したときです。
アプリケーションのプロキシが破損の原因として特定されたら、プロキシを新しいアプリケーションのバージョンと互換性を持つようにアップグレードする必要があります。 また、これらのプロトコルはしばしばプロキシプロバイダーによってリバースエンジニアリングされなければならないため、この破損に対する「修正」が利用可能になるまでには、（それが「広く使われている」とみなされるかどうかにもよりますが）何ヶ月も、あるいはそれ以上かかることがあります。
このため、ネットワーク管理者には2つの選択肢しかありません： 1) ネットワークが新しいアプリケーションのバージョンをサポートしていないことをサーバー管理者に伝える、または 2) アプリケーションプロキシを設定し、新しいアプリケーションを無視（バイパス）します。
2) 特定のプロトコルが徐々に使われなくなること。
この種の移行の例は、MAPIのようないくつかのプロプライエタリな暗号化プロトコルで今日見られます。 MAPIは、マイクロソフト独自のExchange Server電子メールプロトコルですが、より多くのクラウドベースおよびSaaSアプリケーションの進化に伴い、SSLは急速にSOHOおよびモバイルユーザーに選択される企業プロトコルになりつつあります。 また、マイクロソフト社もExchangeメール配信でSSLをサポートしているため、多くの企業がMAPIから非専有のSSLに移行しています。 アプリケーションがプロプライエタリ・プロトコルから離れるにつれて、この種のプロキシは時代遅れになります。
3) WAN最適化技術は、もはや特定のプロキシを必要としないところまで進化しています。
NFSがいい例です。 NFS v3は、ファイル共有プロトコルとして、WANの遅延に関連するスループットとエンドユーザーのレスポンスタイムに一定の制限がありました。 これは主にプロトコルの設計方法によるもので、アプリケーションの応答を受信せずに一度に送信できるデータ量が制限されていました。
同時に、既存のWAN最適化技術は、WAN上で送受信されるデータの総量を削減し、それによって輻輳を解消して応答時間を改善する方法として、主にデータ重複排除に焦点を当てていました。 しかし、これらの古いWAN最適化技術は、ブロックレベルの重複排除の形式を使用しており、NFSトラフィックではあまりうまく機能しませんでした。 NFSプロトコル伝送内のデータ部分の位置はさまざまです。
NFSのWAN問題を「解決」するための当時の最善の解決策は、アプリケーションプロキシを書くことでした。このプロキシーは、プロトコルが必要とする通信量を人為的に減らし、ブロックレベルの重複排除が有効になるように、NFS転送のデータ部分がどこにあるかを突き止めます。
従来のWAN最適化ベンダーは、依然として古い重複排除技術を使用しているため、NFS最適化のためにシムを必要としますが、新しいベンダーは、アプリケーション固有のプロキシを必要とせずにNFSトラフィックを最適化することができます！
4) 10年前にはWAN接続でうまく動作しなかったアプリケーションやプロトコルが、中間シムなしでWAN上で動作するように進化したり、再設計されたりしています。
もう一度、NFSを見てみましょう。 NFS v4.xの後のバージョンでは、チャット性とスループットに関するプロトコルの制限のほとんどが修正されました。 残りの限界は、アプリケーション固有のシムを必要とせず、一般的なTCP最適化によって解決されます。
5) 「アプリケーション・プロキシ」技術アーキテクチャは、ビジネスと開発の観点から持続可能なモデルではありません。
第一に、維持費が非常にかかります。 アプリケーションの新しいバージョンやそのアップデートがアプリケーション・ベンダーからリリースされるたびに、アプリケーション・プロキシ用に新しい特定の最適化メカニズムを開発する必要があります。
例えば、Citrix ICAはプロトコルを所有しており、リリースからリリースへ、あるいはサービスパックのアップデートの中でさえ、いつでもプロトコルの仕様を変更することができます。 これらすべてのアプリケーションプロキシを追跡し、非推奨のプロトコルをサポートし続けることは、あまり効率的なビジネスモデルではありません。
また、将来の拡張性も制限されます。 プロキシの本質は、リモートサーバーに代わって行動することです。 これを実行するために、プロキシは各アプリケーションセッションを終了し、追跡しなければなりません。 このため、必要なハードウェアのオーバーヘッドが非常に大きくなり、その結果、ますます大きなボックスが必要になります。
幸いなことに、かつてアプリケーションレベルのプロキシによって解決されていた問題は、現在ではより効率的な方法で解決されており、古いプロキシ技術の本来の利点のいくつかは時代遅れになっています。 古いバージョンのCIFSやSMBのように、WAN経由での最適化のために特定のプロキシを持つことで恩恵を受けるアプリケーション層のプロトコルはまだいくつかありますが、そのリストは常に少なくなっています。 特定のアプリケーション・レイヤー・プロキシへの依存を減らすことで、今日のテクノロジーは、信頼性を向上させ、潜在的な障害点を取り除きながら、より優れた最適化を提供することができます。
