Engineering

Varnishでテストコードを書こう!~実践編~+Bodyを読もう!

Varnishでテストコードを書こう!~実践編~+Bodyを読もう!

こんにちは、Service Reliabilityチームのいわなちゃんさん(@xcir)です。
先日、社内で行われたチューニングハッカソンではチームマイナス5500万としてVarnishをいれる簡単なお仕事をしてきました。
このエントリは GREE Advent Calendar 2014 17日目の記事です。

以前とある勉強会で
「varnishtestの使い方がよくわからない」
「別のツールを使ってテストをやっている」
という話を聞きました。
varnishはvarnishtestというテストツールがありますが、あまり利用されていないようです。
原因はいくつかあると思いますが、まずは実際のテストコード(VTC)を見てみましょう。
以下は公式のrollback機能のVTCです。

https://github.com/varnish/Varnish-Cache/blob/varnish-3.0.6/bin/varnishtest/tests/c00032.vtc

VTC中にVCLが含まれているのがわかります。
varnishd本体のチェックをするのであれば特に問題はありませんが、
VCLのテストを行いたい場合にVTC中にVCLを記載するのは不都合があります。
ではどのように書けば良いのかというのを弊社でのVCLの構造を紹介しつつ一例として紹介します。

なおvarnishtest/VTC自体については以前の記事である「Varnishでテストコードを書こう!」を参照してください。

VCL構造

弊社で運用しているVarnishは100超のドメインを配信しています。
そのため、ドメイン毎にvcl_recvをやらvcl_fetchなどを書いているとキリがありません。
そこでvclの各アクションを複数定義した際に読み込み順に実行される機能(参照
とincludeを利用し、できるだけ共通化しています。

大まかに以下のように分けています。 

  • 共通設定
    • Probe(ヘルスチェック)やinline-C向けのincludeなどの共通定義
    • 正規化やPurgeなど
  • ロール別設定
    • ACLなどが同じドメインをまとめたタイプ別設定
    • 特殊な振り分けルールを持つドメイン別設定
    • どのドメインをドメイン・タイプ別設定にルーティングするかの設定

このような構造を取ることで基点となるdefault.vclと各ドメイン毎の設定量は非常に少なくなっています。
弊社で実際に稼働しているvarnishのdefault.vclは以下のような記述になっています。
(※複数のロールがあるのですべてがこの設定ではないです)

そしてドメイン・タイプ別設定は

と比較的シンプルです。
ほとんどの基本的な設定はcommon_(pre|post).vclで行っているためです。

このように共通化していると重要なのがテストになります。
特定のドメインへのACLの追加などは影響範囲はそのドメインだけとなりますが、
共通部分に機能を増やそうとすると広範囲に影響を及ぼすためテストが無いと確認は非常に厳しいです。
次に弊社でのVTCの構造と書き方を紹介します。

VTC構造

VTCも共通設定とドメイン・タイプ別設定ごとに分けてテストを行っています。
VTC中にテストを行いたいVCLを書かないようにするためにはincludeを利用しています。
実際に紹介します。

共通設定

vtcサンプル

テスト実行コマンド

このVTCでは以下のチェックを行っています。

  • clientからcookieを送った場合に消去される
  • serverからset_cookieを送った場合に消去される

ポイントはreturn(pass)を指定していることと起動パラメータでvcc_err_unref=offを指定していることです。
varnishtestは実際にvarnishを起動して行うので、当然ながらキャッシュされることが有ります。
キャッシュが前提のテストの場合であれば意識してそのように書きますが、
そうでない場合はpassを指定したほうが便利です。
vcc_err_unrefは定義されているのに使われていないbackend設定等がある場合でも警告だけで起動できるので便利です。
また、マクロ(-D)を使っているのは別パスにテストしたいVCLを用意した時のためです。
マクロはVTC内のみで利用できるため、includeした先のVCLでマクロ展開をしようとしても出来ないので注意が必要です。

ドメイン・タイプ設定

vtcサンプル

テスト実行コマンド

このVTCでは以下のチェックを行っています。

  • /img/hoge.gifにリクエストしてステータスが200
  • /hogehoge/にリクエストしてステータスが403

ここではpassのように無駄なVCLは記述しません。
単純にincludeするだけです。

まとめ

includeをうまく使うことでvarnishtestを使うことが出来ます。
純正のツールなのでテストがFailした時に何処が引っかかったのかわかるので便利だと思います。

なお、今回はvarnish3向けのvtcを書きましたがvarnish4でもほぼほぼ同じです。

varnishtestのおまけ

以前、どこかで与太話として話したのですが
varnishtestはvarnishのテスト目的じゃなくても使えます。
例えばテストでApacheを起動してlocalhost:80に接続してテストを行う場合は以下のように記述できます。

実行ログ

このような使い方も可能です。
わざわざ他のミドルウェアのテストでvarnishtestを使うこともないと思いますが、
ちょっとしたテストを行う際には便利だと思うので紹介しました。
なお、途中で引っかかった場合は以降のステップは実行されないので、
初期化・終了処理がある場合は何かしらのshellスクリプトから実行するのをおすすめします。

Bodyを読もう!

Varnishを使ってRequest/Response headerを変更することはよくあると思います。
例えば以下の様にです。


同じようにBodyにアクセスできたら非常に便利だと想像できます。
以下はあくまでイメージで実際に動作しないものですがこのような形でできると嬉しかったりします。


このような事をやっているプロダクトの代表例としてはVarnish Security Firewall(VSF)があります。
VSFではvmod-parsereqをRequest bodyにアクセスするために使用していましたがお世辞にも行儀が良いとは言えないもので、どちらかと言うと黒魔術に近いものでした。(参考
このようにRequest bodyに対して操作を行うのは非常に困難でした。
また同様にResponse bodyについても非常に困難で、本体にパッチを適用しないとアクセス出来ませんでした。

しかしVMOD作者からの要望が届いたのか4.0.xでRequest bodyに対して手軽にアクセス出来る方法が提供されました。
そして次期バージョンの4.1.x(現在trunk)ではResponse bodyに対してもアクセス出来るようになりました。

そこで今回は4.1.xベースで各bodyにアクセスする方法について紹介します。
当然ながら

  • ドキュメントに記載されていない
  • 4.1は絶賛開発中
  • 公式に明確に言及されていない(フックできるポイントを増やすとは言っている程度)
  • コアに近い機能

のため突然変更される可能性はありますが、恐らく4.2.xまでは変わっても小規模だろうと踏んでいます。

今回利用したのはRev.7f48458です
vmod自体の作り方についてはlibvmod-example(4.0)を参考にしてください。

Request bodyにアクセスする(VRB)

まずRequest bodyにアクセス出来ると何が出来るかというと
GETだけでなくPOSTリクエスト中にセキュリティ的に問題がないかのチェックが可能になったり
パースすることでPOSTのキーでキャッシュをすることが出来たりします。(あまりおすすめしませんが)
他にもサーバーが503エラーを返した時のリクエストを保存するようなモジュールを書くことが出来ます。

vrb
アクセスするのは非常に簡単で、図のようにVRB_CacheでRequest bodyをTransient storageに保存してそれを読み込む形となります。
VRB_Cacheは便利にラップされたstd.cache_req_bodyがあるので今回はそれを使っています。

今回は読み込んだResponse bodyをsyslogに飛ばすモジュールを作ってみましょう。

vmod_test.vcc

vmod_test.c

default.vcl

request


syslog

無事とれていることが確認できました。
vcl_recvでVRB_Cacheを呼び出せば(今回はstd.cache_req_bodyを利用)
vcl_deliverでもRequest bodyを取得することはできるので、先ほどの使用例にあげた503エラー時に保存することもそこまで難しくありません。
但しファイルに書き込もうとするのはパフォーマンスの劣化に繋がるので避けるのが無難です。
私であればVSLに出力して別のツールで取得して保存を行います。
VSLについてはV3向けですがこちらの記事を参照ください

Response bodyにアクセスする

Response bodyにアクセスできるポイントは2つあります。
1つはfetch時(VFP)
もう1つはクライアントにレスポンスする直前です(VDP)
これらはVarnishの機能にあるESIやgzip/gunzipでも使われています。
ESI/gzipで使われてることからわかるように、どちらも読み書きが可能です。
ではどちらを使えばよいでしょうか?それぞれには次の特徴があります。
VFPの場合はFetch時のStorageに対して読み書きするため1回のみ呼び出されます。
そのためCPUコストが高い処理はこちらでやるとよいでしょう。
VDPの場合はClientにレスポンスするたびに呼び出されます。
しかし実際にレスポンスする内容を見ることが可能です。
例えば、ESIを使っている場合はVFPでは全体像はわかりませんがVDPだと可能です。
またどちらも注意する点が2点有ります。

  • Bodyの内容によってVCL内で動作を変えることは出来ない
  • オブジェクトはgzipで圧縮されている可能性がある

VFP/VDPはどちらもフィルタを事前に登録しておき、VCLのFunctionを抜けた後に呼び出されるため、Bodyを読み込んだ結果での判定は出来ません。純粋にフィルターとして考えてください。
もちろん登録時にパラメータを渡すことは可能です。
またgzipについては今回はESIのVFP/VDPのフィルタのコードを読むと参考になると思います。

vfp-vdp
上図はVFP/VDPがどのタイミングでStorageに読み書きをしたり、ClientにResponseするかを示したものです。
着目するべきなのはVFPの一番下層のフィルタ(v1f_(eof|straight|chunked))でBackendからBodyを読み込んでStorageに格納していることです。
v1f_(eof|straight|chunked)は次のフィルタが無いためreturnしていくため、vfp_suckを呼び出した後にbodyにアクセスできます。
逆にVDPの場合は最下層のv1d_bytesでResponseしているため、VDP_Bytesを呼び出す前にbodyにアクセスする必要があります。
それでは実際にVFP/VDPを使ってResponse bodyにアクセスしてみましょう。

Response bodyにアクセスする(Fetch/VFP)

vmod_test.vcc

vmod_test.c

default.vcl

request
POSTである必要はないので普通にリクエストしてみてください。

syslog


何度かアクセスしてみてください。
VFPが呼ばれるのは一度だけだということがわかると思います。
何かしらの初期化処理が必要な場合は.initで定義したfunctionに終了処理が必要な場合は.finiを使うと可能です。
先ほども説明したとおり、BodyにアクセスできるのはVFP_Suckを呼び出した後なので注意が必要です。

Response bodyにアクセスする(Deliver/VDP)

vmod_test.vcc

vmod_test.c

default.vcl

request
POSTである必要はないので普通にリクエストしてみてください。

syslog


何度かアクセスしてみてください。
VFPと違い毎回呼び出されることがわかります。
何かしらの初期化/終了処理が必要な場合はactがVDP_INIT|VDP_FINIのときに処理できます。
VFPと違いFunctionは分かれていません。個人的にリリースされるまでに変更がある場合はここがVFPのように変更されるのでは?と考えています。
また先ほども説明したとおり、BodyにアクセスできるのはVDP_Bytesの呼出し前なので注意が必要です。

まとめ

Varnish4.1(予定)では比較的簡単にRequest/Response bodyにアクセスできることがわかりました。
これを使えばHTMLヘッダ中にjsを挿入したり、自動的に画像等のURLの難読化やショートタイムトークンの付与などが出来たりします。
またこれは私の妄想ですが、VFPで他のリソースをprefetchしてVDPでHTTP/2のpushできたら面白いよなーとか考えています。
prefetchは今も実装はできるのですがパラレル化が黒魔術になりそうだったので、パラレルESIが来るまでまとうと考えています。
他にも使い方はいろいろあると思うのでぜひチャレンジしてみると面白いと思います。
あと本日12/17は私の誕生日だったりします!プレゼントお待ちしております!

明日は@hosi_mo(誕生日)さんによるネイティブゲームクライアントの設計についての記事です。お楽しみに!

参考資料

VDD14Q2
VDD14Q4