ISUCON3本選お疲れさまでした！
うちのチームのことはだいたいgfxが書いてる通りなんですけど、おもに僕がやったこととか本選後に振り返ってみたことを書いておきます。
予選後の教訓で、最初にちゃんとコードを読んで方針を決めようって話してたので、最初に全員でざっと構成とかコードとか初期状態でのベンチとか回してみて全体を把握してから昼に作戦会議。
そのときに僕が話した見解は
- このアプリケーションから何らかの方法で参照時の画像変換のボトルネックを取り除いたとき、次にボトルネックになるのは帯域になる
- なので理想的な状態から逆算すると5台でWANにトラフィックを吐く構成になってる必要がある
- 最悪、参照時にまったく変換しなくて済む理想的な高速化に失敗してすべての変更をrevertすることになっても、5台並べて参照時の画像変換して返せるようにできてれば単純に初期状態の5倍のCPUでスケールできるから5台で動かすのは必須
- 画像変換がボトルネックになっている限りクエリのチューニングに手を付けるのは時間の無駄
我がチームの戦略上のミスは、画像変換を先に済ませておけば最速になるという推定をしていたのに多分無理だろうと変換が時間内に終わりきるか(容量は足りるか)ちゃんと見積もらなかったことだと思う。
昼以降、僕は全台nginxで受けて更新系を1台目に流す部分をやって、Yappoさんが変換した画像のローカルキャッシュと1台目以外で動くように改修する部分、gfxが画像変換のImager化をやってたけど、最終的にみんなの力がひとつになることなくずっとFailしたまま僕たちのISUCONは終了した…。
まぁあとから思うと木曜から体調死にかけで当日心が弱りまくってたとか、予選ではエラーみた瞬間1秒で気づいたことが本選では30分ぐらいドハマりするぐらいぜんぜん気づけなかったとか(413 Request Entity Too LargeとかMySQL server has gone awayとか)、nginxの設定でハマってるときにもっとはやくYappoさんに見てもらえばよかったとか、なんか22番と80番以外のポートで通信できないなと思ってiptables叩いてもルール空で(1台目以外は空だった)ずっとおかしいなって思ってたのももっとはやくなんかおかしいっていえばすぐ解決したのに(Yappoさんが1台目でiptables打ったら一瞬で解決した)、それで自分の作業に掛かりっきりで他の人の変更追えてなかったからアプリがずっとFailしてるのを弱り切った心でコードレビューする気力なくなっててラスト30分諦めてぼーっとしてたりまぁとにかく反省することはたくさんあったけど、終わってから一番後悔してるのは全ての変更をrevertしてでもベンチが通る状態で終わらなかったこと。去年は要件を誤って解釈していたせいで最後断腸の思いで全ての変更をrevertしてベンチが通る状態に戻して苦い思いをしたけど、Failして終わるというのはそれ以上に苦い思いであった。
僕のバックグラウンドは運用エンジニアなので、運用エンジニアの矜持として動いてるものを壊したらあかんという気持ちをとても強く持ってる。これを外科医に例えると、腹開いてみてすごい末期だけどダメ元で手術してみて死んでしまいましたじゃなくて、手術で死なせるわけにはいかんからダメ元ならなにもせずに腹を閉じようの精神かもしれない。それを心が折れてたとはいえ最後諦めてしまった。つらい。しかし愚者も経験から学ぶのである。もう絶対に諦めたりしない。
そして来年こそこの思いをあの子に伝えられたらと思う。
