ISUCON12 予選に出場した

メンバー

• @nakadei
  サーバー系インフラをめちゃくちゃやってくれる
• @RaimuErt
  コードリーディング&コーディングをめちゃくちゃやってくれる
• @kill_in_sun
  　インフラからコードまで一通り手を付けるけどどれも中途半端で悩んでる

最終スコア

6,412 点で、 大体 153 位ぐらいでした。

やったこと

(10:00 ~ ) 開幕

• マニュアルを読みつつ、開幕速攻で AWS に構築と git リポジトリを準備。
• アプリをローカルで実行しようと構成を確認していたが、mysql + SQLite + docker の組み合わせで嫌な予感がしたので早々にやらない決断をする。

(10:30 ~) 準備が整う

• 初回ベンチ実行後、スロークエリの設定を行い、ベンチ実行してリソースの使い具合と SQL の状況をみる
• Raimu たんが alp 仕込んでくれたのであわせて状況みる

(11:30 ~ ) データベース周りの改善に乗り出す

• スロークエリログをみたり、explain コマンドの結果から、インデックス貼ったほうが良さげなクエリをみつけたので教科書どおりにインデックスを貼る。 1 回あたり 10 万行のアクセスを 2800 台まで落として満足する
• テーブルへ 100 回 Insert してユニークな ID を取得するというなんとも不思議なコードを発見。多少時間かければ自分でもいけそうな気はしたが、他にも気になることがあったり、意図を読み取るのに時間がかかりそうなので、Raimu たんに任せたほうが早いと直感。「めちゃくちゃ変なコードがある」と知らせてヘルプを依頼した。
• チーム内で 「SQLite 辞めて mysql に移行したほうがよいのでは？」 という話も度々出たが、この時点では直接的な速度アップにつながるわけでもなく、移行におけるハードルが今の自分たちにはハードルが高すぎるから SQLite のままでいく決断をした。

(12:30 ~) メンバーごとにやることが分かれてきた頃

スロークエリを取り直し、下記のサマリを見てvisit_history 周りのクエリが依然として多いのが気になったので小一時間チューニングを試みるが、これ以上はよくならなそうと諦める。 回数は多いものの、実行時間がそこまででもないのになぜこれ以上なにかしたほうが良いのかと思ったのか、今でもわからない。

# Rank Query ID                      Response time Calls R/Call V/M   Item
# ==== ============================= ============= ===== ====== ===== ====
#    1 0x676347F321DB8BC7FCB05D49... 57.9861 82.2%  3121 0.0186  0.25 SELECT visit_history
#    2 0x2E69352DE16B15042A121750...  8.6719 12.3%   839 0.0103  0.00 INSERT visit_history
#    3 0x3289E87E94D5A82E348974B3...  2.5918  3.7%     1 2.5918  0.00 DELETE visit_history
# MISC 0xMISC                         1.2743  1.8% 16703 0.0001   0.0 <10 ITEMS>

(13:00) billingReportByCompetition の改善に乗り出す

マニュアルの内容と、計測データの結果から、ボトルネックの一つになっている billingReportByCompetition の改善である程度スコアに乗るのではないか？とこのあたりのコードを読む。

この頃から 不思議なオレオレトランザクションの存在に気づくが、SQLite のお作法なのかと勝手に信じ込んでしまって正しいトランザクション化したほうがよい事に終盤まで気づけずにいた。

改善しようと手を付けたものの、時間がかかりそうだったので諦める

(15:00) N+1 を潰す（が徒労に終わる）

コミュニケーションミスで Raimu たんとほぼ同じところの N+1 を対処していた。悲しい。申し訳ない。

終盤

前半の勢いとはうって変わり、集中力切れと熱量切れがでてきてしまい、何をするにも手がつかず・・・という感じだった。 チームとしてはアプリと DB の分離や、他の N+1 対処にあたっていたので大体 4,000 点から 6,000 点ぐらいまで伸びた。

最後の方になってファイルロックの部分なんとかしないとスコア伸びないだろうなとおもいつつ、やる時間もなく途方に暮れていた。

反省点と次回に向けたメモ

• 作問の意図どおり、「準備してきたであろう mysql の知識が使えない」状況は正直本当に辛かった。
• チーム全体で取り組んでいたこと、目の付け所は悪くなかったが、おそらく個人それぞれがマンパワーに限界を感じるタイミングがちょこちょこあったと思う。ただ、去年までは「そもそも何していいかわからん」状態だったので、やるべきことが見えた分、それを実現するためのスキル不足を個人的に強く感じた
• 「推測するな、計測せよ」はちゃんとできたと思う。計測した結果は早とちりで読み間違えないようにしよう
• 早々に SQLite を移行しない決断をしたのは良いムーブだったと思う。その代わり、早く決断した分、 SQLite 単体のチューンナップの調査に時間をかけていればよかったのかもしれない。（ファイルロックの部分然り）
• 近年の ISUCON はローカル起動が難しいものが多く、手元で挙動を試せないのも改善を完了する時間がかかる要因の一つだと思う。この辺は別の方法だったり、基礎力強化だったり、トレース力を強化するなりしないと太刀打ちできなさそう
• jwt は全く手つけてなかった。去年から自分で実装して仕組みは知っているのに・・・。全くもって忘れていた。

/以上