金利0無利息キャッシング – キャッシングできます

YAPC::Asia 2011で発表してきました

00:35 |

キャッシュ戦略とかBloom FilterとかVarnishの話をしました。

j/kかカーソルでページめくりです。

• http://ma.la/files/yapcasia2011/
• http://ma.la/files/yapcasia2011/main.txt

結構分量がありますが、いろんな人が発表できるよう遠慮して20分にしました。

補足的とか参考リンクとか

Bloom Filterについて

有名なアルゴリズムだけど、あんまりWebアプリケーションで使われてるという話を聞かない、いろんな所で知らないうちに使われてるはず。Bloom Filter使ってるよという話は以前にもしたことがあるんだけど、あんまり真似されてないように思えたので盛り込んだ。

• http://la.ma.la/blog/diary_200706062320.htm

• http://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%BC%E3%83%A0%E3%83%95%E3%82%A3%E3%83%AB%E3%82%BF
• http://muziyoshiz.jp/20050328.html#p01
• http://dev.ariel-networks.com/column/tech/boom_filter/
• http://research.preferred.jp/2011/03/bloom-filter/
• http://fallabs.com/blog-ja/promenade.cgi?id=70
• http://search.cpan.org/~mceglows/Bloom-Filter-1.0/
• http://search.cpan.org/~palvaro/Bloom-Faster-1.7/

検出した全てのURLに対して「上位ディレクトリに既知のリンクがあるかどうか」という処理を行う。で、リモートのDBに問い合わせる際に1件ずつ問い合わせると数千件になってしまったり、1回のクエリに収めようとすると「考えうる全ての上位ディレクトリのURLを一括で」ということになって、SQLが巨大になったり、必要のないクエリ(上位ディレクトリでマッチしたら残りはいらない)が含まれることになってしまう。

Webアプリケーションで使いづらいのは、多分Webアプリケーションの性質上、擬陽性があるのを許容出来るケースがあまり無いからだと思う。クエリを間引くような利用例は、シンプルにDBを高速化したほうがわかりやすい、ものすごくパフォーマンスが良いDBがあれば不要になる。Bloom Filterがリアルタイム(もしくは許容出来る遅延)でアップデートされているならば「そのキーが無いと言われたら確実に無い」と判定できるのが特徴。見つかりません、が即答できる。何かしら特殊なことをやりたいときに、二桁上のパフォーマンスが必要なときに、いろんなアルゴリズムを学んで引き出しを増やしておくのは重要だと思う。

キャッシュについて

• get_multi使うと爆速だよって良く言ってるんだけど、これもあんまり使われなかったりする
  • コードが複雑になりがちだからだと思う、一度書いてしまえば後は楽。
• ウォームアップは複数の人が同じフィードの先読みを求めていた場合、未読数が多い方で上書きして余計なクエリが走らないようにしてる。

Varnishについて

• 自社サービスは過去にはApache2 + mod_perl + 必要に応じてSquidみたいな構成だったのが、割と皆さん個人的な趣味でNginxやVarnishを導入して管理の手間を増やしている。
• varnishの良いところはrestartで、500返したら別のバックエンドに切り替えてリクエスト最初からやり直すとか出来る。ヤバイ。
• https://www.varnish-cache.org/trac/wiki/VCLExampleRestarts
  • 強制的に304レスポンス返したいときはリクエストを/304に書き換えてrestart、とかやる。
• ロードバランサかくあるべしみたいなことがキチンと出来る。httpに特化してるだけある。
• レスポンスヘッダ見てほげほげするような、Apacheだとmod_xxxxみたいなモジュール書かないとできないようなことが大抵vclだけで出来る。
• そういうプログラマブルなことをやりたくなったときにperlbalとかでも出来るんだけど「perlbalはちょっと、ねえ」みたいな感じになるのでvarnishが選択肢になる。

• ESIについては、ESIが部分的だけどまともに動くのがvarnishぐらいしかないので、varnishと心中するつもりがないと使いづらい。
• キャッシュしたいフラグメントごとに、URLを作ったり、HTTPレスポンスヘッダでキャッシュ期限指定しないといけない。つまりアプリケーション側に手を入れないといけない。
• そうなると、大抵のエンジニアは生成手前の中間状態をキャッシュして、テンプレートエンジンで組み立てるだけ、という状態を好むだろう。
  • キャッシュのsetやpurgeをmemcachedで管理したほうが楽だからだ。アプリケーションのキャッシュ管理ロジックの中で、ロードバランサのことを気にかけるのは美しくないから。

ORMに関する見解

• DISられてるの大抵DBIx::Classのことじゃないかなーと思うようにしている
• オブジェクトの生成コストが高い(余計なこと色々やってる)のはあるけど、DBIx::SkinnyとかTengはハッシュをblessしてるだけで、殆どコストかからないはず
• ORMが時々余計なことをするのは宿命なので、必要に応じて生SQL書くのが良いと思う。
• 大抵の場合ORMが遅い!!!ってなったときには他の原因だと思われるので、ORM捨てる前に色々考えるべき
• ORMで何やりたいのかって人それぞれだと思うけどINSERTやDELETEのタイミングで何かやりたいみたいなケースが結構多いと思っていて、そういうのを全部MySQL側に持っていく選択肢がある。
• ただ、規模に応じた選択肢というのがあるし「もうジャンジャンバリバリ使ってます → 後々運用に困っている」みたいな事例も聞くので、zigorouさんの言うことは話半分に聞いたほうが良いなーと思っている。

感想とか

何話すのかあんまり考えずに応募して、いつもなんとかなる感じなのですが、たまたま障害対応とか緊急でやったほうが良い案件とか入ってギリギリまで危ない感じでした。既に別のイベント等で話したことのあるネタも幾つか入ってますが、VarnishとESIの話は多分あんまりしたことない。芝生では今年も有用な話が聞けた。懇親会では久しぶりに会えた人がいて面白かった。naoyaさんが珍しく参加していたので「タダメシの力は大きいな」みたいな話を一部の人がしていた。