# 補完製品と代替製品 > Apache、NGINX、Varnish、LVS、Envoy、その他のロードバランサーと HAProxy の関係 --- LLMSインデックス: [llms.txt](/ja/llms.txt) --- HAProxy は、以下に挙げる製品の一部と非常にうまく連携します。そのため、HAProxy に直接関連しないものもここで紹介します。 ## 4.1. Apache HTTP server {#section-4-1} Apache は、事実上の標準となっている HTTP サーバーです。非常に充実したモジュール構成のプロジェクトで、ファイル配信と動的コンテンツの両方をサポートします。一部のアプリケーションサーバーのフロントエンドとしても使用でき、リクエストのプロキシやレスポンスのキャッシュも行えます。いずれの用途でも、通常は前段にロードバランサーが必要です。Apache にはさまざまな動作モードがあり、モードによって負荷が異なります。一部のモジュールでは、依然として負荷の大きい prefork モデルが必要なため、接続数が増えるとうまくスケールできません。この場合、HAProxy でサーバーごとの同時接続数を安全な値に制限すると、大きな効果があります。サーバーを大幅に高速化し、そのリソースを確保してアプリケーションで有効に利用できます。 Apache は "mod_rpaf" 拡張を使い、X-Forwarded-For ヘッダーからクライアントのアドレスを取得できます。HAProxy の設定に "option forwardfor" を指定すると、このヘッダーを自動的に付加します。HAProxy はさまざまな DoS 攻撃への耐性が高いため、インターネットに公開する Apache の保護にも役立ちます。 ## 4.2. NGINX {#section-4-2} NGINX は、もう一つの事実上の標準 HTTP サーバーです。Apache と同様、幅広い機能を備えています。HAProxy に似たモデルで構築されており、数万の同時接続を問題なく処理できます。付属の PHP FPM を使用する場合など、アプリケーションへのゲートウェイとして使用するときは、前段で接続数を制限して PHP アプリケーションの負荷を軽減すると効果的なことがよくあります。この場合、HAProxy は通常のロードバランサーとしてだけでなく、トラフィックを調整して PHP の混雑を解消し、高速化する役割でも有用です。また、どちらもイベント駆動型のアーキテクチャにより CPU 使用量が非常に小さいため、同じシステムに両方を配置することも容易です。NGINX は HAProxy の PROXY プロトコルを実装しているため、HAProxy から NGINX へクライアントの接続情報を簡単に渡し、アプリケーションに必要な情報をすべて提供できます。大きな静的ファイルの配信では、NGINX の前段にある HAProxy でコンシステントハッシュを使用すると、OS のキャッシュヒット率が改善することを示すベンチマークもあります。実質的に、サーバーノード数に応じた倍率で改善します。 ## 4.3. Varnish {#section-4-3} Varnish は、高度なキャッシュ機能を持つリバースプロキシです。Web アプリケーションアクセラレーターと呼ぶのが最も適切でしょう。SSL/TLS は実装せず、自身が最も得意とする処理にすべての CPU サイクルを使うことを目指しています。Varnish も HAProxy の PROXY プロトコルを実装しているため、HAProxy を Varnish の前段に簡単に配置し、SSL オフロードと負荷分散を行いながら、必要なクライアント情報をすべて渡せます。また、Varnish はサーバーから圧縮済みのオブジェクトを受け取った場合、キャッシュからの配信時に展開できますが、圧縮は行いません。バックエンドサーバーが圧縮に対応していなければ、HAProxy で送信データを圧縮できます。ただし、トラフィックが少ない場合を除き、ロードバランサーでの圧縮はあまり勧められません。 複数ノードで大規模なキャッシュ群を構築する場合、HAProxy は URL のコンシステントハッシュでキャッシュノードに負荷を適切に分散し、キャッシュの重複を避けられます。結果として、全キャッシュノードの合計に相当するキャッシュ容量を得られます。また、処理の不要な非常に小さいオブジェクトを HAProxy で短時間キャッシュすると、ネットワークの往復を減らし、HAProxy と Varnish の両ノードの CPU 負荷を軽減できることがあります。これは Varnish がそれらのオブジェクトに処理を加えない場合に限られます。一般に「favicon キャッシュ」と呼ばれる考え方で、不要な下流へのリクエストを相当な割合で減らせることがあります。ただし、他のキャッシュの前段で HAProxy のキャッシュを長時間、具体的には数秒を超えて有効にしないでください。大きな節約効果を得られないまま、トラブルシューティングが大幅に複雑になります。 ## 4.4. 代替製品 {#section-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 を追加して機能を補うのも容易です。