ISUCON14 に参加し、惨敗した

Overview

• isucon 14 に参加した。
• 今年の目標は去年の点数を超えることと最終30位に入ることだった。
• 結果: 未達（惨敗）

やったこと

事前準備

• SRE のメンバーにインフラ関係のワンパン設定 playbook 及び監視環境、デプロイスクリプト等々を準備してもらう。
• 「イスワン(1時間等制限の中で初期準備を高速化するisucon)」を実施して環境設定周りの手順の統一化。
  • pprotein 等メトリクス系のライブラリ導入練習もここで済ませる。
• LLM にコードや改善点を吐き出させるためのプロンプト用意。

speakerdeck.com

当日

• アプリケーションコードの改善
• DB 分割 (web server 2台構成はうまくいかず撤退)
• インフラパラメータチューニング
• アプリケーション側のパラメータチューニング一部
• 一部データのキャッシュ化
  • ベンチマーカーの整合性チェックが合わず減点対象に。
  • この結果環境が壊れてしまい直せず。

結果

• 最終300点台。初期スコアより落ちる。
• 一時は上記改善をやって 14000点台くらいまで伸びて結構いい感じだったが、キャッシュ周りの実装をしたときに本番環境が壊れてしまいベンチマーカーが走ってもスコアが上がりきらなかった。

振り返り

良かった(と思ってる)こと

• 過去問解く時間を捻出はできなかったが、1時間でやることをチームで共通認識持ってすり合わせる 「イスワン」 はとても良い訓練だった。
  • 業務時間中でも1時間程度であれば取りやすく思いの他効果があった（と思う）
• 最初から DB を分割しなかったこと。ある程度1台でチューニングしきれるところまでやりきってお昼すぎくらいにDB分割したらスコアが伸びた。もともと MySQL のプロセスが支配的だったのはわかっていたけどその状態である程度チューニングして分割することでちゃんと因果を意識した改善ができた点は良かった。（反省点でも一部触れる）
• LLM を実戦投入できたこと。
  • アプリケーションコード(と SQL ファイル)をまるっと食わせて Index 提案して、というあたりは精度高くそのまま出力された create index を適用してもスコアには反映された。
  • N+1改善も Copilot と話しながらコード生成してもらったらそこそこいいコードが吐き出す事ができた。このへんは普段の業務でも Copilot に頼ってるいい面が出た。クエリ改善 -> コード改善系も難しいコードがなかったのも今年は良かったと思うけど Copilot は本当に偉大。

反省点

• アプリケーションコードであまり大きなボトルネックじゃないところを潰すのに時間を割いてしまっていた。特に全体のワークロード（アプリの仕様とも言えるけど）を理解せずにとりあえず非効率なクエリ直したり N+1 を改善しても数百点~1000点位の積み上げにしかならなかった = ボトルネックじゃないところを直しても意味はなかった。
• MySQL が支配的というのは最初にベンチ流したタイミングでわかっていたので今回に限っては DB を先に分割しても良かったかもなと思った（アプローチ自体が間違っていたとは思わないのでケースバイケースだけど）
• 「台数不足」のアプローチとして先に owner 側に手を付けず、ユーザーの体験を改善させる（レビューが悪いのはベンチマーカーのログからもわかっていた）方を先に対応するべきだった。
  • notification の改善が終わったタイミングで台数が足りないことがわかっていたので owner 登録改善でいけるのでは？と思ったけど、仕様には売上 UP -> 台数追加と書いてあるので売上 UP のための配車・乗車の改善にアプローチするべきだった。
    • ここはしたにはしたけど効果的な改善方法が見つからなかったというのはある。仕様の理解不足。
• マッチングの改善以外にもレギュレーションに記載されている内容の精査や理解の時間を取るべきだった。
• ベンチは常に回せるようにする。
  • 積極的に revert する。
  • ベンチ壊れた状態を長時間保持しない（改善を merge してもベンチ落ちるので意味がない。手持ち無沙汰の時間を減らす）
  • 可能であれば複数台構成にするまでは1台を dev 環境として使う等のルールを決めておく（デプロイスクリプトはそうしてもらってたけどちゃんとは使えなかった）
• パラメータチューニングもう少し頑張るべきだった。
  • 終盤、ちょっと行き詰まって次の一手が浮かばない時間があってもったいなかったので、実装側のパラメータチューニングにはもう少し意識を向けるべきだった。
    • retry interval を調整したことでスコアが伸びた箇所があったがそこしかチューニングしてなかった。
    • MySQL にしろ nginx にしろスコアに目を向けるのであればパラメータチューニングは王道なので、チューニングの余地があるところはもう少し手を出しても良かった。実際話を聞く限り 5000 点程度の上積みにはなったっぽい。

その他 (感想戦)

当日終了後社内の isucon 参加メンバーで打ち上げをした際にも話したし、Discord の会話も眺めてましたけど DB 分割と web サーバー複数台構成をもう少し早いタイミングでやっても良かったなということと、仕様（アプリケーションのレギュレーション）を理解する時間をちゃんと取るべきだったなと感じた。
仕様の理解については毎年課題を感じているし、今年も取っていなかった訳では無いが、8時間という短い時間の中でルールから加点ポイントを導き出すスキルはまだまだ足りてないと感じる。
ルール理解のプロセスも実際やっていたから一部のパラメータをチューンングしてみようという発想に至ったのは良いことでもあるけどそれ以外にも目を向けるべきだった。
この辺りは ISUCON14 が終わったあとメンバーとも話したけど、ベンチマーカーのログが大きなヒントになっているので、ベンチマーカーのログとレギュレーションを突き合わせて、スコアに効きそうなポイントを洗い出す時間は環境構築してる間にやったりとか、8時間全体のマネジメントには改善の余地があるなと思った。