varnishについて

みなさん、こんにちは。
2010年9月入社のUDAGAWAです。

今回は、reverse proxyのvarnishに関して記事を
書かせていただきます。

■varnishとは
高性能HTTPアクセラレータです。
同じような機能を持ったsquidより10～20倍高速だということが
売りのひとつだそうです。

■背景
Amebaの画像配信システムは、reverse proxyとして
squid2.7 STABLEのCOSSを使ったシステムを利用しています。

squid2.7自体が古いバージョンなので、できればバージョンアップしたいところ
なのですが、現状 squid3系からはcossが使用できないこともあり
varnishを検証しておこうと考えたのがきっかけです。


■テスト環境
CentOS5.5
Kernel 2.6.18-194.3.1.el5
Varnish 2.1.3

■インストール

wget http://jaist.dl.sourceforge.net/project/varnish/varnish/2.1.3/varnish-2.1.3.tar.gz
tar zxvf varnish-2.1.3.tar.gz
cd varnish-2.1.3
sh autogen.sh
./configure --prefix=/usr/local/varnish
make
make install

■設定
設定ファイルの書き方については多々あり、他の記事でも
紹介されているので、そちらを参考いただければと思います。
ほとんど、squidと同じことができます。

主な部分としては・・・

・backendのサーバへの分散

Directorを使うことによって、backendのサーバにround-robin、DNS、random
での振り分けができます。

director hogehoge round-robin {
{
.backend = XXX.XXX.XXX.XXX;
}
# server2
{
.backend = XXX.XXX.XXX.XXX;
}

・backendサーバのhealth check
healthcheckについても簡単に設定できますが、.probeの記述がないと
backendのサーバの切り離しができないので注意が必要です。

backend hogehoge-01 {
.host = "XXX.XXX.XXX.XXX";
.host_header = "hogehoge.jp";
.port = "80";
.probe = {
.url = "/hogehoge_health.jpg";
.timeout = 0.3 s;
.window = 8;
.threshold = 3;
}

・サブルーチンを使いこなす
backendのサーバへの分散ルール&アクションの定義です。

複数のアクションがありますが、たとえばドメインごとに
分散ルールを設定することもできます。

リクエストされたURLが、hogehoge.jpなら、backendサーバ hogehoge01に渡す場合

sub vcl_recv{
if(req.url == "hogehoge.jp") {
set req.backend = hogehoge01;
}

■設定(その他)
・sycctl.conf
公式ドキュメントで紹介していますが、sysctl.confの
設定を変えることを推奨しています。

vi /etc/sysctl.conf
net.ipv4.ip_local_port_range = 1024 65536
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_fin_timeout = 3
net.core.netdev_max_backlog = 30000
net.ipv4.tcp_no_metrics_save=1
net.core.somaxconn = 262144
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

■起動時のオプション

/usr/local/varnish/sbin/varnishd -f /usr/local/varnish/etc/varnish/default.vcl -s malloc,8G -T 127.0.0.1:2000 -a 0.0.0.0:8080 -s "file,/cache/varnish_storage.bin,1000M"

-f 読み込む設定ファイルの指定
-s malloc,1G varnisnがコンテンツキャッシュで使用するメモリサイズ
-T 127.0.0.1:2000 varnishのテキストベース管理インターフェースの接続ポート
-a 0.0.0.0:8080 varnishが受け付けるHTTP REQUESTのポート
-s ストレージサイズの指定(COSSみたいなもの)

■ベンチマーク
abbenchを使って、ある画像に10000回のリクエストを発行しました。
結果からいってしまうと、squidより早いですね。

・cacheなし
Time per request: 182.502 [ms] (mean)
Percentage of the requests served within a certain time (ms)

50% 117
66% 137
75% 153
80% 167
90% 229
95% 313
98% 348
99% 618
100% 1052 (longest request)

・squid
Time per request: 0.211 [ms] (mean, across all concurrent requests)
Percentage of the requests served within a certain time (ms)
50% 27
66% 27
75% 27
80% 29
90% 200
95% 299
98% 618
99% 718
100% 773 (longest request)

・varnish
Time per request: 0.152 [ms] (mean, across all concurrent requests)
Percentage of the requests served within a certain time (ms)
50% 150
66% 160
75% 166
80% 169
90% 177
95% 181
98% 185
99% 188
100% 270 (longest request)

■結果
10倍とまではいきませんが、squidより早いというのは本当みたいです・・・
若干ログの出力部分等で、squidに劣る部分がありますが
なんとなく使えそうな感じがします。

4月末に新しい画像システムを構築するので、その際のreverse proxyに
使用してみようかと考えています。そこで得たtipsなどは
また後ほど紹介させていただきたいと思います。

ちなみにcache領域(storage)の再構築にかかる時間が未検証なことと
squidのようにcacheオブジェクトのサイズで格納先を変えることが
できないようなので、引き続き調査します。

■おまけ。
squidでreverse proxyを運用するにあたって、いくつか得たTipsも簡単に紹介します。

・COSSでのcache領域は、SSDがよい。
COSSで使用するcache領域は、SSDを使用することで大幅にパフォーマンスがUPします。
Amebaでは、CrucialSSD 256GBを使用しています。

・swapに気をつけましょう。
cacheするオブジェクトが多ければ多いほど、squidで明示的に確保しているメモリ以外に
オブジェクトを展開するためにメモリを使用します。
そのため、たびたびswapが発生することもあります。

メモリを増設するのもいいですが、swapの開始閾値を変更するのもありです。

cat /proc/sys/vm/swappiness
60
echo 10 > /proc/sys/vm/swappiness

・refresh-patternを有効に使う
refresh-patternの設定を有効に使うことによって、Pragma:no-cache、Cache-control:no-cacheなどの
リクエストを無効化することができます。