概要
私は、uWSGIを使う時は基本的にマルチプロセス、シングルスレッドの設定を推奨します。しかし、レスポンスタイムがときどき遅くなる外部API呼び出しを含む場合など、メモリ使用量やthundering herd問題を考慮しつつ多くの並列数が必要な場合にマルチスレッドとマルチプロセスを組み合わせてより高い並列数を稼ぎたい場合があります。
マルチスレッドとマルチプロセスを併用する場合、プロセス間でリクエストをうまく分散させるロードバランスが問題になります。この記事ではその問題と解決方法について実験を交えて解説します。
マルチスレッド
まずはマルチスレッドの特性を確認していきましょう。サンプルとしてこんなwebアプリケーションを用意します。実験に使っているPC上では、 fib(25) 1回あたりに約10msかかり、全体で100ms程度かかっています。
import time
import threading
def fib(n):
if n < 2:
return n
return fib(n-1) + fib(n-2)
def app(environ, start_response):
for _ in range(5):
time.sleep(0.01)
fib(25)
start_response("200 OK", [("Content-type", "text/plain; charset=utf-8")])
return [b"Hello, world"]
これを次のような設定で nginx + uWSGI で動かします。
worker_processes 1;
pid nginx.pid;
error_log error.log;
events {
worker_connections 768;
}
http {
include mime.types;
access_log access.log;
upstream myapp {
server 127.0.0.1:5000;
}
server {
listen 8000 default_server;
server_name _;
location / {
include uwsgi_params;
uwsgi_pass myapp;
}
}
}
[uwsgi]
socket = 127.0.0.1:5000
master = 1
pidfile = uwsgi.pid
die-on-term = 1
lazy-app = 1
disable-logging=1
threads = 4
module=wsgi
callable=app
wrkを使って1, 2, 4並列で負荷をかけてみます。
$ wrk -t1 -c1 --latency -d20s http://localhost:8000
Running 20s test @ http://localhost:8000
1 threads and 1 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 107.36ms 535.89us 112.24ms 96.77%
Req/Sec 9.62 1.32 10.00 92.47%
Latency Distribution
50% 107.30ms
75% 107.47ms
90% 107.68ms
99% 111.54ms
186 requests in 20.03s, 36.69KB read
Requests/sec: 9.28
Transfer/sec: 1.83KB
$ wrk -t1 -c2 --latency -d20s http://localhost:8000
Running 20s test @ http://localhost:8000
1 threads and 2 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 117.63ms 3.49ms 140.45ms 88.82%
Req/Sec 17.43 4.36 20.00 74.47%
Latency Distribution
50% 116.27ms
75% 116.54ms
90% 124.00ms
99% 129.20ms
340 requests in 20.03s, 67.07KB read
Requests/sec: 16.98
Transfer/sec: 3.35KB
$ wrk -t1 -c4 --latency -d20s http://localhost:8000
Running 20s test @ http://localhost:8000
1 threads and 4 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 231.09ms 27.29ms 315.45ms 66.86%
Req/Sec 17.43 6.86 30.00 48.07%
Latency Distribution
50% 229.52ms
75% 248.26ms
90% 272.18ms
99% 300.65ms
344 requests in 20.03s, 67.86KB read
Requests/sec: 17.18
Transfer/sec: 3.39KB
2並列の場合はレスポンスタイムが1割ほど悪化しつつ、スループット(req/sec)は2倍弱に増えています。4並列ではスループットが2並列とほぼ同じで、それに応じてレスポンスタイムが悪化しています。
これは1並列時のレスポンスタイムのうち約50%がPythonのGILを必要としているためで、マルチスレッドでは2並列までしかスケールしません。
マルチプロセス
次にマルチプロセスでの特性を確認します。先ほどの設定の threads=4 を workers=4 に書き換えて、今度は4,8並列での結果をみていきます。
$ wrk -t1 -c4 --latency -d20s http://localhost:8000
Running 20s test @ http://localhost:8000
1 threads and 4 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 108.95ms 3.10ms 142.10ms 88.95%
Req/Sec 36.70 5.93 40.00 72.86%
Latency Distribution
50% 107.89ms
75% 109.99ms
90% 112.21ms
99% 119.35ms
733 requests in 20.04s, 144.60KB read
Requests/sec: 36.58
Transfer/sec: 7.22KB
$ wrk -t1 -c8 --latency -d20s http://localhost:8000
Running 20s test @ http://localhost:8000
1 threads and 8 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 212.50ms 7.43ms 232.21ms 98.54%
Req/Sec 38.17 5.99 40.00 90.16%
Latency Distribution
50% 212.84ms
75% 213.05ms
90% 213.28ms
99% 219.39ms
751 requests in 20.04s, 148.15KB read
Requests/sec: 37.48
Transfer/sec: 7.39KB
マルチスレッドと比較すると4並列まで綺麗にスケールしていることがわかります。
8並列にした場合はワーカー数が足りなくなり、平均レスポンスタイムが倍になっています。1つのlistenキューからacceptされたリクエストが順番に処理されるので、90%tileや99%tileのレスポンスタイムが平均から大きく乖離していないのは好ましい特性です。先ほどの4スレッドの1ワーカーに4並列でアクセスした場合に比べると、99%tileレスポンスタイムは2/3程度に抑えられています。
マルチプロセス * マルチスレッド
次はマルチプロセスとマルチスレッドを同時に利用します。
workers = 4
threads = 4
マルチプロセスの時と同じように4,8並列で負荷をかけてみます。
$ wrk -t1 -c4 --latency -d20s http://localhost:8000
Running 20s test @ http://localhost:8000
1 threads and 4 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 185.46ms 50.06ms 298.03ms 60.70%
Req/Sec 21.77 9.33 40.00 64.92%
Latency Distribution
50% 194.01ms
75% 224.45ms
90% 245.66ms
99% 276.01ms
430 requests in 20.03s, 84.82KB read
Requests/sec: 21.47
Transfer/sec: 4.24KB
$ wrk -t1 -c8 --latency -d20s http://localhost:8000
Running 20s test @ http://localhost:8000
1 threads and 8 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 187.29ms 52.88ms 382.29ms 60.63%
Req/Sec 42.60 14.37 80.00 67.34%
Latency Distribution
50% 189.82ms
75% 229.73ms
90% 254.79ms
99% 298.24ms
850 requests in 20.02s, 167.68KB read
Requests/sec: 42.45
Transfer/sec: 8.37KB
マルチプロセスの時と比べると8並列の時のスループットはよくなっているものの、99%tileのレスポンスタイムは逆に1.5倍に悪化しています。しかも4並列のときはレスポンスタイムだけでなくスループットも悪化しています。
これがプロセス間ロードバランスの問題です。各プロセスが最大4並列でリクエストを処理できるため、リクエストが1プロセスに集中する場合があり、99%tileのレスポンスタイムが1番最初に行った1プロセス4スレッドに4並列で負荷をかけた時の値に近づいてしまっているのです。
nginxを利用したプロセス間ロードバランス
この問題を解決するための方法として、ドキュメントの次のセクションで紹介されている方法がよさそうです。この方法とnginxのupstreamモジュールの機能を組み合わせてプロセス間ロードバランスを実現してみます。
Serializing accept(), AKA Thundering Herd, AKA the Zeeg Problem — uWSGI 2.0 documentation
次のように設定ファイルを書き換えて、uWSGIの各ワーカーがそれぞれ別のソケットをlistenし、nginxにそれらに対して least_conn でロードバランスさせます。
workers=4
threads=4
; ソケットを4つ作る
socket = 127.0.0.1:5000
socket = 127.0.0.1:5001
socket = 127.0.0.1:5002
socket = 127.0.0.1:5003
; ソケットをワーカーにマッピングする。ソケット番号は0から、ワーカー番号は1から始まることに注意。
map-socket = 0:1
map-socket = 1:2
map-socket = 2:3
map-socket = 3:4
upstream myapp {
server 127.0.0.1:5000;
server 127.0.0.1:5001;
server 127.0.0.1:5002;
server 127.0.0.1:5003;
least_conn;
}
uWSGI起動時に次のようなログが出力され、各ソケットがそれぞれ別のワーカーにマッピングされていることがわかります。
spawned uWSGI master process (pid: 42729)
spawned uWSGI worker 1 (pid: 42730, cores: 4)
spawned uWSGI worker 2 (pid: 42731, cores: 4)
mapped socket 0 (127.0.0.1:5000) to worker 1
spawned uWSGI worker 3 (pid: 42732, cores: 4)
mapped socket 1 (127.0.0.1:5001) to worker 2
spawned uWSGI worker 4 (pid: 42733, cores: 4)
mapped socket 2 (127.0.0.1:5002) to worker 3
mapped socket 3 (127.0.0.1:5003) to worker 4
また4,8並列で負荷をかけてみます。
$ wrk -t1 -c4 --latency -d20s http://localhost:8000
Running 20s test @ http://localhost:8000
1 threads and 4 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 108.78ms 2.52ms 122.69ms 84.51%
Req/Sec 36.88 6.84 40.00 78.89%
Latency Distribution
50% 107.95ms
75% 109.76ms
90% 112.23ms
99% 117.80ms
736 requests in 20.03s, 145.19KB read
Requests/sec: 36.74
Transfer/sec: 7.25KB
$ wrk -t1 -c8 --latency -d20s http://localhost:8000
Running 20s test @ http://localhost:8000
1 threads and 8 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 135.41ms 12.10ms 186.63ms 76.30%
Req/Sec 59.02 15.26 80.00 61.62%
Latency Distribution
50% 132.56ms
75% 141.02ms
90% 151.48ms
99% 176.16ms
1177 requests in 20.02s, 232.18KB read
Requests/sec: 58.79
Transfer/sec: 11.60KB
4並列ではマルチプロセスと同じ結果になり、8並列ではマルチプロセスの時よりもスループットも99%tileレスポンスタイムも大幅に改善しています。ロードバランスの問題が解決できていることがわかります。
一見理想的に見えますが、問題もあります。もし外部APIが詰まった場合はすべてのスレッドが詰まってしまうのですが、listenキューが1つの時は最初に空いたスレッドが次のリクエストを受け取れたのに、listenキューをバラバラにした場合は空いたスレッドが別のプロセスのlistenキューで待たされているリクエストを処理できないのです。
nginxのupstreamモジュールのドキュメントを読むと、 max_conns オプションで各upstreamサーバーへの同時接続数を制限して、 queue オプションで待ち行列を設定できるようです。これを使えば問題は解決できそうですが、残念ながら queue オプションはnginxの商用版でしか利用できないので今回は実験していません。
このオプションが利用できなくても、スレッド数にかなり余裕を持って設定しておき、かつCPU使用率が高くなったらコンテナやVMがスケールアウトするようにしておけば、リクエスト数が跳ね上がった場合にも外部APIが遅くなった場合にも十分に耐えられると思います。
さいごに
紹介した uWSGI ドキュメント内の記事では、thundering herd問題を解決するための方法として --thunder-lock オプションも紹介されています。しかしこのオプションではロードバランス問題は解決しません。プロセス間ロックがFIFOになっていても、最初に起動したワーカープロセスの全スレッドがそのロック待ち状態になってから次のワーカープロセスが起動してしまうので、4スレッドであれば最初の4リクエストが最初のワーカープロセスに集中してしまうのです。
今さらスレッド？と思われる方もいるかもしれませんが、asyncioを使ってもCPUのマルチコアを活かすためにはマルチプロセスが必要で同じようにロードバランス問題が発生するので、この記事の設定は参考になると思います。
また、フリースレッド版Pythonがあればシングルプロセスで済むという意見もあるかもしれません。完全にシングルスレッドにしてしまえば構成がシンプルになるのはいいのですが、GILが無くなっても代わりになる小粒度のロックは存在するので、アクセスが増えた時にロック競合が増えてしまいマルチスレッドだけではCPUコア数をフルに活用できない可能性があります。GILが無くなってもマルチプロセス構成のメリットが消えるわけではありません。
