このトピックでは、パフォーマンスとセキュリティを向上させるために、クライアントの横でアプリケーション プロキシ サービスをプロビジョニングする方法について詳しく説明します。

問題



アプリケーションは通常、1 つまたは 2 つのデータセンターでホストされ、クライアントはインターネット経由で接続してアプリケーションを操作します。一部のアプリケーションでは、遅延を最小限に抑えることが重要です。これを行う最善の方法は、アプリケーションをクライアントの近くに移動することです。アプリケーションを支えるデータベースはプライマリ データセンターに残しておく必要があるため、オプションは制限されます。

解決方法

アプリケーションは変更されず、プライマリ データセンターに常駐します。クライアントが存在する場所の近くにアプリケーション プロキシを展開します。転送プロキシとクライアント間の遅延が最小限に抑えられ、接続の確立とデータ転送が大幅に高速化されます。完全な TCP および HTTP プロキシ、SSL 終端、キャッシュ、圧縮、およびセキュリティ ブロックや許可リストなどの機能により、クライアントのパフォーマンスが向上し、アプリケーションの分散セキュリティが強化されます。例の遅延図では、遅延が 100 ミリ秒で、クライアントが最初の html ファイルを受信するまでに少なくとも 400 ミリ秒がかかります。Edge プロキシを使用してクライアントの近くにコンテンツを移動すると、RTT が 30 ミリ秒の場合、最初の HTML ファイルは 120 ミリ秒以内に受信されます。大きな追加オブジェクトを要求すると、時間差が大幅に増大します。この場合、追加の TCP ACK とより多くの往復時間が必要になります。

ユースケース 1：

この使用事例は、クライアントの要求の動的な急増に関連しています。たとえば、会議やスポーツ イベント（例：オリンピックなど）など、一時的なイベントは地理的な地域に多数のクライアントを引き付ける場合があります。 

一時的なデータセンターは、パブリック クラウドの仮想インフラストラクチャにプロビジョニングされたいくつかのサービス エンジンを使用して、迅速に起動できます。イベントの後、Edge プロキシを簡単にプロビジョニング解除できます。このバリエーションの主な目的は、クライアント エクスペリエンスの高速化です。



使用事例 2

もう 1 つのバリエーションは、アプリケーションに定期的にアクセスする静的クライアントの場合です。このようなクライアントは、リモート オフィスなどの既知の信頼できるクライアントであるため、プロキシを社内にインストールできます。クライアントがアプリケーションにアクセスすると、その要求はローカル プロキシを経由してルーティングされます。ローカル プロキシは、クライアントの要求を暗号化されたトンネルと SD-WAN を経由して中央データセンターに送り返す前に初期認証を提供します。このバリエーションの主な目的はセキュリティであり、高速化は 2 番目のメリットです。

代替案

アプリケーションを高速化するための最も一般的な代替案はコンテンツ配信ネットワーク (CDN) です。通常、CDN には SSL 証明書が必要ですが、これは金融業界では実行不可能です。多くの場合、かなりの長期的なコストがかかります。

セキュリティの使用事例では、VPN または特定の専用 WAN リンクを使用して接続する各クライアントを構成できます。

アーキテクチャ

既存のデータセンターのアーキテクチャは、どちらの使用事例でも同じままです。使用事例 1 では、新しいデータセンターがオンラインになります。例として、AWS や GCP などのパブリック クラウドが挙げられます。プロキシ サービスを提供するために、2 つの新しいサービス エンジンがプロビジョニングされます。このような SE は、プライマリ データセンター内の既存のコントローラによって管理されます。各 Edge プロキシは、コントローラ内で一意のクラウドとして分離されます。

  • 仮想サービス：Edge プロキシを経由してプロキシされるアプリケーションごとに新しい仮想サービスが作成されます。このような仮想サービスは、SSL 終端、HTTP キャッシュ、アクセス コントロール リスト、クライアント認証、カスタム DataScript、または通常使用されるその他の機能用に構成できます。

  • プール：プロキシ仮想サービスは、プライマリ データセンターとセカンダリ データセンターの仮想サービス IP アドレスを含むプールを使用して構成します。優先ロード バランシングを使用すると、トラフィックはプライマリ データセンターに送信されます。プライマリが停止しているかアクセスできない場合は、セカンダリに送信されます。複数のアクティブなデータセンターが使用されている場合は、最も高速なロード バランシング アルゴリズムが推奨されます。

  • DC 間のトラフィック：Edge プロキシからデータセンター仮想サービスに転送される要求は、常に安全で暗号化されている必要があります。プロキシ仮想サービス プール内で、サーバ側の SSL を有効にして、ワイヤ間の暗号化を行います。

  • オブジェクトの再利用：SSL 証明書などのオブジェクトは、任意のクラウドで使用できます。そのため、SSL 証明書（または同様の共有オブジェクト）を更新すると、そのオブジェクトを使用しているすべての Edge プロキシが更新されます。

  • HTTP 圧縮：圧縮が必要な場合は、Edge プロキシで圧縮を無効にし、データセンター仮想サービスで圧縮を有効にする必要があります。これにより、圧縮が 1 回だけ行われます。データセンターでコンテンツが圧縮されると、圧縮されたコンテンツは Edge プロキシに接続されているクライアントに転送されます。

  • X-Forwarded-For：アプリケーション サーバでクライアント IP アドレスが必要な場合は、HTTP アプリケーション プロファイルを使用して、XFF ヘッダーを挿入するように Edge プロキシを構成する必要があります。プライマリ データセンターの仮想サービスでも XFF ヘッダー挿入が有効になっている場合は、Edge プロキシの SNAT IP アドレスが埋め込まれます。これを解決するには、プライマリ データセンター仮想サービスで DataScript または HTTP 要求ポリシーを使用して、送信元アドレスに基づいて XFF ヘッダーを選択的に追加する必要があります。送信元が Edge プロキシであり、XFF が既に存在する場合は、XFF を追加しないでください。送信元が Edge プロキシでない場合は、XFF を追加します。Edge プロキシが多数ある場合は、その IP アドレスを IP グループに配置して、ポリシーまたは DataScript をクリーンな状態に保ちます。



  • トラフィックの引き付け：パブリック インターネットでは、トラフィックは DNS を介して Edge プロキシに引き付けられます。これは、地理的な場所や IP Anycast などの動的アルゴリズムを使用するグローバル ロード バランサを通じて行えます。使用事例 2 のようなプライベート環境では DNS を使用できますが、代わりに静的ルーティングが必要になる場合があります。

  • リターン トラフィック：デフォルトでは、サービス エンジンはトラフィックを Edge プロキシで SNAT 処理し、その後データセンターで再度 SNAT 処理します。応答は同じパスを通過します。使用事例 2 では、SD-WAN を使用して、中央データセンターから各リモートの場所への接続を作成できます。NSX Advanced Load Balancer は、要求をサービス エンジンに送信した MAC アドレスにすべての応答を返します。