たごもりすメモ

コードとかその他の話とか。

俺の考えるISUCON

ISUCONというイベントがある。要するに技術コンテストイベントだ。領域はWebアプリケーションにかかわる全てといってよい。

isucon.net

これがなんなのか、そろそろ一発説明しておくか、という気分にちょっとなったので書く。実は何を隠すこともなく次の出題者なのでいかに出題内容にひっかからないように書くかがちょっと大変かもしれないが、どうせ出題内容とかまだ確定しているわけでもないので、いいや。

ISUCONとは何か

ある日の朝、Webアプリケーションが一式、適当に設定されたサーバごと渡されます。あとベンチマークツールも渡されます。
さて夕方までにこのベンチマークツールの計測するスコアを可能な限り上げてください、そのためなら渡されたサーバ上で何をやっても構いません。ただしベンチマークツールはアプリケーションの動作が変わっていないかどうかチェックするための機構を備えているので、そいつが違反を検出したらスコアは無効です。

これだけです。もちろんコンテストなので詳細は当日朝にレギュレーション文章として渡されます*1が、想定外の事態を防ぎたいだけで、内容としては本当に上のものだけです。

世の中一般におけるWebアプリケーションというやつは通常、Webサーバ、アプリケーションサーバアプリケーションサーバ上で動作するプログラムコード、およびデータベースから成ります。データベースは多くの場合はRDBMSですが、まれにNoSQLオンリーという強烈な構成のものも世の中にはあります。あとキャッシュサーバを追加したりもしますね。
ISUCONにおけるWebアプリケーションもだいたいはこういうやつです。学生の頃には自分もRDBMSをさわったりはほとんどしなかったけど、お金を稼ぐためにRDBMSは非常に強力なソフトウェアなので、だいたい働きはじめると使うことになります。

ISUCONにおける「何をやってもいい」というのは本当に何でもよくて、別言語でスクラッチから実装し直そうがサーバソフトウェアの構成を完全に変えようがOSから入れ替えようが、何でもいいです。Webアプリケーションの動作さえ変えなければ。これはそれらしい用語ではブラックボックステストとか言ったりします。
これは要するに「あなたに全てをぶっこわす権利をあげます」ということです。それで勝てるもんなら勝ってください。それを見てみたい。

現代のISUCON

むかしむかし、ISUCONには一人で参加できました。現代のISUCONには一人では参加できません。必ず2人か3人でチームを組む必要があります。なぜか。
極めて簡単で、これは1人で勝てるものではない、ということがやってみて明らかになったからです。1人では絶対に勝てません。本当は2人でもつらくて、これまでの優勝チームは漏れなく3人チームですし、上位入賞チームもほとんどが3人です*2

むかしむかし、ISUCONは先着申し込み順での決勝1日だけのイベントでした。現代のISUCONは予選をリモートで行い、通過者が会場に集まって決勝を行うことになっています。なぜか。
最初はこんなコンテストにこんなに参加者が集まるとは思っていなかったからです。が、今となっては70以上のチームが参加*3するイベントになりました。他に似たようなイベントがなかったのが目新しいからでしょうか。
一方会場に集まって決勝をやるスタイルはそのままです。これは単純に、そのほうが盛り上がるからです。イベント後に飲みながらお互い何をやったか話し合うのが、もう、めちゃくちゃに面白いからです。

むかしむかし、ISUCONのWebアプリケーション提供はPerl, Ruby, Node.jsのみで行われました。現代のISUCONではPerl, Ruby, PHP, Golang, Python, Java, Node.jsなどから、増えたり減ったりしつついくつも提供されています。
これは主催者が考えるに、スコアが出せるかどうかは言語の問題ではない、と思うからです。どの言語だろうと勝つ人は勝ちます。速い言語遅い言語で勝負がつくようなつまんない問題は過去一度も出されませんでした。
だがしかし、過去4回の優勝チームの使用言語は全てPerlでした。今年はどうかな?

ISUCONの技術

ISUCONでは様々な技術が必要とされます。もちろん、ごく基本的なWebアプリケーションを書く能力は真っ先に求められます。いわゆるWeb一般の知識、HTTPやHTML/Javascript/CSSなどの基本および応用的な知識も必要でしょう。

性能を出すためには各種ミドルウェアを適切に設定する必要もあります。Webサーバ、アプリケーションサーバ、データベース、Key-Value-Storage、OSなどは少なくとも一ヶ所ずつ手を入れることになるでしょう。
ISUCON出題者はナンセンスな設定を参加者に押し付けることはありません。最初からそこそこ動く設定はおそらく行われています。しかしスコアを出すためにはそこに安住できないのはもちろんのことです。

ISUCONで勝とうと思ったらアプリケーションの改造を恐れてはいけません。高パフォーマンスなアプリケーションを作るためには、適切なキャッシュの管理、RDBMSへのクエリの最適化と適切なインデックスの作成、データの持ちかたの変更、その他ありとあらゆる計算量・処理データ量の削減の努力が求められます。
それを最適な形で実現するために、アプリケーションコード以外のあらゆる部分の変更の可能性を検討すると同時に、アプリケーションコードの変更を組み合わせることを考えてください。

現代のISUCONはチーム戦です。厳しい制限時間の中で、2人が同じことをやっている余裕はありません。コミュニケーションをとり、お互いを信頼して作業を進めましょう。
そしてその結果をお互いにチェックしあいましょう。人間はミスをするものです。ミスを相互にカバーできるのがチームです。

ISUCONの勝敗

最終的に、勝敗はつきます。勝敗は大事です。勝つために参加しているのです。

しかし、最も大事なものは勝敗ではありません。決勝なら25以上のチーム、予選なら去年はなんと185ものチームが、同じ時間に、同じ問題に、同じ目的で、最大限集中して取り組んだということが一番大事なことです。

普段我々が手にできない、全く同じ前提条件でのフラットな技術的な議論ができる場が、そこにできるのです。
その意味では、ISUCON参加前と参加後に最も多くのものを持ち帰った人こそが勝者と言えるでしょう。

まとめ

ISUCONは超面白いので、今年のもたぶん面白くなると思うので、みんな参加したらいいと思う。

とはいえ、普段Webサービスを開発している人にとっては普段の仕事領域だけど、学生の人達にはRDBMSなんか触ったこともない、という人もいると思う。まあ機会なけりゃそんなもんだよね。しかしRDBMSを使ってみたという経験がこの後に無駄になることは100%ありえないので、ぜひこの機会にやってみてほしい。

ということで機会があります。学生の方はいかがでしょうか。isucon.net

さー今年のISUCONの問題はどうしよっかなー!

*1:概要は参加受付時、事前に公開されます

*2:一度だけ2人チームが準優勝まで行ったことがあります、おそろしいおそろしい。

*3:2014年