fastcgi-nginx vs mod_wsgi-apache

"mod_python 終了のお知らせ" を受け、もともとリソース不足だった既存の Django アプリケーション郡のサーバをリプレイスすることにしました。リプレイス要件↓

  • パフォーマンスが高いのにしたい
  • アプリケーションの変更は必要最小限にしたい
  • URL 類は既存のアプリケーションを引継ぐ: 複数プロジェクトをサブディレクトリーで運用していて、 "django.root" で複数プロジェクトを切り分けている

環境設定について

これは apache - mod_wsgi が簡単すぎます。

nginx - fastcgi

nginx - fastcgi 構成の場合は、init.d への登録、 daemontools を利用 (弊社は mod_python 以外はこれ)。

nginx の設定

/etc/nginx/fastcgi_params

fastcgi_read_timeout 180;
send_timeout 180;

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;
fastcgi_param  PATH_INFO          $fastcgi_script_name;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;
fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

fastcgi_pass_header Authorization;
fastcgi_intercept_errors off;

/etc/nginx/sites-enabled/default

server {
        listen   80;
        server_name  example.com;

        access_log  /var/log/nginx/example.com.access.log;

        # No www !　<- www を付けたくない場合の設定
        if ($host = 'www.example.com' ) {
                rewrite  ^/(.*)$  http://example.com/$1  permanent;
        }

        # Django の設定　<- 各 Django プロジェクトはポートで分ける
        location / {
                include /etc/nginx/fastcgi_params;
                fastcgi_pass 127.0.0.1:8080;
        }

        # Admin sites　の設定 <- ローカルからに限定する
        location /admin {
                include /etc/nginx/fastcgi_params;
                fastcgi_pass 127.0.0.1:8080;

                allow [LOCAL_IP_ADDRESS];
                deny all;
        }

        # Static Files
        location /static {
                root   /path/to/staticfiles;
                access_log off;　# アクセスログいらない
        }

        # Admin medias
        location /media {
                root   /path/to/django/contrib/admin/media;
                access_log off;　# アクセスログいらない
        }
}
fastcgi の起動を init.d に登録

Django FastCGI init.d script for Linux を参考に、init.d スクリプトを作成し、反映する。

update-rc.d /etc/init.d/fastcgi defaults
daemontools の設定
# パッケージ名は daemontools or svtools のいずれか
sudo aptitude install daemontools daemontools-run

プロジェクト毎に、デーモンツールを作成する。
/etc/service/[PROJECT]/run

#!/bin/sh
#
#### SERVER SPECIFIC CONFIGURATION
SITE=[PROJECT]
HOST=127.0.0.1
PORT=[PORT]

SITES_PATH=/var/django
ENVIRONMENT_PATH=$SITES_PATH/environment
RUNFILES_PATH=/var/run/django
RUN_AS=www-data
MAXREQUESTS=1000

#### DO NOT CHANGE ANYTHING AFTER THIS LINE!
#
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="[PROJECT DESCRIPTION]"

cd $SITES_PATH/$SITE

# find python binary to use
if [ -f $ENVIRONMENT_PATH/$SITE/bin/python ]; then
    PYTHON=$ENVIRONMENT_PATH/$SITE/bin/python
else
    PYTHON=`which python`
fi

exec 2>&1

exec setuidgid $RUN_AS \
    /usr/bin/env -- $PYTHON \
    $SITES_PATH/$SITE/manage.py runfcgi \
    protocol=fcgi method=threaded maxrequests=$MAXREQUESTS \
    host=$HOST port=$PORT \
    pidfile=$RUNFILES_PATH/$SITE.pid \
    daemonize=false

chmod -R 777 $RUNFILES_PATH
mod_wsgi - apache
wsgi 用スクリプトの作成

各 Django アプリケーションごとに作成します。settings.py と同一階層に置くことを前提。

#!/usr/bin/python
# -*- encoding: utf-8 -*-
# wsgi_handler.py

import sys
import os

# print デバッグとかしてるとこけるから、追加しちゃった。
sys.stdout = sys.stderr

sys.path.append(os.path.dirname(os.path.abspath(__file__)) + '/..')
os.environ['DJANGO_SETTINGS_MODULE'] = '[PROJECT].settings'

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()
mod_wsgi の設定
sudo aptitude install libapache2-mod-wsgi

<VirtualHost *:80>
        ServerAdmin mail@example.com
        ServerName example.com

        DocumentRoot /var/www

        # Django settings
        WSGIScriptAlias / /path/to/project/wsgi_handler.py

        ErrorLog /var/log/apache2/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog /var/log/apache2/access.log combined

</VirtualHost>

daemon mode で起動したい場合の設定は、id:pyxis-dev さんのサイトが参考になります。私も daemon mode で運用しています。

パフォーマンスについて

結論から言うと、fastcgi も mod_wsgi も uwsgi もパフォーマンスに大きな差はありません (mod_python よりは早い) でした。パフォーマンスの差異については、 id:perezvon さんや Alexander Solovyov さんのサイト (英語) 等も参考になります。私がテストした環境だと、初回アクセス時のみ fastcgi の方が若干早かったですが、やはりその後は誤差の範囲内です。

mod_python からの移行について (URL とか)

前述のように、複数の Django プロジェクトをサブディレクトリで運用している場合は、 mod_wsgi の方が簡単です。 mod_python でいうところの "django.root" は mod_wsgi では以下のように設定できます。

# mod_python
<Location "/mysite/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
    PythonOption django.root /mysite
    PythonDebug On
</Location>
<Location "/mysite2/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite2.settings
    PythonOption django.root /mysite2
    PythonDebug On
</Location>

# mod_wsgi
<VirtualHost *:80>
        WSGIScriptAlias /mysite /path/to/django/mysite/wsgi_handler.py
        WSGIScriptAlias /mysite2 /path/to/django/mysite2/wsgi_handler.py
</VirtualHost>

fastcgi の場合は、rewrite の利用や、FORCE_SCRIPT_NAME で置き換えるか、 urls.py を書き換える必要があります。めんどい・・・。

ということで mod_wsgi を使うことにしましたよ！

コメント

コメントを投稿

このブログの人気の投稿

Python から Win32 API 経由で印刷する

Win32 API から印刷をするためには、プリンタデバイスコンテキスト (Printer DC) を利用します。具体的には以下のような順序で印刷します。 プリンタドライバからハンドルを取得する プリンタドライバのステータス API から印刷可能か同かを取得する プリンタデバイスコンテキストを作成する ドキュメントを開始する 必要であればフォント等を設定し、印字、改ページ処理などをする ドキュメントを終了する (この時点でプリンタスプールサービスに登録されるようです) プリンタデバイスコンテキストを開放する プリンタドライバのステータス API を監視し、印刷が正常に終了したかを取得する プリンタドライバのハンドルを解放する 太字の手順 (3 - 7) は Win32 API で共通ですが、それ以外の手順 (1, 2, 8, 9) はプリンタドライバに依存しているため、Python から制御したい場合はライブラリを作成する必要があります。これについては、ドライバマニュアルとにらめっこしながら ctypes.windll でがんばります・・・。プリンタ接続、用紙切れ、ミスフィード等のプリントエラーを制御する必要がなければ、書く必要はありません (排他制御が必要なプリンタを除く)。プリンタドライバ毎に変わる部分は置いといて、太字の Win32 API の部分の覚書です。 プリンタデバイスコンテキストを作成する import win32ui import win32con PRINTER_NAME = '[コンパネ -> プリンタとFAX -> に登録しているプリンター名]' PIXELS_PER_INCH = 1440 # 1 インチ毎のピクセル数 INCH_PER_POINT = 72 # 1 インチ毎のポイント数 SCALE_FACTOR = int(PIXELS_PER_INCH / INCH_PER_POINT) #　わざわざ計算せず 20 と指定する場合が多い dc = win32ui.CreateDC() dc.CreatePrinterDC(PRINTER_NAME) # 指定したプリンタ名のプリンタデバイスコンテキストを作成する self.dc.SetMapMode(win32con.MM...
続きを読む

Disqus のスケール - Django 編

イメージ
やり直し。2010 年の Django Con のスライド より。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/ PgBouncer : コネクションプール用。 PostgreSQL: 10 台ぐらい。 Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFouine でスロークエリーをロギング。 全部でサーバ 100 台ぐらい。他にユーティリティサーバ 15 台、後は HAProxy と heartbeat 用に 20 台ぐらいの構成。Varnish と syslog-ng を除けば Django のデプロイ手順に掲載されているような教科書通り (良い意味です) の構成です。(なんで Apache なの？nginx + gunicorn 速いよって突っ込まれてますね >>> データベースのパーティショニング Django はアプリケーションレベルで簡単に 垂直 パーティショニングができます。アプリケーションごとに DB 分けたり、DB をアプリケーションレベルでルーティングできます ( ドキュメント )。 水平パーティショニング (a.k.a シャーディング) もアプリケーションで 書ける (なるほど・・・)。 >>> キャッシュの削除 Django は QuerySet の結果をキャッシュするけど、それがかなりメモリを消費する。なので SkinnyQuerySet を作った (たぶん Johnny Cache の方が有名？...
続きを読む

Disqus のスケール - Django で月間80億PVを処理する

私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。 月間80億PV 、 45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は 高速開発とパフォーマンス 、 新しい人が入ってすぐに開発に参加できることとカスタマイズ 等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか 最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート ( django.contrib とか?) や不要なコードがあるため。そもそも Django の思想が Python 同様 " バッテリー同梱 (batteries included) " のため、Django は他の Python 製 WAF よりボイラープレートが多いです。Disqus 曰く "実は 言語や WAF は遅さにあまり関係ない " それより " ネットワーク内の他のサービスとの通信 " のオーバーヘッドが原因とのこと。これは一般的によく言われてることですし、大規模になればなるほどそう。Disqus の場合は PostgreSQL, redis, Cassandra , Memcached 等のサービスが使われているそうです。DB へのスロークエリーやネットワークのレイテンシーは Django のようなボイラープレートによるオーバーヘッドを軽く上回ります。この待ち時間を回避する一番メジャーな方法はキャッシュの使用です。Django では キャッシュフレームワーク を使用します。Django でキャッシュを使うのは簡単ですし、バックエンドに Memcached を使うと充分高速化できます。 はい。ここまでは一般的な話です。こっから。 >>> 45k req/seq を処理する キャッシュしたところで...
続きを読む