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 を使うことにしましたよ！

コメント

コメントを投稿

このブログの人気の投稿

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 を処理する キャッシュしたところで...
続きを読む

#PySpa アドベント (23 日目)

PySpa がどんなイベントかは 既に紹介されつくした感じ ですね。そもそも勉強会は "特定のテーマを共有し理解を深める" という目的のものが多いと思っています。PySpa は、それより "勉強したくなるようなテーマを発見する" ってのが大きいと個人的に思っています。私は 勉強したいテーマを見つける 童心に返って技術を楽しむ 煙草エリアのベンチを温める ために行っています。与えられてばかり、お世話になってばかりです。モチベーションしかり、趣味しかり、仕事しかり。
続きを読む