WebアプリケーションとWebサーバーを分離しておくことの具体的なメリットは？
私たちはウェブアプリケーションを開発し、維持しています。現在の設定では、データベースサーバー、アプリケーションサーバー、Webサーバーの3層システムを使用しています。
ここまでは順調ですね。
私たちが直面している問題は、理論上このセットアップは、これらのマシン間の負荷のバランスを取り、必要に応じて新しいシャードを挿入するのに役立つように設計されていることです。実際には、これが私たちの奥の部屋のネットワークに与える負担は深刻なボトルネックになりつつあります。
静的ファイルを提供するという問題もあります。現在の設定のため。これらは、アプリケーションによって処理されるか（着信要求の処理に使用できるFastCGIプロセスを使い果たす）、または最初にアプリケーションを実行しているマシンのローカルプロキシとしてWebサーバーを使用する必要があります。
その場合、質問は次のようになります。
Webサーバーとアプリケーションサーバーを1つにまとめるだけです。構成の簡素化により、およびアクセスの直接性（TCPではなくローカルソケット）。また、Webサーバーを介して静的ファイルを提供する機能が向上すると、パフォーマンスが向上する可能性があります。または私が見逃したオーバーヘッド要因はありますか？
一般的に言って、私は分割アーキテクチャのファンです。DBサーバーファーム、「パブリックwww」サーバーファーム（商用Webサイト）、およびアプリサーバーファームです。必要に応じて、ミドルウェアの他のレイヤーを使用することもできます。
この背後にある論理は古いです。基本的に、パブリックwwwサーバーは機密データにアクセスする必要がないため、www.mycompany.comを突っついている好奇心旺盛なハッカーが、マーケティングサイトを危険にさらす可能性があります。彼らは他に何も得られませんでした。
ここに他のいくつかの一般的なアイデアがあります...
Re：奥の部屋のネットワーク負荷。FastCGIホストに接続することによるトラフィック負荷について話している場合、それらのマシンにWebサーバーを固定し、外部と直接通信させることをお勧めします。
覚えておくべきことの1つは、セキュリティが侵害された場合にデータベースの分離/保護を維持することです。これは、FastCGIのものをWebサーバーにプッシュし、より軽量なものを作成して、データベース...
（私たちが何か他のことについて話しているなら、私に知らせてください、そして私はそれでスイングをします:-)
再：静的ファイルの問題、これを解決する方法はいくつかあります。
静的データのコピーを送信する必要のあるすべてのサーバーに配置します。
これを「ディスクが安い」方法と呼びましょう。これにより、静的コンテンツをホストする単一のボックスに大量の負荷がかかるのを防ぎ、単一障害点を排除します。欠点は、そのコンテンツを何らかの方法で同期する必要があることです（デプロイメントスクリプト、cron'd rsync、cvs/git/svnなど）。フロントエンドサーバーにキャッシュインフラストラクチャをインストールします
これは上記の「ディスクが安い」と同様のソリューションです。静的コンテンツを含むバックエンドサーバーが1つだけあり、フロントエンドサーバーが必要な場合はコピーをキャッシュします$ LIFETIME、したがって同期スクリプトの必要性を排除します（キャッシングインフラストラクチャがそれを行います）。静的コンテンツをコンテンツ配信ネットワークに配置します
これは実際にはSSL関連の作業を行っていない場合にのみ機能します-商用CDNは負荷の問題を解決し、ユーザーがコンテンツを取得できる地理的に分散したポイントを提供します。欠点は、CDNも保護されていない限り、SSLを使用するサイトでこれを行うと、ほとんどのブラウザーが適切に機能することです（それでも、偏執的なブラウザーは当然文句を言うはずです）。