#isucon 2013 予選をトップ通過してきた（はず）。
あとに回すと、ブログを書くハードルが上がってしまいそうなので、取り急ぎ。*1
さて、10月5日、6日と2日間の日程で開催された、isucon（いい感じにスピードアップコンテスト）の予選に参加して、なんと、総合トップで通過いたしました！！！！！
今回は、まずは予選突破を目指して参加したのですが、いろいろな幸運が重なり、現時点で予選総合トップ！ 現時点では、運営の方のAMI審査で問題がなければ、という条件付きではありますが。
すでに、参加チームの幾つかからブログ報告が出ていますが、ほかのチームがかなりアプリ側のコードに手を入れているのとは、対照的にスコアの大半はインフラ側チューニングです。
特に、フロントにおいたnginxで以下にリクエストを捌くかがスコアアップの決め手になっています。
また、アプリの言語はPythonを選びました。Python 3.3が使われていたのにはちょっと戸惑いましたが、結果的にはいい方向に倒れたと思います。
アプリ側で行った主な変更は、ほかのチームに比べて対してものはなく、
という、開始すぐにできるような類のものです。そのほかにも、ほかのチームがやっているようなキャッシュやレンダリングの削減など、いろいろと試行錯誤はしましたが、それほど大きな改善はなく、アプリのチューニングだけでは大きなブレイクスルーを起こすのは難しいと、途中で見切って、インフラ寄りのチューニングに舵を切りました。
今回の課題では、ベンチマークツールとアプリが同じサーバで動いており、かつ、レンダリングの負荷が高かったので、CPU資源があっという間に枯渇してしまうことが問題でした。 そのほとんどをまずNginx側で裁いて、アプリケーションにCPUを使わせないことが、今回のチューニングのポイントになっています。
その結果、フロントでできるだけリクエスト捌き、アプリにアクセスさせないようなNginxのチューニングを行って、30000点弱のスコアを出せたので、あとはその調整という感じですね。
また、isucon2でよく使われていたプリレンダリングは、ページ数が多かったり、ユーザログインの情報があったり、イニシャライズスクリプトに60秒の時間制限があったりと、なかなか効果的なものが入れにくかったので、これも見切って、Nginxのキャッシュの制御だけとしました。
ただ、そのバーターとして、多少のFailが出るのは許容しています。これに倒したのは、今回は、Failに重みが付けられていて、ある程度は妥協できるFailがあったということが大きいです。*2
ということで、結果だけ見ると、僕たちの勝因の多くは非常にシンプルはインフラチューニングによっています。そのほかに挙げるとしたら、制限時間内に効果的な施策を打つための時間管理ですかねー。 こういうインフラチューニングでも、レギュレーションを理解して、大きな観点でボトルネックを潰していけば、スコアが出るように問題が作られていたのかなーと思いますが、それは主催者のみ知るところです。
とにかく、当初目的であった予選通過は達成できそうなので、本戦楽しんできます！
最後ですが、参加してみて、isuconは多大な運営の方の努力によって作られていることを実感しました。2日間、本当にお疲れさまです。 無事に本戦に参加できたら、よろしくお願いします！
