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

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

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

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

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

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

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

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

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

ローカルファイルで実験

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

• type（リサイズの方法）
  • resize（縦横比を変えずにサイズ変換）
  • crop（サイズ変換後に指定されたサイズに切り取る）

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

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

# 靜的なファイルの場合は処理をとめる # リクエストの度にファイルの存在をチェックするのは無駄だという意見もありますが、 # どのURLの時index.phpに渡すのか、プラグインを含めて全仕様が分からないため、 # これが最も安全だと思います # モバイルからのアクセスはキャッシュさせないようにする変数 # 存在しないPHPファイルをシャットアウト # よくアクセスされる静的ファイルにブラウザキャッシュが効くように設定 # ドット始まりのファイルはアクセスできないように internal; # この指定をしておくとURLを指定して直接アクセスできなくなる

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

静的ファイルのチェック

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

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

ここでは、$supercache_uriが””（空文字）に書き換えられると、WP Super Cacheの静的キャッシュファイルが使われず（下の判定で利用されます）、$nocacheが”1″に書き換えられると、fastcgi cacheが使われません（ ~ \.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が仕倳をしてしまいます

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

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

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

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