先週金曜日（12/2）にクックパッドインフラ勉強会に参加しまして、そこで同社の成田さんから「今日からできるApacheモジュール開発と運用」という発表がありました。
リアルタイム画像変換モジュールの「TOFU」を開発するに至った経緯と、Apacheモジュール開発についてのお話でした。

TOFUは、S3に置かれたマスターとなる画像ファイルを取得し、与えられたパラメータでリアルタイム（オンザフライ）にリサイズ・トリミングを行うモジュール（mod_tofu）です。

• 料理を楽しくする画像配信システム

実際は、モジュールによる画像取得・変換をベースに、キャッシュや配信までも含めた一連の画像配信システムと言えそうです。

この仕組みをNginxを使って実装できないかと考えて、リアルタイム変換の仕組みをNginxだけで実現する方法を実験してみました。

準備するもの

HttpImageFilterModule

このモジュールはパッケージに同梱されているオプションモジュールの一つで、JPEG、GIF、PNGを変換するフィルターを提供します。
有効にするには、ビルド時にパラメータを指定する必要があります。

./configure --with-http_image_filter_module

ビルドし直したnginxの入れ替えを行う場合は、こちらを参考にしてください。

• リクエストを落とさずにnginxをアップグレードする方法とその検証

また、ビルドにはlibgdが必要なのでGDライブラリを別途インストールしておく必要があります。

最も簡単な例

/imagesディレクトリにあるjpgファイルを全て150*150のサムネイルに変換したい場合は、以下の設定を書くだけです。

location ~ /images/.*\.jpg$ {
   image_filter  crop  150  150;
}

このままだと元サイズのファイルにアクセスできなかったり、エラー制御がしにくいのですが、このモジュールがいかに簡単に使えるかがわかると思います。

ローカルファイルで実験

前述の最も簡単な例を発展させて、外部からのパラメータに従って、まずはローカルディスクにある画像に対してリアルタイム変換をしてみます。

対象とするファイル

• momiji.jpg
• JPEGファイル
• 1024×683 ピクセル
• 274,661 バイト

外部からのパラメータ

• width（幅）
• height（高さ）
• type（リサイズの方法）
  • resize（縦横比を変えずにサイズ変換）
  • crop（サイズ変換後に指定されたサイズに切り取る）
• quality（JPEGの画質≒圧縮率）

要件

/imagesディレクトリにあるJPEGファイル（*.jpg）にパラメータを付けてアクセスをした時、パラメータに従って変換された画像を返す。

結果

以下のように、パラメータを変えるだけで欲しい画像サイズに変換されます。

/images/momiji.jpg?width=150&height=150&type=resize

/images/momiji.jpg?width=200&height=200&type=crop

/images/momiji.jpg?width=400&height=100&type=crop&quality=5

こちらのリンク先でパラメータをいろいろ変更してテストができます。お試し下さい。
http://nginx.labs.cloudrop.jp/images/momiji.jpg?width=150&height=150

設定方法

1. /images でパラメータの有無をチェックします。なければ通常の画像を返すようにしています。（何もしない）
2. パラメータがあれば /image_filter へリライトされ、パラメータから変数に代入し、$arg_typeを元に /resize か /corp へリライトします。
3. /reize /crop でそれぞれ処理をし、変換された画像が返されます。

※ ImageFilterが処理できない場合は415エラーが発生するので、それを1*1pxの透過GIFに置き換えています。

設定ファイル

location ~ /images/.*\.jpg$ {
    if ($query_string ~ .*=.*) {
      rewrite ^/images/(.*\.jpg)$ /image_filter/$1 last;
    }
}

location ~ ^/image_filter/(.*\.jpg)$ {
    internal;

    set $file $1;
    set $width 150;
    set $height 150;
    set $quality 75;

    if ($arg_width ~ (\d*)) {
        set $width $1;
    }
    if ($arg_height ~ (\d*)) {
        set $height $1;
    }
    if ($arg_quality ~ (100|[1-9][0-9]|[1-9])) {
        set $quality $1;
    }

    if ($arg_type = "resize") {
        rewrite ^ /resize last;
    }
  
    rewrite ^ /crop last;
}

location /resize {
    internal;
    rewrite ^ /images/$file break;
    image_filter  resize  $width $height;
    image_filter_jpeg_quality $quality;
    error_page 415 = @empty;
}

location /crop {
    internal;
    rewrite ^ /images/$file break;
    image_filter  crop  $width $height;
    image_filter_jpeg_quality $quality;
    error_page 415 = @empty;
}

location @empty {
    empty_gif;
}

パフォーマンス

ab（ApacheBench）で100リクエストを並列で一度に送り、1秒あたりのリクエスト処理数を5回測定した平均値。クライアントとサーバーは別でインターネットを経由して測定。

ローカルでの処理なのでネットワークのボトルネックはありません。一方、キャッシュを利用していないので、リクエストごとに変換処理が動くことになります。
無変換を基準に考えると、サイズが大きめの画像へのリサイズは時間がかかりますが、小さくなるに従って無変換よりもパフォーマンスが上がります。
変換に処理時間がかかるものの、Webで利用するサムネイル程度のサイズにすれば十分実用的な速度だと思います。

S3経由で実験

今度はTOFUの仕様に近づくべく、S3（リモートサーバー）にあるファイルを取得するようにします。
実験のサーバーは「さくらのVPS512」でS3は「USスタンダードリージョン」です。ネットワークのレイテンシは150ms程です。

対象とするファイル

• sanzaru.jpg
• US Standard リージョン
• JPEGファイル
• 1024×683 ピクセル
• 194,728 バイト

外部からのパラメータ（ローカルと同じ）

• width（幅）
• height（高さ）
• type（リサイズの方法）
  • resize（縦横比を変えずにサイズ変換）
  • crop（サイズ変換後に指定されたサイズに切り取る）
• quality（JPEGの画質≒圧縮率）

要件

JPEGファイル（*.jpg）にパラメータを付けてアクセスをした時、S3上にある同名ファイルを取得し、パラメータに従って変換された画像を返す。
変換した画像はキャシュし、2回目以降はキャッシュを利用する。

結果

/s3images/sanzaru.jpg?width=150&height=150&type=resize

/s3images/sanzaru.jpg?width=200&height=200&type=crop

/s3images/sanzaru.jpg?width=400&height=100&type=crop&quality=5

こちらのリンク先でパラメータをいろいろ変更してテストができます。お試し下さい。
http://nginx.labs.cloudrop.jp/s3images/sanzaru.jpg?width=200&height=200&type=crop

設定方法

1. 80番ポートで待ち受ける/s3images で8080番ポートで動くバックエンドの/s3images へリクエストをそのまま渡します。
2. 8080番ポートの/s3imagesでパラメータから変数に代入し、$arg_typeを元に/s3_resize か/s3_corp へ、パラメータがなければ/s3_original へリライトします。
   
3. /s3_resize /s3_crop /s3_originalでそれぞれS3からファイルを取得・変換処理をし、画像を80番ポートのフロントエンドへ返します。
4. 80番ポートのフロントエンドはバックエンドから返ってきたレスポンスをキャッシュし、画像を返します。以降、すでにキャッシュ済みリクエストだった場合は、バックエンドへ送らず、キャッシュを返します。

設定ファイル

server {
    listen 80;
    server_name localhost;
    root /var/www/html;

    location /s3images {
        proxy_pass http://localhost:8080;
        proxy_cache s3cache;
        proxy_cache_key $scheme$host$uri$arg_width$arg_height$arg_type$arg_quality;
        proxy_cache_valid  200 60m;
    }
}

server {
    listen 8080;
    server_name localhost;
    root /var/www/html;

    access_log logs/proxy_access.log;
    access_log logs/error_access.log;

    resolver 8.8.8.8;

    location ~ /s3images/(.*\.jpg)$ {

        set $s3host MY_S3_HOST;
        set $file $1;
        set $width 150;
        set $height 150;
        set $quality 75;

        if ($query_string !~ .*=.*) {
          rewrite ^ /s3_original last;
        }

        if ($arg_width ~ (\d*)) {
            set $width $1;
        }
        if ($arg_height ~ (\d*)) {
            set $height $1;
        }
        if ($arg_quality ~ (100|[1-9][0-9]|[1-9])) {
            set $quality $1;
        }

        if ($arg_type = "resize") {
            rewrite ^ /s3_resize last;
        }

        rewrite ^ /s3_crop last;
    }

    location /s3_original {
        internal;
        proxy_pass http://$s3host/$file;
    }

    location /s3_resize {
        internal;
        proxy_pass http://$s3host/$file;
        image_filter  resize  $width  $height;
        image_filter_jpeg_quality  $quality;
        error_page 415 = @empty;
    }

    location /s3_crop {
        internal;
        proxy_pass http://$s3host/$file;
        image_filter  crop  $width  $height;
        image_filter_jpeg_quality  $quality;
        error_page 415 = @empty;
    }

    location @empty {
        empty_gif;
    }
}

8080ポート側にresolverの設定が入っています。NginxはOS標準の名前解決方法を利用してくれないため、ネームサーバーをresolverに設定する必要があります。
ここではGoogle Public DNSが設定されていますが、利用するサーバーの最寄り（通常同じDC内）のネームサーバーを指定します。

パフォーマンス

ab（ApacheBench）で100リクエストを並列で一度に送り、1秒あたりのリクエスト処理数を5回測定した平均値。クライアントとサーバーは別でインターネットを経由して測定。

S3からファイルを取得する処理を含めると、ネットワークのボトルネックがあり、1リクエスト2秒程度かかります。それを含めてしまうと、ネットワークに引きずられて正確な値がでないので、キャッシュに対して測定しています。

キャッシュからの応答になるので、純粋にファイルサイズの大きさに比例していきます。マスターの画像が変更されないことがわかっている場合、もしくは、変更があった場合にハッシュ値などを使ってキャッシュを書き換えるなどすると、実用的な速度で利用できることがわかります。

まとめ

細かい設定（例えば、左上から右へ10px下へ20pxを起点に切り取るなど）はできませんし、pngからjpgなどのフォーマット変換もできないので、多くの機能を望む場合は、他のプログラムを利用するか、Nginxモジュールを書く事になると思います。

とは言っても、モジュールをインストールして、設定を書くだけで利用できるので、プロトタイプ開発の用途には使えますし、リモートサーバーのファイル自体をキャッシュしたり、Proxy Cacheを適切に設定したり、多段にキャッシュを用意したりすれば、用途に限りがありますが、プロダクションでも使えると思います。

Nginxモジュール開発の参考

• NginxでのModuleの作り方 – よねのはてな
• Rails アプリを nginx の拡張モジュールで置き換えて高速化する方法 – HeartRails Tech Blog
• Emiller’s Guide to Nginx Module Development

[root@sakura ~]# ping google.com
ping: unknown host google.com

（コントロールパネルのコンソールから実行）

普通に外部（インターネット）と通信ができません。

AWS EC2やRackspace Cloudではテンプレートから新しくインスタンスを立ち上げた場合は、ネットワーク設定周りを自動的に調整してくれて、起動直後からインターネットにつながります。
逆に言うと、さくらのクラウドは純粋な仮想サーバーと考えると扱いやすくなります。

これは、クラウドのシステムから仮想サーバーに割り振られたグローバルIPアドレスと起動したサーバーのネットワークの設定がずれているのが原因です。

対処法手順

まずは、コントロールパネル ＞ サーバー ＞ 詳細情報で、割り振られているIPアドレスなどネットワークアドレス情報、Macアドレスを確認して、OSのネットワーク設定を変更します。

（クリックで拡大）

以下の例は、RedHat系Linuxの場合で、割り振られたIPv4アドレスが「133.242.xxx.xxx」、ゲートウェイが「133.242.xxx.1」、eth0のMacアドレスが「9c:a3:ba:xx:xx:xx」だったとします。

NICの設定ファイル

ネットワークインターフェースの設定を書き換えます。

[root@sakura ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0 

× NG

DEVICE=eth0
BOOTPROTO=none
HWADDR=9c:a3:ba:yy:yy:yy
NM_CONTROLLED=yes
ONBOOT=yes
TYPE=Ethernet
NETMASK=255.255.255.0
BROADCAST=133.242.yyy.255
IPADDR=133.242.yyy.zzz
NETWORK=133.242.yyy.0
GATEWAY=133.242.yyy.1
IPV6INIT=no
USERCTL=no

◯ OK

DEVICE=eth0
BOOTPROTO=none
HWADDR=9c:a3:ba:xx:xx:xx
NM_CONTROLLED=yes
ONBOOT=yes
TYPE=Ethernet
NETMASK=255.255.255.0
BROADCAST=133.242.xxx.255
IPADDR=133.242.xxx.xxx
NETWORK=133.242.xxx.0
GATEWAY=133.242.xxx.1
IPV6INIT=no
USERCTL=no

udevルールファイル

Macアドレスも変更されている（OS的にはハードウェアが新しくなったと認識している）ので、udevルールファイルも書き換える必要があります。

[root@sakura ~]# vi /etc/udev/rules.d/70-persistent-net.rules 

× NG

# PCI device 0x8086:0x100e (e1000) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="9c:a3:ba:zz:zz:zz", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x100e (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="9c:a3:ba:yy:yy:yy", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

# PCI device 0x8086:0x100e (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="9c:a3:ba:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"

◯ OK

[root@sakura ~]# vi /etc/udev/rules.d/70-persistent-net.rules 
# PCI device 0x8086:0x100e (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="9c:a3:ba:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

再起動

システムを再起動します。

[root@sakura ~]$ reboot

確認

通信が成功します。

[root@sakura ~]$ ping google.com -c 4
PING google.com (72.14.203.104) 56(84) bytes of data.
64 bytes from tx-in-f104.1e100.net (72.14.203.104): icmp_seq=1 ttl=54 time=51.0 ms
64 bytes from tx-in-f104.1e100.net (72.14.203.104): icmp_seq=2 ttl=54 time=51.3 ms
64 bytes from tx-in-f104.1e100.net (72.14.203.104): icmp_seq=3 ttl=54 time=51.3 ms
64 bytes from tx-in-f104.1e100.net (72.14.203.104): icmp_seq=4 ttl=54 time=50.6 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3052ms
rtt min/avg/max/mdev = 50.669/51.102/51.339/0.270 ms

余談

9C-A3-BAのOUIはさくらインターネットのなんですね。

Twitter / 大久保　修一: MACアドレスを取得しました。 9C-A3-BA / SAKURA Internet Inc.

yubitter
yubitter.com
yubitterは見やすさ、つぶやきやすさを重視した携帯電話、PHSでTwitterを利用するためのサービスです。docomo, au, SoftBank, WILLCOM の端末に対応しています。

今回はそこからもう一歩進めたチューニングについて書きたいと思います。

二段階層を廃したシンプルな構成

まずは、図をご覧ください。

前述の王道チューニングの構成はA図となります。

proxy cacheはNginxがバックエンドのサーバーに処理を回し、返ってきたレスポンスをキャッシュして、Nginx自身がキャッシュを返すことでパフォーマンスを上げる仕組みです。
A図-1がキャッシュの無いアクセス、A図-2がキャッシュが効いているアクセスを表しています。
A図-3は静的なファイル（css, js, jpgなど）をフロントのNginxが直接返すことを表しています。

fastcgi cache（HttpFcgiModule）

proxy cache自体はバックエンドのサーバーがHTTPでコンテンツを返してくれれば、どんなアプリケーションでも問わない汎用的なキャッシュ機能です。つまり、proxy cacheを利用しようとするともうひとつHTTPサーバーが必要になり、A図のようにHTTPのレイヤーが二段構成になります。

Nginxにはproxy cacheと似た機能でfastcgi cacheという機能（HttpFcgiModule）があります。これはバックエンドのFastCGIのレスポンスをキャッシュする機能です。
これを利用すると、proxy cacheを利用したのと同じ効果をHTTPサーバーなしに実現できます。
A図の8080ポートのサーバーが必要なくなり、B図の構成になります。
無駄な通信と処理がなくなり、シンプルです。

WP Super Cacheを最大限利用する

WP Super Cacheは、アクセスごとに動的に生成される記事を、静的なHTMLファイルとして保存（キャッシュ）して、それを返すように振舞うプラグインです。
キャッシュが効いている間はMySQLにアクセスすることが無いのでパフォーマンスが上がります。

.htacessの落とし穴

WP Super Cacheを利用すると、.htaccessに以下の設定が追加されます。
(利用しているプラグインによって多少変わります)

# BEGIN WPSuperCache

RewriteEngine On
RewriteBase /
AddDefaultCharset UTF-8
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800).* [NC]
RewriteCond %{HTTP_user_agent} !^(w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-).* [NC]
RewriteCond %{HTTP_USER_AGENT} !^(DoCoMo/|J-PHONE/|J-EMULATOR/|Vodafone/|MOT(EMULATOR)?-|SoftBank/|[VS]emulator/|KDDI-|UP\.Browser/|emobile/|Huawei/|IAC/|Nokia|mixi-mobile-converter/)
RewriteCond %{HTTP_USER_AGENT} !(DDIPOCKET;|WILLCOM;|Opera\ Mini|Opera\ Mobi|PalmOS|Windows\ CE;|PDA;\ SL-|PlayStation\ Portable;|SONY/COM|Nitro|Nintendo)
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz" [L]

RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800).* [NC]
RewriteCond %{HTTP_user_agent} !^(w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-).* [NC]
RewriteCond %{HTTP_USER_AGENT} !^(DoCoMo/|J-PHONE/|J-EMULATOR/|Vodafone/|MOT(EMULATOR)?-|SoftBank/|[VS]emulator/|KDDI-|UP\.Browser/|emobile/|Huawei/|IAC/|Nokia|mixi-mobile-converter/)
RewriteCond %{HTTP_USER_AGENT} !(DDIPOCKET;|WILLCOM;|Opera\ Mini|Opera\ Mobi|PalmOS|Windows\ CE;|PDA;\ SL-|PlayStation\ Portable;|SONY/COM|Nitro|Nintendo)
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html" [L]


# END WPSuperCache

これは、すでにWP Super Cacheによって静的なファイルが生成されている場合、PHPを介さずにApacheが直接リクエストを返すようにする設定です。
WP Super Cacheの推奨設定では、index.htmlとそれを圧縮したindex.html.gzが用意されるので、冗長な設定になっています。

Nginxにとって.htaccessはただのテキストファイルですから、上記RewriteRuleをNginxの設定ファイルに移植しないと、WP Super Cacheは本来のパフォーマンスを発揮しません。
この移植をすることで、B図-4のように、fastcgi cacheに到達することもなく、静的ファイルと同じ処理、パフォーマンスになります。

HttpGzipStaticModule

NginxのHttpGzipStaticModuleは、同じディレクトリ内にあらかじめ圧縮ファイル（.gz）が用意されている場合に、クライアント判定を行なって自動的に圧縮ファイルを返してくれるモジュールです。（正確には、Gzip圧縮に対応しているクライアントからリクエストが来て、同ディレクトリに同タイムスタンプで同名+.gzという名前のファイルがある場合）

このモジュールを導入するメリットは、gzファイル分の.htaccessを移植する手間がなくなることです。ただし、コアモジュールではないので、コンパイル時にオプションで指定する必要があります。

./configure --with-http_gzip_static_module

コンパイルし直したnginxの入れ替えを行う場合は、こちらを参考にしてください。

• リクエストを落とさずにnginxをアップグレードする方法とその検証

NginxにはコアモジュールでHttpGzipModuleがあり、設定をオンにすることで特定のContent-TypeにGzip圧縮をかけてレスポンスを返すことができます。こちらはリクエストごとにオンザフライで圧縮をかけるので、余分に処理がかかります。あらかじめcssやjsなどの圧縮ファイルが用意できる場合は、同階層に設置してHttpGzipStaticModuleの恩恵を受けたほうがいいと思います。

サンプル設定ファイル

前述の項目を網羅して、かつ可能な限り正常に動いている環境の設定ファイルを載せています。

nginx.conf

user  nginx nginx;
worker_processes  2; # サーバーのコア数に合わせて

pid  /var/run/nginx.pid;

events {
    worker_connections  1024;
    use epoll;　# Linuxの場合
}

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

    # 最後の$request_timeは処理時間(ms)
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" $request_time';

    sendfile        on;
    tcp_nopush     on;
    tcp_nodelay on;

    keepalive_timeout  10;

    connection_pool_size 256;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 2k;
    request_pool_size 4k;
    if_modified_since before;
    ignore_invalid_headers on;
    server_tokens off;

    gzip  on;
    gzip_min_length 0;
    gzip_buffers 4 8k;
    gzip_types text/plain text/xml application/x-javascript text/css;
    gzip_disable "msie6";
    gzip_vary on;
    # HttpStaticGzipModuleをオンに
    gzip_static on;

    output_buffers 1 32k;
    postpone_output 1460;

    # fastcgi cacheの設定（httpディレクティブ内のみ有効）
    fastcgi_cache_path      /usr/local/nginx/cache levels=1:2 keys_zone=wpcache:10m max_size=50M inactive=30m;

    server {
        listen       80;
        server_name  localhost;
        charset utf-8;

        location / {
            return 403;
        }

        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 ./wordpress.conf;
}

wordpress.conf

# 設定を変えやすいようにupstreamにまとめておく
upstream phpfpm {
    # ローカルの場合はUNIXソケットで
    server unix:/var/run/php-fpm/www.sock;
}

server {
    listen       80;
    server_name  example.com;
    root /var/www/wordpress;
    access_log logs/access.log main;

    location / {
        # 静的なファイルの場合は処理をとめる
        # リクエストの度にファイルの存在をチェックするのは無駄だという意見もありますが、
        # どのURLの時index.phpに渡すのか、プラグインを含めて全仕様が分からないため、
        # これが最も安全だと思います。
        if (-f $request_filename) {
            break;
        }

        # ここからWP Super Cacheの設定（少しfastcgi cacheの設定も）
        # モバイルからのアクセスはキャッシュさせないようにする変数
        set $nocache "";
        set $supercache_file $document_root/wp-content/cache/supercache/${http_host}${uri}/index.html;
        set $supercache_uri "";
        if (-f $supercache_file) {
            set $supercache_uri /wp-content/cache/supercache/${http_host}${uri}/index.html;
        }

        if ($request_method = "POST") {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($query_string ~ .*=.*) {
            set $supercache_uri "";
        }

        if ($http_cookie ~ ^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$) {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($http_x_wap_profile ~ ^[a-z0-9\"]+) {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($http_profile ~ ^[a-z0-9\"]+) {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($http_user_agent ~ ^.*(2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800).*) {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($http_user_agent ~ ^(w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-).*) {
            set $supercache_uri "";        
            set $nocache "1";
        }

        if ($http_user_agent ~ ^(DoCoMo/|J-PHONE/|J-EMULATOR/|Vodafone/|MOT(EMULATOR)?-|SoftBank/|[VS]emulator/|KDDI-|UP\.Browser/|emobile/|Huawei/|IAC/|Nokia|mixi-mobile-converter/)) {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($http_user_agent ~ (DDIPOCKET\;|WILLCOM\;|Opera\ Mini|Opera\ Mobi|PalmOS|Windows\ CE\;|PDA\;\ SL-|PlayStation\ Portable\;|SONY/COM|Nitro|Nintendo)) {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($supercache_uri) {
            rewrite ^ $supercache_uri last;
            break;
        }

        rewrite ^ /index.php last;
    }

    location ~ \.php {
        # 存在しないPHPファイルをシャットアウト
        if (!-f $request_filename) {
            return 404;
            break;
        }

        # fastcgi とfastcgi cacheの設定
        include ./fastcgi.conf;
        fastcgi_pass          phpfpm;
        fastcgi_cache         wpcache;
        fastcgi_cache_key     "$scheme://$host$request_uri";
        fastcgi_cache_valid   200 10m;
        fastcgi_cache_valid   404 1m;
        # $nocache = "1"の時、fastcgi cacheが無効になる
        fastcgi_cache_bypass  $nocache;
    }

    # よくアクセスされる静的ファイルにブラウザキャッシュが効くように設定
    location ~ \.(jpg|png|gif|swf|jpeg)$ {
        log_not_found off; # 404の時にerror_logに書き込まないようにする設定
        access_log off;
        expires 3d;
    }

    location ~ \.ico$ {
        log_not_found off;
        access_log off;
        expires max;
    }

    location ~ \.(css|js)$ {
        charset  UTF-8;
        access_log off;
        expires 1d;
    }

    # ドット始まりのファイルはアクセスできないように
    location ~ /\. {
        deny all;
        log_not_found off;
        access_log off;
    }

    # リライトされたWP Super Cacheのファイル
    location ~ /wp-content/cache/supercache/${http_host}${uri}/index\.html(\.gz)?$ {
        charset  UTF-8;
        internal; # この指定をしておくとURLを指定して直接アクセスできなくなる
    }

    location ~ /wp-admin/$ {
        rewrite ^/wp-admin/$ /wp-admin/index.php last;
    }
}

処理の解説

Nginxのlocationディレクティブの評価順番は、wordpress.confを例にとると、すべてのアクセスが最初に “location /”ディレクティブを通ります。（記述順番は関係ありません。）

静的ファイルのチェック

このディレクティブの先頭でリクエストされた静的ファイルが存在するかのチェックを行なっています。
静的ファイルとして存在した場合、breakで”location /”ディレクティブの処理が終わります。次に、マッチするlocationディレクティブがあればそちらが実行されます。
例えば、cssファイルだった場合は、”location ~ \.(css|js)$”ディレクティブへ処理が続いていきます。これがB図-3の流れです。

WP Super Cacheのチェック、fastcti cacheのチェック

静的ファイルとして存在しなかった場合、処理は下へ進みます。
次の処理ではWP Super Cacheが生成したキャッシュファイルの存在をチェックし、キャッシュファイルを利用するかどうかを下に続く条件で確認していきます。各条件では同時にfastcgi cacheを利用するかどうかのチェックも行なっています。

ここでは、$supercache_uriが”"（空文字）に書き換えられると、WP Super Cacheの静的キャッシュファイルが使われず（下の判定で利用されます）、$nocacheが”1″に書き換えられると、fastcgi cacheが使われません（ ~ \.phpディレクティブで利用されます）。

$supercache_fileが存在し、$supercache_uriが空でない場合は、”location ~ /wp-content/cache/supercache/${http_host}${uri}/index\.html(\.gz)?$”ディレクティブへ処理が続きます。これがB図-4の流れです。

全てを受け止めるindex.php

静的ファイルのチェック、WP Super Cacheのチェックが終わっても処理が続く場合は、すべてにリクエストがindex.phpへと渡され、”location ~ \.php”ディレクティブへ処理が続きます。
すでにキャッシュされていて期限が有効な場合は、fastcgi cacheが使われ（B図-2）、キャッシュがなかったり、期限が切れていた場合は、FastCGI（PHP）へ処理が渡されます（B図-1）。

今回はステータスコード200の時は10分、404の時は1分キャッシュするように設定してあります。

404がキャッシュされない

目に見える記事部分のキャッシュが効いて応答が良くなると忘れてしまいがちですが、WordPressが返す404 Not Foundは無視できないくらい重い処理です。
404に対してキャッシュが作られないと、存在しない記事にアクセスがくる度にPHPとMySQLが仕事をしてしまいます。

そこで、fastcgi cacheの設定で “fastcgi_cache_valid 404 1m;” を指定しているわけですが、そのままだとキャッシュが効ききません（WordPress 3.2.1）。
調べてみると、WordPressは404の時、ヘッダーに “Cache-Control:no-cache, must-revalidate, max-age=0″ を付けてレスポンスを返すことがわかりました。
このヘッダーがあるのでfastcgi cacheはキャッシュを作らないようなのです。

もっとスマートな方法があると思いますが、今回はWordPressのソースを少しいじって対応することにしました。

wp-includes/class-wp.php

function handle_404() {
    global $wp_query;

    if ( !is_admin() && ( 0 == count( $wp_query->posts ) ) && !is_404() && !is_robots() && !is_search() && !is_home() ) {
        // Don't 404 for these queries if they matched an object.
        if ( ( is_tag() || is_category() || is_tax() || is_author() || is_post_type_archive() ) && $wp_query->get_queried_object() && !is_paged() ) {
            if ( !is_404() )
                status_header( 200 );
            return;
        }
        $wp_query->set_404();
        status_header( 404 );
        //nocache_headers(); # ここをコメントアウト
    } elseif ( !is_404() ) {
        status_header( 200 );
    }
}

これで404もキャッシュされるようになりました。

おわりに

弊社はWordPessのイベント、WordCamp 2011 Tokyoに微力ながらスポンサーとして協力させて頂きました。

ブログにもWordPressの記事が少なく、弊社がWordPressにコミットしている感じが伝わっていないと思ったので、開催前に何とか間に合って良かったです。

参考サイト

• ハイパフォーマンス WordPress サイト入門
• Nginx – WordPress Codex 日本語版
• WordPress › Support » nginx + php-fpm + PHP APC + WordPress multisite (subdirectory) + WP Super Cache

さくらのクラウドの料金が発表になり、相対的に他のクラウドサービスより安いと言われています。ところが、実際にAWSなどから置き換えるような用途を考えた場合に、今までの感覚でプランを選ぼうとすると、本当に安いのか疑問になる部分が出てきたので、シミュレーションをしながら考えてみました。

バランスが悪い？CPUがネック？

アプリケーションサーバーの用途などCPUパワーが必要なケースを考えます。
例えば、4コアは欲しいけどメモリは少なくてもいい場合、4コアの最低プランであるプラン7（メモリ16GB）を選択しないといけなくなります。これはAWSでいうCPUに重みを置いたc1.mediumインスタンスのようなプランがないためで、バランスが悪くオーバースペックになってしまいますし、価格も高めになります。

しかし、パフォーマンスは使われているサーバーのスペックやリソース配分が影響を与えるので、元々の能力が違う上でコア数の多寡だけを取り上げても判断材料にはなりません。

実際多くの方が、先行サービスのさくらのVPSとAWS（EC2）のベンチマークを行なっていて、結果は概ねさくらのVPSが優れているというものです。

• unixbench on AWS micro instance & さくらのVPS – Never forget your first resolution.
• 格安の低価格ＶＰＳを比較する – さくらインターネット創業日記
• Amazon EC2性能検証！気になるパフォーマンスをインスタンスタイプやリージョン毎に計測・比較してみた – RX-7乗りの適当な日々

また、EC2で定義されているECUというCPUの単位は、以下のようなものです。

特定のインスタンスに配分されている CPU 量は、これらの EC2 Compute Unit で明示されます。当社はいくつかのベンチマークとテストを使用して、EC2 Compute Unit のパフォーマンスの安定性と予測可能性を管理します。1つの EC2 Compute Unit は、1つの 1.0-1.2 GHz 2007 Opteron または 2007 Xeon プロセッサの CPU 能力に等しい能力を提供します。

引用元 Amazon EC2 インスタンスタイプより

c1.mediumインスタンス（5 ECU（2.5 ECU × 2仮想コア））の場合は2007 Opteronの2.5-3.0GHz × 2仮想コア相当のパフォーマンスだということになります。

この辺りを考慮にいれて、コア数に振り回されないように、実際のアプリケーションでテストを行って最適なプランを選ぶことになりそうです。
現段階では安いとも高いとも言えないところです。

メモリ特化の用途には安い！ではディスクは？

DBサーバーやキャッシュサーバーの用途などメモリが多く必要なケースを考えます。
例えばmemcachedサーバーの用途でメモリが8GBあればCPUもディスク容量も問わないケースだと、プラン5になりAWSのm1.largeインスタンスと比べて半額で済みます。

一方、m1.largeインスタンス並のディスク容量を追加しようとすると、プラン5+750GBで26,150円と高くなります。
これはAWSのディスクが安いとも言えるので、大容量のストレージが必要な場合はさくらのクラウドは安いとは言えないでしょう。

実際、DBサーバーの用途で8GBのメモリを積んだサーバーを運用する場合、850GBものデータを扱うことはパフォーマンスを考えるとありえないので、通常のケースでは問題にならないと思っています。

トラフィック特化の用途では？

大容量コンテンツの配信やストリーミングサービスだけでなく、単純にアクセス数が多いサービスだと転送量に対する課金が全体の半分くらいに達することもあります。
さくらのクラウドは転送量やリクエスト数に応じて従量課金されることがないので、トラフィックに関しては安いと言えます。

スペック・料金シミュレータ

上記を踏まえて、スペックと料金のシミュレータを作って見ました。
利用したいスペックを選択するとマッチする最低ラインのプランが決定されます。
利用したいスペックよりも表記上オーバースペックの場合、該当のスペックが赤くなります。
（※ 料金表記などに誤りがある場合もありますのでご了承の上、ご利用下さい。）

利用したいスペック

選択されたプラン
CPU
メモリ
ディスク
月額料金
日割料金

本日の第4回さくらの夕べで明らかになった情報のメモを整理します。
ほとんどの情報は明日のプレスリリースで公開される情報です。

リリース日

2011年11月15日 15:00に石狩データセンターがオープンし、そのタイミングでリリース予定とのこと。申込みページはこちら[さくらのクラウド] になる予定。

さくらのクラウド プラン別価格表

上記のプランをベースにローカルネットワークで通信をする場合は仮想スイッチ（¥5,250）、ストレージを増やしたい場合は容量に応じて追加料金でディスクを増やす料金体系。転送量は込み込みなので、転送量の多いサービスはAWSなどに比べてさらに料金が圧縮できる。
ベースの料金は1日〜20日までの利用は日割料金、それ以上の利用は月額料金で課金される。

ロケーション

さくらのクラウドのロケーションは新設の石狩データセンターになるので、在庫は潤沢（1,000台でも2,000台でも）。
東京や大阪などのリージョンも要望が多ければ考える予定。
クラウドとVPSや専用サーバーを同一の石狩データセンターで借りれば、レイテンシーが1ms以下で通信できるミクスチャー環境が構築できる。

その他気になったこと

SSD

ストレージとしてSSDやioDriveも選択できるようにする予定とのこと。手軽に利用できるようになれば、I/Oで頭を悩ませなくて済むようになりそう。

オートスケール

オートスケールは実装する予定はないとのこと。
クラウドをコントロールするAPIが用意されるので、サードパーティーが参入できる部分。

nginxは頻繁に保守されていてどんどんバージョンが上がっていく一方で、UbuntuやWindows以外ではソースコードからビルドする方法が一般的だと思います。

nginxのバージョンアップ頻度

• 2011/05/10 1.0.2
• 2011/05/03 1.0.1
• 2011/04/12 1.0.0
• 2011/04/04 0.9.7
• 2011/03/21 0.9.6

nginx CHANGESより

LinuxやBSDの多くのディストリビューションではNginxがパッケージリポジトリに含まれており、通常のソフトウェアインストール手法でインストールする事ができます。(Debianにおけるapt-getや、Gentooにおけるemerge、FreeBSDにおけるports、Fedora の yum、Vine Linux の apt-get など）

たまにこれらのパッケージは古いものであったりすることがあるので気をつけてください。最新の機能やバグ修正版を求めるなら、ソースコードからビルドすることをお勧めします。…
http://wiki.nginx.org/InstallJaより

上記のようにどのディストリビューションでもパッケージは用意されているものの、バージョンが古いことが多いですし、何よりも各機能を追加するモジュールがApache（httpd）と違ってスタティックな方式を採用しているので、用途に合わせてモジュールを追加したい場合は自分でビルドするしかありません。

そうすると、自分でバイナリを上書きしてアップグレードすることになります。
メンテナンス時間を設けてサービスを止めて保守出来る場合はいいですが、積極的に止めることは避けたいサービスの場合、以下の方法でリクエストを止めることなくアップグレードができます。

オン・ザ・フライで新しいバイナリにアップグレードする

今回は、nginx0.7.67を最新版（1.0.2 2011/5/23現在）にアップグレードした時の手順の確認と結果の検証を行いました。

準備

現在稼動しているバージョンのビルドオプションを確認する

-Vオプションで確認することが出来ます。

$ /usr/local/nginx/sbin/nginx -V
nginx version: nginx/0.7.67
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-48)
TLS SNI support disabled
configure arguments: --with-http_stub_status_module --with-http_ssl_module

configure argumentsがオプション部分です。
サードパーティ製のモジュールを入れている場合（–add-module）は、そのモジュールが新しいバージョンのnginxに対応しているか、対応しているモジュールのバージョンがリリースされていないか、確認する必要があります。

最新バージョンをビルドする

先ほど確認したビルドオプションで新しいバージョンをビルドします。

$ wget http://nginx.org/download/nginx-1.0.2.tar.gz
$ tar vfxz nginx-1.0.2.tar.gz 
$ cd nginx-1.0.2

# ここで先のオプションを使う
$ ./configure --with-http_stub_status_module --with-http_ssl_module
$ make

# 成功すると./objs 以下に新しいバイナリが出来上がるので確認
$ ./objs/nginx -V
nginx: nginx version: nginx/1.0.2
nginx: built by gcc 4.1.2 20080704 (Red Hat 4.1.2-50)
nginx: TLS SNI support disabled
nginx: configure arguments: --with-http_stub_status_module --with-http_ssl_module

現行の設定ファイルのままで問題がないか確認する

仕様の変更などで利用できなくなるディレクティブなどがあるかもしれません。現行の設定ファイルでconfig testが通るかチェックします。

$ sudo ./objs/nginx -t -c /usr/local/nginx/conf/nginx.conf
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful

アップグレード

バイナリをコピーする

単純にコピーnginxファイルを上書きするか、make installで上書きします。

$ sudo cp objs/nginx /usr/local/nginx/sbin/nginx

or

$ sudo make install

プロセスを確認する

いよいよ本題です。現在動いているnginxのマスタープロセスのpidを確認します。

psコマンド確認する方法

$ ps aux |grep nginx
root      5559  0.0  0.0  40976  1000 ?        Ss   16:36   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
nginx     5560  0.0  0.2  42572  3052 ?        S    16:36   0:00 nginx: worker process                                          
nginx     5561  0.0  0.2  42572  3044 ?        S    16:36   0:00 nginx: worker process                                          
nginx     5562  0.0  0.2  42572  2992 ?        S    16:36   0:00 nginx: worker process                                          
nginx     5564  0.0  0.2  42572  2940 ?        S    16:36   0:00 nginx: worker process  

pidファイルで確認する方法

nginx.confにpidディレクティブを設定している場合は設定したパスにpidファイルがあります。

$ cat /var/run/nginx.pid;
5559

pidは5559です。
ワーカープロセス数は、confファイル"worker_processes"の設定に依存します。

新しいバイナリを実行する（USR2シグナル）

USR2シグナルをマスタープロセスに送ります。

$ sudo kill -USR2 5559

すると、古いバージョンのプロセスと新しいバージョンのプロセスが共存する状態になります。

$ ps aux |grep nginx
root      5559  0.0  0.0  40976  1068 ?        Ss   16:36   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
nginx     5560  0.0  0.2  42572  3052 ?        S    16:36   0:00 nginx: worker process                                          
nginx     5561  0.0  0.2  42572  3044 ?        S    16:36   0:00 nginx: worker process                                          
nginx     5562  0.0  0.2  42572  2992 ?        S    16:36   0:00 nginx: worker process                                          
nginx     5564  0.0  0.2  42572  2940 ?        S    16:36   0:00 nginx: worker process                                          
root      7962  2.0  0.2  41024  3084 ?        S    19:29   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
nginx     7963  0.0  0.2  42732  3060 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7964  0.0  0.2  42732  2860 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7965  0.0  0.2  42732  2860 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7966  0.0  0.2  42732  2852 ?        S    19:29   0:00 nginx: worker process 

古いバージョンのワーカーを止める（WINCHシグナル）

WINCHシグナルを古いマスタープロセスに送ります。

$ sudo kill -WINCH 5559

すると、既に受け持っているリクエストの処理が終わり次第、古いワーカープロセスが順次終了していきます。古いプロセスはマスタープロセスだけになり、リクエストは新しいワーカープロセスが受け持っています。

ps aux |grep nginx
root      5559  0.0  0.0  40976  1072 ?        Ss   16:36   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
root      7962  0.0  0.2  41024  3084 ?        S    19:29   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
nginx     7963  0.0  0.2  42732  3060 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7964  0.0  0.2  42732  2860 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7965  0.0  0.2  42732  2860 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7966  0.0  0.2  42732  2852 ?        S    19:29   0:00 nginx: worker process  

古いバージョンのマスタープロセスを止める（QUITシグナル）

QUITシグナルを古いマスタープロセスに送ります。

$ sudo kill -QUIT 5559

古いマスタープロセスが終了し、新しいマスタープロセスとワーカープロセスだけになりました。

$ ps aux |grep nginx
root      7962  0.0  0.2  41024  3084 ?        S    19:29   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
nginx     7963  0.0  0.2  42732  3060 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7964  0.0  0.2  42732  2860 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7965  0.0  0.2  42732  2860 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7966  0.0  0.2  42732  2852 ?        S    19:29   0:00 nginx: worker process 

検証

検証方法

http_loadを使ってドキュメントルートに置いたテキストファイルをアップグレード作業中にクライアントから毎秒10リクエスト行う。

結果

作業中の2分間、1199リクエストが全て正常に終了したので、問題なくアップグレードができたと思われます。

./http_load -rate 10 -seconds 120  -verbose url_file
--- 60.0062 secs, 600 fetches started, 599 completed, 1 current
--- 120.006 secs, 1200 fetches started, 1199 completed, 1 current
1199 fetches, 1 max parallel, 3597 bytes, in 120.006 seconds
3 mean bytes/connection
9.99115 fetches/sec, 29.9735 bytes/sec
msecs/connect: 0.417418 mean, 0.717 max, 0.248 min
msecs/first-response: 0.353556 mean, 0.605 max, 0.253 min
HTTP response codes:
  code 200 -- 1199

詳細は各発表者の方のスライドを見るとわかると思いますが、当日会場でメモしたものでダイジェスト的にまとめました。
MongoDB勉強会は毎月開催（予定）しているそうなので、興味を持たれた方は是非参加して見てください。
MongoDBコミュニティー：MongoDB JP | Google グループ

【発表1】MongoDB全機能解説1

MongoDB特有の仕様や機能など、プロダクションで使う場合には特に注意が必要な部分を中心に説明されていました。

ロック

Read/Writeの各オペレーション時にDBに対してロックがかかる。
MongoDBをフロントエンドで使う場合、DBがロックして応答が返って来なくなるなどの問題が起きる可能性があるので、時間がかかる処理には注意が必要とのこと。

実際、単体のRead/Writeは十分高速でロックの待ち時間で問題が起こることはないが、複数のWrite処理をアトミックで行なったり（{atomic: ture}）、MapReduceで重い処理をさせるケース（ロックはかからないが処理が重いので）が問題になる。

mongos

mongosサーバーは協調する複数のmongodサーバーがある場合、それを一つのクラスターとして扱うためのルーティングサーバーで、それ自体ではストレージする機能はない。
アプリケーションは複数あるmongodサーバーの中でどれががマスターでどれがスレーブなのかを知らなくてもmongosサーバに問い合わせればいい。

database

32bit環境ではDBサイズが2.5GBまで扱えないので、要64bit環境とのこと。
参考：32-bit limitations

BSON

データはBSONという形式で保存されている。データ型が複数あり、どのデータ型で保存されるのかはドライバーに依存する。
→ 例えば、PHPの場合はMongoInt32やMongoInt64などのデータ型用のクラスが用意されてる。
オブジェクト内の順序もみているので、順番が入れ替わるだけで別のオブジェクトととされてしまう。
→ { ‘key1′: ‘value1′, ‘key2′: ‘value2′ } ≠ { ‘key2′: ‘value2′, ‘key1′: ‘value1′ }

Capped Collection

サイズを指定してCollectionを作成するとCapped Collectionになる。
サイズが固定なのでサイズを越えた場合は古いものから自動的に削除される。
とにかく書き込みが速い。でも削除できない。
_idにすらindexがつかない。indexを張ることもできるが遅くなる（それでも速い方）。
shardingすることはできない。
用途 → ロギング（ディスクサイズを圧迫しない）
　　 → キャッシング
　　 → MapReduceの一時的なCollectinとして

Insert周り

Bulk Insert

複数のdocumentを配列に入れて一括でインサートする「Bulk Insert」が速い。
ただ、どのくらいのサイズまでが最適なのかはスペック依存で、経験上16MBを超えるとエラーが出るそう。

fire and forget

インサートはデフォルトではデータベースからの応答を待たない。
応答を確認するには、各種ドライバーでインサート時に応答を待つ処理を明示的にオプションとして指定する必要がある。
→ PHPではarray(‘safe’=>true)

トランザクション

RDBのように複数のオペレーションをトランザクション処理することは出来ないので、連続インサートする場合、途中でエラーになっても一連のインサートをロールバックすることは出来ない。

getLastErrorメソッド

db.getLastError();

でオペレーションの最後に起こったエラーがわかるので、このメソッドは重要。

fsyncコマンド

メモリ上のデータを強制的にストレージにフラッシュするコマンド。

db.runCommand({fsync:1});

fsyncは自動的に60秒に1回走るようになっていて、mongod起動時に、–syncdelayオプションで変更可能だが10genとしては非推奨とのこと。
つまり、最長60秒間に行われたデータの更新は喪失する可能性がある。

Journaling(v1.7.5)

オペレーション前にJournalingファイルに保存し、オペレーションに失敗した場合、次回実行される。
100ms毎にジャーナリングされる。つまり、100ms間のオペレーションは喪失する可能性がある仕様。

Query

printjson

シェル（mongo）でデータを確認するときには

db.collection.find().forEach(printjson);

とするとJSON形式にフォーマットされ見やすくなる。

入れ子

入れ子になったオブジェクトをサブオブジェクト形式でfindする場合は、完全に一致したオブジェクトでないと取得できない。
サブオブジェクト内のあるキーだけを検索対象としたい場合は、dot notation形式({author.name: ‘Jane’})で問い合わせる。

var doc = { title: 'タイトル', body: '本文', author: { first_name: '太郎', family_name: '山田'} };
db.collection.insert(doc);
db.collection.find({author.first_name: '太郎'}); //◯ヒットする
db.collection.find({author: { first_name: '太郎'} }); //×ヒットしない

Update

Update

デフォルトでは最初にヒットしたオブジェクトのみを更新する。
→ ヒットした全てを更新対象としたい場合は{ ‘multi’: true } オプションを付ける。
→ 複数の更新をアトミックに行うには { ‘$atomic’: true } オプションを付ける。

Save

同じ_idのオブジェクトがあれば自動的にドキュメント全体を更新する。

modifier オペレーション

アップデートのオプションとして$inc/$set/$push/$popなどのオペレーションがある。
modifierオペレーションを指定しないでアップデートを行うとオブジェクト（ドキュメント）をまるごと上書きするのでとても怖い。

in-place update

データサイズが変わらない更新の場合は高速。（例えば、{ ‘$inc’; { key: 1 } } など。）
また、データの更新を高速に行うため、インサートされた際に実データサイズよりも大きめにストレージを使って保存している。
→ 多少のサイズの増加も高速に更新出来る。逆に言うと無駄にストレージを使う。

Snapshot

MongoDBはデータサイズが大きく増えた場合、データベースファイルの新しい領域にデータを格納し直す。この瞬間にfind()すると同じドキュメントが2個取れたりする可能性がある。
find()で取り出した複数のドキュメントをupdate()するようなケースでは問題になるので、重複を排除して結果を返すsnapshot()を使う。

db.collection.find({name:'Jane'}).snapshot();

Indexについて

B-Tree indexes

インデックスを生成するオペレーションensureIndex()はデフォルトではDBをブロックする。
{ background: true } オプションを付けるとロックしないので、基本的にこれを必ず付けること。

db.collection.ensureIndex({name: 1}, {background:true});

参考：Indexing as a Background Operation

Sparse Index(v 1.7.4)

インデックスの設定されたフィールドを持っていないドキュメントは無視される。
→ コレクション全体的の中でSparse Indexに設定されたフィールドに値を持っているドキュメントがが少ない場合にパフォーマンスが出るインデックス。

Unique Index

インデックスを張ったキーが存在しないドキュメントを登録するとnullが挿入され、nullがユニークの対象となる。
→ インデックスを張ったキーが存在しないドキュメントをもう一つ登録すると重複エラーになる。
ただし、sharding環境では重複する可能性がある。

Replication

• Master-Slave：一般的なM/S構成
• Replica Sets：自動フェイルオーバ機能などを提供

Master-Slave

Master->Slaveは非同期でコピーされる。
mongodをそれぞれ、–master、 –slaveを付けて起動するだけ。
→ slaveには直接書き込みできない。（mongos経由）

同期は各データベースがそれぞれローカルに自動的に作成するoplog(operation log)コレクションを介して行われる。

1. スレーブ（セカンダリ）はマスターのoplogを監視している。　
2. マスター（プライマリ）は更新系のオペレーションをoplogに書き込み、自分のデータベースに実行する。
3. スレーブはマスターとの差分のoplogを自分のoplogへコピーし、そのオペレーションを自分のデータベースに実行する。

MySQLのバイナリログと同じようなイメージ。

Replica Sets

3台〜12台で構成でき、自動フェイルオーバー機能／自動リカバリ機能を持つ。
ノードタイプには、Standard（データあり。Primaryになれる。）、Passive（データあり。Primaryになれない。）、Arbiter（データなし。投票権はある。）がある。
フェイルオーバーは、起動時に設定するprimary値の高いもの ＞ 最も新鮮なデータを持っているもの ＞ 投票数の多いもの の順で順番付けされ、決定したセカンダリーがプライマリになる。
ダウンしているサーバーが多かったり、最終更新データが古すぎたりするとどのセカンダリーもプライマリにならないことがある。→ 手動で対応。

【発表2】ソーシャルアプリのプロトタイプ制作にMongoDBを活用

Sleepy.Mongoose

アプリケーションとデータベースの通信はSleepy.Mongoose（pythonで実装されたRestインターフェース）を利用して、curlで実装している。
→ Sleepy.Mongooseにはcount()が実装されていないのでforkしたものをGitHubに置いてあるとのこと。
bibrost / sleepy.mongoose

Cray Model

自動車開発のプロセスで粘土細工（Cray Model）で何度も何度も型を作ってから金型を作るように、プロトタイプの開発がしたい。
RDBのようにスキーマを定義して、チーム内で変更を共有して、不整合が起きないようにCREATE TABLEしたりALTER TABLEしたりするのは面倒。
MongoDBはアプリケーション上でいくらでもデータ構造を変更できるので、ソースさえ共有すればよく、途中でドキュメント構造が変わっても、手を止めることなくcollection名を変えるだけでいい。→まさに粘土細工のように失敗したら壊してまた作ればいい。

なぜ最終的にRDBにするのか

• MongoDBを保守できるエンジニアがいない。
• MongoDBをクリティカルなプロダクションで使うことが難しい（トランザクションがない）。

【発表3】MongoDBチューニング 〜スロークエリ撲滅までの道筋〜

オプティマイザ

RDBで多く採用されている一般的なオプティマイザは統計情報を元にしたコストベースで、本番環境と検証環境で統計情報が異なっていると実行計画が違ってきたり、悪い実行計画も行われる。
MongoDBのオプティマイザはコストベースではなく、新しいクエリー実行がある度に計算する仕様。（オーバーヘッド・CPUコストが高いが、最適な計画が行われる）

• 新しいクエリー実行時に複数の実行計画を並行に実施して一番速いのを採用・学習し、他のものは途中で止める。
• 100回データ更新が行われ時やindexが変更された時、最初の評価時からスキャンするドキュメントが大きく増えた場合（nscannedの値が10倍になったら）再評価を実施する。

explainメッソド

explain()で実行計画を確認できる。

db.collection.find(query).explain();

勘所としてはBasicCursorは全件スキャンなので×、millisが長いと処理時間が遅いので×、nscannedが多いとスキャン対象のドキュメント数が多いので×、など。

スロークエリの特定

複合インデックス

順序が大事。
db.collection.find({x: 10}).sort({ y: 1});でも { x: 1, y: 1 }のインデックスが使われる。

hintメソッド

hintメソッドを使うと特定のインデックスを使わせることができる。
インデックス設定されていれば、
db.collection.find().hint({uid:1}); より db.collection.find().hint({uid:1, path:1}); の方がより絞られて高速になる。

mongostat

mongoやmongodなどと一緒にインストールされるmongostatコマンド。
ロックされている割合やインデックスが利用されなかった割合などの統計情報が確認できる。

killメソッド

db.killOp(opId)で実行中のクエリをkillできる。

【発表4】MongoDBを使用したモバイルゲーム開発

東京ガールズスナップの構成

Java（appサーバー2台）+ MongoDB（Replica Setで3台）で運用している。
MongoDBに対応したSpring Data Documentを利用して開発した。

MongoDBで良かったこと

階層型にデータが持てるのでkey-value的に使えた。
→ ドキュメント内に配列を持つことができるので、RDBのようなリレーションや連結などしなくても直接$pushや$popで複数のデータを出し入れできる。

バイナリデータが保存しやすい
当初の想定していた利用法ではなかったが画像データのキャッシュストレージとして利用できた。
→ 4MBまでだったらバイナリデータをそのまま格納できる。

MongoDBが問題になったこと

• オペレーションミスが大変なことになる（update時に$setで指定しないと全部上書きする）
• アプリ経由ではなくコンソールでデータを更新したらデータ型が変わってしまった（intがdoubleに）
• ドキュメント設計の最適化に時間がかかった（ベストプラクティスがわからない）

ATNDのAPIを利用してワンクリックで自分の登録しているイベントをiPhoneのカレンダーに取り込めます。

通常のAPIへのアクセス方法を以下のように変更して、iPhoneのsafariでアクセスするだけです。

すると、カレンダーに取り込む（照会する）かを聞かれるので

照会を押します。

取り込み完了です。

カレンダーにアクセスをするとATNDのイベントスケジュールが表示されます。

URLにアクセスするのも面倒かもしれないのでスクリプトを書きました。
以下のテキストフォームにATNDのニックネームを入れて、「カレンダーを開く」を押すと上記の手順でアクセス出来ます。是非ご利用下さい。

※iPhone以外でも、Webcalに対応していれば同様のことが可能です。

Osukini Cloudとは

クラウドサービス「Osukini クラウド」｜クラウドならSaaSes

Osukini Cloudは日本ラッドが提供するSaas/Paasサービスのブランド「SaaSes」の1商品です。
Cloudと銘打ってはいるものの、サーバーのスナップショットイメージを保存して再利用したり、稼働済みのサーバーのクローンを立ち上げたりする、スケールアウト向けの機能はありません。

簡単に言うと、CPU・メモリ・ハードディスクを動的にスケールアップ・ダウンできる機能が付いたXenベースのVPSサービスです。
仮想サーバーの仕組みをそのままサービスにしたイメージです。

Osukini Cloudの使いどころ

上述のように急激なアクセス増が予想されるスケールアウト必至のサービスには向いていないので、使いどころとしては

• 当面は低スペックで構わないが後々のアクセス増対応に不安
• 既存の格安VPSでどのプランで契約していいかわからない

ようなケースが当てはまるかもしれません。

さくらのVPSが価格の割に品質がよく、満足できるVPSサービスだと思いますが、現時点でスペックが固定なので、もう少し高スペックで同様に低価格なサービスを探している方にはOsukini Cloudはおすすめだと思います。

スペックと価格

一般的なVPSサービスのようにプランごとにスペックが決まるのではなく、1プランでスペック変更が可能というところが特徴ですので、最低スペックで始めて運用しながら随時変更することができます。（スケールアップ・ダウンには再起動・サービスダウンが伴うようです。）

料金とスペックをまとめると以下のようになります。（全て月額）

CPUとメモリは連動で、4×4の16パターンの料金体系があり、月途中でスペックを変更した場合は、その月で最もハイスペックだった料金が請求される仕組みです。
転送量に対する課金もありませんし、稼働時間に対する課金もありませんので、料金が非常に明確になります。

利用可能なOSは以下の通りです。

• CentOS ver5.5 32bit
• CentOS ver5.5 64bit
• Ubuntu ver10.04 32bit
• Debian ver5.0(lenny) 32bit
• Debian ver5.0(lenny) 64bit
• Debian ver6.0(squeeze) 32bit
• Debian ver6.0(squeeze) 64bit

実際に使ってみて

現在、4CPU/4GB+80GB(¥5,800)、CentOS5.5 64bitのサーバーを3台契約しています。
ホームページ上では最短5分以内でスタートできると書いてありますが、1台目を契約した際は在庫がないとのことで、サービスの利用開始まで丸1日かかり、2台目・3台目は14、5分でした。必ずしも契約後すぐに利用できるわけではないので、注意が必要です。

参考までに、サーバーの基本的なスペック情報は以下の通りです。

システム情報

$ uname -a
Linux hostname 2.6.18-194.32.1.el5xen #1 SMP Wed Jan 5 18:44:24 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

CPU情報

$ cat /proc/cpuinfo
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 9
model name	: AMD Opteron(tm) Processor 6128
stepping	: 1
cpu MHz		: 2000.154
cache size	: 512 KB
physical id	: 0
siblings	: 1
core id		: 0
cpu cores	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse
bogomips	: 5003.13
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc [6] [7] [8]

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 9
model name	: AMD Opteron(tm) Processor 6128
stepping	: 1
cpu MHz		: 2000.154
cache size	: 512 KB
physical id	: 1
siblings	: 1
core id		: 0
cpu cores	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse
bogomips	: 5003.13
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc [6] [7] [8]

processor	: 2
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 9
model name	: AMD Opteron(tm) Processor 6128
stepping	: 1
cpu MHz		: 2000.154
cache size	: 512 KB
physical id	: 2
siblings	: 1
core id		: 0
cpu cores	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse
bogomips	: 5003.13
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc [6] [7] [8]

processor	: 3
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 9
model name	: AMD Opteron(tm) Processor 6128
stepping	: 1
cpu MHz		: 2000.154
cache size	: 512 KB
physical id	: 3
siblings	: 1
core id		: 0
cpu cores	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse
bogomips	: 5003.13
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc [6] [7] [8]

メモリ情報

$ cat /proc/meminfo
MemTotal:      4194304 kB
MemFree:         67556 kB
Buffers:         59036 kB
Cached:        3588160 kB
SwapCached:          0 kB
Active:        2048284 kB
Inactive:      1838268 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      4194304 kB
LowFree:         67556 kB
SwapTotal:     8393952 kB
SwapFree:      8393880 kB
Dirty:            1064 kB
Writeback:           0 kB
AnonPages:      239332 kB
Mapped:          11304 kB
Slab:           115088 kB
PageTables:       8744 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:  10491104 kB
Committed_AS:   332088 kB
VmallocTotal: 34359738367 kB
VmallocUsed:      4340 kB
VmallocChunk: 34359734027 kB

ディスク性能(Read)

$ sudo hdparm -Tt /dev/xvda3

/dev/xvda3:
 Timing cached reads:   9604 MB in  1.99 seconds = 4818.05 MB/sec
 Timing buffered disk reads:  340 MB in  3.01 seconds = 113.05 MB/sec

ディスク性能(Write)

$ dd if=/dev/zero of=/tmp/test.tmp bs=1M count=256
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 0.63945 seconds, 420 MB/s

$ dd if=/dev/zero of=/tmp/test.tmp bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 2.70829 seconds, 396 MB/s

最後に

運用して1週間程立ちましたが、スペック通り十分なパフォーマンスを安定して発揮してくれています。リプレース元のサーバーでは転送量課金もかかっていたので、だいぶコストを圧縮することが出来ました。

格安VPSではスペックがネックになって利用シーンが限られていたと思いますが、Osukini Cloudはスペックの自由度が高いので、格安VPSと専用サーバーの間の領域を柔軟にカバーしてくれる数少ない優れたVPSサービスだと思います。