#isucon に参加してやったこと思ったこと

isucon

ISUCONに@と「チームやすべえ」で参加してきたので、その感想です。

ひと言でいうと、良くも悪くもみんな積み重ねてきたものが結果に出たのではないかなと思います。

最初のボトルネックとして用意されていたクソクエリのチューニングは、二人ともDB寄りのエンジニアということもあって、クエリの意図をつかんだあとの対策はツーカーでいい感じでした。

ボトルネックがアプリに寄ってコア数でスケールする状態になったので、コア数も多く経路的にも有利なrevとdbにもアプリを立てて、そっちに多くのリクエストを振るようにしました。細かいチューニングを省略すると、これだけやっただけで、たしか参加チームの中で最初に50000req/minを超えたと思います。

あとは後半、かなり良いスコアを出すチームがちらほら出てきて、このアーキテクチャだと優勝できないと気づいて、キャッシュしてDBアクセスとレンダリングのコストを抑えようとしたけど、実装が間に合わずスコアを落としたままフィニッシュでした。

終わってみて、失敗したなーと思ったのが

  • キャッシュしたら負けかなと(ちょっと)思ってた
  • 特別賞の100000req/minを実現できるアーキテクチャについてちゃんと考察してなかった


日頃クエリのチューニングをしていて、まともなクエリを書けばキャッシュなどせずともアプリは十分速いという感覚を持っていて、良くも悪くもそれが出ちゃったなーというのと

特別賞として100000req/minというスコアが実現可能なラインとして提示されてたのに、それを実現できるアーキテクチャについて考察できてなかったのは、もろに結果に出たと思いました。

あとやっぱみんなコンテストに慣れてないってのもあったんだと思うけど、けっこうなチームが最終的にスコアを落としてたと思う。

あと記事とサイドバーのライフサイクルが違うからESIとかSSIで記事とサイドバーを分けてキャッシュできるといい感じなのはわかってたんだけど、ESIもSSIも実際に使ったことがなかったから動かせなかったときのタイムロスが怖くて選択できなかったんで(キャッシュしたら負けかなと思ってたせいで時間もうなかった)、ここでも積み重ねてきたものの差が出たところなんじゃないかと思った。

この教訓は今後に活かしていきたい。

まとめ

最後に、今回素晴らしいイベントを開催してくださったlivedoor様ありがとうございます！

次回は、ISUCON合宿やりたいですね。