言語は Go、最終スコアは15532点、参考スコアを上から数えると45位だったようです。悔しい。
具体的な取り組みは下の方で述べますが、MySQL移行はバグなく完遂し、さてここからチューニングしていくぞ！という感じのところで終わりました。エンジンが掛かるまでの速度が足りなかった。

毎回、運営の皆様にはいくら感謝しても足りませんが、今回も取り組みがいのある問題で楽しかったです。ベンチマーカーも最後まで待ち時間がほぼなく、スコアも安定していたのでとてもストレスフリーでした。ありがとうございました。

マルチテナントで大量の SQLite3 データベースがあることが分かったとき、ISUCON本を読んだだけの人間には解かせないってことね!と思いながらニコニコしました。

ところで知り合いがたくさん著者に名を連ねているISUCON本ですが、予選の2週間前に購入し、予選開始1時間前に部屋から発掘されました。
30分ぐらいで流し読みしたのですが、大変実利的な内容に溢れているなあと感じました。nginx の upstream で keep-alive を有効にする方法は知らなかった……

9:00 起床

前日も早く寝るぞと自分に言い聞かせながら4時半まで起きてしまい、念には念で8時に掛けた目覚ましが1時間鳴っていました。すでにこの時点で心も体も終わっています。

部屋の隅にISUCON本が積まれているのを発見しました。ちいとぽも積まれています。
h-otterと合流するために移動しつつ、パラパラと眺めます。

10:00

まだ合流のため移動中ですが予選が始まっているようです

10:05

合流しました。 CloudFormation テンプレートを流します

10:22 初回スコア 2732

起動したのでベンチを回しました。この時点で分担も何も決まっていません。

とりあえず kataribe を入れたり pt-query-digest を入れたりします。
「そういえば先日の社内ISUCONで Cloud Profiler 便利だったな……」みたいなことを思いながら、入れ方を調べます。
GCPプロジェクトが必要らしいので作ったり、サービスアカウントキーを発行したりします。予選始まってからやることではない。

11:30ごろ

Cloud Profiler を入れたので眺めました

12:00

h-otter が MySQL 対応の実装を終わらせて、「Uber eatsでも呼ぶか〜」と言いながら、なぜか歩いてマクドナルドに飯を買いに行きます。なんで??

13:03 MySQL移行 3023点

MySQL移行が一段落します。今思うと速かった。

sqlite から SQL をダンプしてゴニョゴニョやり始めて十分程度経ったあと、 sqlite3-to-sql って名前のスクリプトあるけど?? と気付いて笑ってました。先に気付こうね。

とりあえず MySQL に流し込むこと数分、INSERT が一向に終わらないことに気が付きます。このままでは POST /initialize がタイムアウトしてしまうため、バルクインサートをするクエリに書き換えることにしました。

sed で気合でバルクインサートに書き換えましたが遅い。ここで1台目のインスタンスがメモリを食いつぶして死にます。160万件のINSERTを一発でやると死ぬことが分かる。
先日の社内ISUCONでもインスタンスのメモリを食いつぶしたんだよな……と思いながら1台目を捨てます。

これが答えです。

for i in `seq 1 100`; do echo $i; mv $i.sql $i.sql.bak; sed -z -e "s/);\n/);\n\n/" -e "s/NULL\n);/NULL\n);\n\n/g" -e "s/);\nINSERT INTO [a-z_]* VALUES/)\n,/g" $i.sql.bak > $i.sql; done

それなりに早くなりましたが、まだ遅いので tenant の player_score テーブルにおいて、 updated_at が一定以上のレコードを DELETE する作戦に切り替えます。これで10秒程度で POST /initialize が通るようになりました。

DELETE FROM tenant_X.player_score WHERE updated_at > 1654041599;
DROP TABLE tenant_X.competition;
DROP TABLE tenant_X.player;

他のチームの参加記を読んだら 「/var/lib/mysql をコピーする」「毎回 mysqldump を実行する」みたいな筋肉実装が多くて震えました……

確かここらへんで h-otter がなぜか flock を倒す実装を書くもベンチがコケました。
「そこはボトルネックじゃないっぽいし一旦revertしよ?」と、人の競技中の努力を無に帰すような心無い発言をしました。ごめんなさい。

なぜかここからしばらく無の時間が続きます。なぜ……

15:20 3758点

h-otter が competitionRankingHandler の N+1 を潰したようです。

15:50 6336点

グッとクエリを睨んで indexを追加。playerAddHandler がかなり速くなりました。

ALTER TABLE visit_history ADD INDEX (competition_id, player_id, created_at);
ALTER TABLE visit_history ADD INDEX (created_at);
ALTER TABLE tenant_X.player_score ADD INDEX (competition_id, player_id, row_num DESC);

マルチテナントのDBをそのまま持ってきたので、tenant_id は無視するようにしました。

16:08 7923点

h-otter が playerHandler の N+1 を潰したようです。

そして player_score に index を追加。
ALTER TABLE player_score ADD INDEX (player_id, competition_id);

バルクインサートと、JSONシリアライザの変更(encoding/json → goccy/go-json)をした結果、スコアがやや増加しました。(8269点)

16:36 10253点

なんかヤバそうな実装の dispenseId を倒しました。1万点突破。
よくわからんけど順序保証されてたほうが良さそうな気がしたので、 time.Now().UnixNano() を文字列にしてそのまま突っ込みました。爆速。

たしかこのあたりで、 tenant の player_score は (tenant_id, competition_id, player_id) ごとに最新の1行だけあればいいことに h-otter が気付きましたが、あまり速くならず。
この時点で row_num に関する index を落とすべきでした。

既存の tenant_{1..100} に対してもそれを適用しましたが、スコアとしては特に変化なしでした。

このあたりでベンチマーカのログから、タイムアウトでユーザーが減ったという表示がなくなり、ようやくISUCON始まったな! という気持ちになります。すでに手遅れ。

17:03 12505点

h-otter が jwt のパース結果をキャッシュします。神

17:45 14363点

app + DB の2台構成にした気がします。

17:50 15962点

流石にやや諦めムード。ログを切ったりできることをしました。
忘れずDEBUGログを切ったりスロークエリーを切ったりしました。偉い。

「再起動試験はしなくていいでしょ！」で終了

感想

1. MySQL 移行をバグらせずに完遂できた俺達は偉い (本当に偉いと思っている)
2. 毎回意味不明なバグを仕込んで後半暗澹たる感じにあるので、今回はほぼ最後までノーバグで駆け抜けられたのは良かった。良くも悪くも我々は大人になった
3. プロファイラ / スロークエリ / アクセスログの3本柱をちゃんと見ながら走れたのは本当に良かった。常に事実は正しい。fact based / metrics-driven
4. 後半のスコアのブチ上がり方が楽しかった。というかここに来るまでを自分は第一関門を突破した段階だと思っている。やれる改善はたくさん残っていたし、あと1時間あれば更に2倍, 3倍のスコアは出ていたんだろうなと思うと悔しい

そのほか

1. 午前中からの競技は本当に心も体も終了していて何も捗らなかった。ISUCONに必要なのは健康な心と身体
2. デカいテレビで h-otter がリゼ・ヘルエスタと名取さなの原神ガチャ配信をずっと流していた。「縁起がいいと思ったんだけどなあ」って何?
3. その後はリゼがパワプロしてた。リゼ・ヘルエスタについて私が知っているのは第一第二第三皇女のいずれかであるということぐらいです。
4. 最後1時間ぐらいローテンションお嬢様 (壱百満天原サロメ)流したら集中力が0になった。何?

前々回再起動試験で落ちたのでチーム「再起動非対応」で参加しました。チーム名は前日まで考えていましたが変えるのを忘れました。
言語はGo, ベストスコアは2101, 最終スコアは1997で、多分40位ぐらいでした。悔しい〜〜

本チーム「再起動非対応」は同期3人 (自分 @kyontan, @hogashi, @h-otter) です。このメンバーで4回目の参加です。学生はうち2人なので、一般チームです。

今回は直前まで対策が無で、前々日ぐらいに「そろそろ予選ですね」みたいなことを言ったら「前日は酒を飲む予定があるんだった」みたいな感じになり、そういえば僕も酒を飲む予定があったわね……という感じでした。

当日の様子は @hogashi がかなりいい感じに時系列でまとめてくれていた、ので読みながら書いています。特に自分がやっていないことも自分がやったかのように書いてあります。そんなことはない。

0:00: そろそろやるかとなり、自宅のLinuxサーバにISUCON9 の予選問題を展開して、長らく使っていなかったMySQL筋やnginx筋,Go筋などのストレッチをしました。ここまでプログラミングってなんだっけ?状態

2:00: この段階で重大な伏線を仕掛けており、MySQL 8.x での追加機能に触れています。

ついでに、勝手に MySQL 8.x が来ると確信したので、クエリキャッシュ系のコンフィグをテンプレからコメントアウトします。伏線は張れるだけ張る。

8:00: 目覚ましを掛け、おぼろげな意識の中、開始時間が伸びたことを知り二度寝。この時点で優勝を確信する (遅い時間ほど頭が回るため)

11:00: 起きてzoomを繋ぐ。 @hogashi は前回競技中にやっていた洗濯を終わらせる。

12:20: 開始。サーバ一覧が出ないね〜って言いながら謎のgistを見たらIPが乗っていたのでつなぎにいく。ベンチマークがしばらく回せなかったので、とりあえずMySQL 5.7だね〜とか言ったり、コードを眺めたりアプリを触ったりする。
なぞって検索を見て、そういえば最近お仕事でGISやったな〜 SPATIAL INDEXで一発優勝ってマジ? などと、一人で優勝を確信する(大嘘)
featureの検索高速化したいね〜などと議論しつつ、各featureをbitに対応させて数値検索とかしても速くならんだろうし、いわゆるN:Nのタグ付けを実装するパターンでやるかなーみたいな会話をする。

なお、お題の推測は外す。

13:00: 初期スコア 471 を確認。MySQL のスローログ入れたり基本的なチューニングとか nginx の静的ファイルキャッシュとかする。なおクエリキャッシュはコメントアウトされていたのでそのまま忘れ去った。

13:30ごろ: Visual Studio Code の Remote Development + Live Sharing のセットアップ中に1台目からsshの応答が返ってこなくなる。ディスクが遅いのは知っていたが、まじか〜となり、3台目に作業環境を移す。サポートに再起動のお願いをする。 (ちなみに数十分後にサーバから応答が返ってきた)

13:55: なぞって検索を MySQL GIS 使って高速化やるぞ、となる。GEOMETRY型のカラムを足していい感じにやる。初期実装の POINT(x, y) における緯度経度のタプルの順序が、一般的なGISにおけるそれと逆でン゛ッとなる。

14:12: 椅子を回転してドアに入るか試したりしていた。入ったらしい (詳細不明)

15:27: nginx で bot ブロックをする。結局これがどのくらい効いているのかは不明だった。

15:39: GEOMETRY の改修が終わる。スコアは 829

16:13: とりあえずDBとappを分けて2台構成に。インデックスとかもいい感じにやる (降順インデックスなどは気付いていない)。スコアは 1345
この時点で2位に躍り出る。記念にスクショ

16:35: トップページに表示する最安の物件/イス20件をオンメモリキャッシュするが大して変わらず。

16:40ごろ: 3台目で Visual Code Remote Development + Live Sharing したらまた応答が返ってこなくなり2度目の解散。(18:00ごろに返ってきたらしい) 2台目に移る。ついでにポータルも繋がらなくなる。
「『計測するな、推測せよ』ってかｗ」

17:00: @h-otter がいい感じに chair と estate の feature 検索の改善を書き始める。寝不足らしく脳死脳死連呼しながらもテストコードを書きながら直してて偉い。これがTDDってやつね。
この実装はオンメモリ実装とDBのクエリでやる実装の2種類を考えていて、僕はDBを使った実装を書いていたがinitializeがかなり遅くなってしまった && @h-otter のオンメモリ実装が先に終わったこと (かつそちらの方が早くなりそう) もあり、そちらを採用。

19:22: ↑の実装が終わる。スコア654 。本当に?ってなってインデックス効いてるか見たら外れてた。入れる。スコア 2078
たしかこのあたりで15位ぐらい。勝ったなとか言う (勝ってません)

19:30: まだ色々できることはあるけど30分ぐらいでバグらずにできる自信はないね〜となり、細かい変更をちょいちょい入れる。 nginx の client_body_buffer_size を大きくするとか。POST系のペイロードがでかいのは気付いていたが、中身が何なのかわかっていなかった。あきらかに1件の大きさじゃないよな……とは思っていたが…… (複数件同時に投稿されていたことは終了後に知る)

20:00: ベンチを延々叩いて(不)安定性を確認する。なんか検索を改善した部分が若干バグっているっぽくてランダムで落ちる。原因はわからなかったので特にコードは修正せず。不安要素は最小化しましょうということで、とりあえずスコアに貢献してなかったトップページの安い順トップ20のキャッシュはrevert。POST系のペイロードがでかいのはこのあたりで気になっていたが、1件ではなく複数件を追加するリクエストだったことには終わるまで気付かなかった。

20:30: チーム名を思い出す。再起動試験。再起動して実行したらアプリが落ちてて焦る。DBが先に上がってないと落ちることを思い出す。systemdの気持ちになって無限再起動するように設定。OK。

20:45: 適当にベンチを何回か叩く。1997が出る。「どうする?」「ん〜〜〜」「でも最後ってみんなベンチ叩いてるから(CPUとかネットワークの利用率が上がって)スコア落ちたりするよね〜」「じゃあこれで終わりで」最後に再起動する。initialize が通ることを確認。ここでタイマーストップ

20:50: 乾杯

23:00: discordを見つつ、結果出ないね〜と言いつつ、名取さなの fall guys 配信のアーカイブを見る。ISUCONの運営インタビュー?みたいなやつの記事を見たら、とある先輩の顔写真がめちゃくちゃ高解像度で大爆笑する。毛穴までクッキリ。exiftoolを叩くも特に何も残っていない。

23:30ごろ: 生放送で順位が出る。おらんやんけ！！！！！！！ 解散

26:00ごろ: 入眠

最終的なスコアを見た感じ、あと100点ちょいって感じだったので、あと何か1つ出来ていれば本選に行けたでしょう。検索改善はまだ手が残っていたし、estateとchairのDB分けられたね〜とか終わった直後に気付いて「『アッ』」ってなったし、MySQL 8.0 にするだけで SPATIAL INDEX は速くなった可能性があるし、なんならクエリキャッシュだけでも良かったかもしれない。色々できた気がする。

ところで「まだ何かできそう」とアイデアが思いつくのは色々と課題を分析できている証拠だと思っていて、それをちゃんと実装までできるスキルもあるチームメイトはやはり優秀だと思う。今回は特に分析→仮説→改善→振り返りのサイクルをしっかり回せたので、今後にも活きることでしょう。
改善できるネタが思いつくということは、自分たちのチームが勝っていた世界線もあるということです。あとは前日の睡眠をしっかり取ればちゃんと勝てるはず。

来年はインターネットや書記や洗濯が得意な社会人と、インフラとチーム開発とアニメ鑑賞が得意な社会人と、睡眠が得意な社会人(笑)の3人で参加したいです。開始時間は12時だと助かります。ありがとうございました。

前回再起動試験で落ちたのでチーム「再起動非対応」で参加しました。ベストスコアは4410点でした。再起動試験までたどり着けなかった……悔しい……

チーム「再起動非対応」は同期3人 (自分 @kyontan, @hogashi, @h-otter) での参加でした。学生は2人いたはずですがエントリーをミスったので学生は1人ということになっています。

使用した言語

私はRubyが一番得意だと思っていますが、非同期処理が書きやすいとか型が着いていると嬉しい、みたいなことはあり今回もGo言語です。
でも今回はN+1潰すときの型マッピングで無駄に時間を溶かしてしまったので、Rubyの方が良かったかもしれない……つらい……

開始前の準備

Prometheus/Grafana等のサーバの設定を @h-otter にお願いしました。前回のコードを読み返しつつ、何をしたかを思い出すなどした。

時間がなくて完全に忘れてしまいましたが、せめて練習はやっておくべきでしたね…

あと、 Alibaba Cloud の UI が色々不思議な感じで良かったですね。

本番

完全に正解していますが、今回はマイクロサービス問だということに気が付いたのは開始してからだいぶ経ってからでした。

開始30分前、チームメイトとの雑談「今日は何がでるかなー」「フリマアプリかオークションかそういうやつでしょ」「マイクロサービスとかね」「わかる〜」 #isucon

— kyontan@新刊はまだ (@sukukyon) September 8, 2019

今回できたことが異常に少ない気がする。kataribeのログを眺めつつ、チームでやったことは以下のことです。比較的時系列だけどそうでない部分もあるかも。

• 開始スコアは 2310
• 10:30 メモリ多いな〜って思っていたら2, 3台目のインスタンスタイプを間違えていたことに気がつく。インスタンス立て直し
  • コードは既にリポジトリへ追加していたのでチームメイトはルール/コードリーディングを進める
• 10:50ごろ: 作業開始
• 11:30ごろ?: MySQL 5.7 を 8.0 へ (@h-otter)
  • スコア変化なし
• 11:45 DBにインデックスを張る(@kyontan)
  • 多分間違えていて、これらにインデックスを貼りましたがあまり効いていなかったようにみえました
  • BigQuery の触りすぎでRDBのインデックスの挙動をほぼ忘れたのも敗北ポイント

config (name)
items (created_at, id)
items (id)
items (buyer_id)
items (seller_id)
shippings (transaction_evidence_id)
transaction_evidences (id)
transaction_evidences (item_id)
users (account_name)
users (id)

• 12:20: カテゴリをオンメモリへ (@hogas, @h-otter)
  • 2510点ぐらい
• 12:30: http2 対応, 静的ファイルをキャッシュ, アップロードされた画像を nginx で返すなど
  • スコア変化なし
• 13:30: config もキャッシュするように
• 14:00: 新着商品には発売中の商品だけを返すようにする (@hogas)
• 14:45  – 16:00: GET /users/transactions.json の N+1 を潰す (@kyontan)
  • 3500点ぐらい
  • なぜか色々ハマって2時間半ぐらい溶かしていた。これは敗北ポイント
  • 多分ここらへんでMySQLがサチらなくなっていた気がする
    • CPUがサチっていたことに気が付いていたが原因が分からず (pprofをなぜ見なかったのか……)
• 15:30: UserSimple が持つ情報は全てオンメモリでキャッシュする
  • ユーザの存在チェックだけするような部分 (権限チェック) も基本的にこれで対応できるのでそうした
  • 4210点
    • ここからスコア上がらず……
• 16:00: 同じクエリを何度か叩いているエンドポイントがあったので潰す (@hogas, @kyontan)
• 16:00ごろ: transactions 以外詰まってないしCPUに余裕があるので campaign (負荷レベル)を弄ったところ外部APIで 403エラー  {“error”:”IP address is not allowed”} が連発しだす
  • 主にGET /users/transactions.json での外部 shipment  サービスへのリクエストで連発
  • 外部APIへの403はアプリケーション的には500を返す仕様だったので、これが連発してベンチマーカが途中終了し完走しない
  • ここらへんで手詰まりに
• 17:00: 明らかに不要な SELECT FOR UPDATE を削除 (4箇所+ぐらい)
  • これかこれの次辺りで4410点。これがベストスコア
• 17:10: 外部APIを叩く部分で exponential backoff を実装 (@h-otter)
  • 変化なし / 403 が連発する
• 17:30: 外部APIをリクエストするエンドポイントだけ2台へ分散する
  • 403 の連発は解決せず、なぜ……
• 18:10: 最終スコア0点 (failed) で終了

色々施策を打つもスコアの変化要因が今ひとつ分からず頭が回っていなかったですね。
特に外部API が undocumented な 403 を返す (しかもメッセージは 「許可されていないIPアドレス」) というのは全然分かりませんでした。
マイクロサービス問題なら単一IPから連続でアクセスすると弾くようになっているのかな、などと思い、後半で外部APIへリクエストをするエンドポイントだけ複数台へ分散するなどしていましたが全く解決せず泥沼へ。

これベンチマーカと外部API側に問題あるのでは? みたいな気持ちになりつつ、マイクロサービス問だしちゃんとbackoffとか実行すればいけるでしょ! と思っていましたが、意図したエラーだったのかは未だに分からず……

他の方の感想を見た限りでは、ポータルサイトへ登録されていないIPからのアクセスは弾かれるみたいですが、これについてはUI上で正しく登録されていることを確認したので問題なさそうでした。
11:00 ごろにインスタンスを立ち上げ直してIPを再登録したのがポータルサイトの何らかのエッジケースを踏んだのでは? などと勝手に邪推しています。謎ですね。

そのほか、 campaign の値を変えると何が変わるのか (POST系アクセスが増える?)、みたいなことも終了後にログを分析してようやくなんとなく傾向がわかり悔しい気持ちに。

感想

終わってみれば途中重大な気付き (「外部APIのレスポンスキャッシュできるじゃん」「ユーザの嗜好に合わせて商品出し分けたら?」など) があり、見逃しの多い回でした。
bcrypt の件は全く気づいておらず。前回は初手でやった(があまり意味がなかった) pprof を今回なぜ見なかったのか……

短い時間で追い詰められている環境の中でどれだけ集中できる / 気付けるか、というのが重要になると改めて感じました。

コンテストとしては今回も設定が面白く、運営の手の込みようが分かり、かつ短期間で取り組みがいのあるとても良い問題でした。
運営の皆様、大変お疲れさまでした。

チーム「hhkb」で同期3人 (自分 @kyontan, @hogashi, @h-otter) 2回目の参加で2日目で Go 実装でした。学生枠突破ならずでした、悔しい。というよりは 55,982点で全体4位の点数で落ちました。ちなみに hhkb は h-otter, hogashi, kyontan, :boom: ???? の略です。
スキルセット的には、 @h-otter がインフラ(ミドルウェア含)なんでもできる+Goの経験が一番あるマンで、 @hogashi がアプリケーションなんでもできるマンで、 @kyontan はアプリとインフラとDBを一通り見られるマンみたいな感じでした。

今回の参加に向けて、取り組んだことをつらつらと書きます。

今回は真面目に本戦に行きたかったので前々日に ConoHa で ISUCON7 の予選を解き直して練習しました。具体的には ConoHa の練習用イメージを使って 1GBプラン x3台で予選環境を再現しました。結果、10時間程度で 5,204点から509,190点まで持っていけることが分かり、計測と試行の反復を効率的に行えば ISUCON の予選は突破できるという確信を深めていました。
また、前回は最後の最後でベンチマーカを走行させた結果点数が下がって落ちたので、前回の直後に「泣きの1回はやらない」というスローガンを掲げ、1年越しでそれを達成しました。

事前に準備したのは Prometheus のサーバ (@h-otter がいい感じにやってくれた)と、やること/できることチェックリストぐらいでしょうか。だいたい大会では開始した瞬間にテンパってそのまま撃沈するのが常なので、思考停止状態でもコピペで動くようなコード片とかを用意しておくと便利ですね。あとは思考が無になったときに確認するべき事項とかを作っておくと良いのではないでしょうか? 頻繁に無になって帰りたくなりました。メンタルは大事。

例えば下のような感じです。

当日は3人がローカルで開発し、本番環境のVMへバイナリを転送して検証する、という進め方でやっていました。Go はクロスプラットフォームでのビルドがしやすいのが便利ですね。

具体的にやったことを羅列します。というか @h-otter が書いていたのを未承諾引用します。順番は適当

• SELECT * する系のクエリを必要な列しか取らないようにした
• /api/users は user_id で reservations を全部とってきて、アプリ側で処理してやったらめっちゃ速くなった
  • ここでベンチマーカが重いと言ってくるエンドポイントが /users/:id から /api/events/:id/actions/reserve になった
• getEvent を getEventWithoutDetail と分けた
• getEvent と getEvents を2クエリに
• sheets へのクエリを消す
  • 効果があったのかは良くわからない
• MariaDB のチューニング
• Prometheus と Grafana で可視化
• ログインのクエリを1つに
• パスワードを平文で突っ込むようにした
• DB にインデックス張った (けどあまり良い結果がでなくてもんにょりした)
  • 最初に mysql コマンドでインデックス張ったけど結果が全く変わらなくて、なぜ? と思ったら毎回 /initialize でテーブルを作り直していることに気がついた。
• IN句を使いたかったので DBにアクセスするライブラリを sqlx に切り替えた
• トランザクションの開始がおかしいところがあったので直したり デッドロック時にエラーを返さずリトライするようにした

最後は予約時のシート決定を高速化するコードが安定化しなくて入らなかったり、Redisでいい感じにやろうぜみたいなことを思うだけ思ってやらなかったりしました。多分ここができると数万点上がったはず。

あとはスコアに関係ないけど作業便利になる系として、 エラーログでソースコードの行番号を吐くようにしたり、 Makefile 弄って1コマンドでデプロイできるようにしました。
開発は3台のサーバでバラバラにやっていましたがDBは1台だけを参照するようにしました。これはDBのチューニングとかがあって、1台でやった変更を他に反映したりするのが面倒くさかったので。こうすると、やりたい人間が適当にベンチマーク対象のサーバを変更して実行してやればいいので楽でした。

ソースコードは GitHub で管理し、いい感じにやりました。コミットログは下の通りです。

数字がタグに付いていることがありますが、これはいいスコアが出た時にバイナリごとコミットしてタグつけておこうぜ、みたいな感じにした結果でした。

今回の僕の活躍はよく分からなくて、いい感じデバッグ担当だった気がします。PRを見るなりとりあえずマージしてベンチマーカを落としたりバグ探しをしていたりしました。とにかく @h-otter がぶち壊しつつ @hogashi がいい感じに安定化するコードを書いてくれてよかった感がある。

Webサーバはh2oで十分高速だし、画像のトラフィック詰まりもないしで、とにかくアプリケーションコードの改善に注力した/するしかなかった8時間でした。

最終的に残り30分でベンチマーカを叩いたところ3万点前後のスコアが5万点に若干跳ねてそこで打ち止め。一度再起動をしてブラウザからアクセスできることを確認し天命を待ったところ、無事再起動試験で落ち失格となりました。天命……

(追記: スコアが跳ねたのは、最後に実行先サーバを変えた時に インデックスを張る処理を init.sh に書いたサーバで実行したからかもしれないことを思い出した。)

なぜ失格になったのかは分かっていなくて、おそらく /admin/api/reports/events/:id/sales の処理が遅くて不整合が起きて落ちたのかなあなどと思っていますが、2回連続で落ちるのは運が悪かったなと……

なんやかんやでやることがなくならない8時間で、やることが見つからない8時間よりは良かったのではないかと思います。

ISUCONの予選に向けて昨日は練習をしていたわけだけど、知っていることをちゃんと愚直にできれば比較的現実的な時間で予選突破ラインには十分立てることが分かったので良かった

— kyontan@新刊はまだ (@sukukyon) September 14, 2018

イキっているなどと言われてもこれは事実だと信じていて、典型的な N+1 を潰すなどすれば予選は通過できるはずなことは分かりましたね。くぅ〜〜

来年はちゃんと本選に行けたらいいですね。頑張りましょう。

そして、参加会場を提供していただいた mixi 様、惜敗の悔しさを教えてくれる最高のコンテストを運営をしていただいたISUCONの運営の皆様、お疲れ様でした、ありがとうございました!

以下は画像です

Ruby実装で挑み、最終スコア 38605点@2017-10-22 20:59:30, ベストスコア: 67792点@2017-10-22 20:44:59 でした。
ベストスコアでは予選ラインは超えていたんだなあと思いますが、最終的には伸び悩んだチームも多いようで、結局落ち着くところに落ち着いたのかなと思います。

ソースコードは kyontan/isucon7_qual です。踏み台でやっていた影響でコミッタが僕に見えますが、だいたい僕ではない。

次回も参加したいなという気持ちになってきたので、ひとまずはやったことを記していきます。

実は僕と @hogas は ISUCON6 の夏期講習に出たことがありましたが、そのときには日程等もあり参加しておらずということで、今回が初参加に。
@h-otter というインフラにとても強い同期がいたことや、周囲でも参加する人間が何故か多く、とにかくやっていくしかないという流れに。

チーム名を決めるところで消耗/摩耗し、本番前日までSlackはほとんど流れておらず。前日夜になって僕とか @h-otter がぽちぽち参加記やチューニングできそうなところを貼っていく感じに。

最近、正午より前に起きると早起きしたと言い出す僕が時間に間に合っていたあたりで色々とミスっていたんですが、東京都内の某所で3人で集まってやっていました。

事前にやった

とりあえずグローバルIPを持つ作業用サーバを用意しておいた。Rubyは事前に入れておいて、開始後に MySQL  も入れてスタンドアロンで動くようにした。あとあと @hogas はここでずっと作業してたり、 @h-otter が Prometheus のサーバを立てたりしていた。便利

コードについては GitHub リポジトリを立てて、普通にブランチ切ってやっていた。便利

情報共有は対面だったので、コードスニペット貼れるしリアルタイムで最高な HackMD を例のごとく使っていた。ベンチマーカの結果を全部ペタペタ貼っていたら容量制限に引っかかり、2スレ目、3スレ目が誕生した。HackMDのタイトルは「ISUCON7 まだチーム名で消耗してるの? 2スレ目」でした。

やったこと

ミドルウェアより下は正直 @h-otter に丸投げしていたので、アプリケーションより上をぽちぽち見ていました。
インフラについては正直何をしたのかは全容を把握していないですが、初手で nginx や MySQL に基本のチューニングを突っ込み、Prometheus で延々と監視しながらPDCAを回していたっぽい。正しいインフラチューニングや……

言語は僕と @hogas が使い慣れている Ruby を選択しました。正直クエリ弄るぐらいでいいなら Go でもいいよねーって言っていましたが、慣れてるほうが便利でした。Sinatra の文字列には幼馴染のような安心感がある。

僕と @hogas はよしなにアプリケーションコードを読みながら色々した。以下は色々

erb を haml に置き換える / hamlit gem の導入

気持ち+2000点ぐらい

初期実装が erb で、erubis に置き換えるというのも一案ありましたが、行きの車内で「erubis hamlit 速度」などで検索した結果やっぱり hamlit かとなっており、ノータイムで haml に書き換えることを決断しました。
erb2haml とかあったね〜と @hogas と話しながらやってもらった。

以下様子です

. @hogextend 「erb2hamlどうやって使うの?」ぼく「とりあえず rails new して突っ込んでみたら?」 #isucon

— きょんたん (@sukukyon) October 22, 2017

僕「ﾖｯｼｬ(gem install rails)」

— hogas (@hogextend) October 22, 2017

(erb2haml はコマンドラインツールとかではなく、Rails に追加する rake タスク群ということに気が付いた様子)

nginx <-> Puma を UNIXドメインソケットに

気持ち +2000点

定番です。HTTP 5000/tcp から UNIXドメインに変えた。

SQL のクエリ改善

気持ち+10000点ぐらい

これは定番ですね。SELECT のカラムを絞ったり (@hogas)、 LIMIT を付けたり (@hogas)、インデックスを張ったりした。N+1 は手を付けていましたが、コード変更に集中できなくて最終的に投げてしまった。悔しい

終了直前にソースコード眺めてたら statement.close を意図的に忘れていそうなコードが見つかり慌てて修正した。スコア上の変化は分からず。

 画像を静的ファイルに書き出す

気持ち+15000点ぐらい

ユーザーのアバター画像が DB に blob で入っていたので、雑に Ruby のワンライナーで書き出して (ここまで @kyontan)、 nginx に try_files で食わせる (@h-otter) みたいなことをした。
既に話題になっていますが、最終的には Cache-control 的な問題でキャッシュヒット率が悪かったらしい。むむむ。

SHA1 を殺す (パスワード, アバター画像)

気持ち+2000点

パスワードのソルトを生成している random_string を見たときに、これは要らないのではと思ってしまったのが始まり。初期データのパスワードはハッシュ化されていたので、 id が1000より大きい user は全て平文パスワードを DB に突っ込んだりした。 (by @hogas)
アバター画像は、ファイルの内容を SHA1 したものをファイル名に使用する実装になっていましたが、もしかしていけるのではと言いながらユーザIDをそのままファイル名にしたら通ってしまったのでそのままに。

Redis (最終的に入れず)

気持ち+2000点ぐらい(?)

画像をバイナリで入れるのはまあそうだね〜〜と言いながら、Redis に載せようとしていた。正直コードの変更は大したことがないのは分かっていたので実装はシュッとできたけれど、実際に動かしてみると意外とスコアに有意な差が出なかった。その後も永続化周りで少し足踏みしていたり、他の変更を見ていたために最終的に入れられなかった。残念

アプリケーションサーバ3台化

気持ち +3000点ぐらい

@h-otter がラスト30分でイケると言い出してやってた。ここで Puma (アプリケーションサーバ) のスレッド数を調整していた (10 -> 18スレッド)時に出したのがベストスコアです。

その他

• 再起動試験は何の問題もなかった????
  • 過去の参加記なんかを見てるとここが関門かなというのはあったので絶対やっておきたかった (やりました)
  • Redis に手を出してなかったのでここで不安はあまりなかった
• MySQL の Too Many Connections が割りと頻発した
  • ここは statement.close 忘れも影響してるかなと思うけれど、500が途中で出たり安定しないことがあった。最終的には安定しました
• 日ごろは頭痛の頭の字もないのに、とにかく頭痛が酷かった。緊張にはやはり弱い。
• JSONシリアライザが遅いのは分かっていて、 Oj を入れるぞと言いながら入れるのを忘れた。あれを入れただけでシリアライズについては数倍速くなるというのは分かっていたので、ただただつらい。
• ICTトラブルシューティングコンテストでスコアサーバを延々とやっていたことが知見として生きたとは思う。DB設計なりアプリケーション設計なりチューニングなり。
  • 当時のオーバーキルなチューニングしたときの操作が生きることになるとは思ってなかった
• 最後のベンチマークの結果を見て全員で嘘やんって言ってた
  • ルールを読んでなかった。次回は読みます
  • にゃーん

そういえば30分ほどですがスコアボードの上位に乗っていました。学生トップなのは分かっていたので、これは予選突破できるんじゃない? とか言いながら笑っていたのを覚えています。このあたりが後々ボーダーになるんだろうな〜という話をしていて、実際そうなったのである程度読みは正しかったのかなと思いつつ。

総括/最高

監視に強い人(@h-otter)強い。常に横で IOバウンドかネットワークバウンドか、みたいなことを見ながらアドバイスしてもらえる環境は最高。

限られた時間の大会という環境でもくもくとコードいじれる人(@hogas)強い。とにかく僕が頭が回ってなくてコードをまともに書けない状況にあったので、そんな中でちゃんと改善する変更を入れ続けてくれて最高。

基本的にどこに手を入れればいいか、この変更はコスパ的にどうかみたいなことを常に考えながら立ち振る舞えてはいたと思うので、そういった点ではなかなか善戦はできたかなと思いつつ。
しかし、できたことは山のように残っているなという感想。、途中で集中力が切れてしまったこともあり、こういう結果になったのは悔しいなと思う。

ただ、これだけ言えるというのはつまりバランスが最高だということに他ならなくて、こういった駆け引きができるバランスのゲームを作るのはとにかく難しいなと思っているだけに最高だな！！！という気持ちです。
こんな最高のコンテストを生み出してくれた運営の皆様、ありがとうございました。そしてお疲れ様でした！

本選に行かれる皆様はぜひとも頑張ってほしいなと思うところです。

次回は最高の♨️から最高の心構えでやっていきたい。