Varnish6.0.0がリリースされました。[changelog] [公式のリリース文] [パッケージDL] [ソースDL]
今回のリリースはメジャーバージョンアップということで機能追加や累積バグFixなど来ています。
目玉機能はUnixDomainSocket(UDS)対応で、個人的に注目しているのがshard directorにおけるlazyモード追加です。
また新しいVCLバージョン(4.1)も追加されていますが、既存が使えなくなったわけではないので影響は少ないでしょう。
なお、アップデートする場合はいくつか注意が必要な点があります。
現状で適用する場合は十分に注意検討する必要がある環境
http/2環境
h2利用時にスレッドがリークしているような動きをしています。(#2623)
最初は自分のテスト用環境だけかなと考えていたんですが、他に踏んでる人を確認したので現状のままでh2を有効にするのはかなり注意が必要です。
h2を使いたいのであれば、きちんと検証して自環境で起きないことを確認しつつ行うか、既存バージョンのままで使いつつFixを待つと良いと思います。
ただしh1のみの場合は現状問題ないため、h2を使わないのであればバージョンアップをしても良いかと思います。
公式パッケージの対象バージョンが少なくなった
公式で提供してるパッケージの対象OSは以下の通りです
– RHEL7(CentOS7)
– Debian9
– Ubuntu16.04
Ubuntu14.04やRHEL6は対象外となりましたので注意が必要です。
ただ、これはあくまで対象バージョンを絞ったというだけなので、自前でpkg-varnish-cacheを利用してパッケージを作って適用は可能です。
VMODを利用している場合
VMOD側で対応しないといけない変更が入っているため、いろんなVMODを利用している場合は対応状況を確認したほうが良いです。
必要な変更はたいしたことないので、メンテされてるものについては対応されるんじゃないかなとか思います。
なお、VSMに直接つなぐアプリについては5.2.0のときのVSM/VUTインタフェース変更に対応できていればほぼ動くと思います。
一部定数と戻り値の型が変わったものがあるためそこを使っていて運が悪いと踏むかもしれません。
VCL
vclを記述する際には、先頭に「vcl 4.0;」と記述していたかと思いますが、今回「vcl 4.1;」が追加されました。
既存の4.0が使えなくなったわけではないため、そのまま動かすことも可能ですし、大抵の場合は先頭行だけ4.1に書き換えても（大抵の場合は）動くでしょう。
あとで紹介するUDSは4.1のみでサポートしている記法が必要なので、もし使う場合は4.1に変更しましょう。
またincludeですが親のVCLバージョンより小さい場合は可能です。
つまり
| parent vcl ver | child vcl ver | result |
|---|---|---|
| 4.0 | 4.0 | OK |
| 4.0 | 4.1 | NG |
| 4.1 | 4.0 | OK |
| 4.1 | 4.1 | OK |
こんな感じです。
VCLの記載の仕方は環境それぞれだとおもうのでなんともいえないのですが、
default.vclを起点として、includeしていくやり方であればdefault.vclを一旦4.1にしておくと良いのかなと思います。
とはいえ、4.0から4.1へのアップデートはそんなに難しくないのでやってしまったほうがいいんじゃないかなとは思います。
VCL変更点
4.0での変更点と4.1での変更点があります。
まずは共通の変更点から
変更点(4.0/4.1共通)
return(fetch)がvcl_hitで使えなくなりました
個人的にはまだ残っていたのかといった感じですが（結構前からdeplicatedになってた）
return(miss)を使いましょう
req.storage / hash_ignore_busy / hash_always_missをclientスレッド側でアクセスできるようになりました。
obj.storageが追加され、vcl_hit/vcl_deliverでアクセスできるようになりました
restart時の動作が変わりました
req.restarts,xid以外のすべてのreq変数は維持されます。
restartを利用している場合は動作の確認をしたほうが良いでしょう。
vcl_recvでもreturn(restart)が呼べるようになりました
変更点(4.1のみ)
backendの定義に.pathが追加
あとで触れるUDSで使うパスです。
.hostと同時に定義することは出来ません。
local.socketの追加
接続に利用したソケットの名前を返します。
-afoo=:81と名前が指定されてる場合はfooを返しますが、もし定義されていない場合は自動的につけられた名前（a0,a1）が返却されます。
local.endpointの追加
接続に利用したソケットの定義を返します。
-afoo=:81の場合は:81が返却されます
sess.xidの追加
セッションのユニークなID(xid)を返します。
今まで使用していたreq.xid/bereq.xidはそのリクエスト、バックエンドリクエストを示すものでした。
しかしKeepaliveやHTTP/2では1セッション中に複数のリクエストが含まれます。
* << Session >> 433160262 - Begin sess 0 PROXY - SessOpen *** - Proxy *** - Link req 423002616 rxreq - Link req 423002617 rxreq - Link req 423002618 rxreq - Link req 423002619 rxreq - Link req 423002620 rxreq - ReqAcct 72 22 94 1251 6 1257 - End
これはとあるHTTP/2.0でのログの抜粋ですが、これが示しているのは
xid:433160262のセッション(sess.xid)にxid:423002616～423002620のリクエスト(req.xid)がぶら下がっているということです。
今回sess.xidがvcl中から簡単に取れることで、異なるリクエスト中でも同一セッションであることがわかるので、なにかに使えるかもしれないです（ぱっと思いつかないですが・・）
resp.do_esiの追加
beresp.do_esiの指定でフェッチ時にパースした場合でも無効にすることができます。
vcl_deliver/vcl_synthで呼び出し可能です。
(req|bereq|beresp).protoがreadonly
そんなに変更することもなかったと思いますが.protoがreadonlyになりました。
req.esiが削除された
まぁ使う人はそんなにいないかと・・・beresp.do_esiを使いましょう
beresp.storage_hintが削除されました
beresp.storageで代用できます。
例えば今まで
set beresp.storage_hint = "foo";
としていたのであれば
set beresp.storage = storage.foo;
と変更すればよいです。
beresp.backend.ipがが削除されました
IPアドレスが0.0.0.0:0のものはUDS経由のものになります。
Unix Domain Socket(UDS)対応
上下流どちらも対応しています。
これを利用することにより高CPS環境において、特に同一サーバに置いてることがほとんどだと思われるTLS終端を行うミドルウェアとの通信をより効率的に行えるようになります。（上流側）
なお、今回の例ではNginxを組み合わせてやってみます。
LISTEN側でUDSを使う場合
起動パラメータの-aで以下のような指定をします
-a /var/run/varnish-uds.sock,user=vcache,group=varnish,mode=666
今回はproxyプロトコルを指定していませんが指定できます。(PROXYを追加しましょう)
また今回はお手軽にNginxとつなぐために666にしていますが、適切な設定にするべきでしょう。
Nginx側
upstream backend {
server unix:/var/run/varnish-uds.sock;
}
server {
listen 80 default_server;
listen [::]:80 default_server;
location / {
proxy_pass http://backend;
}
...
}
これだけです。
なお、LISTEN側でUDSを使う場合はVCL4.1が必須です。
が、現状試してる限りでは起点となるvcl(default.vcl)が4.1であればinclude先は4.0でも平気な動きをしています。
しかし、ドキュメント上は
When UDS listeners are in use, VCL >= 4.1 will be required for all VCL programs loaded by Varnish.
と記述されており、もしかしたら塞がれる可能性もありますので、UDSを使う場合はすべてのVCLを4.1にするのが無難でしょう。
なお、UDSは当然ながらIPアドレスはなく、UDS経由のアクセスは0.0.0.0:0として扱われます。
なので、client.identity(デフォルトではclient.ipが使われる)を使って振り分けを行う場合は常に同一backendが選択されるので注意が必要です。
適切に修正を入れるか、そもそも上流はPROXYプロトコルが使えるミドルウェアにするなどの対策が必要でしょう。
バックエンド側でUDSを使う場合
すごく単純です
Nginx側
server {
listen unix:/var/run/nginx-uds.sock;
access_log off;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
}
Varnish側
vcl 4.1;
backend default {
.path = "/var/run/nginx-uds.sock";//絶対パス
}
これだけです。
特に難しくないと思いますが、1点注意なのがbackend内での.pathプロパティはvcl4.1のみなので4.0だと出来ません。
なおListenの時と違いバックエンドのみ使用する場合は4.0混在でも動きます。とはいえ4.1の書き換えは難しくないので書き換えたほうが無難でしょう。
その他新機能・変更
varnishncsa
制御文字・バイナリを含む可能性があるタグの-Fを拒否するようになりました
対象はH2RxHdr H2RxBody H2TxHdr H2TxBody Debug HttpGarbage Hashですが、たぶん使ってる人はいないかなと
起動パラメータの変更
esi_iovsの追加
ESI処理で使うiovec構造体の割り当て数ですが通常の場合はいじる必要がありません。
ESIを使っていてどうしてもtuneしたい場合はsystemcallでwritevの実使用数をみながら調整するとよいでしょう
またこの値を変更する場合はworkspace_threadを同時に調整する必要があるでしょう（割り当て元がworkspace_threadからなので）
h2関連パラメータの追加
h2_header_table_size
h2_max_concurrent_streams
h2_initial_window_size
h2_max_frame_size
h2_max_header_list_size
このあたりはh2のRFCを読んでもらえればわかるかなって感じです。
ちなみにh2_max_concurrent_streamsは100なんですが、chromeのストリームはデフォで1000なので、そのあたりで気になる人もいるかもしれないです。（とはいえそんなに弄る必要ないと思います）
feature_bitの追加(http_dete_postel)
日付の形式はrfc7231#section-7.1.1.2で定義されてるんですが、たまにこれに準拠しないやんちゃなDate,Last-Modified,Expiresを返してくるサーバがいます
Fri, 2 Mar 2018 14:26:02 GMT (まちがい) Fri, 02 Mar 2018 14:26:02 GMT (ただしい)
この間違いのパタンを許容するようになります
有効にしたい場合は-p feature=+http_dete_postelにします。
個人的にはオリジン側直したほうがよいかなーとは思いますが・・・
cli_bufferの削除
まぁ以前からアナウンスあったので・・・
カウンタの追加
cache_hit_grace
そのまんまですがgrace状態でレスポンスできた件数になります。
パフォーマンスを稼ぐ場合は一旦古い状態のキャッシュを返しつつ裏で更新リクエストを行うのを重視しますが（うまくいけばキャッシュ更新時に遅くならない）
このカウンタを見てチューニングを行うことが出来るかなとも思います。
n_lru_limited
nuke_limitに達した件数を示します。
当然ですがストレージがいっぱいの状態で新しいオブジェクトをキャッシュを行おうとする場合は古いものを押し出す必要があります。（LRUです）
Varnishではこの処理をNukeと呼んでいますが、実はこの処理にはnuke_limitというパラメータがあり、一つのオブジェクトを確保するためにNukeして良いオブジェクトのLimitを定義しています。
オブジェクトサイズがだいたい似たようなところならデフォルト値(50)でも問題ないのですが、平均50KBのところに10MBのでかいオブジェクトがたまにやってくるとかだと足りないことがあります。
当然Limitを超えた場合はストレージを確保できないためエラー(503)となるのですが、問題はストリームをしている場合です。
ストリームでレスポンスをしている場合は、当然ながらオリジンから帰ってきたレスポンスコード(200)を返してしまっているので503を返すことができません。
そのため200なのにレスポンスボディが中途半端なサイズになるということがあるのですが（割とmlとか見てるとそれっぽい問い合わせ多い）
このカウンタを見ることでそのような状態に陥ってることがわかります。
とりあえず1でもあがるようであれば、nuke_limitを引き上げる、ストレージの見直しをする（サイズあげるとか、ある程度のサイズ毎に分けてしまうとか）とかすると良いと思います。
vmod_directors
shard directorにかなりの修正が入っています。
shard_param
新しくshard_paramというクラスが定義されています。
基本的に今までのshardの各種パラメータ(rampupとか)が定義されており、単純に外出しにされたものです
使い方は
sub vcl_init{
new vd = directors.shard();
vd.add_backend(hoge);
new p = directors.shard_param();
p.set(by=URL, warmup=0.7);
vd.associate(p.use());
}
や
sub vcl_init{
new vd = directors.shard();
vd.add_backend(hoge);
new p = directors.shard_param();
p.set(by=URL, warmup=0.7);
}
sub vcl_backend_fetch{
set bereq.backend=vd.backend(param=p);
}
こんな感じです。
ハッシュアルゴリズムについて
今までハッシュアルゴリズムを選択できたのですが(SHA256(default),CRC32,RS)
これがSHA256だけになりました。これに伴いalgを指定できていたメソッドにおいてalg引数が削除されました。
しかし、わざわざSHA256以外を使ってる人も少ないと思うのでそこまで影響ないと思います。
引数がなくなる影響を受けるのは.reconfigureと.keyになります。
resolve={now,lazy}の追加
個人的に注目している機能です。
lazyモードは実際にバックエンドへの接続を作るタイミングで解決されるものです。
これが何が嬉しいのかというと、Directorを入れ子にすることができます。
例えばfallbackと組み合わせてdirectorが全滅したらfallbackするみたいなのも書けます。
probe healthcheck {
.url ="/check";
.timeout = 1s;
.window = 4;
.threshold = 2;
.interval = 1s;
}
backend ws01 {.port="80";.host = "XX";.probe=healthcheck;}
backend ws02 {.port="80";.host = "YY";.probe=healthcheck;}
sub vcl_init {
new sdp = directors.shard_param();
sdp.set(warmup=0.5, healthy=ALL);
new sd1 = directors.shard();
sd1.associate(sdp.use());
sd1.add_backend(ws01);
sd1.reconfigure();
new sd2 = directors.shard();
sd2.associate(sdp.use());
sd2.add_backend(ws02);
sd2.reconfigure();
new fb = directors.fallback();
fb.add_backend(sd1.backend());//lazy
fb.add_backend(sd2.backend());//lazy
}
sub vcl_recv {
set req.backend_hint = fb.backend();
return(pass);
}
サンプルでshardに登録してるバックエンドはそれぞれ一つですが感覚は掴んでもらえるかと思います。（ついでにshard_paramもサンプル的に入れてみました）
vmod_std
std.log/syslogにおいてworkspace枯渇した場合でもfailしないようになりました
vmod_unix
今回追加されたvmodです
接続してきたプロセスのuser/group/uid/gidを取得できます。
厳密にガードをかけたいときに使うとよいかもしれないです。
man vmod_unixそのままですが
sub vcl_recv {
# Return "403 Forbidden" if the connected peer is
# not running as the user "trusteduser".
if (unix.user() != "trusteduser") {
return( synth(403) );
}
# Require the connected peer to run in the group
# "trustedgroup".
if (unix.group() != "trustedgroup") {
return( synth(403) );
}
# Require the connected peer to run under a specific numeric
# user id.
if (unix.uid() != 4711) {
return( synth(403) );
}
# Require the connected peer to run under a numeric group id.
if (unix.gid() != 815) {
return( synth(403) );
}
}
こんな感じです
vmod_proxy
今回追加されたvmodです
Proxy Protocol v2にはType-Length-Value(TLV)というフィールドに例えばどんなCipherを使用しているかみたいな情報を埋め込むことが可能です。
残念ながらHitchはalpn(PP2_TYPE_ALPN)しか埋め込んで来ないようなので、フル機能を使いたい場合はHAProxyの比較的新しいバージョンを使う必要がありますが
何かしら情報を取得してログに出力したい場合は有用だと考えています。
また、残念ながら取れる値は固定になっているので、カスタムTLVの範囲へは現状アクセスできません。（NLBのVPCエンドポイントIDとかl）
とはいえコードを見る限りでは対応は容易なのでp-rしてみるのもおもしろいかもしれないです。
使い方は単純で
vcl 4.1;
import proxy;
import std;
sub vcl_recv{
if(proxy.alpn() == "http/1.1"){
//プロトコルはまぁreq.protoで取れるんで適切ではないかもですがサンプルとして
...
}
}
こんな感じです
VSL
ReqAcctのバイト数が正確になりました
プロトコルのオーバーヘッド分(chunkedのとか)は今まで入ってませんでしたが、OSから報告される値を使うように変更したので正確になりました。
バグ修正
多くのバグ修正がされているのですが、その中でも特筆したほうがよいものに触れます。
max_restartsの取扱い
return(restart)を行った際のチェックの不備で、max_restrtsで指定した回数より1回少ないrestartでlimitになっていましたが、修正されてmax_restartsの指定した数return(restart)ができるようになりました。
