ぱいぱいにっき

Pythonが好きすぎるけれど、今からPerlを好きになりますにっき

#isucon2 に参加してきてました

Perl Redis チューニング ISUCON

おはようございます、マコピーです。

さて、昨日 ISUCON2 なる何でもありのWebアプリケーションチューニングイベントに参加してきてました。詳細や全体の様子は以下のリンクからどうぞ。

livedoor Techブログ : #isucon2 リアルタイムフォトレポート 更新終了

我らがチームぽわわのメンバーは、



という感じでお送りしておりまして、目下のライバルかつディフェンディングチャンピオンであるfujiwara組に社内IRCでいろいろ聞き出しつつ直前にVarnish + nginx + perl + Redisという実際に採用することになった構成を確認しあっていたのでした。

で、当日。

けんじおじさんのエントリ（2012-11-03 - kenjiskywalker no memo）に大体まとまってはいるのですが、まあアプリ側について僕なんにもやってないですけれど、ちょいと解説してみます。

昼ごろ

サバメシがお昼に出まして僕はそれを早速パクついていたのですが、大体のボトルネックをSQLのクエリとか適当にDevel::KYTProfした結果から/buyっていうURLへのPOSTがクソかかると推定し、
「マスタデータは全部コードにベタに貼っておいて、ユーザデータはRedisで実装しておけばいいのでは」
という話になるのです。
RedisっていうのはKVSなんですけれど、アトミックトランザクションっていうトランザクションが使えたり、KVSのくせにリスト型とか集合型とかなんかチート級の高機能を持ったヤツで、そしてなおかつ速いっていうやつです。
社内では最近のアプリケーションに@先生のおかげで導入されつつあります。実際、@typesterさん擁するfujiwara組はそれにより優勝することになるのです。
#isucon2 で優勝してきました - 酒日記 はてな支店

その後

ここまではいいとして、実際のRedisへの書き換えを@さんにまかせてしまって、僕はとりまXslate->newしているところでcache => 2にしてみようかとか、VarnishでTTLやればいいんじゃないんですかねとか、まあそういうことしかできなくて、本当にもったいなかったなあと。
上のfujiwara組のエントリを見ると@さんがMySQLのままでボトルネックを解消していってみたらしく、僕がそれやればそこそこいけたんじゃないかなって思いました。
こうやって役割分担が出来てなかったのが敗因です。
フルRedisのアプリケーションを見てみたかったのはあるのですが、少々飛び道具すぎたのと、僕たちのRedisに対する理解が足りなかったのも敗因です。

f:id:mackee_w:20121104123644p:plain

次へ

次は@さんがなんか出題やるらしく、帰り際に「マコピーがんばれよ、1年あれば大丈夫」なんて言われたのですが、ウム、と思いつつ、反省。


確かに購入処理部分にRedisを使う以外は順当なチューニングであって、アトミックに処理ができるRedisは安定するにつれてたぶんそういったシビアな分野に採用されていくと思うのです。
今の飛び道具、未来の定石、それがRedisだと思いました。
ただ、Redisは型が多くて、使い慣れていないと使いこなすのは難しいと@typesterさんが懇談会でおっしゃっていたので、本当にそうなので、「Redis構築&運用パターン的な本書いてください」って言っておきました！　なんか酔ってたけれどノリノリっぽい反応が得られたので、期待大！
あとはVarnish。去年に引き続き、いや、去年以上にあの4000何行のテーブルによる座席表により、DBボトルネックを潰すと今度はフロントキャッシュやテンプレートキャッシュといった技が有効になるわけで。僕はそれに対してXslateのキャッシュを有効化するぐらいしかやんなかったのですが、たぶんこれでは意味がなくて、他の人に聞くとこんな感じ。

  • POST /buyが来た時点でVarnishのキャッシュをクリアする（できるのか・・？）
  • あのテンプレートをプリレンダし続けるワーカーを立てる
  • むしろ1秒以内にすべてのページをレンダリングし続けるワーカープロセスとリバースプロキシという男気構成
    • これは講評で20秒以内に全チケットを売り切るスコアを叩きだした@さんの手法
  • というか座席のランダム配置チェックが効いてないからすべての座席配置パターンを予め吐いておいて売れた席の数に応じてそれを出しておけばいいのでは（まじかよ・・・・）

アレの対策はいろいろあるようで。
これらの対策はたぶん実運用ではなかなか見られない、しかし理にかなえばスポット的に投入する対策ではあります。
Webサービスを作っていく上でテンプレート生成だとかはどうしても避けられない分野かつそこそこに重くボトルネックになりがちで、さらにデザインだとかの要求で譲れないところでもあったりするので、こういった手法を一般化したりもっと運用しやすい手法に転化するなどしていきたいですね。

とまあこんなスピリチュアルな感じになりました。もう少し頭を冷やしてfujiwara組とぽわわのアプリから見るRedis構成など解説できたらな、と思います。

追記(11/4 18:15)

@さんの記事が出ていましたので
「Perlの上級初心者がISUCON2に行ってきた話」(2012/11/04) - beatsync.net
劣化版というのはたぶんそれぞれの立ち位置を見ると間違いないはずなので、来年はオリジナルが運営に回るってことは劣化版の出番ですね！
とか言っときます。
あとぽわわのRedis実装などが書かれているので僕が解説する必要もなくなったとかそういう@acidlemon++という感じの記事で大変助かります。

あと昨日の時点の僕がRedisで書きなおしても同じような感じになっていやーんな感じになりそうで。やっぱりRedis神の書頼みます！
本業の方のよゆーがでたら僕はキャッシュなしのさいきょうのApache+Perl+MySQL構成で一人ISUCON2してみる予定です。
あ、あと冬コミ受かったんですけれど、全く準備していないのでラノベ風にISUCONする小説でも書きましょうかね。夢が広がりますね。