エンジニアHubproduced by エン

若手Webエンジニアのための情報メディア

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

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

ISUCONの問題作成の裏側メインカット

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

ISUCON公式Blog

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

mirakui @mirakui

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

sorah @sora_h

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

rosylilly @rosylilly

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

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

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

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

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

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

白金動物園rosylillyさん

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

白金動物園のプライベートリポジトリ

白金動物園のISUCON4作問用プライベートリポジトリでのやりとり。さまざまなアイデアが行き来している。

工数管理、設計ミス……挽回すべきISUCON4の後悔

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

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

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

白金動物園mirakuiさん

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

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を返すだけ」といった形で設計されることが多いと思います。

白金動物園sorahさん

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

ISUCON10が2020年9月12日 / 10月3日開催!
あの熱い戦いが、いよいよ今年も始まります!残念ながらすでに参加登録は締め切られていますが、予選ライブでは上位のスコアがひと目でわかるリアルタイムランキングを公開予定。さらに、本戦ライブでは過去の出題者や優勝者による予選問題解説をお送りするなど、オンラインで大会の盛り上がりが楽しめる仕組みも提供予定です。記念すべき第10回のISUCONを制するのは一体どのチームか、ぜひその目で確かめてください。詳細は以下のISUCON公式ブログか、公式Twitterをチェック!
ISUCON公式Blog
ISUCON公式Twitter

関連記事

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