ISUCON6の予選に参加しました

2016/09/20

知人とチームを組み、今年も ISUCON に挑戦しました。今年で2回目の参加です。昨年は片っ端からボトルネックっぽいところをいじくり回しては元に戻しのような進め方をし、全然スコアが上がらないという結果でした。今年は、焦らず計測をし、計測結果に基づいたチューニングをするという方針で進めることを心がけました。

何した

言語は Ruby を選択。チューニング無しの状態で、初期スコア 0 からのスタート。コミットログを見返して、ざっくりやったことを挙げると ↓ こんな感じ。

isutar DB の中身を isuda に突っ込んだ
合わせて isutar を isuda に移植し、HTTP request している箇所を DB を直接見に行くように
静的ファイルを nginx で捌く
nginx <=> unicorn 間を UNIX-domain socket に変更
unicorn の worker 数の調整
正規表現に使っている keyword を memcached でキャッシュするようにした
Regexp Object にしてからキャッシュすればいいんじゃねってなった
MySQL の Query Cache を有効化
password を平文にした (!)

これで、ベストスコア 5355 、最終スコア 4940 という結果でした。惨敗、、、😇

あと、開始直後 Azure のデプロイがいつまで経っても終了しなかった。45分ほど初期スコア/ログの確認やコード読んだりが出来ず初動が遅い感じでのスタートになってしまったのが悔しい。

振り返り

手を動かす前に計測してから進めたのは良かった

当てずっぽうに作業するのではなく、アプリケーションのどこが遅いかを少しずつ特定し作業を進められたのは良かったと思います。ただ、得られた結果を元に次に何をするかという判断が出来なかった場面が多々あり、次回挑戦するまでの課題だと感じました。ミドルウェアのボトルネック調査や、チューニングする際の設定の勘所については、もう少しスキルレベルを挙げる必要がありそうです。特に、MySQL 周りのチューニングにおいて Slow Query や EXPLAIN の結果を活かすチューニング策を練ることができなかったのは大きな反省点です。

過去問を解きチューニングの勘所を身に着けておくべきだった

なんだかんだで忙しく、予選前に過去問を解くことをしませんでした。チューニング手法についてキーワードは知っていても、実際に何をすべきか知らず競技時間中に gg ってる時間が長かったなと思います。 ISUCON に関しては、大会本番に関わらず大きくスコアを上げることをそもそも経験したことがありません。少なくとも、去年参加した ISUCON5 の予選問題くらいは再挑戦しておくべきでした。答えを見ながらでもいいのでスコアが上昇することを確認し、何を変えたらパフォーマンスが良くなるのかをより深く理解する必要があると感じました。

ソースコード管理は上手く機能していたと思う

昨年はお手製の構成管理ツールのようなものを使ってみたりもしましたが、手動 cp で全然良かったです。webapp ディレクトリをまるっと git init し、中に conf ディレクトリを作ってミドルウェアの設定ファイルを放り込んだだけでした。作業の進め方についてメンバー内で認識をすり合わせる時間/手間も少なく、バージョン管理によって上手く動作しなかった場合の切り戻しも瞬時に行えました。