Varnishの使い方(Using Varnish)を和訳しました

  5 Responses to “Varnishの使い方(Using Varnish)を和訳しました”

1. 

   heppoko says:

   2011/05/02 at 8:39 AM

   すばらしい！
   varnish の資料は少ないので、大変助かります。

   ご存知なら教えて頂きたいのですが、client host1:80(varnish) host2:80(apache WebDav) にて destination を書き変えたいのですが、良い方法はないでしょうか？
2. 

   trout says:

   2011/05/02 at 10:06 AM

   どういたしまして、少しでもお役に立てれば幸いです。

   destinationを書き換えたいというのがちょっとよくわからないのですが（アドレスの書き換え？）
   URLやホストなどの条件でサーバを切り替えたり、
   varnish->バックエンド(ここではhost2)へのリクエストヘッダを書き換えることは可能です。
   apacheのrewriteみたいのもできます。

   もしバックエンドの切り替えであれば
   「高度なバックエンドの設定(Advanced Backend configuration)」
   のところを参照していただければわかると思います。

   もし、僕が勘違いしてるようであればもうちょい詳しく教えていただけるとありがたいです。

   でわでわ
3. 

   hello world says:

   2011/08/18 at 2:36 AM

   和訳、お疲れ様でした！とても参考になります。

   varnishについてお詳しそうなので、質問させてください。
   複数台の構成にしてキャッシュを共有したいと思っているのですが…つまりこんな感じの事です。

   Client1 Client2
   ↓ ↓
   varnish1 ⇔ varnish2
   ↓ ↓
   backend1 backend2

   ・varnish1とvarnish2は別サーバです。
   ・varnish1にキャッシュがなければ、varnish2にキャッシュがあるかを確認しにいきます。(varnish1と2でキャッシュを共有しているような状態です)

   ご存知でしたらぜひご教授頂きたいです。よろしくお願いします。
4. 

   trout says:

   2011/08/18 at 4:12 AM

   Versionも3になったのでちょっと書きなおさないとと思っています。
   ありがとうございます

   さて質問についてですが
   ちょいと共有の意味がわからなかったので
   同じキャッシュを共有しているパタンと
   複数台のVarnishでクラスタ化してキャッシュを共有するパタンについて説明します
   ちなみにVarnishにはsquidでいうsiblingの機能はありません

   ■重複したキャッシュを持つ場合
   それぞれのバックエンドにもう片方のvarnishを追加指定することです
   イメージ的には
   client->varnish1(miss)<->varnish2(hit)
   client->varnish1(miss)<->varnish2(miss)<->backend
   ってなかんじです
   ただこの場合ループしないようにbereq.http.*変数を設定することで方系のVarnishのreq.http.*に同じ名前があれば問い合わせしないでbackendに行くといった感じです。(bereq.http.X-REQFROM-VARNISHとか適当に)
   この場合の利点として
   両方共だいたい同じキャッシュを持つので方系死んだ時でもVarnishに余力があればbackendに大量のアクセスで死ぬみたいなことは起こりづらい事が挙げられます
   逆に欠点として設定が複雑になりやすいこととキャッシュ効率が悪い、またVarnishからVarnishに問い合わせをする場合のNWのトラフィックに注意といった感じです。
   もしVarnishが4台以上の場合はVarnishからVarnishの問い合わせにHashDirectorを使うことでバックエンドの問い合わせを更に減らせます
   仮に全てキャッシュできるとした場合にバックエンドに問い合わせする最大回数は以下のとおりです
   2台Random=1 2台Hash=1
   3台Random=1 3台Hash=1
   4台Random=2 4台Hash=1
   5台Random=2 5台Hash=1
   6台Random=3 6台Hash=1

   ■複数のVarnishでクラスタ化
   Varnishだけではなくなりますが・・・
   Client<->[サーバA/B]Nginx(port80)<->[サーバA/B]Varnish(port81)<->backend
   こんな感じの構成ですNginx側でHashを行い振り分けを行う方法です
   利点として複数のVarnishが載ってるサーバで1グループのキャッシュを持つので
   システム全体でのキャッシュサイズが大きくなります。
   欠点としてVarnishが落ちた場合backendへの負荷が大きくなる
   2台構成の場合でそのサーバでのキャッシュのヒット率は最大50％になることが注意点です
   Nginxで振り分けするので実際同じサーバにあるVarnishと別サーバのVarnishの振り分け比率はだいたい半分ずつになります。
   クラスタ全体でのヒット率は向上しますがより多くのトラフィック（均等に振り分けされた場合で＋50％）が走るためNW構成に注意が必要です。

   また振り分けにVarnishを使ってdirectorにHashを使う方法もあります
   client->Varnish(port80:pass:HashDirector)->Varnish(port81:lookup:randomなど)->backend
   この場合の注意としてVarnishのpipeの除く動作は基本ストアアンドフォワードなので
   port80のVarnishで想定されうるProxyするサイズ以上のキャッシュサイズを確保しないと503になります。

   あとはいい感じにハイブリッドにする方法もありますね

   うーん正直図にしないとわからんですねこれ・・・
5. 

   hello world says:

   2011/08/20 at 1:17 AM

   早速の返答と複数のケースの解説、どうもありがとうございます。

   共有というのは、varnish1とvarnish2というサーバがあって、varnish1とvarnish2はお互いにキャッシュを補完し合うという意味合いでした。つまり、
   ・varnish1にキャッシュがある　→　あればそのままクライアントにキャッシュを返します。
   ・varnish1にキャッシュがない　→　varnish2を見に行ってあれば、クライアントにキャッシュを返します。
   ・両方になければバックエンドに処理を渡します。
   というようなことです。そのようにできればキャッシュ効率は最高だろうなと思いまして。
   説明が足りなくてすいません。

   「重複したキャッシュを持つ場合」のケースはルールを設定して追加していくうちに混乱してハマリそうな予感がします（汗）
   「複数のVarnishでクラスタ化」のケースは、なるほど。こんなやり方もあったのかと唸りました。
   ウェブアプリの提供時にフロントにNginxを配置することは検討していることもあって、嬉しいアイデアです。

   ちょっと、頭の中整理しきれていませんが、取り急ぎの返信でした。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。