ISUCON14で惨敗してきました
ISUCON14に参加して惨敗してきました。repoは以下です。
ざっくりやって割とうまくいったことを書くと以下です。
- matchingをHTTPリクエストではなく、Goのtime.Tick経由に変更
- 少しロジックを変えると30秒間マッチできないユーザーが現れてcriticalで落ちるので、一旦変更を保留
- getChairStatsのride_statusesのN+1クエリを改善
- （チームメイトが）chair_location更新時にtriggerで距離を保持しておいて、スロークエリを潰す
- appGetNearbyChairsで椅子全件を取得せずに
WHERE is_active = 1を付与する
そして失敗したのは以下です。
- ownerGetSalesのN+1クエリを解決しようとして、どうしてもresponseが同じにならず、数時間を溶かして失敗
- chairの現在地をchairテーブルのカラムに入れて、appGetNearbyChairsで引いてくる椅子の量を減らそうとしたが、減点が増えてスコアが変わらず、断念
- 初期データを入れるのが面倒で、初期データが壊れていたような気もする
という感じで、自分の大きめの変更は失敗して、小さめの変更を入れていくしかない状況でした。
最後にMySQLを専用サーバーの切り出したところ、notificationsの負荷が上がり、スコアが安定しなくなり、1万点を超えたり、0点になったりを繰り返していました。最終的に少し速度を抑えて9884点が出たので終了にしました。
感想
惨敗でしたが、問題は非常におもしろかったです。単純にN+1クエリを解消すればいいのかと思いきや、ロジック的にそう簡単に解消できないクエリで、頭を抱えました。キャッシュで簡単に解決できるような箇所も特になく、小手先で改善を進められる問題ではないことに早い段階で気付けていたので、すごい問題だと思いながら解いていました。
問題の制約も実際のWebサービスにありそうな制約ばかりで、リアルに感じてワクワクしました。競技だから何でもいいではなく、実際にありそうなリアルも追求されていて、そしてベンチマーカーが厳格で変更する度に必ず阻まれ続けていました。
問題の雰囲気的に、自分が以前作ったISUCON9予選に似た要素もありましたし、他の過去問のエッセンスも一部取り入れられていると感じました。しかし、似た要素はありつつも、過去の問題を明らかに超えており、更に上の問題を狙ったことがすぐに分かりました。
マッチングをさせないといけないというのは過去なかった新しい要素で、アプリケーションの仕様を理解して、仕様から最適化をしないと進められないというのは新しいISUCONを感じました。この仕様にもリアルさを感じ、実際のWebサービスにありそうで、よくできていると感じます。
問題の質といい、量といい、過去一の完成度ではないかと感じています。全然解けなかったので、これからやりこんでいきたいと思います。運営の皆様、こんな素晴らしい問題と運営をありがとうございました。
Discussion