今年もISUCONの季節がやってきました。以前組んだメンバー「忠で焼酎を飲んでいた人たち」を再度結集して、我が家に集合して臨みました！
概要
- 土曜日組
- Rubyで参加 (今回は多分どの言語でも大きな差は出なかった気がする)
- 最終構成は、DB1台・APサーバ1台の2台構成
- 5,010 イスコインでフィニッシュ！
やったこと
- ドキュメントを刷って挙動を全員で理解する (刷ったのは良かった)
- DBのテーブルへ組み合わせIndexを含めたIndexを張る
- masterをプログラムのオンメモリにキャッシュする
- settingsをMySQLのMEMORYストレージに突っ込む
- トランザクションが少しでも短くなるようにAPIタイミングを見直す
作業時に、危うくインスタンス起動の設定を間違えて失格になりかけました。ドキュメントに言及されていたチェックプログラムをきちんと回しておいてよかったです。
反省点
問題を見た瞬間、ああ、これどこかで見たことがあるコードだなと思いました。ただ、なんの問題が出ているかがわかっていても、どうやって攻略すればいいかがわからないところが悩みでした。
はっきり問題だと認識できたのは以下の3点でした。
- BCrypt() が遅い
- 負荷を高めたときに /buy にアクセスが集中してロック待ちの行列ができる
- 外部API呼び出しのレイテンシ自体は上がらない中でどうやって高速化するか
BCryptが遅いのは、他の人が計算機の並列度を上げて対策しているのを見て、あー、nginxの設定で負荷分散をする設定がスムーズにできないのがあかんかったなと思いました。
/buy の競合も、DBのロックの競合なのだということがわかっても、それが innodb_lock_wait_timeout ＋メッセージの変更で対処できるってのに気づくことができませんでした。
また、プロファイラの実行のときに、うまく実行できなくて情報を適切に抽出できていなかったのは練習が足りなかったのかもしれません。他にも、アクセスログの集計だけだと問題点を解像度高く分析することができなくて、なかなか難しかったように思います。
感想
仕事でコードは触っているのですが、この3年、ミドルウェアの設定や、コードのチューニングにあまり力を注いでいなかったんだなという反省点が浮き彫りになった日になりました。
言い換えれば、ISUCONという競技を通じて、こういった技術に改めて目を向けることができる機会を頂いていると考えることもできます。
チームの反省会は後日行う予定です。
ISUCON運営の皆様、大変貴重な会を設けていただきありがとうございました！お疲れさまでした〜