（まとめ）Nginx/LVS/HAProxy負荷分散ソフトのメリット・デメリットを詳しく解説

追記: Nginx/LVS/HAProxy は現在最も広く使用されている 3 つの負荷分散ソフトウェアであり、いくつかの情報を参照し、私自身の経験を組み合わせてまとめました。

一般に、負荷分散の使用は、Web サイトの規模が大きくなるにつれて、さまざまな段階に応じてさまざまなテクノロジーを使用することです。特定のアプリケーション要件を詳細に分析する必要がある場合、たとえば、1 日の PV が 1,000 万未満の小規模および中規模の Web アプリケーションの場合、マシン数が多い場合は、Nginx を使用することができます。 DNS ポーリングを使用しても、LVS は依然として多くのマシンを消費します。大規模な Web サイトや重要なサービスでサーバーが多数ある場合は、LVS の使用を検討できます。

1 つは、ハードウェアを介して行うことです。一般的なハードウェアには、比較的高価な F5 や Array などの商用ロード バランサーが含まれます。その利点は、これらのサービスを維持するための専門のメンテナンス チームが存在することです。欠点は、コストが高すぎることです。なので、当面は小規模なネットワーク サービスに使用する必要はありません。もう 1 つは、Nginx/LVS/HAProxy に似た Linux ベースの無料の負荷分散ソフトウェアです。これらはすべてソフトウェア レベルで実装されているため、料金がかかります。は非常に低いです。

現在、Web サイトのアーキテクチャで最も合理的で一般的なアーキテクチャ ソリューションは次のとおりです。Web フロントエンドはロード バランサーとして Nginx/HAProxy+Keepalived を使用し、バックエンドは 1 つのマスターと複数のスレーブを備えた MySQL データベースを使用します。書き込み分離を実現し、LVS+Keepalivedアーキテクチャを採用しています。 もちろん、計画はプロジェクトの特定のニーズに基づいて作成する必要があります。
それぞれの特徴と適用シーンについてお話しましょう。

Nginx の利点は次のとおりです:

1. ネットワークの 7 層上で動作し、ドメイン名やディレクトリ構造などの http アプリケーションの一部の流用戦略を作成できます。 HAProxy そして柔軟性は、これだけを基にすると Nginx が LVS よりもはるかに多くの状況で使用できる主な理由の 1 つです。
2. 理論上、Nginx は ping が可能な限り負荷機能を実行できますが、これは逆に、LVS はネットワークの安定性に大きく依存します。
3. Nginx はインストールと設定が比較的簡単で、基本的にはエラーをログに出力することができます。 LVS の構成とテストには比較的長い時間がかかり、LVS はネットワークに大きく依存します。
3. 高い負荷圧力に耐えることができ、安定しています。ハードウェアが悪くなければ、通常は数万の同時実行をサポートでき、負荷の度合いは LVS よりも比較的小さいです。
4. Nginx は、Web ページを処理するサーバーから返されるステータス コードやタイムアウトなどの内部サーバー障害をポート経由で検出でき、エラーを返すリクエストを別のノードに再送信します。 URL の検出をサポートします。たとえば、ユーザーがファイルをアップロードしていて、アップロード処理中にアップロードを処理するノードが失敗した場合、Nginx は再処理のためにアップロードを別のサーバーに切り替え、大きなファイルがアップロードされると LVS が直接切断されます。重要なファイルを保存すると、ユーザーが不満を抱く可能性があります。
5. Nginx は、優れたロード バランサー/リバース プロキシ ソフトウェアであるだけでなく、強力な Web アプリケーション サーバーでもあります。 LNMP は近年非常に人気のある Web アーキテクチャでもあり、高トラフィック環境での安定性も非常に優れています。
6. Nginx は Web リバース アクセラレーション キャッシュとしてますます成熟しており、従来の Squid サーバーよりも高速です。リバース プロキシ アクセラレータとして使用することを検討できます。
7. Nginx は中間レベルのリバース プロキシとして使用できます。このレベルでは、Nginx と比較できるのは lighttpd だけです。ただし、lighttpd はまだ Nginx の完全な機能を備えていません。設定があまり明確ではなく読みにくいため、コミュニティ情報は Nginx よりもはるかに活発ではありません。
8. Nginx は静的 Web ページおよび画像サーバーとしても使用でき、この分野でのパフォーマンスは比類のありません。 Nginx コミュニティも非常に活発で、多くのサードパーティ モジュールがあります。

Nginx の欠点は次のとおりです:
1. Nginx は http、https、および電子メール プロトコルのみをサポートするため、適用範囲が狭いです。
2. バックエンドサーバーのヘルスチェックはポートを介した検出のみをサポートし、URL を介した検出はサポートしません。セッションの直接保持はサポートされていませんが、ip_hash を通じて解決できます。

LVS: Linux カーネル クラスターを使用して、優れたスケーラビリティ (Scalability)、信頼性 (Reliability)、および管理容易性 (Manageability) を備えた高性能、高可用性の負荷分散サーバーを実装します。

LVS の利点は次のとおりです: 1. ネットワークの第 4 層上で動作し、トラフィックが生成されないため、負荷分散ソフトウェアの中で最も強力なパフォーマンスが得られます。メモリと CPU リソースが比較的少ない。
2. 設定可能性は比較的低いですが、これは短所でもあり、長所でもあります。あまりにも多くの設定が必要ないため、人的エラーの可能性が大幅に減少します。
3. 強い負荷耐性があり、LVS+Keepalived などの完全なデュアルマシンホットバックアップソリューションを備えているため、安定して動作します。ただし、プロジェクトの実装で最もよく使用されるのは LVS/DR+Keepalived です。
4. トラフィックなし。LVS はリクエストを分散するだけであり、トラフィックはそれ自体から送信されません。これにより、バランサー IO のパフォーマンスは大量のトラフィックによって影響を受けません。
5. 適用範囲は比較的広いです。LVS はレイヤー 4 で動作するため、http、データベース、オンライン チャット ルームなど、ほぼすべてのアプリケーションの負荷を分散できます。

LVS の欠点は次のとおりです: 1. ソフトウェア自体は正規表現処理をサポートしておらず、動的と静的を分離できません。これが、Nginx/HAProxy+Keepalived の利点です。

2. Web サイト アプリケーションが比較的大規模な場合、LVS/DR+Keepalived の実装はより複雑になります。特に、その背後に Windows Server マシンがある場合、実装、設定、およびメンテナンスのプロセスはより複雑になります。 /HAProxy+Keepalived ははるかに簡単です。

HAProxy の機能は次のとおりです:

1. HAProxy は仮想ホストもサポートします。

2. HAProxy の利点は、セッション保持や Cookie ガイダンスのサポートなど、Nginx の欠点の一部を補うことができます。また、指定された URL を取得することによるバックエンド サーバーのステータスの検出もサポートします。
3. HAProxy は LVS に似ていますが、純粋に効率という点では負荷分散ソフトウェアです。HAProxy は Nginx よりも優れた負荷分散速度を持ち、同時処理においても Nginx よりも優れています。
4. HAProxy は、TCP プロトコルの負荷分散転送をサポートし、MySQL 読み取りの負荷分散、バックエンド MySQL ノードの検出と負荷分散を行うことができます。LVS+Keepalived を使用して、MySQL マスターとスレーブの負荷分散を行うことができます。
5. HAProxy のロード バランシング アルゴリズムには現在、次の 8 種類があります。
① ラウンドロビン、これは基本的にロード バランシングの機能です。これは、重みに基づいて、注意することをお勧めします。
③ minimumconn、つまり、最も接続されていないものが最初に処理されることを意味します。
④、source、つまり、リクエストのソース IP に基づいて、これはNginx の IP_hash メカニズムと同様に、セッションの問題を解決する方法として使用します。注意することをお勧めします。
⑤ ri、リクエストされた URI に基づく意味です。
⑥ rl_param、リクエストされた URL パラメータ 'balance url_param に基づく意味です。 ' URL パラメータ名が必要です。
⑦ hdr(name) は、HTTP リクエスト ヘッダーに基づいてロックされることを意味します。
⑧ rdp-cookie(name) は、cookie(name) に基づいてすべての TCP リクエストをロックおよびハッシュすることを意味します。

Nginx と LVS の比較の概要:
1. Nginx はネットワークの 7 層で動作するため、ドメイン名、ディレクトリ構造などの http アプリケーション自体の流用戦略を実装できます。これに対し、LVS は、そのような機能がないため、これだけで Nginx は LVS よりもはるかに多くの状況で使用できますが、Nginx のこれらの便利な機能により、LVS よりも調整しやすくなるため、あまりにも頻繁に触る必要があります。 、間違いを犯す可能性が高くなります。
2. 理論的には、ping が成功し、Web ページにアクセスできる限り、Nginx は接続できるのが大きな利点です。 Nginx は内部ネットワークと外部ネットワークを区別することもできます。内部ネットワークと外部ネットワークの両方を持つノードの場合、LVS はネットワーク環境にさらに依存します。同じネットワークセグメントでは、LVS はオフロードにダイレクトモードを使用します。その効果はより確実です。また、LVS がビジュアル IP として使用するには、ホスティング プロバイダーから少なくとも 1 つの IP を申請する必要があることにも注意してください。独自の IP を VIP として使用することはできないようです。優れた LVS 管理者になるには、ネットワーク通信について多くの知識をフォローアップして学ぶ必要があります。ネットワーク通信はもはや HTTP ほど単純ではありません。
3. Nginx はインストールと設定が比較的簡単で、基本的にエラーをログに出力できるため、テストにも非常に便利です。 LVS のインストール、構成、テストには比較的長い時間がかかります。LVS はネットワークに大きく依存しており、多くの場合、構成に問題があるのではなく、ネットワークの問題が原因となります。解決するのがさらに面倒です。
4. Nginx は高負荷にも耐えることができ、安定していますが、LVS にはいくつかのレベルがあります。Nginx はすべてのトラフィックを処理するため、マシンの IO と構成によって制限されます。
5. Nginx は、Web ページを処理するサーバーから返されるステータス コードやタイムアウトなどの内部サーバー障害を検出でき、エラーを返すリクエストを別のノードに再送信します。現在、LVS の ldirectd はサーバーの内部状態の監視もサポートしていますが、LVS の原理によりリクエストを再送信することはできません。たとえば、ユーザーがファイルをアップロードしていて、アップロード処理中にアップロードを処理するノードが失敗した場合、Nginx は再処理のためにアップロードを別のサーバーに切り替え、大きなファイルがアップロードされると LVS が直接切断されます。重要なファイルがある場合、ユーザーはこれに煩わされる可能性があります。
6. Nginx のリクエストの非同期処理は、ノード サーバーの負荷を軽減するのに役立ちます。Apache を使用して外部関係者に直接サービスを提供する場合、ナローバンド リンクが多数ある場合、Apache サーバーは大量のメモリを占有して解放できなくなります。もう 1 つの Nginx が Apache プロキシとして使用される場合、これらの狭帯域リンクは Nginx によってブロックされ、Apache にあまりにも多くのリクエストが積み重なることがなくなり、リソース使用量が大幅に削減されます。この点では、Squid 自体がキャッシュしないように設定されている場合でも、Squid を使用すると同じ効果が得られますが、Apache にとっては非常に役立ちます。
7. Nginx は http、https、および電子メールをサポートできます (電子メール機能はあまり使用されません)。この点で、LVS は Nginx よりも多くのアプリケーションをサポートします。使用に関しては、フロントエンドで採用される一般的な戦略は LVS である必要があります。つまり、DNS は LVS イコライザーに向けられる必要があります。LVS はその利点により、このタスクに非常に適しています。データベース IP や Web サービス サーバー IP などの重要な IP アドレスは、LVS によって管理するのが最適です。時間が経つにつれて、これらの IP アドレスはますます広く使用されるようになり、IP アドレスが変更されると障害が発生します。したがって、これらの重要な IP を LVS に引き渡してホスティングすることが最も安全です。そうすることの唯一の欠点は、必要な VIP の数が増えることです。 Nginx は LVS ノード マシンとして使用できます。第 1 に、Nginx の機能を活用できます。第 2 に、Nginx のパフォーマンスを活用できます。もちろん、このレベルでは Squid を直接使用することもできます。Squid の機能は Nginx に比べてはるかに弱く、パフォーマンスも Nginx に劣ります。 Nginx は中間レベルのプロキシとしても使用できます。このレベルでは、Nginx に対抗できるのは lighttpd だけですが、lighttpd はまだそれができていません。 Nginx は完全に機能しますが、構成はそれほど明確ではなく、読みやすいものではありません。さらに、中間レベルのエージェントの IP も重要であるため、中間レベルのエージェントにも VIP と LVS を持たせるのが最も完璧なソリューションです。特定のアプリケーションを詳細に分析する必要がある場合は、比較的小規模な Web サイト (1 日の PV が 1,000 万未満) であれば、Nginx を使用しても問題ありません。マシンの数が多い場合でも、LVS を使用できます。 ; 大規模な Web サイトや重要なサービスの場合、マシンが問題にならない場合は、LVS の使用を検討してください。

現在のネットワーク負荷分散の使用法は、Web サイトの規模が拡大するにつれて、さまざまな段階に応じてさまざまなテクノロジーを使用することです:

最初の段階: シングルポイント負荷分散に Nginx または HAProxy を使用します。 この段階では、サーバーの規模が大きくなります。課金サーバーと単一データベースのモデルでは、ある程度の負荷分散が必要ですが、それでも規模は小さく、専門のメンテナンス チームによる保守は必要ありませんし、大規模な Web サイトの展開も必要ありません。このように、現時点では、Nginx または HAproxy を使用することが最初の選択肢となり、レイヤー 7 より上の HTTP プロトコルを使用するだけで簡単に開始できます。これが第一の選択です。

第 2 段階: ネットワーク サービスがさらに拡大するにつれて、シングルポイントの Nginx では十分ではなくなり、LVS または Array のノードとして使用されることが第一の選択肢となります。または Array 企業の規模と予算に応じて選択してください。Array のアプリケーション配信機能は非常に強力で、商用用途では F5 よりもはるかに優れています。ただし、一般的に、この段階では関連する人材がビジネスの改善に追いつくことができないため、商用負荷分散を購入することが唯一の方法となっています。

第 3 段階: 現時点では、ネットワーク サービスが主流の製品になり、会社の人気がさらに拡大するにつれて、カスタマイズの開発という点でも、関連する人材の能力と量も増加しました。自社製品への適合とコスト削減 オープンソースのLVSに関しては、LVSが第一の選択肢となっており、現時点ではLVSが主流となるでしょう。
最終的な理想的な基本アーキテクチャは、Array/LVS — Nginx/Haproxy — Squid/Varnish — AppServer です。

このブログ投稿は http://www.ha97.com/5646.html から転載されています

上記では、Nginx/LVS/HAProxy ロード バランシング ソフトウェアの長所と短所を、関連する側面も含めて詳細に紹介 (概要) し、PHP チュートリアルに興味のある友人に役立つことを願っています。