HAProxyとは？ L4/L7ロードバランシングの実践ガイド（設定例付き）

トラフィックの急増時でもアプリケーションの速度と可用性を維持する必要がある場合、すべてを 1 台のサーバーで処理することはできません。 

代わりに、HAProxy などのロードバランサーを使用してください。 

これは実稼働環境で最も信頼されているロードバランサーの 1 つであり、GitHub や Reddit などのプラットフォームで何百万もの接続を効率的かつ制御的に処理するために使用されています。

このガイドでは、HAProxyの仕組みと、いつ使うべきか（そしていつ使わないべきか）について説明します。セットアップ手順、負荷分散戦略、ACLルール、高可用性パターンなどについて、初心者にも分かりやすい説明と、実際に活用できる例を用いて解説します。

HAProxy とは何ですか?

HAProxy（高可用性プロキシ） TCP および HTTP アプリケーションのリバース プロキシおよびロード バランサとして動作するオープン ソース ソフトウェアです。

• リバース プロキシは、クライアント要求を受信して​​バックエンド サーバーに転送するゲートウェイです。
• ロード バランサーは、受信トラフィックを複数のサーバーに分散して、パフォーマンスを向上させ、過負荷を防止します。

HAProxyは、リクエストをバックエンドサーバーのプールに分散することで、アプリケーション（ウェブサイトまたはAPI）の可用性とパフォーマンスを向上させます。あるサーバーが低速またはオフラインになった場合、HAProxyはヘルスチェックによってそれを自動的に検出し、正常なサーバーにトラフィックを転送します。これにより、ユーザーは高速で信頼性の高いエクスペリエンスを維持できます。

これは、クライアント接続とトラフィックルーティングを管理するための中央制御ポイントとして、Webサーバーとアプリケーションサーバーの前面に配置されます。そこからクライアント接続を受け入れ、ルーティングルールを適用し、各リクエストを選択されたバックエンドに転送します。

そのために、トラフィックをルーティングする方法に応じて、次の 2 つのルーティング モードが提供されます。

• レイヤー4（「モードTCP」）: IPアドレスとポート番号でトラフィックをルーティングします。アプリケーション層（HTTPヘッダーやパスなど）を検査しないため、データベースなどの一般的なTCPサービスに適しています。
• レイヤー7（「モードhttp」）: 見る HTTPの詳細 （パス、ヘッダー、Cookie）を使用してコンテンツに基づいてルーティングします。これは、ウェブサイト/API、および単一ドメイン内の複数アプリのルーティングに適しています。L7では、オプションで以下のロジックを追加できます。

• URL パス (例: /api/v1/)
• HTTP ヘッダー (例: User-Agent、Host)
• クッキー（例：セッションアフィニティ/スティッキーセッション）
• リクエストメソッド（GET/POST）

HAProxy を使用する理由

負荷がかかった状態でもアプリケーションを利用できるようにし、リクエストのルーティング方法を制御する必要がある場合は、HAProxy を使用します。 

その主な利点の一部を次に示します。

• スケーラビリティ： トラフィックを複数のサーバーに分散するため、アプリを変更することなく水平方向に容量を追加できます。
• 信頼性： アクティブなヘルス チェックを実行し、正常でないサーバーをプールから自動的に削除して、ダウンタイムとエラー率を削減します。
• 低遅延: 高速負荷分散アルゴリズムと接続プールを使用して、ルーティングのオーバーヘッドを最小限に抑え、応答時間を短く保ちます。

実際の例: HAProxy を使用しているのは誰ですか?

HAProxyは、インターネット上で最もトラフィック量の多いプラットフォームのいくつかから信頼されています。これが、パフォーマンス重視のチームにとって信頼できる選択肢となる理由の一つです。

たとえば、 GitHubはHAProxyを使用しています 同社のグローバルインフラの一部に活用されています。チームは、アクティブなヘルスチェック、効率的な接続処理、そしてトラフィックフローの完全な制御にこれを活用しています。

のような他のプラットフォーム スタックオーバーフロー, Reddit, タンブラー、さらに X HAProxyも使用しています 極度の負荷下でもサービスが利用可能になるようにします。

なぜ、この問題のでしょうか？

HAProxy が、要求の厳しい実世界のワークロードに対応できるほど拡張可能であることを示しているからです。このレベルのインフラストラクチャで動作すれば、パフォーマンスと稼働時間の目標も達成できる可能性が高くなります。

HAProxy とよりシンプルなオプションを使用する場合

HAProxy がどのような場合に適するかを理解するために、表形式の比較を見てみましょう。 

HAProxyのコアビルディングブロック

HAProxyを設定するには、受信トラフィックの処理方法と送信先を定義します。これは、フロントエンド、バックエンド、ACL（アクセス制御リスト）という3つの重要なコンポーネントから始まります。 

それぞれがどのように特定の役割を果たすかを見てみましょう。

フロントエンド（エントリーポイント）

フロントエンドは、HAProxy が着信トラフィックをどのように受信するかを定義します。これは、ブラウザ、API、または内部システムからのクライアント接続を処理する設定の最初の部分です。

フロントエンドでは、HAProxy にリッスンする IP アドレスとポートを指定します。また、使用するプロトコルモード（例：tcp または http）も定義します。これにより、HAProxy がそのフロントエンドに対してレイヤー 4（トランスポート）で動作するかレイヤー 7（アプリケーション）で動作するかが決定され、トラフィックの次の行き先を決定するロジックも決まります。

各フロントエンドには、リクエストの内容に基づいてトラフィックを異なるバックエンドに転送する ACL などのルーティング ルールを含めることができます。

フロントエンドで使用する主なディレクティブは次のとおりです。

• バインド HAProxy がリッスンする IP アドレスとポートを設定します。
• モード 要求を TCP レベル (モード tcp) で検査するか、HTTP レベル (モード http) で検査するかを指定します。
• デフォルトバックエンド ルーティング ルールによって上書きされない限り、すべてのリクエストを特定のバックエンドに送信します。
• Use_backend … の場合 条件 (ACL によって定義) が true と評価された場合、トラフィックを別のバックエンドに転送します。

バックエンド（サーバープール）

バックエンドは、HAProxy がトラフィックを転送できるサーバーのプールを定義します。ここでは、利用可能なオリジンサーバー、HAProxy がそれらのサーバー間でリクエストをどのように分散させるか、そしてどのようなルールを適用するかを指定します。

すべてのバックエンドには、サーバーのリストと負荷分散戦略が含まれています。また、サーバーに相対的な重みを割り当てたり、ヘルスチェックを有効にして障害を自動検出したりすることもできます。

バックエンド セクションで設定する主要なディレクティブは次のとおりです。

• サーバー ホスト名またはIPアドレスと、リッスンするポート番号で単一のバックエンドサーバーを定義します。ヘルスチェック、接続制限、重み付けなどのオプションも設定できます。
• 残高　 リクエストの分散方法を決定する負荷分散アルゴリズムを設定します。
• 重量 プール内の他のサーバーと比較して、サーバーが受信するトラフィックの量を調整します。

バックエンドに複数のサーバーを追加し、これらのディレクティブを組み合わせてリクエストの分散を微調整できます。

アクセス制御リスト

ACLを使用すると、条件に基づいた柔軟なルーティングルールを作成できます。URLパス、HTTPヘッダー、クライアントIPなどの条件を定義し、その条件が満たされた場合に実行する処理を決定します。

これは、HAProxy が高度なユースケースをサポートする方法であり、特にレイヤー 7 (HTTP) モードでは、リクエストの送信元だけでなく、リクエストに含まれる内容に基づいてルーティングできます。

ACLは通常、HAProxyが受信リクエストを検査するフロントエンドで定義・使用されます。ただし、アクセス制御やリクエストの変更といったタスクのために、バックエンドセクションにも適用できます。一致が見つかった場合、トラフィックは別のバックエンドに送信されるか、完全にブロックされます。

関係する中核指令は次のとおりです。

• ACL テストする条件を定義します (例: URL パスが /api で始まるかどうか)。
• Use_backend … の場合 一致するトラフィックを特定のバックエンドにルーティングします。
• HTTPリクエスト拒否 オプションで条件に一致するトラフィックをブロックします。

以下は、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

この構成は次のことを行います:

• ポート 80 で HTTP トラフィックを受け入れます。
• パスが /api で始まるかどうかを確認します。
• 存在する場合、HAProxy はリクエストを api_backend にルーティングします。
• その他のリクエストはすべて web_backend に送られます。

コピーできる一般的なACLパターン

各 ACL には 2 つの部分があります。

1. 条件 (何を一致させるか)。
2. アクション (条件が真の場合に実行する処理)。

上記のように、各ACLはURLパス、HTTPメソッド、ヘッダーなどの条件を定義します。そして、その条件をuse_backendやhttp-request denyなどのアクションステートメントで使用して、条件に一致した場合の動作を決定します。

ここで、いくつかの一般的な使用例を確認し、それぞれで表示される設定行について説明しましょう。

URLパスに基づくルート

例えば、ブログのトラフィック（/blog）をブログサーバーに送信する場合、URLパスに基づいてルーティングできます。その仕組みは以下のとおりです。

• ACL は、リクエスト URL が /blog で始まるかどうかを確認します。
• 存在する場合、HAProxy はそれを別のバックエンドにルーティングします。

構成は次のようになります。

acl is_blog path_beg /blog

use_backend blog_backend if is_blog

ホスト名に基づくルート

api.example.com と app.example.com のように、サブドメインで異なるサービスを使用している場合は、ホスト名に基づいてルーティングを行うとよいでしょう。その方法は次のとおりです。 

• ACL はホスト ヘッダーをチェックして、どのサブドメインが使用されたかを確認します。
• 次に、そのドメインに基づいてルーティングします。

設定は次のようになります。

acl is_api_host hdr(host) -i api.example.com

use_backend api_backend if is_api_host

リクエストメソッドに基づくルート

HTTPメソッドに基づいてリクエストを異なる方法でルーティングできます。例えば、POST/PUTリクエスト（書き込み）とGETリクエスト（読み取り）を分離できます。その仕組みは以下のとおりです。

• ACL は、HTTP メソッドが POST か PUT かをチェックします。
• そうであれば、それらのリクエストは特定のバックエンドにルーティングされます。

構成は次のようになります。

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 つのコアタイプの負荷分散をサポートしています。 

1. レイヤー 4 (トランスポート レベル)。
2. レイヤー 7 (アプリケーション レベル)。

HAProxy で検査するデータの種類と必要なルーティング制御のレベルに応じて、それぞれの動作が異なります。

両方を見ていきましょう。 

レイヤー4負荷分散 

レイヤー 4 の負荷分散はトランスポート層で機能します。HAProxy は、クライアントの IP アドレスやポート番号などの低レベルの情報に基づいてトラフィックをルーティングします。

クライアントが接続を開くと（例えば、MySQLの場合はポート3306のデータベースへの接続）、HAProxyはそのポートをリッスンし、プール内のバックエンドサーバーの1つに接続を転送します。特定のポート（MySQLの場合は3306）でリクエストを受け付け、プールからバックエンドサーバーを即座に選択します。

HAProxyは、内部にどのようなデータが含まれているかを把握していません。接続全体を、バイト単位で利用可能なサーバーの1つに転送するだけです。サーバーが応答すると、HAProxyは応答を検査することなく、クライアントに返します。

このモードは、HAProxy がプロトコルを理解したりリクエストを解凍したりする必要がないため、高速かつ軽量です。

レイヤー7負荷分散

レイヤー7のロードバランシングはアプリケーション層で機能します。HAProxyはIPアドレスとポート番号に加えて、パス、ヘッダー、Cookie、クエリパラメータといったHTTPリクエストの内容を読み取ることができます。

クライアントが HTTP リクエスト (Web ページの読み込みや API へのアクセスなど) を送信すると、HAProxy は次のようなリクエストの一部を解析します。

• URLパス
• ホストヘッダー
• リクエストメソッド
• クッキーやクエリパラメータも

HAProxyは、定義したACL（ルール）に照らし合わせてデータを評価します。例えば、リクエストパスが/apiで始まる場合、HAProxyはAPIトラフィック専用に設計されたバックエンドにルーティングできます。

このアプローチにより、同じIPアドレスとポートを共有する複数のサービス間でトラフィックを分割できます。ルーティングの決定は、HTTPリクエストの送信元や宛先だけでなく、リクエストの内容に基づいて行われます。

レイヤー4とレイヤー7：主な違い

以下に、ニーズに最適なものを判断するのに役立つ簡単な比較表を示します。

適切な負荷分散アルゴリズムの選択

HAProxyは、バックエンドサーバー間のトラフィック分散を制御するための複数の負荷分散アルゴリズムをサポートしています。各アルゴリズムは、アプリケーションが接続を処理する方法に応じて特定の目的を果たします。

最も一般的なアルゴリズムを見ていきましょう。

ラウンドロビン（デフォルト）

このアルゴリズムは、リストを順番に巡回しながら、リクエストをすべてのサーバーに均等に分配します。サーバーに異なる重みを割り当てることで、重み付けラウンドロビンもサポートされます。

そのため、次の場合にこれを使用する必要があります。

• すべてのバックエンドサーバーの容量は同等である
• セッションの持続性は必要ありません
• アプリは短命な接続を処理する

リーストコン

このアルゴリズムは、新しい接続をアクティブな接続が最も少ないサーバーにルーティングします。設定されている場合、サーバーの重み付けも考慮されます。接続時間が一定でない場合や、一部のリクエストが他のリクエストよりも大幅に長い場合に特に効果的です（例：データベースクエリ、ライブセッション）。

したがって、次の場合にこれを使用する必要があります:

• バックエンドサーバーは長時間の接続を処理する
• リクエスト期間は大きく異なります
• 1台のサーバーに過負荷がかかるのを避けたい

ソース

このアルゴリズムは、クライアントの送信元IP（およびオプションで送信元ポート）のハッシュを適用し、クライアントを常に同じバックエンドサーバーにマッピングします。これにより、クライアントは常に同じバックエンドに接続し、基本的なスティッキーセッションに最適です。

次の場合に使用できます:

• IPベースのセッション持続性が必要な場合
• アプリはCookieや共有セッションストレージを使用していません
• リピート顧客向けに予測可能なルーティングが必要な場合

不均等なトラフィック分散に重みを使用する

重み付けディレクティブを使用して、サーバーが受信するトラフィック量を制御できます。重み付けが大きいほど、プール内の他のサーバーと比較して、そのサーバーが受信する接続またはリクエストの割合が大きくなります。デフォルトでは、重み付けの範囲は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 におけるヘルスチェックとフェイルオーバー処理

複数のサーバー間でトラフィックを分散する場合、ダウンしているサーバーや過負荷になっているサーバーにリクエストを送信しないようにする必要があります。 

だからこそ健康診断は重要なのです。

HAProxyは、トラフィックをバックエンドサーバーにルーティングする前に、アクティブなヘルスチェック（定期的なTCP接続やHTTPリクエストの送信など）を使用して、バックエンドサーバーの正常性をテストします。サーバーがチェックに失敗した場合には、HAProxyは回復するまでそのサーバーをプールから一時的に削除します。

これにより、手動による介入を必要とせずに信頼性が向上し、ダウンタイムが短縮されます。

HAProxyがヘルスチェックを実行する方法

HAProxy は、バックエンドの種類に応じて、TCP および HTTP ヘルスチェックをサポートします。

• TCP チェックはデフォルトです。HAProxyはサーバーのポートでTCP接続を確立しようとします。接続が失敗するかタイムアウトした場合、サーバーはダウンしているとマークされます。
• HTTP チェックはさらに進みます。HAProxyは特定のパスに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

この例では:

• HAProxy は各バックエンド サーバーに GET /healthz を送信します。
• サーバーが 2xx または 3xx ステータスで応答した場合、正常であると見なされます。
• /healthz を使って、アプリから単純な「OK」ステータスを返すことができます。

ヘルスチェックの感度の制御

次のパラメータを使用して、サーバーがアップまたはダウンとしてマークされるタイミングを微調整できます。

• インター ヘルスチェックの間隔（ミリ秒単位）を表示します。
• 上昇 サーバーが再び正常とマークされるまでに必要な、連続して成功したチェックの数を示します。
• 秋 サーバーがダウンしているとマークされるまでの失敗したチェックの数を指定します。

3 つすべてを一緒に使用した例を次に示します。 

server web1 10.0.0.11:80 check inter 3000 rise 2 fall 3

これの意味は：

• HAProxy は 3 秒ごとにサーバーをチェックします。
• 3 回連続して失敗すると削除されます。
• プールに再び入るには 2 つのチェックに合格する必要があります。

失敗を適切に処理する

よくある間違いは、503 エラーを検出してトラフィックを別のバックエンドに再ルーティングするなど、応答ステータス コードに基づいて ACL を使用して異常なサーバーを迂回しようとすることです。

しかし、それは機能しません。

どうして？

HAProxyが503を受信する頃には、リクエストは既にバックエンドに到達しているため、再ルーティングするには遅すぎます。

代わりに、ヘルスチェックで処理するようにしてください。

これらはリクエストが送信される前にプロアクティブに動作します。これにより、HAProxy はクリーンなフェイルオーバーと中断のないサービスを実現します。

スティッキーセッション：セッションの永続性が必要な場合

デフォルトでは、HAProxy は各リクエストを独立したものとして扱います。つまり、ユーザーは同じセッション内であっても、リクエストを行うたびに異なるバックエンドサーバーにアクセスする可能性があります。

通常は問題ありません。しかし、場合によっては問題が発生する可能性があります。

スティッキー セッション (セッション永続性とも呼ばれます) は、クライアントがバックエンド サーバーにマップされると、そのクライアントからの後続の要求がセッションの期間中、同じサーバーにルーティングされ続けることを保証します。

HAProxy は以下を使用してスティッキー セッションをサポートします。

• クッキーHAProxyによって挿入されるか、バックエンドから追跡される
• アプリセッショントラッキング 特定のサーバーに結び付けられたセッション識別子を持つ

知っておくべきトレードオフ

スティッキーセッションは1つの問題を解決しますが、いくつかの問題を引き起こします。そのため、以下の点に留意してください。

• 水平スケーリングが難しくなります: トラフィックが特定のサーバーに結び付けられると、一部のバックエンドが過負荷になり、他のバックエンドがアイドル状態になる可能性があります。これにより、負荷分散の効率が低下する可能性があります。
• キャッシュ可能性が低下します: スティッキーセッションはユーザーを特定のサーバーに縛り付けます。そのため、共有キャッシュ層やCDNから同一のレスポンスを提供する能力が制限されます。
• ブルー/グリーンデプロイメントは扱いが難しい場合があります。 スティッキー セッションは、特に異なるサーバーが異なるコード バージョンを実行している場合、ロールアウト中にユーザーを誤って古いバージョンのアプリに「閉じ込める」可能性があります。
• セッション状態はバックエンドにバインドされたままです: バックエンドがクラッシュした場合、セッション データは外部 (データベースなど) に保存されていない限り失われる可能性があります。

スティッキーセッションを使用する場合

スティッキー セッションを使用する場合と使用しない場合を識別するのに役立つ表を次に示します。 

HAProxyの設定方法

HAProxy を設定するための 4 つのステップ ガイドを以下に示します。 

ステップ1: HAProxyをインストールする

HAProxy をインストールするには、いくつかのオプションがあります。

• システムのパッケージ マネージャーを使用します。
• 移植性と簡素化された展開のために、Docker コンテナとして実行します。
• 　 HAProxyエンタープライズ 高度なセキュリティ モジュールや商用サポートなどのプレミアム機能が必要な場合。

インフラストラクチャとオペレーティングシステムに最適な方法を選択してください。多くのチームはオープンソース版から始め、必要に応じてアップグレードします。

ステップ2: フロントエンドとバックエンドを構成する

HAProxy をインストールしたら、次のステップは、リッスンする場所 (フロントエンド) とトラフィックを送信する場所 (バックエンド) を定義することです。

まず、haproxy.cfg ファイルを編集します。

• フロントエンドセクションでは、リッスンするIPアドレスとポート番号（例：bind:80）、および動作モード（httpまたはtcp）を指定します。また、フロントエンドでACLを定義してルーティングの決定を制御することもできます。
• バックエンド セクションで、server ディレクティブを使用して、オリジン サーバーとその IP アドレスおよびポートをリストします (例: server app1 10.0.0.11:80 check)。

ここでは、デフォルトのバックエンドまたは ACL を使用したコンテンツベースのロジックのいずれかのルーティング ルールも定義します。

ステップ3: 負荷分散アルゴリズムを選択する

HAProxy には複数の負荷分散戦略が用意されています。トラフィックパターンに応じて 1 つを選択してください。

• ラウンドロビン サーバーを順番に循環します (デフォルト)。
• Leastconn アクティブな接続が最も少ないサーバーにリクエストを送信するため、長時間のセッションに最適です。
• source クライアントの IP (およびオプションでポート) のハッシュを使用して、クライアントを一貫して同じサーバーにルーティングします。これにより、スティッキー セッションに役立ちます。

トラフィックを受信する頻度を制御する場合は、個々のサーバーに重みを割り当てることもできます。

ステップ4: SSL/TLS終了を有効にする

HTTPS トラフィックを処理するには、HAProxy は受信 SSL 要求を復号化する必要があります。

次の方法で実行します。

1. バインド ディレクティブに SSL オプションを追加します (例: bind *:443 ssl crt /etc/ssl/haproxy.pem)。
2. crt オプションを使用して TLS 証明書を指定します。SNI をサポートするために、複数の証明書を含むディレクトリを指定することもできます。

この設定では、HAProxy は TLS ターミネーターとして機能します。クライアントからのセキュアな接続を処理し、プレーン HTTP を内部的にバックエンドに転送します。

HAProxyトラフィックをリアルタイムで監視

HAProxy が稼働したら、HAProxy が何をしているかを把握する必要があります。 

可観測性は問題の検出に役立ちます 早期にトラブルシューティングを行い、トラフィックが期待どおりに処理されていることを確認します。

HAProxy は、すぐに使用できる 2 つのコアな監視ツールを提供します。

1. 組み込みの統計ページ (ライブ メトリックの Web ダッシュボード)。
2. 構造化ログ（syslog経由） リクエストごとの詳細な分析。

1. HAProxy統計ページ

統計ページは、フロントエンド、バックエンド、サーバーのリアルタイムステータスを表示する軽量なウェブベースのインターフェースです。接続数、キューの深さ、サーバーの健全性、稼働時間など、コマンドラインを使わずに様々な情報を確認できます。

これを有効にするには、HAProxy 構成で専用の統計セクションを構成する必要があります。

たとえば、基本認証で統計ページを有効にする方法は次のとおりです。

listen stats

  bind :8404

  mode http

  stats enable

  stats uri /stats

  stats refresh 10s

  stats auth admin:strongpassword

2. ログ記録とリクエストの可視性

HAProxy ログには次の情報が表示されます。

• リクエストを処理したフロントエンド/バックエンド
• 応答時間とステータスコード
• ソースIPとリクエストの詳細
• 健康診断結果
• 再試行、タイムアウト、またはフェイルオーバーイベント

HAProxyはログをファイルに直接書き込むのではなく、デフォルトではログを転送します。 syslogほとんどのシステムでは、ログは次の場所に送信されます。

• /var/log/haproxy.log
• または、OSに応じてrsyslogまたはjournald経由で

HTTP レベルのログを有効にするには、フロントエンドでモード http が使用されており、以下が含まれていることを確認します。

option httplog

次のようなフィールドを表示するようにログ形式をカスタマイズできます。

• %ci (クライアントIP)
• %r (完全なHTTPリクエスト)
• %s (ステータスコード)
• %Tt (合計リクエスト時間（ミリ秒）)

ロードバランサー層における単一障害点を回避する

HAProxy は、トラフィックを複数のバックエンド サーバーに分散することで、アプリケーションの稼働時間を向上させます。

しかし、ロードバランサー自体がダウンした場合はどうなるでしょうか?

適切な冗長性がなければ、ロードバランサは単一障害点（SPOF）になります。つまり、バックエンドサーバーが正常であっても、HAProxyに障害が発生するとユーザーはサーバーにアクセスできなくなります。

これを解決するために、本番環境では通常、高可用性設定で複数のHAProxyインスタンスを実行します。これにより、1つのインスタンスに障害が発生しても、別のインスタンスが処理を引き継ぐことができます。 

最も一般的な 2 つのパターンは次のとおりです。 

1. アクティブ/スタンバイ 
2. アクティブ/アクティブ

1. フローティングIPを使用したアクティブ/スタンバイ

このセットアップでは、2つのHAProxyインスタンスを実行します。1つはアクティブで、すべてのトラフィックを処理します。もう1つはスタンバイモードのままで、プライマリインスタンスに障害が発生した場合に処理を引き継ぐ準備ができています。

この設定の鍵となるのは、VRRP（通常はKeepalived経由）などのプロトコルによって管理されるフローティングIP（仮想IP、またはVIP）です。このIPは常にアクティブなHAProxyノードを指します。そのノードがオフラインになると、フローティングIPは自動的にスタンバイノードに切り替わります。

しくみはこうです： 

• クライアントは単一の IP (フローティング IP) に接続します。
• HAProxy A はアクティブです。HAProxy B はその状態を監視します。
• A に障害が発生した場合、B が引き継いでフローティング IP にバインドします。
• ダウンタイムは数秒以下に最小限に抑えられます。

このパターンはシンプルで信頼性が高く、トラフィック量を処理するために1つのロードバランサーのみが必要な場合に適しています。

2. アクティブ/アクティブでスループットを向上

このパターンでは、両方のHAProxyインスタンスがアクティブになり、同時にトラフィックを共有します。これにより、スループットが拡張され、アイドル状態のリソースが削減されます。

各HAProxyインスタンスには独自のIPアドレスが割り当てられます。トラフィックは、DNSラウンドロビン、グローバルロードバランサ（GSLB）、上流ルーターなどの外部メカニズムによってインスタンス間に分散されます。つまり、フェイルオーバーの動作はDNS TTL、つまり上流ルーターがトラフィックを再ルーティングする速度に依存します。

ヘルスモニタリングとフェイルオーバーロジックは引き続き使用できますが、両方のノードが最初から完全に使用されます。

したがって、これを選択する前に、次の点を考慮する必要があります。

• アプリでセッションの持続性が必要な場合は、正しく処理されるようにしてください。例えば、両方のインスタンスで機能するCookieを利用する場合などが考えられます。
• 1つのノードに障害が発生した場合、トラフィックは残りのノードに移行します。そのため、全負荷に対応できる十分な余裕があることを確認してください。

このパターンはスケールアウトする場合や、 コンテナ化された環境、または複数のリージョン クラスターの前で HAProxy を使用します。

HAProxy vs. NGINX vs. LoadMaster

ロード バランサまたはリバース プロキシを選択する際には、必要な柔軟性、制御、カスタマイズの程度と、管理可能な運用オーバーヘッドの程度に応じて決定します。

HAProxy を 2 つの一般的な代替手段とどのように比較するかを見てみましょう。 nginxの (NAIST) と ケンプ ロードマスター.

• HAProxy はオープンソースで、高度にカスタマイズ可能であり、高度なルーティングと高パフォーマンス環境向けに構築されています。 
• NGINXもオープンソースですが、静的コンテンツ、キャッシュ、軽量リバースプロキシのセットアップによく使用されます。L4およびL7のロードバランシングもサポートしていますが、トラフィック管理の設定と機能はHAProxyほど高度ではありません。
• Kemp LoadMasterは商用製品です。GUI、サポート、エンタープライズ機能を備えたフルマネージドエクスペリエンスを提供しますが、柔軟性が犠牲になり、ライセンス料金が高額になります。

どちらを選ぶか

どれが自分に適しているかを判断するのに役立つ、3 つのツールの概要を並べて示します。 

簡単なチェックリストでHAProxyのセットアップを安全にしましょう

HAProxyインスタンスの実行後は、攻撃対象領域を縮小することが重要です。公開されているサービスを制限し、最小限の権限で実行し、最小アクセス原則を適用します。つまり、不要な権限をロックダウンし、アクセスを制限し、本番環境での誤用を防ぐベストプラクティスに従う必要があります。

以下は、あらゆる HAProxy デプロイメントに適用できる簡単なセキュリティ チェックリストです。

次のステップ：小さく始めてスケールアップ

HAProxy の仕組みと機能について理解できたので、基本的なデプロイメントを始めましょう。

• 負荷分散とフェイルオーバーの動作を検証するには、トラフィックを少なくとも 2 つのバックエンド サーバーにルーティングします。
• ヘルスチェックをテストする
• ログをリアルタイムで観察します。

 そこから、アーキテクチャの拡大に合わせて、ACL、TLS 終了、スティッキー セッションを重ねていきます。

すでに HAProxy をお使いですか? 

このガイドのチェックリストと例を使用して、高可用性、セキュリティ、スケールの設定を強化します。

よくあるご質問

バインド *:443 ssl crt /etc/haproxy/certs/site.pem