LASSIC Media らしくメディア
リバースプロキシとは｜前段でリクエストを捌く
複数のサーバーでアプリケーションを動かす企業では、利用者からのアクセスをどこで受け止めるかが、システムの安定稼働を左右します。クラウドやコンテナの活用が進み、機能ごとにサーバーを分ける構成も一般的です。公開する窓口が増えるほど、公開設定やTLS証明書の更新対象、監視すべき対象も比例して膨らんでいきます。この負担は、発注担当者やプロジェクトマネージャーが見落としやすいところでしょう。
こうした課題に対応する仕組みの一つが、リバースプロキシです。この記事では、リバースプロキシとは何か、何をしてくれるのか、直接公開との違いを整理します。あわせて、代表的な使われ方と、発注時に押さえておきたい注意点までを順番に見ていきましょう。なお、リバースプロキシは負荷分散の役割も担えますが、その仕組み自体は別記事のロードバランサで扱う範囲です。本記事では、利用者とサーバーの間に立ち、リクエストの受け口を一本化して共通処理を担う役割に絞って解説します。
目次
この記事のポイント
- リバースプロキシは、利用者とサーバーの間に立ち、リクエストの受け口を一本化して共通処理を担う中継役のサーバーです。
- TLS(HTTPS)の終端や静的コンテンツのキャッシュ、URLに応じた振り分けなど、複数の役割をまとめて引き受けます。
- 導入にあたっては単一障害点にしない構成やTLS証明書の運用体制など、発注段階で確認しておきたい論点があります。
リバースプロキシとは
リバースプロキシとは、利用者からのリクエストを、後ろにあるサーバーの手前でいったん受け取り、適切なサーバーへ中継したり、共通の処理をまとめて担ったりする中継役のサーバーです。
似た言葉に、フォワードプロキシがあります。フォワードプロキシは利用者側に置かれ、社内の端末から外部のサイトへアクセスする際に、利用者に代わって通信を中継する仕組みです*1。対してリバースプロキシは、サーバー側に置かれ、外部からのアクセスを一手に受け止める点で役割が異なります*1。フォワードプロキシが利用者の素性を隠す仕組みだとすれば、リバースプロキシはサーバー側の素性を隠す仕組みだと言えるでしょう*1。
「リバース(逆)」という名前は、フォワードプロキシと逆方向の役割を持つことに由来します*1。フォワードプロキシは利用者の代わりに動きますが、リバースプロキシはサーバーの代わりに動く、という対比です。この向きの違いを押さえておくと、両者を混同しにくくなります。Apache HTTPサーバーの公式ドキュメントでは、リバースプロキシを「ゲートウェイ」とも呼んでおり、名称は製品によって異なる場合があります*4。呼び方は違っても、指している役割はおおむね共通していると考えてよいでしょう。
リバースプロキシは、特定のサーバー宛てのリクエストが常に通過するように設置されます*3。この点で、不特定多数の宛先へ向かう一般的なプロキシとは、役割が逆になっています*3。利用者からは、あたかもリバースプロキシ自体が目的のサーバーであるかのように見え、背後に何台のサーバーが存在するかは意識させません*4。
複数のサーバーでシステムを構成する背景には、機能ごとに開発チームや更新頻度を分けたい、という運用上の事情があります。会員機能・決済機能・検索機能のように役割を分けておけば、一部の機能だけを個別に更新することもできるでしょう。一方で、サーバーの台数が増えるほど、利用者からの入り口をどう整理するかという課題が表面化します。この課題への答えの一つが、次章で見る受け口の一本化という役割です。
オフィスの受付に例えると、イメージがつかみやすくなります。来訪者が各部署のドアを直接ノックするのではなく、まず受付で用件を伝え、受付担当者が適切な部署へ案内する、という流れです。リバースプロキシは、この受付担当者の役割をシステムの世界で担っていると考えられます。来訪者(利用者)から見える窓口は1つのままで、案内先(アプリサーバー)がいくつあっても対応できる点が、共通しているところでしょう。
受け口の一本化からアクセス制限まで、6つの役割
リバースプロキシがサーバー側の入り口に立つことで、次のような役割を一手に引き受けられます。まずは、利用者からのリクエストが実際にどう流れるのかを、図で確認してみましょう。
図のとおり、利用者から見える宛先は1つですが、内部では複数のアプリサーバーへ振り分けられています。この仕組みが担う代表的な役割を、表で整理しました。
| 役割 | 何をするか | 発注側にとっての利点 |
|---|---|---|
| 受け口の一本化 | 複数のアプリサーバーへの入り口を1つのドメイン・IPに集約します。 | 公開設定やDNSを管理する箇所が減ります。 |
| TLS(HTTPS)の終端 | 通信の暗号化・復号をまとめて1か所で処理します。 | 証明書の管理・更新作業を集約できます。 |
| 静的コンテンツのキャッシュ | 画像やCSSなど変化の少ないファイルを手前で保持します。 | アプリサーバーへの問い合わせを減らせます。 |
| URLに応じた振り分け | パスやドメインごとに転送先のサーバーを出し分けます。 | サービスを増やしても公開の入口を増やさずに済みます。 |
| 負荷分散 | 複数台のサーバーへリクエストを分散します(詳細は別記事のロードバランサで解説)。 | 特定の1台にアクセスが集中する事態を避けやすくなります。 |
| アクセス制限 | 特定IPの遮断や認証をまとめて設定します。 | アプリサーバーごとに個別実装する手間が省けます。 |
たとえば、会員機能・決済機能・検索機能をそれぞれ別のサーバーで動かしているケースを考えてみましょう。リバースプロキシがなければ、利用者は複数の宛先を使い分け、公開担当者は複数枚のTLS証明書を管理することになります。リバースプロキシを前段に置けば、利用者から見える宛先は1つのままで、内部の振り分けだけで対応できるのです。新しい機能を追加するときも、公開の入口を新設せず、振り分けの設定を1か所足すだけで済むでしょう。
監視の観点でも、この一本化が役立ちます。アクセスログをリバースプロキシの1か所に集約しておけば、全体のアクセス傾向や異常な増加を、まとめて確認しやすくなるからです。アプリサーバーごとにログを見比べる手間が減り、障害の予兆にも気づきやすくなります。運用担当者を増やさずに監視の目を行き届かせたい場合、この集約効果は見逃せないところです。
静的コンテンツのキャッシュも、応答を速くする工夫の一つです。画像やCSSのように内容がほとんど変わらないファイルは、いったんリバースプロキシ側に保持しておき、次回以降の要求にはそこから直接返せます*2。アプリサーバー側は、変化のあるコンテンツの処理に力を割きやすくなるでしょう。どこまでの期間キャッシュを保持するかは、コンテンツの更新頻度に応じて調整する運用が一般的です。
表に挙げた役割のうち、負荷分散という切り口は、別記事のロードバランサでその仕組みを詳しく取り上げています。本記事では、受け口の一本化と共通処理という土台の部分に絞って、もう少し掘り下げていきましょう。
アプリサーバーを直接公開しない理由
アプリサーバーをインターネットに直接公開すると、外部からIPアドレスや稼働状況が見えやすくなります。見えやすい情報は、攻撃の足がかりに使われる恐れを高めます。前段にリバースプロキシを置けば、公開されるのはリバースプロキシのアドレスだけです*1。結果として、背後の構成は利用者から見えにくくなるでしょう。
認証やログ収集、ヘッダーの付与といった共通処理があります。これらをアプリサーバーごとに個別実装するのではなく、リバースプロキシの1か所にまとめられるのです*4。サーバーを増やすたびに同じ設定を繰り返す手間が減り、変更時の抜け漏れも起きにくくなるはずです。
直接公開した状態でサーバーを追加・入れ替えする場合、DNSやTLS証明書の設定をサーバーごとに見直す作業が発生します。前段に中継役を置いておけば、こうした変更をリバースプロキシ側だけで完結させやすくなるでしょう。結果として、公開範囲を絞り込みながら運用できる構成に近づきます。
直接公開の構成でセキュリティ更新する場合、対象になるサーバーの台数分だけ作業が発生します。前段にリバースプロキシを立てておけば、共通のセキュリティ設定を1か所に集約でき、対応漏れを防ぎやすくなるでしょう。運用担当者が確認すべき箇所を絞り込める点は、日々の保守負担にも直結します。サーバーの台数が増える計画があるほど、この差は運用フェーズで大きく効いてくるはずです。
アクセス制限や認証をリバースプロキシの手前でまとめて行う構成は、Webアプリケーションファイアウォール(WAF。悪意ある通信のパターンを検知して遮断する仕組み)などのセキュリティ機能を追加する際の土台にもなります*1。個々のアプリサーバーに手を入れずに、前段でまとめて防御を強化できる点は、運用上の利点と言えるでしょう。追加のセキュリティ要件が発生した場合も、リバースプロキシの設定を見直すところから検討を始められます。
ここまで見てきたように、直接公開との違いは、単に「見えにくくする」ことだけにとどまりません。共通処理の集約先を1つに定めることで、変更・監視・防御のいずれについても、対応する場所を絞り込めるのが強みです。次章では、この役割を実際に担う代表的な製品を確認していきましょう。
Nginx・Apache・Traefikなど代表的な使われ方
リバースプロキシの機能は、Webサーバーソフトウェアに組み込まれている場合がほとんどです。Nginxは、リクエストを指定した別サーバーへ送り、その応答を受け取って利用者へ返す動きを標準機能として備えています*2。複数サーバーへ負荷を分散する用途でも、広く使われています*2。
Apache HTTPサーバーも、リバースプロキシ(ゲートウェイ)として動作します*4。その際は、mod_proxyモジュールのProxyPassディレクティブを使って設定するのが一般的です*4。この構成では、利用者からは通常のWebサーバーと変わらないように見えます。クライアント側で特別な設定をする必要はありません*4。
Traefikのように、コンテナやKubernetes環境向けに設計され、バックエンドの増減に合わせて転送先を自動で切り替える製品もあります。CDN(コンテンツデリバリーネットワーク。世界各地に配置した拠点からコンテンツを配信する仕組み)や、APIゲートウェイという製品もあるところです。どちらも、利用者との間に立って共通処理を担うという意味では、広い意味でリバースプロキシの仲間と言えるでしょう*1。代表的な製品と位置づけを、表で整理します。
| 製品・仕組み | 位置づけ | 得意な点 |
|---|---|---|
| Nginx | Webサーバー内蔵のリバースプロキシ機能 | 高い処理性能を活かした負荷分散 |
| Apache HTTPサーバー | mod_proxyによるゲートウェイ動作 | 既存Apache環境への組み込みやすさ |
| Traefik | コンテナ・Kubernetes向け | バックエンドの増減への自動追従 |
| CDN | 世界各地に配置した配信拠点 | 静的コンテンツの地理的な分散配信 |
| APIゲートウェイ | API呼び出しの共通窓口 | 認証やレート制御などAPI向け処理 |
APIゲートウェイは、外部向けAPIの窓口という用途に特化して発展してきた製品群です。認証・利用量の制御・呼び出し履歴の記録など、API特有の共通処理をまとめて担う点に強みがあります。Webページの配信を主眼に置くリバースプロキシと、API呼び出しを主眼に置くAPIゲートウェイとでは、想定する利用者やログの見方も変わってくるでしょう。自社のシステムがAPI中心か、Webページ中心かによって、選ぶべき製品の重心も変わります。
それぞれの導入・設定の詳細は製品ごとに異なるため、個別の解説は別の記事に譲ります。発注時に製品を比較する際は、次のような観点を確認しておくと、選定の目安になるでしょう。
- 自社の環境(オンプレミス・クラウド・コンテナ)に合う製品かどうか
- 公式ドキュメントや設定例が整備され、追いやすいかどうか
- 商用サポートの有無と、問い合わせ先が明確かどうか
- 社内やパートナー企業に、運用経験を持つ人材がいるかどうか
- バージョンアップの頻度と、既存の設定を引き継げるかどうか
製品選びに迷う場合は、まず自社と近い規模・構成の事例が、各製品の公式サイトや公式ドキュメントで紹介されていないかを確認するとよいでしょう。実績のある組み合わせから検討を始めれば、設定でつまずく場面を減らせるはずです。
単一障害点や証明書運用など発注時の注意点
リバースプロキシそのものを一から作り込む場面は、実のところ多くありません。ほとんどは、既存のWebサーバーソフトウェアやサービスを選び、正しく設定して活かす形が中心です。発注や設計の段階で意識しておきたい点を、次に挙げていきましょう。
単一障害点にしない構成を確認する
すべての通信がリバースプロキシを経由する構成では、そのリバースプロキシ自体が停止すると、接続に影響が及びます。背後のアプリサーバーが正常に動いていても、利用者からは接続できなくなるのです。冗長化した構成にするか、稼働状況を継続的に監視する体制になっているかを、発注段階で確認しておくと判断材料になります。1台構成のまま本番運用へ進めてしまうと、後から冗長化を組み込む作業がかえって大掛かりになる場合もあるでしょう。
TLS証明書の管理体制を決める
TLSの終端をリバースプロキシに集約すると、証明書の発行・更新作業も1か所にまとめられます。一方で、その1か所の設定に不備があると、複数のサービスへ影響が及ぶ点には注意が必要です。誰が証明書の更新を担当し、期限をどう管理するかは、契約の段階で明確にしておきます。更新の自動化が可能な仕組みかどうかも、あわせて確認しておきたいところです。証明書の有効期限が切れると、利用者のブラウザに警告が表示され、サービスの信頼性を損ないかねません。
前段が1段増える分の運用を見込む
リバースプロキシを挟む構成は、通信の経路が1段増えることを意味します。設定ファイルやログの確認箇所は、アプリサーバーとリバースプロキシの両方に分かれるのです。そのため、障害発生時の切り分け手順や、監視対象をどちらに置くかを、あらかじめ整理しておく必要があります。導入して終わりではなく、運用に組み込む前提で計画するとよいでしょう。設定変更時のレビュー体制や、変更を反映する手順も、事前に決めておくと判断の助けになります。
監査ログの集約を検討する
だれが、いつ、どの経路でアクセスしたかを追跡できるようにしておくことは、システムの信頼性を保つうえで欠かせません。リバースプロキシにアクセスログを集約しておけば、複数のアプリサーバーにまたがる調査でも、まず1か所を確認すれば全体像をつかみやすくなります。監査対応や障害調査の場面を想定し、ログの保存期間や参照権限をどう設計するかも、発注段階で確認しておきたい論点でしょう。
ここまで挙げた4つの論点は、いずれも導入後に見直そうとすると手戻りが大きくなりがちです。要件定義書や設計書に、冗長化の方針・証明書の管理者・運用体制・ログの扱いを明記しておくと、開発会社とのレビューの場でも認識のずれを防ぎやすくなります。契約前の打ち合わせで、これらの項目を一つずつ確認しておくとよいでしょう。すでに直接公開の構成で運用しているシステムを見直す場合も、考え方は変わりません。現状の課題を洗い出したうえで、どの役割をリバースプロキシに担わせるかを、段階的に検討していく進め方が現実的です。
まとめ
本稿では、リバースプロキシの役割を、受け口の一本化と共通処理という観点に絞って整理しました。要点を3つに集約すると、次のとおりです。第一に、リバースプロキシは利用者とサーバーの間に立つ中継役であり、フォワードプロキシとは逆方向の役割を持ちます。第二に、TLS終端やキャッシュ、振り分けなど複数の役割をまとめて引き受け、アプリサーバーを直接公開せずに済む構成をつくれるところです。第三に、導入にあたっては単一障害点や証明書運用、運用負荷の増加を発注段階で確認しておく必要があります。負荷分散の仕組みそのものを深掘りしたい場合は、別記事のロードバランサもあわせて参照してください。
- リバースプロキシとは、利用者とサーバーの間に立ち、リクエストを中継したり共通処理をまとめて担ったりするサーバーである。
- フォワードプロキシが利用者側に立つのに対し、リバースプロキシはサーバー側に立ち、外部からのアクセスを一手に受け止める。
- 受け口の一本化・TLS終端・キャッシュ・URL振り分け・負荷分散・アクセス制限など、複数の役割を担える。
- アプリサーバーを直接公開せず前段に置くことで、構成を見えにくくし、共通処理を1か所に集約できる。
- 導入にあたっては、単一障害点にしない構成やTLS証明書の運用体制、前段が増える分の運用を発注段階で確認しておきたい。
よくある質問
リバースプロキシとロードバランサの違いは何ですか。
リバースプロキシは、利用者とサーバーの間に立ち、受け口の一本化や共通処理をまとめて担う中継役です。負荷分散はリバースプロキシが持つ機能の一つで、ロードバランサはこの負荷分散の役割に特化した仕組みを指します*3。実際の製品では、1台のソフトウェアがリバースプロキシと負荷分散の両方を兼ねる場合も少なくありません。役割の違いを押さえたうえで、自社の要件に必要な機能を確認するとよいでしょう。負荷分散の具体的な方式については、別記事のロードバランサで解説しています。発注時にどちらの用語を使うかによって、開発会社との認識がずれることもあるため、事前にすり合わせておくとよいでしょう。
リバースプロキシを導入すれば、アプリサーバーの構成は隠せますか。
背後のサーバー台数やIPアドレスといった情報を、利用者から見えにくくすることはできます*1。ただし、構成を隠すこと自体が目的ではなく、公開範囲を絞り込み、共通の処理を1か所にまとめることが本来のねらいです。設定に不備があれば内部構成が推測できてしまう場合もあるため、リバースプロキシ側の設定も見直しの対象に含める必要があります。定期的な設定の棚卸しも、あわせて計画しておきたいところです。エラーページの内容によっては、内部の情報が意図せず表示される場合もあるため、表示内容の確認もあわせて行うとよいでしょう。
TLS証明書はリバースプロキシとアプリサーバーのどちらで管理しますか。
一般的な構成では、TLSの終端をリバースプロキシに集約し、証明書の発行・更新もそこでまとめて管理します*3。アプリサーバー側は暗号化されていない通信を受け取るだけで済むため、証明書を個別に持つ必要がなくなります。誰が更新作業を担当し、期限をどう追うかは、契約の段階で決めておくと運用がぶれません。証明書の自動更新に対応した仕組みかどうかも、確認しておくとよいでしょう。更新を人手で行う運用のままにしておくと、失効に気づかず利用者に警告画面が表示される事態にもつながりかねません。
リバースプロキシ自体が止まると、どうなりますか。
すべての通信がリバースプロキシを経由する構成では、そのリバースプロキシが停止したとき、背後のアプリサーバーが動いていても接続できなくなります。この単一障害点のリスクを抑えるには、リバースプロキシ自体を冗長化するか、稼働状況を継続的に監視する体制づくりが欠かせないのです。導入時の設計段階で、この点を確認しておくことが欠かせません。復旧手順をあらかじめ整理しておくことも、あわせて検討しておくとよいでしょう。停止に気づくまでの時間が長いほど、利用者への影響も広がるため、監視の間隔についても発注時に確認しておきたいところです。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、リバースプロキシを含むインフラ構成の設計から実装、公開済みシステムの見直しまでを一貫して支援する体制です。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。前段の中継構成やTLS終端の設計でお困りの際も、ご相談いただけます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
出典
- MDN Web Docs「Proxy servers and tunneling」
- NGINX公式ドキュメント「NGINX Reverse Proxy」
- Wikipedia日本語版「リバースプロキシ」
- Apache HTTP Server公式ドキュメント「mod_proxy」
