※レポート遅すぎてすみません！
isucon12、チーム「パカパカアルパカ」として初本戦に出場しFailで終了してきました！残念！
チームメンバーのブログもありますので是非ご参照くださいませ。 techblog.tver.co.jp
テーマ
ISU CONQUESTというソシャゲアプリケーションのチューニングでした。 すでに公式から 解説記事が出ているのでそちらを見ていただいくとわかりやすいと思います。
開始早々サーバが５台あることが判明し、これは分散がキーになりそうだな？という想像がつきました。1
自分のやったこと
序盤はいつもどおり足回り系と、モニタリング系の準備。
また予選では複数デプロイスクリプトがいまいちだったので、それも今回事前に用意しておいてシュッと複数サーバにデプロイ出来るようにしておいたのは良いポイントでした。
あとalpのregex集計が便利すぎて「alp便利〜」とずっと言ってましたｗ
あとはログ見ながらひたすらチューニングしまくり。
- user_present_all_received_historyにindex追加
- user_presentsにindex追加
- interpolateParams設定
- DBコネクションプーリング
- user_one_time_tokensにindex追加
- checkViewerIDしてるとこ削除
- versionをオンメモリキャッシュ＋サーバ間同期取るように( これがバグってた ><
- login_bonus_reward_masters にindex追加
- gachaをオンメモリキャッシュ＋サーバ間同期取るように
- initを並列処理化
- nginx / mysqlチューニング
- redis / mysqlを別サーバに
中盤〜終盤にかけてDBをどう分散するかの検討について
中盤過ぎた辺りからDBどうにかせんとな〜と思って「ユーザIDなら水平分散できるのでは？」と考えました。
実際に数値IDからシャーディングする実装もしたこともあるし、そんなに工数かけずに行けるやろ！と踏んでました。
しかし、とあるクエリを確認したところ「IN句でユーザID使ってるみたいだから厳しいか…」と諦めてしまいました。
ただこれ競技終了後に指摘されてよくよく見てみたらこれが完全に勘違いで、普通に分散できることが発覚 😇
こういうところも含めてisuconですね…！
Failしてないときの最終スコア
10万弱くらいだった気がします。
Failしなかったとしても入賞まで程遠いのでもっと精進します！！
延長線
運営様のご厚意で１週間ほど延長線出来ることになり、メンバーで時間のある時にちょいちょい延長線してました 2
以下自分が追加でやってたことです。
- MySQL REDO off
- redisサーバの場所を調整
- select * やめ
- 複数selectおまとめしたり
- user_device作らない
- sync.onceで無駄処理しないように
- redisをpipelineで並列化
- インフラ・ミドルウェアチューニング諸々
- N+1潰し
- item_type毎におまとめして処理するように
そして延長線の最終チーム結果としてはこんな感じでございました。
score: 423541
お疲れさまでした！
次回に向けて
今回Failだったのは残念ですが、自分はそれよりも入賞に届くまでのスコアが出せなかった方が悔しいです…！
やはり予選と本戦では求める水準が違うので、もっともっと素早く的確にチューニングする力が足りなかったなと言うのが正直な感想です。
スコアが伸び悩むと余裕ができず、今回のようなバグの箇所やIN句の勘違いなどミスも出やすくなります。もっと精度を上げることにより気持ちにも余裕ができより正確にチューニングができるはずです。
ただ、今回の予選・本戦の結果で僕らも少し自信をつけることができました。3
来年は是非ともまた予選突破し、次は本戦入賞を目指してこの一年で力をつけていこうと思います！
ISUCON運営の皆様・関わってくださった皆様、楽しい時間を本当にありがとうございました！
