ISUCON10に参加し撃沈しました

今年もISUCONに参加し、最終スコア1090でさっぱり敗退しました。
今回は反省しかなく2日たった今でもふとした瞬間に「あー」という声を出しています。

やったこと

インフラの整備やボット対策は@srphcrがやってくれていたりしたのですが、私がやったことを中心に書いていきます。

まずは手元で開発できるようにしたり（といってもほぼMySQLのDockerを用意するだけでした）、NewRelicのエージェントをアプリに入れたりと諸々の初動をやっていて、この辺は特に問題なく進みました。
余談ですが今回アプリの監視に、無料枠の提供もありNewRelicを使ったのですがとても使いやすかったです！Railsのアプリでも試してみたい。

で、コードやテーブルを見ながら「DBいろいろやりがいがありそうだなー」なんて話をしていて、ベンチを回してみたらイスと不動産の検索APIがかなりの割合のトランザクションを占めていたので、まあまずはDBにインデックス貼りながら何やっていくか考えましょうかーという感じで動き始めました。

こっからが大反省なのですが、各検索APIのレスポンスタイムを見ていると、遅くても1秒前後では返せていたし、データの件数も各テーブル30,000件くらいだったので「もしかしてここがボトルネックになっているのは実は問題ないのでは？」と考えてしまいました。
というのが、これまでのISUCONだと遅いエンドポイントはレスポンスタイムが数秒から数十秒かかったりすることもあったので、1秒前後という数字がさほど問題ない数字に見えてしまったのです。

ここからは完全に迷走を始めてしまい、「これはより効果のあるイス・不動産を表示できればスコアが上がるという問題なのでは？」という仮説のもと
・ベンチマーカーの行動をトレースするためにセッションを付与しようとしてみたり（ベンチマーカーがクッキーを送ってこなかったのでこの作戦は無になった）
・売れたイスや資料請求された不動産の傾向を見ようとしたり（poplularityが高いものが売れるということしかわからなかった）
・アクセスログを眺めたり（本当に眺めただけになった）

そんなこんなしてるうちにそこそこな時間になり、これはまずいということでとりあえずわかりやすくN+1してたなぞって検索を@risouの助言のもと改善したりCSVのINSERTをBULK INSERTに書き換えてトランザクションを削除してみたりしたらスコアが上がり始めました。

「あれ、これやっぱりDBを改善していく問題だったのでは？」と思い直して見ていくと、諸々直したい箇所が浮き彫りになっていったのですが、「この時間からは直しきれないよなあ」という悲しい気持ちになりました。
最後NewRelicを消したりもろもろお掃除してスコア1090になったところで試合終了でした。

反省

今回の敗因は私がアプリのボトルネックを放置したことでした。
過去のISUCONで遅いエンドポイントが数秒〜数十秒だったからといって今回のISUCONで1秒前後のレスポンスタイムを許容していい理由にはなりません。

これは実際の業務でも同じです。システムの特性や事業のフェーズによって許容されるレスポンスタイムは変わってきます。
過去に携わったシステムが数秒程度のレスポンスタイムを許容していたからといって、今携わっているシステムでもその程度は許容される、というわけではありません。

ボトルネックはボトルネックなのです（それはそう）。過去がどうだったかはある程度参考にしつつも、やはり大事なのは今目の前で起きている問題に正しく課題設定することです。
今回のISUCONではそれに完全に失敗してしまいました。

この失敗を胸に1年間過ごしていきたいと思います...