友人たちとisucon予習会をやってみた感想
isuconの予習会をした記録を書く。
pixivさんが社内isuconの資料を公開してくれたので、そちらの資料をもとに実際に予習会をやってみました。
友人が予習会の準備とかしてくれて、isucon概要や基本の戦略をwikiにまとめてくれたり、各チームのスコアをリアルタイムで見れる表とか作ってくれました。ありがとうございました m(_ _)m
資料:
僕はisucon初参加だったのですが、なんとなくisuconがどういうものかこのwikiのおかげで把握できました。
参加人数は10人で、1チーム2~3人にまとまるように当日にチームを4つ作ってスコアを競ってみました。
とりあえず何をやったか忘れないためにメモする。
今回学んだことをざっくりメモ
最初にやった方がいいこと
- editorとかバージョン管理まわりとかの環境を早めに整える
- チームの人が「/tmp/usernameをローカルと見立てて本番masterをクローン&コミットして、本番反映するときは本番masterがある場所でpullする」という素晴らしいバージョン管理方法を教えてくれて、今回はこの方法を実践してみました。メンバーがそばにいるので本番反映しますと一言声かけて実行してみて、だめならrevertするみたいにやってました。git remote add file:///tmp/username みたいなことをするという発想が自分にとっては新しくて、感動しました。
- debianにvimが入っていなくて、しかもapt-get updateしないとvimが入らないという状況だったので、最初に手に馴染んだエディタを入れるための方法を調べておいたほうがいいですね。ちなみに僕はvimを入れるためにカジュアルにupdateしてしまいましたが、updateすると今まで動いていたものが急に使えなくなるという状況になることがあるみたいなので、その辺りの知見があれば心強いですね..。
- 頻繁に使うコマンドは何かでまとめて管理しておく (今回チームメンバーの人がMakefileをささっと作ってくれました)
- 後半になるとコマンドのtypeミスが多くなるから、とチームの人が作ってくれました。これは初期にやってくれててとても助かりました。
- コマンド補完を使えるようにする
- 最初はtabで補完効かなくて不便だったので、apt-get install bash-completion して使えるようにしました。手馴れたもの以外のコマンドのオプションとかいちいち覚えていられないので..。
- nginx, mysql, アプリケーションのログを出すようにする
- slow_query とか便利でした
- ログを解析するためのツールを導入して負荷が高いところを見てみる(みんなはkataribe, ALPとか使ってた)
- index貼ってあるか確認してみる
- 他のチームはindexを貼ってみて一気に2万とかスコア上がってました。相乗効果はアプリのチューニング次第だと思うんですが、早めに試しておくべきだった。
チームで試してみたこと
ぼくはあんまり改善できなかったけど、全体的にこんな感じだったらしい
isucon参加する前に身に付けたいこと
- isuconでちゃんと使える言語を身につけておく
- 今回はrubyを選択したのですが、構文的な部分で時間を無駄に食ったので、そういう無駄をなくすためにもそれなりに使える言語を身につけておいたほうがいいですね。
- あと選択した言語が得意な人がいると強いですね。自分がわかってることが一番ですけども。
- どのファイルシステム/OSが来てもそれなりに使えるようになっておく
- 今回はdebianだったのですが、環境構築まわりで疲弊したので、本番前にテストで環境構築してみたほうが本番の精神衛生が保てるとおもう。
- webアプリケーションのパフォーマンスを改善するための定石を知っておく・事前に実践してみる・サクッとできるまで日頃から鍛錬しておく
チームでやる場合に気をつけたほうがいいなと思ったこと
- バージョン管理をどうするか事前に決めておく
- 多分それぞれの楽な方法を持っていると思うんですけど、当日試合がスタートしてからなんとなくで決めると、その決めた管理方法に慣れてる人とそうでない人で作業に差が出るので、可能なら先に打ち合わせして決めたほうがよいかなと感じた。
- あと、まっさらな開発環境更の整備をどこまで時間をかけるかも事前に相談して決めておくといいですね。環境構築のためのshをdropboxに配置しておき、当日はそれを実行すれば環境が整うようにしておくと消耗しなくて済みそうです。
- 参加意識とが同じレベルの人とやった方が良さそうな感じがあった
- 今回、私は「とりあえずやってみるぞ」という気持ちで予習会に参加したのですが、おそらくチームの人はそうではなかった様子で、途中で足を引っ張ってしまったあたりから今後どうすれば相手の迷惑にならないのだろうと考えていて思うように作業できなかったので、まずは本番では同じ意識レベルの人と組んで、「いろいろダメなところがあったけどisuconに参加してみて楽しかったね」で終われる人と組むといいのかなと思いました。
- 技術レベルが近い人と組むか、それなりにwebサービスのパフォーマンス改善の知識をつけてから参加したほうがいい感じがした
- isucon初ということもあったのですが、僕が何をするとパフォーマンス改善するかを考えて試そうかなと思った時には経験者さんがガガーッと色々やっていて、その頃には下手にコード触ると逆に迷惑になるみたいな状況になり、相手のパフォーマンスとか精神的な部分にも負荷をかけてしまっていて、後半は僕はいないほうが良いのではという感じになったので、そうにならないためにも改善の知識を身につけてからやったほうがいいなと感じました。
全体的な感想
- 第一に、体調万全でやる。体調が良くないとイライラしたり集中が続かないので、スムーズに問題解決ができなくなる...。
- isucon予習会の前にしっかり事前調査しておけば少しは僕もマシな作業ができたかなと反省。
- 試したいこといくつかあったけど今回できなかったのが悔しかったので、個人的にやってみる。なるべく足引っ張らないように最初に一人で似たようなことを試しておいたほうが良かったなと反省。後半、参加しないで後ろからみてた方が良かったかな、ってちょっと思った。
- rubyを全く書けなくなっていて自分でも愕然としたのでredmineいじりの練習がてらruby触ろうと思います...本当にだめだめだった
- プロファイラとかツール周りの知識を一通り自分の中で蓄えておきたいなと思った。そもそもrubyのプロファイラって何使えばいいの？みたいになって死んだ。
- チームで苦しんだ点としてsinatraアプリの簡単なデバッグ方法がわからなかったんだけど、試合終了してから簡単にできることが判明して死んだ。ちゃんと添付資料読もう...。
- 辛い気持ちになって嫌な体験にしないためにも本番は気楽にやりたいし、そういう空気になるようにしたい
- 作業分担というか、二人でやるならインフラとアプリケーションで分けても良かったかもしれない。コンフリクトが発生しないような切り分けを最初に決めて、あとはひたすら担当の作業をするというほうが効率が良かったのかもしれないと今日やってみて思いました。
- そんなに時間を気にしてやってなかったのでいつの間にか残り1hとかで焦ったので、タイマーとかで時間管理した方が良いですね..結構焦る。
雑にメモしたけど、まだまだ書いてない知見が結構あった（いっぺんに書くと疲れるし多すぎるので別のメモに書く）。
こういうの初めてで、楽しかったです。とても良い経験になりました。
予習会を主催してくれた人たちや参加者の皆、そしてチームメンバー、ありがとうございました！
