注文：1. nginx 2.ワニス3. haproxy 4.ウェブサーバー？
フローでこれらすべてを組み合わせることが推奨されるのを見てきましたが、機能が重複しているようですので、実際のWebサーバーにアクセスする前に3つの異なるプログラムを通過する必要がある理由を詳しく調べたいと思います。
nginx：
- ssl：はい
- 圧縮：はい
- キャッシュ：はい
- バックエンドプール：はい
ワニス：
- ssl：いいえ（stunnel？）
- 圧縮：？
- キャッシュ：はい（主な機能）
- バックエンドプール：はい
haproxy：
- ssl：no（stunnel）
- 圧縮：？
- キャッシュ：いいえ
- バックエンドプール：はい（主な機能）
メインのWebサーバーの前でこれらすべてを連鎖させて、主要な機能の利点の一部を得るための意図はありますか？
非常に多くのデーモンが一緒にストリームして同じようなことをするのは非常に壊れやすいようです。
導入と注文の設定はどのようなもので、その理由は何ですか。
簡単に言えば..
HaProxyは、市場で最高のオープンソースロードバランサーです。
ワニスは、市場で最高のオープンソースの静的ファイルキャッシュです。
Nginxは、市場で最高のオープンソースウェブサーバーです。
（もちろん、これは私や他の多くの人々の意見です）
ただし、一般に、すべてのクエリがスタック全体を通過するわけではありません。
すべてがhaproxyとnginx/multiple nginxを通過します。
唯一の違いは、静的リクエストの場合、ワニスを「固定」することです。
- リクエストは冗長性とスループットのためにロードバランスされます（良い、それはスケーラブルな冗長性です）
- 静的ファイルへの要求は最初にニスキャッシュにヒットします（良い、それは高速です）
- 動的リクエストは直接バックエンドに送られます（素晴らしい、ワニスは使用されません）
全体として、このモデルはスケーラブルで拡大するアーキテクチャに適合します（複数のサーバーがない場合はhaproxyを削除してください）
これが役に立てば幸い：D
注：実際には、SSLクエリのポンドも導入します：D
SSLリクエストを復号化し、標準リクエストをバックエンドスタックに渡す専用サーバーを用意することができます：D（スタック全体をより速く簡単にする）
序文
2016年に更新。すべてのサーバーが改善され、すべてがSSLをサポートし、Webはこれまでになく驚異的です。
特に明記しない限り、以下はビジネスや新興企業の専門家を対象としており、数千から数百万のユーザーをサポートしています。
これらのツールとアーキテクチャには、多くのユーザー/ハードウェア/お金が必要です。これをホームラボやブログで試すことができますが、あまり意味がありません。
一般的なルールとして、シンプルにすることを忘れないでください。追加されたすべてのミドルウェアは、維持すべきもう1つの重要なミドルウェアです。 追加するものが何もないが、削除するものが残っていない場合、完璧は達成されません。
一般的で興味深い展開
HAProxy（バランス）+ nginx（phpアプリケーション+キャッシング）
ウェブサーバーはnginxでphpを実行しています。 nginxがすでに存在する場合は、キャッシングとリダイレクトも処理する可能性があります。
_HAProxy ---> nginx-php
A ---> nginx-php
P ---> nginx-php
r ---> nginx-php
o ---> nginx-php
x ---> nginx-php
y ---> nginx-php
_HAProxy（バランス）+ Varnish（キャッシュ）+ Tomcat（Javaアプリケーション）
HAProxyはリクエストURI（* .jpg * .css * .js）に基づいてVarnishにリダイレクトできます。
_HAProxy ---> Tomcat
A ---> Tomcat
---> Tomcat
P ---> Tomcat <----+
r ---> Tomcat <---+|
o ||
x ---> varnish <--+|
y ---> varnish <---+
_HAProxy（バランシング）+ nginx（ホストへのSSLおよびキャッシング）+ Webサーバー（アプリケーション）
誰もがSSL（特にEC2を通過するプライベートユーザー情報とのこのHAProxy-WebServerリンク）を話す必要があるにもかかわらず、WebサーバーはSSLを話しません。ローカルnginxを追加すると、SSLをホストに提供できます。 nginxが存在するようになると、キャッシュやURLの書き換えも行われる可能性があります。
注：ポートリダイレクト443：8080が発生していますが、機能の一部ではありません。ポートのリダイレクトを行う意味はありません。ロードバランサーは、webserver：8080と直接通信できます。
_ (nginx + webserver on same Host)
HAProxy ---> nginx:443 -> webserver:8080
A ---> nginx:443 -> webserver:8080
P ---> nginx:443 -> webserver:8080
r ---> nginx:443 -> webserver:8080
o ---> nginx:443 -> webserver:8080
x ---> nginx:443 -> webserver:8080
y ---> nginx:443 -> webserver:8080
_ミドルウェア
HAProxy：ロードバランサー
主な機能：
- 負荷分散（TCP、HTTP、HTTPS）
- 複数のアルゴリズム（ラウンドロビン、ソースIP、ヘッダー）
- セッションの永続性
- SSL終了
Similar Alternatives：nginx（ロードバランサーとして構成可能な多目的Webサーバー）
さまざまな代替手段：クラウド（Amazon ELB、Googleロードバランサー）、ハードウェア（F5、フォーティネット、citrixネットスケーラー）、その他＆ワールドワイド（DNS、エニーキャスト、CloudFlare）
HAProxyは何をしますか、いつ使用する必要がありますか？
負荷分散が必要なときはいつでも。 HAProxyはソリューションへの移行です
例外非常に安くしたい場合ORクイック＆ダーティーORあなたはしません ' t利用可能なスキルがあれば、ELBを使用できます：D
例外厳しい要件（専用インフラストラクチャ、信頼できるフェイルオーバー、2層のファイアウォール）を備えた独自のデータセンターを使用する必要がある銀行/政府/類似の場合監査項目、SLAダウンタイムの1分あたりx％を支払う、オールインワン）次に、30のアプリケーションサーバーを含むラックの上に2つのF5を配置できます。
例外100k HTTP（S）[およびマルチサイト]を超える場合は、が必要です。 multiplesHAProxyの前に[グローバル]ロードバランシングのレイヤー（cloudflare、DNS、エニーキャスト）。理論的には、グローバルバランサーはWebサーバーと直接通信して、HAProxyを破棄できます。ただし、通常は、HAProxyをデータセンターへのパブリックエントリポイントとして維持し、ホスト間で公平にバランスを取り、分散を最小限に抑えるように詳細オプションを調整する必要があります。
Personal Opinion：完全に1つの真の目的に特化した、小規模な、オープンソースプロジェクト。最も簡単な構成（1つのファイル）の中で、私が出会った中で最も便利で信頼性の高いオープンソースソフトウェア。
Nginx：吸わないApache
主な機能：
- WebServer HTTPまたはHTTPS
- CGI/PHP /その他でアプリケーションを実行する
- URLリダイレクト/書き換え
- アクセス制御
- HTTPヘッダーの操作
- キャッシング
- リバースプロキシ
Similar Alternatives：Apache、Lighttpd、Tomcat、Gunicorn ...
Apacheは事実上のWebサーバーであり、数十のモジュールと数千行の巨大なクラスタファックとしても知られていますが、壊れた要求処理アーキテクチャの上に_httpd.conf_がありました。 nginxは、すべてをやり直し、モジュールを減らし、（わずかに）構成をシンプルにし、コアアーキテクチャを改善します。
Nginxは何をしますか、いつ使用する必要がありますか？
ウェブサーバーは、アプリケーションを実行するためのものです。 nginxで実行するようにアプリケーションを開発すると、すでにnginxがあり、そのすべての機能を使用できます。
例外アプリケーションがnginxで実行することを意図しておらず、nginxがスタック（Javaショップの誰か？） nginxで。 Webサーバー機能は現在のWebサーバーに存在する可能性が高く、他のタスクは適切な専用ツール（HAProxy/Varnish/CDN）でより適切に処理されます。
例外Webサーバー/アプリケーションに機能が不足している場合、構成が困難な場合、および/またはそれを見るよりも仕事を中止したい場合（Gunicornの誰か？）、次に、nginxを前に（つまり、各ノードでローカルに）配置して、URL書き換えを実行し、301リダイレクトを送信し、アクセス制御を適用し、SSL暗号化を提供し、HTTPヘッダーをオンザフライで編集します。 [これらはウェブサーバーに期待される機能です]
ワニス：THEキャッシングサーバー
主な機能：
- キャッシング
- 高度なキャッシング
- ファイングレインキャッシング
- キャッシング
Similar Alternatives：nginx（キャッシングサーバーとして構成可能な多目的Webサーバー）
さまざまな代替案：CDN（Akamai、Amazon CloudFront、CloudFlare）、ハードウェア（F5、Fortinet、Citrix Netscaler）
Varnishは何をするもので、いつ使用する必要がありますか？
キャッシングのみを行い、キャッシングのみを行います。これは通常、努力する価値がなく、時間の無駄です。代わりにCDNを試してください。キャッシングは、Webサイトを実行するときに注意すべき最後のことです。
例外写真またはビデオについてのみWebサイトを実行している場合は、CDNを十分に検討し、キャッシュについて真剣に検討する必要があります。
例外独自のデータセンターで独自のハードウェアを使用する必要があり（CDNはオプションではありません）、Webサーバーが静的ファイルを配信するのがひどい場合（Webサーバーを追加しても役に立たない）次にVarnishは最後の手段です。
Exceptmostly-static-yet-complex-dynamically-generated-content（次の段落を参照）を含むサイトがある場合、ワニスは大幅に節約できますあなたのウェブサーバーの処理能力の。
静的キャッシングは2016年に過大評価されています
キャッシングは、構成、お金、時間をほとんど必要としません。 CloudFlare、CloudFront、Akamai、MaxCDNをサブスクライブするだけです。この行を書くのにかかる時間は、キャッシングのセットアップにかかる時間よりも長く、手に持っているビールはCloudFlareサブスクリプションの中央値よりも高価です。
これらのサービスはすべて、静的な* .css * .js * .pngなどの設定なしで機能します。実際、それらは主にHTTPヘッダーの_Cache-Control_ディレクティブを尊重します。 キャッシュの最初のステップは、適切なキャッシュディレクティブを送信するようにWebサーバーを構成することです。どのCDN、どのワニス、どのブラウザーが途中にあるかは関係ありません。
パフォーマンスに関する考慮事項
Varnishは、平均的なWebサーバーがブログで猫の写真を提供するために窒息していたときに作成されました。今日では、平均的な最新のマルチスレッド非同期流行語主導のWebサーバーの単一インスタンスで、子猫を国全体に確実に配信できます。 sendfile() 提供。
私が取り組んだ最後のプロジェクトについて、いくつかの簡単なパフォーマンステストを行いました。単一のTomcatインスタンスは、HTTPを介して毎秒21 000〜33 000の静的ファイルを処理できます（さまざまなHTTP /クライアント接続数でファイルを20B〜12kBでテストします）。持続する送信トラフィックは2.4 Gb /秒を超えています。本番環境には1 Gb /秒のインターフェイスしかありません。ハードウェア以上のことはできません。ワニスを試しても意味がありません。
動的コンテンツを変更する複雑なキャッシュ
CDNおよびキャッシングサーバーは通常、_?article=1843_のようなパラメーターを持つURLを無視し、セッションCookieまたは認証されたユーザーによる要求を無視し、_application/json_から_/api/article/1843/info_までのほとんどのMIMEタイプを無視します。利用可能な設定オプションがありますが、通常は細かい設定ではなく、「すべてか何もない」です。
Varnishには、カスタムの複雑なルール（VCLを参照）を設定して、キャッシュ可能なものとそうでないものを定義できます。これらのルールは、特定のコンテンツをURI、ヘッダー、現在のユーザーセッションCookie、MIMEタイプ、およびコンテンツすべてでキャッシュできます。これにより、非常に特定の負荷パターンに対して、Webサーバーの処理能力を大幅に節約できます。それは、ワニスが便利で素晴らしいときです。
結論
これらすべての要素を理解し、いつ使用し、どのように組み合わせるかを理解するのにしばらく時間がかかりました。これがお役に立てば幸いです。
それはかなり長いことがわかりました（書くのに6時間。OMG！：O）。多分私はそれについてブログか本を始めるべきです。面白い事実：回答の長さに制限はないようです。
3つのツールが共通の機能を共有していることは事実です。ほとんどのセットアップは、3のうちの2の任意の組み合わせで問題ありません。それは、その主な目的が何であるかに依存します。アプリケーションサーバーが静的（たとえば、nginx）で高速であることがわかっている場合は、キャッシュを犠牲にすることを受け入れるのが一般的です。数十または数百のサーバーをインストールし、それらを最大限に活用したり、問題のトラブルシューティングを行ったりする必要がない場合は、負荷分散機能を犠牲にするのが一般的です。どこにでも多くのコンポーネントを持つ分散アプリケーションを実行する場合は、一部のWebサーバー機能を犠牲にするのが一般的です。それでも、一部の人々はそれらすべてで興味深い農場を建設します。
3つの固体製品について話していることを覚えておいてください。通常、それらの負荷を分散する必要はありません。フロントSSLが必要な場合は、リバースプロキシとして最初にnginxで問題ありません。あなたがそれを必要としないならば、それから正面のニスは大丈夫です。次に、haproxyを配置してアプリの負荷を分散できます。ファイルタイプやパスに応じて、haproxy自体で別のサーバーファームに切り替えることもできます。
重いDDoS攻撃から保護する必要がある場合があり、前のhaproxyが他の攻撃よりも適しています。
一般に、選択の間にどのような妥協をするかについて心配する必要はありません。現在および将来のニーズに最適な柔軟性を得るために、それらを組み立てる方法を選択する必要があります。そのうちのいくつかを複数回積み重ねても、ニーズによってはそれが正しい場合もあります。
これが役立つことを願っています！
他のすべての回答は2010年より前なので、更新された比較を追加します。
Nginx
- フルWebサーバー、他の機能も使用できます。例：HTTP圧縮
- SSLサポート
- Nginxは最初から軽量になるように設計されているため、非常に軽量です。
- ニスに近いキャッシングパフォーマンス
- HAProxy負荷分散パフォーマンスに近い
ワニス
- 複雑なキャッシングシナリオやアプリケーションとの統合に最適です。
- 最高の静的ファイルキャッシュ
- SSLサポートなし
- メモリとCPUイーター
Haproxy
- ハードウェアロードバランサーに匹敵する、最先端のロードバランシング機能に最適なロードバランサー
- SSLは1.5.0以降でサポートされています
- よりシンプルで、http実装のない単なるtcpプロキシであるため、より速く、バグが発生しにくくなります。
したがって、最善の方法は、適切な順序でそれらすべてを実装することです。
ただし、一般的な目的では、Nginxが最適ですすべてに対して平均以上のパフォーマンスが得られるため：キャッシュ、リバースプロキシ、負荷分散、リソース使用率のオーバーヘッドはほとんどありません。そして、SSLと完全なWebサーバー機能があります。
Varnishは負荷分散をサポートしています： http://www.varnish-cache.org/trac/wiki/LoadBalancing
Nginxは負荷分散をサポートしています： http://wiki.nginx.org/NginxHttpUpstreamModule
私はこれをニス+スタンネルで構成するだけです。他の理由でnginxが必要な場合は、nginx + varnishを使用します。 nginxにSSL接続を受け入れさせ、それらをワニスにプロキシしてから、httpを介してワニスがnginxと通信できるようにします。
Nginx（またはApache）はVarnishよりもいくぶん汎用的なツールであるため、一部の人々はそれらをミックスに投入する可能性があります。たとえば、プロキシ層でコンテンツを変換する場合（XDV、Apacheフィルターなどを使用）、これらのいずれかが必要になります。これは、Varnishがそれを行うことができないためです。一部の人々はこれらのツールの構成に慣れているだけなので、Apache/nginx/haproxyをロードバランサーとしてすでに理解しているため、Varnishを単純なキャッシュとして使用し、別のレイヤーでロードバランシングを実行する方が簡単です。