はじめに
ISUCONでは決勝に出たことがないけど、ISUCONが好きな @showwin です。
ISUCONは5から出場し始めて、毎回出場しているので合計4回参加しています。特に今年のISUCON8は社内の優秀なメンバーと組めたので、決勝行けるだろうと思っていたのですが、残念ながらまたしても予選落ちでした。。
来年は絶対決勝行きます…！！
ぼくはISUCONが好きすぎて、ISHOCONという個人ISUCON問題を作成しています。
ISHOCONのコンセプトは "一人でできる簡単なISUCON" で、ISUCON出場する前に練習したい。でもISUCONだとボリューミーなのでもうちょっと気軽にISUCON練習したい！という人向けに問題を作成しています。
去年、今年とISHOCON問題を皆で解いてISUCONの素振りをするというイベントをやっているのですが、今年も30人弱が参加していただいて、一人でゆるく参加できるISUCONイベントは意外と需要があるのでは！？と思っているところです。
(ISUCON8も一人参加枠はすぐに埋まっていましたからね…)
と、前置きが長くなってしまったのですが、個人ISUCON問題を作る上での流れとTipsを紹介したいと思います。
1. 問題のコンセプト決め
個人ISUCON問題に興味を持ってもらうには、コンセプトの面白さが大事なんじゃないかな？と思って、ぼくは結構力を入れて考えています。
ISUCON1を作成した当時2015年は中国人観光客が日本にガンガン来始めた年で、"爆買い"という言葉が流行っていました。中国の方が日本のECサイトで爆買いを始めても大丈夫なように、ISUしましょう！という思いを込めて問題を作成しました。
ISUCON2では、まだ日本では実現していませんが、そのうち実現するだろうと思っているネット選挙をテーマにしたものでした。将来ネット選挙のプラットフォームを自分が実装することになった時に、高速化することがどれほど大変なんだろう…と気づけるかも知れませんね。笑
実は ISHOCON3 も作りかけていて、「今後の高齢化社会で遺言書のバージョン管理が必要になるが、バックエンドのログ管理部分をgitで実装してしまってスケールしない…」というクソ実装にする予定だったのですが、作り始めたら意外とうまく問題が作れなくて一旦開発が止まってしまっています…w
ここのコンセプトを決める段階で、ある程度時間を書けないと解消できないような一番大きなボトルネックのアイデアを持っておくと良いと思います。細かなボトルネックはアプリケーションを実装し始めてからでも仕込めるのですが、勝負を決める大きめのギミックはあとから決めるとうまくできなかったり、面白いギミックが作れなくなりがちです。
2. アプリケーションを実装して、ボトルネックを作る
コンセプトが決まったら、アプリケーションの実装に入ります。
ISHOCONの場合は1人で取り組んで8時間でやりたいことの8割ぐらいができる分量を目指しているので、(ページ数が全てではありませんが)2~3ページぐらいの軽量なアプリケーションに収まるように意識して仕様を決めながら実装をしていきます。
その過程で、この辺にN+1を入れていくかーとか、ネットワークがボトルネックになるようにこの辺いじっておくか〜とか考えながら実装していきます。
いきなり100%完成した問題を作ろうとするより、80%ぐらいの出来のもので止めておくのがよいです。ベンチマーカーができて実際に問題を解いてみるといろいろと調整したくなるのが世の常なので…
3. ベンチマーカーの実装
並列でリクエストをガンガン投げられるベンチマーカーを作成していきます。
個人的には goroutine を使ってGoで書くのが一番楽じゃないかなと思っています。
リクエストパターンはいくつか典型的なユーザ行動パターンを作って、そのパターンを繰り返し実行していくのがよくある方針だと思います。
レスポンスのバリデーションの厳密さや、リクエスト負荷増加の手動/自動など、手を抜こうと思えば抜ける部分がベンチマーカーには多くあります。サッと自作ISUCON問題を作りたい場合にはここで手を抜くのが良いと思います。
(本番のISUCONではそうはいかないと思いますが…)
ある特徴的なリクエストパターンに気づけるとスコアアップにつながる。みたいな要素があると面白いかもしれないですね。
4. アプリケーションチューニングとスコア調整
このフェーズは意外と時間が取られます。
特にスコア調整は難しく、手順1で作った大きめのギミックが分かるとドンと点数があがるようなスコアリングにしたいな〜と思うのですが、地道な改善を続けていっても結構な点数が出てしまったりと、いきなりうまくいくことは少ないです。
ISHOCONなんかは入門者向けに作っていることもあり、DBのインデックスを貼ったり、だれでも気づくようなN+1を修正すると初期の10倍ぐらいのスコアになって良い気分になれるようなスコアリング設計になっています。笑
UXに関わってくる部分なので、どうしたら飽きずに8時間遊んでもらえるか。8時間終わったあとも、あ〜もうちょっと触りたい！！と思って遊び続けてもらえるか、といったところを考えながらチューニングしていきます。ゲームづくりの感覚に近いのかも知れませんね。
チューニングをしすぎると問題に慣れてしまって、初見でこの問題やるとどれぐらい時間がかかるのだろう🤔と分からなくなってくると思います。
そのような時には1,2ヶ月ぐらい放置すると、何を作ったか忘れて新鮮な気持ちで問題に取り組めるので一回クールダウンするのも大事です！
5. イベントを開催して皆に解いてもらおう
せっかく問題を作ったのに誰も解いてくれないのでは面白くありません。ISUCONが近くなって皆のISUCON意欲が高まってきた頃に同じチームメンバーの人に解いてもらうとか、僕のようにイベントを開催するとかすると多くの人に遊んでもらえるのかなと思います。
その際にはドキュメントの整備も必要になってきます。テストユーザーにこの情報で過不足がないか確認してもらいましょう。(作った本人はドキュメントがなくても理解できていますからね。。)
最後に
最初は自己満足でつくっていた自作ISUCONの問題でしたが、全然知らない人がISUCON勉強会イベントで使ってくれたり、他社の社内ISUCONでも使われたり、他言語実装のPullReqが飛んできたりと、思いもよらぬ広がりをみせています。
皆さんも自作ISUCON問題を作ってみると意外と面白いつながりができるかもしれません、ぜひ一度作ってみてください！