リバースプロキシ（nginx、haproxy）はいくつありますか？
Nginx、haproxy、Apacheを使用してHA（高可用性）クラスターをセットアップしています。
私はnginxとhaproxyについて素晴らしいことを読んでいます。人々はどちらかを選ぶ傾向がありますが、私は両方が好きです。 Haproxyは、nginxの単純なラウンドロビンよりも負荷分散に柔軟性があります（アップストリームフェアパッチを使用している場合でも）。ただし、クラスターへのエントリの時点で、特にhttps以外をhttpsにリダイレクトするためのnginxを保持したいと思います。
一方、nginxは静的コンテンツを提供するのにはるかに高速であり、大量のRAMを消費するのが大好きな強力なApacheの負荷を軽減します！
これが私の計画したセットアップです：
ロードバランサー：nginxはポート80/443でリッスンし、proxy_forwardsは同じサーバー上の8080でhaproxyをリッスンして、複数のノード間の負荷分散を行います。
ノード：ノードのnginxは、8080でhaproxyからのリクエストをリッスンします。コンテンツが静的な場合は、それを提供します。ただし、バックエンドスクリプト（私の場合はPHP）の場合は、別のポート番号でリッスンしている同じノードサーバー上のApache2にプロキシ転送します。
技術的にはこの設定は機能しますが、私の懸念は、いくつかのプロキシを通過するリクエストがあるとリクエストが遅くなるかどうかです。バックエンドはサービスであるため、ほとんどのリクエストはPHPリクエストです（つまり、nginx-> haproxy-> nginx-> Apacheからグローイングします）。
考え？乾杯
純粋にパフォーマンスの観点から、アーキテクチャを変更するときに httperf のようなツールを使用することが非常に重要であると想定するのではなく、ベンチマークでこれらの決定を下してください。
アーキテクチャ哲学の観点から、アプリケーションサーバーにnginxとApacheの両方がある理由に少し興味があります。 Nginxは静的コンテンツに対応し、ほとんどのバックエンドフレームワーク/テクノロジー（Rails、PHP FastFCGIなどを介して）など）を効率的に処理するため、最終的なApacheレイヤーを削除します。これも限られた理解によるものです。あなたが使用しているテクノロジーの中で、私が期待していないためにそれが必要になる場合があります（しかし、その場合は、常にアプリケーションサーバーにnginxをドロップし、Apacheを使用するだけでかまいません）。適切に構成されている場合の静的コンテンツ）。
現在、私は負荷分散サーバーでnginx-> haproxyを使用し、アプリサーバーでnginxを使用して多くの成功を収めています。 Willy Tarreauが述べたように、nginxとhaproxyは非常に高速な組み合わせであるため、フロントエンドで両方を使用する速度について心配する必要はありませんが、レイヤーを追加すると複雑さが増し、ポイント数も増えることに注意してください。失敗。
あなたのセットアップはますます一般的になっています。心配する必要はありません。 nginxとhaproxyはどちらも、HTTPリクエストの処理と転送が非常に高速です。両方が非常にうまく組み合わされて、彼らの仕事を非常にうまくやります。選択する必要はありません。それらの両方をインストールし、幸せになります。そうすることで、静的ファイルを非常に迅速に配信し、動的サーバーのスムーズなスケーリングを保証します。
プロキシの数を気にする必要はありません。多くの場合、問題は「プロキシを使用できますか」です。時にはそれは実用的ではありません。あなたが1つを持つことができるならば、あなたは2つまたは3つを持つことができます。多くの複雑なアーキテクチャには、最大5〜6レベルのプロキシが含まれ、それでも非常に適切に拡張できます。 1つの点に注意する必要があります。1台のマシンにこのマシンのCPUコアよりも多くのプロキシをインストールしないでください。そうしないと、プロキシは高負荷でCPU時間を共有する必要があり、応答時間が長くなります。しかし、これがマシン上のnginxとhaproxyで発生するためには、これは1秒あたり数万のリクエストのロードを意味します。これは今日のすべての人の問題ではありません。
また、同じシステム上でシングルスレッドプロキシをApache、Javaなどの大規模なマルチスレッド/マルチプロセスソフトウェアと混合することは避けてください。
これらのルールを考慮に入れたら、ニーズに合ったアーキテクチャを描き、ボックスに名前を付け、それらを適切な方法で組み合わせてインストールします。
複雑さは、コード/設計と同じくらいスケーリングの障害になる可能性があることを覚えておいてください。実装の詳細をますます多くのサービスと構成ファイルに分散させると、スケールアウトがより困難になり、チームに不慣れな人にとっては学習曲線が長くなり、管理するソフトウェア/パッケージが増え、トラブルシューティングが複雑になります。より多くの潜在的な障害ポイントなど。just-Apacheまたはjust-nginxで問題がなかったサイトに4プロキシ層スタックを設定することは、基本的に「時期尚早の最適化」のsysadminバージョンです。
ワニス を使用しないのはなぜですか？このようにして、キャッシング、プロキシ、およびロードバランシングを1つのアプリケーションに組み合わせれば、アーキテクチャの観点から見るとすごくすっきりします。
スケールアウトスケーリングはかなり驚異的です。ロードバランサーがノードの実際の状態に基づいてよりインテリジェントな決定を行うことができるという利点もあります。
構成ファイルを使用すると、ヘッダーを調べて、静的コンテンツと動的コンテンツをどこから提供するかを決定できます。
大量の静的コンテンツを提供することを本当に予測している場合、おそらくそのほとんどをCDNにシャントすることは費用効果の高いソリューションになるでしょうか。
「技術的にはこの設定は機能しますが、私の懸念は、いくつかのプロキシを通過するリクエストがあると、リクエストが遅くなるかどうかです。」
はい。ただし、スケールアウトしたシステムのネットワーク側に注意を払う場合は特にそうです。それは頑強でなければなりません。
一般に、スケールアウトを取得して多くのマシンに作業を分散できるようにするには、通常、個々のマシンの一部またはすべてでパフォーマンスをいくらか犠牲にする必要があります。それは避けられないことであり、通常は心配する価値のないことです（テストを超えて、全体のパフォーマンスが風を吸い込んでいることを確認するために常に行う必要があります）。部品の最適化は、全体を最適化するための最良の方法であるとは限りません。