はじめに

2020/9/12に行われたISUCON10に参加しました。そのときにやったことや感想などを備忘録として残します。

チーム構成

最大3人で参加が可能ですが、今年は1人(チーム名: takoshi)で出ました。理由は

誘ったはいいものの何も成果が生まれないと申し訳ない気持ちで死んでしまう(去年がそうだった)
複数人チームと比べたアドとして、1人だと作業のコンフリクトが発生しないので思ったことをすぐ試せる
シンプルに友達が少ない

という感じです。言語はGoかRustで迷いましたが、修正をシュッと反映できそうだったのと、Goのほうが書きなれているのでGoでいきました

やったこと

何をどの順番でやったかはそんなに記憶していないので思い出せる範囲で箇条書き

計測コードを挿入して動かす。初期スコア480くらい
/api/estate/searchと/api/chair/searchが重そうだったのでコードを読むが、自明な改善点が見つからなくて困る。適当にインデックスを張った。
ベンチがバグってたりしてアプリケーションコードの変更が試せなかったので、この時間を使って複数台構成にしておいた。
マニュアルを良く読むとBotからアクセスがいっぱい来るらしいのでnginxで弾くように修正。割とスコアが伸びた。
ベンチマーカーの出力をみると「なぞって検索」のレスポンスおそすぎることがわかった。元のコードでは多角形の内部に物件があるかの判定をMySQLに投げていたが、MySQLはCPU張り付いている状態 & N+1だったのでアプリケーション側でやることに。ここで競プロをした。
相変わらず/api/estate/searchと/api/chair/searchが重いが、ブレイクスルーできるだけの改善は思いつかなくて本当に困っていた。
困ったので色々観察することに徹し、以下のことが判明
- サーバリソースはCPUが1コア、メモリ2G
- mysql専用サーバーのCPUは常に100%近く張り付いていてヤバそう
- アプリのサーバーはCPU/メモリともにかなり余裕がある
- データ更新系のPOSTはそんなにこない
Redisに乗っけるオンメモリ戦略でいくことを決意 (この方針にたどり着くまでにかなり時間がかかった)
リクエストパラメータが一緒ならredisから返す + POSTでデータ更新されたらredisの中身をクリアする処理をいれるとそれっぽいスコア改善があり嬉しい気持ちになる
が、相変わらず/api/estate/searchと/api/chair/searchが重い。リクエストパラメータ単位ではなくもっと細かな粒度でオンメモリにすればスコアが良くなることが想像できたが、そこまでやっている時間がなく最後の方はmysqlやnginxのパラメータ調整 + このブログを書いて終了
最終スコア: 1461 (max: 1503)、凍結前順位: 500チーム中35位前後最終順位: ？位