guri3.dev
Published on

ISUCON14に参加した

香る明治屋ガロファロというチームでISUCON14に参加しました。最終スコアは7,187でした。
前回のあらすじはこちら

事前準備

ほとんど前回のISUCON13で準備したスクリプト・Makefileを流用する形で行いました。
利用ツールも変わらず以下のようになっています。

  • alp
    • アクセスログ解析用
  • pt-query-digest
    • スロークエリログ解析用
  • notify_slack
    • ログ集計結果のSlack通知
  • top
    • ベンチマーク実行中のマシンの状態を確認

自分が当日やったこと

10:00~12:00

用意してきたスクリプト・Makefileを使って最初に行う各種設定を行いました。 素直に実行するだけでは動かないものがいくつかあり、想定より時間がかかってしまいました。

特にMySQLのスロークエリログの設定がうまくいかずにファイルの権限を色々触っていたら、意図しない変更を加えてしまい一度スタックを作り直すということもしました... 完全に素振り不足が露呈していて、今回の大反省ポイントです。

12:00~14:00

MySQLのCPU使用率が大きく、スロークエリログにも明らかに重いクエリが存在していたので、それらにindexを貼っていきました。あとは一通り重いクエリを倒した後に上がってきたPrepareを倒したりしました。このタイミングで大体3,500くらいになっていました。

14:00~16:30

MySQLのCPU使用率が依然として高かったので、DB分割をしてしまおうということで作業に入りました。DBの向き先を変更すること自体はすぐに出来たのですが、この変更の影響でベンチマークが椅子がライドの完了通知を受け取る前に、別の新しいライドの通知を受け取りましたや椅子に想定していないライドの状態遷移の通知がありましたというエラーを返すようになり、このエラーの解消にめちゃくちゃ手こずりました。

まず、DBの向き先を変えただけでエラーが出たので、他に何かまずい変更をしてしまったのか？というのを確かめるために向き先を直して検証をしたりして時間を取られてしまいました。椅子への通知やマッチングのポーリング速度を変えたりしても解消せず、よくよくエラーを読んでみると、マッチングの順番がおかしいのか？というのに気付き/api/internal/matchingを見に行きました。イスのステータスに関わらずライドにマッチしてしまう実装になっていたので、ステータスを見てマッチングするようにしたらひとまずこのエラーは解消しました。

ただ、DB変更のせいでこのエラーが出てくるという根本的な原因を理解することは出来ていなかったので、この後もモヤモヤする形で進めることになってしまいました。また、DBの分割には成功したものの、それまでチームメイトがあげていた5,000から2,000ほど上昇した7,000くらいにしかスコアが上がらず、根本的なボトルネックは直接MySQL側には存在しなさそうだなという形になりました。

16:30~17:30

チームメイトが/api/chair/coordinateの改善を行っていたので、自分はそれ以外をやっていこうとなりました。DB分割によってスコアがあまり上がらなかったので、アプリケーションのロジックに手を入れる必要があるのでは？と考えてマッチングの改善を行いました。

まずは愚直に最も近いイスからマッチングするようにしましたがあまり点数は変わらず。イスの速さを考慮したマッチングにしてみるも、こちらも点数はあまり変わりませんでした。結局いい感じにマッチングを改善することは出来ずに事前に決めていた時間になってしまったので後片付けに入りました。

17:30~18:00

nginxのアクセスログやMySQLのスロークエリログを無効にする作業を行いました。MySQLのスロークエリログをoffにするとベンチマークがfailするようになってしまったので、結局スロークエリログはそのままで最後のベンチマークを回しました。パフォーマンス起因のベンチマークエラーの原因をうまく特定出来なかったことを最後まで引き摺ってしまったなーと思いました。

反省

事前準備、当日の進め方ともにたくさんの反省ポイントがある回となりました。

  • 初回ベンチマークまでの流れはノーミスで。素振り&事前の準備をしっかりやる
    • 複数台へのデプロイ作業なども今までは当日よしなにで進めていたが準備する
  • スロークエリログやアクセスログの単純な集計のみだとアプリケーションの挙動に対するチューニングが出来ない。ベンチマークがどういう動きをしているか？というところの追い方を理解・練習する
    • プロファイリングのツールなども見直したい
  • DB分割に手を出すのが早かった感。うまくいかないならDB分割を無理やり通しに行かずに根本的なロジックを理解しに行くべきだった
  • シンプルにGoの実装力が足りなすぎる

感想

悔しい結果となりましたが、解きがいのある問題でとても楽しかったです！
しっかり反省して次回リベンジできるよう頑張ります。