トラフィックの急増時でもアプリケーションの速度と可用性を維持する必要がある場合、すべてを 1 台のサーバーで処理することはできません。
代わりに、HAProxy などのロードバランサーを使用してください。
これは実稼働環境で最も信頼されているロードバランサーの 1 つであり、GitHub や Reddit などのプラットフォームで何百万もの接続を効率的かつ制御的に処理するために使用されています。
このガイドでは、HAProxyの仕組みと、いつ使うべきか（そしていつ使わないべきか）について説明します。セットアップ手順、負荷分散戦略、ACLルール、高可用性パターンなどについて、初心者にも分かりやすい説明と、実際に活用できる例を用いて解説します。
TL; DR： HAProxy は、柔軟性、制御性、稼働率に優れた、頼りになるロードバランサーです。
リクエストをサーバー間でルーティングし、負荷が高い場合でもアプリの速度と可用性を維持します。
ACL とコンテンツ認識ロジックを使用して、パス、ヘッダー、または IP に基づいてトラフィックをルーティングします。
小規模および大規模なセットアップの両方に適合します。
GitHub、Reddit、その他のトラフィック量の多いプラットフォームでは、何百万もの接続を管理するために使用されています。
HAProxy（高可用性プロキシ） TCP および HTTP アプリケーションのリバース プロキシおよびロード バランサとして動作するオープン ソース ソフトウェアです。
HAProxyは、リクエストをバックエンドサーバーのプールに分散することで、アプリケーション（ウェブサイトまたはAPI）の可用性とパフォーマンスを向上させます。あるサーバーが低速またはオフラインになった場合、HAProxyはヘルスチェックによってそれを自動的に検出し、正常なサーバーにトラフィックを転送します。これにより、ユーザーは高速で信頼性の高いエクスペリエンスを維持できます。
これは、クライアント接続とトラフィックルーティングを管理するための中央制御ポイントとして、Webサーバーとアプリケーションサーバーの前面に配置されます。そこからクライアント接続を受け入れ、ルーティングルールを適用し、各リクエストを選択されたバックエンドに転送します。
そのために、トラフィックをルーティングする方法に応じて、次の 2 つのルーティング モードが提供されます。
負荷がかかった状態でもアプリケーションを利用できるようにし、リクエストのルーティング方法を制御する必要がある場合は、HAProxy を使用します。
その主な利点の一部を次に示します。
HAProxyは、インターネット上で最もトラフィック量の多いプラットフォームのいくつかから信頼されています。これが、パフォーマンス重視のチームにとって信頼できる選択肢となる理由の一つです。
たとえば、 GitHubはHAProxyを使用しています 同社のグローバルインフラの一部に活用されています。チームは、アクティブなヘルスチェック、効率的な接続処理、そしてトラフィックフローの完全な制御にこれを活用しています。
のような他のプラットフォーム スタックオーバーフロー, Reddit, タンブラー、さらに X HAProxyも使用しています 極度の負荷下でもサービスが利用可能になるようにします。
なぜ、この問題のでしょうか？
HAProxy が、要求の厳しい実世界のワークロードに対応できるほど拡張可能であることを示しているからです。このレベルのインフラストラクチャで動作すれば、パフォーマンスと稼働時間の目標も達成できる可能性が高くなります。
HAProxy がどのような場合に適するかを理解するために、表形式の比較を見てみましょう。
| HAProxyは次のような場合に適しています | もっとシンプルな選択肢で十分かもしれない |
| トラフィックは変動性が高く、スパイクが発生しやすいため、複数のサーバーにまたがってスケーリングする必要があります。コンテンツ（例：/api と /app）に基づいてトラフィックをルーティングする必要があります。TLS終端、ヘルスチェック、詳細なログなどの組み込み機能が必要です。TCPベースのサービス（例：データベース、メッセージキュー）のバランス調整が必要です。 | 一貫性のある低ボリュームのトラフィックで単一サーバー アプリケーションを実行しています。基本的な Web サーバー (NGINX など) で効率的に処理したり、CDN にオフロードしたりできる静的ファイルを提供しています。チームでは、管理されたクラウド ロード バランサーを維持するのではなく、使用することを希望しています。 |
HAProxyを設定するには、受信トラフィックの処理方法と送信先を定義します。これは、フロントエンド、バックエンド、ACL（アクセス制御リスト）という3つの重要なコンポーネントから始まります。
それぞれがどのように特定の役割を果たすかを見てみましょう。
フロントエンドは、HAProxy が着信トラフィックをどのように受信するかを定義します。これは、ブラウザ、API、または内部システムからのクライアント接続を処理する設定の最初の部分です。
フロントエンドでは、HAProxy にリッスンする IP アドレスとポートを指定します。また、使用するプロトコルモード（例：tcp または http）も定義します。これにより、HAProxy がそのフロントエンドに対してレイヤー 4（トランスポート）で動作するかレイヤー 7（アプリケーション）で動作するかが決定され、トラフィックの次の行き先を決定するロジックも決まります。
各フロントエンドには、リクエストの内容に基づいてトラフィックを異なるバックエンドに転送する ACL などのルーティング ルールを含めることができます。
フロントエンドで使用する主なディレクティブは次のとおりです。
バックエンドは、HAProxy がトラフィックを転送できるサーバーのプールを定義します。ここでは、利用可能なオリジンサーバー、HAProxy がそれらのサーバー間でリクエストをどのように分散させるか、そしてどのようなルールを適用するかを指定します。
すべてのバックエンドには、サーバーのリストと負荷分散戦略が含まれています。また、サーバーに相対的な重みを割り当てたり、ヘルスチェックを有効にして障害を自動検出したりすることもできます。
バックエンド セクションで設定する主要なディレクティブは次のとおりです。
バックエンドに複数のサーバーを追加し、これらのディレクティブを組み合わせてリクエストの分散を微調整できます。
ACLを使用すると、条件に基づいた柔軟なルーティングルールを作成できます。URLパス、HTTPヘッダー、クライアントIPなどの条件を定義し、その条件が満たされた場合に実行する処理を決定します。
これは、HAProxy が高度なユースケースをサポートする方法であり、特にレイヤー 7 (HTTP) モードでは、リクエストの送信元だけでなく、リクエストに含まれる内容に基づいてルーティングできます。
ACLは通常、HAProxyが受信リクエストを検査するフロントエンドで定義・使用されます。ただし、アクセス制御やリクエストの変更といったタスクのために、バックエンドセクションにも適用できます。一致が見つかった場合、トラフィックは別のバックエンドに送信されるか、完全にブロックされます。
関係する中核指令は次のとおりです。
注意： 各ACLには明確な名前を付け、スコープを厳密に限定する必要があります。論理演算子（AND、OR）を使用して複数の条件を組み合わせることで、より複雑なロジックを実現できます。
以下は、HAProxy がパスベースの ACL を使用して API トラフィックを別のバックエンドに送信する方法を示した例です。
frontend main_in
bind :80
mode http
acl is_api path_beg /api
use_backend api_backend if is_api
default_backend web_backend
backend web_backend
balance roundrobin
server web1 10.0.0.11:80 check
server web2 10.0.0.12:80 check
backend api_backend
balance leastconn
server api1 10.0.1.21:8080 check
server api2 10.0.1.22:8080 checkこの構成は次のことを行います:
各 ACL には 2 つの部分があります。
上記のように、各ACLはURLパス、HTTPメソッド、ヘッダーなどの条件を定義します。そして、その条件をuse_backendやhttp-request denyなどのアクションステートメントで使用して、条件に一致した場合の動作を決定します。
ここで、いくつかの一般的な使用例を確認し、それぞれで表示される設定行について説明しましょう。
例えば、ブログのトラフィック（/blog）をブログサーバーに送信する場合、URLパスに基づいてルーティングできます。その仕組みは以下のとおりです。
構成は次のようになります。
acl is_blog path_beg /blog
use_backend blog_backend if is_blogapi.example.com と app.example.com のように、サブドメインで異なるサービスを使用している場合は、ホスト名に基づいてルーティングを行うとよいでしょう。その方法は次のとおりです。
設定は次のようになります。
acl is_api_host hdr(host) -i api.example.com
use_backend api_backend if is_api_hostHTTPメソッドに基づいてリクエストを異なる方法でルーティングできます。例えば、POST/PUTリクエスト（書き込み）とGETリクエスト（読み取り）を分離できます。その仕組みは以下のとおりです。
構成は次のようになります。
acl is_write_method method POST PUT
use_backend write_backend if is_write_method次のような論理演算子を使用して複数の条件を組み合わせることもできます。
use_backend blog_backend if is_blog or is_staticこれにより、API、静的アセット、地域コンテンツ、分割環境など、どのような種類のアプリでも正確なルーティング ロジックを構築できます。
HAProxy は、次の 2 つのコアタイプの負荷分散をサポートしています。
HAProxy で検査するデータの種類と必要なルーティング制御のレベルに応じて、それぞれの動作が異なります。
両方を見ていきましょう。
レイヤー 4 の負荷分散はトランスポート層で機能します。HAProxy は、クライアントの IP アドレスやポート番号などの低レベルの情報に基づいてトラフィックをルーティングします。
クライアントが接続を開くと（例えば、MySQLの場合はポート3306のデータベースへの接続）、HAProxyはそのポートをリッスンし、プール内のバックエンドサーバーの1つに接続を転送します。特定のポート（MySQLの場合は3306）でリクエストを受け付け、プールからバックエンドサーバーを即座に選択します。
HAProxyは、内部にどのようなデータが含まれているかを把握していません。接続全体を、バイト単位で利用可能なサーバーの1つに転送するだけです。サーバーが応答すると、HAProxyは応答を検査することなく、クライアントに返します。
このモードは、HAProxy がプロトコルを理解したりリクエストを解凍したりする必要がないため、高速かつ軽量です。
レイヤー7のロードバランシングはアプリケーション層で機能します。HAProxyはIPアドレスとポート番号に加えて、パス、ヘッダー、Cookie、クエリパラメータといったHTTPリクエストの内容を読み取ることができます。
クライアントが HTTP リクエスト (Web ページの読み込みや API へのアクセスなど) を送信すると、HAProxy は次のようなリクエストの一部を解析します。
HAProxyは、定義したACL（ルール）に照らし合わせてデータを評価します。例えば、リクエストパスが/apiで始まる場合、HAProxyはAPIトラフィック専用に設計されたバックエンドにルーティングできます。
このアプローチにより、同じIPアドレスとポートを共有する複数のサービス間でトラフィックを分割できます。ルーティングの決定は、HTTPリクエストの送信元や宛先だけでなく、リクエストの内容に基づいて行われます。
以下に、ニーズに最適なものを判断するのに役立つ簡単な比較表を示します。
| 基準 | レイヤー4（モードtcp） | レイヤー7（モードhttp） |
| 検査対象 | IPアドレスとポート | HTTPヘッダー、パス、Cookie、クエリパラメータ |
| 柔軟性 | 低; ルーティングは IP アドレスとポート情報に制限されます (リクエストの内容は表示されません) | 高; コンテンツベースのルーティングをサポート |
| パフォーマンス | 最速（オーバーヘッドが少ない） | リクエストの内容を解析するため L4 よりも遅くなりますが、それでも非常に効率的で、大規模な本番環境で実証済みです。 |
| ユースケース | データベース、メールサーバー、汎用TCP | ウェブアプリ、API、コンテンツ認識ルーティング |
| 使用する場合 | 素早いスピードとシンプルなルールが必要 | ルーティングはリクエストの内容によって異なります |
HAProxyは、バックエンドサーバー間のトラフィック分散を制御するための複数の負荷分散アルゴリズムをサポートしています。各アルゴリズムは、アプリケーションが接続を処理する方法に応じて特定の目的を果たします。
最も一般的なアルゴリズムを見ていきましょう。
このアルゴリズムは、リストを順番に巡回しながら、リクエストをすべてのサーバーに均等に分配します。サーバーに異なる重みを割り当てることで、重み付けラウンドロビンもサポートされます。
そのため、次の場合にこれを使用する必要があります。
このアルゴリズムは、新しい接続をアクティブな接続が最も少ないサーバーにルーティングします。設定されている場合、サーバーの重み付けも考慮されます。接続時間が一定でない場合や、一部のリクエストが他のリクエストよりも大幅に長い場合に特に効果的です（例：データベースクエリ、ライブセッション）。
したがって、次の場合にこれを使用する必要があります:
このアルゴリズムは、クライアントの送信元IP（およびオプションで送信元ポート）のハッシュを適用し、クライアントを常に同じバックエンドサーバーにマッピングします。これにより、クライアントは常に同じバックエンドに接続し、基本的なスティッキーセッションに最適です。
次の場合に使用できます:
重み付けディレクティブを使用して、サーバーが受信するトラフィック量を制御できます。重み付けが大きいほど、プール内の他のサーバーと比較して、そのサーバーが受信する接続またはリクエストの割合が大きくなります。デフォルトでは、重み付けの範囲は1から256です。
次のコード ブロックを見てみましょう。
backend weighted_backend
balance roundrobin
server s1 10.0.3.11:80 check weight 3
server s2 10.0.3.12:80 check weight 1この場合、サーバーs1は4つのリクエストのうち3つを受信します。これは、サーバーのCPUやメモリ容量が異なる場合に役立ちます。
複数のサーバー間でトラフィックを分散する場合、ダウンしているサーバーや過負荷になっているサーバーにリクエストを送信しないようにする必要があります。
だからこそ健康診断は重要なのです。
HAProxyは、トラフィックをバックエンドサーバーにルーティングする前に、アクティブなヘルスチェック（定期的なTCP接続やHTTPリクエストの送信など）を使用して、バックエンドサーバーの正常性をテストします。サーバーがチェックに失敗した場合には、HAProxyは回復するまでそのサーバーをプールから一時的に削除します。
これにより、手動による介入を必要とせずに信頼性が向上し、ダウンタイムが短縮されます。
HAProxy は、バックエンドの種類に応じて、TCP および HTTP ヘルスチェックをサポートします。
HTTP チェックを使用するには、バックエンド設定に「httpchk」ディレクティブオプションを追加してください。例えば、一意の URI を使用した HTTP ヘルスチェックのサンプルを以下に示します。
backend web_backend
balance roundrobin
option httpchk GET /healthz
server web1 10.0.0.11:80 check
server web2 10.0.0.12:80 checkこの例では:
次のパラメータを使用して、サーバーがアップまたはダウンとしてマークされるタイミングを微調整できます。
3 つすべてを一緒に使用した例を次に示します。
server web1 10.0.0.11:80 check inter 3000 rise 2 fall 3これの意味は：
よくある間違いは、503 エラーを検出してトラフィックを別のバックエンドに再ルーティングするなど、応答ステータス コードに基づいて ACL を使用して異常なサーバーを迂回しようとすることです。
しかし、それは機能しません。
どうして？
HAProxyが503を受信する頃には、リクエストは既にバックエンドに到達しているため、再ルーティングするには遅すぎます。
代わりに、ヘルスチェックで処理するようにしてください。
これらはリクエストが送信される前にプロアクティブに動作します。これにより、HAProxy はクリーンなフェイルオーバーと中断のないサービスを実現します。
デフォルトでは、HAProxy は各リクエストを独立したものとして扱います。つまり、ユーザーは同じセッション内であっても、リクエストを行うたびに異なるバックエンドサーバーにアクセスする可能性があります。
通常は問題ありません。しかし、場合によっては問題が発生する可能性があります。
スティッキー セッション (セッション永続性とも呼ばれます) は、クライアントがバックエンド サーバーにマップされると、そのクライアントからの後続の要求がセッションの期間中、同じサーバーにルーティングされ続けることを保証します。
HAProxy は以下を使用してスティッキー セッションをサポートします。
スティッキーセッションは1つの問題を解決しますが、いくつかの問題を引き起こします。そのため、以下の点に留意してください。
スティッキー セッションを使用する場合と使用しない場合を識別するのに役立つ表を次に示します。
| スティッキーセッションを使用するのは、 | スティッキーセッションを避ける |
| • アプリはセッションデータを各サーバーのローカルメモリに保存します（サーバー間で共有されません） • ログインやショッピングカートなどの機能は、リクエストが異なるバックエンドに送られると機能しなくなります • インフラストラクチャが共有セッションストレージをサポートしていない | • セッション状態に依存しないステートレスAPIを使用している • セッション状態は既に外部に保存されている（例：データベース、Redis、または他の集中型ストア） • すべてのバックエンドにわたって柔軟性、キャッシュ可能性、スケーリングを最大化したい |
HAProxy を設定するための 4 つのステップ ガイドを以下に示します。
HAProxy をインストールするには、いくつかのオプションがあります。
インフラストラクチャとオペレーティングシステムに最適な方法を選択してください。多くのチームはオープンソース版から始め、必要に応じてアップグレードします。
HAProxy をインストールしたら、次のステップは、リッスンする場所 (フロントエンド) とトラフィックを送信する場所 (バックエンド) を定義することです。
まず、haproxy.cfg ファイルを編集します。
ここでは、デフォルトのバックエンドまたは ACL を使用したコンテンツベースのロジックのいずれかのルーティング ルールも定義します。
HAProxy には複数の負荷分散戦略が用意されています。トラフィックパターンに応じて 1 つを選択してください。
トラフィックを受信する頻度を制御する場合は、個々のサーバーに重みを割り当てることもできます。
HTTPS トラフィックを処理するには、HAProxy は受信 SSL 要求を復号化する必要があります。
次の方法で実行します。
この設定では、HAProxy は TLS ターミネーターとして機能します。クライアントからのセキュアな接続を処理し、プレーン HTTP を内部的にバックエンドに転送します。
HAProxy が稼働したら、HAProxy が何をしているかを把握する必要があります。
可観測性は問題の検出に役立ちます 早期にトラブルシューティングを行い、トラフィックが期待どおりに処理されていることを確認します。
HAProxy は、すぐに使用できる 2 つのコアな監視ツールを提供します。
統計ページは、フロントエンド、バックエンド、サーバーのリアルタイムステータスを表示する軽量なウェブベースのインターフェースです。接続数、キューの深さ、サーバーの健全性、稼働時間など、コマンドラインを使わずに様々な情報を確認できます。
注意： 統計ページをパブリックインターネットに公開しないでください。認証、IP制限、またはその両方を使用してください。
これを有効にするには、HAProxy 構成で専用の統計セクションを構成する必要があります。
たとえば、基本認証で統計ページを有効にする方法は次のとおりです。
listen stats
bind :8404
mode http
stats enable
stats uri /stats
stats refresh 10s
stats auth admin:strongpasswordHAProxy ログには次の情報が表示されます。
HAProxyはログをファイルに直接書き込むのではなく、デフォルトではログを転送します。 syslogほとんどのシステムでは、ログは次の場所に送信されます。
HTTP レベルのログを有効にするには、フロントエンドでモード http が使用されており、以下が含まれていることを確認します。
option httplog次のようなフィールドを表示するようにログ形式をカスタマイズできます。
HAProxy は、トラフィックを複数のバックエンド サーバーに分散することで、アプリケーションの稼働時間を向上させます。
しかし、ロードバランサー自体がダウンした場合はどうなるでしょうか?
適切な冗長性がなければ、ロードバランサは単一障害点（SPOF）になります。つまり、バックエンドサーバーが正常であっても、HAProxyに障害が発生するとユーザーはサーバーにアクセスできなくなります。
これを解決するために、本番環境では通常、高可用性設定で複数のHAProxyインスタンスを実行します。これにより、1つのインスタンスに障害が発生しても、別のインスタンスが処理を引き継ぐことができます。
最も一般的な 2 つのパターンは次のとおりです。
このセットアップでは、2つのHAProxyインスタンスを実行します。1つはアクティブで、すべてのトラフィックを処理します。もう1つはスタンバイモードのままで、プライマリインスタンスに障害が発生した場合に処理を引き継ぐ準備ができています。
この設定の鍵となるのは、VRRP（通常はKeepalived経由）などのプロトコルによって管理されるフローティングIP（仮想IP、またはVIP）です。このIPは常にアクティブなHAProxyノードを指します。そのノードがオフラインになると、フローティングIPは自動的にスタンバイノードに切り替わります。
しくみはこうです：
このパターンはシンプルで信頼性が高く、トラフィック量を処理するために1つのロードバランサーのみが必要な場合に適しています。
このパターンでは、両方のHAProxyインスタンスがアクティブになり、同時にトラフィックを共有します。これにより、スループットが拡張され、アイドル状態のリソースが削減されます。
各HAProxyインスタンスには独自のIPアドレスが割り当てられます。トラフィックは、DNSラウンドロビン、グローバルロードバランサ（GSLB）、上流ルーターなどの外部メカニズムによってインスタンス間に分散されます。つまり、フェイルオーバーの動作はDNS TTL、つまり上流ルーターがトラフィックを再ルーティングする速度に依存します。
ヘルスモニタリングとフェイルオーバーロジックは引き続き使用できますが、両方のノードが最初から完全に使用されます。
したがって、これを選択する前に、次の点を考慮する必要があります。
このパターンはスケールアウトする場合や、 コンテナ化された環境、または複数のリージョン クラスターの前で HAProxy を使用します。
どちらのパターンでも、HAProxy のヘルスチェック システムはバックエンド サーバー (およびオプションでピア ロード バランサー) を継続的に監視し、障害を早期に検出します。
ロード バランサまたはリバース プロキシを選択する際には、必要な柔軟性、制御、カスタマイズの程度と、管理可能な運用オーバーヘッドの程度に応じて決定します。
HAProxy を 2 つの一般的な代替手段とどのように比較するかを見てみましょう。 nginxの および ケンプ ロードマスター.
どれが自分に適しているかを判断するのに役立つ、3 つのツールの概要を並べて示します。
| ツール | ベスト | カスタマイズ | 使いやすさ | 費用 |
| ハプロキシ | 高性能ルーティングAPIリアルタイムアプリ | 非常に高い（完全な構成制御） | 中程度（テキストベースの構成） | 無料（オープンソース） |
| nginxの | 静的コンテンツキャッシュリバースプロキシ基本的な負荷分散 | 穏健派 | 簡単（特に初心者向け） | 無料有料プラス |
| ロードマスター | マネージドかつプラグアンドプレイのLBを必要とする企業 | 低（事前構築された機能） | 非常に簡単（GUIベース） | 有料（ライセンスが必要） |
HAProxyインスタンスの実行後は、攻撃対象領域を縮小することが重要です。公開されているサービスを制限し、最小限の権限で実行し、最小アクセス原則を適用します。つまり、不要な権限をロックダウンし、アクセスを制限し、本番環境での誤用を防ぐベストプラクティスに従う必要があります。
以下は、あらゆる HAProxy デプロイメントに適用できる簡単なセキュリティ チェックリストです。
HAProxy の仕組みと機能について理解できたので、基本的なデプロイメントを始めましょう。
そこから、アーキテクチャの拡大に合わせて、ACL、TLS 終了、スティッキー セッションを重ねていきます。
すでに HAProxy をお使いですか?
このガイドのチェックリストと例を使用して、高可用性、セキュリティ、スケールの設定を強化します。
両方です。HAProxy はリバース プロキシ (クライアント接続を終了してバックエンドに転送する) とロード バランサ (トラフィックを複数のサーバーに分散する) として機能します。
はい。HAProxyは、パス、ヘッダー、Cookie、メソッドに基づくルールを使用して、レイヤー7（アプリケーション層）の負荷分散をサポートしています。また、よりシンプルで高速なルーティングを実現するために、レイヤー4（トランスポート層）もサポートしています。
使用ケースによって異なります。
SSLオプションを使用してbindディレクティブを設定し、証明書を指定します。例：
バインド *:443 ssl crt /etc/haproxy/certs/site.pem
これにより、HAProxy は HTTPS トラフィックを内部でルーティングする前に復号化できるようになります。
はい、HAProxyはDockerで動作しますが、高度なネットワーク設定が必要です。macvlanインターフェースの設定、ポートを正しく公開するためのカスタムネットワークの設定、ネットワーク名前空間の適切な設定などが必要になります。可能ですが、初心者向けではありません。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
