今年もだめでした。無念。。
結果としては最高スコア 68,347 だったものの、最終ベンチマークでがfailしてしまってスコア0で失格となりました。二年連続のスコアなしはちょっと悲しいところですが、最後の一時間まで修正の反映をしていたので、攻めのfailなのでやむなしという感じかなと思っております。
ただ、本戦の最終状態のレポジトリをisucon11のAMIを使って3台構成を構築し、ベンチマーカー用サーバーも立てて実行してみたのですが、指定のエラーが出ておらず。。何度実行しても落ちることがなくなってしまい、どの設定がまずかったのか？などが闇の中に消えてしまったのは非常に残念でした。スコア公開当日にアクセスできる状態になっていたことを後で知り、間に合わなくて悲しみに暮れておりました。。
自分の担当範囲
自分のインフラ周りの知識がとても弱い自覚があったので、今回はインフラ中心をやらせてもらい、として以下のような作業の対応をしました。
- git, githubでの管理の対応
- nginx, mysql周りの設定変更（alp, slow query logとか）
- deploy スクリプトの調整
- 複数サーバー対応
- no1をweb, no2をDB, no3をapp（/api/announcements$ と /api/announcements/[A-Z0-9]+$）
予選より本戦が難しかった
予選問題が比較的いろいろな箇所でスコアを大きく伸ばせていたのに対し、本戦の問題は課題サービスがシンプルだったこともあり、大きくスコアを伸ばせるタイミングがかなり少なかったように感じました。（それ以外の改修をしていた影響もあるとは思いますが）スコアが伸びたのは主に複数サーバーの対応をしたときぐらいだったように思います。
ボトルネックは見えたが解消できなかった
ただ、DBに大きなボトルネックがあることや、そのボトルネックがどこあたりのクエリ・エンドポイントで起こっているかについては、そこそこ早めのタイミングで見えていました。それが他の方も触れている /me/grades のあたりです。
我々チームは真正面からクエリをどうにかできないか、という戦い方しかしていなかったのですが、他の方の回答を見るとDBの負荷を下げるということでレプリケーションをやるとか、キャッシュを試してみるとか、そういった回答の検討の余地はあったなーと終わってから感じたりしていました。あとは、思いついても「レギュレーション的にokと書いてないけどよい？」とか「そもそもレプリケーション構成の実装経験ないからやれるの？？」とかの胆力や経験値の足りなさも浮き彫りになったあたり、まだまだ修行が足りないなと感じました。
その他、経験値不足でハマった
MySQL 8系は（というか5系もわりと最近のはそうらしいですね）rootアクセスするときはsudoしないといけないらしく、それを知らずにMySQLのリモート接続ができなくて時間をかなりロスしてしまいました。また一つ勉強になった。
stackoverflow.com
というわけで今年のISUCONはこれにて終了です。来年のカレーおじさんにご期待ください。
