序文
2016年に更新します。状況は進化しており、すべてのサーバーは改善されており、すべてがSSLをサポートしており、Webはこれまで以上に素晴らしいものになっています。
特に明記しない限り、以下はビジネスおよび新興企業の専門家を対象としており、数千から数百万のユーザーをサポートしています。
これらのツールとアーキテクチャには、多くのユーザー/ハードウェア/お金が必要です。これを自宅のラボで試すことも、ブログを運営することもできますが、それはあまり意味がありません。
原則として、シンプルに保ちたいことを忘れないでください。追加されるすべてのミドルウェアは、維持する必要があるミドルウェアの別の重要な部分です。追加するものが何もないとき、削除するものが残っていないとき、完全性は達成されません。
いくつかの一般的で興味深い展開
HAProxy（バランシング）+ nginx（PHPアプリケーション+キャッシング）
Webサーバーはphpを実行しているnginxです。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を話さなければならない場合でも、WebサーバーはSSLを話せません（特に、このHAProxy-WebServerリンクはプライベートユーザー情報とEC2を通過します）。ローカル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終了
同様の選択肢：nginx（ロードバランサーとして構成可能な多目的Webサーバー）
さまざまな選択肢：クラウド（Amazon ELB、Googleロードバランサー）、ハードウェア（F5、フォーティネット、citrixネットスケーラー）、その他＆世界全体（DNS、エニーキャスト、CloudFlare）
HAProxyは何をし、いつ使用する必要がありますか？
負荷分散が必要なときはいつでも。HAProxyはgo toソリューションです。
非常に安いか、早くて汚いか、スキルがない場合を除き、ELBを使用できます：D
銀行/政府/同様の状況で、ハード要件のある独自のデータセンターを使用する必要がある場合を除きます（専用インフラストラクチャ、信頼できるフェイルオーバー、2層のファイアウォール、監査スタッフ、ダウンタイム1分あたりx％を支払うSLA、すべて1） 30台のアプリケーションサーバーを含むラックの上部に2つのF5を配置できます。
100k HTTP（S）[およびマルチサイト]を通過する場合を除き、それらの前に[グローバル]負荷分散の層（cloudflare、DNS、エニーキャスト）を持つHAProxyを複数持つ必要があります。理論的には、グローバルバランサーはWebサーバーと直接通信してHAProxyを捨てることができます。ただし、通常、データセンターへのパブリックエントリポイントとしてHAProxyを保持し、ホスト間で公平にバランスを取り、分散を最小限に抑えるために高度なオプションを調整する必要があります。
個人的な意見：ひとつの真の目的に完全に専念する、小規模で、オープンなオープンソースプロジェクト。最も簡単な構成（1ファイル）の中で、私が人生で出会った中で最も有用で信頼性の高いオープンソースソフトウェアです。
Nginx：吸わないApache
主な特長：
- WebServer HTTPまたはHTTPS
- CGI / PHP /その他でアプリケーションを実行する
- URLリダイレクト/書き換え
- アクセス制御
- HTTPヘッダーの操作
- キャッシング
- 逆プロキシ
同様の代替案：Apache、Lighttpd、Tomcat、Gunicorn ...
Apacheは事実上のWebサーバーでありhttpd.conf、壊れたリクエスト処理アーキテクチャの上にある数十のモジュールと数千の行の巨大なクラスターファックとしても知られています。nginxは、これらすべてを、少ないモジュールで（わずかに）簡単な構成と優れたコアアーキテクチャでやり直しました。
nginxは何をし、いつ使用する必要がありますか？
Webサーバーは、アプリケーションを実行するためのものです。アプリケーションがnginxで実行するように開発されたとき、nginxが既にあり、すべての機能を使用することもできます。
アプリケーションがnginxで実行されることを意図しておらず、nginxがスタックのどこにも見つからない場合（Javaショップの誰か？）を除いて、nginxにはほとんど意味がありません。Webサーバー機能は現在のWebサーバーに存在する可能性が高く、他のタスクは適切な専用ツール（HAProxy / Varnish / CDN）により適切に処理されます。
除き（Gunicorn誰を？）あなたのウェブサーバ/アプリケーション、構成するハードの機能を、欠けている、および/またはあなたがそれを見てではなく、ダイの仕事をしたい、あなたはURLを実行する（各ノード上すなわちローカル）前にnginxのを置いてもよいとき書き換え、301リダイレクトの送信、アクセス制御の実施、SSL暗号化の提供、HTTPヘッダーのオンザフライ編集を行います。[これらはウェブサーバーに期待される機能です]
ニス：キャッシングサーバー
主な特長：
- キャッシング
- 高度なキャッシング
- 細粒度キャッシング
- キャッシング
同様の選択肢：nginx（キャッシュサーバーとして構成可能な多目的Webサーバー）
さまざまな選択肢：CDN（Akamai、Amazon CloudFront、CloudFlare）、ハードウェア（F5、Fortinet、Citrix Netscaler）
Varnishは何をし、いつ使用する必要がありますか？
キャッシングのみを行います。通常、努力する価値はなく、時間の無駄です。代わりにCDNを試してください。キャッシングは、Webサイトを実行する際に最後に気をつけなければならないことに注意してください。
写真やビデオに関するウェブサイトを独占的に運営している場合を除き、CDNを徹底的に調べ、キャッシュについて真剣に検討する必要があります。
独自のデータセンターで独自のハードウェアの使用を余儀なくされ（CDNはオプションではない）、静的ファイルの配信がWebサーバーでひどい場合（Webサーバーの追加が役に立たない場合）を除き、Varnishは最後の手段です。
ほぼ静的、まだ複雑、動的に生成されたコンテンツ（次の段落を参照）を持つサイトがある場合を除き、VarnishはWebサーバーの処理能力を大幅に節約できます。
静的キャッシュは2016年に過大評価されています
キャッシングはほとんど構成不要で、無料で、時間もかかりません。CloudFlare、CloudFront、Akamai、MaxCDNに登録するだけです。この行を書くのにかかる時間は、キャッシュのセットアップにかかる時間よりも長く、手に持っているビールはCloudFlareサブスクリプションの中央値よりも高価です。
これらのサービスはすべて、静的* .css * .js * .pngなどの場合にそのまま使用できます。実際、彼らは主Cache-ControlにHTTPヘッダーのディレクティブを尊重します。キャッシュの最初のステップは、適切なキャッシュディレクティブを送信するようにWebサーバーを構成することです。どのCDN、どのVarnish、どのブラウザが中間にあるかは関係ありません。
パフォーマンスに関する考慮事項
Varnishは、平均的なWebサーバーがブログで猫の写真を配信するのを窒息させていたときに作成されました。最近では、平均的な最新のマルチスレッド非同期流行語駆動型Webサーバーの単一インスタンスが、子猫を確実に全国に配信できます。の礼儀sendfile()。
私が取り組んだ最後のプロジェクトのいくつかの簡単なパフォーマンステストを行いました。単一のTomcatインスタンスは、HTTP経由で毎秒21 000〜33 000の静的ファイルを処理できます（さまざまなHTTP /クライアント接続カウントで20B〜12kBのファイルをテストします）。持続的なアウトバウンドトラフィックは2.4 Gb / sを超えています。本番環境では、1 Gb / sのインターフェイスのみが使用されます。ハードウェアよりも良いことはできません。ワニスを試しても意味がありません。
複雑な変化する動的コンテンツのキャッシュ
CDNおよびキャッシングサーバーは通常、などのパラメーターを持つURLを?article=1843無視し、セッションCookieまたは認証されたユーザーを含む要求を無視し、application/jsonfrom を含むほとんどのMIMEタイプを無視し/api/article/1843/infoます。使用可能な構成オプションはありますが、通常はきめ細かくなく、むしろ「すべてまたは何も」ではありません。
Varnishは、カスタムの複雑なルール（VCLを参照）を使用して、キャッシュ可能なものとそうでないものを定義できます。これらのルールは、特定のコンテンツをURI、ヘッダー、現在のユーザーセッションCookie、MIMEタイプおよびコンテンツ別にキャッシュできます。これにより、非常に具体的な負荷パターンに対してWebサーバーの処理能力を大幅に節約できます。それは、ワニスが便利で素晴らしいときです。
結論
これらのすべての部品、それらをいつ使用し、どのように組み合わせるかを理解するのに時間がかかりました。これがあなたのお役に立てば幸いです。
それは非常に長いことがわかりました（書くのに6時間。OMG！：O）。たぶん私はそれについてブログか本を始めるべきです。楽しい事実：回答の長さに制限はないようです。