ISUCON4 練習、予選
ISUCON4に初参加した。
予選通過ならずっぽいけど、いろいろ勉強になったので、記録しておく(だらだら書き)。
チーム
aomoriringoさん、matsu4512さん、自分。
おおよその役割分担は、
- aomoriringo : アプリ周り中心
- matsu4512 : DB周り中心
- 自分 : その他
で、
当日は具体的に、
あたりをやった。
練習会
「初めてで何もできないで終わるのでは？」ということで、aomoriringo邸で練習会を2回行った。
実際の問題が試せるということで、「ISUCON3予選(夏合宿)の問題」を、1回目は何も見ずに、2回目はいろいろ資料見ながら解いていった。
問題は、「Markdown形式のメモを管理できるサービスの最適化」で、DBやアプリの書き換え、ライブラリの置き換えなんかが効果的な問題セットだった。
やっぱり、通してやってみるとか、ほかの人のをトレースしてやってみるのはすごく勉強になった。
あと、perlやrubyやpythonなど、ライブラリが充実しているものの方がいいのかなという感触だった。
でも、アプリやDB以外については、varnishとかのミドルウェア導入や設定のチューニングはあまり寄与しなさそうな結果がでていたり、workloadの値を変えてもあまりスコアが変化していなかったりで、正しい経験が得られていなかった可能性が高い・・・
申込Phase
練習1回目の時に、チーム名を検討。
方向制御文字とかはみ出る文字とかも考えてたけど、読める文字で検討し、無難な感じになった。
んでいろいろ入力して登録して送信・・・してたつもりが、予選前に登録できていないことが発覚。
運営、くしいさんのご厚意によって参加締切すぎてたけど追加していただけることになった。本当にありがとうございます。
予選(土曜日)
朝7時ぐらいに起床。乾燥して鼻血ぶー。
9時すぎにaomoriringo邸に集合。朝ごはん。
10時スタート。
aomoriringoが光速でサーバー環境準備して8分で全員ログイン完了、ベンチ実施完了。
練習だと、「サービスを触ってみることが大事だね」とか「ソースコード読んどかないと一部だけ修正したりするね」みたいな教訓が得られてたので、
を中心に進める。
練習だとapacheだったのに、今回はnginxになったり、静的データ(css、png)があんまりサイズ大きくないので、キャッシュとかあまり効果なさそうかも、という感じだった。
動的なページが多いのでapacheにした方がいいのかなとか。
11時すぎ。
インデクスやクエリキャッシュやらの改善で暫定1位！
ソースコードで重そうなところを見てみると、
- report/が重い
- バンやロックされたuserやipの計算がメインの改善ポイント
かなということで、そこを中心に修正する方針に。
memcache導入して必要な情報を持たせればよさそうということで、まずは重いreportページから改善。(けどそんなに呼び出されるの？という話は出てた)
アプリの改善はペアプロ気味に書き換えてるところを一緒にみて間違っていそうなところを指摘する感じに。
15時すぎ。
実装＆デバッグに時間かかってしまい、reportの書き換えが3時間ぐらい。。。ベンチチェック→スコア変わらず？？？？
そもそもreportがベンチ結果のスコアに含まれていない？？？→マニュアル読んだらreportは中身チェックだけでスコアに関係ないことが判明。。。
16時。
report以外の部分をmemcache使うように変更するということで、別の部分のチューニングをすることに。
他のを入れても試せる時間なさそうなので、できていなかった設定周りを調整。
アプリを見てみてもほとんど重そうな処理もなく、DB周りを見ていたら、そもそもテーブルがそんなに大きくないのでengineをInnoDBじゃなく、MyISAMやMEMORYで試せないかと思ってinit.shやmy.confあたりを修正。
アプリ側の修正を中心に、上のは試せず終了。
予選終了後
スコアは7000点後半。
初速はよくて、問題洗い出しやらActionItem設定もよかったけど、python+flask+gunicorn+nginxのデバッグがもっと効率的な方法で行えてたらもっといろいろ試せたかなという感じ。
終了直後、試せなかったテーブルのエンジンをInnoDBからMEMORYへの変更を試してみたら9000点ちょっとまで上がった・・・でもおおよそ上位陣には遠く及ばないので、ダメぽ。
みんなどうやってるのかなぁと思ってチャットを覗いてると、みんなのworkloadがおかしい。
自分たちはいじっていなくて、workload=1のまま。。。
練習の時は、かなり重い処理があって最初の負荷でも全然さばけていなかったので、それをどれだけ軽くできるかだと思っていたけど、正しい進め方としては、どれだけ負荷を高めても耐えられる環境を作れるか、だったみたいで、戦い方がそもそも違っていたなぁという感じ。
(workloadをめちゃくちゃ大きくするとスコアが高くなるようで、変えたら50000近くのスコアが出たりしてほげ)
だとすると、varnishやらapacheやらが重要になってきて、自分の担当分だったかも。
あと、他の人とかは複数サーバーでやってたりして、いろいろ効果が出そうなチューニングを探すだとか、パラレルで修正できるようにしたほうがよかったなと思った。
教訓としては、
- マニュアルはきちんと全部読む
- デバッグ方法は最初に最適化しておく
- 2重3重にチェックをすることが大事
いろいろと勉強になったし、面白かったので、また来年でてみたいし、単純にphp+apacheとかjavascriptでの開発以外に、python+flask+gunicornやvarnishやnginxとかを使ったサービス作ってみたい。
