2013年11月アーカイブ

11/20に行われた「Shibuya Plack/PSGI Conference (shibuya.pl) #1 #plackcon 」で発表をしてきました。内容はYAPC::Asia 2013 Tokyoで発表した内容のその後と、ISUCON3でやってたことです。

それほど成果のある内容ではありませんが、strace芸の一つとしてみて頂ければ幸いです

主催のYappo++。発表者のみなさまありがとうございました~。

スライド表紙のダンボーは、ISUCON3の副賞でもらった。データホテルのロゴ入りロボダンボーです。ちゃんと動きました！

いやぁ、、ほっとした。予選はこっちのblogに書かないぐらい惨敗した気分だったのでよかった。勝たなければ「LINE選抜大した事無い」とか「元出題者wwww」とか言われるし、勝ったら「#茶番」とか言われる立場でしたが、まじほっとしました。やったぁぜぇぇえぇえ！！！

(写真は http://isucon.net/archives/33919770.html から引用)

チームは、@tagomorisさん、@sugyanさんとの「LINE選抜チーム」です。お疲れ様でした！！

isucon3本戦いってきた＆勝ってきた！ #isucon - tagomorisのメモ置き場

#isucon 2013で優勝しました - すぎゃーんメモ

最終的なコードや設定などはこちらのリポジトリ

予選で学んだこと

予選のときは、開始直後からアプリケーションをみて明らかに重そうなところから手をつけていって、序盤からスコアをあげていくことが出来ていたんだけど、最終的なスコアにそれを結びつけることができませんでした。

その反省から、本選ではまず最初にプロファイリングやコードの把握をしようということで、開始から1時間はコードに手をいれない時間を設けた。これが大事だったのかも

予選から本選までにやっていたこと。

予選AMIを起動していろいろ試していて

予選AMIのスコア、66kぐらいが最高でした #isucon

— masahiro nagano (@kazeburo) November 8, 2013

までやってたり、perlの初期スコアがかなり悪いのでそれを改善するためにいろいろやっていたわけなんですが、もちろんそれだけではなくて、必要なミドルウェアのセットアップをスムーズに行ってアプリケーションの改善に集中できるように準備をしていました。例えばnginx(openresty)であればこんな感じ

cd /tmp
wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.33.tar.gz
tar zxf pcre-8.33.tar.gz
wget http://openresty.org/download/ngx_openresty-1.4.3.3.tar.gz
tar zxf ngx_openresty-1.4.3.3.tar.gz
cd ngx_openresty-1.4.3.3
export PATH=/sbin:$PATH
./configure --with-luajit --prefix=/usr/local/openresty --with-http_gzip_static_module --with-pcre=/tmp/pcre-8.33 --with-pcre-jit
make
sudo make install
sudo mkdir -p /var/log/nginx
sudo chmod 755 /var/log/nginx
sudo /etc/init.d/httpd stop
sudo /sbin/chkconfig httpd off

nginx、mysql、memcachedやProcletを使ったアプリケーションの起動などについてこういうのをgithubのwikiにまとめておいて本番に備えておいた。

本選のアーキテクチャ

@tagomoris @sugyanが既に書いているので図で。

252から255の4台がベンチマークツールからのリクエストを受けるようにして、251にproxyしてます。はじめ全台に画像を配るかーとか言ってたんだけど、この方がシンプルだしコストも低いのでこうなった。

やったことと言えば、

• 元からある画像のリサイズ
• 新しい画像をリサイズしてPUT

の2点ぐらい。あとは、iconを252-255のフロントでキャッシュしたり、SQLをちょっと直したり、timelineでやっていたsleepを消したりしたぐらい。ぎりぎりまでバグ対応してたので詳しく見る事が出来てないんだけど、たぶん勝因は @tagomorisがやっていた画像の圧縮。quality 40%とか本番ではやらないけどファイルサイズ1/3になって処理できるリクエスト3倍とかになったのかなと思いました。

そうそう普段の画像配信のパターンとしては、ストレージ側の容量やIO負荷を押さえるために元画像のサイズはひとつで、リクエストが来たときにリサイズして、その結果をキャッシュして配信するのがよくある戦略だと思うのですが、今回まったく逆ですね。

あと、sleepを消したtimelineのpollingの効率はどなたか調査してくれると嬉しいやも。

あれこれ

• 準備は大切。自分たちのパターンを持つ事は重要
• だからといってそのパターンにこだわりすぎないこと。新規画像を非同期で処理する戦略をとったけど、難しいことに気付いてそれを捨てれたのもよかった
• 困った時はすぐに相談する。目の前にいるんだから話すの大事
• 間抜けなnginxの設定ミスをいっぱいしたので、マスタリングnginxは買おうと思った。internal redirect。まじinternal redirect。
• Furlで、PUTしたあとのkeepaliveに問題がありそうなので、あとでみる
• もっと性能を出す為に必要なことを考えて、日々の業務に活かすこと。そしてオープンソースに貢献する事

最後に

@fujiwaraさん、@acidlemonさん、@941さんをはじめ運営のみなさまお疲れ様でした。ありがとうございます！ あと、途中で応援に来てくれた奥さんと、息子と娘にも感謝！

ダンボーは頑張って組み立てます

マスタリングnginx、あってよかった