補完製品と代替製品

HAProxyは、以下に挙げる製品の一部と非常にうまく連携します。そのため、HAProxyに直接関連しないものもここで紹介します。

4.1. Apache HTTPサーバー

Apacheは、事実上の標準となっているHTTPサーバーです。非常に充実したモジュール構成のプロジェクトで、ファイル配信と動的コンテンツの両方をサポートします。一部のアプリケーションサーバーのフロントエンドとしても使用でき、リクエストのプロキシやレスポンスのキャッシュも行えます。いずれの用途でも、通常は前段にロードバランサーが必要です。Apacheにはさまざまな動作モードがあり、モードによって負荷が異なります。一部のモジュールでは、依然として負荷の大きいpreforkモデルが必要なため、接続数が増えるとうまくスケールできません。この場合、HAProxyでサーバーごとの同時接続数を安全な値に制限すると、大きな効果があります。サーバーを大幅に高速化し、そのリソースを確保してアプリケーションで有効に利用できます。

Apacheは “mod_rpaf” 拡張を使い、X-Forwarded-Forヘッダーからクライアントのアドレスを取得できます。HAProxyの設定に “option forwardfor” を指定すると、このヘッダーを自動的に付加します。HAProxyはさまざまなDoS攻撃への耐性が高いため、インターネットに公開するApacheの保護にも役立ちます。

4.2. NGINX

NGINXは、もう一つの事実上の標準HTTPサーバーです。Apacheと同様、幅広い機能を備えています。HAProxyに似たモデルで構築されており、数万の同時接続を問題なく処理できます。付属のPHP FPMを使用する場合など、アプリケーションへのゲートウェイとして使用するときは、前段で接続数を制限してPHPアプリケーションの負荷を軽減すると効果的なことがよくあります。この場合、HAProxyは通常のロードバランサーとしてだけでなく、トラフィックを調整してPHPの混雑を解消し、高速化する役割でも有用です。また、どちらもイベント駆動型のアーキテクチャによりCPU使用量が非常に小さいため、同じシステムに両方を配置することも容易です。NGINXはHAProxyのPROXYプロトコルを実装しているため、HAProxyからNGINXへクライアントの接続情報を簡単に渡し、アプリケーションに必要な情報をすべて提供できます。大きな静的ファイルの配信では、NGINXの前段にあるHAProxyでコンシステントハッシュを使用すると、OSのキャッシュヒット率が改善することを示すベンチマークもあります。実質的に、サーバーノード数に応じた倍率で改善します。

4.3. Varnish

Varnishは、高度なキャッシュ機能を持つリバースプロキシです。Webアプリケーションアクセラレーターと呼ぶのが最も適切でしょう。SSL/TLSは実装せず、自身が最も得意とする処理にすべてのCPUサイクルを使うことを目指しています。VarnishもHAProxyのPROXYプロトコルを実装しているため、HAProxyをVarnishの前段に簡単に配置し、SSLオフロードと負荷分散を行いながら、必要なクライアント情報をすべて渡せます。また、Varnishはサーバーから圧縮済みのオブジェクトを受け取った場合、キャッシュからの配信時に展開できますが、圧縮は行いません。バックエンドサーバーが圧縮に対応していなければ、HAProxyで送信データを圧縮できます。ただし、トラフィックが少ない場合を除き、ロードバランサーでの圧縮はあまり勧められません。

複数ノードで大規模なキャッシュ群を構築する場合、HAProxyはURLのコンシステントハッシュでキャッシュノードに負荷を適切に分散し、キャッシュの重複を避けられます。結果として、全キャッシュノードの合計に相当するキャッシュ容量を得られます。また、処理の不要な非常に小さいオブジェクトをHAProxyで短時間キャッシュすると、ネットワークの往復を減らし、HAProxyとVarnishの両ノードのCPU負荷を軽減できることがあります。これはVarnishがそれらのオブジェクトに処理を加えない場合に限られます。一般に「faviconキャッシュ」と呼ばれる考え方で、不要な下流へのリクエストを相当な割合で減らせることがあります。ただし、他のキャッシュの前段でHAProxyのキャッシュを長時間、具体的には数秒を超えて有効にしないでください。大きな節約効果を得られないまま、トラブルシューティングが大幅に複雑になります。

4.4. 代替製品

Linux Virtual Server（LVSまたはIPVS）は、Linuxカーネルに含まれるレイヤー4のロードバランサーです。パケット単位で動作し、TCPとUDPを処理します。レイヤー7の知識をまったく持たないため、多くの場合、代替というより補完する製品です。

Poundもよく知られたロードバランサーです。HAProxyより大幅に簡素で機能も少ないものの、非常に基本的な構成であればどちらも利用できます。作者は常にコードの監査しやすさを最優先し、機能数を少なく保つ方針をとっています。スレッドベースのアーキテクチャのため、多数の接続ではスケーラビリティに劣りますが、優れた製品です。

Penは比較的軽量なロードバランサーです。SSLをサポートし、クライアントのIPアドレスを格納する固定サイズのテーブルで接続先を固定します。パケット指向のモードも備え、Direct Server ReturnやUDPにもある程度対応します。接続先固定用のテーブルは2048エントリーしかなく、小さな負荷を想定しています。

NGINXにもある程度の負荷分散機能がありますが、明らかに主要な機能ではありません。実際のトラフィックを使ってサーバー障害を検出し、負荷分散アルゴリズムも限られ、接続先固定の機能も非常に限定的です。それでも、すでにNGINXを使用している単純な構成では、有用な場合があります。HAProxyと非常によく連携するため、限界に達してからHAProxyを追加しても問題ありません。

Varnishもバックエンドサーバーの負荷分散を行い、実際のヘルスチェックにも対応します。ただし、接続先固定は実装していません。そのため、NGINXと同様、接続先固定が不要であれば、最初はそれだけで十分な場合があります。HAProxyとVarnishは非常によく連携するので、後からHAProxyを追加して機能を補うのも容易です。