リバース プロキシは、システム管理者のツールキットに含まれる便利なツールです。負荷分散、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 回だけオリジン サーバーから要求されることです。これにより、オリジンサーバーの負担が大幅に軽減されます。
たとえば、あなたが今読んでいるこの記事は WordPress によって提供されており、記事のコンテンツとメタデータを取得するには SQL データベースと通信する必要があります。ページが実際には変更されないことを考えると、ページを更新するたびにこれを行うのは無駄です。したがって、このルートをキャッシュすることができ、リバース プロキシは WordPress に再度迷惑をかけることなく、最後の応答を次のユーザーに送信するだけになります。
コンテンツをキャッシュするリバース プロキシの専用ネットワークは、コンテンツ配信ネットワーク (CDN) と呼ばれます。 CloudFlare や Fastly などの CDN は、グローバル配信を高速化するために大規模な Web サイトで非常に一般的に使用されています。コンテンツをキャッシュする世界中のサーバーは「エッジ ノード」と呼ばれ、これを多数配置すると、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 はリクエストへの応答には優れていますが、それ以外のことはあまり得意ではありません。 Kestrel をプライベート ポートで実行し、NGINX を構成可能なリバース プロキシとして使用するのが非常に一般的です。
集中ロギング
これは非常にシンプルですが、トラフィックのほとんどが 1 つのサービスを通過するため、ログの確認が簡単になります。 NGINX のアクセス ログには、トラフィックに関する有用な情報が数多く含まれており、Google Analytics などのサービスの機能には及びませんが、持っておくと便利な情報です。
