コンテンツにスキップ

【比較】ロードバランサーとリバースプロキシの違い

Webシステムの可用性やパフォーマンスを向上させるために重要な役割を果たす「ロードバランサー」と「リバースプロキシ」。この2つは、クライアントとサーバーの間に配置されるという点で共通しており、しばしば同じソフトウェア（例: Nginx, HAProxy）が両方の機能を提供するため混同されがちです。しかし、その主目的には明確な違いがあります。

概要

項目 ロードバランサー (Load Balancer) リバースプロキシ (Reverse Proxy)
主目的 負荷分散 リクエストの中継・集約
役割 複数のサーバーにトラフィックを振り分ける 特定のサーバー群の唯一の窓口となる
主な関心事 サーバーの稼働状況、応答時間、負荷 URLのパス、リクエスト内容、セキュリティ
主な機能 負荷分散、ヘルスチェック、SSLアクセラレーション リクエストルーティング、SSL終端、キャッシュ、セキュリティ対策
構成 1台のロードバランサーが複数のサーバーを束ねる 1台のリバースプロキシが1つ以上のサーバーの代理となる
例えるなら 人気飲食店の「受付・案内係」 特定の会社の「総合受付」や「代表電話」

一言で言うと、ロードバランサーは「複数のサーバーに仕事をうまく割り振る」のが専門であり、リバースプロキシは「サーバーの代わりにリクエストを受け取り、適切な場所に繋ぐ」のが専門です。リバースプロキシが持つ機能の一つとして、負荷分散機能が含まれることもあります。

詳細比較

1. ロードバランサー (Load Balancer)

ロードバランサーの第一の目的は、その名の通り「負荷（Load）」を「分散（Balance）」させることです。Webサイトへのアクセスが集中すると、1台のサーバーだけでは処理しきれなくなり、レスポンスが遅延したり、最悪の場合はサーバーがダウンしたりします。これを防ぐため、ロードバランサーは受け取ったリクエストを、複数のバックエンドサーバーに効率的に振り分けます。

主な機能と役割

  • 負荷分散: ラウンドロビン、最小コネクション数、IPハッシュなど、様々なアルゴリズムを用いて、各サーバーに均等（または最適）にリクエストを分配します。
  • ヘルスチェック: 定期的にバックエンドサーバーの稼働状況を監視します。もしサーバーが応答しない、あるいは異常な応答を返した場合、そのサーバーを振り分け対象から一時的に外し、正常なサーバーにのみリクエストを送るようにします（冗長化・可用性の向上）。
  • SSLアクセラレーション: SSL/TLSの暗号化・復号処理をロードバランサーが肩代わりし、バックエンドサーバーの負荷を軽減します。
  • セッション維持（パーシステンス）: 特定のユーザーからのリクエストを、常に同じサーバーに送るように制御します。ショッピングカート機能などで必要になります。

ロードバランサーは、システムのスケールアウト（サーバー増設による性能向上）と可用性の確保に不可欠な技術です。

2. リバースプロキシ (Reverse Proxy)

リバースプロキシは、不特定多数のクライアントからのリクエストを一旦受け取り、それをバックエンドの適切なサーバーに中継します。クライアントからは、リバースプロキシ自体がコンテンツを提供しているように見え、背後にある実際のサーバーの存在は隠蔽されます。

主な機能と役割

  • リクエストルーティング: URLのパス（例: /api/, /images/）などに応じて、リクエストを異なるサーバー（APIサーバー、画像サーバーなど）に振り分けます。マイクロサービスアーキテクチャで重要な役割を果たします。
  • SSL終端: クライアントとの通信を暗号化（HTTPS）し、リバースプロキシとバックエンドサーバー間は暗号化しない（HTTP）構成にすることで、証明書管理を一元化し、バックエンドサーバーの負荷を軽減します。
  • キャッシュ: 画像やCSSなどの静的コンテンツや、頻繁にアクセスされる動的コンテンツを一時的に保存（キャッシュ）し、バックエンドサーバーに問い合わせることなく高速に応答します。
  • セキュリティの向上: バックエンドサーバーのIPアドレスや構成を外部から隠蔽し、不正なリクエストをフィルタリングするWAF（Web Application Firewall）のような役割を担うことで、セキュリティを強化します。
  • 圧縮: レスポンスボディを圧縮して、クライアントへの転送量を削減します。

リバースプロキシは、システムの構成を柔軟にし、パフォーマンスとセキュリティを向上させる多機能な中継役です。

よくある誤解

  • 「ロードバランサーとリバースプロキシは別物なので片方しか使えない」は誤り。 RFC 9110 はサーバー側で受ける中継者を gateway（＝reverse proxy）と定義し、NGINX 公式ドキュメントも「リバースプロキシの一般的な用途の一つが負荷分散」と説明しています。実際 Nginx・HAProxy・Envoy のような同じ製品が両機能を兼ねることが多く、対立概念ではなく主目的が違うだけで重なり合う関係です。
  • 「リバースプロキシ＝負荷分散装置」は不正確。 負荷分散はリバースプロキシが持ちうる機能の一つにすぎません。MDN もリバースプロキシの用途として負荷分散・キャッシュ・圧縮を並べており、URL ルーティング・SSL 終端・バックエンド隠蔽といった中継・集約こそが本来の役割です。サーバー 1 台構成でもキャッシュや SSL 終端目的でリバースプロキシは有用です。
  • 「ロードバランサーは L4（トランスポート層）専用」は誤解。 ロードバランサーには L4（IP/ポート単位で振り分け）と L7（HTTP のパスやヘッダを見て振り分け）の両方があります。L7 ロードバランサーはリバースプロキシとして HTTP を解釈して動作しており、層で機能が固定されるわけではありません。
  • 「SSL を終端すればバックエンドの暗号化は不要」は条件付き。 SSL/TLS 終端は証明書管理を一元化しバックエンド負荷を下げますが、終端から先（プロキシ〜バックエンド間）が平文になります。同一信頼境界内なら許容されますが、ゼロトラスト要件では再暗号化（mTLS 等）が必要で、「終端＝以降は暗号化不要」と一律に断じるのは誤りです。

実務での選び分け

  • ロードバランサーは負荷分散が主目的。
  • リバースプロキシはリクエストの中継が主目的であり、その過程でキャッシュやURLルーティングなど多くの付加機能を提供します。

実際には、多くのロードバランサーはリバースプロキシとして機能し、多くのリバースプロキシは負荷分散機能を持っています。

  • シンプルなWebサイトで、サーバー1台の負荷を軽減したい → リバースプロキシを導入し、キャッシュを活用する。
  • アクセスが増えてきたので、Webサーバーを複数台に増やして可用性を高めたい → ロードバランサーを導入し、トラフィックを分散させる。
  • 複数のサービス（API、Web、画像配信など）を異なるサーバーで運用している → リバースプロキシを導入し、URLパスに基づいて各サーバーにルーティングする。
  • 判断軸: 「複数サーバーへ均等に仕事を割り振りたい（＝可用性・スケールアウト）」のか「サーバーの代理として受け、中継・キャッシュ・隠蔽したい（＝構成の柔軟性・セキュリティ）」のかで主目的を見極める。代理の向き（クライアント側かサーバー側か）やゲートウェイ概念の整理はプロキシとゲートウェイの違いを参照。

現代のWebシステムでは、これらを組み合わせて利用するのが一般的です。例えば、外部からのリクエストをまずロードバランサーで受け、それを複数のリバースプロキシサーバーに分散し、各リバースプロキシがさらにバックエンドのアプリケーションサーバーにリクエストをルーティングする、といった多段構成も珍しくありません。

ひとことまとめ

ロードバランサーは「複数サーバーへ負荷をうまく割り振る」のが主目的、リバースプロキシは「サーバーの代理として受け取り中継・集約する」のが主目的で、両者は対立概念ではなく機能が重なり合います。同じ製品（Nginx, HAProxy, Envoy）が両方を兼ねることが多く、構成では主目的で役割を整理して組み合わせます。

出典・参考