ISUCON14に向けて
- 30 Dec, 2024
前回、竹内（@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時間ほどの制限時間の中で手数を出していくことになるそうだから、きっと他のメンバーとの連携も重要になるだろう。 僕も機会があれば参加してみたいし、まずは竹内が大会でどんな結果を残すのか、興味を持って見守りたいと思う。
