公式ドキュメントでも黒魔術などと称されている悪名高いモジュールmod_rewriteですが、要は設定例や内部でどのように動くかが解説されていないためによくわからないモジュールとされているだけであって、それらを理解してしまえば普通に使いこなすことができるようになります。

例えば以下のことを知らないような人向けに書いてみました。

• RewriteRuleディレクティブに渡される（RewriteRuleディレクティブで評価される）URLが、RewriteRuleディレクティブをどこに書くか（httpd.confか.htaccessかなど）によって違う
• RewriteBaseディレクティブはなんのためにあるのかよくわからない
• RewriteCondで使える変数に何があるか、そしてそれらの変数が何を指すのかわからない
• RewriteRuleの第三引数の各種フラグ（LとかNとかPとかQSAとか）がよくわからない

また設定例として、携帯からのアクセスを特定のURLに振り向ける、拡張子が.htmlから.phpに変わった場合でもリンク切れを起こさない方法、DNSを用いない簡易的なラウンドロビン、特定のファイル名のファイルをアップロードするだけで素早くメンテナンス画面に切り替えられるようにする、Amazon風のURLを実現する方法などを挙げてみました。

さらに、WEB+DB press Vol.38「RESTレシピ」などでも連載が始まって注目されているRESTなどとも絡めて、mod_rewriteを使ってURLをRESTful（REST準拠な）URLにするためのテクニックにも軽く触れています。

正規表現の解説も2ページほど付けましたので、mod_rewriteで多用する正規表現が苦手という方にもオススメです。

今回は、予めgzip圧縮するという作業を自動化するために、Railsでよく使われるデプロイツールであるCapistranoを利用します。

基本的な方針としては、(1)ローカルの開発環境上ではCSSやJavaScriptは非圧縮（編集しやすいように）、(2)サーバー上にデプロイされたCSSやJavaScriptにはgzip圧縮をかける（帯域削減のため）、(3)非圧縮CSSや非圧縮JavaScriptをサーバー上にも置いておく（gzip対応してないブラウザ向け）、という3点です。

例えば(1)の例は/asets/js/prototype.js（非圧縮）、(2)の例は/asets/js/prototype.js（gzip圧縮済み）、(3)の例は/asets/js/prototype.js.ungz（非圧縮）と言った感じ。ここで(1)と(2)のファイル名を揃えているのは楽をするため。つまりローカル開発環境とサーバー上でファイル名が異なってると、いちいちscriptタグを書き換えるのがめんどくさいのです。

さて、上で述べたようにサーバー上にデプロイされたアセットをgzip圧縮するCapistranoのタスクは以下の通り。これは#{current_path}に最新リリースがデプロイされた後に実行されるコードです。:updateタスクの中で実行されるようにしておくと良いでしょう。

desc <<-DESC
Updates the code and fixes the symlink under a transaction
DESC
task :update do
transaction do
update_code
compress_assets
end
end

desc "Compress assets"
task :compress_assets do
run "find #{current_path}/public/assets/ -name '*.js' -exec gzip {} \;"
run "find #{current_path}/public/assets/ -name '*.css' -exec gzip {} \;"
run "cd #{current_path}/public/assets/js;for i in *;do mv $i ${i%.js.gz}.js;done"
run "cd #{current_path}/public/assets/css;for i in *;do mv $i ${i%.css.gz}.css;done"
run "cd #{current_path}/public/assets/js;for i in *;do gzip -dc $i >$i.ungz;done"
run "cd #{current_path}/public/assets/css;for i in *;do gzip -dc $i >$i.ungz;done"
end

いちおう説明しておくと、findの2行で/public/assets/配下のJavaScriptファイルやCSSファイルにgzip圧縮をしています。次の2行は、gzip圧縮をかけると例えば名前がprototype.js.gzと変わってしまうので、prototype.jsに戻しています。最後の2行は圧縮後のprototype.jsを解凍し、prototype.js.ungzというファイルを作る部分です。

そうすると、/assets/jsの中身は以下のようになります。

-/assets/js/
|
|-prototype.js（gzip圧縮済み）
|-prototype.js.ungz（非圧縮）

さて、これをApacheのディレクティブを活用して配信するわけです。方針はgzip受け取れるブラウザはprototype.jsをそのまま受け取る、gzipを受け取れないブラウザやgzip扱いにバグありブラウザはprototype.js.ungzを受け取る、というもの。

<Directory /home/httpd/vhosts/example.jp/current/public/assets>
<Files ~ ".(css|js)$">
SetEnvIf Accept-Encoding "gzip" can_compress_assets
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 !can_compress_assets
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4.0[678] !can_compress_assets
# MSIE masquerades as Netscape, but it is fine
BrowserMatch bMSIE can_compress_assets

RewriteCond {%ENV:can_compress_assets} !1
RewriteRule ^(.+)(.css|.js)$ $1$2.ungz [L,QSA]
Header set Content-Encoding: gzip env=can_compress_assets
</Files>
</Directory>

説明。まずSetEnvIf Accept-Encoding "gzip"でHTTPリクエストヘッダの中にAccept-Encoding: gzipがあれば、圧縮できる（can_compress_assets）という環境変数を立てます。その後、BrowserMatchでごにょごにょやってるのは、一部ブラウザでgzipの扱いに問題があるため、問題があるブラウザはgzipしてないコンテンツをサーブする（!can_compress_assets）ようにします。

次のRewriteCond、RewriteRuleは環境変数can_compress_assetsがセットされていなかった場合（非圧縮コンテンツを返すべき場合）、例えばprototype.jsがリクエストされたら、非圧縮のprototype.js.ungzを代わりに返すというものです。

最後のHeader set Content-Encoding: gzip env=can_compress_assetsは、圧縮されたコンテンツを返している場合、HTTPレスポンスヘッダにContent-Encoding: gzipを追加するというものです。こうしないとブラウザは返されたコンテンツがgzipされていることを知らないため、解凍してくれません。

Content-Encoding: gzipを付けるならAddType gzip .jsでいいじゃないか、という意見が聞こえてきますが、その場合、上の非圧縮コンテンツを返している際もHTTPレスポンスヘッダにContent-Encoding: gzipが付いてしまい、ブラウザが圧縮されてないものを解凍しようとして混乱してしまいます。

CSSファイルやJavaScriptファイルはサイト内で数十になることも多く、それが数千万回リクエストされるとなると、それらのdeflate処理にかかっていたコストは馬鹿に出来なくなります。こうして予めgzip圧縮しておくことで、それらのコストを削減し、少しでも地球に優しくしようという試みでした。

しかし、HTTPサーバーはコンテンツの数だけ304 Not Modifiedを返さないといけないため、その分帯域を消費しますし、またCSSや画像などのパーツの304 Not Modifiedが返ってくるまで、そのパーツのレンダリングが行えないという問題があります（つまり体感速度に影響します）。

今回紹介するのはExpiresヘッダやCache-Control: max-age=31536000を活用して、CSSやJSなどのファイルをリクエストする際、それらのファイルが変更されない限り、If-Modified-Sinceなどのリクエストをそもそも発生させなくする方法です。

まず、Expiresヘッダの説明。これは、このHTTPレスポンスで返されたコンテンツの有効期限を指定するものです。例えばExpires: Sun, 08 Jun 2008 07:07:37 GMTと返ってくると、その日が訪れるまでブラウザはキャッシュの中身のものを使い続けます。つまり、Expiresで指定した日が訪れるまでIf-Modified-Sinceなどのリクエストをしなくなります。

Cache-Control: max-age=31536000の方は、31536000秒（365日）間はそのコンテンツが有効であると判断されます。つまり31536000秒間はブラウザのキャッシュから読み続けることになり、Expiresと同様にIf-Modified-Sinceなどのリクエストをしなくなります。

ApacheでExpiresヘッダやCache-Control: max-age=31536000を付加させるディレクティブは以下の通り（この例では1年後が有効期限に来るように設定しています）。

ExpiresActive On
ExpiresDefault "access plus 1 year"

ちなみに、RFC2068の14.21節によれば、HTTP/1.1サーバーは有効期限として「無期限」を指定したい場合は、「ちょうど1年後をExipresに指定すべき」とあり、また「HTTP/1.1サーバーは有効期限として1年以上を返すべきでない」とされています。

さて、こうしてExpiresヘッダを指定してしまうと、CSSなどを変更したときに、（ファイル名が同じである限り）Expiresで設定した有効期限が訪れるまでブラウザが新しいものを読みに行ってくれなくなるという問題が発生します。これを解決するのがmod_rewrite。

ここでのミソはファイル名が同じである限りキャッシュから読み続けるということ。つまりファイル名さえ変えてしまえば、新しいファイルとして取得してきてくれるわけです。

しかしながら、CSSの変更を加える度に毎回linkタグで読み込むCSSのファイル名を変えるのはものすごく手間がかかります。そこで、ファイルにバージョン名を含ませる（/assets/css/base.v20070609.css）のだけれど、実体は/assets/css/base.cssを読むようにすることが出来るのがmod_rewrite。その設定方法は以下の通り。

<Directory /home/httpd/vhosts/example.jp/current/public/assets>
RewriteEngine on

RewriteRule ^(.*?).vd+.(.*)$ $1.$2 [QSA,L]
</Directory>

こうすることで、実体の/assets/css/base.cssを更新したときに、
<link href="/assets/css/base.v20070609.css" rel="stylesheet" type="text/css" />
から
<link href="/assets/css/base.v20070610.css" rel="stylesheet" type="text/css" />
に変更すれば、ブラウザは変更後のファイルを読みに行ってくれます。

さて、これは応用編になりますが、RailsアプリなどでCapistranoを使うと、サイトが以下のようなファイル構成になります。

---current ->(20070609071925へのシンボリックリンク)
|
|-releases/
|-20070609071925/
|   |-public/
|       |-index.cfm
|       |-assets/
|           |
|           |-css/
|           |  |
|           |  |-reset.css
|           |  |-base.css
|           |
|           |-js/
|              |
|              |-protopype.js
|
|-20070609065605/

つまり、releases以下にリリースされたサイトが蓄積され、currentから最新版のリリースディレクトリへシンボリックリンクが張られている状態になります。

ここで、releases以下のディレクトリ名がユニーク（ぶつからない）ことを利用して、上のmod_rewriteのソリューションを使うことが出来ます。

つまり、アプリケーションロジックでcurrentシンボリックリンクのリンク先をresolveして（20070609071925などというディレクトリ名を取得し）、CSS読み込みタグをアプリケーションで下記のように動的に書き出す
<link href="/assets/css/base.v(リリースディレクトリ名).css" rel="stylesheet" type="text/css" />
ことで、Capistranoでサイトをリリースするたびに、自動で新しいCSSが読み込まれるようになります。

しかしながら、mod_filterの実例があまりにも少ないため、どう使っていいか分からないのが現状です。なので、AddOutputFilterByType DEFLATE text/htmlを書き換えてみることにしました。

mod_deflateのドキュメントには、実例として画像以外をすべて圧縮する方法が以下のように書かれています。

<Location />
# Insert filter
SetOutputFilter DEFLATE

# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine
# BrowserMatch bMSIE !no-gzip !gzip-only-text/html

# NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
# the above regex won't work. You can use the following
# workaround to get the desired effect:
BrowserMatch bMSI[E] !no-gzip !gzip-only-text/html

# Don't compress images
SetEnvIfNoCase Request_URI
.(?:gif|jpe?g|png)$ no-gzip dont-vary

# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
</Location>

これをベースにMIME-typeがtext/*、application/xhtml、application/xmlの場合、deflateするようにしたものが以下になります。

<Location />
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine
BrowserMatch bMSIE !no-gzip !gzip-only-text/html

# ここからフィルター設定
FilterDeclare Compression CONTENT_SET
FilterProvider Compression DEFLATE Content-Type $text/plain
FilterProvider Compression DEFLATE Content-Type $text/css
FilterProvider Compression DEFLATE Content-Type $application/xhtml
FilterProvider Compression DEFLATE Content-Type $application/xml
FilterProvider Compression DEFLATE Content-Type $application/xhtml+xml
FilterProvider Compression DEFLATE Content-Type $application/rss+xml
FilterProvider Compression DEFLATE Content-Type $application/atom+xml
FilterProvider Compression DEFLATE Content-Type $application/x-javascript
FilterProvider Compression DEFLATE Content-Type $image/svg+xml
FilterChain Compression
# ここまでフィルター設定

# Don't append Vary heder for specific files
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|zip|lzh|exe)$ dont-vary

# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
Header append Vary Accept-Encoding env=!dont-vary
</Location>

まず、FilterDeclareディレクティブでCompressionという名前のフィルター群のタイプがCONTENT_SETであると宣言します（これはなぜそうする必要があるのかよく分からないので教えてください）。

次にFilterProviderディレクティブでCompressionフィルター群にフィルターを追加しています。FilterProviderディレクティブの第一引数はフィルター群に付ける名前（今回はCompression）、第二引数はフィルターのプロバイダー名です。mod_deflateモジュールを読み込むと、ap_register_output_filter関数でDEFLATEというプロバイダー名が自動的に登録されます（そのプロバイダーがdeflateを行います）。第三引数（Content-type $text/plain）はフィルターを実行する条件を指定するもので、今回はHTTPレスポンスヘッダのContent-typeがtext/plainに部分一致した場合のみ、フィルターを実行するという条件をつけています。

最後のFilterChainディレクティブでCompressionフィルター群がApacheのリクエストを通じて呼び出されるようにします（つまりFilterChainディレクティブを使わないと、定義されたフィルター群は実行されません）。

ここで気になるのが、BrowserMatchディレクティブで環境変数に設定したno-gzipやgzip-only-text/htmlがフィルター実行の条件の絞込み（FilterProviderディレクティブの第三引数）に使われていないということです。実はこれらの環境変数はmod_deflateモジュール内で参照され、たとえばno-gzipが設定されていた場合は、自動的にフィルターが外れるようになっています。

なので、経験を元に書いてみることにします。

弊社の画像配信サーバーには、平均10kbぐらい（たぶん）の画像が30万個ぐらいあって、それをDell PowerEdge 1750+lighttpdを使って配信してます。

以前は搭載メモリ1GBのサーバーを使っていたのですが、その時のvmstatがこのような感じ。

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa 0  1  31368  55072 598708 119256    0    0   946     0 1573  1577  0  1 71 27 0  3  31368  54580 600728 119576    0    0  1184   682 1600  1521  0  1 71 27 0  2  31368  51168 603412 120012    0    0  1472     0 1646  1634  0  1 74 25 0  1  31368  48764 606928 120136    0    0  1794     0 1567  1299  0  1 75 25 0  1  31368  47280 608764 120120    0    0  1014   684 1608  1618  0  1 74 25 0  3  31368  47252 611056 120428    0    0  1212     6 1504  1283  0  1 74 25 0  1  31368  47656 613236 120328    0    0  1138   720 1487  1125  0  1 74 25 0  2  31368  46288 615728 120436    0    0  1286     0 1534  1382  0  1 73 26

見て分かるのが、CPUのディスクI/O待ち（wa）が大きいこと。実際、画像が配信されてくるまで一呼吸置くぐらいあって、これはディスクI/Oがやばいんだろうなと思ってました。なので、ディスクを高速化しないといけないのかなぁ、と思っていたのですが、すでにSCSIでRAID5だしどうしたものかと思っていたのです。

しかし、Linuxにあるファイルキャッシュを使えばいいんじゃないと気付いたのです。Linuxは、『一度読み込んだファイルは再び読み込まれる可能性が高い』という前提の元、読み込んだファイルをメモリー上にキャッシュしておくのです（memory欄のcacheがファイルキャッシュに使われてるメモリー量）。ファイルキャッシュは空きメモリーの中からLinuxが勝手に確保してくれるので、メモリーを2GBに増設してみました。増設後のvmstatがこんな感じ。

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
0  0    696  46956 235932 1457628    0    0    48  1512 2938  5197  1  4 94  1
2  0    696  47020 235932 1457628    0    0     0     0 3077  5451  1  5 94  0
0  1    696  46956 235932 1457628    0    0    68   756 3457  6351  2  6 91  1
1  0    696  46764 235932 1457628    0    0    28  6404 5446  7418  2  8 81  9
0  0    696  46828 235936 1457624    0    0    20     0 3653  6699  2  6 91  0
0  0    696  46636 235944 1457616    0    0    92  1504 3644  6701  2  7 89  2
0  0    696  46636 235948 1457872    0    0    48     0 3469  6373  2  7 91  1
0  0    696  46572 235964 1457856    0    0    32     0 3837  7359  2  7 90  1
0  0    696  46508 235980 1457840    0    0    48     0 3513  6718  2  7 90  1
0  0    696  46572 235980 1457840    0    0     0     0 3058  5742  1  5 93  0
0  0    696  46508 235980 1457840    0    0    36  1592 2834  4880  1  4 93  2
0  0    696  46508 235980 1457840    0    0    12     0 3379  6077  1  5 93  0
0  0    696  46508 235980 1457840    0    0     0     0 3159  5850  1  5 94  0

ほとんどI/O待ちが発生していないことが分かります。つまり、よく読み込まれる画像はほとんどファイルキャッシュに入ってしまって、キャッシュから読み込んでいると言うことです（上に比べてbi(ディスクからの読み込み量)が少ないことからも分かります）。この対策をしたことで、サーバーから出て行く秒間のデータ量が約3倍ぐらいになりました（つまりディスクI/Oのボトルネックが解消し、画像配信速度が向上したと言うこと）。

そこで、導き出されるサーバーの選び方は以下のようになるのではないでしょうか。

ところで、なぜこのボトルネックに気付かなかったかというと、abやJMeterで負荷テストをしていたからです。つまり、これらのベンチマークツールでは数十万個のファイルのランダムリクエストを擬似的に発生させることができなかったのであり（JMeterとかだとできるのかもしれないですけど調べてないです…）、リクエストしていたせいぜい数十個のファイルはファイルキャッシュに入ってしまっていたので、負荷テスト時にはディスクI/Oのボトルネックが表面化しなかったのです。

もしかするとまだまだ改善できるかもしれないので、つっこみとかお待ちしてます。

で、そんなような仕組みを作った後で考えないといけないことは、認証後どうやってHTTPに戻すかと言うこと。つまり、すべてのページでHTTPSを使うのはサーバーに負荷がかかり現実的ではないので、認証する部分だけHTTPSで改竄や盗聴を防ぎ、その他のページはHTTPで済まそうという事です。図にするとこんな感じ。

普通に考えると、パスワードを認証後のHTTPレスポンスヘッダ(*1の部分)で
Location: http://www.exmaple.com/logined.html
とかすればいいんじゃないの？と思うのですが、そうするとIEで「セキュリティーで保護されていないページに移動しようとしています」というような警告ダイアログが出てきてしまいます。

そんな警告ダイアログが出るのはユーザーフレンドリーじゃないので、それを防ぐ方法。

解決方法は簡単で、レスポンスヘッダで対応できないならレスポンスボディーで対処すればOK（Yahoo!なんかもこの方法を使っているようです）。たとえば、認証後、*1のところで以下のようなHTMLを返してあげれば、ブラウザがHTTPなページにリダイレクトしてくれるわけです。

<html>
<head>
<meta http-equiv="refresh" content="0; url=http://www.exmaple.com/logined.html">
<script type="text/javascript">
<!--
location.href = "http://www.exmaple.com/logined.html";
//-->
</script>
</head>
<body>
<p>ログインが完了しました。<a href="http://www.exmaple.com/logined.html">続けるにはここをクリックしてください</a>。</p>
</body>
</html>

追記 2006年4月26日

セキュリティー警告を回避することをフレンドリーというのはいかがなものか、というトラックバックなどもいただきましたので、あわせてHTTPSからHTTPのページに移動する際にIEのセキュリティー警告を回避できることについてもご覧ください

このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。

Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。

そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。

今回は、mod_deflateと組み合わせる際の注意点です。前回までの設定ではhttpd.confに以下のように書いていたかと思います。

ProxyRequests Off
ProxyPass / balancer://cluster/ timeout=2

<Proxy balancer://cluster/>
BalancerMember http://192.168.1.1/ loadfactor=10 keepalive=On
BalancerMember http://192.168.1.2/ loadfactor=10 keepalive=On
</Proxy>

さて、mod_proxy_balancerようなモジュールを使うサイトというのはApacheレベルで300 Request/secを超えるようなサイトだと思います。このようなサイトで気になってくるのは帯域の問題。基本的に流せるデータ量によって回線使用料が決まってくるのであり、圧縮効率のよいHTMLやCSSやJavaScriptはなるべくmod_deflateで圧縮して転送し、またブラウザにキャッシュされた後から変更のないファイルは「304 Not Modified」をHTTPレスポンスとして送ることで、データの転送量を少しでも削減することが重要になります。

普通に圧縮すればいいだけだろうと思って、以下のように設定すると、意外と帯域が節約できてないことに気づくと思います。

ProxyRequests Off
ProxyPass / balancer://cluster/ timeout=2

<Proxy balancer://cluster/>
AddOutputFilterByType DEFLATE text/html text/css application/x-javascript
BalancerMember http://192.168.1.1/ loadfactor=10 keepalive=On
BalancerMember http://192.168.1.2/ loadfactor=10 keepalive=On
</Proxy>

これで帯域が節約できない原因は意外なところにありました。

BalancerMemberで指定したバックエンドのサーバーが返すHTTPレスポンスには普通ETagという、コンテンツが更新されているかどうかを判定するためのヘッダが含まれるのですが、そのETagの生成に、ファイルのinode番号が使われていたのでした。

inode番号はサーバーごとにほぼ固有の値になってしまうのであり、192.168.1.1と192.168.1.2にアクセスが振り分けられた際には、それぞれ違うETagが返されてしまいます。違うEtagが返ってくると、ブラウザはコンテンツが更新されたものとして、新たに取得してしまうので、その分の帯域を使ってしまうと言うことでした。

これの解決策として、mod_headersモジュールを使ってブラウザへETagヘッダを返さないようにするのと、ブラウザからのIf-None-MatchヘッダをBalancerMemberに渡さないようにする方法をとりました。

ProxyRequests Off
ProxyPass / balancer://cluster/ timeout=2

<Proxy balancer://cluster/>
AddOutputFilterByType DEFLATE text/html text/css application/x-javascript
RequestHeader unset If-None-Match
Header unset ETag
BalancerMember http://192.168.1.1/ loadfactor=10 keepalive=On
BalancerMember http://192.168.1.2/ loadfactor=10 keepalive=On
</Proxy>

FileETag ディレクティブでETagの生成にinode番号を使わないようにする（FileETag MTime Size）とすることでも回避可能ですが、IEでは一旦ETagがキャッシュされてしまうと新しいETagに置き換えてくれないという問題があり、この回避策は見送りました。

さて、これでもまだ帯域が節約できていないことに気づくと思います。

原因はブラウザシェア8〜9割を占めるIEの実装にありました。

mod_deflateを使うと、レスポンスヘッダにVary: Accept-Encodingが追加されるのですが、これがあると常にIEはIf-Modified-Sinceヘッダを送らずにコンテンツを取得しようとするのでした。（See also: IE ぁぃぃ〜 – にぽたん研究所）

これの回避策としてはレスポンスヘッダからVaryヘッダを取り除くことが挙げられます。副作用としてAccept-Encoding: deflateを送っていないブラウザにもdelateなコンテンツをデリバリしてしまうことになりますが、 deflateに対応していないブラウザというのはごく少数だと思われるので、問題ないと言うことにしました。

ProxyRequests Off
ProxyPass / balancer://cluster/ timeout=2

<Proxy balancer://cluster/>
AddOutputFilterByType DEFLATE text/html text/css application/x-javascript
RequestHeader unset If-None-Match
Header unset ETag
Header unset Vary
BalancerMember http://192.168.1.1/ loadfactor=10 keepalive=On
BalancerMember http://192.168.1.2/ loadfactor=10 keepalive=On
</Proxy>

このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。

Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。

そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。

今回は、BalancerMemberディレクティブに渡すパラメーターのチューニングについてです。前回までの設定ではhttpd.confに以下のように書いていたかと思います。

ProxyRequests Off
ProxyPass / balancer://cluster/ timeout=2

<Proxy balancer://cluster/>
BalancerMember http://192.168.1.1/ loadfactor=10
BalancerMember http://192.168.1.2/ loadfactor=10
</Proxy>

さて、mod_proxy_balancerはバックエンドのサーバーが生きているかどうかを試すために、常に一定数のリクエストをBalancerMemberディレクティブで設定されたバックエンドのサーバーに投げているようです。SetHandler server-statusで見られるページには以下のようなアクセスとして見えます。（ExtendedStatus Onにしておかないと見られません）

さて、このリクエストを逆手にとって、HTTP/1.1のKeepAliveさせることで、新たにバックエンドとHTTPコネクション張るをコストを押さえようと考えました。

まず、バックエンドのサーバーのhttpd.confを編集することで、HTTP/1.1のKeepAliveを有効にします。

KeepAlive On
MaxKeepAliveRequests 300
KeepAliveTimeout 30

これで、HTTPレベルでのKeepAliveはOKになりました。

その後、mod_proxy_balancerの入っているサーバーからバックエンドとのコネクションがTCP/IPレベルで切断されないように、TCP/IPレベルでKeepAliveするようにBalancerMemberにkeepaliveパラメーターを渡しました。

ProxyRequests Off
ProxyPass / balancer://cluster/ timeout=2

<Proxy balancer://cluster/>
BalancerMember http://192.168.1.1/ loadfactor=10 keepalive=On
BalancerMember http://192.168.1.2/ loadfactor=10 keepalive=On
</Proxy>

残念ながら、この設定をする前とした後でのベンチマークを取っていないので、確実にスピードアップが図れたかどうかは不明ですが、おそらくレスポンスタイムは向上していると思います。

次回はmod_deflateと組み合わせる際の注意点を解説します。

このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。

Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。

そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。

今回は、ProxyPassディレクティブに渡すパラメーターのチューニングについてです。前回までの設定ではhttpd.confに以下のように書いていたかと思います。

ProxyRequests Off
ProxyPass / balancer://cluster/

<Proxy balancer://cluster/>
BalancerMember http://192.168.1.1/ loadfactor=10
BalancerMember http://192.168.1.2/ loadfactor=10
</Proxy>

こう設定した場合、mod_proxy_balancerがフリーのワーカーを取得できなかった場合、フリーのワーカーを取得するまで待つのではなく、即座にクライアントにエラーを返してしまいます。

アクセス数が50 request/secぐらいまではこの設定で問題なかったのですが、150 request/secを超えたあたりから、フリーのワーカーが取得できないというエラーが頻発するようになりました。おそらく、ワーカーの生成が間に合ってないために発生していたものだと思われます。

なので、ワーカーの生成を2秒ほど待つように設定しました。

ProxyRequests Off
ProxyPass / balancer://cluster/ timeout=2

<Proxy balancer://cluster/>
BalancerMember http://192.168.1.1/ loadfactor=10
BalancerMember http://192.168.1.2/ loadfactor=10
</Proxy>

こう設定したことで、ワーカーが取得できないためにクライアントにエラーが返ることは無くなりました。

次回はBalancerMemberに渡すパラメーターについて解説します。

このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。

Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。

そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。

まず、mod_proxy_balancerの設定から。よく、httpd.confでこのようになっている設定例を見かけます。

ProxyRequests Off
ProxyPass / balancer://cluster

<Proxy balancer://cluster>
BalancerMember http://192.168.1.1 loadfactor=10
BalancerMember http://192.168.1.2 loadfactor=10
</Proxy>

こう設定した場合、http://example.com/でアクセスした場合は問題なくリクエストが行われたのですが、http://example.com/dir/などサブディレクトリにアクセスした場合、403 forbiddenが返ってきてしまいました。その時のerror_logには以下のように書かれていました。

[Fri Dec 30 22:25:00 2005] [warn] proxy: No protocol handler was valid for the URL /dir/. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

エラーを文字通り受け取れば、mod_proxy_httpなどのmod_proxyのサブモジュールがロードされていないためにエラーが起こっていると思ってしまいがちですが、そうではないのです。（実際にこのエラーが起きたときにはmod_proxy_httpなどはロードされていました）

原因は「ProxyPass /」ディレクティブが、URLに含まれるすべての「/」に適用されてしまうために、このようなエラーになってしまうと言うことでした。

httpd.confの設定を以下のように変えることで解決しました。

ProxyRequest Off
ProxyPass / balancer://cluster/

<Proxy balancer://cluster/>
BalancerMember http://192.168.1.1/ loadfactor=10
BalancerMember http://192.168.1.2/ loadfactor=10
</Proxy>

次回はProxyPassディレクティブに渡すパラメーターについて解説します。