連覇だ！ ヒャッホウ！！！
特にkazeburoさんのエントリに最終的な状況についての詳細が書いてありますので、ぜひそちらもどうぞ。sugyanは自分で力不足とか言ってますが、ISUCON本戦という場で、業務でほぼ使ったことがないはずのRedisメインのコード改造をごりごりやってちゃんと動かす人なので、チーム外のみなさんは騙されてはいけません。それできるの超すごいんやで。
主催のLINE株式会社、あれこれ提供いただいていたデータホテル改め株式会社テコラス様、問題作成担当 @mirakui, @rosylilly, @sora_h の3氏、本当にありがとうございました。たのしかった！
だいたいこんなんで
大雑把に時系列の経緯だけ書くとこんな感じ。
- 開始-12時頃
- ssh鍵の導入など環境の準備、コード読む、全体の設計変更の議論
- 12時-14時過ぎ
- 複数台構成への変更
- 14時半-18時半過ぎ
- NW帯域詰まってどうにもならず呪いの言葉を吐き続ける
- kazeburo親子を見てほっこりする
- 散歩
- 18:43-19:00
- Cache-Control!
実際のところ14時半には複数台構成への変更が完了し1Gbpsをほぼ使い切った状況までいってたようで、その他の、スコアに影響がほとんどないけど普通のWebアプリとしてはやったほうがよさそうな変更をやりながら悶々と考えていたのが17時頃まで。
ほぼ諦めかけて投げやりな気分になったところで33万点を目にし、現実的に動画を配信しないでスコアを上げる方法があるらしい、ということで可能性を片っぱしから列挙しては自分で却下したりしてた。その中に Cache-Control も含まれていたが、この時は設定ミスで気付かず。もはや万策尽きた、というところになりかけたが、最後の最後でなんとか間に合ったのでした。
なおlocal ipを --hosts に指定できること、それによりNW帯域を稼げることは気付いてなかった。Cache-Control のほうが間に合わなかったら5位に入ってなかったんじゃないかと思う。(ので結果発表が怖過ぎた。)
そういえば最後が劇的すぎて忘れてたけど、途中で突然ベンチマークツールが登録に来なかった advertiser id についてレポートが無いといってFAILにされてた時間帯があったんだけど、あれはなんだったんだろ。裏側でベンチ用データがバグってたとかなんじゃないかと思ってたんだけど。だいぶ長いことデバッグログを入れたりしながら唸ってたんだけど、そのうち勝手に直った。
変更した構成
最初に考えた構成で、結局最後までこのまま。帯域が詰まらなくてrps勝負になったときに威力を発揮した構成なんじゃないかと思うんだけど、確認できず。
- 動画は(例によって)WebDAVでnginxから配信する
- アップロードリクエストが来たらレスポンスを返す前にnginx全台にpush
- /asset リクエストが来たらnginxが直接返す
- isu401 は1CPUなので、基本的にはRedis専門サーバとする
- ただしappも立てておいて、広告の登録やレポート集計にはこちらを使う
- レポートのリクエストはベンチ走行中も来ていたようなので、その負荷の隔離先
- isu402, isu403 で /ads, /ad, /count, /redirect の処理
他に悶々時間帯にささやかなチューンとして、公平性ボーナスの条項を満たし次第*2、あとはバイト数が最も小さな動画広告だけを返す、などということもしていた。ほぼ結果に影響なかったみたいだけど。
いちおう何がどうなってもいいよう、isu401 のnginx設定やperlのコードは isu402/3 と全く同じ状態で動くようになっている。こういうふうにしておくと、ボトルネックが移動して問題を再考しないといけない場合にも便利。
ブレークスルー案として検討した項目
動画が1ファイル5.3MBから5.4MB、1Gbpsを使い切ったあたりでremoteなスコアが8000前後、アクセスログによるとだいたい700回くらいのレスポンスを返していたようだった。
で、このスコアを33倍以上にするために動画リクエストをどうすればいいかと考えたときの候補。
- いきなり206を返す(ダメ)
- レギュレーションによると25%のERRORが許可されているので、動画の25%をエラーにしつつclickを増やす
- 動画を返さないとそもそもclickに来ない、ダメ
- 動画ファイルのmd5コリジョンを発見
- ムリ……というかアップロードされてくるのでいちいちそんなもん見付けてられるか
- 動画の先頭とかの部分だけ返してチェック通すとか？
- ETag, Cache-Control (最終的にはこれだった)
- ベンチ走行中の1分間のあいだは動画リクエストが来たら全部 sleep して60秒待たせる
- 60秒経過後に溜まりに溜まったリクエストに順にレスポンスを返せば、60秒間で稼いだコネクション数だけのスコアが稼げるのでは？
- と思ったけど33倍ってことはつまりベンチ実行合計時間が33分以上になるってことで、いやそりゃダメだろと
- 結局その戦略はsleepしてる間にレポートのリクエストが来て不整合でFAILするらしい
他にもいくつかあった気がするけど忘れた。ひたすら会場内をうろうろ散歩したり座ってぶつぶつ独り言いいながら検討してた。
問題設定について
Cache-Control つけるだろ、というのはまあ冷静になればわかるんだけど、もうちょっとヒントがあっても良かったかなあという気はする。例えばレギュレーションの impression の説明のところに、有効なインプレッションとして認められるレスポンスコードを列挙しておくとか。
終わってみると、Cache-Controlに気付くか気付かないかで消費するにはもったいない問題だったんじゃないのという気がして、そこはちょっと残念。超大量のアクセスをどう捌くかこそがISUCONのいちばん脳汁出るところで、その戦いがもっと多くのチームでできればよかった。redirectをひとつ削減したやつとかもそこで効くはずだったし、Redis::Jet や Chobi が火を噴いただろうに。
とりあえずうちのチームの得点、最後のベンチ走行時にどこがボトルネックになってたかすら全く見られてない*3んだけど、たぶんちゃんと調整すれば workload 8 で100万点いったんじゃないかなと思う。
参考資料
今年もマスタリングnginxにはお世話になりました。
が、もうちょっといい解説があった気がするんだよなー、なんだっけかなー、と30分くらい悩んだところで気付きました。自分でちょっと前に書いたSoftware DesignのNginx特集の記事だ！！！！！！！
これまじ分かりやすくて超便利でした。みんなも買うといいよ……と思ったけど、Amazonだと中古だけだな。PDF版を買うといいですね。いい時代だ。
まとめと今後の話
なんにしろ、面白かった。じつにすばらしいイベントでしたね！
で、2回勝ったので、まだあんまりちゃんとチームで合意をとってないけど、もうこのチームで出ることはないんじゃないかなーという気がする。出るなら自分も、もうちょっと他の人とやるISUCONを経験してみたい気がするし。何より勝ち逃ｇ(ry
で、来年も開催できるらしいですね！ 2回出場側にまわって、そろそろまた出題側に戻ってもいい気がしてきた。気力が回復した。ｗ
これもまた別途確認ですが、やれれば出題担当しようかなーと思う。ちょうど勝ったことだし。
また ISUCON Makers Casual Talks というイベントを近々やろうかなと思います。いろいろ話したいことがあるんですよ！ 出題をやった側にしかわかんない苦労とかがですね！ そういうのをビールを飲みながら赤裸々に話したい！
さて
来週はRubyConfでサンディエゴだ！
