blog.syfm

徒然なるままに考えていることなどを書いていくブログ

ISUCON9 予選で負けた

今年も ISUCON に参加していました。メンバーは去年と変わらず @acomagu と @natumn。
去年は 👇

syfm.hatenablog.com

去年は温泉旅館に二泊三日で泊まり、中日で ISUCON をやっていて、その体験がすごく良かったので今年も旅館に泊まることにしました。
今回は土肥温泉の玉樟園新井という旅館で、部屋からは海を一望でき、蝉の声を聞きながら眺める景色は「理想の夏休み」感がありました。
朝・夜ご飯も海老や蟹などの海の幸が多くあり、どれもとても美味しかったです。

www.toi-arai.co.jp

やったこと

アプリケーションのバックアップ & Git リポジトリ化は @acomagu に任せ、ツールのインストールや、デプロイスクリプトの用意はだいたい自分が行っていました。
必要なツールは事前に用意してあった Ansible Playbook でシュッとインストールし、デプロイスクリプトも練習時に使っていたものを使いまわしました。自分たちが使っていた言語は Go だったので、サーバ環境向けにビルドしたバイナリや設定ファイルを Rsync を使ってデプロイしました。主に使っていたツールは pprof、htop、pt-query-digest、alp など。
自分が用意している間、他の二人にはアプリケーションコードを読んで問題点を洗い出してもらっていました。
初期ベンチが測れたのは開始一時間後くらい。

コードを読んだり pprof で見たりしていると、とにかく N+1 が多いことがわかり、まずはそこを地道に解消していっていました。
getCategoryByIDgetUserSimpleByID とかを解消したり、必要なインデックスを貼ったりしました。

このあたりで再度 pprof を見ると bcrypt が支配的になっていたので BcryptCost = bcrypt.MinCost に設定して負荷を減らしました。
カテゴリやユーザデータのインメモリ化を行ったりもしました。

最終的なスコアは 3610、最高スコアは 4110 でした。

今回は細かく変更を行ったり、複雑な箇所はペアプロしたりしていたのであまり迷わずにチューニングを進められたものの、キャンペーンや複数台構成を行うのを後回しにしたのが大きく響いてしまいました。また、インフラのチューニングを担当する人をちゃんと決めていなかったため、データベース以外はほとんどチューニングできていなかったのも反省すべき点です。来年はこのあたりを意識したい。
あと、今回の問題は非常に盛りだくさんの内容だっただけに、購入やキャンペーンでのユーザ行動の特徴などをしっかり分析する時間が確保できなかったのは悔しかったです。もっと余裕を持ってチューニングできるようになりたい…。


以下は旅行の記録です 📸

f:id:ktr_0731:20190911004111j:plainf:id:ktr_0731:20190911004021j:plain
f:id:ktr_0731:20190911005223j:plainf:id:ktr_0731:20190911004612j:plain

f:id:ktr_0731:20190911003814j:plain

f:id:ktr_0731:20190911004657j:plainf:id:ktr_0731:20190911004852j:plain
f:id:ktr_0731:20190911003848j:plainf:id:ktr_0731:20190911003904j:plain

f:id:ktr_0731:20190909220027j:plain