はい、承知いたしました。uWSGIを使ってPythonアプリケーションをデプロイする方法について、初心者向けの詳細な入門記事を約5000語で記述します。記事の形式で直接内容を表示します。

uWSGI入門：Python Webアプリケーションを堅牢かつ高速にデプロイする

Webアプリケーション開発の世界では、コードを書くだけでなく、それをユーザーが利用できるように公開（デプロイ）することが非常に重要です。特にPythonで開発されたWebアプリケーションを本番環境で運用するには、開発時に使っていた簡易なWebサーバー（例：Flaskの開発サーバー flask run や Djangoの manage.py runserver）ではなく、より高性能で信頼性の高いツールが必要になります。

ここで登場するのが「WSGIサーバー」です。そして、その中でも特に広く使われ、高機能で知られるのが「uWSGI」です。

この記事では、Python WebアプリケーションをuWSGIを使ってデプロイする方法を、初心者の方でも理解できるように詳細に解説します。uWSGIの基本的な概念から、簡単なアプリケーションのデプロイ、さらにNginxといったリバースプロキシとの連携、設定ファイルの書き方、プロセス管理、そしてトラブルシューティングまで、実践的な知識を網羅します。

この記事を読み終える頃には、あなたはPythonアプリケーションをuWSGIを使って本番環境にデプロイするための確固たる第一歩を踏み出せるようになっているでしょう。

さあ、uWSGIの世界へ飛び込みましょう！

1. なぜWSGIサーバー（そしてuWSGI）が必要なのか？

PythonでWebアプリケーションを開発する際、FlaskやDjangoのようなWebフレームワークを使用することがほとんどです。これらのフレームワークには、開発中にアプリケーションを一時的に実行するための簡易なWebサーバーが付属しています。例えば、Flaskなら flask run、Djangoなら python manage.py runserver コマンドで起動できます。

しかし、これらの開発用サーバーは、あくまで開発やテストを目的として設計されています。本番環境で求められる以下の要件を満たしていません。

パフォーマンス: 多数の同時接続要求を効率的に処理できません。
安定性と信頼性: エラーが発生した場合にプロセスが停止しやすいなど、運用上の信頼性に欠けます。
セキュリティ: 本番環境でのセキュリティ要件を満たしていません。
機能: 静的ファイルの配信、SSL終端、負荷分散、セキュリティ防御（DDoS対策など）といった機能がありません。

そこで必要になるのが、Webサーバー（NginxやApacheなど）とPython Webアプリケーションの間に位置する「WSGIサーバー」です。

1.1. WSGIとは何か？

WSGI（Web Server Gateway Interface）は、PythonのWebサーバーとWebアプリケーション（フレームワーク）の間で通信するための標準的なインターフェース仕様です。PEP 3333で定義されています。

WSGIが登場する前は、WebサーバーとPythonアプリケーションの連携方法はサーバーごとにバラバラでした。そのため、アプリケーション開発者は特定のサーバー向けにコードを書く必要があり、サーバーを変えるたびにアプリケーションを修正する必要がありました。

WSGIはこの問題を解決しました。WSGI仕様に従って作られた「WSGIサーバー」は、WSGI仕様に従って作られた「WSGIアプリケーション」（FlaskやDjangoで作られたアプリケーションはこの仕様を満たしています）と連携できます。

WSGIサーバーの役割: WebサーバーからのHTTPリクエストを受け取り、それをWSGI仕様に沿った形式に変換してWSGIアプリケーションに渡します。そして、アプリケーションからのレスポンスをWSGI仕様に沿った形式で受け取り、HTTPレスポンスとしてWebサーバーに返します。
WSGIアプリケーションの役割: WSGIサーバーからWSGI仕様に沿ったリクエストを受け取り、ビジネスロジックを実行し、WSGI仕様に沿ったレスポンスを返します。

これにより、アプリケーション開発者は特定のWSGIサーバーに依存せずにコードを書くことができ、好きなWSGIサーバーを選択してデプロイできるようになりました。

FlaskやDjangoといった主要なPython Webフレームワークは、WSGI仕様に準拠したアプリケーションとして動作します。

1.2. uWSGIの立ち位置

uWSGIは、このWSGI仕様を実装した「WSGIサーバー」の一つです。Pythonだけでなく、Ruby, PHP, Perlなど、様々な言語に対応したアプリケーションサーバーとしての機能も持ち合わせています。

uWSGIはC言語で書かれており、非常に高速で高性能です。また、以下の特徴を持っています。

高機能: WSGIの基本的な機能に加え、プロセス管理、スレッド管理、ロギング、監視、リロード機能、セキュリティ機能など、本番運用に必要な多くの機能を備えています。
柔軟性: コマンドライン引数、設定ファイル（INI, XML, YAML, JSONなど）、環境変数など、様々な方法で詳細な設定が可能です。
多様なプロトコル: HTTPはもちろん、uwsgiプロトコル（uWSGI独自の高速プロトコル）、FastCGIなど、様々なプロトコルでWebサーバーと連携できます。
自己完結型: uWSGI単体でHTTPリクエストを受け取ることもできますが、通常はNginxやApacheといった高性能なWebサーバー（リバースプロキシ）と組み合わせて使用します。

本番環境では、通常以下のような構成を取ります。

クライアント（ブラウザ） <=> Webサーバー（Nginxなど） <=> WSGIサーバー（uWSGI） <=> Python Webアプリケーション（Flask/Djangoなど）

この構成において、Nginxはクライアントからのリクエストを受け取り、静的ファイルの配信、SSL終端、リクエストの振り分け、負荷分散などを行います。動的な処理が必要なリクエストは、uWSGIへと転送されます。uWSGIはPythonアプリケーションを実行し、その結果をNginxに返し、Nginxがクライアントに応答を返します。

このように、uWSGIはPython Webアプリケーションを本番運用する上で、パフォーマンスと安定性を確保するための重要なコンポーネントとなります。

2. uWSGIを使うための準備

uWSGIを始める前に、いくつかの準備が必要です。

2.1. Pythonとpip

言うまでもなく、Pythonがインストールされている必要があります。そして、Pythonのパッケージ管理システムであるpipも必要です。

多くのOSにはデフォルトでPythonとpipがインストールされていますが、バージョンが古い場合があります。最新版のPython 3を使用することをお勧めします。

コマンドラインで以下のコマンドを実行して確認できます。

bash python --version pip --version

もしインストールされていない場合や、古いバージョンの場合は、OSのパッケージマネージャーを使うか、公式ウェブサイトからインストーラーをダウンロードしてインストールしてください。

2.2. 仮想環境 (Virtual Environment)

Pythonのプロジェクトごとに独立した実行環境を構築できる仮想環境を使うことを強く推奨します。これにより、プロジェクト間でライブラリの依存関係が衝突するのを防ぎ、環境をクリーンに保つことができます。

標準ライブラリのvenvを使うのが簡単です。

“`bash

プロジェクトディレクトリに移動

cd your_project_directory

仮想環境を作成 (envという名前で作る例)

python -m venv env

仮想環境をアクティベート

Linux/macOS:

source env/bin/activate

Windows (Command Prompt):

env\Scripts\activate.bat

Windows (PowerShell):

env\Scripts\Activate.ps1

“`

仮想環境がアクティベートされると、コマンドラインのプロンプトの前に仮想環境の名前（例: (env)）が表示されます。この状態でインストールしたPythonパッケージは、その仮想環境内にのみインストールされます。

仮想環境を使い終わったら、deactivate コマンドで解除できます。

2.3. 必要なビルドツールのインストール

uWSGIはC言語で書かれているため、pipでインストールする際にコンパイルが必要です。そのため、システムにCコンパイラやPythonの開発用ヘッダーファイルなどがインストールされている必要があります。

主要なLinuxディストリビューションでは、以下のパッケージをインストールすることが多いです。

Debian/Ubuntu:
bash sudo apt update sudo apt install build-essential python3-dev
CentOS/RHEL/Fedora:
bash sudo yum update sudo yum groupinstall "Development Tools" # CentOS/RHEL 7 sudo yum install gcc # CentOS/RHEL 8, Fedora sudo yum install python3-devel

これらのツールがインストールされていないと、後述の pip install uwsgi が失敗する可能性が高いです。

2.4. 簡単なWebアプリケーション（またはフレームワーク）

uWSGIを動かすためには、WSGIアプリケーションが必要です。この記事では、FlaskやDjangoを使った簡単なアプリケーションを例に説明します。もしまだアプリケーションがない場合は、最小限のコードを用意しておくと良いでしょう。

3. uWSGIのインストール

準備ができたら、仮想環境をアクティベートした状態でuWSGIをインストールします。

“`bash

仮想環境をアクティベートしていることを確認

(env) pip install uwsgi
“`

インストールが成功すれば、uwsgi コマンドが使用可能になります。

bash (env) uwsgi --version

バージョン情報が表示されればインストールは成功です。もしここでエラーが出る場合は、ビルドツールが不足している可能性が高いです。

4. uWSGIの基本：Hello World

まずは最もシンプルなWSGIアプリケーションを作成し、uWSGIを使って実行してみましょう。

プロジェクトディレクトリに wsgi.py という名前のファイルを作成します。

“`python

wsgi.py

def application(env, start_response):
start_response(‘200 OK’, [(‘Content-Type’, ‘text/plain’)])
return [b”Hello, uWSGI!”]
“`

これは、WSGI仕様に完全に準拠した最も単純なアプリケーションです。application という名前の関数が定義されており、この関数がWSGIサーバー（uWSGI）によって呼び出されます。

env: 環境変数やリクエスト情報を格納した辞書。
start_response: レスポンスのステータスコードとヘッダーを送信するためのコールバック関数。これを呼び出した後に、レスポンスボディを返すイテラブル（リストなど）を返します。

次に、この wsgi.py ファイルをuWSGIで実行します。仮想環境がアクティベートされているターミナルで、wsgi.py があるディレクトリから以下のコマンドを実行します。

bash (env) uwsgi --http :8000 --wsgi-file wsgi.py

このコマンドの意味は以下の通りです。

uwsgi: uWSGIコマンド本体
--http :8000: HTTPプロトコルを使って、ローカルホストのポート8000番でリクエストを待ち受けます。
--wsgi-file wsgi.py: 実行するWSGIアプリケーションファイルとして wsgi.py を指定します。uWSGIはこのファイル内の application というcallableを探して実行します。

コマンドを実行すると、uWSGIが起動し、以下のようなログが表示されるはずです。

*** Starting uWSGI 2.0.xx (xx bits) *** ... (省略) ... Python version: 3.x.x (default, ...) ... (省略) ... WSGI app 0 (mountpoint='') ready in ... seconds mapped 72720 bytes (71 KB) for 1 requests mapped 72720 bytes (71 KB) for 1 background workers *** Running in HTTP mode for :8000 (HTTP/1.1) *** *** uWSGI is running in multiple interpreter mode *** spawned uWSGI worker 1 (and the older children are dead) spawned uWSGI http 1 (and the older children are dead)

ブラウザを開き、http://localhost:8000/ にアクセスしてみてください。「Hello, uWSGI!」というテキストが表示されるはずです。

これで、uWSGIを使ってシンプルなWSGIアプリケーションを動かすことができました。しかし、これは単一プロセスでHTTPリクエストを受け付けているだけの、開発用サーバーと大差ない状態です。本番環境では、もう少し複雑な設定が必要です。

5. uWSGIのコアコンセプト

uWSGIを効果的に使うためには、その内部でどのようにリクエストが処理されているのか、いくつかの重要な概念を理解しておく必要があります。

5.1. マスタープロセスとワーカープロセス (Master Process and Workers)

uWSGIを本番環境で実行する際の最も一般的な構成は、マスタープロセスと複数のワーカープロセスを使う方法です。

マスタープロセス (Master Process): uWSGIの親プロセスです。ワーカープロセスの生成、監視、再起動、設定のリロード、シグナルの処理などを担当します。クライアントからの直接のリクエスト処理は行いません。オプション --master または master = true で有効にします。
ワーカープロセス (Worker Processes): 実際にクライアントからのリクエストを受け付け、Pythonコード（WSGIアプリケーション）を実行するプロセスです。マスタープロセスによって管理されます。オプション --processes または processes = N で、起動するワーカープロセスの数を指定します。

ワーカープロセスを複数起動することで、同時に複数のリクエストを処理できるようになり、アプリケーションの応答性が向上します。これは、マルチプロセスによる並列処理です。

5.2. スレッド (Threads)

各ワーカープロセス内でさらにスレッドを生成し、並行処理を行うことも可能です。オプション --threads または threads = N で、各ワーカープロセスが持つスレッド数を指定します。

PythonにはGIL (Global Interpreter Lock) という仕組みがあり、一つのプロセス内で同時に実行できるPythonバイトコードは、インタープリターレベルでは基本的に一つだけです。しかし、I/O処理（ネットワーク通信、ファイル読み書きなど）のように、GILを解放する操作を含む処理であれば、スレッドを使うことで並行処理による恩恵を得られる場合があります。

一般的には、CPUバウンドな処理が多いアプリケーションではプロセス数を増やす方が効果的で、I/Oバウンドな処理が多いアプリケーションではプロセス数を増やしつつ、各プロセス内のスレッド数も増や検討することがあります。

推奨される設定はアプリケーションの特性やサーバーのリソースに依存しますが、一般的なWebアプリケーションでは processes = N, threads = M のように設定し、同時接続数を考慮して N * M が適切な数になるように調整します。例えば、processes = 4, threads = 2 のような設定です。

5.3. ソケット (Sockets)

uWSGIはクライアントやWebサーバーからのリクエストを「ソケット」を通して受け付けます。ソケットには主に2種類あります。

TCPソケット (TCP Socket): ネットワーク越しに通信するためのソケットです。--http :8000 のようにポート番号を指定するとTCPソケットを使用します。異なるサーバー上のプロセスと通信する場合に使います。uWSGI単体でHTTPリクエストを受け付ける場合や、Webサーバーが別のサーバーにある場合などに使われます。
Unixドメインソケット (Unix Domain Socket): 同じサーバー上のプロセス間通信に特化したソケットです。ファイルシステム上のパスとして表現されます（例: /tmp/myapp.sock）。ネットワークスタックを通さないため、TCPソケットよりも高速でオーバーヘッドが少ないという利点があります。通常、同じサーバー上でNginxとuWSGIを連携させる場合は、Unixドメインソケットを使用することが推奨されます。オプション --socket /path/to/socket.sock または socket = /path/to/socket.sock で指定します。

本番環境では、NginxとuWSGIを同じサーバーにデプロイし、Unixドメインソケットで連携させる構成が最も一般的で推奨されます。

5.4. uwsgiプロトコル

uWSGIは、HTTPプロトコルだけでなく、「uwsgiプロトコル」という独自のプロトコルもサポートしています。このプロトコルはuWSGIと他のコンポーネント（特にNginxのuwsgiモジュール）の間で、HTTPよりも効率的にデータをやり取りするために設計されています。

Nginxと連携する場合、--socket オプションでUnixドメインソケットを指定し、Nginx側で uwsgi_pass ディレクティブを使ってこのソケットにリクエストを転送すると、自動的にuwsgiプロトコルが使用されます。これが、HTTPプロトコルで連携するよりも一般的に高速な理由です。

5.5. Emperorモード

複数のPython Webアプリケーションを一つのサーバーで運用する場合、それぞれのアプリケーションに対して独立したuWSGIインスタンスを起動・管理する必要があります。Emperorモードは、この複数のuWSGIインスタンス（「Vassals」、家臣の意）をまとめて管理するための強力な機能です。

Emperor（皇帝）プロセスを一つ起動し、特定のディレクトリを監視させます。そのディレクトリに各アプリケーションの設定ファイル（例: .ini ファイル）を配置すると、Emperorがそれらの設定ファイルに基づいて対応するVassal（uWSGIインスタンス）を自動的に起動し、監視してくれます。設定ファイルが変更されたり削除されたりすると、Emperorは該当するVassalを自動的にリロードしたり停止したりします。

これは、複数のアプリケーションをデプロイする際に、それぞれの起動・停止・再起動を手動で行う手間を省き、管理を大幅に楽にしてくれます。オプション --emperor /path/to/vassals/directory で有効にします。

6. 設定ファイルを使ったuWSGIの起動

コマンドライン引数でuWSGIを設定するのは、簡単なテストには便利ですが、本番環境のように多くのオプションを指定する場合や、設定をバージョン管理したい場合には不向きです。

uWSGIは様々な形式の設定ファイルをサポートしていますが、最も一般的で推奨されるのはINI形式です。

プロジェクトのルートディレクトリなどに uwsgi.ini というファイルを作成してみましょう。

“`ini

uwsgi.ini

[uwsgi]

モジュールとcallableを指定

例えば、myproject/wsgi.py の application callable を指定する場合

module = myproject.wsgi:application

アプリケーションのルートディレクトリに移動

これにより、Pythonがアプリケーションのモジュールを見つけられるようになる

chdir = /path/to/your/project

仮想環境のパスを指定 (オプションだが強く推奨)

virtualenv = /path/to/your/project/env

マスタープロセスを有効化

master = true

ワーカープロセス数

processes = 4

各ワーカーのスレッド数 (I/Oバウンドなアプリ向け、CPUバウンドなら不要なことも)

threads = 2

リクエストを待ち受けるソケット

Nginxと連携する場合は Unix ドメインソケットが推奨

socket = /path/to/your/project/myproject.sock

ソケットのパーミッション (他のユーザーからのアクセスを許可する場合)

通常は Nginx が uwsgi を実行するユーザーと同じグループに属するように設定し、660 にするのが安全

chmod-socket = 666

起動時のログレベル (デフォルトは info)

log-level = critical

ログの出力先 (ファイル、syslogなど)

logto = /var/log/uwsgi/myproject.log

エラーログのみ別の場所に出力

disable-logging = true # リクエストログを出力しない

logto = /var/log/uwsgi/myproject_error.log # 標準出力/エラー出力をリダイレクト

バックグラウンドでデーモンとして実行

daemonize = /var/log/uwsgi/myproject.daemon.log

PIDファイルを作成 (停止やリロードに使う)

pidfile = /tmp/myproject.pid

ファイルを touch するとワーカーがリロードされる

touch-reload = /path/to/your/project/uwsgi.ini # 設定ファイル変更でリロード

touch-reload = /path/to/your/project/wsgi.py # アプリケーションコード変更でリロード

————————————————————

オプションの便利な設定

————————————————————

アプリケーションの起動タイムアウト (秒)

ready-timeout = 60

ワーカーがリクエスト処理中にクラッシュした場合に再起動

worker-reload-mercy = 8

メモリリーク対策などで定期的にワーカーを再起動

max-requests = 5000 # ワーカーが5000リクエスト処理したら再起動

reload-on-rss = 100 # ワーカーのメモリ使用量が100MBを超えたら再起動 (Mb)

Nginxの proxy_buffering が off の場合にレスポンスをチャンクで送信

enable-threads = true # threads を使う場合は必須

post-buffering = 8192

プロセスに名前をつける (ps コマンドで分かりやすくなる)

procname-master = uwsgi_master_myproject

procname-prefix = uwsgi_worker_myproject_

staticsize とか sendfile とか色々ある

参考: https://uwsgi-docs.readthedocs.io/en/latest/Options.html

“`

上記のコメントで説明を加えていますが、重要なオプションをいくつか解説します。

module: 実行するPythonモジュールとその中のcallableを指定します。myapp.wsgi:application のように指定する場合、uWSGIは $PYTHONPATH または chdir で指定されたディレクトリ内の myapp ディレクトリ（またはファイル）を探し、その中の wsgi.py ファイル（myapp.wsgi と解釈される）の application という名前の関数やオブジェクトをロードしようとします。
chdir: uWSGIがカレントディレクトリを変更するパスを指定します。これは、アプリケーションが自身のリソース（テンプレート、設定ファイルなど）を見つけるために非常に重要です。通常はプロジェクトのルートディレクトリを指定します。
virtualenv: 使用する仮想環境のパスを指定します。これを指定することで、uWSGIは指定された仮想環境内でPythonインタープリターを起動し、プロジェクトの依存関係が正しくロードされるようにします。本番環境では必須の設定と考えましょう。
master: マスタープロセスを有効にします。ワーカーの管理が行われます。
processes: 起動するワーカープロセスの数を指定します。サーバーのコア数などを参考に決定します。
threads: 各ワーカープロセス内で起動するスレッド数を指定します。I/Oバウンドなアプリケーションの場合に検討します。threads > 1 と設定する場合、enable-threads = true も設定が必要な場合があります。
socket: リクエストを待ち受けるソケットのパスまたはアドレスを指定します。Nginxと連携する場合はUnixドメインソケット（例: /var/run/uwsgi/myproject.sock）が推奨されます。TCPソケットを使う場合は 127.0.0.1:8001 のように指定します。
chmod-socket: 作成されるUnixドメインソケットのパーミッションを指定します。Nginxがこのソケットにアクセスできるように、Nginxを実行するユーザーまたはグループが読み書きできるパーミッションを設定する必要があります。例えば、Nginxが www-data ユーザーで実行されている場合、uWSGIも www-data ユーザーで実行するか、ソケットのグループを www-data にしてパーミッションを 660 (chmod-socket = 660, chown-socket = :www-data or uid, gid) に設定するのが一般的です。
daemonize: uWSGIプロセスをバックグラウンドでデーモンとして実行し、標準出力と標準エラー出力を指定したファイルにリダイレクトします。本番環境では必須の設定です。
pidfile: マスタープロセスのプロセスID (PID) を書き込むファイルのパスを指定します。これにより、後から kill -HUP cat /path/to/pidfile や uwsgi --reload /path/to/pidfile コマンドを使ってuWSGIプロセスを安全にリロードしたり停止したりできます。
logto: uWSGIのログを出力するファイルのパスを指定します。起動情報、リクエストログ、エラーなどがここに出力されます。トラブルシューティングに非常に重要です。

これらの設定ファイルを保存したら、以下のコマンドでuWSGIを起動できます。

“`bash

仮想環境がアクティベートされていることを確認

設定ファイルはプロジェクトのルートにあるとする

(env) uwsgi –ini uwsgi.ini
“`

daemonize を設定している場合、コマンドはすぐに終了し、uWSGIはバックグラウンドで実行されます。pidfile と logto で指定したファイルを確認して、uWSGIが正常に起動しているか確認しましょう。

もし daemonize をコメントアウトしてフォアグラウンドで実行すると、ログが直接ターミナルに表示されるので、起動時のエラー確認には便利です。

7. NginxとuWSGIの連携

uWSGIを単体でインターネットに公開することは、静的ファイルの配信能力やセキュリティ機能が限定的なため、一般的ではありません。高性能なWebサーバーであるNginxと組み合わせて使用するのが、現代のWebアプリケーションデプロイの標準的なプラクティスです。

7.1. Nginxの役割

Nginxはリバースプロキシとして機能し、以下の役割を担います。

リクエストの受け付け: クライアントからのHTTP/HTTPSリクエストをインターネット側で受け付けます。
静的ファイルの配信: HTML, CSS, JavaScript, 画像などの静的ファイルを高速に直接配信します。これにより、WSGIアプリケーションが静的ファイルの処理にリソースを割かずに済みます。
リクエストの転送: 動的な処理が必要なリクエスト（特定のURLパターンなど）を、設定に基づいてuWSGIなどのアプリケーションサーバーに転送します。
SSL終端: HTTPS通信の暗号化/復号化を行います。uWSGIでSSLを処理するよりも、Nginxで行う方が効率的です。
負荷分散: 複数のアプリケーションサーバーインスタンスがある場合に、リクエストを分散させます。
バッファリングとキャッシング: アプリケーションサーバーからの応答をバッファリングすることで、クライアントへの送信を効率化したり、アプリケーションサーバーの負荷を軽減したりします。
セキュリティ: 不正なリクエストのフィルタリング、レート制限など、基本的なセキュリティ防御を提供します。

7.2. NginxとuWSGIの連携方法

NginxとuWSGIは、前述のソケット（通常はUnixドメインソケット）とプロトコル（通常はuwsgiプロトコル）を使って通信します。

uWSGI側の設定: uWSGIのINIファイルで、Unixドメインソケットを使用するように設定します。

“`ini
[uwsgi]

… その他の設定 …

socket = /var/run/uwsgi/myproject.sock # Nginxがアクセスできる場所に作成
chmod-socket = 660 # Nginxユーザーがソケットにアクセスできるよう権限を設定
chown-socket = www-data:www-data # Nginxユーザー/グループに所有者を変更 (必要に応じて)

…

``/var/run/uwsgi/のようなディレクトリは、適切な権限で事前に作成しておく必要がある場合があります。ソケットのパーミッションと所有者は、Nginxを実行するユーザー（多くのLinuxではwww-dataやnginx`）に合わせて設定することが重要です。
Nginx側の設定: Nginxの設定ファイル（通常 /etc/nginx/sites-available/ ディレクトリにプロジェクトごとの設定ファイルを作成し、/etc/nginx/sites-enabled/ にシンボリックリンクを張る）で、特定のロケーションへのリクエストをuWSGIソケットに転送するように設定します。

“`nginx

/etc/nginx/sites-available/myproject

server {
listen 80;
server_name your_domain.com www.your_domain.com; # あなたのドメイン名
```
# 静的ファイルの設定 (例: /static/ ディレクトリにあるファイルを配信)
# collectstatic で集められた静的ファイルの場所を指定
location /static/ {
    alias /path/to/your/project/static/; # 静的ファイルがある実際のパス
    expires 30d; # ブラウザキャッシュの有効期限
    add_header Cache-Control "public, no-transform";
}

# メディアファイルの設定 (例: /media/ ディレクトリにあるファイルを配信)
# user がアップロードしたファイルなど
location /media/ {
    alias /path/to/your/project/media/; # メディアファイルがある実際のパス
    expires 30d;
    add_header Cache-Control "public, no-transform";
}

# その他のすべてのリクエストを uWSGI に転送
location / {
    include uwsgi_params; # uWSGI に必要なパラメータをインクルード
    uwsgi_pass unix:///var/run/uwsgi/myproject.sock; # uWSGIソケットのパスを指定

    # uWSGIへのタイムアウト設定 (必要に応じて調整)
    uwsgi_read_timeout 300;
    uwsgi_connect_timeout 300;
    uwsgi_send_timeout 300;
}

# エラーページのカスタム設定 (オプション)
# error_page 500 502 503 504 /50x.html;
# location = /50x.html {
#     root /usr/share/nginx/html;
# }
```
}
“`
- listen 80;: ポート80でHTTPリクエストを待ち受けます。HTTPSの場合は listen 443 ssl; などと設定します。
- server_name your_domain.com;: この設定ブロックが応答するドメイン名を指定します。
- location /static/ { ... }: /static/ で始まるURLへのリクエストは、uWSGIを通さず、Nginxが直接 /path/to/your/project/static/ ディレクトリからファイルを配信します。
- location / { ... }: 上記のどの location ブロックにもマッチしないすべてのリクエストを処理します。
- include uwsgi_params;: uWSGIプロトコルで通信する際に必要なHTTPヘッダーやその他の情報をNginxがuWSGIに渡すための標準ファイルです。通常 /etc/nginx/uwsgi_params にあります。
- uwsgi_pass unix:///var/run/uwsgi/myproject.sock;: リクエストを指定されたUnixドメインソケットを通してuWSGIに転送します。TCPソケットの場合は uwsgi_pass 127.0.0.1:8001; のようになります。unix:// というプレフィックスはUnixドメインソケットを指定する際に必要です。
- uwsgi_read_timeout, uwsgi_connect_timeout, uwsgi_send_timeout: NginxとuWSGI間の通信タイムアウトを設定します。特に時間がかかる処理がある場合は調整が必要です。
Nginx設定の有効化: 作成した設定ファイルを /etc/nginx/sites-available/ に保存し、/etc/nginx/sites-enabled/ にシンボリックリンクを作成します。

bash sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled/
Nginx設定のテストと再起動: Nginxの設定ファイルに構文エラーがないかテストし、Nginxサービスを再起動して設定を反映させます。

bash sudo nginx -t sudo systemctl restart nginx

これで、Nginxがフロントとなり、動的なリクエストはuWSGIへと転送される構成が完成しました。

7.3. ユーザーと権限

uWSGIとNginxを連携させる際には、ファイルシステム上の権限が重要になります。

uWSGIプロセスの実行ユーザー: uWSGIを起動するユーザーは、プロジェクトディレクトリ、仮想環境、設定ファイル、そしてソケットファイルを作成・書き込みできる権限が必要です。セキュリティ上の理由から、rootユーザーではなく、専用のシステムユーザー（例: webuser）で実行することが推奨されます。
Nginxプロセスの実行ユーザー: Nginxワーカープロセスが実行されるユーザー（例: www-data, nginx）は、静的ファイルやメディアファイルにアクセスできる読み取り権限が必要です。また、uWSGIソケットファイルにアクセスして通信するための読み書き権限が必要です。

もしNginxとuWSGIを異なるユーザーで実行する場合、uWSGIソケットのパーミッション (chmod-socket) と所有者 (chown-socket) を適切に設定する必要があります。例えば、NginxユーザーとuWSGIユーザーを同じグループに所属させ、ソケットのグループをそのグループに設定し、パーミッションを 660 にするのが一般的です。

8. Flaskアプリケーションのデプロイ例

簡単なFlaskアプリケーションをuWSGIを使ってデプロイする例を示します。

まず、簡単なFlaskアプリケーションを作成します。
your_project/app.py:

“`python

your_project/app.py

from flask import Flask

app = Flask(name)

@app.route(‘/’)
def hello():
return “Hello from Flask!”

if name == ‘main‘:
# これは開発用サーバーなので、本番環境では使いません
app.run(debug=True)
“`

Flaskをインストールします。

bash (env) pip install Flask

次に、uWSGIがアプリケーションを見つけられるように、WSGIエントリポイントとなるファイル（例: wsgi.py）を作成します。
your_project/wsgi.py:

“`python

your_project/wsgi.py

from your_project.app import app as application

if name == ‘main‘:
# uWSGI は直接 application callable を呼び出すので、このブロックは uWSGI 実行時は実行されません
# ただし、python wsgi.py のように実行すると開発サーバーが起動します
from wsgiref.simple_server import make_server
httpd = make_server(‘0.0.0.0’, 8000, application)
httpd.serve_forever()
`` WSGI仕様ではapplicationという名前のcallableを探すのが標準的です。Flaskアプリケーションオブジェクトの名前がappなので、application = app` のように別名を付けてエクスポートしています。

次に、uWSGIの設定ファイル uwsgi.ini を作成します。
your_project/uwsgi.ini:

“`ini

your_project/uwsgi.ini

[uwsgi]

wsgi.py ファイルの application callable を指定

your_project.wsgi は your_project ディレクトリ内の wsgi.py を指す

module = your_project.wsgi:application

プロジェクトのルートディレクトリを指定

chdir = /path/to/your/project

仮想環境のパスを指定

virtualenv = /path/to/your/project/env

マスタープロセス有効化

master = true

ワーカー数

processes = 4

スレッド数

threads = 2

Nginxと連携するためのUnixソケット

socket = /var/run/uwsgi/myproject.sock
chmod-socket = 660

chown-socket = www-data:www-data # 必要に応じて

バックグラウンド実行とログ設定

daemonize = /var/log/uwsgi/myproject.daemon.log
pidfile = /tmp/myproject.pid
logto = /var/log/uwsgi/myproject.log

コード変更時にリロード (開発/ステージング向け、本番ではデプロイスクリプトで対応することもある)

touch-reload = /path/to/your/project/wsgi.py

uWSGIを実行するユーザーとグループ (root以外を推奨)

uid = webuser

gid = webuser

``/path/to/your/projectや/path/to/your/project/envは実際のパスに置き換えてください。また、/var/run/uwsgi/` ディレクトリを作成し、uWSGIプロセスを実行するユーザーがそこにソケットファイルを作成できるように適切な権限を設定してください。

uWSGIを起動します。
“`bash

プロジェクトディレクトリに移動

cd /path/to/your/project

仮想環境をアクティベート

source env/bin/activate

uWSGIを起動

(env) uwsgi –ini uwsgi.ini
“`

ログファイル /var/log/uwsgi/myproject.log を確認し、エラーなく起動していることを確認します。PIDファイル /tmp/myproject.pid が作成されていることも確認します。

次にNginxを設定します（前のセクションのNginx設定例を参照）。/var/run/uwsgi/myproject.sock を参照するように設定し、Nginxを再起動します。

ブラウザで設定したドメイン名にアクセスすると、「Hello from Flask!」が表示されるはずです。

9. Djangoアプリケーションのデプロイ例

Djangoプロジェクトも同様にuWSGIを使ってデプロイできます。Djangoプロジェクトを作成すると、自動的にWSGIエントリポイントとなるファイル (your_project/wsgi.py) が生成されます。

myproject という名前のDjangoプロジェクトがあるとします。プロジェクト構造は通常以下のようになります。

myproject/ ├── manage.py ├── myproject/ │ ├── __init__.py │ ├── asgi.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py <-- これが uWSGI から使われる └── myapp/ ├── __init__.py ├── admin.py ├── apps.py ├── models.py ├── tests.py └── views.py

myproject/wsgi.py ファイルは以下のようになっています（Djangoのバージョンによって多少異なることがあります）。

“`python

myproject/wsgi.py

“””
WSGI config for myproject project.

It exposes the WSGI callable as a module-level variable named application.

For more information on this file, see
https://docs.djangoproject.com/en/x.y/howto/deployment/wsgi/
“””

import os

from django.core.wsgi import get_wsgi_application

os.environ.setdefault(‘DJANGO_SETTINGS_MODULE’, ‘myproject.settings’)

application = get_wsgi_application()
`` Djangoはget_wsgi_application()関数を使って、WSGIアプリケーションオブジェクトを生成し、applicationという名前でエクスポートしています。uWSGIはこのapplication` callable を呼び出します。

次に、uWSGIの設定ファイル uwsgi.ini を作成します。プロジェクトのルートディレクトリ（manage.py があるディレクトリ）に作成するのが一般的です。

“`ini

myproject/uwsgi.ini

[uwsgi]

Djangoプロジェクトの settings.py があるモジュール名 (プロジェクト名.settings)

これを設定することで Django が設定ファイルを読み込む

env = DJANGO_SETTINGS_MODULE=myproject.settings

WSGIエントリポイントのモジュール名とcallable

manage.py があるディレクトリからの相対パス myproject/wsgi.py を指定

module = myproject.wsgi:application

プロジェクトのルートディレクトリに移動 (manage.py がある場所)

chdir = /path/to/your/django/project

仮想環境のパスを指定

virtualenv = /path/to/your/django/project/env

マスタープロセス有効化

master = true

ワーカー数

processes = 4

スレッド数

threads = 2

Nginxと連携するためのUnixソケット

socket = /var/run/uwsgi/myproject.sock
chmod-socket = 660

chown-socket = www-data:www-data # 必要に応じて

バックグラウンド実行とログ設定

daemonize = /var/log/uwsgi/myproject.daemon.log
pidfile = /tmp/myproject.pid
logto = /var/log/uwsgi/myproject.log

コード変更時にリロード (開発/ステージング向け)

touch-reload = /path/to/your/django/project/myproject/wsgi.py

touch-reload = /path/to/your/django/project/myproject/settings.py

uWSGIを実行するユーザーとグループ (root以外を推奨)

uid = webuser

gid = webuser

Django の collectstatic で集められた静的ファイルの場所を uWSGI に教えておく

これにより uWSGI 自身が静的ファイルを配信できる (Nginxを使う場合は不要だが、設定しておくとデバッグなどに便利)

static-map = /static=/path/to/your/django/project/static

``/path/to/your/django/projectや/path/to/your/django/project/env` は実際のパスに置き換えてください。

uWSGIを起動します。
“`bash

プロジェクトのルートディレクトリに移動 (manage.py がある場所)

cd /path/to/your/django/project

仮想環境をアクティベート

source env/bin/activate

uWSGIを起動

(env) uwsgi –ini uwsgi.ini
“`

ログファイルやPIDファイルを確認して起動を検証します。

Nginxの設定は、Flaskの場合と同様に、静的ファイルやメディアファイルのエイリアスを設定し、動的なリクエストをuWSGIソケットに転送するように記述します。

Djangoプロジェクトの場合、Nginxで静的ファイルやメディアファイルを配信するためには、事前に python manage.py collectstatic コマンドを実行して、すべての静的ファイルを一つのディレクトリに集めておく必要があります。Nginx設定の location /static/ ブロックの alias ディレクティブには、この集められた静的ファイルがあるディレクトリのパスを指定します（通常 settings.py の STATIC_ROOT で設定したパス）。同様に、ユーザーがアップロードしたメディアファイルがあるディレクトリ（settings.py の MEDIA_ROOT で設定したパス）を location /media/ の alias に指定します。

Nginxを設定し、再起動すれば、Djangoアプリケーションにアクセスできるようになります。

10. uWSGIの停止とリロード

本番環境でuWSGIプロセスを停止したり、コードや設定を変更した後にプロセスを再起動したりすることは頻繁に行われます。これらの操作は、サービスの中断を最小限に抑えつつ安全に行う必要があります。

uWSGIは、設定ファイルで指定したPIDファイルを使って、これらの操作を制御できます。

10.1. 停止 (Stop)

uWSGIのマスタープロセスにTERMシグナルを送信することで、ワーカープロセスを順次シャットダウンし、最終的にマスタープロセス自身も終了させることができます。

PIDファイルを使っている場合、以下のコマンドで停止できます。

bash uwsgi --stop /path/to/your/pidfile

または、PIDファイルからPIDを読み取って kill コマンドを使う方法もあります。

bash kill -TERM $(cat /path/to/your/pidfile)
--stop オプションを使う方が推奨されます。

10.2. グレースフルリロード (Graceful Reload)

コードや設定を変更した場合、サービスを停止せずに新しいコードでuWSGIを再起動したいことが多いです。uWSGIは「グレースフルリロード」に対応しています。これは、新しいワーカープロセスを起動し、新しいリクエストをそちらに振り向けつつ、既存のワーカープロセスは現在のリクエストの処理を完了させてから終了させるという方式です。これにより、サービスの中断なしに新しいバージョンに切り替えることができます。

グレースフルリロードを行うには、マスタープロセスにHUPシグナルを送信します。

PIDファイルを使っている場合、以下のコマンドでリロードできます。

bash uwsgi --reload /path/to/your/pidfile

または、PIDファイルからPIDを読み取って kill コマンドを使う方法もあります。

bash kill -HUP $(cat /path/to/your/pidfile)
--reload オプションを使う方が推奨されます。

設定ファイルに touch-reload = /path/to/file オプションを指定している場合、指定したファイルを touch コマンドなどで更新することでもリロードをトリガーできます。これはデプロイスクリプトなどで利用すると便利です。

bash touch /path/to/your/project/uwsgi.ini

10.3. 強制停止 (Hard Stop)

kill -QUIT (または uwsgi --quit), kill -INT, kill -KILL などのシグナルを使うと、ワーカープロセスが現在のリクエストを処理中でも強制的に終了させられることがあります。通常は推奨されません。

10.4. システムサービスとしての管理

本番環境では、uWSGIプロセスを systemd や supervisor のようなプロセス管理システムを使って管理するのが一般的です。これにより、サーバー起動時に自動的にuWSGIを起動したり、uWSGIプロセスが予期せず終了した場合に自動的に再起動したり、これらのプロセス管理システムのコマンド（例: systemctl start uwsgi, systemctl restart uwsgi, systemctl status uwsgi）で簡単に状態を確認したり停止・起動できるようになります。

systemd サービスファイルを作成する場合、以下のような設定になります（例: /etc/systemd/system/myproject.service）。

“`ini
[Unit]
Description=uWSGI instance to serve myproject
After=network.target

[Service]
User=webuser # uWSGIを実行するユーザー (root以外推奨)
Group=webuser # uWSGIを実行するグループ
WorkingDirectory=/path/to/your/project # chdir と同じ
Environment=”PATH=/path/to/your/project/env/bin” # 仮想環境の bin ディレクトリを PATH に追加
ExecStart=/path/to/your/project/env/bin/uwsgi –ini /path/to/your/project/uwsgi.ini # 仮想環境内の uwsgi コマンドと設定ファイルを指定
Restart=always # uWSGI が終了した場合に自動再起動
KillSignal=SIGQUIT # systemctl stop が送るシグナル (グレースフルシャットダウン)
Type=notify # uWSGI が systemd に起動完了を通知

[Install]
WantedBy=multi-user.target
``ExecStartコマンドは、daemonize,pidfile,logtoオプションをuWSGI INIファイルから削除するか、systemdの設定で上書きする必要がある点に注意してください。systemd` がプロセスの管理、ログの収集、再起動などを肩代わりするためです。

サービスファイルを作成・編集したら、sudo systemctl daemon-reload で設定を読み込み、sudo systemctl start myproject.service で起動、sudo systemctl enable myproject.service でOS起動時の自動起動を有効にします。

11. その他の重要な設定と考慮事項

11.1. ログの設定

ログはトラブルシューティングやアプリケーションの状況把握に不可欠です。logto オプションで出力先を指定しますが、ログレベルや形式、特定のログの除外なども設定できます。

log-level: 出力するログの最小レベルを指定します (critical, error, warning, info, debug など)。
disable-logging: リクエストごとに生成されるアクセスログを無効にします。リクエストログはNginxで行う場合に便利です。
log-date: ログ出力に日付と時刻を追加します。
log-encoder: ログのエンコーディングを指定します（JSON形式なども可能）。
req-logger, logger: 特定のログ（リクエストログ、エラーログなど）を異なる出力先に送る設定も可能です。

本番環境では、ログをファイルに出力するだけでなく、集中的なログ管理システム（Fluentd, Logstash, Datadogなど）に転送することも検討します。

11.2. セキュリティ

root権限での実行回避: uWSGIプロセスはroot権限で実行すべきではありません。uid, gid オプションまたはsystemdの設定で、権限の低いユーザーで実行するように設定してください。
ソケットのパーミッション: Unixドメインソケットのパーミッションは、Nginxプロセスが必要最小限の権限でアクセスできるように設定します (chmod-socket, chown-socket)。666 は誰でも読み書きできるので危険な場合があります。
不要なオプションの無効化: uWSGIは多くの機能を持っていますが、使用しない機能（例えば、HTTPプロトコルをNginx経由で使う場合にuWSGI側のHTTPリスナーを無効にするなど）は無効にしておくことで、攻撃対象を減らすことができます。
バッファリング: post-buffering などのオプションを使って、大きなリクエストボディやレスポンスボディを適切に処理できるように設定することで、一部の攻撃を防ぐのに役立ちます。

11.3. パフォーマンスチューニング

プロセス数とスレッド数: processes と threads の設定はアプリケーションの特性（CPUバウンドかI/Oバウンドか）とサーバーのリソース（CPUコア数、メモリ）に応じて適切に調整することが重要です。一般的なガイドラインとしては、CPUコア数 * 2 程度のプロセス数を設定し、I/Oが多い場合は各プロセスで数個のスレッドを使うことが考えられます。しかし、最適な設定は負荷テストを行って見つけるのが最も確実です。
GILとスレッド: PythonのGILがあるため、CPUバウンドな処理ではスレッドを使っても真の並列実行はできません。このような場合はプロセス数を増やす方が効果的です。スレッドは主にI/O待ちを並行で行う場合に有効です。
Stats Socket: uWSGIは stats オプションで統計情報を取得できるソケットを公開できます。これを監視ツール（Prometheusなど）と連携させることで、ワーカーの状態、リクエスト数、エラー率、メモリ使用量などをリアルタイムに監視し、パフォーマンスの問題を発見したりチューニングの参考にしたりできます。

“`ini
[uwsgi]

…

stats = 127.0.0.1:9191 # localhost のポート 9191 で統計ソケットを公開

stats = /tmp/myproject_stats.sock # Unixドメインソケットでも可

“`
注意: 統計ソケットは認証がないため、外部に公開せず、ローカルホストからのみアクセスできるようにするか、ファイアウォールなどでアクセスを制限してください。

11.4. メモリ管理

長時間稼働するプロセスでは、メモリリークが発生する可能性があります。uWSGIには、ワーカープロセスのメモリ使用量を監視し、閾値を超えた場合に自動的に再起動する機能があります。

reload-on-rss = 100: 各ワーカープロセスのResident Set Size (RSS) が100MBを超えたら、そのワーカープロセスをグレースフルに再起動します。
max-requests = 5000: 各ワーカープロセスが指定されたリクエスト数を処理した後、グレースフルに再起動します。これにより、ワーカーのメモリ状態をリフレッシュできます。

これらの設定は、メモリリークが疑われる場合や、長期間の安定稼働を確保するために役立ちます。

12. トラブルシューティング

uWSGIのデプロイ中に発生しうる一般的な問題と、その対処法について説明します。

uWSGIが起動しない:
- 設定ファイルのパス間違い: --ini オプションで指定した設定ファイルのパスが正しいか確認します。
- 設定ファイルのエラー: 設定ファイルに構文エラーがないか確認します。uwsgi --ini your_config.ini をフォアグラウンドで実行すると、エラーメッセージが表示されることが多いです。
- 必要なライブラリやビルドツールの不足: pip install uwsgi の際にエラーが出なかったか確認します。もし出ている場合は、Section 2.3 を参考にビルドツールをインストールします。
- Pythonインタープリターや仮想環境のパス間違い: virtualenv または python オプションで指定したパスが正しいか確認します。
- モジュールやcallableが見つからない: module オプションの指定が正しいか、chdir でカレントディレクトリがアプリケーションのルートになっているか、Pythonの sys.path が正しいか確認します。ログに ImportError などが出ていないか確認します。
uWSGIは起動したが、Nginx経由でアクセスできない（Nginxが502 Bad Gatewayエラーなど）:
- uWSGIが指定したソケットで待ち受けているか: uWSGIのログを確認し、socket = ... で指定したパスでソケットが作成されているか確認します。ls -l /path/to/your/socket.sock コマンドでファイルが存在するか確認します。
- ソケットのパーミッション: Nginxワーカープロセスがソケットファイルにアクセス（読み書き）できるパーミッションがあるか確認します (chmod-socket, chown-socket)。Nginxのログ (/var/log/nginx/error.log など) に “Permission denied” のエラーが出ていないか確認します。
- Nginx設定のソケットパス間違い: Nginx設定の uwsgi_pass ディレクティブで指定したソケットパスが、uWSGI設定の socket と一致しているか確認します。
- uWSGIプロセスがクラッシュしていないか: uWSGIのログファイル、またはsystemdを使っている場合は journalctl -u myproject.service でログを確認し、起動後にエラーが発生していないか、プロセスが予期せず終了していないか確認します。ps aux | grep uwsgi コマンドでuWSGIプロセスが実行されているか確認します。
- ファイアウォール: 同じサーバー上でも、一部のファイアウォール設定がUnixドメインソケット通信をブロックしている可能性は低いですが、TCPソケットを使っている場合はポートが開いているか確認します。
Nginx経由でアクセスできるが、アプリケーションエラーが発生する（Nginxが500 Internal Server Error、またはアプリケーション独自のカスタムエラーページ）:
- uWSGIのログ: uWSGIのログファイル (logto で指定したファイル) を確認します。Pythonのトレースバック（エラーの詳細な情報）がここに記録されている可能性が高いです。
- アプリケーションのログ: アプリケーション自体がロギングを設定している場合は、そのログファイルも確認します。
- 開発サーバーでの動作確認: uWSGIやNginxの設定問題ではなく、アプリケーション自体の問題である可能性もあります。アプリケーションを開発サーバー (flask run や manage.py runserver) で起動してみて、同じエラーが発生するか確認します。
- 環境変数の違い: 開発環境と本番環境（uWSGIで実行される環境）で、設定ファイルや環境変数の値が異なり、それが原因でエラーが発生している可能性があります。特にデータベース接続情報、APIキー、デバッグモードの設定などを確認します。env = KEY=VALUE オプションで環境変数を設定できます。
リクエストタイムアウト（Nginxが504 Gateway Timeoutエラー）:
- uWSGIワーカーがハングアップしていないか: uWSGIプロセスは動作しているが、ワーカープロセスが特定の重い処理でブロックされている可能性があります。uWSGIの統計情報（stats socket）でワーカーの状態を確認したり、ログに特定の処理で時間がかかっているという情報が出ていないか確認します。
- NginxとuWSGIのタイムアウト設定: Nginx設定の uwsgi_read_timeout, uwsgi_connect_timeout, uwsgi_send_timeout が短すぎる可能性があります。処理時間に合わせてこれらの値を増やします。
- uWSGIワーカーの再起動: reload-on-rss や max-requests オプションで定期的にワーカーを再起動するように設定することで、ハングアップしたワーカーが解放されることがあります。

トラブルシューティングの際には、ログを確認することが最も重要です。uWSGIのログ、Nginxのログ、そしてアプリケーション自身のログを連携させて確認することで、問題の切り分けが容易になります。

13. uWSGIとGunicornの比較

PythonのWSGIサーバーとしては、uWSGIの他にGunicorn (Green Unicorn) もよく使われています。初心者にとってどちらを選べば良いか迷うこともあるでしょう。簡単な比較を示します。

uWSGI:
- C言語で書かれており、非常に高速で多機能。
- Python以外の言語（Ruby, PHPなど）もサポート。
- 多くのプロトコル（HTTP, uwsgi, FastCGIなど）に対応。
- 高度なプロセス/スレッド管理、監視、Emperorモードなど、豊富なオプションを持つ。
- 設定が多岐にわたり、やや複雑に感じることがある。
- ビルドにはCコンパイラなどが必要。
Gunicorn:
- Pythonで書かれており、インストールや設定が比較的シンプル。
- WSGIに特化している（ASGIも一部サポート）。
- HTTPプロトコルまたは独自の非同期プロトコルでWebサーバーと連携。
- プロセス管理機能は提供するが、uWSGIほど多機能ではない（例: Emperorのような多アプリケーション管理機能はない）。
- 設定オプションはuWSGIより少ない。
- Pythonだけで動作するため、依存関係が少ない。

どちらも本番環境でPython Webアプリケーションを運用する上で十分な性能と安定性を提供します。

シンプルさやPythonエコシステムとの親和性を重視するならGunicorn
最高のパフォーマンス、豊富な機能、マルチ言語対応、詳細なチューニングを求めるならuWSGI

という傾向があります。uWSGIは機能が豊富な反面、学習コストが若干高いと言えますが、一度習得すれば非常に強力なツールとなります。

この記事ではuWSGIに焦点を当てていますが、Gunicornも有力な選択肢であることを覚えておくと良いでしょう。

14. まとめと次のステップ

この記事では、Python WebアプリケーションをuWSGIを使ってデプロイするための基本的なステップと重要な概念を詳細に解説しました。

なぜWSGIサーバーが必要なのか、WSGIとは何かを理解しました。
uWSGIのインストールと基本的なHello Worldアプリケーションの実行方法を学びました。
マスタープロセス、ワーカー、スレッド、ソケットといったuWSGIのコアコンセプトを理解しました。
INI形式の設定ファイルを使ったより詳細な設定方法を学びました。
Nginxをリバースプロキシとして使用し、uWSGIと連携させる標準的なデプロイ構成を理解しました。
FlaskおよびDjangoアプリケーションのデプロイ例を見ました。
uWSGIプロセスの停止、グレースフルリロード、systemdによる管理方法を学びました。
ロギング、セキュリティ、パフォーマンスチューニング、トラブルシューティングといった運用上の考慮事項について解説しました。
uWSGIとGunicornの比較を行いました。

uWSGIは非常に多くのオプションと機能を備えた強力なツールです。この記事で紹介できたのはその一部に過ぎません。

次のステップとして、以下のことをお勧めします。

実践: 実際に自分のアプリケーションをuWSGIとNginxを使ってデプロイしてみましょう。小さなアプリケーションから始めて、設定を試行錯誤してみてください。
ドキュメントの参照: uWSGIの公式ドキュメントは非常に詳細で網羅的です。この記事で紹介しきれなかった多くのオプションや高度な設定について学ぶことができます。（英語ですが、Google翻訳などを活用しながら読み進める価値があります）。
systemd/supervisorの活用: 本番環境での運用には、プロセス管理システムは必須です。systemd または supervisor の設定方法を学び、uWSGIプロセスをそれらで管理できるようにしましょう。
監視とロギング: uWSGIのstats socketや詳細なロギング設定を活用し、アプリケーションのパフォーマンスやエラー状況を常に把握できる体制を構築しましょう。
セキュリティの深化: 非rootユーザーでの実行、ソケット権限、ファイアウォール設定など、セキュリティに関する設定をより深く理解し、適切に構成しましょう。

uWSGIは、Python Webアプリケーションを本番環境で安定かつ効率的に動かすための強力な基盤を提供してくれます。最初は設定の多さに戸惑うかもしれませんが、基本的な構成から始めて、徐々に理解を深めていけば、その強力さを実感できるはずです。

あなたのPythonアプリケーションデプロイが成功することを願っています！

uWSGI入門：Python Webアプリケーションを堅牢かつ高速にデプロイする

1. なぜWSGIサーバー（そしてuWSGI）が必要なのか？

1.1. WSGIとは何か？

1.2. uWSGIの立ち位置

2. uWSGIを使うための準備

2.1. Pythonとpip

2.2. 仮想環境 (Virtual Environment)

プロジェクトディレクトリに移動

仮想環境を作成 (envという名前で作る例)

仮想環境をアクティベート

Linux/macOS:

Windows (Command Prompt):

env\Scripts\activate.bat

Windows (PowerShell):

env\Scripts\Activate.ps1

2.3. 必要なビルドツールのインストール

2.4. 簡単なWebアプリケーション（またはフレームワーク）

3. uWSGIのインストール

仮想環境をアクティベートしていることを確認

4. uWSGIの基本：Hello World

wsgi.py

5. uWSGIのコアコンセプト

5.1. マスタープロセスとワーカープロセス (Master Process and Workers)

5.2. スレッド (Threads)

5.3. ソケット (Sockets)

5.4. uwsgiプロトコル

5.5. Emperorモード

6. 設定ファイルを使ったuWSGIの起動

uwsgi.ini

モジュールとcallableを指定

例えば、myproject/wsgi.py の application callable を指定する場合

アプリケーションのルートディレクトリに移動

これにより、Pythonがアプリケーションのモジュールを見つけられるようになる

仮想環境のパスを指定 (オプションだが強く推奨)

virtualenv = /path/to/your/project/env

マスタープロセスを有効化

ワーカープロセス数

各ワーカーのスレッド数 (I/Oバウンドなアプリ向け、CPUバウンドなら不要なことも)

リクエストを待ち受けるソケット

Nginxと連携する場合は Unix ドメインソケットが推奨

ソケットのパーミッション (他のユーザーからのアクセスを許可する場合)

通常は Nginx が uwsgi を実行するユーザーと同じグループに属するように設定し、660 にするのが安全

起動時のログレベル (デフォルトは info)

log-level = critical

ログの出力先 (ファイル、syslogなど)

エラーログのみ別の場所に出力

disable-logging = true # リクエストログを出力しない

logto = /var/log/uwsgi/myproject_error.log # 標準出力/エラー出力をリダイレクト

バックグラウンドでデーモンとして実行

PIDファイルを作成 (停止やリロードに使う)

ファイルを touch するとワーカーがリロードされる

touch-reload = /path/to/your/project/uwsgi.ini # 設定ファイル変更でリロード

touch-reload = /path/to/your/project/wsgi.py # アプリケーションコード変更でリロード

————————————————————

オプションの便利な設定

————————————————————

アプリケーションの起動タイムアウト (秒)

ready-timeout = 60

ワーカーがリクエスト処理中にクラッシュした場合に再起動

worker-reload-mercy = 8

メモリリーク対策などで定期的にワーカーを再起動

max-requests = 5000 # ワーカーが5000リクエスト処理したら再起動

reload-on-rss = 100 # ワーカーのメモリ使用量が100MBを超えたら再起動 (Mb)

Nginxの proxy_buffering が off の場合にレスポンスをチャンクで送信

enable-threads = true # threads を使う場合は必須

post-buffering = 8192

プロセスに名前をつける (ps コマンドで分かりやすくなる)

procname-master = uwsgi_master_myproject

procname-prefix = uwsgi_worker_myproject_

staticsize とか sendfile とか色々ある

参考: https://uwsgi-docs.readthedocs.io/en/latest/Options.html

仮想環境がアクティベートされていることを確認

設定ファイルはプロジェクトのルートにあるとする

7. NginxとuWSGIの連携

7.1. Nginxの役割

7.2. NginxとuWSGIの連携方法

… その他の設定 …

…

/etc/nginx/sites-available/myproject

7.3. ユーザーと権限

コメントする返信をキャンセル