前回のリプレイスでどのくらい変化があるかを調べてみました。構成などはそちらをご覧ください。

対象サーバーをDNSから外してアクセスを止め、リプレイス作業後、DNSに再登録しました。
そのビフォアとアフターのグラフです。

Apacheのアクセス数
横軸のひと目盛は6時間なので、4日午前0時にアクセスが止まって、5日の午前2時にアクセスがもどっていることがわかると思います。（3日のアクセス数が少ないのはラウンドロビン環境下のサーバーを2台から3台に増やしたからです。5日には再び2台に戻しています。）

nginxのリクエスト数（アクセス数）
nginxも5日の午前2時頃からアクセスされ始めました。ビフォア（Apache）もアフター（nginx）もちょうどピーク時に160リクエスト程度を受けているので、アクセス数は同じくらいと考えられます。

トラフィック
ビフォアとアフターでピーク時に2Mbits/s程度レスポンスを、やはり同じように返しています。ここからも同程度のパフォーマンスを発揮していることがわかります。

I/O待ちの数
ビフォアでピーク時に7〜9あったI/O待ちのプロセス数が2程度に減少しています。

ロードアベレージ
I/O待ちが解消したことで、ピーク時に7〜8程度まで上がっていたロードアベレージがアフターでは2程度に落ち着いています。

実際は、ビフォアのApacheはWeb+APサーバーの機能を担っていたのと、MPM設定がPHPの影響でpreforkになっていたので、公平を期するためには、workerに設定したApache（mod_proxy）のWebサーバー+APサーバーで比べる必要があるかもしれません。

yubitterという携帯向けTwitterクライアントサービスで、ユーザーのアイコンを携帯電話向けに変換している(※1)、いわゆる画像変換サーバーのhttpd部分をApacheからnginxへ変更しました。

処理は単純に以下の流れです。

1. クライアントからアイコン画像のリクエストが来る
2. 既にハードディスクにキャッシュファイルがある場合は、それをそのまま返す
3. ファイルがない場合は、PHPプログラムがアイコン画像がアップロードされているTwitterのサーバー（現在はAmazon S3/CloudFront）へ取りに行く
4. PHPプログラムが取得した画像データをGDライブラリを利用して加工、ハードディスクに保存、レスポンスを返す

変換するにあたり、以下の2パターンを検討しました。

リプレイス案1は、Apacheのレイヤーを一つ下げてAPサーバーに専念してもらう案で、2案は、Apache+mod_phpの構成をやめて、php-fpm(FastCGI)に置き換える案です。

厳密にテストをしたかったのですが、時間が取れなかったのでどこかにベンチマークがないものかとGoogleで探してみたところ、
Apache + mod_php compared to Nginx + php-fpm
このブログを見つけました。

このデータからわかるのは、同時アクセス時のリクエスト処理数はApache+mod_php（-kはKeepAliveのこと）の方が優れているということで、実際には処理速度とメモリの消費量という観点でmod_php v.s. php-fpmを計測するべきだと思います。

今回は、上記のデータとリプレイスが簡単で影響が少ないということで、1案で対応しました。時間があれば、Apache + mod_php v.s nginx + php-fpmのベンチマークをやりたいと思います。

まず、nginxをインストールします。

#nginxのコンパイルに必要なもの
sudo yum install pcre-devel.x86_64
sudo yum install openssl-devel.x86_64

#stableの最新版を公式サイトから取得
wget http://www.nginx.org/download/nginx-0.7.67.tar.gz
tar vfxz nginx-0.7.67.tar.gz 
cd nginx-0.7.67

#監視用のステータス取得モジュールオプションを付ける
./configure --with-http_stub_status_module
make
sudo make install

標準では/usr/local/nginx にインスールされます。

設定ファイルを修正します。

sudo vi /usr/local/nginx/conf/nginx.conf

user  apache apache;
worker_processes  2;

error_log  logs/error.log;
pid        logs/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  logs/access.log  main;

    sendfile    on;
    tcp_nopush  on;
    tcp_nodelay on;
    keepalive_timeout  10;
    server_tokens off;
    ignore_invalid_headers on;
    connection_pool_size 256;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 2k;
    request_pool_size 4k;

    server {
        listen       80;
        server_name  localhost;

        location / {
            access_log off;
            return 403;
        }

        location /server-status {
            proxy_pass http://localhost:8080;
            access_log off;
            allow 127.0.0.1;
            deny all;
        }

        location /nginx_status {
            stub_status on;
            access_log off;
            allow 127.0.0.1;
            deny all;
        }

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }

    include /usr/local/nginx/conf/example.jp.conf;
}

includeするバーチャルホストの設定ファイルを作成します。

sudo vi /usr/local/nginx/conf/example.jp.conf

proxy_redirect                          off;
proxy_set_header Host                   $host;
proxy_set_header X-Real-IP              $remote_addr;
proxy_set_header X-Forwarded-Host       $host;
proxy_set_header X-Forwarded-Server     $host;
proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;

server {
    listen       80;
    server_name  example.jp;
    root /var/www/example.jp/public_html;

    location / {
        if (-f $request_filename) {
            access_log off;
            expires 30d;
            break;
        }

        if (!-f $request_filename) {
            proxy_pass http://localhost:8080;
            access_log off;
            break;
        }
    }

    location ~ \.php {
            proxy_pass http://localhost:8080;
            break;
    }
}

Linux用の起動スクリプトを作成します。

sudo vi /etc/init.d/nginx

#!/bin/sh
#
# nginx - this script starts and stops the nginx daemin
#
# chkconfig:   - 85 15 
# description:  Nginx is an HTTP(S) server, HTTP(S) reverse \
#               proxy and IMAP/POP3 proxy server
# processname: nginx
# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ "$NETWORKING" = "no" ] && exit 0

nginx="/usr/local/nginx/sbin/nginx"
prog=$(basename $nginx)

NGINX_CONF_FILE="/usr/local/nginx/conf/nginx.conf"

lockfile=/var/lock/subsys/nginx

start() {
    [ -x $nginx ] || exit 5
    [ -f $NGINX_CONF_FILE ] || exit 6
    echo -n $"Starting $prog: "
    daemon $nginx -c $NGINX_CONF_FILE
    retval=$?
    echo
    [ $retval -eq 0 ] && touch $lockfile
    return $retval
}

stop() {
    echo -n $"Stopping $prog: "
    killproc $prog
    retval=$?
    echo
    [ $retval -eq 0 ] && rm -f $lockfile
    return $retval
}

restart() {
    configtest || return $?
    stop
    start
}

reload() {
    configtest || return $?
    echo -n $"Reloading $prog: "
    killproc $nginx -HUP
    RETVAL=$?
    echo
}

force_reload() {
    restart
}

configtest() {
  $nginx -t -c $NGINX_CONF_FILE
}

rh_status() {
    status $prog
}

rh_status_q() {
    rh_status >/dev/null 2>&1
}

case "$1" in
    start)
        rh_status_q && exit 0
        $1
        ;;
    stop)
        rh_status_q || exit 0
        $1
        ;;
    restart|configtest)
        $1
        ;;
    reload)
        rh_status_q || exit 7
        $1
        ;;
    force-reload)
        force_reload
        ;;
    status)
        rh_status
        ;;
    condrestart|try-restart)
        rh_status_q || exit 0
	    ;;
    *)
        echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload|configtest}"
        exit 2
esac

起動スクリプトに実行パーミッションをつける

sudo chmod +x /etc/init.d/nginx

キャッシュファイルのパーミッションの関係があるので、起動ユーザーはapacheに合わせておきます。
特定ドメイン以外のアクセスは全て403を返すようにして、localhostからのステータス取得アクセスのみ許可します。ドキュメントルートにキャッシュファイルが存在する場合は、expiredヘッダーを付けて、nginxが返します。ファイルが存在しない場合や、拡張子が.phpのものはApacheに渡し、処理内容を返してもらいます。

Apache側はListenを8080ポートに変えます。Apacheはプロキシを介してアクセスされるので、クライアントのIPアドレスが取得できません。Apacheでも取得したい場合は、mod_rpafなどでX-Real-IPを変換する必要があります。

通常はgzip圧縮設定などもしますが、今回の用途では圧縮済みのjpgファイルのみのやりとりとなるので、設定を省いています。
nginxの詳しい説明は公式 非公式のWiki（日本語）が分かりやすいと思います。

次回は、リプレイス後のパフォーマンスの違いを書きます。
→nginxがApacheよりも優れていることが一目瞭然のグラフ

1. Twitterのアイコン画像はPNGやGIF、中にはBMPフォーマットでアップロードされているものがあり、全ての携帯電話で表示できるようにするために、変換する必要があります。

Flareのフェイルオーバー機能をテストしてみました。

ノード監視 + フェイルオーバー (インデックスサーバにより各サーバを監視し、ダウンした場合にはサービスアウトします。また、masterサーバがダウンした場合はslaveサーバのうち1台がmasterサーバに昇格します)
Flare – GREE Labsより

今回は後半のmasterサーバーがダウンした場合のテストです。
実際にダウンしてしまうというよりも、メンテナンスのためにを故意にダウンさせるケースを想定しています。実際の挙動を確認しておくことで、本番環境で自信を持ってmasterサーバーを落とすことができます。

設定ファイル

インストールは公式ドキュメントをご覧いただくとして、各サーバーの設定から。
1台のサーバーにインデックスサーバー*1、各ノードサーバー*3を立ち上げるため、ポートを変えて起動します。

インデックスサーバー

/etc/flare/flarei.conf

data-dir = /opt/flare/flarei
log-facility = local0
max-connection = 256
monitor-threshold = 3
monitor-interval = 1
server-name = localhost
server-port = 12120
thread-pool-size = 8

マスターノードサーバー

/etc/flare/flared_master.conf

data-dir = /opt/flare/flared_master
index-server-name = localhost
index-server-port = 12120
log-facility = local1
max-connection = 1024
mutex-slot = 64
proxy-concurrency = 2
server-name = localhost
server-port = 11211
storage-type = tch
thread-pool-size = 16
storage-ap = 4
storage-bucket-size = 16777216

スレーブノードサーバー

/etc/flare/flared_slave.conf

data-dir = /opt/flare/flared_slave
index-server-name = localhost
index-server-port = 12120
log-facility = local2
max-connection = 1024
mutex-slot = 64
proxy-concurrency = 2
server-name = localhost
server-port = 11212
storage-type = tch
thread-pool-size = 16
storage-ap = 4
storage-bucket-size = 16777216

プロキシノードサーバー

/etc/flare/flared_proxy.conf

data-dir = /opt/flare/flared_proxy
index-server-name = localhost
index-server-port = 12120
log-facility = local3
max-connection = 1024
mutex-slot = 64
proxy-concurrency = 2
server-name = localhost
server-port = 11213
storage-type = tch
thread-pool-size = 16
storage-ap = 4
storage-bucket-size = 16777216

syslog設定

/etc/syslog.conf

# Log flare
local0.*                                                /var/log/flarei.log
local1.*                                                /var/log/flared_master.log
local2.*                                                /var/log/flared_slave.log
local3.*                                                /var/log/flared_proxy.log

通常運用状態を再現

設定が終わったら、各サーバーを起動します。

sudo /usr/local/flare/bin/flarei -f /etc/flare/flarei.conf --daemonize
sudo /usr/local/flare/bin/flared -f /etc/flare/flared_master.conf --daemonize
sudo /usr/local/flare/bin/flared -f /etc/flare/flareid_slave.conf --daemonize
sudo /usr/local/flare/bin/flared -f /etc/flare/flared_proxy.conf --daemonize

起動が終わったらインデックスサーバーへ接続し、node roleコマンドで以下の状態に設定します。

stats nodes
STAT localhost:11211:role master
STAT localhost:11211:state active
STAT localhost:11211:partition 0
STAT localhost:11211:balance 1
STAT localhost:11211:thread_type 16
STAT localhost:11212:role slave
STAT localhost:11212:state active
STAT localhost:11212:partition 0
STAT localhost:11212:balance 2
STAT localhost:11212:thread_type 17
STAT localhost:11213:role proxy
STAT localhost:11213:state active
STAT localhost:11213:partition -1
STAT localhost:11213:balance 0
STAT localhost:11213:thread_type 18

通常運用では、クライアントはproxyサーバーへ接続します。その後proxyサーバーが、get時にはmaster:slave=1:2の比率（設定で変えられます）で分散してアクセスし、set時にはmasterサーバーへアクセスします。書き込まれたmasterサーバーはslaveサーバーへデータをレプリケートします。
この状態で、masterサーバーを落としてみます。

マスターダウンからスレーブの昇格

killコマンドでmasterサーバーを落とすと、インデックスサーバーがダウンを検知し、slaveサーバーを昇格させます。
状態を確認すると、

stats nodes
STAT localhost:11211:role proxy
STAT localhost:11211:state down
STAT localhost:11211:partition -1
STAT localhost:11211:balance 0
STAT localhost:11211:thread_type 16
STAT localhost:11212:role master
STAT localhost:11212:state active
STAT localhost:11212:partition 0
STAT localhost:11212:balance 2
STAT localhost:11212:thread_type 17
STAT localhost:11213:role proxy
STAT localhost:11213:state active
STAT localhost:11213:partition -1
STAT localhost:11213:balance 0
STAT localhost:11213:thread_type 18
END

元masterサーバがダウンしてproxyサーバーに、元slaveサーバーがmasterサーバーに昇格しています。
無事成功しました。

昇格時のログ

ログを確認すると、挙動がよく理解できます。

インデックスサーバーのログ

/var/log/flarei.log

Sep  1 13:55:20 flare-test flarei[10772]: [1152215360][WRN][connection.cc:448-write] connection seems to be already closed (sock=-1)
Sep  1 13:55:21 flare-test flarei[10772]: [1152215360][WRN][connection.cc:122-open] connect() failed: Connection refused (111) -> wait for 500000 usec
Sep  1 13:55:24 flare-test last message repeated 7 times
Sep  1 13:55:25 flare-test flarei[10772]: [1152215360][ERR][connection.cc:129-open] connect() failed
Sep  1 13:55:26 flare-test flarei[10772]: [1152215360][WRN][connection.cc:122-open] connect() failed: Connection refused (111) -> wait for 500000 usec
Sep  1 13:55:29 flare-test last message repeated 7 times
Sep  1 13:55:30 flare-test flarei[10772]: [1152215360][ERR][connection.cc:129-open] connect() failed
Sep  1 13:55:30 flare-test flarei[10772]: [1152215360][NTC][cluster.cc:338-down_node] handling node down event [node_key=localhost:11211]
Sep  1 13:55:30 flare-test flarei[10772]: [1152215360][ERR][cluster.cc:357-down_node] master node down -> finding an active slave and shift its role to master
Sep  1 13:55:30 flare-test flarei[10772]: [1152215360][NTC][cluster.cc:380-down_node] found new master node (node_key=localhost:11212, partition=0, balance=2)
Sep  1 13:55:30 flare-test flarei[10772]: [1152215360][NTC][cluster.cc:396-down_node] setting node state to down (and clearing role, etc)
Sep  1 13:55:30 flare-test flarei[10772]: [1152215360][NTC][cluster.cc:1308-_reconstruct_node_partition] reconstructing node partition map... (from 3 entries in node map)
Sep  1 13:55:30 flare-test flarei[10772]: [1152215360][NTC][cluster.cc:1416-_reconstruct_node_partition] node partition map:
Sep  1 13:55:30 flare-test flarei[10772]: [1152215360][NTC][cluster.cc:1421-_reconstruct_node_partition] 0: master (node_key=localhost:11212, node_balance=2)
Sep  1 13:55:30 flare-test flarei[10772]: [1152215360][NTC][cluster.cc:1435-_reconstruct_node_partition] node partition map (prepare):
Sep  1 13:55:31 flare-test flarei[10772]: [1152215360][WRN][connection.cc:122-open] connect() failed: Connection refused (111) -> wait for 500000 usec
Sep  1 13:55:34 flare-test last message repeated 7 times

インデックスサーバーは設定ファイルのmonitor-intervalの秒数ごとに各ノードへ死活チェックを行っています。
今回は1（秒）に設定しているので、マスターがダウンしてから最長1秒でダウンを検知します。
検知した後monitor-thresholdの回数分（3回）、死活チェックをリトライします。リトライの間は0.5秒のインターバルがあり、最後の死活チェックが終わると、ノードのダウンを決定し、新しいマスターを探します。
新しいマスター候補が見つかると昇格させ、晴れてマスターになります。

ログでは10秒で昇格を果たしていますが、環境やデータ量によって変わる可能性はありそうです。

スレーブサーバーのログ

/var/log/flared_slave.log

Sep  1 13:55:30 flare-test flared[11476]: [1036380480][NTC][cluster.cc:759-reconstruct_node] reconstructing node map... (3 entries)
Sep  1 13:55:30 flare-test flared[11476]: [1036380480][NTC][cluster.cc:785-reconstruct_node] update: node_balance (1 -> 0)
Sep  1 13:55:30 flare-test flared[11476]: [1036380480][NTC][cluster.cc:1308-_reconstruct_node_partition] reconstructing node partition map... (from 3 entries in node map)
Sep  1 13:55:30 flare-test flared[11476]: [1036380480][NTC][cluster.cc:1416-_reconstruct_node_partition] node partition map:
Sep  1 13:55:30 flare-test flared[11476]: [1036380480][NTC][cluster.cc:1421-_reconstruct_node_partition] 0: master (node_key=localhost:11212, node_balance=2)
Sep  1 13:55:30 flare-test flared[11476]: [1036380480][NTC][cluster.cc:1435-_reconstruct_node_partition] node partition map (prepare):
Sep  1 13:55:30 flare-test flared[11476]: [1036380480][NTC][cluster.cc:1061-_shift_node_state] shifting node_state (node_key=localhost:11211, old_state=0, new_state=2)
Sep  1 13:55:30 flare-test flared[11476]: [1036380480][NTC][cluster.cc:1078-_shift_node_role] shifting node_role (node_key=localhost:11212, old_role=1, old_partition=0, new_role=0, new_partition=0)
Sep  1 13:55:30 flare-test flared[11476]: [1036380480][NTC][cluster.cc:1078-_shift_node_role] shifting node_role (node_key=localhost:11211, old_role=0, old_partition=0, new_role=2, new_partition=-1)

こちらにもインデックスサーバーの指令を受けて、マスターになるログが残っていました。

クライアントへの影響

マスターをダウンさせた時に接続中だったクライアントがどうなるのかを調べてみました。

set

以下は”key_” + 1〜100万をキーに20バイトの文字列をsetするプログラムで、keyの後ろの数字は処理時間を表しています。

set key_500261:0
set key_500262:0
set key_500263:0
set key_500264:0
set key_500265:16.000910997391
set key_500266:0
set key_500267:0
set key_500268:0

5行目の処理時にマスターがダウンし処理が止まりますが、マスター昇格後、無事書き込みが完了しています。
時間はかかるものの、書き込みは失敗しませんでした。

get

以下は上のプログラムでsetした値をgetするプログラムで、key:value:処理時間を表しています。

get key_245:01234567890123456789:0
get key_246:01234567890123456789:0
get key_247:01234567890123456789:0
get key_248:01234567890123456789:0
get key_249:01234567890123456789:0
get key_250::31.737808942795
get key_251:01234567890123456789:0
get key_252:01234567890123456789:0
get key_253:01234567890123456789:0
get key_254:01234567890123456789:0
get key_255:01234567890123456789:0

6行目の処理時にマスターがダウンし処理が止まり、そのままデータが取得できず、タイムアウトしてしまいました。
スレーブの台数が多ければ止まらなかったかもしれませんが、この構成では5回中5回、全て同じ結果でした。テスト不足ではありますが、getの処理は失敗することがありそうです。