この前の日曜日は ISUCON4 本戦に参加してきました。

当初は予選突破は厳しいと思っていたのですが、最終的に本戦出場が決まったので、前回と同じく「MEAN普及委員会」として出場しました。予選はスコアの都合で Go の実装を使ったのですが、本戦は全員が問題なく読み書きできる Node.js を選択しよう、とメンバーとは事前に話していました。ところが開催の4日前に Node.js の実装はナシとのお知らせがあり、やむなく本戦でも Go を使うことにしました。

本戦のお題は動画広告配信。今回は予選の教訓を生かして開始と同時に Nginx のログを有効化してベンチマークを実行し、処理時間と URL の傾向を見るところからスタート。傾向を見たところ、動画広告のアップロードと動画広告の配信に時間がかかっていて、かつその処理のスコアも高いということで、そのあたりのアプリのコードを読み進めることにしました。

アプリのコードはシンプルで、動画広告のデータがまるまるローカルの Redis に突っ込まれてたり、アクセスログがファイルに書き出されていたりしたので、Redis を別サーバーの Redis を使うようにしたり、ファイルを使っていた部分も Redis を使った実装に切り替えたりと、地道に修正してベンチマークの動きを見ることに。

この時点ではローカルでベンチマークを実行するとスコアはだいたい 14,000 程度で、なかなか悪くない数字だったんですが、なぜか公式のリモート環境でベンチマークを計測すると、7,500 前後に後退。その後も構成を変えてみたり、動画広告のアップロード時にキャッシュ判定できるようにしてみたりしたものの、スコアは上がったり下がったりを繰り返して安定せず、打つ手の効果が見えなくてだいぶ辛かったです。

そんなこんなでそのままタイムアップ。最終スコアも 7,500 で結果は入賞もできず惨敗でした。出題陣からの発表によると、今回の問題はいかにリクエストを減らすかがカギとのことで、サーバー側から動画へのリクエストに対して Cache-Control を設定してあげれば、ベンチマークはそれに従ってキャッシュを使うようになるよ、とのこと。

アプリのコードを見るなかで、キャッシュが使われていなさそう、というポイントには気づいていたのですが、あのベンチマークがそれに従うとは思えずに手を打たなかった部分だったので、これは本当に悔しい。思い込みはせずに柔軟な発想で何でもトライしてみないといけないな思いました。

それにしても、ISUCON への参加は今回が初めてでしたが、いやー、楽しかった。来年も開催とのことなので、優勝目指してリベンジしたいと思います。運営の皆様、本当にありがとうございました。