はじめに
先日、このイベントに参加してきました。
いわゆる社内 ISUCON というやつです。
※ ISUCON
お題となる Web サービスを決められたレギュレーションの中で限界まで高速化を図る LINE 株式会社主催のチューニングバトル、それが ISUCON です。過去の実績も所属している会社も全く関係ない、結果が全てのガチンコバトルです。
（ ISUCON 公式アカウントより/ @isucon_official ）
結論から言うと、かなり楽しかった上に様々なことを学べました。
今回は「どんなイベントだったのか」「どういうアプローチを取ったのか」「何を学んだのか」について書いていきたいと思います。
イベントについて
LITALICO の 社内 ISUCON ということで LISUCON というイベント名でした。
お題
本家 ISUCON と同様、非常に処理の重いサービスが渡され、見た目は一切変えずに限界まで高速化を図るというものです。
お題のアプリケーションは、connpass のようなイベントプラットフォームアプリケーションでした。
お題のアプリケーション、スコアの計算方法、お題アプリケーションにリクエストを送るベンチマーカーなどは全て主催者の方々が自作したオリジナルでした。
ただし、渡されたアプリケーションにはバグが仕込まれており、そのバグを直すことで得点が上がるという、本家にはない要素も盛り込まれていました。
競技時間も 4 時間と短めで、難易度も本家よりかなり簡単めに作られており、私含め本家 ISUCON についてよく知らないエンジニアに対しても参加ハードルをかなり下げた作りになっていました。
参考実装の技術スタック
アプリケーションは最初に渡された状態では、以下のような技術スタックでした。
参加者
社内 ISUCON だったため、基本的に参加したい社内のエンジニアが参加するというものだったのですが、学生も 4 名参加してくれました。
参加した社内のエンジニアは 1 ~ 3 年目のエンジニアがほとんどで、終始和やかな雰囲気でわいわい進めていました。
1 チーム 2 人以下で参加することができたので、私（新卒 2 年目）も同期のエンジニアと一緒に参加しました。
取ったアプローチ
実際の競技では、パートナーと協力して以下の 3 点に取り組みました。
アプリケーションのデバッグ
最初の 30 分で作戦会議を行い、「まずはバグを解消しよう」という話になり、渡された API 仕様書とアプリケーションを見ながらバグを探すことにしました。
すると、以下の 2 つのバグを見つけました。
- 会員登録時に Email の unique バリデーションが効いていない
- イベントのキャンセルを行ってもイベントの空き枠が元に戻らない
sinatra を使って書かれたアプリケーションのコードをいじって、上記 2 つのバグを修正することができました。
因みに競技終了後に解説があったのですが、仕込まれていたバグは合計 3 つで、上記 2 つに加えて「複数の予約が同時に起こった際にデッドロックが発生する」というバグも仕込まれていたそうです。
競技時間中には気付くことができませんでした。
アセット類を nginx が返すようにした
次に取り組んだのは、画像や js ファイルなどを sinatra が返していたので、nginx.conf をいじってこれらのアセット類を nginx が返すようにしました。
root ディレクティブの設定の仕方を、私とパートナー双方が同じ勘違いをしていたためなかなか上手く行かず、かなり時間を取られてしまいました。
ここまでで 3 時間以上掛かってしまいました。
N + 1 問題を解決した
最後に少し残った時間で、N + 1 問題を起こしている箇所があったので、これを解決することにしました。
普段は Rails を使っており、ログを集計する以外にほとんど SQL を書くことがないので、少し苦戦しましたが直すことができました。
改めて ActiveRecord の偉大さを再認識しました。。
ただ、N + 1 問題が起こっていた箇所は全部で 3 箇所用意されていたのですが、時間がなく 1 箇所しか直すことができませんでした。
結果
4 時間は本当に一瞬で「もっと直したいところたくさんあるのに...」という中で終わってしまいました。
あまり上手く時間を使うことができなかったのが、反省です。
ただし、結果は 10 チームぐらい参加していた中で 2 位で個人的には良い結果でした！（一番スコアの高かったチームが再起動試験で落ちて繰り上げ 2 位だったので、実質 3 位かもしれない。）
学んだこと
sinatra、nginx に触れられたということ自体が良い勉強になってとても良かったのですが、以下の 3 つが個人的な学びでした。
仕様書はちゃんと読みましょう
むちゃくちゃ当たり前のことなんですが、私のチーム含め、恐らくほとんどのチームができていなかったと思いました。
「nginx でアセット類を返すようにした」と上述しましたが、実は最初はアセット類をブラウザ側にキャッシュさせるようにしようと試み、失敗に終わっています。
これは渡された仕様書をよく読むと、そのアプローチではスコアが伸びないことが読み取ることができるようになっていました。
「仕様書をちゃんと読む」ということは、まだまだ自分のレベルでは意識しておかないとできないことだと再認識 できました。
無意識に問題の森を見ずに木を見てしまっている
アプリケーションが渡されたときに、作戦会議をしようと試みたのは良かったのですが、最初からかなりソースコードを読んでしまっていました。
まずはブラウザで触ってみて、全体的にどんなアプリなのか把握するべきだったなと感じました。
現に今回のお題では、スコアを上げるためのボトルネックになっている部分がブラウザで確認してもかなり遅く、ブラウザでアプリを全体的にちゃんと見ていたチームは、まずどこに手を入れるべきかすぐ分かるような作りになっていました。
私たちもそのアプローチを取ることで、もっと時間を有効活用できたなぁと思いました。
クイック and ダーティーは存在しない
上記で書いた nginx.conf の root ディレクティブの部分で、作業を早く進めようと、理解が曖昧なままで進めていき、その結果かなり時間をロスしてしまいました。
エンジニアリング組織論でも言われていることですが、クイック and ダーティーなど存在せず、丁寧に進めていくことが最も早いということを再認識できました。
これに関しては今回の競技ではできていた部分もあり、競技の最初の時間でソースコードをバージョン管理できるようにする準備時間を取っていたことから、コミット 5 つ分元に戻して作業を再開してミスをリカバリーできた場面がありました。
終わりに
反省や悔しい点も多かったですが、「はじめに」で述べた通りかなり楽しいイベントでした。
第二回があるかは分かりませんが、あればまた参加したいと思っています。
いずれは運営側に回れたらとも思っています。
と、こんな感じで業務時間中にも色々面白いことやっている会社なので、興味ある方いらっしゃいましたら是非遊びに来てください〜。
なんかエンジニアも随時募集しているっぽいです。