Nginx vs HAProxy：適切なリバースプロキシの選び方

リバースプロキシがアプリケーションにもたらすもの

リバースプロキシはアプリケーションの前に置かれ、クライアントのリクエストを最初に受け取るサーバーです。リクエストを適切なバックエンドサービス（アプリサーバー）へ転送し、応答をクライアントに返します。ユーザーはプロキシと話し、プロキシがアプリと話します。

フォワードプロキシは逆の働きをします：クライアント側の前に置かれ（例えば企業ネットワーク内）、発信リクエストをインターネットに転送し、制御やフィルタリング、匿名化を行います。

ロードバランサーはしばしばリバースプロキシとして実装されますが、特に「複数のバックエンドインスタンスにトラフィックを分配する」ことに焦点を当てています。Nginx や HAProxy を含む多くの製品はリバースプロキシとロードバランシングの両方を行えるため、用語が混同されることがあります。

チームがリバースプロキシを使う典型的な目的

多くの導入は以下の一つ以上の理由から始まります：

• TLS/SSL 終端：HTTPS を一箇所で扱い、証明書を集中管理し、必要に応じて内部サービスへは平文 HTTP を渡す。\n- ルーティング：ホスト名、パス、ヘッダー、その他ルールに基づいてトラフィックを振り分ける（例：/api を API、/ を Web アプリに）。\n- バッファリングと接続管理：遅いクライアントやアップストリームのばらつきを平滑化し、アプリ側の接続オーバーヘッドを減らし、信頼性を向上させる。\n- 保護制御：リクエスト制限、基本的なフィルタリング、安全なデフォルトを実装してアプリ到達前に防御する。

アプリの前に置かれる場所

リバースプロキシは一般的に ウェブサイト、API、マイクロサービス のフロントに置かれます—エッジ（公開インターネット）でも、サービス間の内部でも。モダンなスタックでは、Ingress ゲートウェイ、ブルー/グリーンデプロイ、HA 構成のビルディングブロックとして使われます。

本ガイドで判断できること

Nginx と HAProxy は重なる部分がありますが、重点が異なります。以下では 多数接続下の性能、ロードバランシングとヘルスチェック、プロトコル対応（HTTP/2、TCP）、TLS 機能、可観測性、そして 日常的な設定と運用 といった決定要因を比べます。

Nginx の概要：強みと典型的なユースケース

Nginx は ウェブサーバー として、また リバースプロキシ として広く使われています。多くのチームは公開サイトの配信で始め、後に TLS、ルーティング、スパイク緩和のためにアプリサーバーの前に置くようになります。

エッジで Nginx が好まれる理由

トラフィックが主に HTTP(S) で、1 つの「フロントドア」にいろいろ任せたい場合に Nginx は強みを発揮します。特に以下が得意です：

• 静的アセット（画像、CSS/JS）の効率的配信\n- パスやホストに基づく直感的な HTTP リバースプロキシ\n- バックエンド負荷を減らすための キャッシュ\n- ヘッダーの追加や正規化（例：X-Forwarded-For、セキュリティヘッダー）

コンテンツ配信とプロキシの両方をこなせるため、構成要素を少なくしたい小〜中規模の環境でよく選ばれます。

チームが頼るモジュールと機能

代表的な機能：

• TLS 終端 と証明書管理ワークフロー（リロード自動化と組み合わせることが多い）\n- 帯域を削る 圧縮（gzip / brotli はビルド次第）\n- レート制限 や基本的なリクエスト制御\n- URL のクリーンアップやマイグレーション用の リライト / リダイレクト\n- WebSocket プロキシ のようなオプション機能

典型的な「フロントドア」シナリオ

Nginx がよく選ばれる場面：

• マーケティングサイトと API の併存（静的配信 + プロキシ）\n- 少数のアプリインスタンスへのシンプルな負荷分散\n- 遅いバックエンド（CMS や REST）の前にキャッシュを置く\n- 複数ホスト名下の複数サービスのゲートウェイとして動かす

HTTP 処理が重要で、ウェブ配信とリバースプロキシを組み合わせたい場合、Nginx はデフォルトとしてよく選ばれます。

HAProxy の概要：強みと典型的なユースケース

HAProxy（High Availability Proxy）は主に リバースプロキシ兼ロードバランサー として使われ、複数のアプリサーバーの前に置かれてトラフィックを受け、ルールを適用してヘルシーなバックエンドへ転送します。高い並列性の下でも応答時間を安定させることが求められる環境でよく使われます。

HAProxy の一般的な用途

チームは通常、トラフィック管理のために HAProxy を導入します：リクエストを複数サーバーに分散し、障害時の可用性を保ち、トラフィックスパイクを緩和します。エッジ（north–south）や内部（east–west）両方で採用され、予測可能な振る舞いと接続制御が求められる場面で人気です。

コアな強み：接続、ロードバランシング、ヘルスチェック

HAProxy は多数の同時接続を効率的に扱うことで知られています。多くのクライアントが同時接続する（忙しい API、長寿命接続、チャット）ような場合にプロキシが応答し続けることが重要です。

またロードバランシング機能が充実しており、単純なラウンドロビン以上のアルゴリズムやルーティング戦略をサポートします。これにより：

• ホットなサーバーへの過負荷を防ぐ\n- ロールアウト時に徐々にトラフィックを移行する\n- 速い／軽いインスタンスを優先する

ヘルスチェックも強力です。HAProxy は積極的なプローブでバックエンドの健全性を確認し、問題があるインスタンスを自動的にローテーションから外し、回復したら再投入します。これはダウンタイムを減らし「半壊」デプロイが全ユーザーに影響するのを防ぎます。

レイヤー4（TCP）対レイヤー7（HTTP）：実務での意味

HAProxy は**レイヤー4（TCP）とレイヤー7（HTTP）**の両方で動作できます。

• L4（TCP）モードは生の接続転送に注力します。HTTP の詳細を見なくてよいプロトコル（データベースやカスタム TCP）に向き、オーバーヘッドが少ないのが利点です。\n- L7（HTTP）モードは HTTP セマンティクスを理解し、ヘッダベースのルーティング、パスルール、細かいトラフィック制御を可能にします。

実務上の違い：L4 は単純で高速な TCP フォワードに向き、L7 は詳細なルーティングやリクエストロジックが必要な場合に強力です。

HAProxy を選ぶ場面

HAProxy は信頼性の高い高性能ロードバランシングと強力なヘルスチェックが重要な場合に選ばれます。例：API トラフィックを複数サーバーに分散、AZ 間フェイルオーバー、接続量や予測可能なトラフィック挙動が Web サーバ機能より優先されるケース。

性能の基本：レイテンシ、スループット、接続数

性能比較で陥りがちなのは、単一の数値（例：「最大 RPS」）だけを見ることです。ユーザーが体感するのは平均ではなくテール（p95/p99）です。

スループット vs レイテンシ vs テールレイテンシ

• スループット：処理できる量（リクエスト/秒、バイト/秒）。\n- レイテンシ：リクエストに要する時間。\n- テールレイテンシ（p95/p99）：遅い上位数パーセントで実際の問題が出ます。

プロキシはスループットを増やしても、負荷時に過度にキューイングするとテールレイテンシを悪化させることがあります。

接続パターンが重要

アプリの「形」を考えてください：

• 短命で多数のリクエスト（通常のウェブトラフィック）：接続受け入れ、TLS ハンドシェイク、リクエスト解析の効率が重要。\n- 長寿命で少数の接続（WebSocket、ストリーミング、gRPC、データベースライクな TCP）：接続ごとの予測可能なリソース使用が重要。

ベンチマークを特定のパターンで取ってしまうと、別のパターンでの実運用結果は異なります。

バッファリング：味方にも敵にもなる

バッファリングは、クライアントが遅い場合やバースト時にリクエスト／レスポンスを溜めてアプリに一定の速度で渡せるため助けになることがあります。

一方で ストリーミング を重視するワークロードでは余分なバッファがメモリ圧迫やテールレイテンシの悪化を招くため害になることがあります。

実用的なベンチマークのコツ

「最大 RPS」以上を計測しましょう：

• RPS/スループット、p50/p95/p99 レイテンシ、エラー率（タイムアウト、502/503）\n- 定常負荷とスパイクの両方（短いバーストはキューイングの挙動を明らかにします）\n- 現実的な keep-alive/TLS 設定で CPU、メモリ、オープン接続数を記録

p95 が急に上がる前にエラーが出ることがあるので、そこが飽和の初期警告です。

ロードバランシングとヘルスチェックの比較

Nginx と HAProxy はどちらも複数インスタンスの前に置けますが、ロードバランシング機能の深さや標準機能は異なります。

ロードバランシングアルゴリズム

ラウンドロビンはバックエンドが似ている（同一リソース、同等リクエストコスト）場合に十分に機能します。

**最少接続（least connections）**はリクエストの長さが変動するケース（ファイルダウンロード、長い API、WebSocket）で有効です。\n 重み付きはノードが均一でない場合（古いノードと新しいノードの混在、異なるインスタンスサイズ、段階的なトラフィック移行）に使います。

一般に、HAProxy はより多くのアルゴリズムと細かな制御を提供し、Nginx は一般的なケースをシンプルにカバーします（エディションやモジュールで拡張可）。

セッション永続化（スティッキー）

スティッキーはユーザーを同じバックエンドに固定します。

• Cookie ベース永続化はウェブアプリに最適：明示的で NAT 越えに強く、バックエンド消失時の制御が可能。\n- ソース IP は簡単だが不公平になりやすく（多くのユーザーが同一 IP の背後にいる）、CDN/プロキシが介在すると壊れやすい。

レガシーなサーバーサイドセッションがなければ、可能な限りスティッキーを避けるべきです。

ヘルスチェック：アクティブ vs パッシブ

アクティブヘルスチェックは定期的にバックエンドをプローブ（HTTP エンドポイント、TCP 接続、期待されるステータス）し、トラフィックが少ない状況でも障害を検出します。

パッシブヘルスチェックは実トラフィックに反応して、タイムアウトや接続エラー、異常なレスポンスでサーバーを不健全と判断します。軽量ですが検出まで時間がかかる場合があります。

HAProxy は 豊富なヘルスチェック制御（閾値、rise/fall カウント、詳細チェック）で知られ、Nginx もビルドやエディションによって堅実なチェック機能を提供します。

無停止デプロイ：ドレインとリトライ

ローリングデプロイを行うときは：

• コネクションドレイン：新しいリクエストをバックエンドに送らず、既存のインフライトを完了させる。\n- リトライとリディスパッチ：バックエンドが途中で失敗した場合に（冪等なリクエストのみ）再試行するか別のヘルシーなサーバへ送る。

どちらの場合も、短めのタイムアウトと明確な readiness ヘルスエンドポイントを組み合わせるとスムーズにトラフィック移行できます。

プロトコルと TLS：HTTP、HTTP/2、TCP プロキシング

リバースプロキシはシステムのエッジに立つため、プロトコルや TLS の選択はブラウザ性能からサービス間通信の安全性まで影響します。

TLS 終端と証明書管理

Nginx と HAProxy はどちらも TLS を「終端」できます：クライアントからの暗号化接続を受け復号し、アプリへは HTTP や再暗号化された TLS で転送します。

運用上は証明書管理が現実的な課題になります：

• 証明書の取得と更新（ACME / Let’s Encrypt など）\n- 秘密鍵の安全な保管とアクセス制限\n- 接続を切らずに設定をリロードする手順

Nginx は TLS 終端をウェブサーバ機能と組み合わせることが多く、HAProxy は TLS をトラフィック管理レイヤーの一部として扱う場面が多いです。

HTTP/2：パフォーマンスと互換性

HTTP/2 は複数リクエストを一つの接続で多重化することでブラウザのページロードを改善します。両ツールともクライアント向けに HTTP/2 をサポートします。

注意点：

• クライアント互換性：現代のブラウザはほとんど HTTP/2 をサポートしますが、古いクライアントや一部ツールは非対応の場合があります。\n- バックエンド互換性：プロキシで HTTP/2 を終端し、アップストリームとは HTTP/1.1 で通信するのが一般的で簡単です。

TCP プロキシが重要になるとき

非 HTTP トラフィック（データベース、SMTP、Redis、カスタムプロトコル）をルーティングする必要がある場合は TCP プロキシが必要です。HAProxy は高性能な TCP 負荷分散で広く使われます。Nginx も stream 機能で TCP をプロキシできますが、単純なパススルー用途で十分なことが多いです。

相互 TLS（mTLS）

mTLS は双方を検証します：クライアントも証明書を提示します。サービス間通信やパートナー連携、ゼロトラスト設計で有効です。どちらのプロキシもエッジでクライアント証明書検証を強制できますし、内部でも mTLS を使って「信頼されたネットワーク」前提を減らす運用が行われます。

可観測性：ログ、メトリクス、デバッグ

リバースプロキシはすべてのリクエストの中央にいるため、「何が起きたか」を答えるのに最適な場所です。良い可観測性は一貫したログ、少数の高シグナルなメトリクス、タイムアウトやゲートウェイエラーを繰り返しデバッグできるパターンを意味します。

必須ログ：アクセス、エラー、アップストリーム時間

本番では最低でも アクセスログ と エラーログ を有効にしてください。アクセスログにはアップストリームの時間を含め、遅延がプロキシ側かアプリ側かを判断できるようにします。

Nginx では $request_time、$upstream_response_time、$upstream_status のようなフィールドが一般的です。HAProxy では HTTP ログモードとキュー/接続/応答時間を取得して、「バックエンドの待ち時間」と「バックエンド自体の遅さ」を分離します。

ログはできれば構造化（JSON）にし、リクエスト ID（受信ヘッダー由来か生成）を付けてプロキシログとアプリログを相関できるようにしてください。

エクスポートすべきメトリクス

Prometheus 等に送る場合、次を一貫して出力してください：

• リクエスト数とステータス別カウント（2xx/4xx/5xx）\n- エラーカウンタ（リトライ、失敗したヘルスチェック、502/504）\n- レイテンシ（p50/p95/p99；可能ならプロキシ側とアップストリームを分離）\n- 接続数（アクティブ、キュー、拒否）

Nginx は stub status や Prometheus エクスポーターを使うことが多く、HAProxy はビルトインの stats エンドポイントをエクスポーターが読む形が一般的です。

ヘルス/レディネスエンドポイント

軽量な /health（プロセスが起動しているか）と /ready（依存先に到達できるか）エンドポイントを公開してください。オートスケールやデプロイ、ロードバランサのチェックに使います。

タイムアウトやリセット、502/504 のデバッグ

• 502: バックエンドが接続を拒否／切断、DNS、プロトコル不一致。\n- 504: プロキシがバックエンドを待ってタイムアウト。\n- リセット/タイムアウト: keep-alive 設定、バックエンド飽和、キュー長を確認。

デバッグ時はプロキシのキュー/接続時間とアップストリーム応答時間を比較してください。キュー/接続が高いなら容量追加や負荷分散調整、アップストリーム時間が高いならアプリ/DB 側の改善に注力します。

設定と日常運用

リバースプロキシ運用はピーク性能だけでなく、チームが安全に変更を行えるかどうかが重要です。

設定スタイルとオンボーディング

Nginx の設定はディレクティブベースで階層的です。http → server → location のようなブロック構造はサイトやルートの考え方に合いやすく、習得が比較的直感的です。

HAProxy の設定は frontend（受け入れ）と backend（転送先）を定義し、ACL で接続するパイプライン的なモデルです。一度慣れるとトラフィックルールが明示的で予測可能に感じられます。

リロードとデプロイの変更管理

Nginx は通常ワーカーを再起動して古いワーカーを優雅にドレインすることで設定をリロードします。証明書更新や頻繁なルート更新に向いています。

HAProxy もシームレスリロードが可能ですが、運用上はより「アプライアンス」的に扱われ、厳格な変更管理やバージョン化された設定の運用、リロードコマンド周りの調整が行われることが多いです。

検証、テンプレート、DRY に保つ

両者ともリロード前に設定チェックが可能です（CI/CD で必須）。実運用では設定を DRY に保つために生成することが多いです：

• テンプレート（Helm、Ansible、Terraform、社内ツール）を使う\n- ログ、ヘッダー、タイムアウト、安全設定の共通スニペットを共有する

運用上の習慣として、プロキシ設定はコードとして扱い、レビュー・テストしてデプロイすることが重要です。

スケール運用：多数のアプリ、ルート、証明書

サービス数が増えると証明書やルーティングの散逸が最大の課題になります。対策：

• 命名とオーナーシップを標準化（誰がどのホスト名を持つか）\n- 証明書の自動発行/ローテーション\n- アプリごとのタイムアウトやリトライの慣例を定める

多数のホストがあるなら、手作業編集ではなくサービスメタデータから設定を生成する方が現実的です。

Koder.ai がこのワークフローで果たす役割

複数のサービスを作り反復する場合、リバースプロキシは配信パイプラインの一部に過ぎません。アプリのスキャフォールディングや環境整合性、安全なロールアウトも必要です。

Koder.ai はチャットベースのワークフローで React アプリ、Go + PostgreSQL バックエンド、Flutter モバイルアプリを生成し、ソースコードのエクスポート、デプロイ/ホスティング、カスタムドメイン、スナップショットとロールバック をサポートします。これにより API + Web フロントエンドを素早くプロトタイプし、実トラフィックに基づいて Nginx か HAProxy かを判断できます。