ISUCON11予選に失格してきた

先日開催されたISUCON11の予選に参加してきたよ

結果

気になる結果は・・・

大会結果

takahiroは去年のisuconに初出場で本戦出場(学生枠)したすごい人。今年新卒入社した同期エンジニア3人でtakahiroに誘われる形でISUCON出場することに。

大会1ヶ月くらい前に一回、会社の同期5人でゆるーく勉強会をする。経験者になんとなく教えてもらったりしながらISUCONとはなにかみたいな話をしてた。

同じように勉強会を開催。

などを経験者組からおそわる(教わってばっか)

メンバーが交通事故(無傷)に巻き込まれて警察署に行ったりわちゃわちゃした。

モニタリングまわりのことと、ミドルウェアの設定とかは他のメンバーがやってくれそうな雰囲気があったので僕はとりあえずGoの勉強した。Goはほぼ初めてだったけど雰囲気理解した。あとSQLもちょっとだけ勉強した。

takahiroの家に集まってやることに。感染対策の観点からは良くないけど、全員テレワークで外出してないから大丈夫と判断。対面での連携の鳥やすさを優先した。

詳しい時系列とかは他のメンバーのエントリに書いてもらうとして、僕がやったこととその振り返りを書いていく。

僕は主にアプリケーションの改善を担当した。時系列順には多分以下の通り。

0にしたり0.5くらいにしたり。みんなやるよね。

明らかに大量に呼ばれてるクエリで、わかりやすくN+1が発生していたので。簡単に修正できた。点数はほとんど変わんなかった。もしかしたら後々効いてたのかもしれないけど。

dropProbabilityを下げれるかが大事そうな雰囲気してたので、postIsuConditionへのリクエストをいい感じにキャッシュして複数回分のリクエストをまとめてInsertできないかと思って試した。僕のGo力とメモリに関する理解と人徳が足りなくて無理だった。

ルールを読む限り、getTrend自体は得点につながらなさそうだったけど、他にできそうなことが思いつかなくて着手。

getTrendが明らかに非効率なクエリになっていてので、修正を試みるが動かない。。。。

getTrendが動かないのを修正しようとすると沼が深そうだったのと、修正しても得点に結びつかなさそうだったので、諦めて他のメンバが解析した結果を眺めて他のアクションを考えてた。

この間に他のメンバがサーバー分散したりインデックス貼ったりしたらgetTrendが一番重いクエリになってきた。やっぱり修正することに。

よく見てみたらGolangのsliceのappendの挙動で失敗してたのでそこを直したら動いた。 GET /trend 自体はかなり早くなった。得点もちょっと伸びた。

エンドポイント自体は早くなったけど、SQLで不要なデータをとってきてたので、それを改善するためにtomonoriと一緒にSQLを改善した。(二人ともSQL力が足りなくて調べながらやってた)。結果うまいことデータを取れるSQLを作れて、クエリもかなり早くなったが、スコアはむしろ下がってしまった。

ログを見ると、クエリが早くなった分ベンチから呼び出される回数も増えてた。なんでこういう挙動になるのか今でも謎。

今回の(僕個人の)反省点は

ルールや仕様をちゃんと読む
- 課題のトリアージがちゃんとできず、筋の悪そうなgetTrendを触ってた
- そもそもルールをよく読んでなかったせいで失格になった
事前準備
- デプロイスクリプトとかはあってもよかった
- ブランチ戦略でちょっとまごついたのでプロンプトにブランチ名とHEADのコミットハッシュを表示するbashrcを用意してても良かったかも
技術力不足
- Goに不慣れ
- SQLにも不慣れ

楽しかった。中高生の頃からロボコンやってきてた身としては、こういうコンテスト特有の緊張感が好き。

他のチームとして出場するにも関わらず、初出場の僕やtomonoriに色々教えてくれたり勉強会の準備をしてくれたり反省会を手伝ったりしてくれたもう一人の同期に感謝。