リバース プロキシとは何ですか? どのように機能しますか?

リバース プロキシは、システム管理者のツールボックスにある便利なツールです。負荷分散、DDOS 保護など、多くの用途があります。

リバース プロキシとは

フォワード プロキシと呼ばれる通常のプロキシ サーバーは、ユーザーの接続がルーティングされるサーバーです。多くの点で、インターネット接続の前にあるシンプルな VPN のようなものです. VPN はこの一般的な例ですが、特定のコンテンツへのアクセスをブロックできる学校のファイアウォールなども含まれます。

リバース プロキシの動作は少し異なります。これは、システム管理者が使用する内部ツールです。コンテンツを提供する Web サイトに直接接続する代わりに、NGINX などのリバース プロキシを中間に置くことができます。ユーザーからリクエストを受け取ると、そのリクエストを最終サーバーに転送または「プロキシ」します。このサーバーは、リクエストに応答するサーバーになるため、「オリジン サーバー」と呼ばれます。

ユーザーは、VPN やファイアウォールなどのフォワード プロキシ経由でルーティングされているかどうかを知っている可能性がありますが、リバース プロキシは内部ツールです。ユーザーが知る限り、ユーザーは Web サイトに接続するだけです。リバース プロキシの背後にあるものはすべて隠され、これには多くの利点もあります。

ただし、この効果は逆にも発生します。オリジン サーバーにはユーザーへの直接接続がなく、リバース プロキシの IP アドレスからの一連のリクエストのみが表示されます。これは問題になる可能性がありますが、NGINX などのほとんどのプロキシ サービス  X-Forwarded-For はリクエストにタイプ ヘッダーを追加します。これらのヘッダーは、オリジン サーバーにクライアントの実際の IP アドレスを通知します。

リバース プロキシは何に使用されますか?

リバース プロキシの概念は非常に単純ですが、予想外の多くのユース ケースで驚くほど便利なツールであることが証明されています。

負荷分散

リバース プロキシの主な利点の 1 つは、その軽さです。リクエストを転送するだけなので、多くの処理を行う必要はありません。データベース クエリを実行する必要がある場合は特にそうです。

これは、多くの場合、ボトルネックがオリジン サーバーであることを意味しますが、その前にリバース プロキシがあれば、簡単に複数のオリジン サーバーを持つことができます。たとえば、プロキシは要求の 50% を 1 つのサーバーに送信し、50% を別のサーバーに送信して、Web サイトの帯域幅を 2 ​​倍にすることができます。HAProxy などのサービスは、これが得意です。

これは非常に一般的な使用例であり、アマゾン ウェブ サービス (AWS) などのほとんどのクラウド プロバイダーは負荷分散をサービスとして提供しているため、自分で設定する手間が省けます。クラウドの自動化により、トラフィックに基づいてソース サーバーの数を自動的にスケーリングすることもできます。これは「自動スケーリング」と呼ばれる機能です。

AWS の Elastic Load Balancer のようなロード バランサーは、ソース サーバーがダウンしたときに自動的に再構成するように構成できます。これらはすべて、内部のリバース プロキシによって可能になります。

キャッシング

リバース プロキシはオリジン サーバーよりもはるかに高速に応答することが多いため、キャッシュと呼ばれる手法を使用して、共有ルートでの要求を高速化することがよくあります。キャッシングとは、ページ データがリバース プロキシ サーバーに保存され、数秒/分ごとに 1 回だけオリジン サーバーから要求される場合です。これにより、ソース サーバーの負荷が大幅に軽減されます。

たとえば、あなたが現在読んでいるこの記事は、記事のコンテンツとメタデータを取得するために SQL データベースにアクセスする必要がある WordPress によって提供されました。ページが実際に変更されないことを考えると、ページを更新するたびにこれを行うのは無駄です。こうすることで、このルートをキャッシュすることができ、リバース プロキシは、WordPress に再び迷惑をかけずに、最後の応答を次のユーザーに送信するだけです。

コンテンツをキャッシュするリバース プロキシ サーバーの専用ネットワークは、コンテンツ配信ネットワークまたは CDN と呼ばれます。CloudFlareやFastlyなどの CDNは、大規模な Web サイトでグローバル配信を高速化するために非常に一般的に使用されています。コンテンツをキャッシュする世界中のサーバーは「エッジ ノード」と呼ばれ、それらの数が多いとサイトが非常に高速になります。

ネットワークのセキュリティとプライバシー

ユーザーはリバース プロキシの背後にあるものを知らないため、オリジン サーバーを直接攻撃することは容易ではありません。実際、リバース プロキシは通常、プライベート サブネット上のオリジン サーバーで使用されます。つまり、外部インターネットへの着信接続がまったくありません。

これにより、ネットワーク構成がプライベートに保たれます。あいまいさによるセキュリティは信頼できませんが、攻撃にさらされるよりはましです。

この固有の信頼は、ネットワークを計画するときにも役立ちます。たとえば、データベースと対話する API サーバーはリバース プロキシのようなものです。データベースは、プライベート サブネット上の API サーバーを信頼できることを認識しており、API サーバーはデータベースのファイアウォールとして機能し、有効な接続のみを許可します。

カスタマイズ可能なインターフェース

NGINX のようなリバース プロキシの利点の 1 つは、セットアップが簡単なことです。これらのサービスへのユーザー アクセスを構成するためだけに、それらを他のサービスの前に置くと便利なことがよくあります。

たとえば、NGINX は特定のルートへのリクエストを制限できます。これにより、攻撃者が単一の IP アドレスからオリジン サーバーに何千ものリクエストを作成するのを防ぐことができます。DDOS 攻撃を阻止するわけではありませんが、これは良いことです。

NGINX は、カスタムの「サーバー」ブロックを使用して、複数のドメイン名からトラフィックをリダイレクトすることもできます。たとえば、リクエストはexample.com オリジン サーバーに送信api.example.com されますが、カスタム API サーバーやfiles.example.com ファイル ストレージなどに送信されます。各サーバーは、独自の構成とルールを持つことができます。

NGINX は、一元化された HTTPS 証明書やヘッダー構成など、既存のオリジン サーバーに追加機能を追加することもできます。

そのサービスのコンテンツを提供するためだけに、別のローカル サービスと同じマシンに NGINX があると便利な場合があります。たとえば、ASP.NET Web API は、Kestrel と呼ばれる内部 Web サーバーを使用します。これは応答性に優れていますが、それ以上のものではありません。プライベート ポートで Kestrel を実行し、NGINX をカスタム リバース プロキシとして使用することは非常に一般的です。

集中ロギング

非常にシンプルですが、ほとんどのトラフィックが 1 つのサービスを通過するため、ログを簡単に確認できます。NGINX アクセス ログには、トラフィックに関する有用な情報が多数含まれており、Google アナリティクスなどのサービスよりも優れているわけではありませんが、有益な情報です。