2020-09-08

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

ISUCONの問題は、一体どうやって作られている？あまり明かされることのない、ISUCONの舞台裏を2020年の出題チーム「白金動物園」に聞いてみました。出題者たちは、果たしてなにを考え、どのように参加者と戦うための問題を作っているのか。彼らの答えに、ISUCON攻略のヒントがある!?

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

与えられたWebサービスをいかに高速化するか──。エンジニアが知識と技術を駆使し、パフォーマンスチューニングの成果を競い合うISUCONが、今年（2020年）も間もなく開催されます。参加者が挑む問題は、年ごとに作成者が変わり、例年「どんな問題が出題されるのか」も注目を集めます。

ISUCON公式Blog

今回のISUCON10の出題（一部）を担当するのは、チーム「白金動物園」の3人です。ISUCON9の優勝チームであり、ISUCON4の出題担当も経験する同チームは、どのようなプロセスで問題を作成しているのでしょうか。知られざるISUCON問題作成の裏側、そして古参チームだからこそ知る「ISUCONを勝ち抜くための戦術」を聞きました。

mirakui @mirakui

クックパッド株式会社 CTO。2010年に同社に入社し、サーバサイドのパフォーマンス改善や画像配信を担当するインフラエンジニアとして経験を積み、現職に。白金動物園のリーダー的存在。競技時は主に分析やディサイダーを担当。

sorah @sora_h

クックパッド株式会社ソフトウェア・エンジニア (Developer Productivity, Corporate Engineering)。2012年、中学卒業とともにクックパッドに入社。開発基盤エンジニア、SRE を経て現在のロールに。2011年、14歳でRubyのコミッターとなったことでも知られる。白金動物園の万能選手的存在。競技時は主にインフラやアプリケーション改善を担当。

rosylilly @rosylilly

宇宙海賊合同会社代表。17歳でドワンゴに入社しエンジニアに。その後、2012年にクックパッドに転職。2017年にソフトウェア / ハードウェアの開発・研究支援などを行う宇宙海賊合同会社を設立。白金動物園の飛び道具。競技時は主に一発逆転を担当。

インフラにもアプリケーションにも最適化の余地あり。多様化するISUCONの出題傾向
「過去問に出ていないボトルネック」をいかに作るか。知られざる「ISUCONの問題」の作り方
工数管理、設計ミス……挽回すべきISUCON4の後悔
言語特性を考慮するのか？作問プロセスと、そこから見える「やるべき対策」
変化するISUCON。学生参加者はなぜ躍進したのか
ISUCONは「学ぶ必要性」を作り出す場

インフラにもアプリケーションにも最適化の余地あり。多様化するISUCONの出題傾向

── チーム白金動物園はISUCON常連チームのひとつですが、前回のISUCON9が初めての優勝なんですね。

mirakui　はい。チーム白金動物園はISUCON3で参加者として初参加し、それから毎年ISUCONに顔を出していますが、優勝は前回が初めてです。ISUCONでは、予選を勝ち抜いたチームが本選に出場できることになっていますが、過去本選に出場できたのは半分ほどで、もう半分は予選落ちしているので、常連チームではあるけれど強豪チームではない、という立ち位置でしょうか（笑）。

sorah　ただ、毎年同じメンバーで参加している、という意味では珍しいチームかもしれません。

rosylilly　同じ人が次の年にまったく違うチームで参加するケースもよくありますからね。ISUCONは8時間という長時間にわたってチーム内での濃密なコミュニケーションが要求される技術イベントなので、毎回異なるメンバーと参加できる人がいるというのは個人的に驚きです。イベントは楽しんだ人が勝ちだから、どんな形態で参加してもいいんですが、いろいろなチームを渡り歩く勇気は自分にはありません（笑）。

── 今回のISUCON10では出題側としての参加になるわけですね。出題を担うのは、2014年のISUCON4に続いて2回目ですが、前回と今回で出題への向き合い方に変化はありますか？

sorah　実を言うと、ISUCON4のときは初めての出題だったこともあり、いろいろ悔いも残していました。「そろそろ出題側でリベンジしたいな」、「優勝できたら、その次の大会では出題をやらせてもらおうか」などと話していた矢先、ISUCON9で優勝できて、たまたま正式にオファーもきたので、喜んで引き受けた形です。

── ISUCON4から数えると6年が経過しています。その間にインフラ技術をめぐるトレンドはかなり変わっていると思いますが。

sorah　6年前と今とで、インフラのチューニングに対する基礎的な技術はそれほど大きくは変わっていないと考えています。しかし、作問という観点では前回より考えることは増えました。

まず、6年前よりISUCONに対する要求が高くなっていて、問題のレベルに対する期待も上がっています。その期待は裏切りたくありません。参加者から「簡単じゃん」とか、「あの問題の焼き直しじゃん」とか、「スコアリングの設計が悪くて競技が面白くない」と反応されてしまうような問題には絶対にしたくないです。

また、基礎的な部分は6年間で大きく変わっていなくとも、問題の作り方やテーマの選び方は時代とともに変わります。これらの要素は「高いスコアを出すためのブレークスルー」の材料になるので、出題側としては工夫のしどころです。

mirakui　例年、出題者がかなりこだわって多くの工夫をしているので、過去の問題と同じ解き方を適用して高いスコアをとれる、ということはありません。それに、近年はインフラだけでなくアプリケーションの攻略が鍵になるような問題が多くなってきている印象があります。

たとえばISUCON7ではブラウザゲームを題材にした問題が出ました。複数プレイヤーが同じWebページを見ながら同時プレイする「レイドバトル」が可能なウェブアプリの参考実装があり、これをチューニングするという問題です。ところが、このレイドバトルのためにゲーム内の時間を同期する処理が非常に難解だったんです。

sorah　最初に仕様書のデータを渡されたんですが、競技開始5分ぐらいで「ねえmirakui、このPDFちょっと外のコンビニまで走って印刷してこない？あとノートとペンが欲しい！」とお願いしたことを覚えています。ISUCONでそんなお願いしたのは初めてでしたよ。

mirakui　ISUCON7で自分が出した一番のバリューは、あの買い物だと思ってます（笑）。インフラ以外の技術要素がからむ問題に増えてきたので、インフラが得意な自分の出番が少なくなりつつあるんです。とにかく、問題の作り方は多様化してきています。

たとえば、ISUCON6の問題も、ちょっとした大規模テキスト処理の知識があるとサーバーを高速化できるというテーマでした。はてなのチームが出題を担当していて、「投稿された記事に特定のキーワードが含まれていたら、そのキーワードが含まれるページ同士をリンクさせる」というはてなダイアリーの機能を踏襲した問題でしたが、インフラのチューニングというよりは、ちょっとした競技プログラミングのようなテイストになっていました。

sorah　実際、「インフラというより、アプリケーション実装の要素が強い」という意見もありますよね。ただ、個人的にはさまざまな要素をバランスよく楽しめればいいと思っています。いま例に挙がったISUCON6や7では自分たちも敗北しているので大きなことは言えませんが、インフラで当たり前のRDBのチューニングのような対策をしたうえで「さらにアプリを対策するとスコアが伸びる」という問題の設計だったので、参加者として楽しかったです。

mirakui　確かに、インフラに最適化の余地があり、なおかつアプリケーションにも最適化の余地があるような問題が面白いですよね。いろいろな解き方、いろいろな攻め方ができるのが「良いISUCONの問題」と表現できそうですね。

sorah　もっとも、「いろんな人が楽しめるような問題」と口にするのは簡単ですが、作るのは非常に難しいです。「ごくごく基本的なウェブサービスが参考実装として用意されていて、アプリケーションサーバーとSQLとクライアントの間のボトルネックをつぶす」みたいな問題ばかりでは、参加者も飽きてしまいます。

かといって、「アプリケーション実装側で有効なちょっとしたアルゴリズム」のような、部分的な知識の有無が勝敗を分けてしまっては、“参加者体験”が悪くなってしまいます。一方で出題側としては“部分的な知識”を採り入れることで、より問題が面白くなる、と考えることもあり、バランスをとるのが難しいですね。

「過去問に出ていないボトルネック」をいかに作るか。知られざる「ISUCONの問題」の作り方

── ここからは、作問に関して少し踏み込んでお聞きします。インフラだけなく、アプリケーション側に「難しさ」を作り込んだ出題が増えてきているのはなぜだと思いますか。

sorah　ひとつには、「過去に出題されていないボトルネックの作り方」が枯渇してきた、という理由があるように思います。

mirakui　さらに、インフラのボトルネックをチューニングするにしても、その時々で流行しているチューニング戦略があるので、出題者はそうした戦略への対策を考慮する必要があります。

── 流行の戦略で解けるような問題は出さない、という意味ですか？

mirakui　正確には、「流行の戦略でボトルネックを解消してくるチームでも楽しむ余地がある問題にする」ことに気を配りテーマを決める、というアプローチです。

たとえば我々が問題作成を担当したISUCON4のときは、「データベースに載っているものをすべてオンメモリに展開することでI/Oを少なくして高速化する」という戦略が大流行していました。実際、ISUCON3までの問題には「メモリに載せれば解決できる」ものがありました。仮にオンメモリ戦略が現実的でなくても、そういう戦い方に持ち込むような解法をするチームがけっこうあったんです。

ISUCON4の本選問題を作る際は、動画広告をテーマにしたのですが、これはオンメモリ戦略だけでは解決できない問題を作りたかったからなんです。

メモリに載らないものといったら、“大きいデータ”です。そして大きいデータを取り扱うサービスといったら動画だろう、とテーマを発想していきました。「広告配信ではログ書き込みを正確に行いつつ、大量の数を捌かないといけない」という性質があるので、これはISUCON向きのテーマだなと。

もしも、自分たちが所属するクックパッドのサービスの特性をいかした問題にするとしたら、「ミニクックパッドの実装を用意し、そこに課題になるボトルネックを作り込んでおく」といった出題は考えられるでしょう。しかし、クックパッドはそれほど書き込みヘビーなサービスではなく、そのまま単純化してISUCONの問題にしてしまうと「メモリに載せて速くする」という戦略が奏功してしまう可能性があります。ですから、ISUCON4でも、クックパッドを問題のテーマにする案はありましたが、早々に却下しました。

sorah　もっとも、最近は基本的に会社単位で問題作成のオファーがくるので、自社のサービスで体験している課題や得意なモチーフを使った出題になる印象がありますね。

mirakui　前回のISUCON9の予選では、メルカリのチームがまさしく「メルカリみたいなサービス」をテーマにしていて、自分たちのサービス上の課題をうまくISUCONの問題に落とし込んでいました。すごくきれいな問題設計だなと思いました。

── いま皆さんはISUCON10の問題を構想されているわけですが、今回の問題もクックパッドのサービス特性をテーマにするのは避けるのでしょうか？

sorah　それはネタバレになるので絶対に答えられません（笑）。ただ、自分たちが日々向き合っている課題を盛り込めるテーマにしようとは考えています。

rosylilly　ISUCON4のときに比べると、テーマはかなりスムーズに決まりました。去年のISUCON9で優勝した直後、まだオファーを受ける前に問題案を考えるスレをすぐに立てていましたから（笑）。

mirakui　とはいえ、テーマをベンチマーカーのシナリオとして矛盾がない形にするのは至難の業です。「なにをすればスコアが伸びるような問題にするか」を設計するのが難しく、そこに時間を使っている段階です。

rosylilly　出題者としては、トリッキーなことをしたら勝てるようなベンチマーカーは書きたくないんです。正しいアプローチ、つまりパフォーマンスに対して向き合って考えた結論に対してスコアを与えるようなベンチマーカーを用意したいと考えています。