やったこと

nginx周りの設定
- gzip圧縮
errorsを入れた
- コケたときにログへスタックトレースを吐くように
N+1撤去
- getCategoryID()
  - 親を探しにいく過程で更に自分自身を呼び出してクエリを発行している。categoryをまとめて持ってきてメモリに保持すればよさそう（オンメモリ戦略）
  - getEvent()の再来か？と思ったけどそこまでボトルネックではなかったよう。pprofを見るとCPU時間的には支配的だが、直接的にレスポンスタイムへ影響を及ぼしてるものが他にあった
- getUserSimpleByID
  - これもN+1
監視体制
- alp
  - レスポンスタイム
- pt-query-digest
  - スロークエリ
- net/http/pprof
  - アプリケーションコードのボトルネック計測。ローカルでWebUIを起動していたせいかSourceが正しく表示されず焦った
- netdata
  - 結局スケールアウト構成できなかったのでHost1のnetdataの画面のみ見てた
- （prometheus + grafana）
  - 結局ほとんど見ずにnetdataのほうを見てた

やろうとしたこと

POST /buyとPOST /completeのレスポンスタイムが遅い原因の究明
- 明らかなデッドロックに気づけなかった…
- （実はこの2つは外部APIを叩いてる以上どうしようもないと思い込んでいた）
DBのインデックシング
- どこにインデックス作成すればいいのかよくわからなくてつらかった……
パスワードハッシュの変更
- pprofで見てもbcryptが支配的なのは明らかだったのでなんとかしたいという気持ちにはなった。
- 特に、パスワードハッシュ周辺について（特にbcrypt）は、ISUCON8の本選で言及されてるし明らかに典型なことはわかる
- ただ、POST /initializeでinsertしているユーザ情報はすでにハッシュ済みになってしまっているのをみて、「パスワードハッシュは変更できない」と判断して放置してしまった。後々考えてみれば新規登録の人だけハッシュアルゴリズム変えればよかっただけ。つらい
スケールアウト・ロードバランス
- Host 1: App + DB
- Host 2: App
- Host 3: App
h2oへの差し替え
- もともとh2oに差し替えるつもりだったが、upload周りでnginxに分があると判断してnginxの状態で進めた。結局upload周りは全くボトルネックになってなかったのでh2oにしたほうがよかったかもしれない。
redis
- いい感じに載せるものがなかった（というか載せる段階までいかなかった）

やればよかったこと

モジュール分割
- main.goﾄﾞｰｰｰｰﾝの状態で突き進んだのはミスだった（コードの見通しが悪かった）
- 責務ごとにざっくり分割しちゃったほうがよかった気がする
監視体制について
- せっかく準備したしダッシュボードも含めてちゃんと作ればよかった
- Stackdriver Profilerの導入
  - pprof勉強会で紹介されたけど結局使わなかった。他の人見てると使ってもよかったのかなーと（pprofの結果引き回すのに少し手こずったので）
全体的にもう少し初動をスムーズにしたい
- データを手元に丸ごとダンプしてくる（scp系）やつはシェルスクリプトにしておけばよかった（オペでやった結果、メンバー間でロックがかかってしまった）
- デプロイスクリプトは動くだけで、使いやすいとは言えない

感想

まず、初動に2時間もかかってしまったのは失敗でした。事前の準備不足が祟った形です。初動については入念にマニュアルを組んだり予行演習をすることで十分圧縮できた時間だと思うので、ここは次回に向けて改善しなければならないと思いました。

実は毎週定例MTGをしていたのですが、なんだかんだでメンバー全員でまとまった時間がとれず、まともな予行演習ができてませんでした。そのため、実質ISUCONをやったのは本番が初めての状態でした。

ただ、今回のISUCONで様々な改善点を見つけることができました。来年に向けての課題点がこれで見えました。

来年は本選出場してやるぞ

がべーじこれくしょん

技術系とかいろいろ

初出場のISUCON9で泣きながら椅子を温めました

やったこと

やろうとしたこと

やればよかったこと

感想