11回目を迎えたISUCON11、30チームが本選に出場

11回目を迎える、エンジニアたちのチューニングバトルISUCON11。去る8月21日にオンライン予選が開催され、上位30チームが本選に進むことになりました。

いよいよ本番が迫る中、今回、gihyo.jpが注目するいくつかのチームに事前メールインタビューを行い、本選に向けた意気込みとISUCON11にかける想いを聞きました。

ISUCON公式Blog

https://isucon.net/

インタビューを実施したのは4つのカテゴリ

今回、インタビューを実施したのは、

• 優勝経験者在籍チーム
• 連続本選出場チーム
• 学生上位チーム
• 初出場チーム

11回目を迎え、優勝経験者や連続出場チームだけではなく、学生チームの本選通過、また、初出場で本選に進んだチームもあります。それぞれのチームがどのような想いでエントリを決め、また、予選を通過した決め手が何だったのか。そして、間近に迫った本選に向けての意気込みを伺い、各チームの本音に迫りました。

今回の共通質問は次の3つになります。

1. 今回の予選課題が発表されて、最初に感じたこと、また、具体的に取り組むに当たってどのような方針でスタートしましたか。
2. 決定した方針を進めるにあたって難しかったこと、チームとして工夫したことがあれば教えてください。
3. 本選に向けての意気込みを一言！

優勝経験者在籍チーム

まず、fujiwara組、第6西東京市の優勝経験者在籍の2チームを紹介します。

fujiwara組（スコア：769405）

①の回答

題材がIoTとのことで、書き込み量が多くなりそうだなと思いました。コード量が多かったため、いったんSQLだけ読んで処理内容をかんたんに理解し、その後はメトリクスやpt-query-digestなどのツールでの解析結果を参考に、ボトルネックを解消していきました。

②の回答

チーム全員がおなじ会社の同僚のため、役割分担は前回ISUCON10の時や仕事のときと同様にすんなり決まりました。どちらかといえばアプリケーションのチューニングポイントが多かったので、全員がコードに手を入れる形になったのですが、その分担も上手くできたと思います。

セオリー通り高速化を進めるとしっかりスコアが上がる良問だったため、難しいことはあまりなかったのですが、工夫したこととしては、最後に行ったセカンダリインデックスを削除してプライマリキーを複合キーに変更するのが、打ち手として優れていたと思います。

問題になるログの書き込み量については、バルクインサート以外にもいくつか書き込み量を軽減するアイディアは出たものの（差分更新、複数ログを1行にまとめるなど⁠）⁠、実際に取り掛かることはできなかったのが少し残念です。

早い時間帯でチームNaruseJunが100万点を出していたので、最終的には他のチームもそれぐらいの点数まで伸ばしてくるのではないかと戦々恐々としていました。

③本選に向けての意気込みを一言！

久しぶりに優勝したいです！（fujiwara）

本選はいつも頭をヘトヘトに使う問題が多いので、楽しみです!（acidlemon）

スコア的に盛り上がりどころを作れたら良いなと思います！！！（macopy）

第6西東京市（スコア：157464）

①の回答

とても「ISUCONらしい」問題であるなと感じました。確かに遅いことは分かる、手を付けるべき箇所も解く度に見えてくる、しかし直すべき箇所が多く時間は限られている……。8時間という短い時間の中でどのように戦っていくべきなのかを問われている、そんな問題に感じました。

具体的な取り組み方針としては、もう同じメンバーで6回出ているため改めて役割分担のための打ち合わせは行わずともスムーズに作業できました。1人がサーバの設定を確認しつつ計測方法を整え、並行して他のメンバーがマニュアルとコードを熟読し、最初に手を付けるところをお互い軽く相談した上で取り組みました。

②の回答

最初はなかなかブレイクスルーと思えるような点数の上昇を得られずかなりピリピリとした気分でした。たしかに取り組んだ課題に対して確実に点は上がっていくのですが、他の参加者を見ると文字どおり桁が違う得点を出しているチームもあり、安心できない時間が長く感じました。結局のところ最後まで安心はできずじまいだったのですが。

特殊な工夫は行っていないのですが、強いて言うのであれば「いつもどおり」を意識したことでしょうか。

ピリピリとした緊張している場面であっても、早い段階から不安定なスコア上昇施策を採らず、確実に早くなる施策を採り続けることで最終的に大きなスコアの伸びを得られたと考えています。

③本選に向けての意気込みを一言！

今からどのような問題が出るのか、わくわく半分ドキドキ半分と言ったところでしょうか。予選問題のGitリポジトリを拝見したのですが、以前の大会よりも多くの方が作問に参加しており、また「ISUCONらしい」問題についても熟知されている方がとても多いように感じました。

多くの方が参加することにより今までのISUCONでは行えなかった発想や問題が出てくるのではないかと思っています。

メンバーは社会人になりましたが、ISUCON11でも優勝して学生時代の自分たちに勝つことができればと思います。

連続本選出場チーム

続いて、連続本選出場チームから、FetchDecodeExecWrite、ウー馬場ーイー2、チーム中目黒乗り過ごし、カレーおじさんの4チームです。

FetchDecodeExecWrite（スコア：462239）

①の回答

ISUへの愛が感じられる良いストーリーでした。今回特別に用意した方針はなく、他の回同様ボトルネックを見つけては改善する、の繰り返しをしました。したがって、最初に行ったのは各種プロファイリングツールの設定とマニュアルを丁寧に読むことです。すると、DBがボトルネックになることがわかったので、スロークエリを解析し、適宜N+1の解決やインデックスの追加、LIMITの追加などの改善を行ないました。

②の回答

DBのボトルネックをいくつか解決して全体を見渡すと、トレンドの取得が重いことがわかりました。この部分にキャッシュを雑に入れて良いのかと思いましたが、ペナルティがあり調整が難しかったです。

また、ISUから送られてくるデータをすべて反映するのではなく、新規ユーザの獲得につながりそうなものを選別して優先的に保存するようにしました。

③本選に向けての意気込みを一言！

予選は通過さえすればいいので、序盤うまくいけば危険な変更をせず乗り切ることも可能ですが、本選は1位を目指す必要があるので難しいところ。これまで参加した本選は、0点、失格、6位と少しずつ良くなっている（？）ので、今年こそは優勝したい！

ウー馬場ーイー2（スコア：389509）

①の回答

「ISUのコンディション登録が大量にあるだろうから、時系列データベースなどを検討する必要があるかもしれないね」なんて想像していました。ただ実際にはそのような構成変更は行っておらず、検討すらしていません。

方針については毎年同じで、レギュレーションなどのドキュメントをじっくりきちんと読んで・アプリを触ってサービスの内容や目的を理解したうえで、ボトルネックに着目してOODAループを回しています。AppArmorはEnforceにする方針としました。

②の回答

今回はシステムリソースのボトルネックを解消してもスコア上昇につながらないといった状況がたびたび発生しました。CPU負荷は下がったのに、さしてスコアアップしないといった状況です。それでも狙った効果は出せているので良しとして進めたところ、別の改善との相乗効果によって最終的にスコアアップしたと考えています。

チームではドキュメント・アプリ・ログ・システムリソースをつぶさにモニタリングするのと、煮詰まったら立ち止まって発想を転換するよう意識しています。今年の予選問題はコンディション登録が1度に10件登録されるのですが、マニュアルをよく読んだ結果「どうせデータはほとんどdropしているのだから、登録するのは最後の1件だけにしてリクエストをガンガン回してもいいのでは？」と思いつき、これを実践したところスコアが大きく向上しました。それでもAppArmorはEnforceです。

③本選に向けての意気込みを一言！

インフラエンジニア3人で構成される私たちのチームは、ランキング上位のチームに比べるとプログラムを改修する速度がかなり控えめです。だけど奇想天外な発想力と抜群のインフラ力、チーム結成10年のチームワークで補完して、優勝めざして頑張ります！そしてAppArmorはEnforceだぞ！

チーム中目黒乗り過ごし（スコア：289148）

①の回答

まずCloudFormationによる環境構築と、IPアドレスのポータルへの自動反映など丁寧につくられており、予選に集中できる環境が整っていたのは非常に良かったところです。問題としては椅子が自身の状態を送ってくる、IoTやネットワーク機器のメトリクス収集がベースになっているユニークな問題であると感じました。

ここ数年のISUCONでの傾向ですが、ソースコードやデータベースのスキーマだけをみて取り組むことを考えるのはすでに難しく、サーバ、アプリケーションのプロファイリングやデータベースのslowlogを取得し、結果を見ながらボトルネックについて相談し、取り組むことを決めるのが常套手段となっています。

今回であれば、データベースへの書き込みが多くあるのでMySQLのチューニング、明らかに不足しているインデックスの付与、短時間で修正でき、効果の高そうなアプリケーションのコード変更に分かれて手を動かし始めました。

②の回答

最初のインデックス追加でスコアは上がりましたが、その後はアプリケーションに手を入れてもボトルネックが移動し、ジリジリとスコアが上がるものの、改善の方向が正しいかわからず、劇的にスコアがあがるようになるまで我慢の時間が続いたのが、今回の難しいところでした。

その中で、アプリケーションのプロファイルを継続的に取得し、定期的に3人でプロファイル結果を確認し取り組むべき箇所を相談しつつ、ひとつひとつボトルネックを解消し、最終的に予選通過できるスコアにたどりつくことができました。

また、チーム内で今どんなことに取り組んでいるのか、気になっている箇所は「声」を出して確認し、作業の重複やコミュニケーションの行き違いをなくすよう意識し、さらに、デプロイしたコードに問題があ、はり、エラーが発生した際はデプロイした本人だけではなく、全員で原因を探し、解決できない状況で乗り過ごさないようしておりました。

③本選に向けての意気込みを一言！

昨年の本選は最終的に、Failしてしまいスコアを残すことができませんでした。今年はスコアを残しつつ、上位を狙っていきたいです！！１

カレーおじさん（スコア：286089）

①の回答

問題紹介動画を見たときは椅子を擬人化した育成ゲームかと思い、仕様が複雑そうで大変そうだなと思いましたが、蓋を開けたら普通のIoTサービスでホッとしました。

最初の1時間くらいは開発環境の整備とパフォーマンス測定のためのツールの準備、サービスの仕様の確認を行うことに決めていました。役割分担も事前に決めていたので、まずは各自粛々と決めていたタスクをこなしました。最初のタスクが終わった後は、愚直にパフォーマンスの測定を行ってボトルネックを潰していく方針でスタートしました。

②の回答

今回の問題は測定からわかったボトルネックを潰すこと、スコアの計算方法を理解してチューニングを行うことで素直にスコアが伸びていったので、序盤は方針通りに進めるにあたって難しいと感じたことはとくにありませんでした。

「推測するな計測せよ」という格言を忠実に実践することが求められる良い問題だと思いました。ただ、最終的には時間が足りなくなってしまい、3台目のサーバを使用することなく競技終了となってしまった点が心残りです。本選では、時間配分も意識して競技に取り組んでいきたいと思います。

③本選に向けての意気込みを一言！

昨年の本選では終了直前にサーバを起動不能にしてしまう痛恨のバグを仕込んでしまい、失格となってしまいました。今年の本選では、サーバが起動できる状態で終えられるように頑張ります！

学生上位チーム

優勝経験者や連続出場チームだけではありません。ISUCONには毎回多くの学生チームが参加しています。今回は多くの学生チームが本選に通過した中、上位5チームのふらんふらん、aqua Fruits、手が3本あるテディーベア、kotamanegi、komorebiにインタビューを行いました。

ふらんふらん（スコア：128576）

①の回答

IoT系のサービスというのを聞いて、時系列データがたくさんポストされてるくるのかな、それらの書き込みをいい感じにする必要があるのかな、Redisなどを入れたらダイナミックに解決できるかもしれないなとか考えていました。ただ、初参戦で経験値が少ないということもあり、飛び道具は控えて、地道なチューニングをしていこうと決めていました。

②の回答

1人チームで時間が惜しいので、計測ツールなどを流し込めるItamaeを用意していました。また、アプリケーションやマニュアルの全体把握はそこそこにして、ボトルネックに見えていた箇所に修正を重ねながら全体を把握していくという流れで進めていました。筋力が足りず、Nginxの設定で詰まり、Goの実装で詰まり、SQLで詰まりと、思ったように進まない苦しい時間があったことが、決定した方針を進めるにあたって難しかったことです。そういった時に、絶対にスコアが上がることをしようということで、サーバの分離や負荷分散の設定をして心を落ち着かせたのはよかったなと思います。

③本選に向けての意気込みを一言！

力不足を痛感する予選でした。本選が終わった後に、予選時より成長していることの実感を得られると共に良い結果がついてきてくれると嬉しいなと考えています。

aqua Fruits（スコア：124594）

①の回答

IoTサービスであることを知ったとき、絶え間なく細かいデータがPOSTされてきそうと想像したり、どんなヤバいコードがあるのかと期待を膨らませたり、という感じでした。実際に触ってみてからは、椅子に性格があるという世界観がおもしろいと感じていました。

パフォーマンス分析ツールの導入や、各種ログ出力を有効にしてからベンチマークを回して、ボトルネックを解析してから改善を始めるようにしました。

その間にマニュアルとコードに目を通し、気になったポイントの中から許容されているエンドポイントでのキャッシュの有効化と、リクエストを捨てていた部分の確率の変更を試すことからスタートしました。また、機能面で複雑な部分がないことから、SQLの改善はそこまでしなくて良いと予想していました。

②の回答

与えられた3台のインスタンスを最初から複数台構成に変更せず、1人1台利用して試行錯誤する方針は良かったと思っています。そのためのデプロイフローを整え、チームで共有して利用できるようにしていました。また、データベースをGUIで扱えるソフトウェアを使うことで、ベンチマークで使われるデータの特性を把握できるようにしていました。

難しかったことは、ISUCONDITIONを利用するユーザを増やすことに成功したが、スコアが下がってしまう問題への対処だったと思います。ユーザを増やすことは明らかにスコアにつながるのですが、上手く改善させることができませんでした。

③本選に向けての意気込みを一言！

本選めちゃくちゃ楽しみです！予選以上に沢山計測して、沢山挑戦していきたいです！（ゆゆ）

コードをしっかり読んで無駄なく改善していきたいです！（f0reachARR）

「推測するな、計測せよ」を大事にがんばります！（momochi）

手が3本あるテディーベア（スコア：80370）

①の回答

予選課題が発表されて最初に感じたことは、題材のおもしろさ、難しさです。毎年ISUCONではその課題のテーマが決まっており、今回のISUCON11予選課題はIoTを意識した課題となっていました。これは例年にはないもので非常に面白いものでしたが、IoTの性質から膨大なリクエスト数が予想される難しい課題でした。しかし、私たちのチームでは、Webサイトをチューニングする際の計測して改善するというフローは変わらないと考え、練習していたセットアップ作業を行い、計測結果を見てボトルネックを特定し、そこを改善するという方針は変えずに課題に取り組み始めました。

②の回答

ボトルネックを見つけ、改善するという方針により、スコアに現れない無駄な改善をすることなく、効果的な改善を続けていくことができました。これには、あえて担当を決めずに、各々が気づいた改善点を改善していくという工夫によって、見つかったボトルネックを改善できる人がどんどん改善していくという流れを作ることができたのが活きたと思います。しかし、最大のボトルネックが明らかになっているのにも関わらずその改善方法が思い浮かばない際に、点が少し伸び悩んでしまいました。そのような難しい状況をいかに打開できるかが本選の鍵になると思います。

③本選に向けての意気込みを一言！

私たちのチームは学生枠での突破で、上には多くの強豪が立ちはだかっていますが、少しでも良い成績を残せるように精一杯頑張ります！

kotamanegi（スコア：78267）

①の回答

予選課題が発表されて、まず提供マシンの台数やスペックを確認しました。同スペックのAWSインスタンスが3台用意されるということを確認し、今回は割り当てる作業の特性を考慮する必要はなさそうだと感じました。

次に問題文を確認すると、アプリケーション/ISUのコンディション登録/データベースサーバの3つの作業に分担させるのが良さそうだと考えて分離作業をスタートしました。

この方針は結果的には大当たりで、データベースがボトルネックになっていることに気付けたのが収穫でした。

②の回答

DBサーバを分離するのに苦労しました。外部インターネットからのDBアクセスは今回のルールでは許可されていなかったので内部ネットワークからアクセスする必要があるのですが、当初はそのことに気づかず苦戦しました。

また、ソースコードに対して行った変更をサーバ上に反映することにも苦戦しました。Configファイルなどのコピー忘れなどがあり、行った変更が反映されなかったのでその原因調査に時間が掛かってしまいました。

③本選に向けての意気込みを一言！

1人ということで作業量的にはどうしても他のチームに劣ると思うのですが、作業量の分は、まあ、有り余る才能でカバーしたいと思っております。できるだけ上位を目指して貪欲にチャレンジしていきます。よろしくお願いします。

komorebi（スコア：63876）

①の回答

最初は、IoTデバイスからの情報を利用するWebサービスを模した問題ということで、何か細々としたデータを大量に扱う問題だという印象を受けました。そして実際、この大量のデータをどのようにさばききるのかというところが今回の大きなポイントでした。

取り組む際の最初の方針としては、サービス特有のボトルネック部分ではなくて、どのようなサービスでも点数が上がるだろうと考えられる部分から改善を行いました。具体的には、APPとDBの複数台構成、カーネルパラメータやnginxの設定の変更です。

細かい調整は後にして、とりあえず点数を上げることでモチベーションを保ちつつ、後で時間が無くなってこれらの変更ができずに後悔することが無いようにしました。

②の回答

最初にやると決めていた複数台構成や設定の変更について、どの部分をどう変えるのかというメモはしていたのですが、実際に与えられたサーバ3台それぞれに対して変更を入れる際に、慣れていないこともあって、思ったより時間がかかってしまいました。

なので、本来このような決まりきった部分は、多少なりともスクリプトを書くなどして自動化しておくべきだったと後悔しました。

また、アプリケーションのコードを変更する際には、時間をかけて書いた部分のベンチマーク実行が失敗してしまい、さらに、その修正をやると時間がかかりそうだと判断すれば、その部分はあきらめて、より短時間で点数が上がる部分を探すようにしました。

③本選に向けての意気込みを一言！

予選はどうにか突破することができたのですが、時間ぎりぎりまで変更を行っており、一歩間違えればベンチマークが失敗して競技が終了してしまうところでした。事前にもっと練習や準備をしていれば、スムーズに進められる部分がたくさんあったのは非常に大きな反省点です。

本選では、時間を短縮できる部分をできるだけ増やして、アプリケーションの本質的な部分のボトルネックの解消により多くの時間が割けるようにしたいです。

自分の力を最大限に出し切れるよう、かつ全力でISUCONを楽しみつつ、優勝を目指します！

初出場チーム

最後に初出場（または初出場者在籍）で本選通過したチームの中から、今年こそは出場、pizza cat、undefinedの3チームにインタビューを行いました。

今年こそは出場

①の回答

率直に実装量が多そうだと感じました。序盤の方針として、btkはコードのGit化やデプロイスクリプトの作成、y0zaはボトルネック計測のための準備、yuki2006はマニュアルやコードの通読のようにタスクを振り分けました。

序盤のタスクが完了したら、ログ計測の結果からボトルネックとなっているエンドポイントを特定し、各自それを改善していくという方針で進めました。

②の回答

ベンチマークが厳しい、ベンチマークのエラーメッセージから問題箇所を割り出すのに苦戦した印象があります。N+1の改善が難しかったり、できたとしてもあまり改善がなかったり……。過去問と比べて典型的なアプローチが効きづらかったのが難しいと感じました。

工夫した点として、ローカル環境でクロスコンパイルしたGoのバイナリをサーバにデプロイ、各種サービスの設定ファイルの反映と再起動、ログを一括ダウンロードするスクリプトなどを作成しました。

③本選に向けての意気込みを一言！

いい感じに優勝したいと思います！（yuki2006）

初出場なのでチームメンバーに迷惑をかけないように頑張ります！（btk）

優勝したらビール1000本買います！（y0za）

pizza cat

①の回答

私たちはISUCONに向けてとくに何も準備はしていませんでした。そのため、ISUCON用に何か方針を決めた、ということはなく、普段の仕事で気を付けていることを行った、というのが正直なところです。ただ、時間制限が結構大変だと思いましたので、思いつきで対応しないように気を付けました。

②の回答

とくに方針は決めませんでしたが、最終的にはmiが手を動かし、ArmadaSuitがボトルネックを読み解く、という分担になっていました。プロファイラなどもあまり使わずナイーブに問題を解いていたので、もう少し工夫できればよかったと思っています。

③本選に向けての意気込みを一言！

pizza catという、いかにもな名前を付けてしまったな～と思っています。とりあえず好きなものでいいか、という判断がよくなかったです。sushi dogのほうがよかったかな～。がんばります。

undefined

①の回答

最初に感じたこととしては、割とサクサクと動くサービスだったので、改善できるポイントが見つかるか不安でした。チームメンバーはyumechi以外初参加だったので、レギュレーションを読み込み、加点ポイントや注意点を熟読しました。

とりあえずの方針として、過去問をやったときにAPIサーバとDBを分けるということをしていたので、まずその分割をしました。

そのあとはDBログの解析をyumechiが、サーバログの分析をmosmos21が、コードリーディングをpxfncが担当する形に自然となり、N+1クエリや発行回数の多いクエリを地道に改善していきました。

②の回答

慣れていればもっと簡単にできた部分が多かったように思いました。過去問を使って練習をしてきましたが、見えているものの改善できない問題もいくつかありました。具体的には、DBのCPU負荷が高くなる問題や画像配信の最適化に対する対応がいまひとつでした。

また、事前に勉強してきたもののRustのコンパイルがなかなか通らず苦戦しました。

チームとして大まかな方針を決めるなどの工夫をしなかったものの、チームメンバーが見えている問題をコツコツ取り組みました。結果的に改善した点がスコアに反映されました。

③本選に向けての意気込みを一言！

元々勉強目的でコンテストに参加していたので、正直なところ驚いています。本選に向けて勉強を続けていきますが、本選が終わっても学び続けていきたいです。

予選以上にベストを尽くして、良い結果が出るよう頑張ります！

いよいよ本選！栄冠はどのチームに輝くか

いよいよ2021年9月18日にオンライン本選が開催されます。今回ご紹介した14チーム以外に、スコア上位、100万を超えたshallowverse（1464232⁠）⁠、都営三田線東急目黒線直通急行日吉行（1026200）の2チームをはじめ、注目チーム計30チームが登場します。

どんな問題が発表され、各チームどのように取り組み、スコアを獲得していくのか、今年もまたエンジニアたちのアツいチューニングバトルが見られることでしょう。

ISUCON11本選LIVE（YouTube Liveにて配信予定）

2021年9月18日（土）10：00～18：00（JST）

https://www.youtube.com/watch?v=88EyI6xhq98

gihyo.jpでは、本選終了後、優勝チームへの個別インタビューも予定しております。お楽しみに！