ISUCONとは「いい感じに スピードアップ コンテスト」(Iikanjini Speed Up CONtest)の略だそうで、課題として与えられたWebアプリケーションを制限時間内でチューニングし、ベンチマークツールによる得点を競う大会です。

本物の方は年1回開催され、賞金はなんと100万円。今年は9/17〜18に予選が行われますが、技術力やモチベーション向上の良い機会であることから、社内で開催される事例も増えているようです。 社内ISUCONにはpixivカヤックなどの事例があります。

その流れに乗ってペパボでも開催することになり、今日がその本番。 参加者は全員ではなく立候補ですが、新卒エンジニアはWebアプリ・Webオペレーション研修と学んできたタイミングなので時期的にもちょうどよく、研修の一環のような形で参加しました。

事前知識なしで突っ込むと何もできずに終わりかねないことから、事前に先輩からISUCONとは何かや、基本的な進め方のレクチャーは受けていました。

が、結果は……見事に撃沈。。。

実力を考えればハイスコアは難しいと思ってはいたが、最後までエラーが直せず完全にお手上げ状態になってしまった。 途中からベンチマークが失敗し続けたので、「ここの設定は知ってるぞ!」とできる範囲でチューニングしてもそれが正しいかどうかまったくわからず、闇の中をひたすら歩き続けるつらさだった。

速度が出なかったりエラーが出る原因は複雑に絡み合っていて、そのチューニング自体は正解だったけど実は主要因は別のところにあったとか、原因の見当がつかないと迷走して時間をロスすることになってしまう。

近視眼的になりすぎた

エラー対処をするうちに近視眼的になりすぎたのも反省点。 先輩によるレクチャーや参考記事は少し読んでいたので、MySQLのslow_query_logなど、まずきちんとログを読んで原因のあてをつけたりなど、開始当初はよい心構えでできたと思う。 しかしアプリに500エラーが頻発する問題が発覚。おそらくチューニングポイントとして用意されていたものだが、その原因が一向に特定できず、ベンチマークが全然通らなくなった焦りもあり、その対処で頭が一杯になってしまった。

今回の参考実装にはRubyとPHPが用意されていたので、Rubyでエラーが出続けるならPHPで試してみたらどうだろうとか、アプリケーションサーバはPumaだったがUnicornに変えてみるとか、試してみることはいろいろあった。 Unicornは研修でも使っていて比較的慣れているのもあり試したのだが、その作業タイミングでベンチマークツールがちょっと不安定になっており確認が有耶無耶になってしまった。 Unicorn化がうまくいっていなかったのか、変更はできたけどエラーは出たままだったのか、それとも単にベンチが不安定で失敗していただけだったのか……それもわからない。

アプリケーションに課題はいっぱいあったのに

ミドルウェアの対処に時間をかけすぎた結果、コードやデータベース構成をきちんと読み込んでアプリケーションを把握することができなかった。 「オペレーション(System Engineering)で点を守り、 プログラミング(Software Engineering)で点をとる」のとおりで、もっと早くアプリケーションコードの課題解決に入るべきだった。

リクエストのボトルネックを見るのにブラウザの開発者ツール使えばわかりやすいじゃんと気付いたのはだいぶ後になってからだし、画像を毎回DBから取り出していることがわかって、ここを静的に、あるいはキャッシュにできればよさそうだとわかってももう時間はなかった。 SQLのチューニングも、データベースの行数を確認して効果がよく出そうなポイントだけに絞るとか、SELECT *を必要なカラムだけ指定する基本のリファクタだけはやるとか、慣れていなくてももっとやりようがあったなと。

「原因の切り分け」や「優先順位」って本当に大事だなと痛感する一日だった。 うう……次はリベンジするぞ。

参加したチームの皆様、そして環境構築・運営のtnmtさんとpyamaさん、おつかれさまでした。