この記事の要点

HAProxy は高性能な TCP / HTTP ロードバランサ兼リバースプロキシで、大規模トラフィックの負荷分散に広く使われる 設定は frontend (受け口) と backend (振り分け先サーバ群) に分けて記述するのが基本構造 ACL (アクセス制御リスト) を使い、パスやヘッダの条件で backend を切り替える柔軟なルーティングができる 各サーバのヘルスチェックを行い、ダウンしたサーバを自動的に振り分け対象から外す 統計画面 (stats) でリアルタイムの接続数・サーバ状態・エラー率を可視化できるのが運用上の強み

概要

HAProxy (High Availability Proxy) は、TCP および HTTP に対応した高性能なロードバランサ兼リバースプロキシです。少ないリソースで大量の同時接続を捌けることから、大規模 Web サービスのフロントで負荷分散を担う定番ソフトウェアとして使われています。ロードバランサ としても リバースプロキシ としても機能し、L4 (TCP) と L7 (HTTP) の両方の振り分けに対応します。親項目は 負荷分散・プロキシ・CDN です。

nginx がリバースプロキシ + 静的配信に強いのに対し、HAProxy は負荷分散と振り分けに特化しており、ヘルスチェック・きめ細かい ACL・充実した統計画面など、ロードバランサとしての機能が豊富なのが特徴です。

仕組み

HAProxy の設定は、役割ごとに分かれたセクションで構成されます。中核となるのは frontend と backend です。

• global: プロセス全体の設定 (最大接続数・ログ出力・実行ユーザなど)。
• defaults: frontend/backend 共通の既定値 (タイムアウト・モードなど)。
• frontend: クライアントからの受け口。どのアドレス:ポートで待ち受け、どの条件でどの backend へ渡すかを定義する。
• backend: 振り分け先のサーバ群。分散アルゴリズム (roundrobin / leastconn 等) とヘルスチェックを定義する。

frontend では ACL (Access Control List) を使って「このパスなら」「このヘッダなら」という条件を定義し、条件に応じて送り先の backend を切り替えられます。各 backend のサーバには定期的なヘルスチェックが行われ、応答しないサーバは自動的に振り分け対象から外れ、復帰すれば再び加わります。これにより一部のサーバが落ちてもサービスを継続できます (高可用性)。

設定・実用例

/haproxy.cfg の実用的な例です。80 番で受け、/api で始まるパスは API サーバ群へ、それ以外は Web サーバ群へ振り分けます。統計画面も有効化しています。

global
    maxconn 20000
    log /dev/log local0

defaults
    mode    http
    timeout connect 5s
    timeout client  30s
    timeout server  30s

# 受け口
frontend http_in
    bind *:80

    # ACL: パスが /api で始まるか判定
    acl is_api path_beg /api

    # 条件に応じて backend を切り替え
    use_backend api_servers if is_api
    default_backend web_servers

# API サーバ群 (最小接続方式 + ヘルスチェック)
backend api_servers
    balance leastconn
    option httpchk GET /healthz
    server api1 10.0.0.31:8000 check
    server api2 10.0.0.32:8000 check

# Web サーバ群 (ラウンドロビン + 重み付け)
backend web_servers
    balance roundrobin
    server web1 10.0.0.41:80 check weight 3
    server web2 10.0.0.42:80 check weight 1

# 統計画面 (運用監視用)
listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats refresh 5s

設定変更後は構文チェックしてから再起動します。

# 設定ファイルの構文チェック
haproxy -c -f /etc/haproxy/haproxy.cfg

# 反映 (systemd 環境)
sudo systemctl reload haproxy

ブラウザで http://<HAProxyのIP>:8404/stats を開くと、各サーバの状態 (UP/DOWN)・接続数・エラー数などをリアルタイムに確認できます。

主な用途

• 大規模な負荷分散: 多数のバックエンドへ高速に要求を分散し、スケールアウトを支える。
• TCP レベルの中継 (L4): HTTP 以外 (データベース接続・MQ など) も mode tcp で負荷分散できる。
• 条件付きルーティング: ACL でパス・ホスト・ヘッダ別に backend を切り替える。
• 高可用性: ヘルスチェックで故障機を自動切り離しし、サービス継続性を高める。
• 運用監視: 統計画面で接続状況・サーバ状態を可視化し、障害の早期発見に使う。

nginx との比較

観点	HAProxy	nginx
得意分野	負荷分散・振り分けに特化	リバプロ + 静的配信
対応レイヤ	L4 (TCP) / L7 (HTTP)	主に L7 (HTTP) ※stream で L4 も可
ヘルスチェック	非常に充実	基本的 (商用版で拡張)
統計画面	標準で stats 画面あり	標準は簡易 (status のみ)
静的配信	不可 (中継専用)	得意

注意点

• 統計画面の保護: /stats は内部情報を晒すため、認証・アクセス元制限を必ずかける。外部公開は厳禁。
• タイムアウトの設定漏れ: timeout を適切に設定しないと、滞留したコネクションがリソースを食い潰す。
• SSL 終端の負荷: HAProxy で TLS 終端する場合は CPU 負荷が上がる。証明書と暗号スイートの選定に注意する。
• クライアント IP の引き継ぎ: バックエンドへ元 IP を伝えるには option forwardfor で X-Forwarded-For を付与する。
• 単一障害点: HAProxy 自体が落ちると全断する。keepalived 等で冗長化 (VRRP による仮想 IP の引き継ぎ) を組む。

関連リンク

• 負荷分散・プロキシ・CDN
• ロードバランサ
• リバースプロキシ
• nginxリバースプロキシ設定
• HTTP