リバースプロキシ
クライアントとサーバの間に立ち、要求を中継するサーバ。
クライアント → [リバースプロキシ] → アプリサーバ 1
→ アプリサーバ 2正引きプロキシとの違い#
| フォワードプロキシ | リバースプロキシ | |
|---|---|---|
| 誰のために立つか | クライアント側 | サーバ側 |
| 隠すもの | クライアントの身元 | サーバの構成 |
| 例 | 社内プロキシ、VPN | nginx、ALB、Cloudflare |
役割#
| 役割 | 内容 |
|---|---|
| 負荷分散 | 複数のサーバへ振り分ける |
| TLS 終端 | 暗号化・復号をここで行う |
| キャッシュ | 静的資源を返す |
| 圧縮 | gzip / brotli |
| ルーティング | パスやホストで振り分ける |
| 保護 | レート制限、WAF、DDoS 緩和 |
| ヘルスチェック | 異常なサーバを外す |
アプリケーションから横断的な関心事を切り離せるのが本質。 TLS も圧縮もアプリで書かなくてよくなる。
負荷分散の方式#
| 方式 | 内容 |
|---|---|
| ラウンドロビン | 順番に |
| 最少接続 | 接続数が少ないところへ |
| IP ハッシュ | 同じ client は同じサーバへ |
| 重み付き | 性能差を反映する |
セッションをサーバのメモリに持つと、 同じサーバに送り続ける必要が生じる（sticky session）。 これは水平スケールを難しくするので、 セッションを外部に出す方がよい。
気をつける点#
X-Forwarded-For 元のクライアント IP
X-Forwarded-Proto 元のスキーム（http/https）TLS 終端をプロキシで行うと、 アプリから見た接続は HTTP になる。 これらのヘッダを見ないと、 リダイレクトが http に落ちるといった不具合が起きる。
同時に、これらのヘッダは偽装できるので、 信頼するプロキシからのものだけを採用する設定が要る。
参考文献#
- nginx documentation. https://nginx.org/en/docs/
- Roy T. Fielding, Mark Nottingham, Julian Reschke (eds.). HTTP Semantics. RFC 9110, 2022. https://doi.org/10.17487/RFC9110
- Betsy Beyer et al. (eds.). Site Reliability Engineering. O’Reilly, 2016.（全文公開） https://sre.google/sre-book/table-of-contents/