ISUCONの問題作成の舞台裏を2020年の出題チーム・白金動物園に聞いてみた

── ISUCON4の問題作成工程はうまくいったのですか。

mirakui　いま思い返すと、ISUCON4のときはかなり無邪気に問題を作っていたなと思います。うまくいかなかった部分もたくさんありました。

たとえば、工数管理です。問題作成のためにかなり徹夜しないといけないことに……。今回はまだ徹夜していませんが、競技開始の前の晩、自宅のベッドで寝ていたら、工数管理については成功、ということにしようと思っています（笑）。

── 工数管理以外はうまくいったのでしょうか。

sorah　いえ、予選1日目にベンチマーカーにバグが見つかり、2日目までに修正を余儀なくされた、という失敗もありました。

mirakui　本来なら1分でベンチマーカーへのリクエストが打ち切られるはずなのに、1分以上にわたってリクエストを流し続けることができてしまうというバグでした。

そのバグにより、参加者がチューニングを進めて負荷が高くなると無限にスコアを伸ばせてしまう状態が発生してしまいました。 バグを突いてスコアを伸ばしたチームの扱いを考えたり、謝罪文を書いたり、翌日の競技で使えるようにベンチマーカーを1日で修正したり、運営本部だったLINE社のオフィスで厳しい空気にさらされながら対応していたのをよく覚えています。

rosylilly　また、本選の問題については、設計に大きな反省点があります。ベンチマーカーに「Cache-Controlヘッダを考慮してConditional GETリクエストを行う」という機能を用意していたのですが……。

mirakui　参加者がその機能の存在に気づいてCache-Controlヘッダを設定すれば、動画を制御できるような仕掛けを入れていたんです。これにより動画のトラフィックをかなり減らせるので、そこから本格的なチューニングに入るようなアプローチを期待していました。

私たち出題側としては、ほとんどの参加者が機能の存在に気づくと思っていたのですが、実際に競技が始まると、当初は誰一人その存在に気づかず、なかなか本選で意図していた問題設定までたどりつくチームが出なかったんです。Cache-Controlなしのままでチューニングを進めると、すぐに帯域が詰まってしまいスコアが上がらなくなります。手詰まりになった参加者から、「この状態は問題の意図どおりですか？」という質問を受けたりもしました。

rosylilly　そのうち、突然スコアを跳ね上げて1位にランクインするチームが出てきたんです。予選問題でバグを出してしまったので怖くなり、「いま何をしましたか？」と聞きに行ったんです。そしたら何のことはなく、無事にベンチマーカーに仕込んでいたCache-Controlを見つけてくれていたんです。すごくほっとしたのを覚えています。

ただ、優勝したのは違うチームでした。スコアの急上昇を見て、「ベンチマーカーに何か気づいていない仕掛けがある」と確信して探したそうです。ちょっとしたソーシャルハック戦略ですね。

▲スコア急上昇が観測され、ザワつく様子がTwitterで垣間見える。

sorah　このときの混乱から、その後のISUCONではベンチマーカーについて「どこまでの情報を事前に公開するか（あるいは公開しないか）をきちんと文書にしておく」ことが意識されるように思います。わたしたちの設計上の失敗は、先行事例としてその後のISUCONの役に立ったといえるかもしれません（笑）。今回のISUCON10は6年前の失敗を取り返すチャンスです。「NO MORE ISUCON4」を掲げ、頑張って問題を作っています。

言語特性を考慮するのか？作問プロセスと、そこから見える「やるべき対策」

── 作問のプロセスに関しても教えて下さい。問題を作るときは、事前に「チューニングのベストプラクティス」を想定しながら作るのでしょうか？

sorah　ISUCON4のときは、そこまで考える余裕がありませんでしたが、最近は「予選と本選の問題を別々のチームが作り、お互いがそれを事前に解きあう」という作問プロセスになっています。ですから、まったく誰も解かないまま当日を迎えることはありません。

── なるほど。もうひとつ、ISUCONでは参加者が利用するプログラミング言語は自由です。どの言語を選択するかによってスコアに差が出ることがないように考慮して問題を設計しているのでしょうか？

sorah　幸い、多くのウェブアプリはI/Oヘビーなので、プログラミング言語によって大きな差は出ません。並行性に関する機能の有無で初期のパフォーマンスの出しやすさには差が出るかもしれませんが。

mirakui　ISUCON4の出題も、そもそもI/Oがヘビーになるように作った問題だったこともあり、言語による優劣は気にしませんでした。

rosylilly　ただ、ベンチマーカー担当としては、言語の違いによるHTMLテンプレートの速度差は気にしていましたね。

sorah　HTMLテンプレートは言語やフレームワークによる違いがけっこうありますからね。ただ、最近はJavaScriptで何でもやる時代なので、問題を作るときも、フロントエンド側については「Web APIを叩いてJSONを返すだけ」といった形で設計されることが多いと思います。

mirakui　チューニングが進んだ後でCPUを使い切ってしまうような問題設計になっていると、言語による差が出ることはありますね。 たとえばISUCON7の本選は、内部でbigint型の値の計算が発生する問題だったのですが、こうした場合、言語による差があったと思います。

sorah　現実世界のアプリケーションであれば、「そんなところで絶対にbigintは使わせない」というようなケースでしたよね。

僕たちのチームは、普段は「みんながGoを使うようになってもRubyでやる」と決めていますが、あのときばかりは煩悩に負けて「Rubyだと厳しそうなのでGoを使う」という判断をしてしまったんですよ。そうしたら、実はGo標準のbigintライブラリは他の言語に比べて遅めで、一方のRubyは数年前にbigint実装が更新されて高速だったんです……。

適材適所の要素はありますが、個人的にもRubyは好きな言語です。一貫してRubyで勝負してきた流れを断ってしまったし、そのうえ、「Rubyの適材適所」に関して判断ミスしてしまったとも考えられたので、かなり悔しい思いをしてしまいました。その後もRubyにこだわり続けてきましたが、ついに ISUCON9でRubyを使って優勝できたので、本当によかったです。

── 一見すると問題に向いていそうに見える不慣れな言語で挑むよりも、自分がノウハウを持っている言語でアプローチするのがいい、とも言えそうですね。

mirakui　ISUCONは8時間しかないので、不慣れな言語で始めるのは博打のようなものです。

rosylilly　「あるプログラミング言語ができる」と一口にいっても、「その言語でウェブアプリが書ける」というレベルと、「その言語のユーザーコミュニティや文化の作法がわかる」というレベルの間には、すごく大きな隔たりがあると思います。

ISUCONでは、限られた時間で大量のソースを読むことになります。いちいち「ある関数がどのライブラリで定義されているか」を探しているような時間はないので、「その言語の作法を熟知している」レベルでスムーズに読める言語でないと、かなりきついと思います。

sorah　自分たちの場合、そのレベルで使えるのがRubyとGoなので、Rubyの参考実装をメインで読みつつ、裏でGoの実装も読んで部分的に利用するというやり方をしています。

── それもあって出題側では複数の言語で参考実装を用意するわけですね。

mirakui　参加者の観点では、「出題者の意図が最速で読み解けるのは、出題者が得意とする言語。だから、それで勝負する」というメタ戦略もあるかもしれませんね。「今回の出題チームはいつもGoを使っているから、きっと参考実装をGoで書いたはず。だからそれを読むのが一番いいだろう」といったように。

rosylilly　ISUCON4のころと違い、最近は出題者自身が書くのは1つの言語の実装だけで、他言語への移植はボランティアが担当することもあります。出題者の意図が最も的確に表現されているのはオリジナルの参考実装だ、というメタ戦略もありえるかもしれません。

sorah　ただ、1つしか言語を使えない、という場合、選択肢は狭まってしまうというのも確かです。2つ以上の言語の長所と短所を把握しておくと戦略上有利だと個人的には思います。複数の実装を読むことで理解が深まったり、問題に適したライブラリやフレームワークを使えるでしょう。自分たちも、Rubyをメインにしつつ、部分的にGoを使って乗り切った回がありました。もちろん、ISUCONに限らず日頃の業務でも役に立ちます。

変化するISUCON。学生参加者はなぜ躍進したのか

── ISUCON4のときと比べると、参加者のバックグラウンドも多様化していると思いますか？

mirakui　学生の参加者がどんどん増えて、しかも強くなっています。ISUCONには以前からは「学生枠」というのが用意されていて、全体ランキングが低くても学生の中で高順位なら本選に残れるような仕組みがあります。この仕組みが生まれた当初はそれくらい、学生と社会人の間にスコアの差があったんです。

それがいまでは学生が本当に強くて、本選でも全体の上位に学生のチームが食い込んできます。実際、ISUCON9では学生チームが2位になっています。

▲ISUCON8では大会史上初めて、学生チームが優勝を飾っている。

── インフラのチューニングを競うコンテストなので、業務経験がものをいう社会人のほうが圧倒的に有利な気がします。

rosylilly　もちろん、業務でやっているほうが有利な面はたくさんありますが、学生が強くなったのには、“負荷”を手に入れられるようになったのが要因だと見ています。

そもそもアプリケーションにおけるパフォーマンスの問題は、そのアプリケーションを使う人がたくさんいないと発生しません。社会人参加者の多くは、どこかしらの企業に所属し、業務としてサービスのユーザーが生み出す大きな負荷をさばいた経験を持っているでしょう。一方で、学生は、こうした本物の負荷を手にるす機会には、なかなか恵まれません。

ところがISUCONでは、ベンチマーカーが過去問という形で提供されていて、アプリケーションに対して実際にかかるような本物の負荷を学生でも手に入れられます。いま学生が強くなっているのは、ISUCONが回数を重ねて過去問が増えたことで、負荷を手にする機会が増え、負荷と対峙する経験を積んだ結果だと思います。

sorah　さらに、時間が豊富な点も学生の強みです。過去問を全部やって参加してくるから、非常に手強い相手になるんです。

mirakui　学生が強くなったのはISUCONがベンチマーカーを配ったからで、それがISUCONの意義でもあった、といえるかもしれませんね。

ISUCONは「学ぶ必要性」を作り出す場

── 学生エンジニアの技術の底上げに寄与する、とはなんとも素晴らしい意義だと感じます。みなさんにとって、ISUCONはどのような意味を持つコンテストなのでしょうか。

rosylilly　僕はいま、起業してウェブアプリケーションを扱っていますが、ISUCONでの経験が非常に役立っています。ただしこれは、「ISUCONのおかげで何かを直せるようになった」ではなく、「ISUCONのおかげでイケてない実装を書かなくなった」という意味です。

セキュリティでは「攻撃方法を知らないと防御方法もわからない」といわれますが、パフォーマンスチューニングもこれに似ていて、遅くする方法を知らないと速くする方法がなかなかわかりません。

しかし、わざわざウェブアプリケーションを遅くする方法を考える機会は仕事ではなかなか訪れませんが、ISUCON出題者という立場は、それを考える絶好の機会です。おかげで、「こんなふうに書くとISUCONの参考実装みたいだな」と思ってやめる、といったことがよくあります（笑）。

mirakui　クックパッドでは新人を対象にした「社内ISUCON」を定期的に開催しています。とても盛り上がりますし、なによりよい勉強になるので、「ISUCONは実務でとても役に立つ」と実感しています。

── 実際の業務で問題に直面して必要になる前に、勉強する機会を作ってしまうわけですね。

mirakui　業務だとインフラまわりの作業がどんどん自動化されているので、アプリケーションエンジニアがインフラのセットアップに苦労する場面はあまりありません。最近ではSSHでログインしてオペレーションをする機会もないんです。

一方で、ISUCONはウェブアプリのほぼ全体を一人でさわる貴重な機会です。社内ISUCONを実施すれば、通常業務では使わない技術に触れることができ、研修のパッケージとして非常によくできているわけです。

sorah　インフラだけでなく、ISUCONの問題になるような「昔ながらのSQLのパフォーマンスチューニング」みたいなものに業務で遭遇する機会も貴重になっていますね。クラウドでマイクロサービスみたいな環境が増えた結果、「APIを叩いて右からきたJSONを左に流すだけ」といった作業も多いですし、「そもそもRDBMSではない」ということもありえるでしょう。

rosylilly　その意味では、自分は一般的なパフォーマンスチューニングの手法はすべてISUCONで学んだといってもいいくらいです。超単純だけど頻出するn+1クエリの解消なんかも、ISUCONを通して勉強したようなものです。業務で書くアプリケーションでは、n+1クエリを探して解消するような場面は頻繁にはないので、勉強する機会がない。

また、ある程度の規模の組織だと、「不得意な部分を他の人に任せる」ができてしまいます。ところが、ISUCONに出るとなれば、スコアのために勉強します。自分にとってはISUCONが「必要性に直面する機会」なのだと思います。

── 最後にISUCON10参加者へのメッセージをお願いします。

rosylilly　7年近く参加しているので、ISUCONコミュニティに対する仲間意識や恩や友情のようなものが自分の中にはあります。ですから、「今年もよろしく。また一緒に遊んでください」というのが正直な気持ちです。ブログでは「かかってこい！」と書いたりもしますが、どちらかというと出題者が参加者に挑戦するイベントだと思っていますので、参加者のみなさんに楽しい場を提供し、一緒に楽しみたいです。

sorah　出題者として重視しているのは、いろんな人が参加するようになったので、みんながフェアに楽しめるような問題を作ることです。 何もできなかった人も、負けた人も、勝った人も、「いい問題だったな」と感じてもらえるような出題を予定しているので、ぜひ楽しんでください。

mirakui　生みの苦しみは、出題の楽しみでもあるので、個人的にはすごくわくわくしています。業務そっちのけで参考実装を書き続けていたいと思うくらい、楽しくてしょうがないんです。同じように楽しんでくれる人がたくさん参加してくれたらうれしいです。皆さんの期待に応えられるような問題にしたいですね。

取材・執筆：鹿野 桂一郎（技術書出版ラムダノート）