チーム「さばかんちゃーはんかれー」でISUCON11に参戦してきました。

毎年恒例のISUCONの参加ブログです。今年も例年と同じメンバーで戦ってきました。

まず結果からですが残念ながら予選敗退してしまいました。今年はスコア的には本戦出場ラインだったんですが、追試で失格になってしまいました。悔しい。

それではやったことを振り返ってみたいと思います。

準備

特別何か対策はしていませんが、蓄積された秘伝のスクリプト郡を今回用のリポジトリを立ち上げてぶち込んでおきました。ビルド、デプロイ、ログ収集を全てMakefileから実行できるようにしており、使い慣れたメンバーだったので非常にスムーズに快適に使えました。

開始前まで

10時開始予定だったので9時に集合して、軽く作戦会議。各自の担当と開始時の動きを確認。

10:00 - 12:00

私のAWSアカウントを使用する予定だったので、CloudFormationのテンプレートを落としてきて環境構築。その間、他の二人にはレギュレーションの読み込みと、dstat,kataribe,pt-query-digestで各種メトリクスを取得できるよう仕込んでもらう。明らかに遅いクエリにindexを貼りスコア21,868。

12:00 - 13:00

indexを調整
jiaServiceURLをconst化
クエリで不要なカラムを取得しないよう変更
trendで不要なレコードを取得し過ぎているので LIMIT 1 を追加
AppとDBのサーバを分離

この時点で35,225

13:00 - 14:00

デフォルトアイコンのキャッシュ
postIsuCondition でバルクインサート対応
dropProbabilityを0.8に下げる
画像をDBからローカルファイルに移す

この時点で42035

14:00 - 17:00

index調整
GET時の不要なトランザクションを削除
isu_conditionテーブルのみを別DBにする
trendをキャッシュ→失敗してリバート

ここではあまり効果が出ず38,066

17:00 - 18:00

このままでは勝てないので何か大きい手を打つ必要がある。
改めてボトルネックを確認すると、とにかくisu_conditionテーブルの負荷をなんとかする必要がある。
今までメトリクスの結果からgetTrendの処理に目がいっていたが、よくよく処理を確認するとgetIsuConditionsFromDBでレコードを対象に取得し過ぎていることに気づく。
安易にLIMITを入れるとfailし、一旦不要なループを抜ける処理を追加40043

18:00 - 18:30

ポータルのメンテによるロスタイム。
getIsuConditionsFromDBの改善を再び検討し、conditionLevelが一部でフィルタされていなければLIMIT指定できることに気づく。
LIMITを追加し、66,681

18:30 - 18:45

isu_conditionテーブルの負荷が下がったのでdropProbabilityを下げられるはずということでチャレンジ。
0.1ずつ下げていき、最終的に完全に取っ払う。
147,684でFinish。

最終結果

運営による追試の結果 138,574。本戦出場ラインは突破！しかし、画像をローカルに保存する対応で再起動時に画像が吹っ飛んでしまい、失格に。。。

感想

失格は悔しいですが、今年も非常に楽しかったです。チームワークも洗練されてきて、メンバーの得意分野で無駄なく動けている感じでした。メンバーがメトリクスをgit管理してくれてたのが非常に見やすくてGJでした。

@matsukaz と @kz_morita 今年もありがとうございました！懲りずにまた一緒に戦いましょう！

ではまた来年！