来客からは受付しか見えない
大きなオフィスでは、来客はまず総合受付に行きます。受付が要件を聞いて、営業、経理、サポートなど適切な部署へ案内する。来客からは受付しか見えず、奥の部署がどのフロアにあるかは知らないままです。
リバースプロキシは、この総合受付をWebに置いたものです。利用者がアクセスするのはリバースプロキシで、その後ろで用途に応じて複数のアプリやサーバーへ振り分けます。裏側のサーバーを直接公開しなくて済むので、構成を変えたり保守したりするときも、利用者に見える入口はそのままにできます。
利用者の側に立って外へ出ていく通信を取り次ぐプロキシとは、立つ位置が逆です。こちらはサーバーの側に立ち、入ってくるアクセスを受け止めます。
受付にまとめると楽になること
- 複数のアプリを、1つのドメインの下にまとめて公開できる
- HTTPS の暗号をここでほどく（終端する）ので、証明書を受付で一括管理できる
- 裏側サーバーのIPアドレスや構成を、外に見せずに済む
- メンテナンスのとき、一部の部署だけ案内先を切り替えられる
受付を挟むと見えにくくなるもの
受付を通すと、奥の部署から見た来客は、全員「受付から来た人」になります。Webでも同じで、何も設定しないと、裏側のサーバーのログには利用者ではなくリバースプロキシのアドレスが残ります。ログの分析やアクセス制限に元の利用者の情報が必要なら、受付がその情報を引き継いで渡すようにヘッダーを設定しておきます。
奥の部署が返事をしないときの扱いも、先に決めておくことの一つです。どれくらい待ったら諦めるか（タイムアウト）、調子の悪い宛先をどう見分けて外すか（ヘルスチェック）。転送のルールは、パスやホストの条件を増やしすぎると誰も読めなくなるので、シンプルに保ちます。
障害のときは、受付の問題なのか、奥のアプリの問題なのかを最初に切り分けます。受付は取り次ぎ役で、アプリのバグやデータベースの遅さを直す道具ではありません。