#isucon 4 本選10位で惨敗でした

ISUCON4本戦に毎度おなじみ山形組で参加してきました。結果は既報の通り、われわれは8千点前後の団子状態から抜け出すことはできず、60倍以上のスコアを叩き出したLINE選抜チームが連覇となりました。おめでとうございます。

ISUCON2で2位を取って以来、ISUCON3で5位、そして今回10位と順位を下げ続けており、年々高まる参加者のレベルが恐ろしい限りです。

やったこと

• redisを落として本当のインメモリDBアプリ化(aサーバ)
  「来年、もう一度来て下さい、本当のインメモリDBアプリで優勝させますよ」
• slot-IDベースでのnginxによる3台のサーバへの動画postの振り分け
  • ad-IDはaサーバのアプリに問い合わせて発番した上で動画ファイル保存
• asset-URLをあらかじめslot-IDベースで3台のサーバのアドレスに分散
  • nginxからmp4を直接serve
• –hostsは3台のPrivateアドレス指定。
  • 当初Globalアドレスでベンチが通らず、運営からPrivateアドレスを使うようアナウンスが出てた覚え

やれなかったこと

Plack::Handler::Nginx化
　高rps化しなかったのでやっても意味はなかった

感想

これから出題者側による詳細の講評があると思うのでそれを見てみないと最終的な判断はできないとは思いますが、優勝チームのkazeburoさんのエントリを読む限りでは、ベンチマーククライアントが特殊すぎる状況を模倣してるように見受けられます。
いつもやっていることを当たり前にやることでスコアを伸ばさせたかったんなら、redisからLast-Modifiedを付けずに動画を配信しているところから、ファイル化していつものようにnginx等のwebサーバに配信を任せて、Last-Modifiedが付いた時点で、クライアントはキャッシュするべきだった。
もちろん、Cache-Control(max-age)/Expires をつけることはより良いことだし一足飛びにその設定をする場合もあるだろうけど、普通は狙う効果が違って、これは304すら無くす場合に設定するものです。
実はCDN経由でデフォルトのmax-ageが0でした～という話もあるようだけど、サーバのIPアドレス直でアクセスさせておいてそれはかなり苦しいし、もし特殊なip routingを駆使してそれを実現しているのであればそれこそいつもやってることを当たり前にやってもしょうがない話になってしまう。前任者はトラックにでもはねられたのだろうか。
ISUCONの面白さは、一般に存在する”問題”が散りばめられていて、経験者はいつもやっていることが功を奏し、そうでないものは今後に活かせる教訓を得られるということだと僕は思っています。ISUCONにしか存在しない”問題”が作成され、それが解けたか解けないかで出題者が出場者に勝った負けたと騒ぐイベントだったのかなぁと。

というわけでたっぷり負け惜しみを書きました。

来年も開催されるとのことですが、予選を含めた過去のISUCON本番計測のすべてにおいて完走というちっぽけな記録が継続中なので来年も最低限そこは死守しつつリベンジします。もう負け惜しみを書きたくないです。

出題を担当されたクックパッドの皆様、主催/共催の、LINE、テコラスの皆様ありがとうございました。