インフラ

HAProxyとは?L4/L7ロードバランサーの仕組みと設定・nginxとの違いを実装目線で解説

HAProxyとは、クライアントからの通信を複数のバックエンドサーバーへ振り分ける、TCP/HTTP対応の高性能ロードバランサー兼リバースプロキシのオープンソースソフトウェアです。名前の由来は High Availability Proxy で、1台のサーバーに負荷と障害リスクが集中する構成を、複数台への分散と死活監視によって解消する目的で使われます。この記事では、HAProxyがロードバランサーやリバースプロキシとどう関係するのかという定義から、frontend/backendという設定の構造、L4(TCP)とL7(HTTP)の処理モデルの違い、負荷分散アルゴリズムとヘルスチェックの設計、最小構成の設定例とHAProxy自身の冗長化、そしてnginxやクラウドのマネージドLBとの違いと、どんなときに採用しどんなときに見送るかまでを、実装者と発注者の双方が判断に使える形で整理します。

目次

まとめ|HAProxyの正体と負荷分散設計で押さえる要点

HAProxyは、受け取った通信を裏側の複数サーバーに割り振る「交通整理役」のソフトウェアです。設定ファイルは待ち受け側を書くfrontendと、振り分け先を書くbackendに分かれ、この2つの対応関係が構成の骨格です。振り分けはbalanceで指定するアルゴリズムで決まり、順番に回すroundrobinや、接続数の少ない先を選ぶleastconnがよく使われます。serverにcheckを付ければ、停止中のサーバーには通信が送られません。TCPをそのまま流すmode tcp(L4)と、HTTPの中身を見て振り分けるmode http(L7)の2つのモードを、扱うプロトコルに応じて使い分けます。

実務で最初に押さえるべきは、HAProxy自身が単一障害点になりうるという一点です。負荷分散でバックエンドを冗長化しても、入口のHAProxyが1台なら、そこが落ちれば全体が止まります。本番ではKeepalived等でHAProxyを2台構成にし、仮想IPを引き継ぐ形にして初めて高可用性が成立します。nginxやクラウドのマネージドLBという選択肢もあるなかで、HAProxyが向くのはL4/L7を細かく制御したい自前運用の場面です。フルマネージドで済ませたい構成や小規模な単一サーバーでは過剰になります。以下で定義・仕組み・設定・冗長化・採否の判断を順に解説します。

HAProxyとは|TCP/HTTPを振り分けるロードバランサー兼リバースプロキシの定義

最初にHAProxyが何をするソフトなのかを固めます。ここが曖昧だと、後半のnginxとの比較や採否の判断が宙に浮きがちです。HAProxyは、クライアントとサーバーの間に立ち、受けた通信を複数の実サーバーへ振り分ける中継役として動きます。

HAProxyとロードバランサー・リバースプロキシの関係と位置づけ

HAProxyは、TCPおよびHTTPのトラフィックを受け付け、あらかじめ登録したバックエンドサーバー群へ分配するオープンソースのプロキシです。単に通信を横流しするのではなく、各サーバーが生きているかを定期的に確認し、応答しないサーバーを振り分け先から自動で外します。この「分配」と「死活監視」の2つが揃うと、1台が落ちても残りのサーバーで処理を続けられます。ライセンスはGPLで、追加費用なしにLinux上へ導入できる点も採用の後押しです。単一プロセスで数万規模の同時接続をさばける処理性能が、採用理由になります。

HAProxyが兼ねる2つの役割:負荷分散とリバースプロキシ

HAProxyは、ロードバランサーとリバースプロキシという2つの役割を1つのソフトで兼ねます。負荷分散の一般的な考え方や振り分け方式の全体像はロードバランサーとは?仕組み・種類・振り分け方式を実装目線で解説【2026年版】で整理したとおりで、HAProxyはそれをソフトウェアで実装した具体的な製品です。同時に、クライアントの代わりに背後のサーバーへ通信を取り次ぐリバースプロキシとは?仕組み・フォワードプロキシとの違いと導入判断を実装目線で解説の性質も持ち、SSL終端やヘッダの書き換えといった前段処理も担えます。つまりHAProxyは「振り分けるLB」と「取り次ぐリバースプロキシ」が同居した製品だと捉えると位置づけがつかめます。

HAProxyが解決する課題:単一サーバーの処理限界とSPOF

サービスを1台のWebサーバーだけで運用すると、アクセスが増えたときの処理能力の頭打ちと、その1台が壊れたときの全停止という2つの問題が同時に起こります。前者はサーバーを増やして負荷を分散すれば緩和が可能です。後者は同じ役割のサーバーを複数持てば、1台の故障を吸収できます。HAProxyはこの入口に立ち、来た通信を空いているサーバーへ配り、落ちたサーバーを避けることで両方に対処します。裏を返せば、アクセスも少なくサーバーも1台でよいシステムに、HAProxyを挟む必然性はありません。

HAProxyの仕組み|frontend/backendとL4・L7の処理モデル

HAProxyの動きは、設定ファイル haproxy.cfg のセクション構造を見ると理解しやすくなります。全体像さえ押さえれば、どこに何を書くソフトなのかは難しくありません。ここでは設定の4セクションと、動作モードの違いを確認します。

設定4セクション:global・defaults・frontend・backend

haproxy.cfg は役割の違う複数セクションで構成されます。globalはプロセス全体の共通設定(実行ユーザーやログ、PIDファイル)を、defaultsは各セクションの既定値をまとめて書く場所です。実際の振り分けを決めるのがfrontendとbackendで、frontendはbindで待ち受けるIP・ポートを定義し、backendはserverで転送先サーバーのホストとポートを列挙します。frontendとbackendを1つにまとめた簡潔な書き方としてlistenセクションも使えます。要は「どこで受けて(frontend)」「どこへ渡すか(backend)」の対応を書くのが設定の中心だと押さえてください。

mode tcp(L4)とmode http(L7)の違いと使い分け

HAProxyには通信の見方が異なる2つの動作モードがあります。mode tcpはOSI参照モデルのL4で動き、パケットの中身を解釈せずTCP接続をそのまま振り分ける方式です。データベースやメールなどHTTP以外のプロトコルや、暗号化されたまま素通しさせたい通信に向きます。一方のmode httpはL7で動き、HTTPヘッダやURLパス、Cookieといったリクエストの中身を読んで振り分けます。パスごとに別のサーバー群へ流すといった制御は、このL7モードでのみ可能です。判断軸は単純です。通信の中身を見て振り分けたいならL7、速度と汎用性を取るならL4を選びます。

ACLによるコンテンツベースルーティングとリクエスト振り分け

mode httpの真価は、ACL(Access Control List)を使ったコンテンツベースの振り分けにあります。ACLは、パスが/apiで始まる・ホスト名が特定ドメイン・送信元IPが社内といった条件に名前を付けた判定ルールです。その真偽に応じてuse_backendで振り分け先を切り替えます。たとえば「/imagesは静的ファイル用サーバー群へ、それ以外はアプリサーバー群へ」という経路制御を、アプリ側を変えずHAProxyの設定だけで実現できます。単なる負荷分散にとどまらないこの柔軟さが、HAProxyの採用理由です。

HAProxyの負荷分散アルゴリズムとヘルスチェック設計|振り分けと死活監視

frontendとbackendの対応を書いたら、次は「どのサーバーへ、どういう基準で配るか」を決めます。ここがHAProxyの設計で最も差が出る部分です。balanceによる配り方と、checkによる死活監視をセットで設計します。

balanceの選び分け:roundrobin・leastconn・source

振り分け方式はbackend(またはlisten)内のbalanceパラメータで指定します。主要なものは次の3つで、システムの性質に合わせて選びます。

アルゴリズム 振り分け基準 向いている場面
roundrobin 登録順に1台ずつ順番に割り当てる サーバー性能が均一で負荷が揃う構成
leastconn アクティブ接続数が最少のサーバーを選ぶ 接続が長く続く処理で偏りを避けたい構成
source 送信元IPで同じ利用者を同じサーバーへ セッションをサーバー側に持ち固定したい構成

迷ったときの実務上の起点はroundrobinです。まず順番配りで様子を見て、接続が長引いて偏るならleastconn、クライアントとサーバーを紐づけたいならsourceへ切り替える、という順で検討すると外しません。全サーバーを等価に列挙せず、性能差があるサーバーにはweightで重み付けし、強いサーバーに多く配る調整も加えられます。

ヘルスチェック(check)による死活監視とフェイルオーバー

負荷分散を安全に成り立たせる鍵が、serverキーワードに付けるcheckオプションです。checkを指定すると、HAProxyは各バックエンドサーバーへ定期的に接続確認を行い、応答しないサーバーを振り分け対象から自動で外します。障害サーバーへ通信を送り続けてエラーを返す事態を防ぎ、復旧すれば自動で振り分けに戻す動きです。L7ではURLを叩いて特定の応答コードを確認する、といった中身に踏み込んだチェックも設定できます。単なるポート開放の確認より、精度の高い死活監視が可能です。この自動フェイルオーバーがあるからこそ、1台の故障がサービス全体の停止に直結しません。

スティッキーセッションとstick-tableによるセッション固定

ログイン状態などのセッションをアプリサーバーのメモリに持つ構成では、同じ利用者を毎回同じサーバーへ送る必要があります。これをスティッキーセッションと呼び、実現手段は主に3つです。前述のsourceアルゴリズム、Cookieを使う方式、stick-tableで送信元と振り分け先の対応を記録する方式が代表例です。ただし固定は分散の効きを弱め、固定先が落ちればそのセッションは失われます。設計としては、セッションをアプリ外(RedisやDB)に逃がして固定自体を不要にするほうが、分散と可用性の両面で扱いやすい構成です。

HAProxyの導入手順と冗長化|最小構成の設定例とKeepalived

ここまでの要素を、動く最小構成に落とします。導入自体は数ステップで済みますが、本番投入で必ず問題になるHAProxy自身の冗長化まで含めて設計するのが実装の勘所です。

HAProxyのインストールと最小構成のhaproxy.cfg

主要なLinuxディストリビューションではパッケージマネージャ(apt/dnf等)で導入でき、設定ファイルは /etc/haproxy/haproxy.cfg に置きます。動作検証だけなら、複数のバックエンドをローカルで立てて確かめる方法が手軽です。docker-composeとは?複数コンテナをymlで定義し一括管理する仕組みを解説で扱う手順を使えば、HAProxyと複数のWebサーバーを1つのcomposeファイルでまとめて起動し、振り分けを目視できます。最小構成は、frontendで80番を待ち受け、backendに2台のserverをcheck付きで並べ、balanceにroundrobinを指定するだけです。まずこの形で挙動を確認してから、L7の条件分岐やアルゴリズムの調整に進むのが安全です。

HAProxy自身のSPOF回避:Keepalived+VRRPによる冗長化

負荷分散で背後のサーバーを何台冗長化しても、入口のHAProxyが1台なら、そこが単一障害点です。この構造的な弱点は、HAProxyを2台用意し、KeepalivedとVRRPで仮想IP(VIP)を共有すると解消できます。通常はアクティブ側がVIPを保持して通信を受け、落ちるとスタンバイ側がVIPを引き継ぐ仕組みです。負荷分散と冗長化は別物で、両方を設計して初めて止まらない入口が成立します。この切り分けは冗長化とは?二重化との違い・種類と構成、企業の設計判断まで解説【2026年版】の整理と対で押さえたい観点です。稼働率の目標値から必要な冗長構成を逆算する考え方は可用性とは?稼働率の計算と高可用性の設計をインフラ実装目線で解説【2026年版】にまとめています。

HAProxyのバージョン選定と運用:3.4系LTSと保守方針

HAProxy公式(haproxy.org)によると、2026年7月時点の最新安定版は3.4系(3.4.2が2026年6月3日公開のLTS)で、サポートは2031年第2四半期まで案内されています。並行して3.3系や、長期サポートの3.2系・3.0系LTSも維持されており、新規構築では長期サポート対象のLTS系列を選ぶのが運用面で扱いやすい判断です。設定の書式はメジャー系列間でおおむね継続していますが、機能追加や既定値の変更は起こるため、採用する系列の公式ドキュメントで該当バージョンの記述を一次情報として確認してから設定を固めます。

nginx・クラウドLBとの違いとHAProxyを採用すべき場面・見送る場面

HAProxyは唯一の選択肢ではありません。同じ役割はnginxやクラウドのマネージドLBでも果たせます。ここでは違いを整理したうえで、どんなときにHAProxyを選び、どんなときに見送るかを条件付きで言い切ります。

nginx・クラウドマネージドLBとHAProxyの違いと選定

3者は守備範囲が重なりつつ、得意分野が異なります。選定の目安を整理します。

比較軸 HAProxy nginx クラウドマネージドLB(ALB/NLB等)
主目的 負荷分散・プロキシ専用 Webサーバー+リバースプロキシ兼用 マネージドな負荷分散
L4/L7 L4・L7とも細かく制御可 L7中心(L4はstreamモジュール) L4/L7で製品が分かれる
運用負荷 自前で冗長化・監視が必要 自前運用が必要 冗長化・スケールは提供側が担う
向く場面 振り分けを細かく作り込む自前基盤 静的配信とプロキシを1台で兼ねたい 運用を任せてインフラ設計を軽くしたい

nginxは静的ファイル配信やアプリ実行を含めて1台で兼ねたいときに強く、HAProxyは負荷分散とヘルスチェックの制御そのものを作り込みたいときに強い、という住み分けです。似た前段の役割を持つAPIゲートウェイとは?役割・機能とリバースプロキシ/サービスメッシュとの違い・導入判断を解説と比べると、HAProxyは認証やレート制限といったAPI管理機能ではなく、あくまで通信の分配と可用性に軸足がある点が異なります。

HAProxyを採用すべき場面:負荷分散を作り込みたい自前基盤

HAProxyが第一候補になるのは、次の条件が重なるときです。オンプレミスや自前で構築したクラウドVM上で、複数の実サーバーへ負荷を分散し、その振り分け方式やヘルスチェックの条件を自分で細かく制御したい場合。加えて、L4のTCP負荷分散(データベースやメール等)が必要で、Webサーバー機能は別に持っている場合。この2条件がそろうなら、単一プロセスで高い同時接続をさばけるHAProxyが素直な選択です。水平にサーバーを増やして受けきる設計は、スケールアウトとスケールアップとは?水平・垂直スケーリングの違いと実装・使い分けを実装目線で解説【2026年版】で示した水平スケールの実装手段そのものであり、HAProxyはその入口を担います。

HAProxyを見送るべき3つの場面とインフラ設計の相談先の判断

逆に、次の場合はHAProxyを見送るほうが合理的です。第一に、サーバーが1台で当面アクセス増の見込みもないシステム。ここに負荷分散を挟むのは運用対象を増やすだけで、得るものがありません。第二に、AWSやクラウド上で完結し、冗長化やスケールを提供側に任せたい構成。マネージドLBを使えばHAProxy自身の2台構成やKeepalivedの保守が不要になり、運用が軽くなります。第三に、Kubernetes上でコンテナを運用する場合。コンテナオーケストレーションとは?Kubernetesの役割と自社に必要かの判断を解説で扱うとおり、k8sはService/Ingressとして負荷分散の仕組みを内包するため、その内側に別途HAProxyを立てる必然性は薄くなります(Ingressの実体としてHAProxyを選ぶ選択肢はあります)。どのLBを選ぶか、そもそも冗長化をどこまで作り込むかは、可用性の目標と運用体制から逆算する設計判断です。自社での構成設計や構築に迷う場合は、負荷分散・冗長化を含むインフラ構築(AWS/GCP/Azure)の受託で、要件に合わせた可用性設計から相談できます。

HAProxyとロードバランサー・負荷分散に関するよくある質問

検索されることの多い疑問に、仕組みと選定の両面から簡潔に答えます。

HAProxyとは何ですか?

クライアントからの通信を複数のバックエンドサーバーへ振り分ける、TCP/HTTP対応の高性能ロードバランサー兼リバースプロキシのオープンソースソフトウェアです。名前はHigh Availability Proxyの略で、負荷分散とサーバーの死活監視により、1台への集中と単一障害点を解消する目的で使われます。Linux上に無償で導入でき、単一プロセスで高い同時接続をさばけます。

HAProxyとnginxの違いは何ですか?

主目的が違います。HAProxyは負荷分散とプロキシに特化した専用ソフトで、L4のTCP負荷分散やヘルスチェックの制御を細かく作り込めます。nginxはWebサーバー機能を持ち、静的配信やアプリ実行とリバースプロキシを1台で兼ねられるのが強みです。負荷分散の制御を突き詰めるならHAProxy、Webサーバーと前段プロキシをまとめたいならnginx、という選び分けになります。

HAProxyのL4とL7の違いは何ですか?

通信の見方が異なります。L4(mode tcp)はパケットの中身を解釈せず、TCP接続をそのまま振り分ける方式です。HTTP以外のプロトコルや暗号化通信の素通しに向きます。L7(mode http)はHTTPヘッダやURLパス、Cookieを読んで振り分けるため、パスごとに別サーバーへ流すコンテンツベースの制御ができます。中身を見て振り分けたいならL7、速度と汎用性を取るならL4です。

HAProxyの負荷分散アルゴリズムはどれを選べばよいですか?

起点はroundrobin(順番配り)です。各サーバーの性能が均一で1リクエストの重さが揃うなら、まずこれで十分です。接続が長く続いて偏るならleastconn(接続数最少を選ぶ)、同じクライアントを同じサーバーに固定したいならsource(送信元IPで固定)へ切り替えます。性能差のあるサーバーにはweightで重みを付けて配分を調整します。

HAProxy自体が故障したらどうなりますか?

入口が1台なら、そこが単一障害点になり全体が止まります。これを防ぐため、本番ではHAProxyを2台構成にし、KeepalivedとVRRPで仮想IP(VIP)を共有する構成が定番です。アクティブ側が落ちるとスタンバイ側がVIPを引き継ぎ、処理を継続します。バックエンドの冗長化とHAProxy自身の冗長化は別の設計であり、両方そろえて初めて止まらない入口になります。

関連記事

資料請求

RELATED POSTS 関連記事