バックエンドサーバーの前段に何かを置く構成は、規模を問わず広く採用されています。しかし「リバースプロキシ」「ロードバランサー」「APIゲートウェイ」の3つは混同されやすく、実際の設計では役割の違いを把握してから選定しないと、後から構成を大きく変える羽目になります。
まずリバースプロキシが解決する問題を整理する
リバースプロキシとは、クライアントとバックエンドサーバーの間に置かれる中継サーバーのことです。クライアントはリバースプロキシのアドレスに接続し、プロキシが実際のバックエンドへリクエストを転送します。バックエンドのIPアドレスはDNSに公開されないため、直接攻撃を受けにくくなります。
リバースプロキシが担う主な役割は4つです。
- SSLターミネーション: TLSハンドシェイク（暗号化通信を開始する手続き）をプロキシで処理し、バックエンドへはHTTPで転送することでCPU負荷を下げる
- キャッシュ: 同じレスポンスを繰り返し返すAPIであれば、プロキシがメモリに保持してバックエンドへのリクエストを削減する
- 圧縮: GzipやBrotliでレスポンスを圧縮し、帯域を節約する
- セキュリティ: レートリミット（単位時間あたりのリクエスト数制限）やヘッダー検証をプロキシ層で処理する
NginxやHAProxy、Caddy、Envoyといったツールがリバースプロキシとして広く使われています。重要なのは、これらはビジネスロジックを認識しないという点です。静的なルーティングルールに従って転送するだけで、「このユーザーは認証済みか」「このAPIはv2か」といった判断はしません。
ロードバランサーはリバースプロキシの上位互換ではない
ロードバランサーは、複数のバックエンドサーバーにトラフィックを分散させる仕組みです。単一サーバーが処理できる同時接続数やCPUには物理的な上限があるため、水平スケーリング（サーバーを横並びに増やす構成）を取る際に必要になります。
リバースプロキシとロードバランサーは「別物か、同じものか」という疑問が生じやすいですが、実際には役割の粒度が違います。リバースプロキシは「1台のバックエンドへの転送を最適化する」もので、ロードバランサーは「複数台への振り分け方を管理する」ものです。NginxやHAProxyはどちらの機能も持っているため混同されがちですが、概念としては分けて理解する方が設計の議論で役立ちます。
分散アルゴリズムにはいくつかの種類があります。ラウンドロビン（順番に振り分け）、最小接続数（現在の接続が少ないサーバーを優先）、IPハッシュ（同じクライアントを同じサーバーに固定）などがあり、アプリケーションの特性に合わせて選びます。たとえばセッション情報をメモリ上で保持するステートフルなアプリケーションでは、同じユーザーを同じサーバーに送るスティッキーセッション設定が必要になります。
ロードバランサーはまた、ヘルスチェック（バックエンドの死活監視）も担います。障害が発生したサーバーをプールから自動的に除外し、残りのサーバーへトラフィックを流し続けます。AWSのALB（Application Load Balancer）やGCPのCloud Load Balancingがこの役割をマネージドサービスとして提供しており、オンプレミスではHAProxyが長く使われています。
APIゲートウェイが必要になる局面
APIゲートウェイは、リバースプロキシやロードバランサーよりも「アプリケーション層（L7）」に踏み込んだ処理を担います。L7とは、HTTPのヘッダー・パス・ボディの内容を理解して処理できるレイヤーのことです。
具体的にAPIゲートウェイが処理する内容を挙げると、認証・認可（JWTトークンの検証やOAuthフローの処理）、APIバージョニング（/v1と/v2を異なるバックエンドへルーティング）、リクエスト変換（クライアントのリクエスト形式をバックエンドが期待する形式に変換）、レートリミット（ユーザーIDや契約プランごとに上限を設ける）などがあります。
マイクロサービス構成（機能ごとにサービスを分割したアーキテクチャ）では、APIゲートウェイが特に重要になります。たとえば注文サービス・在庫サービス・ユーザーサービスがそれぞれ独立して動いている場合、クライアントがそれぞれのエンドポイントを直接知る必要がなくなり、ゲートウェイが一元的に窓口となります。AWS API GatewayやKong、Apigee、Azure API Managementがよく使われる選択肢です。
リバースプロキシとの違いを端的に言えば、APIゲートウェイは「リクエストの意味を読んで処理を変える」のに対し、リバースプロキシは「リクエストの中身を読まずに転送する」という点です。
3つの役割を整理すると次のように位置づけられます。リバースプロキシは接続の最適化と保護、ロードバランサーは複数サーバーへの振り分けと可用性の維持、APIゲートウェイはビジネスルールに基づいたリクエスト制御、という分担です。実際の構成では、これらを重ねて使うことも珍しくありません。たとえばNginxでSSLターミネーションとキャッシュを行い、その後段にKongをAPIゲートウェイとして配置し、さらにその先でALBがバックエンドサービスへ振り分ける、という構成は現実的な選択です。
どれか1つを選ぶ問題ではなく、それぞれが解決する問題の粒度を理解した上で組み合わせを設計することが、保守性の高いシステムを作る出発点になります。