uWSGIの組み込みロードバランサーとnginxの使用
python wsgiを介して公開され、それを世界にデプロイしようとしていたアプリがあります。そこから提供される静的アセットはありません。アプリは単一のマシンにデプロイされます。 uwsgiを使用してwsgiアプリを提供し、2つのオプションを考えることができます。
マシン上の単一のuwsgiインスタンスを介してサービスを提供します（使用するワーカー/プロセスの数を増やして調整し、2 *＃コアから開始する可能性があります）
同じマシン上のnginxの背後で、それぞれが単一のワーカーを持つ複数のuwsgiインスタンスを実行します。
Nginxの背後で単一のuwsgiインスタンスを実行します
覚えておくべきことの1つは、サーバーがすでにロードバランサーの背後にあるということです。
提供する静的アセットがある場合は、＃2または＃3で実験することを検討します。静的ファイルがないので、やり過ぎのようです。
この場合、nginxの背後でuwsgiを実行することにメリットはありますか？適切な数のワーカーを持つ単一のuswgiサーバーとは対照的ですか？
この質問への答えは、ユースケースによって大きく異なります。
UWSGIについてはよくわかりませんが、明らかにスレッド用に設計されているため、まったく同じマシン/ VMで実行されている類似のインスタンスをいくつか使用することが理にかなっているユースケースは想像できません。そのちょうど追加のオーバーヘッド。したがって、＃2は実際にはオプションではありません（アプリを頻繁に再起動する必要がある場合は、そのような設定を使用するのではなく、コードを修正してください）。
＃3は今はちょっと役に立たないように聞こえますが、そうではありません。 nginxはそれほどオーバーヘッドではなく、パフォーマンスとメモリフットプリントは、この場合、python appと比較して、おそらく無視できます。レイテンシーに影響を与えますが、これも短いことでは問題になりません。 RTSゲームサーバーの基本的には構成に要約されます。
これが邪魔にならないように、ここで考慮すべきことがいくつかあります。
- これが、単一のサーバーが問題なく処理できるよりも多くのユーザーを期待しない小さなWebアプリ（つまり、個人のホームページ、小さな学校のホームページ）の場合、単一のuWSGIはまったく問題ありません。 uWSGIには 独自のロードバランサー があるため、小さなインスタンスのスケーリングを処理できるフォールバックがあります（ただし、大規模なデプロイについてはよくわかりません）。
- アプリが現在ホストされている場所（AWSなど）にとどまることが確実な場合でも、＃1を使用して、ホスティングサービスに組み込まれているロードバランサーを使用できます。これにより、オーバーヘッドが削減され、追加の構成について心配する必要がありません。ただし、価格とサービスが変更される可能性があり、小規模なホスティング業者が廃業する可能性があることに注意する必要があります（AWSthisリスクは十分に小さいです）。
- アプリが単一のVM）からすぐにスケールアウトする可能性があり、ホスティング業者のロードバランサーが保証されない場合は、実際にnginxを追加する必要があります。前述のように、オーバーヘッドはそれほど大きくなく、突然2番目が必要になった場合VM非常に感謝します。また、アプリのクラッシュを処理したり、リクエストをフィルタリングしたりすることもできます（たとえば、DOSを使用している場合）。追加する場合https、nginxも役に立ちます。
TL; DR
アプリがコードをスケーリングできるよりも速くスケーリングしない（またはまったくスケーリングしない）と確信している場合は、追加機能は必要ありません（アプリは思ったほど安定していません） ！）そして、ホスティング業者の負荷分散機能を確信している場合は、nginxをスキップしてください。そうでない場合、または上記が当てはまるかどうか100％確信が持てない場合は、nginxを使用してください。オーバーヘッドはそれほど多くありませんが、多くの問題を回避できる可能性があります。