Varnish を CouchDB 用のReverse Proxyに活用する。

ご無沙汰しております、生きています。

さて、CouchDB 1.0 がでて、incremental replication もだいぶ安定した感があるので、自宅の CouchDB でロードバランスしたくなりました。

Apache mod_proxy_balancer という手もあるのですが、Incremental (MapReduce + Replication) という環境では、High Performance な Caching Proxy になる Varnish という選択肢もおもしろそうなので試しています。

構成

• CPU: Opteron Dual Core 1.8 GHz
• Memory: 8GB
• Servers: http://relax:5984/, slave: http://relax:15984/ (master と slave は同じサーバー上。ただし、ディスクは別)

で twitter のタイムラインをバックアップしている http://www.yssk22.info/relax/_design/mytweets/_list/timeline/by_date?descending=true のデータを対象にします。1つのドキュメントは 1.5KB ぐらいです。

CouchDB の設定

init.d の起動スクリプトに Incremental Replication を仕込んでおきます。これ忘れると、うっかり再起動したときにレプリケーションが止まっている、とかそういう感じになるので注意。

#!/bin/sh

/opt/relax/master/couchdb/pro-1.0.0/etc/init.d/couchdb $@
/opt/relax/slave/couchdb/pro-1.0.0/etc/init.d/couchdb $@

start_replication () {
      sleep 1  # wait for slave waking up
      curl -X POST --data '{"source": "http://127.0.0.1:5984/relax", "target": "http://127.0.0.1:15984/relax", "continuous" : true }' http://localhost:5984/_replicate
} 

case "$1" in
   start)
      start_replication
      ;;
   restart)
      start_replication
      ;;
   *)
      ;;
esac

Varnish の設定

初心者なので、 vcl にこんな感じで とりあえず GETとHEAD をロードバランスしてくれればいいや、と。
まずは、効果測定のために、Varnish キャッシュを無効にしておきました。

backend default {
.host = "127.0.0.1";
.port = "5984";
}

backend slave {
.host = "127.0.0.1";
.port = "15984";
}

director couchdb round-robin {
   { .backend = default; }
   { .backend = slave; }
}

sub vcl_recv {
    if (req.request != "GET" && req.request != "HEAD") {
        return (pass);
    }
    set req.backend = couchdb;
    return (pass);
}

ab してみる

クライアントには iMac (Core2Duo 3.02GHz, 4GB Memory) を使います。

まずは、直接CouchDBにある 1 tweet を直接たたく感じで。

$ ab -n 1000 -c 30 "http://relax:5984/relax/fffdcaf2b6bafa2f6a39a513d48d5e45"

Concurrency Level:      30
Time taken for tests:   2.431 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      1687000 bytes
HTML transferred:       1452000 bytes
Requests per second:    411.42 [#/sec] (mean)
Time per request:       72.918 [ms] (mean)
Time per request:       2.431 [ms] (mean, across all concurrent requests)
Transfer rate:          677.80 [Kbytes/sec] received

• c 30 が正しいかはともかく(もうちょっと多くてもいいかな...)、こんな感じです。

Varnish 経由でたたいてみます。

$ ab -n 1000 -c 30 "http://relax:6081/relax/fffdcaf2b6bafa2f6a39a513d48d5e45"

Concurrency Level:      30
Time taken for tests:   1.671 seconds
Complete requests:      1000
Failed requests:        7
   (Connect: 0, Receive: 0, Length: 7, Exceptions: 0)
Write errors:           0
Non-2xx responses:      7
Total transferred:      1747622 bytes
HTML transferred:       1445098 bytes
Requests per second:    598.52 [#/sec] (mean)
Time per request:       50.123 [ms] (mean)
Time per request:       1.671 [ms] (mean, across all concurrent requests)
Transfer rate:          1021.48 [Kbytes/sec] received

ちょっと効果がでたようです。beam.smp 自体は concurrent に動いてはいるんですけどね。いろんな作用のせいで(ちょっと詳しく見る必要ありそう)、単体時が 500 rec/sec, RB時が 600 rec/sec ぐらいになっていました。

ab してみる (2)

次に MapReduce View。これは更新しながらはからないと余り意味がないのですが、とりあえず、tweetを日付順に並び替えて、10件とるURIをたたきまくります。

CouchDB 直接。

$ ab -n 1000 -c 30 "http://relax:5984/relax/_design/mytweets/_view/by_date?limit=10&descending=true"

Concurrency Level:      30
Time taken for tests:   13.289 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      27286000 bytes
HTML transferred:       27082000 bytes
Requests per second:    75.25 [#/sec] (mean)
Time per request:       398.667 [ms] (mean)
Time per request:       13.289 [ms] (mean, across all concurrent requests)
Transfer rate:          2005.17 [Kbytes/sec] received

Varnish 経由。

$ ab -n 1000 -c 30 "http://relax:6081/relax/_design/mytweets/_view/by_date?limit=10&descending=true"

Concurrency Level:      30
Time taken for tests:   10.043 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      27377000 bytes
HTML transferred:       27082000 bytes
Requests per second:    99.57 [#/sec] (mean)
Time per request:       301.293 [ms] (mean)
Time per request:       10.043 [ms] (mean, across all concurrent requests)
Transfer rate:          2662.06 [Kbytes/sec] received

こちらも若干改善された感じ。全部メモリにのっちゃうのでそんな変わらないかなー、と思いきや。

ab してみる (3)

最後に、HTMLレンダリングのURIもやってみます。これは毎回JSプロセスがCGI的に動くので、どうでしょう。

$ ab -n 1000 -c 30 "http://relax:5984/relax/_design/mytweets/_list/timeline/by_date?limit=10&descending=true"
Concurrency Level:      30
Time taken for tests:   40.317 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      7127000 bytes
HTML transferred:       6942000 bytes
Requests per second:    24.80 [#/sec] (mean)
Time per request:       1209.498 [ms] (mean)

割とがんばっている気がします。JSでHTMLをレンダリングするって結構重い処理なので。。。(pure JS実装のtemplate engineしかないもので。。。

Varnish版。

$ ab -n 1000 -c 30 "http://relax:6081/relax/_design/mytweets/_list/timeline/by_date?Concurrency Level:      30
Time taken for tests:   34.386 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      7217500 bytes
HTML transferred:       6942000 bytes
Requests per second:    29.08 [#/sec] (mean)
Time per request:       1031.594 [ms] (mean)
Time per request:       34.386 [ms] (mean, across all concurrent requests)
Transfer rate:          204.97 [Kbytes/sec] received

あんまりかわらなくなっちゃいました。

じゃあ、Varnish Cache を有効にしてみようか。

vcl_recv で最後に lookup します。尚、キャッシュはデフォルトの1GB。

sub vcl_recv {
    if (req.request != "GET" && req.request != "HEAD") {
        return (pass);
    }
    set req.backend = couchdb;
    return (lookup);
}

測定

$ ab -n 1000 -c 30 "http://relax:6081/relax/_design/mytweets/_list/timeline/by_date?descending=true"

Concurrency Level:      30
Time taken for tests:   1.673 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      196220832 bytes
HTML transferred:       195932256 bytes
Requests per second:    597.55 [#/sec] (mean)
Time per request:       50.205 [ms] (mean)
Time per request:       1.673 [ms] (mean, across all concurrent requests)
Transfer rate:          114504.36 [Kbytes/sec] received

20倍ぐらい高速になりました。 tweet 自体は cron で 10 分ごとにまとめてとってきてCouchDBにつっこんでいるので、そのタイミングで Varnish Cache を破棄させるもよし、 CouchDB の update notirifcation を使って Cache を破棄させるもよし。

なんかこの組み合わせはすばらしい気がする。

もう少し気になること。

master -> slave 構成ですが、逆向きのincremental replicationも起動時に仕込んでおけば、POST, PUT もVarnishにくわせることができるんじゃないかと。