前回、竹内（@rikson_en）から「ISUCON に参加することになった」と聞いて、興味をそそられている。
ISUCON とは Web アプリケーションを短時間で徹底的に高速化して、そのスコアを競う大会で、僕は以前、競技プログラミングの大会には参加したことはあったが、 ISUCON はまた少し毛色が違って、いわば本番さながらのインフラやアプリのチューニングを試されるところが魅力だ。
竹内は金曜の夜になると「過去問を試すか」と思い立ち、深夜に Vim の設定に没頭し始めたらしい。 Go 言語のランゲージサーバを整えるのに時間がかかったようで、気づけば明け方が近くなっていたというのだから、本来の勉強に取りかかる前に膨大なエネルギーを使っている。
彼いわく、ISUCON は過去問を Docker や AWS で構築して、あらかじめベンチマークツールを回しておくのが練習の王道らしい。 DB や Nginx の設定を少し変えるだけでスコアが上下するので、それを地道に試すのが大事だと力説していた。
実際、朝方になってから過去問を動かし、ベンチマークを走らせてみると、初期状態でそれなりに点数が出たらしい。 ただ、インデックスを貼るだけでスコアがぐっと伸びる一方、Nginx のキャッシュをいじったら逆に落ちることもあって、なぜそうなるのかまだよく分からないという。 僕も過去問を少し調べてみると、Docker でサクッと立ち上げられる年の問題と、AWS で構築する手順しか用意されていないものが混在していることが分かる。 大会によって形式が変わり、予選がある年とない年があることも初耳だった。年ごとでけっこう違いが出るらしい。
竹内が言うには「3 人 1 チームで役割分担をするのがセオリー」だそうだ。 例えばアプリ担当が SQL の JOIN や N+1 問題を潰し、インフラ担当が Nginx や DB サーバの設定を調整し、もう一人が雑務や全体の指揮を取るといった具合です。 ところが、初参加の竹内は「自分はどの担当をやればいいのか」と少し悩んでいるようだった。 Go 言語は使ったことがないし、インフラまわりも詳しくない。 ただ、実際に過去問を眺めてみると、複数の SELECT 文をまとめて JOIN にしてみるなど、明らかに速度が上がりそうな箇所が見つかったようで、そこなら貢献できそうだと話していた。 初心者でも定番パターンに当たれば着実にスコアを上げられるのが ISUCON の面白いところだと思う。
僕は競技プログラミングに触れたことがあるだけで、ISUCON 自体はそこまで詳しくない。 しかし、話を聞いていると「モダンな Web 開発」の実践的な訓練になりそうで、思いのほかワクワクしてきた。 上位を狙う人たちは、パフォーマンスチューニングの鉄板手法をすべて暗記していて、短時間でごっそり設定を変えてくるらしい。 反面、竹内のように Vim のセットアップや SQL の書き方で一喜一憂するのも、コンテストならではの醍醐味だと感じる。 本番では 8 時間ほどの制限時間の中で手数を出していくことになるそうだから、きっと他のメンバーとの連携も重要になるだろう。 僕も機会があれば参加してみたいし、まずは竹内が大会でどんな結果を残すのか、興味を持って見守りたいと思う。
