最新のアプリ プロキシの 3 つの主な特徴
熱い側を熱く、冷たい側を冷たく保ちます。
数年前、マクドナルドが自社の商品のパッケージを「温かい面は温かく、冷たい面は冷たく」保つことを宣伝したキャンペーンを、皆さんは覚えているかもしれません（年齢が十分であれば、心配しないでください。手を挙げるようには言いません）。
コンセプトは実にシンプルでした。温かいものと冷たいものを分けて、持ち運びしやすいように 1 つの容器に保管するというものです。
同じ「コンテナ」内での分離という概念は、アプリ プロキシをプロキシたらしめる基礎となります。 クライアント側クライアントとアプリ側…アプリを保持します。
そうですね、結局のところ、私が望むほどきれいに翻訳されていないかもしれません。
それでも、この概念は有効であり、アプリ プロキシを理解する上で重要なものです。
基本的に、プロキシは、通信交換の 2 つの参加者の間に論理的に配置されるソフトウェアです。 アプリ プロキシはアプリとクライアントの間に配置されます。 現在、すべてのプロキシが完全なプロキシであるわけではありません。 完全なプロキシでは、2 つの側を内部的に分離する必要があります。基本的に、完全なプロキシには、1 つのデバイス内に 2 つの独立したネットワーク スタックが含まれています。 クライアント側 (ホット サイド) とアプリ側 (コールド サイド)。
わかっています、この例えは実際にはうまく機能していませんよね？ 私と一緒に働いてください。それが今のところ私にできるすべてです。
これがアプリ プロキシの要件である (または要件であるべきである) 理由は、プロキシがクライアントとサーバー間の交換に参加する機能を提供するためです。 これは、最小化（アプリのパフォーマンスを向上）やセキュリティ機能（データ スクラビングなど）、TCP 多重化（最適化）などの機能や、その他の幅広いサービスを提供するために必要です。
魔法が起こるのは、クライアント側とアプリ側の間の内部の「ギャップ」です。 ここでは、基本的な負荷分散から高度なアプリケーション ファイアウォール、アプリケーション アクセス制御まで、さまざまなサービスが機能します。 リクエストは、アプリ プロキシのクライアント側で実質的に終了します。 その後、サービス チェーニングによく似たプロセスが発生しますが、すべてが内部バスとプロセッサの速度 (ほとんどの場合、ネットワーク速度よりも高速) で内部的に発生します。 検査が行われます。 ポリシーが適用されます。 変化が起こります。 決定が下されます。 プロキシとアプリの間に別の接続が確立され、リクエストが送信されます。
そのリクエストがプロキシに戻ると、逆のことが起こります。 検査が行われます。 データが消去されました。 ポリシーが適用されます。 その後、クライアント側に戻り、クライアントに転送し直すことができます。
これらはすべてプロキシ内部で行われるため、1 秒未満のタイミングで実行されます。
アプリ プロキシの目的は、可用性、セキュリティ、モビリティ、ID とアクセス、パフォーマンスなど、幅広いアプリ サービスを提供することです。そのため、アプリ プロキシは完全なプロキシである必要があります。 完全なプロキシのみが、すべてのリクエストとレスポンスに参加するように設計されています。 シンプル プロキシ (詳しく言うと、実際にはステートレス プロキシです) は、クライアントとアプリ間の接続が作成される最初の会話にのみ参加します。 その目的は、アプリ インスタンスを選択し、その 2 つの間の接続を「つなぎ合わせる」ことです。 それ以降はプロキシは参加しません。 これは「フロー」（SDN について議論しているときに聞いたことがあるかもしれないレイヤー 4 TCP 構造ですが、これについては別の機会に説明します）を認識し、ホットとコールドを無差別に混合しながら、パケットを単純に前後に転送します。 （見る？ この類推が最終的にはうまくいくだろうとわかっていました。
さて、そうは言っても、最新の（そしてスケーラブルな）アプリ プロキシは完全なプロキシであり、プログラミング可能性、パフォーマンス、プロトコルという 3 つの重要な特性を備えている必要があります。
プログラミング可能性は、自動化、オーケストレーション、標準化をサポートするために、最新のデータ センターとクラウドで非常に重要です。 また、これは、ビジネスと運用に独自の価値を提供するセキュリティとサービスを有効にし、カスタム プロトコルのサポートと既存のプロトコルの拡張を可能にするためのデータ パスの鍵でもあります。 パフォーマンスは単純なように思えますが、実際はそうではありません。 アプリ プロキシはすべてのリクエストとやり取りするため、単に高速であるだけでなく、非常に高速である必要があります。 アプリエクスペリエンスを犠牲にして交換の遅延を増やすことなく、必要な作業を迅速に実行する必要があります。 特に、展開の基盤として汎用コンピューティングを使用するように求められている場合は、それは言うほど簡単ではありません。
最後に、プロトコルは重要です。 「アプリ」と言ったときに最初に思い浮かぶのはおそらく HTTP でしょう。 それは驚くことではありません。HTTP は新しい TCP であり、インターネットの共通言語です。 しかし、これは使用されている唯一のプロトコルではなく、特にインターネット対応の通信の時代においてはそうではありません。 SIP と UDP もあります。 SMTP (まだ電子メールを送信していますよね?) と LDAP については言うまでもありません。 SSL と TLS についてはどうでしょうか? SSL をあらゆる場所で、つまりあらゆる場所で利用することへの注目 (および緊急性) が高まる中、アプリケーション プロキシが SSL/TLS に対応し、しかも非常に流暢に通信することがさらに重要になっています。 そうしないと、パフォーマンス要件が満たされない可能性があります。
アプリ プロキシは、セキュリティとパフォーマンスの課題に対処し、自動化とオーケストレーションによって運用コストを削減し、一般消費者と企業顧客の両方に最適なアプリ エクスペリエンスを確保するために、最新のデータ センターに必要なプラットフォームを提供できます。 しかし、アプリが取り残されないようにするには、プログラミング性、パフォーマンス、プロトコル サポートを備えた完全なアプリ プロキシである必要があります。