
ISUCON11 予選お疲れ様でした！
「都営三田線東急目黒線直通急行日吉行」というチームで参加し、予選 2 位で通過することができました。
チーム編成は 5 年連続同じメンバーで、[0gajun](https://twitter.com/0gajun) と [izumin](https://www.wantedly.com/id/izumin) の 3 人チームでした。

![ISUCON11_Portal](/i/ISUCON11_Portal.png)
[ISUCON11 Portal](https://portal.isucon.net/)

[ISUCON11 オンライン予選 予選結果と本選出場者決定のお知らせ](https://isucon.net/archives/56021237.html)

ISUCON7 以来の本戦出場で、またこのメンバーで本戦出場をきめられたこともうれしいですし、予選 2 位 / 100 万点越えを達成できたのも本当にうれしいです！

## やったこと

言語は Go で、middleware まわりはとくに変なことはせず nginx + MariaDB のまま設定だけいじってすすめました。
例年は Redis やオンメモリで大胆なキャッシュを試みることが多かったのですが、今年は大人な戦い方で堅実にスコアを伸ばせたのでとても満足しています。

正確に記録をとれていない面もあるのですが、箇条書きでやったことを列挙してみます。
作業 repository も公開する予定です。

- 初期スコア
  - 1803
- 10:38 いつものように実装だけみて足りない index をはる
  - 17124
  - 大体いつも、書き込みがボトルネックになったら見直す、という前提で雑につっこむ
- 11:10 postIsuCondition の INSERT をまとめる
  - ほぼ変わらず
- 11:20 getTrend の N+1 をつぶす
  - 18614
- 11:40 無駄な `SELECT *` を消す
  - 19240
- 11:58 keepalive と worker connection 追加
  - 20028
- 12:33 静的ファイルを nginx から配信する
  - 19300
- 13:07 各いすの最新コンディションを別テーブルに保存
  - 19936
- 13:12 index.html に cache-control
  - 25392
- 13:19 dropProbability を 0.9 → 0.7 に
  - 13084
  - 捌ききれなかったが、↓ の複数台構成とセットで伸びたのでヨシとした
- 13:28 DB を別サーバーに出して 2 台構成に
  - 31258
- 13:33 echo の余計なアクセスログを消した
  - 37395
- 14:00 リクエスト drop 時のログを消した
  - 40120
  - このあたりまではアプリケーションの CPU が限界だったので、ログをきるだけで大きく伸びた
- 14:11 condition_level を事前計算し、それをつかって filter する
  - 83782
- ??:?? このあたりで dropProbability を 0.7 → 0.4 に
  - 94000 くらい
- 14:45 グラフ生成時の SELECT を適当に 25 時間分にしぼる
  - 114958
- 15:03 25 時間分にしぼったつもりが、start 側しかしぼれていなかったので修正
  - 143372
- 15:11 `/api/trend` にほぼ同時に来たリクエストを束ねて計算を省略(singleflight)
  - 161966
  - 50ms スリープし、その間にきたリクエストに対して 1 回だけ trend を計算するようにした。
- 16:06 DB1 台、App2 台構成にした
  - 198583
- 16:16 書き込みが限界だったので、DB を 2 台にして最新コンディションのテーブルへの書きこみを分離 (DB, DB + APP, APP 構成)
  - 214492
- ??:?? dropProbability や Load Balancing の調整、middleware の設定をなんやかんやした
  - 30 万くらい
  - ここからひたすら書き込み負荷を減らす努力を開始
- 18:12 postIsuCondition の書き込みを非同期 & Batch 化
  - 372101
  - fail にびびって 10ms 以内の書き込みしかまとめないようにしていたが、もっと攻めたら書き込み負荷をより軽減できたかもしれない
- 18:15 isu_condition の timestamp sort をアプリでやることで index を消す
  - 400792
  - index をひとつ消すだけで 30,000 も伸びた。DB が完全に限界にきていて、これを緩和すればするほどスコアが伸びる状態。
- 18:19 slow query log などを disable
  - 593482
  - !?
- 18:30 interpolateParams=true
  - 1045520
  - !??!??

## すすめかた

インフラ的なパラメータ調整などは完全に 0gajun にまかせていたのですが、下回りでつまることが一度もなかったので感動しました。最終的につかわなかったのですが Redis の用意までしてもらったり、デプロイやプロファイルまわりの整備もやってもらい、アプリの改善が 120%活きる状態をつくってくれました。
例年は izumin の実装速度にものをいわせた飛び道具を仕込む戦いをしていたのですが、今回は大人にたたかおうということで堅実なアプローチを採用するよう心掛けていました。そういう堅実な手を数多くためすことができたのは、やはり izumin の手によるところが大きいです。Go への慣れという面でも頼りになりました。
このチームでまた本戦に出場できてよかったです。

手をつける場所の選定やコストのかけかたが今回はかなりうまくいった気がします。
グラフのところなんかは誰も最後まで仕様を正確には理解していなかったのですが、「ぱっと見いけそうだから雑に 25h でしぼってみる、だめだったらちゃんと理解してからやりかたを考えよう」で突撃したのがうまくはまったりしていました。25h なのは、仕様を理解していないので保守的にとってみたことの表れです。

マニュアルに書き込みを遅延してもよい、というような内容が記載されていたので、そこがキモかな、とおもっていたのですがどうだったんでしょう？
僕たちのチームは最終的には書き込みの負荷をいかに減らすか、というところが壁でした。
正直終盤の伸びは、自分でもなんでこんなに伸びたのかよくわかっていなかったりしますが、割とぎりぎりまでチューニングされていたからちょっと負荷がへるだけで大幅な伸びにつながった、と解釈することにしました。

## まとめ

最近の ISUCON ではいつもアグレッシブな最適化をした結果、謎 fail が発生するようになる、というパターンで苦しんでいたのですが、今回は fail に苦しまず最後まで改善をつづけることができました。
堅実に改善していったものがハマって最後に爆上げする、というパターンははじめて経験したのですが、最高に楽しいですね！

運営のみなさま、ありがとうございました！問題もわかりやすく、ボリュームもちょうどよくて、問いていてとても気持ちよかったです！
本戦もがんばります！

## おまけ

go1.17 から(フラグで有効にすれば部分的に) Generics がつかえるようになったので、実は前日まで Generics つかいたおしてみようか、という話をしていました。
~~意外とやりたいシーンがなく、~~ 結局お蔵になったのですが、izumin が Go Generics で snippet を用意してくれていたので、せっかくだし載せておきます。
(「やりたいシーン 4 回くらいあったぞ！！！！！ by izumin」 とのことです。)

[izumin5210-sandbox/go-generics](https://github.com/izumin5210-sandbox/go-generics)


ISUCON11予選に「都営三田線」で参加して予選2位で本戦出場きまりました!!


ISUCON 7 お疲れ様でした！

僕らのチーム，「都営三田線東急目黒線直通急行日吉行」は学生枠 2 位，全体で 10 位という結果でした．

予選の結果が異常によかったので完全に調子に乗っていたんですが，本戦はやっぱり難しかったですね... 本戦でも社会人上位勢と戦えるくらいのスコアを出すのと学生枠優勝が目標だったのでやっぱりくやしい．

### やったこと

結局テンパりすぎてスコア記録を残せていないので，なんとなく記憶を頼りに...

Go 実装でいきました．

- room 名から ws をつなぎに行くホストが一台に固定されるように
  - 同じルームの action は全部同じホストにいくように
  - これでオンメモリに出来るようにした（結局ほとんどオンメモリにデータは持たなかった）
- ルーム名から適当なハッシュ値を計算してふるようにしていたけれど，ルームによってアクセス頻度とかがちがうっぽい？ことに気がつく
  - 3 台に振ってるはずなのに，CPU 使用率を見ると 2 台しか使われていないとか
  - 負荷分散が運ゲーになっていて改善の結果が見にくかったので，とりあえず 1 台しか使わないように
- ホストごとの接続数を redis に入れて，空いていそうなところに振り分けるように
  - 前段のサーバに nginx + app + redis を入れて，そこの redis に room -> host の対応情報を入れた
  - CPU 使用率で振り分けたほうが良かったかもしれない
- schedule の計算過程を最適化出来る気がしなかったので，結果をキャッシュしようと試みる
  - どうやっても事後検証をパスできなかったので捨てることに...
- 部屋ごとにロックをとってすべての操作を直列にした
  - トランザクションとかが複雑すぎていじれる気がしなかったので，一旦直列にして考えることを減らそうとした
  - rollback 考えなくて良くなったのでこれ自体は良かった気がする
- @izumin5210 が adding/buying を redis にいれたり，過去の adding をまとめてくれた
  - ここは完全におまかせしてしまった
  - 最終的にまともに効いたのはこれだけだったのでは
- 終盤はベンチマーカに弾かれる原因をひたすら探していた
  - 安全側に倒そうということで，色んな所でひたすらロックを取るようにしてなんとかパスした

という感じで，最高スコアが 17000 くらい，最終スコアが 16700 で終了しました．

### 反省

- チーム名が長すぎた
  - 名札のチーム名部分のフォントが他のチームより小さかった気がする（ご迷惑おかけしていたらすみません...）
  - 手書きで書くのがつらすぎる
  - 来年は気をつけます
- テストがせっかく用意されていたのにまったく使わなかった
  - テスト使っていたらもうちょっと計算過程の最適化にも手を出せたかもしれない
- なにも操作がなくても 500ms ごとに status を計算していたところの最適化を入れきることができなかった
  - この計算は room ごとに一回やれば良いはずなのにコネクション一個につき一回計算していた
  - room ごとにひたすら status を計算し続ける goroutine を起動してそこから返す実装を書いていたが，終盤の fail 祭りにびびっていれられなかった...
  - 意味があったかどうかはよくわからない．
- CPU profile をみて，bigint の計算がやばいことはわかっていたのに，手が出せなかった
  - この複雑さは結果をキャッシュしろってことだな！って勝手に思い込んでいたけど，結果のキャッシュも複雑で無理だった
  - 他のチームの方の話を聞く限り，そんなに無茶な最適化じゃなくても地道に最適化していたらそれなりにスコアに効いたのかもと思った（これはやってみないとわからないけど）

予選のときも練習のときも，「遅いのはわかっているけど複雑そうでやりたくない」部分を触らないとだめっていう教訓は得ていたはずなんだけど，結局そこでやられてしまったのが一番くやしいですね...

来年は学生枠ではなくなるのですが，社会人枠でも本戦にでて勝ちたいです！

去年に引き続き本戦に出られたのはほんとうに良かったし，またまた勉強になる良い経験でした！運営の皆様お疲れ様でした ＆ ありがとうございました！

---

COMMENT:
AUTHOR: davidcruise
IP: 117.98.190.10
DATE: 11/27/2017 21:25:12
[pc kik](https://www.kikforpcapp.com/kik-for-pc-windows-xp788-110-free-download/) article on an innovative messaging amenity that is continually on, permanently linked with fast and unswerving than any added applications that are existing due to some of the following reasons.

---

---


ISUCON 7 本戦出場してきました 「都営三田線東急目黒線直通急行日吉行」


ISUCON7 予選お疲れ様でした！
タイトルどおりですが，「都営三田線東急目黒線直通急行日吉行」という学生チームで参加し，1 日目 3 位枠で通過することができました．
チーム編成は，去年 2 人チームで参加したときの相方である [0gajun](https://github.com/0gajun) と，僕の内定先の同期の [izumin](https://github.com/izumin5210) の 3 人チームでした．

何をやったかとかスコアの変遷は別で記録したいと思います（僕一人で把握しきれていないので）が，とりあえずリポジトリはここです．

[github.com](https://github.com/agatan/ISUCON7-qualify)

追記: タイムラインと詳細はこっちに書きました

[www.wantedly.com](https://www.wantedly.com/users/17993775/post_articles/81190)

![f:id:agtn:20171023153909p:plain](/i/20171023153909.png "f:id:agtn:20171023153909p:plain")

去年 2 人で参加した時は学生枠で予選通過はできたものの，一般枠との圧倒的なスコア差にだいぶ打ちひしがれていました．
もともと，「0gajun がインフラ，僕がインフラ寄りのアプリ」というチームだったので，アプリ側をがつがついじれる izumin が加わったことで，チームバランスが良くなった + 手数が圧倒的に増えたと思います．

去年とくらべてメンバーも増えたし学生とはいえ一年間で成長している（はず）というのもあったので，夢として「学生枠だけど一般枠と戦えるスコアを出したい」というのがありました．
結果，予選 1 日目上位 3 チーム枠で本戦出場を決められて本当にうれしかったです．2 日目の上位が圧倒的なスコアだったのでちょっと凹みましたが，全体でも 10 位くらいだったと思うので，目標は達成できたと思います．
また，無理やり ISUCON 特化な高速化を入れたりすることなく良いスコアを出せたと思うので，そこも良かったなと思っています．
本戦でも良いスコアが出せるように頑張るぞー！

最後に，ISUCON 運営の皆様，本当にお疲れ様でした & ありがとうございました！
予選から複数台構成で面食らいましたが，複数台は難しい分，楽しさも増すし勉強になることもたくさんありました！
本戦も楽しみにしています！

---

---


↗ agatan blog ↗

#ISUCON

ISUCON11予選に「都営三田線」で参加して予選2位で本戦出場きまりました!!

ISUCON 7 本戦出場してきました「都営三田線東急目黒線直通急行日吉行」

ISUCON7予選1日目に「都営三田線」で参加して通過できた話

#ISUCON

ISUCON 7 本戦出場してきました 「都営三田線東急目黒線直通急行日吉行」

ISUCON7予選1日目に「都営三田線」で参加して通過できた話

ISUCON 7 本戦出場してきました「都営三田線東急目黒線直通急行日吉行」