📑

ISUCON11に参加して予選敗退しました

2 min read

はじめに

去年と同じチーム、即日安心カードローン(@ikkuntech, @IshidallP)で参加してISUCON11予選敗退しました。
最終スコア65886点(参考値)で49位でした。去年の順位は100位より下だったので今回はわりと善戦できたようです。

ただ、今回自分はわりとできたことが少なく、チームメイトの力が大きかったです。
役割は去年と同じく自分がインフラまわり、他2人がアプリまわりでした。
DBはインデックス1つ追加したぐらいで今回あまり変更できなかった。。そこも反省ポイントです。
言語も去年と変わらずGoです。

https://github.com/ktny/isucon11-qualify

やったこと

大体時系列順に。

環境セットアップ

EC2インスタンス立ち上げて初回ベンチを流す。1000いくつが出る。
この時点で10000とかいってるチームがいて早くね?となっていた。
開発環境効率化のためにデプロイスクリプトなどを作って配布。

DBのスロークエリを出す。インデックスを貼る

スロークエリを出して、SELECT isu_conditionが支配的だねとなる。
とりあえずjia_isu_uuidにインデックスを貼り、ベンチを流すと10000点を超える。
ORDER BY timestamp DESCがあるので、timestampに負にしたGenerated Columnsを作ろうとするが、timestampを負にはできないので失敗。
(あとでUNIXTIMEにしたあと負にする方法をikkuntechが思いついていたが失敗していた。ただしこの方法でいけるらしい。未検証。)

いろいろオンメモリ化

ikkuntechがJIAサービスURLとかuserテーブルをオンメモリ化してくれた。
ただ、このあたりでベンチが失敗したり成功したりと不安定になったので、いろいろ切り戻しが発生した。
デプロイスクリプトの不具合があったり、userテーブルオンメモリ化もユーザー追加対応がなかったりしたようで結局原因はよくわからなかったので時間的にはロスが大きかったかもしれない。
ISUCONは時間との勝負であり、ボトルネックを見つけて対応していくということが重要なので、簡単に直せそうなところでも本当にそこがボトルネックなのか一歩待ってみた方が結果的にいいかもという反省になった(そうでないと間違えたときのロスが大きくなる)。
スクリプトの不具合は準備不足が大きいので、こういうのは事前にしっかり作っておかないとダメ。

IsuConditionのバルクインサートとか

IshidallPがバルクインサートなどいくつか対応してくれた。
このあたりでたしか15000ぐらい。

nginx対応

nginx.conf書き換えてalpで解析とか。13時とかにやってるけどそれまで何やってた?ってぐらい記憶がない。
この辺は初回ベンチ流したらわりとすぐにやっておくべきだった。
alpで解析してPOST /api/condition がボトルネックなことはわかったが、解決策わからず。

DBを別サーバに移す

1サーバでやってたが、DBを別サーバに移すことに。
MariaDBを外部から接続できるようにして、アプリのDB接続先を他インスタンスに変えるだけの作業だがめちゃめちゃハマる。
やり方自体はわかってたはずが、初期のbind-addressの場所が/etc/mysql/mariadb.conf.d/50-server.confにあると気づかず、2時間ほど溶かす。
去年もDBの外部接続まわりはミスっていて、今年もこれなのでけっこう辛い。次こそはスムーズに行きたい。
my.cnfの1ファイルで管理した方がいいのかなあ?
一応これで20000 ~ 25000点ぐらいになる。

ベンチ結果を安定させる

実はここまでベンチの結果が最後まで走ったり途中で死んだりと不安定な状態になっていた。
原因はおそらくIsuConditionのキャッシュまわりの不具合だろうということで、ikkuntechがロック対応してくれた。
このときほぼ同時にISUCONポータルも見れなくなるなどしてベンチを走らせられない状態が続いた。
結果的にこの対応は成功し、ベンチ結果は安定するようになった。

最後ログを切る

ここまでの対応でたしか28000点とかが最高点の状態。
すでに他チームのスコアは見られない状況になっているとはいえ、最低でも50000はいかないと厳しいねという感じ。
時間もないのでそろそろログを切るなどしてパフォーマンスを詰めることに。
これがかなり効いて60000点近くが出る。ログ切っただけでそんな上がんの?と盛り上がる。
あとは再起動試験成功を祈るのみとなった。

反省点

  • サーバリソース監視を全然できてなかった
    • してたらアプリCPUボトルネックだから~とかの話ができてたんだろうな
  • サーバ3台使えてない
    • いくらでもやりようはあっただろうけど普通に技術力不足で対応できず
    • 今回はweb,アプリ,DBとかアプリx2,DBの構成にするのが良さそうだったけどどうなのか
  • 本質でない対応に時間が取られすぎている
    • スクリプトのミスとかDBの外部接続とか
    • アプリ側の対応もボトルネックに沿って対応したい
    • gitのrevert多すぎ問題
  • DBのインデックスもっと貼れた
    • timestamp DESCはともかく、isu.jia_user_idとかは気づいてたけどなんか後回しにして貼れてなかった
  • というかマニュアル全然読めてない、理解できてない
    • 仕様的になにしたらスコアが上がるのか最後までよくわからなかった
    • GoodとかBadってなに?

感想

全体的によくこの状況でこのスコア取れたなという感じですが、伸び代ということで来年も頑張りたいと思います。
運営の皆様ありがとうございました。来年もよろしくおねがいします。

GitHubで編集を提案

Discussion

ログインするとコメントできます