リバースプロキシとフォワードプロキシの違いは？それぞれの用途についても解説

「フォワードプロキシとリバースプロキシってのがあるらしいけど、どう違うの？」
「それぞれの用途や使い分けはどうすればいいの？」
という疑問をお持ちの方もいらっしゃると思います。

そこで今回の記事では、
・フォワードプロキシ（Forward Proxy）
・リバースプロキシ（Reverse Proxy）
これらの違いと、それぞれの用途について見ていきましょう。

フォワードプロキシとは

普通に「プロキシ」と言う場合、フォワードプロキシを指します。

LAN（ローカルエリアネットワーク）からWAN（ワイドエリアネットワーク）へと抜けるときに、クライアント（ユーザが使う端末&ブラウザ）の代理として通信を行ってくれます。

クライアントからの通信はプロキシを経由しているため、リクエストを受けるWebサーバー側から見れば、プロキシからリクエストが来ているように見えます。
そのため、実際のクライアントのIPアドレスはWebサーバ側からは見えなくすることができます。

リバースプロキシとは

リバースプロキシは「逆プロキシ」とも呼ばれます。

通常、ユーザ（クライアント）がPCやスマホなどからウェブサイトを閲覧する場合、インターネットを通して、Webサーバーにアクセスを行います。
ここで、クライアントとアクセス先サーバーが通信している間に入って、サーバーの応答を代理する役割を果たすのが「リバースプロキシ」です。

リバースプロキシの挙動は、
・クライアントに対してはWebサーバとして振る舞う
・Webサーバに対してはクライアントとして振る舞う
という動作をします。

この動作により、クライアントが直接アクセスする対象はリバースプロキシとなり、Webサーバ自体の存在は隠された状態となります。
（クライアント側から見て、サーバーの存在が直接見えないだけで、サーバーの中のデータにはリバースプロキシを経由してアクセスが可能です）

リバースプロキシの代表的な用途紹介

その１：負荷分散（サーバーロードバランシング）

サーバー1台では耐えられるかどうかわからないほど大量のアクセスが見込まれる場合に、
Webサーバーを複数用意し、リバースプロキシによって、クライアントからのリクエストを複数のWebサーバーに分散させることができます。
サーバーロードバランシングってやつですね。

Tips

サーバーロードバランシング（Server Load Balancing）とは：
サーバー（Server）の負荷(Load)の、つりあいを保つ（Balancing）ことです。
SLBと呼ばれることもあります。
ネットワーク上でのロードバランシングと言えば、
同等の機能を持つ2台以上のシステムや機器を用意しておき、それぞれの機器へと外部からの処理リクエストを振り分けることによって、耐障害性を向上させることができます。

振り分けのルールとしては、
・各装置に順番にリクエストを振り分ける

※ローカルコンピュータ内のストレージやプロセッサ、GPUなどでもロードバランシングが行われる場合がありますが、それについては割愛します。（本記事はネットワーク関連の内容であるため）

クライアント側は、分散されたサーバーを意識することなく、同じアクセス先にリクエストを送るだけでOKです。
そのおかげで、ユーザ側では、空いているサーバを選んでアクセスするような必要もなく使用できます。
（そもそも、ユーザ側からは単一のサーバーとして見えています）
サイト運営側は、クライアントからの大量のアクセスを、ユーザに面倒をかけることなく捌くことができるわけです。

負荷分散時の振り分けのルール

負荷分散時の振り分けルールには、以下のようなものがあります。

振り分け方式いろいろ

ラウンドロビン方式：
各装置（この場合はサーバー）に順番に均等に振り分ける。
一定時間ごと、またはリクエストを受けるたびに順番に切り替えて応答する方式。

最小コネクション方式：
クライアントからのリクエストが来たとき、現在の接続数が最も少ないサーバへと振り分ける方式。

最速応答時間方式：
用意しておいた複数のサーバーのうち、最も応答までの時間が早かったサーバーに、クライアントからのリクエストに対する処理を任せる方式。

負荷分散以外のメリットも

また、メリットは負荷分散だけにとどまりません。
運用スタイルによっては、サービスを一時停止せずにメンテナンスを行うことが可能となる場合があるのも、大きなメリットと言えるでしょう。
たとえば、A, B, C の3つのサーバに分散させる運用をしている場合に、
クライアントからのリクエストを振り分けの設定を変更し、サーバーCへの振り分けを停止します。
これにより、サーバーAとサーバーBだけにリクエストが送られるようになります。
そのあいだに、サーバーCのメンテナンスを行う。というような運用が可能です。

その２：異なる動作環境、フレームワーク、プラットフォームの統合

複数の機能をそれぞれ異なるサーバーで運用しながら、ユーザからのアクセス先を1つに統合することが可能です。

たとえば、
・静的Webページ
・Ruby on Rails
・PHP
の3つの機能をそれぞれ異なるサーバーで運用。これらのサーバたちとクライアントとの間にリバースプロキシを配置します。
このとき、ユーザ（クライアント側）は複数のアクセス先（この場合は3つ）を使い分ける必要はありません。
クライアント側から見れば単一のサーバーにしか見えませんので、ユーザにアクセス先を使い分けてもらうような面倒を強いることがありません。

ほかにもこんなメリットが

たとえば、
「既存のコンテンツに加えて、最新のコンテンツを追加したい。しかし、最新のコンテンツは最新のサーバーでないと動作しないのに、既存のコンテンツは最新のサーバーでは動作しない。困った」
のような場合、古いコンテンツを最新の環境で動作するように改修するのに高いコストがかかる場合があります。
そんなときも、既存のサーバーを残したまま最新のサーバーを追加し、リバースプロキシを使って両方のコンテンツを双方のサーバーに振り分けるような運用が可能です。
これにより、古いコンテンツを改修するコストがかからなくなります。

ほかにも、外部の複数のコンテンツホルダーの提供を受けてコンテンツを公開しているような場合に役立ちます。それら複数社のデータを同じサーバーに置いて管理するのは難しい（複数の会社が同じサーバ内のデータを管理するのは機密保持上問題がある）ため、
情報機密保持上のリスクを低減するためにも、別サーバで運用する方法が比較的安全です。このようなときにリバースプロキシによる振り分けが活躍します。