1つのVPSを使用して、トラフィックの少ない複数のCherryPyアプリをサブディレクトリとして展開するつもりです。例：example.com/app1、example.com/app2など

WSGIのデプロイについて調べたところ、アプリのデプロイに推奨される方法は、WSGIサーバー（Gunicorn、uWSGIなど）とNGinxをリバースプロキシ設定で使用することです。特に私のCherryPyアプリ自体がWebサーバーであるため、2つのWebサーバーをタンデムで使用するのはやり過ぎのようですが、どこにでもあるので、このアイデアを却下したくありません。私は確かに専門家ではないので、話し合いたいと思います。

3つのオプションが表示されます。

• CherryPyを単独でデプロイします。
• Gunicornまたは別のWSGIサーバーの下にデプロイします。
• WSGIサーバーの下にデプロイし、NGinxにリバースプロキシします。これは、みんなのソリューションのようです。

私の質問：

• どこにでもこのパターンが見られる主な理由は何ですか？NGinxはそれで良いのでしょうか？
• トラフィックの少ないアプリの場合、ネイティブのCherryPyサーバーで十分ですか、それとも試してはいけませんか？

どんなアドバイスでもよろしくお願いします。

誰もがnginx（またはApacheなどの別のサーバー）をアプリサーバーの前に配置する理由は、誰もが画像、CSS、JavaScriptなどの静的コンテンツ、およびアプリケーションに固有の奇妙な要件を持っているためです。

アプリサーバー（CherryPy、gunicornなど）は、アプリを実行してその出力を提供するように最適化されています。アプリサーバーは静的コンテンツを提供することもできますが、アプリサーバーの主な目的の副次的なものであるため、このタスクに対して最適化されることはほとんどありません。（一部のアプリサーバーは、CSSとJSを縮小して圧縮することでも役立つため、前面のWebサーバーがこれらのリソースをさらに高速に提供できます。）

さらに、実際のWebサーバーは、高性能なコンテンツの提供よりもはるかに多くのことができます。キャッシング、ヘッダー操作、URLリライティング、地理位置情報など、アプリサーバーを肥大化させるだけの目的以外の多くの機能。

通常、アプリケーションサーバーを単独で実行するのは、アプリケーションを開発するときだけで、自分が唯一のユーザーであり、パフォーマンスは問題ではありません。サイトのトラフィックが少ない場合でも、サイトをより高速にしたいと思いませんか？低速なトラフィックの少ないサイトは、通常、トラフィックの多いサイトに成長しません...

なぜ人々はNginxを前に置くのですか？

1. Nginxは非同期のWebサーバーです。これは、接続ごとにスレッドまたはプロセスを専用にしないことを意味します。代わりに、OSの優先ソケットポーリングライブラリを使用するため、数十万の接続を処理できます。アプリケーション開発者として、なぜ気にする必要があるのですか？Nginxは接続をバッ​​ファリングし、リクエストが完全に読み取られたときにのみCherryPyアップストリームインスタンスにリクエストを渡すためです。応答についても同じです。このようにして、さまざまな意味でNginxの背後にあるスレッドサーバーであるCherryPyアプリケーションが非同期になります。具体的には、遅いクライアントの問題と遅いロリスDOS攻撃に手を振ります。
2. Nginxには、デフォルトで接続レート制限があります。たとえば、同じIPから同時に8つ以上接続したくない。
3. CherryPyにSSLの問題があります。Nginxはサポートしていません。
4. PythonはCとほぼ同じようにバイトを送受信できます。Python zlibはCライブラリのラッパーにすぎません。ただし、Nginxは接続を効率的に処理するため、CherryPyワーカースレッドが本番環境で静的コンテンツを提供することを軽減し、動的コンテンツのみに専念することをお勧めします。
5. 同じポート、ドメイン、パスなどでの複数のCherryPyインスタンスの多重化。一般に、別の構成レベルの追加の柔軟性。

CherryPyを単独で使用しても安全ですか？

元の作者の一人によれば、そうです。CherryPyを単独で使用して実行できるWeb関連のほとんどのこと。

CherryPyにはアプリケーションの概念があり、1つのCherryPyインスタンスで複数のアプリケーションを提供できます。CherryPyは他のWSGIアプリケーションにも対応できます。

CherryPyのデプロイ

従来の* nixスタイルのデプロイメントでは、initスクリプトの作成、処理のデーモン化、その特権の削除、PIDの書き込みなどを行います。CherryPyインスタンスが2つある場合は、それほど大きな問題ではありません。数十に達すると、面倒になり、プロセス管理をGunicornまたはuWGSIに引き渡して、CherryPyインスタンスをHTTPからWSGIに切り替えることは理にかなっています。

私はチュートリアル/プロジェクトのスケルトン、cherrypy-webapp-skeletonを書きました。その目的は、Web開発者のために、Debianに実際のCherryPyアプリケーションを（従来の）デプロイするためのギャップを埋めることでした。

要約

1. トラフィックが少なく、特別な要件はありません→ CherryPy * 1 ⇐ HTTP ⇒ Client。
2. 高トラフィック、特別な要件→ CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client。
3. 同一サーバー上にある数十の個別のCherryPyインスタンス。すべての人のソリューションのやりすぎに熱心です→ CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client。