チームルンバとして #isucon2 に参加してきた！

最近Rubyやスマフォアプリを書いたりしているkazuphです。

今回同期の@koichi222に誘われてISUCON2に参加してきました。
また是非インフラに詳しい人をということで@kitanpさんにもジョインして頂きました。

そうそうたる~~モヒカン~~実力者の方々に囲まれることになったわけですが、めでたく失格にならず完走できましたよ、と。

今回はISUCON2当日はもちろんのこと今まで準備期間でやったことをざっと書きます。

何はともあれISUCONって何が出るの？ってことでISUCON1のブログ漁りを始めました。
すぎゃーんさんが前回のブログでISUCONタグがついているブクマのリンクを張っていたのを見て全部見てました。

基本的にはサイトのパフォーマンスチューニングなど本格的にやったことがないメンバーしかいなかったので、自分が読んだブログをFacebookグループに流して文章などで読み取れない部分は調べて解説したり、全員で相談しながらやっていました。

構成はfujiwaraさんのnginx + memcachedの環境を参考に自分たちでどう作るかを考えていて、直前の方では@kitanpさんがリバプロ周りの環境をつくってくださったので実際に動かしながらhttp_load(patch適用済み)で叩きまくってました。

memcacheを使うだけで(GETだけなら)爆速化できて満足していましたが、まあまさか同じ問題が来るわけないので対策ISUCON1の勉強だけだったのはやはり失敗でしたね・・。

作戦としては基本はLinuxに強い@kitanpさんがカーネルの設定とnginxやmemcachedなどのミドルウェアまわりの設定とチューニング、
アプリが書ける@kazuphと@koichi222がPerlをゴリゴリ書いてmemcachedに載せるという想定でした。

nginxでmemcacheに保存して更新時にのみアプリからmemcacheを更新する作戦だったのでこの構成がマストだったのですが、nginxに変えた途端スコアが激下がりして原因究明を試みましたが13時を過ぎても解決しなかったのでApache構成へ変更。

あとから捌けるワーカーが多すぎて内部で詰まっていると聞いて全然そんなことになっているとわからなかったのことを反省。

ですよね、やっぱりそうですよね。
ポストのことなんてさっぱり考えてませんでしたよ。

そしたら@kitanpさんがMySQLの更新性能を考えて一部のテーブルのみMyISAMに変更。
そこでチケット数が1000を越えましたがそれ移行は振るわず。

もっと更新系でさばけるように勉強するべきだったと反省。

再起動対策を全然していなかったためかなんなのか、再起動直後のスコアが劇的に遅くなりました。
そこまで！？って思うほど下がってISUCON終了間際は中間くらいの順位だったのに、
まさかのブービー賞（Failedのチームがあったので最下位ではないけど・・・）。

みんな悩んでいる時間が大きくて手を動かす時間が少なかった気がする。
もっとゴリゴリ改善したかったけど、そこは実力不足といったとこですね。。。
ボトルネックを追求する能力はもっと磨くべきだと思いました。

以上大まかにはこの４点ですかね。

詳細な部分は相方の@koichi222が書いてくれる（書いてくれた）と思うのでたぶん。

ぶっちゃけスコアは振るわずでしたが、正直かなり勉強になったってのが一番です。

普段の業務でやらないことをできたのは良い収穫でした。

ただ一つすごいなぁと思うのは、普段アプリしか書いてない人とか、逆にインフラしかやってない人でも今回の参加者だと両方できちゃう人も多かったのかなぁと。

そこら辺の存在がとても刺激になったので来年にこそ満足の結果が出せるようにしたいと思いました。

こんな素敵なイベントがあったら是非来年も参加したいと思います、ホント。

運営チームもありがとうございました。

また来年も参加します。

僕のYak Shavingは終わらない