ISUCON4 本戦に出場

自分はサーバ側でみんなの開発ベースを整えつつ、今回の問題をどう対応していくかという作戦について取りまとめておりました。
当然3台使い切るための構成を考え

1. redisは1ノードに集約
2. uploadされた動画は各サーバの足元に置いてredisに動画置き場の情報を書く
3. アプリは x-reproxy-url ヘッダを返して動画を持ってるサーバから取得する

という方針で全部のサーバでベンチを受けられるようにしまして、これ自体は15時〜16時くらいまでに完了。
ただ、その先のチューニングからはスコアも伸びず、ベンチマーカー側の帯域がいっぱいになるし "さて果たしてこれから何をしたものか" となって終了時間を迎えた次第でした。

"帯域が太ければ" みたいな話が終了後の懇親会で出ましたが、たとえ10Gのネットワークが提供されていたとしてもスコアはせいぜい10倍にしかならず、トップの60万点には当然届かないわけで、今回問われたのはそういう所の戦いではなかったということです。

今回は5位まで賞があるということもあって、みんな堅実な戦い方をしたせいかわかりませんがfailが少なく最後まで戦えていたのでそこはとても良かったと思います。
ただ、8000点前後で大きく差がつかず団子状態になって手詰まって抜けられるチームが少なかったのは予選同様で、実力で差が出る部分まで全体的に行き着きづらい問題設計になってしまっていたのかなと感じました、さじ加減がとても難しそうですが。。

講評でCache-Controlの話が出た時は"ウーム、UAごとのキャッシュだと何度来るかわからんからそれだけで劇的に変わっちゃうのもどうなのよ、あと現実に即して考えるならnginxがLast-Modified返してるんだからベンチマーカー側も考慮したほうがいいのでは"とは思いましたが...

この辺はあとでロージリーさんに伺ったところ、Cache-Controlを付与するとベンチマーカーは一度キャッシュすると全体で使いまわしてくれる仕様だったようです。
更にベンチマーカーはスループットが出れば出るほど多くリクエストを出す仕様になっており、キャッシュさせてしまえば後はずっとレスポンスを返し続けるだけの簡単なお仕事をぶん回すのみになります。
そうなると、途中で得点レギュレーション変更された imp得点(0.001)x5 -> 表示回数(1)x5 によって1位の60万点のようなスコアが出るのもうなずける話です。
とはいえ現実の配信でCDNを向けさせるにしてもCache-Controlとかオリジン側で入れるのはごくごく当然やることなのでそういうのをやれてない/気づけてない時点でやられてしまっていたというのが現場からのレポートです。

さいごに、出題の皆様、運営の皆様、テコラス様、ありがとうございました。