今年はだめでした。来年も頑張るために今年は何をやったか、次に何を糧にするかをメモ。。
今年も去年と同じ3名で参加してきました。そして自分の担当はインフラ。 @tasumack @lazydg
今年のテーマ
今年はISUCONをSaaSとして提供するというものでした。管理者、参加者それぞれでログインできるなど、ISUCONに対してメタな構造の問題は少し複雑な印象もありました。
我々のチームは敗退しましたが、本戦常連なチームがしっかりと結果を残しているところを見ると悔しいですね。ぐぬぬ。
github.com
我々のrepositoryはこちら
github.com
やったこと
・下準備（git init とか pt-query-digest、alpの準備 とか deployツールの準備など）
・echo の debug を offに
・UUIDをアプリ側で作るように
・visit_historyにindexを追加
・visit_historyはplayer_id 1つに対して1レコードしか必要がなかったので、upsertするように
・SQLiteの実行時間なども取れるように（sqlite trace）
・competition tenant_idにindexを追加
・player_scoreにindexを追加
・player_scoreのN+1を解消
・rankingのN+1を解消
・player/playerのN+1を解消
・player_nameをcache
・1台目:app、2台目MySQL（visit_hisotry以外 + visit_historyのidが偶数のもの）、3台目MySQL（visit_historyのidが奇数のもの）の構成に
N+1の解消やindexの追加、サーバーの分割などを計測しながら愚直にやっていたが、visit_historyの負荷が高いところでハマり、スコアが伸び悩んでしまっていた。
敗因と次に気をつけること
講評はこちらにあるので、合わせてご覧いただければと思います。
isucon.net
・初期データの扱いについて忘れずに
結果的に最後までvisit_historyの負荷を減らせず、MySQLのプロセスが支配的になっていた状態でした。
ここがボトルネックだということには気づいていたが、これは初期データへの扱いを考慮できていなかったことが原因だったので、初期データが何で、ベンチで入れられるデータが何、というのはコードを読むときに意識するようにと秘伝のタレに追記しておきました。
もうちょっと「visit_hisotry」についてエンドポイントから処理のすべてをチーム全体で見ても良かったかなという気持ちもある。
・SQLite -> MySQL化など、換装のフットワークを軽く
講評にもありますが、SQLiteを使っていても予選通過スコアは出せているようでした。が、MySQLのほうが使い慣れているというのもあり、このあたりをサクッと換装できればもっと可能性を探りやすかったのかなと感じています。
チーム「シン・ウー馬場ーイー2」の差分をみても、割とコードはサクッと直せたはずですし、sqliteからcsvにガツッと出力できれば比較的簡単に行けたのかなーという予感もしています。
個人的に反省としてはGoをかけるまともな環境になかったので、deployしながらコンパイルエラーのような状態になっていたのは反省。。（きちんとGoland動く状態にすべきだった。。）
github.com
以上です。来年は本戦出場したい。（あとアプリレイヤー担当したいな）
